DevOps 是一個席卷 IT 界的新術(shù)語。但它究竟是什么，南非的公司們?nèi)绾卫盟鼇砑涌旄咂焚|(zhì)應(yīng)用程序的開發(fā)速度？國外知名博客作者凱西·吉布森找到了一些答案。

其實 DevOps 這個詞已經(jīng)火了一段時間了，我們知道它是很多新時代數(shù)字化企業(yè)的成功秘訣。但是，在南非公司收獲由 DevOps 帶來的全部好處之前，重要的是理解它的涵義，以及如何最大限度地利用它的優(yōu)勢。

維基百科對 DevOps 的定義為：「一種強(qiáng)調(diào)軟件開發(fā)人員和其他IT專業(yè)人士之間溝通，協(xié)作（信息共享和對 Web 服務(wù)的使用），集成化，自動化和合作測量的軟件開發(fā)方法?！埂冈摲椒ㄕJ(rèn)可軟件開發(fā)，質(zhì)量保證（QA）和 IT 運(yùn)營之間的相互依存關(guān)系，旨在幫助企業(yè)快速生產(chǎn)軟件產(chǎn)品和服務(wù)，改善經(jīng)營業(yè)績?！惯@聽起來很像敏捷之類的現(xiàn)有開發(fā)方法，但根本的不同之處在于： DevOps 積極推進(jìn)一系列流程和方法，致力于開發(fā)、質(zhì)量保證和 IT 運(yùn)營之間的跨部門溝通與協(xié)作。

DevOps 的一個主要目標(biāo)是快速應(yīng)用部署，從而縮短產(chǎn)品上市時間，降低新版本的故障率，縮短崩潰事件的修復(fù)時間和平均恢復(fù)時間。DevOps 的目標(biāo)是通過自動化方式方法，最大限度地提高運(yùn)營流程的可預(yù)測性，效率，安全性和可維護(hù)性。Chef 的 EMEA 副總裁兼首席企業(yè)架構(gòu)師的賈斯汀·阿巴克爾，解釋說，DevOps是與業(yè)務(wù)的整體轉(zhuǎn)型密切相關(guān)的。

「通過思考企業(yè)運(yùn)作的方式，我們才知道要完成什么任務(wù)，」他說。 「事實證明，DevOps 的核心原則是讓公司全員了解新的變化和戰(zhàn)略?！棺孖T人員了解到，如何看待業(yè)務(wù)的變革正在進(jìn)行大有裨益。 「實際上，這不只是關(guān)于 DevOps，或西海岸的想法或基于 Web 的企業(yè)，」阿巴克爾說。 「所有的業(yè)務(wù)正在開始改變?！埂傅?dāng)你從大網(wǎng)站跳槽到大企業(yè)時，會有某個核心因素使人們不希望發(fā)生改變。或者，他們忙于應(yīng)對為期八周的項目然后永遠(yuǎn)不再改進(jìn)。」「但你可以做到這一點(diǎn)，并且你必須這樣做。除非你的運(yùn)營模式使用 DevOps 方法，否則，你將使公司變得不穩(wěn)定。如果你認(rèn)為公司現(xiàn)在中規(guī)中矩且安全可靠，這是一種錯覺。」阿巴克爾說，在已經(jīng)轉(zhuǎn)變的企業(yè)中，新產(chǎn)品能根據(jù)一系列需求快速迭代?！杆麄儾辉噲D預(yù)測未知的未來?？焖俚哪芰椭档惋L(fēng)險。你們應(yīng)該有能力進(jìn)行最佳預(yù)測，創(chuàng)造一個最小可行產(chǎn)品，并以此為基礎(chǔ)快速迭代?！?/p>

速度是來自大型 Web 的新的必備條件，阿巴克爾補(bǔ)充道。 「如果你想在更高的速度下操作，就會犯錯誤。但動作更快意味著更快地修復(fù)，比起貫穿整個公司的操作流程你更需要這種能力?！缸屗俣茸瞿愕南?qū)??！惯@一切都增加了公司的可靠性，使其越發(fā)牢固，阿巴克爾解釋到。并且，速度是必要的：「如果你不能快速響應(yīng)，那就等于自說自話?！?/p>

在南非，一組 IT 開發(fā)者和學(xué)者成立了一個 DevOps 工作組，致力于探索 DevOps 的規(guī)則，并促進(jìn)其在當(dāng)?shù)丨h(huán)境中的使用。

