【51CTO.com原創(chuàng)稿件】缺乏***實(shí)踐的 DevOps，會(huì)給你的企業(yè)帶來(lái)緩慢的發(fā)布周期，甚至是災(zāi)難性的錯(cuò)誤。本文向你介紹一些能夠充分使用 DevOps 的小技巧。

[[220177]]

本文會(huì)分享一些有趣的 DevOps 原則，并通過(guò)應(yīng)用展示它們給高效的項(xiàng)目交付與轉(zhuǎn)化所帶來(lái)的好處。

這里所提及的概念都源于 John Willis，他有著豐富的 IT 管理經(jīng)驗(yàn)，同時(shí)也是 DevOps 運(yùn)動(dòng)的最初倡導(dǎo)者。

當(dāng)一個(gè)組織考慮去實(shí)踐 DevOps 的時(shí)候，他們需要掌握一些相關(guān)術(shù)語(yǔ)和實(shí)用方法。

本文會(huì)談及如下幾個(gè)方面：

• 騎士資本的故事
• DevOps 的術(shù)語(yǔ)
• 價(jià)值流（value stream）/交付(lead) 時(shí)間/周期時(shí)間（CycleTime）
• 高績(jī)效組織與低績(jī)效組織
• 對(duì)精益模型的學(xué)習(xí)
• 持續(xù)交付模型
• DevOps 的實(shí)踐

騎士資本的故事

在開(kāi)始討論 DevOps 的***實(shí)踐之前，讓我們先來(lái)看看 IT 流程和技術(shù)的失敗是如何導(dǎo)致企業(yè)的各種業(yè)務(wù)問(wèn)題與損失的。

為了深入理解這一點(diǎn)，我們會(huì)引入一個(gè)發(fā)生在 2012 年的騎士資本的失敗案例。

[[220178]]

騎士資本集團(tuán)曾是一家美國(guó)本土的全球金融服務(wù)公司，它的業(yè)務(wù)涉及到開(kāi)拓市場(chǎng)、電子交易、機(jī)構(gòu)銷(xiāo)售和交易。

2012 年 8 月 1 日，騎士資本在系統(tǒng)的生產(chǎn)環(huán)境中部署了帶有倒退功能、且未經(jīng)測(cè)試的軟件。

該事故的發(fā)生是由于技術(shù)人員忘記將新的零售流動(dòng)性計(jì)劃（Retail Liquidity Program，RLP）代碼拷貝到八臺(tái) SMARS 服務(wù)器中的一臺(tái)之上，而這臺(tái)服務(wù)器正是騎士用于處理股權(quán)訂單的自動(dòng)路由系統(tǒng)之一。 

當(dāng)代碼被發(fā)布到生產(chǎn)環(huán)境中以后，導(dǎo)致了 154 只股票的 4 百萬(wàn)宗交易，在大約 45 分鐘內(nèi)有超過(guò) 3.97 億的換手，造成直接損失 4.4 億美元。

騎士資本的這一異常交易行為被定性地描述為“技術(shù)故障。”這充分地表明了：將帶有 Bug 的軟件部署到生產(chǎn)環(huán)境中所能夠造成的嚴(yán)重程度。

反觀此事，如果他們當(dāng)時(shí)遵循了 DevOps 的基本原則，該事故是完全可以避免的，而且無(wú)用功也會(huì)降低許多。

這里的無(wú)用功意味著他們完全可以使用自動(dòng)化的部署，來(lái)取代引發(fā)人為錯(cuò)誤的手動(dòng)部署。接下來(lái)我們看看 DevOps 的各種實(shí)踐。

DevOps 的術(shù)語(yǔ)

Chef 的創(chuàng)始人 Adam Jacob 將 DevOps 定義為一種文化和專(zhuān)業(yè)的運(yùn)動(dòng)。

通常，影響一個(gè)項(xiàng)目的三個(gè)因素分別是速度（時(shí)間）、可靠性和成本。開(kāi)發(fā)需要有按時(shí)交付的速度，而運(yùn)營(yíng)需要有可靠性。DevOps 可以保證以低成本的方式實(shí)現(xiàn)速度和可靠性。

