在持續(xù)流行的、被稱為DevOps的現(xiàn)代軟件交付方法中，溝通、協(xié)作和集成是3個(gè)主要原則。DevOps一詞由Patrick Debois創(chuàng)造于2009年，這個(gè)術(shù)語（開發(fā)和運(yùn)維）是對(duì)敏捷開發(fā)環(huán)境的擴(kuò)展，它的目的是強(qiáng)化軟件交付過程作為一個(gè)整體。
回到2009年，越來越多的IT專業(yè)人士開始擯棄傳統(tǒng)的瀑布方法，轉(zhuǎn)而擁抱非線性的敏捷方法。他們實(shí)現(xiàn)敏捷方法的途徑是，讓每個(gè)開發(fā)階段獨(dú)立，在早期就把持續(xù)測(cè)試納入進(jìn)來，并且把持續(xù)測(cè)試貫穿在整個(gè)部署周期中（請(qǐng)參考本文后半部分的術(shù)語詞匯表以獲取更多細(xì)節(jié)）：
作為這種實(shí)踐的結(jié)果，它提高了效率，同時(shí)減少了風(fēng)險(xiǎn)。之所以能夠?qū)崿F(xiàn)這種結(jié)果，是因?yàn)樗沟瞄_發(fā)者可以基于他們收到的持續(xù)反饋而在部署到生產(chǎn)環(huán)境前做出快速的變更。
雖然敏捷方法通常增強(qiáng)了部署，但是在到達(dá)部署的時(shí)候，在這個(gè)流程中仍然存在著脫節(jié)，因?yàn)樵诓渴鹬幸廊徊捎玫氖瞧俨挤椒ā?/div>
雖然開發(fā)通過使用敏捷方法降低了風(fēng)險(xiǎn)和提高了效率，但是部署卻停滯在了線性的瀑布結(jié)構(gòu)上，這就減慢了交付，并且把測(cè)試留到了這個(gè)過程的最后-這個(gè)過程錯(cuò)誤的劃分了所有者關(guān)系。它帶來了交付周期中的巨大瓶頸，因?yàn)槿绻诮咏渴鸷笃跁r(shí)發(fā)現(xiàn)一個(gè)問題，那么開發(fā)人員需要從頭來過。
通過透視在開發(fā)和部署中的這種脫節(jié)和理解在軟件交付的全部方面都擁抱敏捷所帶來的好處，Debois想到了DevOps的理念。
把開發(fā)和運(yùn)維嫁接起來，同時(shí)采用由敏捷所擴(kuò)展出來的最佳實(shí)踐和原則，那么就有可能極大的提高效率并且降低交付的風(fēng)險(xiǎn)。
DevOps需要文化的變化
DevOps不是一個(gè)工具或者技術(shù)，它是文化的變化。不管組織的類型是什么，大部分組織都是懼怕變化的，所以采用新方法論可能是極具挑戰(zhàn)的。所以，最關(guān)鍵的，首先要做的是，定義業(yè)務(wù)需求，是業(yè)務(wù)需求帶來了對(duì)潛在變化和相應(yīng)挑戰(zhàn)的討論。
現(xiàn)在，我們期望業(yè)務(wù)能夠快速的交付無瑕疵的應(yīng)用，這些應(yīng)用聚焦在用戶體驗(yàn)上。但是，如果沒有恰當(dāng)?shù)墓ぞ?、?yīng)用和行動(dòng)，這個(gè)看起來簡(jiǎn)單的任務(wù)將會(huì)變得團(tuán)團(tuán)糟。最終，有缺陷的交付將導(dǎo)致錯(cuò)失商業(yè)機(jī)會(huì)。
DevOps文化僅僅能夠在這樣的環(huán)境中長(zhǎng)存：每個(gè)人都擁抱DevOps理念。想要獲得成功的軟件開發(fā)和交付，它需要恰當(dāng)?shù)募夹g(shù)、現(xiàn)狀評(píng)估和態(tài)度。如果組織內(nèi)的每一個(gè)人都能站在同一個(gè)面上，并且理解無歧義的、一致性的溝通所帶來的力量，也能夠理解業(yè)務(wù)目標(biāo)，那么就沒有什么可以阻礙這個(gè)組織了。
當(dāng)然，擁有廣泛的技能集合是有益于這個(gè)過程的任何一個(gè)層面的，那些幸運(yùn)個(gè)體也會(huì)愿意成為在團(tuán)隊(duì)中發(fā)揮能量的成員。
DevOps需要統(tǒng)一的、具備多元能力的團(tuán)隊(duì)
正如前面所提到的，協(xié)作、溝通和集成是把DevOps納入任何開發(fā)和交付設(shè)置中的關(guān)鍵元素。構(gòu)建具備多元能力的團(tuán)隊(duì)能夠帶來巨大的收益，該團(tuán)隊(duì)由人才個(gè)體組成（例如開發(fā)人員、系統(tǒng)管理員和測(cè)試人員）。
但是，如果沒有恰當(dāng)?shù)膱F(tuán)隊(duì)合作和態(tài)度，每個(gè)人才個(gè)體都幾乎是沒有任何用處的。當(dāng)人們知道他可以信賴其他任何人時(shí)，這個(gè)組織作為一個(gè)整體可以更加快速和高效的做出響應(yīng)，這最終會(huì)讓客戶滿意度更高。
實(shí)踐DevOps方法的第一步包括，識(shí)別出軟件開發(fā)、IT運(yùn)維和QA是如何相互依賴的。正如前面所提到的，DevOps依賴于在軟件交付流水線上的關(guān)鍵人員之間的跨部門協(xié)作和開放溝通，這樣才能夠提升運(yùn)維效率、可預(yù)測(cè)性和可維護(hù)性。在該流程的早期集成和自動(dòng)化這些元素可以使團(tuán)隊(duì)以流式的方式進(jìn)行軟件交付。
DevOps是企業(yè)IT的未來
現(xiàn)代企業(yè)應(yīng)用充斥著復(fù)雜性，這些復(fù)雜性隨著使用各種不同的技術(shù)、多種數(shù)據(jù)庫和各式各樣的終端用戶設(shè)備而愈演愈烈。DevOps可能是成功應(yīng)對(duì)這些多樣環(huán)境的唯一可行的方法。
DevOps詞匯表
以下是前面所描述的整體原則中所涉及到的術(shù)語和工具，它們是成功的DevOps工程師所需要知道的：
云
IaaS
如果你在IT行業(yè)工作，你會(huì)聽說過公有云。如果你聽說過公有云，那么你會(huì)聽說過處于領(lǐng)先地位的云廠商，例如Amazon Web Services（AWS）、Microsoft Azure和Google Cloud Platform （GCP）。
他們是基礎(chǔ)設(shè)施即服務(wù)（Infrastructure as a Service，IaaS）廠商，他們通過基于互聯(lián)網(wǎng)的開放鏈路在虛擬化的環(huán)境中向用戶提供了計(jì)算資源。這些資源包括，存儲(chǔ)、帶寬、虛擬服務(wù)器、負(fù)載均衡器、網(wǎng)絡(luò)連接和IP地址。
廠商和工具的一些例子是：AWS、GCP、Azure、IBM SoftLayer、Digital Ocean
PaaS
平臺(tái)即服務(wù)（Platform as a Service，PaaS）使得開發(fā)人員可以在基于云的平臺(tái)上構(gòu)建應(yīng)用和服務(wù)。PaaS提供的服務(wù)可能需要很少或者完全不需要客戶方具有托管的專業(yè)知識(shí)，并且在簡(jiǎn)化的框架中包含了預(yù)配置的功能。
PaaS提供者例行的更新他們的服務(wù)，例如升級(jí)和新功能，并且在一開始就通過部署為開發(fā)者提供支持。PaaS服務(wù)的提供通常是以為每次使用付費(fèi)的訂閱方式進(jìn)行。
廠商和工具的一些例子是：Heroku、Google App Engine、AWS Elastic Beanstalk
SaaS
如果你熟悉Google和Facebook，那么你已經(jīng)被軟件即服務(wù)（Software as a Service，SaaS）所服務(wù)了。這些云上托管的軟件應(yīng)用擁有多種用途，有些是為個(gè)人的，有些是為組織的，例如即時(shí)消息、郵件、性能監(jiān)控、記賬和溝通，并且這些工具可以很方便的在線訪問到。
和購買傳統(tǒng)的軟件應(yīng)用（包含授權(quán)限制）不同，SaaS是基于訂閱的，應(yīng)用是在線使用的并且被托管在云上。
敏捷 vs 瀑布
瀑布是一套方法論，它把軟件開發(fā)和交付的各個(gè)階段分離開來，然后以線性方式執(zhí)行這些階段。因此，只有當(dāng)項(xiàng)目順利進(jìn)展到尾聲時(shí)，代碼才有可能被部署上去。而測(cè)試和質(zhì)量保證這2個(gè)重要階段，可能會(huì)因?yàn)榍懊嬉恍╇A段的延遲而被縮短，甚至被徹底的放棄。
如果在測(cè)試和質(zhì)量保證階段發(fā)現(xiàn)了問題，那么軟件必須要重新編碼或者會(huì)退回到開發(fā)過程更早期的階段。
敏捷也是一套方法論，它在審視業(yè)務(wù)和軟件開發(fā)項(xiàng)目時(shí)，使用的是非線性的方法。這樣做的結(jié)果，顯而易見的，就是更高的效率。
測(cè)試在早期階段就被頻繁的實(shí)施，這樣一來，開發(fā)人員就可以一邊構(gòu)建一邊修復(fù)錯(cuò)誤和進(jìn)行調(diào)整，因此它就為產(chǎn)品提供了更好的控制，同時(shí)減少了瀑布方法所帶來的大量風(fēng)險(xiǎn)。
集成和交付
持續(xù)集成
持續(xù)集成（Continuous Integration，CI）- 開發(fā)人員可以每天把代碼集成進(jìn)共享庫多次，對(duì)代碼的每個(gè)隔離的變更可以被迅速的測(cè)試以實(shí)現(xiàn)檢測(cè)和防止集成問題的目的。
廠商和工具的一些例子是：Jenkins、Teamcity、TravisCI、CircleCI
持續(xù)交付
持續(xù)交付（Continuous Delivery，CD）- 作為持續(xù)集成的擴(kuò)展，增量軟件交付的下一個(gè)步驟就是持續(xù)交付。它保證了在持續(xù)集成庫中被測(cè)試過的代碼的任何版本都可以在任何時(shí)候被發(fā)布。
廠商和工具的一些例子是：Jenkins、Teamcity、TravisCI、Electric Cloud、Go、Codeship、AWS、 CodeDeploy
持續(xù)部署
持續(xù)部署（Continuous Deployment）也可以被想象成持續(xù)集成的擴(kuò)展，它的目標(biāo)是讓新代碼被部署進(jìn)生產(chǎn)環(huán)境并且被在線用戶所使用到。這個(gè)功能是由持續(xù)集成所支持的，當(dāng)測(cè)試達(dá)到發(fā)布標(biāo)準(zhǔn)時(shí)，代碼被立即發(fā)布。
配置管理
簡(jiǎn)而言之，維護(hù)硬件和軟件最新的、細(xì)節(jié)的記錄-包括版本、需求、網(wǎng)絡(luò)地址、設(shè)計(jì)和運(yùn)維信息-就被稱為配置管理（Configuration Management，CM）。你可以使用配置管理工具來輔助這個(gè)過程，例如Chef、Puppet或者Ansible。你也可以使用Bash和Python來構(gòu)建你自己的配置管理自動(dòng)化。
廠商和工具的一些例子是：Chef、Puppet、Ansible、Saltstack、Vagrant、CFEngine
資源編排
當(dāng)考慮微服務(wù)、面向服務(wù)的架構(gòu)、融合式基礎(chǔ)設(shè)施、虛擬化和資源準(zhǔn)備時(shí)，計(jì)算系統(tǒng)之間的協(xié)作和集成就稱為編排。通過利用已定義的自動(dòng)化工作流，編排保證了業(yè)務(wù)需求是和你的基礎(chǔ)設(shè)施資源相匹配的。
容器
容器是輕量級(jí)的虛擬化組件，它以隔離的方式運(yùn)行應(yīng)用負(fù)載。它們運(yùn)行自己的進(jìn)程、文件系統(tǒng)和網(wǎng)絡(luò)棧，這些資源都是由運(yùn)行在硬件上的操作系統(tǒng)所虛擬化出來的。
廠商和相關(guān)工具的一些例子是：Docker、CoreOs、Kubernetes、Mesos、ElasticBox
源代碼（版本）控制
版本控制包括實(shí)踐和工具，它們幫助研究和開發(fā)型組織維護(hù)和控制源代碼庫中的變更。研究和開發(fā)成員也使用源代碼控制工具來文檔化和追蹤系統(tǒng)配置文件。
廠商和工具的一些例子是：GitHub、Bitbucket、JFrog、Artifactory
缺陷追蹤
缺陷跟蹤系統(tǒng)（Bug Tracker）是這樣一個(gè)系統(tǒng)，它匯集和報(bào)告軟件缺陷或者瑕疵。它幫助研究與開發(fā)型組織進(jìn)行任務(wù)管理，它也是一致性反饋環(huán)中的一個(gè)組成部分。一致性反饋環(huán)是DevOps方法中所要求的。
廠商和工具的一些例子是：BUGtrack、JIRA、GitHub
測(cè)試自動(dòng)化
通過支持持續(xù)的運(yùn)行多次測(cè)試，測(cè)試自動(dòng)化加速了測(cè)試工程師的工作。測(cè)試自動(dòng)化在支持高效的發(fā)布周期的同時(shí)，也加強(qiáng)了測(cè)試覆蓋。例如，測(cè)試自動(dòng)化工具有助于管理、執(zhí)行和測(cè)量功能測(cè)試和負(fù)載測(cè)試。
廠商和工具的一些例子是：Selenium、Cucumber、JUnit、TestNG、JMeter
單元測(cè)試
單元測(cè)試是這樣一個(gè)過程，它允許測(cè)試人員檢查一個(gè)應(yīng)用的某些小部分，例如特定代碼或者模塊。這個(gè)測(cè)試通常是自動(dòng)化的，并且可以被重用以支持持續(xù)測(cè)試和集成。
監(jiān)控
監(jiān)控是IT性能管理的主要元素，它也是運(yùn)維在線業(yè)務(wù)時(shí)最重要的方面之一。監(jiān)控工具是必須的，它提供了關(guān)鍵信息以幫助保證服務(wù)的健壯性（例如可用性、安全和性能）。
應(yīng)用性能監(jiān)控
當(dāng)你的應(yīng)用框架（包含應(yīng)用和數(shù)據(jù)庫層）中出現(xiàn)熱點(diǎn)時(shí)，應(yīng)用性能監(jiān)控（Application Performance Monitoring，APM）能夠讓你自動(dòng)檢測(cè)到這些情況，并且被報(bào)警。
廠商和工具的一些例子是：New Relic、AppDynamics、DataDog
基礎(chǔ)設(shè)施監(jiān)控
這個(gè)分類中的工具自動(dòng)化的對(duì)底層物理和虛擬資源的性能和可用性的降級(jí)進(jìn)行檢測(cè)和報(bào)警。
廠商和工具的一些例子是：AWS CloudWatch、Nagios、Zabbix、Sensu、Icinga
日志管理
日志管理（或者叫日志分析）是指處理由計(jì)算機(jī)生成的巨量消息的實(shí)踐。這些消息可能是運(yùn)維相關(guān)的消息（例如當(dāng)追蹤服務(wù)性能或者安全時(shí)）或者是為了商業(yè)智能的目的（例如，當(dāng)追蹤在線用戶行為時(shí)）。
廠商和工具：Logz.io（ELK）、Splunk、Sumo Logic
第三十六屆CIO班招生
國際CIO認(rèn)證培訓(xùn)
首席數(shù)據(jù)官（CDO）認(rèn)證培訓(xùn)
責(zé)編：content
免責(zé)聲明：本網(wǎng)站（http://www.www.gypb.net/）內(nèi)容主要來自原創(chuàng)、合作媒體供稿和第三方投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
本網(wǎng)站刊載的所有內(nèi)容（包括但不僅限文字、圖片、LOGO、音頻、視頻、軟件、程序等）版權(quán)歸原作者所有。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，請(qǐng)及時(shí)通知本站，予以刪除。
搶沙發(fā)