亞當(dāng)·雅各布，Chef 首席技術(shù)官，在該工作組的成立大會上講話，談到 DevOps 是怎樣出現(xiàn)的，并提供了一些使它奏效的忠告?！窪evOps 是由從事相關(guān)工作的人建立的，對每一個人來說都是不同的，”他說。 「它來自一段歷時15 年的深網(wǎng)運(yùn)作經(jīng)歷，這段經(jīng)歷最終演變?yōu)橐环N工作方式?！顾忉屨f，負(fù)責(zé)運(yùn)營大型網(wǎng)站的人逐漸認(rèn)識到了他們之前學(xué)到的 IT 學(xué)科知識在新的環(huán)境中一無所用?！埂鸽S著時間的推移，我們意識到，必須建立更強(qiáng)的信任關(guān)系，提高自動化程度、更加自力更生。當(dāng)你遇到問題時，廠商都很樂意賣給你解決方案 —— 對于你的問題，他們總會有答案。但他們并不真正了解你的問題，所以你真得靠自己?！笽T 公司面臨的挑戰(zhàn)如此難以界定，提出 DevOps 的定義或方法幾乎是不可能的，雅各布補(bǔ)充道?！鸽m然有一些共同的主題和行為，但不同的定義卻不計其數(shù)，」他說。 「DevOps 不是作為一個理論概念存在，而是作為一種生活體驗而存在?！?/p>

但是,通常，在成功運(yùn)用 DevOps的人眼中，的確存在一些共同的宏觀趨勢。

Chef 提出 DevOps 有點(diǎn)像功夫或者說武術(shù)?！副M管有數(shù)百種不同的武術(shù)流派，但他們都可以被認(rèn)定為武術(shù)，」他解釋說。 「顯然，他們并不都是一樣的，它們共享三個基本理念。」
這三個共同的基本要素是基礎(chǔ)，形式和應(yīng)用?！高@三樣?xùn)|西是共享的。教基礎(chǔ)的方法是相同的，形式也是相同的，而且在現(xiàn)實中應(yīng)用它們的方法也是相似的，但因不同個體而異。這就是你所知道的練武術(shù)的方式?！?/p>

「你可以用同樣的方式來類比 DevOps?！寡鸥鞑冀忉尩?，DevOps 更多是關(guān)于重新打造經(jīng)營業(yè)務(wù)的方式，而不是軟件開發(fā)的流程?！覆还苣阆膊幌矚g這是我們現(xiàn)在正在做的——事實上我們都在實踐 DevOps。現(xiàn)在需要的是集齊所有的專家并讓他們相互協(xié)作，使人們組成團(tuán)隊，完成他們無法獨(dú)自完成的事。」

根本上來說，DevOps 是一種專注于如何建立和運(yùn)營高效率公司的文化和行業(yè)運(yùn)動，誕生自從業(yè)者的經(jīng)驗，雅各布說。他提醒道，同樣的規(guī)則用于低效率的公司將導(dǎo)致不穩(wěn)定。「值得記住的是，該運(yùn)動來自網(wǎng)絡(luò)的創(chuàng)新者們。當(dāng)你將它應(yīng)用到自己的環(huán)境中時，需要從中獲取對你有效的部分。DevOps的從業(yè)者都相信——并且踐行——一系列準(zhǔn)則，雅各布補(bǔ)充說，不采用這些準(zhǔn)則的人就沒有擁抱 DevOps」

這些規(guī)則如下，他說：

• 以安全，滿意，知識和自由為設(shè)計目標(biāo)。
• 做 DevOps 服務(wù)于人和公司的所有產(chǎn)品?！高@始終是一個事實，人們喜歡做這樣的工作，因為這是一個建立更好的產(chǎn)品的好機(jī)會?？鞓返娜藙?chuàng)造快樂的的產(chǎn)品就等于快樂的企業(yè)…」
• DevOps 的人精干?！杆麄兿窃鲋档男袆? 幫助推動; 旨在持續(xù)改進(jìn)，顛覆性的變化，批量和試驗?！?/li>
• DevOps 的人會和失敗建立關(guān)系?！高@是正常的現(xiàn)狀，不是一個要避免的事情; 會感到恐慌意味著你沒有試圖解決這個問題?！?/li>
• 無處不在的工作流程自動化?！敢坏┪覀兿胍ぷ?，應(yīng)該建立工作流程并默認(rèn)其自動化?！?/li>
• 多元化?！窪evOps 是多元的，一個高機(jī)能的團(tuán)隊也必須是多元的——越是如此越能做到更好; 需要多種多樣的技能。」