DevOps 會(huì)涉及到各種模式，包括：持續(xù)改進(jìn)、組織文化、學(xué)習(xí)曲線、持續(xù)交付、持續(xù)學(xué)習(xí)、持續(xù)協(xié)作和自動(dòng)化。

與 DevOps 相關(guān)的術(shù)語(yǔ)有：

• 價(jià)值流，它指一個(gè)組織針對(duì)客戶(hù)的需求所執(zhí)行的各項(xiàng)交付活動(dòng)的順序。也就是指你如何把一個(gè)想法最終變現(xiàn)的過(guò)程。
• 交付時(shí)間，它指價(jià)值流從開(kāi)始到結(jié)束，全程轉(zhuǎn)化的耗時(shí)。一般情況下，交付時(shí)間是指呈現(xiàn)到客戶(hù)眼前所花費(fèi)的時(shí)間。
• 周期時(shí)間，它始于按照需求所開(kāi)展的工作，終于準(zhǔn)備好交付項(xiàng)目的時(shí)候。
• 交付時(shí)間的掌控能力，意味著我們對(duì) DevOps 的運(yùn)用水平。
• 部署交付時(shí)間，反映了我們?cè)谧詣?dòng)化方面的水平。

由此可見(jiàn)，組織應(yīng)遵循 DevOps 的模式和實(shí)踐方式，以減少交付的時(shí)間。他們完全可以從中選取諸如：放大反饋或加強(qiáng)持續(xù)學(xué)習(xí)文化等一個(gè)或多個(gè)適合自身的 DevOps 方法。

高績(jī)效組織與低績(jī)效的區(qū)別

在 2016 年的 DevOps 狀況報(bào)告中，有著關(guān)于如何區(qū)分出高績(jī)效與低績(jī)效的組織研究。

該研究指出：高績(jī)效的組織更接近于 DevOps 的文化，而低績(jī)效的組織則不太適合。

以下是從那些高績(jī)效組織中所觀察到的 DevOps 文化和實(shí)踐：

• 更高的員工參與程度。
• 內(nèi)部質(zhì)量方面的建設(shè)。
• 遵從精益產(chǎn)品的管理原則：注重客戶(hù)反饋意見(jiàn)的收集、傳播與實(shí)施；分解整體工作成各個(gè)小的部分，并使交付流程的工作流可視化。
• 在計(jì)劃外的工作和返工上花費(fèi)的時(shí)間最少。

總結(jié)起來(lái)，他們具有如下的實(shí)踐和文化：

• 更高的部署頻率
• 更短的變更交付時(shí)間
• 更短的平均恢復(fù)時(shí)間（Mean Time To Recover，MTTR）
• 更少的變更故障率

下面是有關(guān)此類(lèi)高績(jī)效組織的詳情：

• 范例：亞馬遜、谷歌、Facebook、Etsy 和 Netflix。
• 在 2015 年，谷歌已經(jīng)表示：他們每天會(huì)提交 5000 行代碼，75 萬(wàn)次用例測(cè)試；亞馬遜，每天會(huì)進(jìn)行 13.6 萬(wàn)行代碼的部署，平均每年 1500 萬(wàn)行；Netflix，每天部署 500 行代碼；Etsy 則每天數(shù)百行以上。
• 相對(duì)于低績(jī)效的組織來(lái)說(shuō)，他們的部署頻率多了 200 倍以上、交付時(shí)間快了 2555 倍、恢復(fù)時(shí)間快 24 倍，而故障率則只有三層以下。
• 他們往往有更多的合作、培訓(xùn)、風(fēng)險(xiǎn)信息分享、并且更鼓勵(lì)溝通，同時(shí)他們面對(duì)各種故障也有著健康的心態(tài)。

而對(duì)于低績(jī)效的組織來(lái)說(shuō)：

