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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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