DevOps的形式——關(guān)注人們實際做了什么——要求團(tuán)隊專注于一個比手頭任務(wù)更大的目標(biāo)，雅各布說。 「因此一個工作也許不在于修好網(wǎng)站，而是在于改變這個國家?！笵evOps 的形式是這樣的，他解釋說：

• 相信?！改阆嘈攀裁礀|西會在你的領(lǐng)域創(chuàng)造良好的成果？使用主動語態(tài)來講，以好的結(jié)果為目的，公開包括 DevOps 規(guī)則在內(nèi)的理念，并將其融入對你的行業(yè)或遇到的問題有特殊意義的事情中。」
• 建立一個高度授權(quán)的團(tuán)隊?！杆麄儽仨氂袡?quán)限采取行動，在適宜的情況下做出正確的決定;與關(guān)心組織的宗旨并能夠分享利益的領(lǐng)袖為伍?！?/li>
• 形式多樣的關(guān)系?！刚J(rèn)識專業(yè)領(lǐng)域以外的人;了解他們做什么，了解他們遇到的的問題和擁有的觀點(diǎn)。他們可以是來自法律，財務(wù)或銷售領(lǐng)域。」
• 借此在重要決定上達(dá)成共識?！秆h(huán)性的計劃，包含批評和反饋。這將有助于解決問題?！?/li>
• 有較強(qiáng)的價值主張。「人們是買止痛藥而不是維生素，重點(diǎn)要放在人們需要而非想要的事情上。能區(qū)分是一個客戶想要一個功能還是許多客戶需要一個功能?！?/li>
• 建立一個路線圖?！赴ㄔ妇昂头答?。平衡創(chuàng)新與需求，將它們組合成主題，提煉那些為功能，并向客戶確認(rèn)他們。需要堅持這個主題，結(jié)果也許會保持原樣，但功能將會發(fā)生變化?！?/li>
• 總要有興奮因素。「包括那些用戶用了并感到愉快的功能。」
• 建立功能迭代?！覆皇窃噲D逐漸描繪出蒙娜麗莎，因為在開始之前你就得知道它是什么樣。而是從一個草圖開始，加點(diǎn)顏色，然后完成它。」
• 管理風(fēng)險?！竿ㄟ^階段性假設(shè)進(jìn)行小批量工作。請記住，必須且只能通過客戶進(jìn)行效果驗證。引入短期收益減少長期風(fēng)險——這讓短期路線圖不夠清楚，但減少了一些在長期的風(fēng)險?！?/li>
• 不要擔(dān)心規(guī)模?！阜潜匾臅r候不必?fù)?dān)心它——而且這通常會比你想的更晚。」
• 執(zhí)行?！溉藗儠氤鲂碌睦碚摚阈枰ㄟ^執(zhí)行挑戰(zhàn)它們。執(zhí)行總是勝過理論?！?/li>
• 證明每星期持續(xù)進(jìn)行?！覆⑶已埓蠹医o出反饋?！?/li>
• 選擇適合這份工作的語言和工具?！拔覀兌际峭〞远嚅T語言的人; 新的語言和工具是這個行業(yè)的巨大優(yōu)勢之一。迭代開發(fā)和小批量生產(chǎn)會有利于規(guī)避風(fēng)險?！?/li>
• 有一個 bug 數(shù)據(jù)庫?！附o錯誤分類和排優(yōu)先級?！?/li>
• 持續(xù)集成。「永遠(yuǎn)在短期迭代分支中合并分支到 master。測試是好的，但持續(xù)集成更好，當(dāng)它出現(xiàn)問題可以及時進(jìn)行修復(fù)。”
• 遵守四眼原則。除非至少有兩個人都發(fā)現(xiàn)了問題，不要改變什么。必須有另外的人時時檢查你的工作。
• 編寫測試?！傅淮沃粚懸粋€測試，這很有必要?！?/li>
• 持續(xù)交付。「你應(yīng)該摒棄只要你想就能做到的想法?！?/li>
• 一個變化的路徑?！冈诮M織中發(fā)生變化的方式固定的。如果有一個一致的模式會使加強(qiáng)規(guī)則和輔助流程變得簡單。它可以幫助人們互相幫助，這在執(zhí)行的層面是靈活的?！?/li>
• 代碼經(jīng)過相同的工作流，不用考慮它是用于應(yīng)用程序或基礎(chǔ)結(jié)構(gòu)。
• 專注于可用性?！高@其中包括正常運(yùn)行時間，縮短平均診斷時間和平均修復(fù)時間。失敗是不可避免的，不同的是你如何面對它?！?/li>
• 收集 metrics?！缚梢詮牟僮飨到y(tǒng)，網(wǎng)絡(luò)，應(yīng)用程序或進(jìn)程收集。
• 能力計劃?！改惚緫?yīng)在那但可能并沒有。確定關(guān)鍵 metrics，把它們放在一個圖中，設(shè)定一個上限，繪制趨勢線; 并且在需要的時候擴(kuò)展時間跨度。”
• 只對可行動的人告警。「讓正確的人去關(guān)注問題——但數(shù)量越少越好; 只通知可以采取行動解決問題的人?！?/li>
• 練習(xí)事件響應(yīng)?！高@可能最重要的步驟。第一個響應(yīng)者是事件指揮者，他們決定做什么，統(tǒng)籌資源和通信狀態(tài)。這不是排等級，但只能有一個事件指揮者?！?/li>
• 事件剖析?！笇W(xué)習(xí)不責(zé)難的去描述的事件，建立時間表，確定影響因素，描述對客戶的影響，描述整治任務(wù)，并說明任務(wù)可以如何改善響應(yīng)流程?！?/li>
• 使用可擴(kuò)展系統(tǒng)設(shè)計?！缸园l(fā)因素為自己負(fù)責(zé)，實現(xiàn)目標(biāo)的過程中要有對其他能對其進(jìn)行評估質(zhì)量的因素的明確保證。」
• 為簡易性，可擴(kuò)展性和再利用而設(shè)計。