• 此類(lèi)組織只能努力實(shí)現(xiàn)一年兩次以上的部署，并只有一種瀑布式的部署模型。
• 他們的執(zhí)行力緩慢、且不太可靠。在合作方面，他們的水平較低，溝通并不順暢，對(duì)失敗常會(huì)產(chǎn)生消極和畏難情緒，且不愿意嘗試新鮮的事物。

對(duì)精益模型的學(xué)習(xí)

與精益模型有關(guān)的術(shù)語(yǔ)包括：無(wú)用功、資源流和壓力。

無(wú)用功：通過(guò)對(duì)精益模式的學(xué)習(xí)能夠消除無(wú)用功。這里的無(wú)用功是指對(duì)于實(shí)現(xiàn)交付時(shí)間毫無(wú)用處的、不必要的步驟。就 DevOps 而言，我們應(yīng)該多采用一些自動(dòng)化來(lái)完成工作。

資源流：資源流就是在開(kāi)發(fā)成品時(shí)所用到的資源的平衡。我們必須保持它們的一致性，而且堅(jiān)持全局優(yōu)化會(huì)優(yōu)于局部?jī)?yōu)化的理念。

壓力：在我們減少無(wú)用功和平衡資源流時(shí)，其實(shí)就是在給系統(tǒng)減少壓力。這是一種系統(tǒng)的思維：在我們觀察資源流的全局性能時(shí)，應(yīng)確保各路資源能盡快地流向最終的產(chǎn)品。

改善（Kaizen）：這是一個(gè)有關(guān)持續(xù)改進(jìn)的日語(yǔ)詞匯。我們以豐田生產(chǎn)系統(tǒng)為例，它能夠通過(guò)優(yōu)化資源流，來(lái)消除無(wú)用功，并通過(guò)持續(xù)改進(jìn)來(lái)減少對(duì)系統(tǒng)的壓力。

規(guī)程（Kata）：通過(guò)對(duì)規(guī)程的執(zhí)行，公司里的各個(gè)角色員工能夠以系統(tǒng)性的方法開(kāi)展工作。而且通過(guò)可重復(fù)的方式，學(xué)習(xí)者可以用非常自然的、自發(fā)的方式，來(lái)提高技術(shù)和執(zhí)行能力。

DevOps 中的精益模型影響，旨在消除任何可能出現(xiàn)的無(wú)用功，從而實(shí)現(xiàn)對(duì)資源流的優(yōu)化與平衡。

此外，通過(guò)減少壓力，以確保各路資源能夠盡快地流向最終的產(chǎn)品。因此我們需要持續(xù)改進(jìn)，并且通過(guò)遵循規(guī)程，以自然、自發(fā)的方式，來(lái)提高技術(shù)和執(zhí)行能力。

持續(xù)交付模型

DevOps 的一個(gè)重要部分就是持續(xù)交付模型，也被稱(chēng)為 CI/CD - 持續(xù)集成/持續(xù)交付。

它們的基本原則就是要內(nèi)置到質(zhì)量保障之中，這可用通過(guò)在軟件上建立全方位的測(cè)試來(lái)實(shí)現(xiàn)。

高績(jī)效的組織一般會(huì)做非常嚴(yán)謹(jǐn)?shù)臏y(cè)試，他們會(huì)認(rèn)真地對(duì)待各種流程中的功能性代碼、集成測(cè)試、冒煙測(cè)試（smoke test），并且貫穿到他們最終的軟件交付階段。

DevOps 的實(shí)踐

從較高層次上說(shuō)，有三種方法可用來(lái)實(shí)現(xiàn) DevOps，你可以從中挑選出一到兩個(gè)最適合本企業(yè)的方法進(jìn)行嘗試：

• 縮短交付周期
• 放大反饋
• 持續(xù)學(xué)習(xí)

***種是從左（始）到右（終）的方式。為了能夠在較高的層次上實(shí)現(xiàn)對(duì)交付周期的縮短，我們需要有一個(gè)面向客戶(hù)與交付的、整體交付時(shí)間的規(guī)劃。

該方法的實(shí)現(xiàn)方式有：

• 使工作可見(jiàn)化，如使用看板（譯者注：Kanban board 是在看板系統(tǒng)中用塑料或紙制成薄板，將產(chǎn)品名稱(chēng)及數(shù)量寫(xiě)于其上，故此得名）。
• 切分成小批量的處理工作。
• 自動(dòng)化可重復(fù)的任務(wù)。
• 運(yùn)用精益軟件的原則，消除無(wú)用功，減少各種瓶頸。
• 設(shè)置對(duì)正在進(jìn)行中的工作的各種約束。

第二種是從右（終）到左（始）的方式，或稱(chēng)為放大反饋。我們使用多種工具來(lái)進(jìn)行監(jiān)控。

一般情況下，通過(guò)賦能各種獲取反饋的能力，我們就能夠在流程中更早地發(fā)現(xiàn)各種缺陷、或是無(wú)用功。

該方法的實(shí)現(xiàn)方式有：

• 遙測(cè)法。
• 故障注入。
• 同等評(píng)審，所有的變更都被同等地進(jìn)行評(píng)審。
• 監(jiān)控各種提交日志。

相對(duì)于***種的從左（始）到右（終）、和第二種的從右（終）到左（始）來(lái)說(shuō)，第三種方法是一個(gè)閉環(huán)。我們通過(guò)使用上述提到的改善和規(guī)程來(lái)進(jìn)行持續(xù)的學(xué)習(xí)。

各個(gè)組織對(duì)它的具體實(shí)現(xiàn)方式有：

• 持續(xù)學(xué)習(xí)。
• 溝通反饋。
• 以目標(biāo)為導(dǎo)向的反饋。
• 學(xué)習(xí)的目標(biāo)應(yīng)可信、且能不斷改進(jìn)。
• 反饋不應(yīng)針對(duì)個(gè)人，應(yīng)當(dāng)針對(duì)的是交付過(guò)程中的行為，且必須是可行的。
• 反饋方法，在低信任度的環(huán)境中使用海豚式反饋，在中信任度的環(huán)境中使用三明治式反饋，以及在高信任度的環(huán)境中使用基層人員式反饋。
• 無(wú)抱怨式的企業(yè)文化。

結(jié)論

從騎士資本的故事中，我們已經(jīng)能夠看到：嚴(yán)重的軟件問(wèn)題能夠引起多么大的災(zāi)難。

根據(jù) DevOps 的狀況報(bào)告，DevOps 的文化和實(shí)踐不但能夠讓企業(yè)受益，還能夠讓他們?cè)诔杀竟?jié)省和價(jià)值上提高投資回報(bào)率：

• 成本節(jié)省，包括宕機(jī)的成本和過(guò)剩的重復(fù)勞動(dòng)上的成本。
• 價(jià)值，包括從更快速的發(fā)布中，所收獲的潛在收入與更多的客戶(hù)。

我們希望通過(guò)本文的分析和引導(dǎo)，你的組織可以更好地領(lǐng)悟 DevOps 的實(shí)施潛力，并能創(chuàng)造出更多的價(jià)值。

[[220179]]

陳峻（Julian Chen） ，有著十多年的 IT 項(xiàng)目、企業(yè)運(yùn)維和風(fēng)險(xiǎn)管控的從業(yè)經(jīng)驗(yàn)，日常工作深入系統(tǒng)安全各個(gè)環(huán)節(jié)。作為 CISSP 證書(shū)持有者，他在各專(zhuān)業(yè)雜志上發(fā)表了《IT運(yùn)維的“六脈神劍”》、《律師事務(wù)所IT服務(wù)管理》 和《股票交易網(wǎng)絡(luò)系統(tǒng)中的安全設(shè)計(jì)》等論文。他還持續(xù)分享并更新《廉環(huán)話》系列博文和各種外文技術(shù)翻譯，曾被(ISC)2 評(píng)為第九屆亞太區(qū)信息安全***成就表彰計(jì)劃的“信息安全踐行者”和 Future-S 中國(guó) IT 治理和管理的 2015 年度踐行人物。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】