一旦被談?wù)撈饋恚P(guān)于 DevOps 聲音往往是復(fù)雜的，有時甚至是矛盾的，但是雅各布說，堅持技術(shù)是安全的。 “記住一個原則，用您的識別能力實踐這種形式，”他建議道。

「在現(xiàn)實世界中，DevOps 是在描述一個涉及整個組織中的利益相關(guān)因素，并連續(xù)八周進(jìn)行嘗試的問題。你能夠負(fù)擔(dān)得起投資這八個星期?！?/p>

為了驗證這個規(guī)則，雅各布建議企業(yè)選擇一個足夠小的垂直問題，就在這八個星期進(jìn)行一次有意義的迭代?！冈诘诙A段，設(shè)置了你的目的，信念和團(tuán)隊。寫下的目的和信念，授權(quán)團(tuán)隊，并做好準(zhǔn)備。下一步驟是做產(chǎn)品開發(fā)。 寫下的價值主張；建立關(guān)于主題，成果和特點(diǎn)的路線圖；包括一些興奮因素，并確保功能簡單，擁有可擴(kuò)展和再利用的特性。」

接下來就是功能迭代。 「通過小批量風(fēng)險管理，選擇語言并進(jìn)行工作，同時忽略規(guī)模，」雅各布說。 「提出理論時，把重點(diǎn)放在執(zhí)行性上。每周向整個公司展示進(jìn)度。使用源代碼控制。有一個 bug 數(shù)據(jù)庫。使用一個變化事件流。讓其他人監(jiān)視一切。記得做持續(xù)集成并且每次都測試。使用可擴(kuò)展的系統(tǒng)設(shè)計。操作時，專注于可用性，收集 Metrics，規(guī)劃能力，對可行動的事件進(jìn)行告警，堅持事件響應(yīng)和事件剖析。」交付時需要堅持最終演示并保持可追溯。

「對 DevOps 而言最重要的是，找到屬于自己的方法，」雅各布說。

原文作者 Kathy Gibson，本文由 OneAPM 工程師編譯整理。

Cloud Insight 集監(jiān)控、管理、計算、協(xié)作、可視化于一身，幫助所有 IT 公司，減少在系統(tǒng)監(jiān)控上的人力和時間成本投入，讓運(yùn)維工作更加高效、簡單。本文由 OneAPM 工程師翻譯整理，想閱讀更多技術(shù)文章，請訪問 OneAPM 官方技術(shù)博客。

本文轉(zhuǎn)自 OneAPM 官方博客