為何DevOps是如今重要的技術(shù)策略
消除一些關(guān)于 DevOps 的疑惑。
很多人初學(xué) DevOps 時(shí)，看到它其中一個(gè)結(jié)果就問(wèn)這個(gè)是如何得來(lái)的。其實(shí)理解這部分 Devops 的怎樣實(shí)現(xiàn)并不重要，重要的是——理解（使用） DevOps 策略的原因——這是做一個(gè)行業(yè)領(lǐng)跑者還是追隨者的差別。
你可能會(huì)聽(tīng)過(guò)些 Devops 的難以置信的成果，例如生產(chǎn)環(huán)境非常有彈性，就算是有個(gè)“癲狂的猴子）跳來(lái)跳去將不知道哪個(gè)插頭隨便拔下，每天仍可以處理數(shù)千個(gè)發(fā)布。這是令人印象深刻的，但就其本身而言，這是一個(gè) DevOps 的證據(jù)不足的案例，其本質(zhì)上會(huì)被一個(gè)反例困擾：DevOps 環(huán)境有彈性是因?yàn)閲?yán)重的故障還沒(méi)有被觀測(cè)到。
有很多關(guān)于 DevOps 的疑惑，并且許多人還在嘗試弄清楚它的意義。下面是來(lái)自我 LinkedIn Feed 中的某個(gè)人的一個(gè)案例：
最近我參加一些 #DevOps 的交流會(huì)，那里一些演講人好像在倡導(dǎo) #敏捷開(kāi)發(fā)是 DevOps 的子集。不知為何，我的理解恰恰相反。
能聽(tīng)一下你們的想法嗎？你認(rèn)為敏捷開(kāi)發(fā)和 DevOps 之間是什么關(guān)系呢？
- DevOps 是敏捷開(kāi)發(fā)的子集
- 敏捷開(kāi)發(fā)是 DevOps 的子集
- DevOps 是敏捷開(kāi)發(fā)的擴(kuò)展，從敏捷開(kāi)發(fā)結(jié)束的地方開(kāi)始
- DevOps 是敏捷開(kāi)發(fā)的新版本
科技行業(yè)人員在那篇 LinkedIn 的帖子上表達(dá)了各種各樣的答案，你會(huì)怎樣回復(fù)呢？
DevOps 源于精益和敏捷
如果我們從亨利福特的戰(zhàn)略和豐田生產(chǎn)系統(tǒng)對(duì)福特車型的改進(jìn)（的歷史）開(kāi)始， DevOps 就更有意義了。精益制造就誕生在那段歷史中，人們對(duì)精益制作進(jìn)行了良好的研究。James P. Womack 和 Daniel T. Jones 將精益思維（Lean Thinking）提煉為五個(gè)原則：
- 指明客戶所需的價(jià)值
- 確定提供該價(jià)值的每個(gè)產(chǎn)品的價(jià)值流，并對(duì)當(dāng)前提供該價(jià)值所需的所有浪費(fèi)步驟提起挑戰(zhàn)
- 使產(chǎn)品通過(guò)剩余的增值步驟持續(xù)流動(dòng)
- 在可以連續(xù)流動(dòng)的所有步驟之間引入拉力
- 管理要盡善盡美，以便為客戶服務(wù)所需的步驟數(shù)量和時(shí)間以及信息量持續(xù)下降
精益致力于持續(xù)消除浪費(fèi)并增加客戶的價(jià)值流動(dòng)。這很容易識(shí)別并明白精益的核心原則，可以做一些游戲去了解為何同一時(shí)間移動(dòng)單個(gè)比批量移動(dòng)要快得多。其中的兩個(gè)游戲是硬幣游戲和飛機(jī)游戲。在硬幣游戲中，如果一批 20 個(gè)硬幣到顧客手中要用 2 分鐘，顧客等 2 分鐘后能拿到整批硬幣。如果一次只移動(dòng)一個(gè)硬幣，顧客會(huì)在 5 秒內(nèi)得到一枚硬幣，并會(huì)持續(xù)獲得硬幣，直到在大約 25 秒后第 20 個(gè)硬幣到達(dá)。（LCTT 譯注：有相關(guān)的視頻的）
這是巨大的不同，但是不是生活中的所有事都像硬幣游戲那樣簡(jiǎn)單并可預(yù)測(cè)的。這就是敏捷的出現(xiàn)的原因。我們當(dāng)然看到了高效績(jī)敏捷團(tuán)隊(duì)的精益原則，但這些團(tuán)隊(duì)需要的不僅僅是精益去做他們要做的事。
為了能夠處理典型的軟件開(kāi)發(fā)任務(wù)的不可預(yù)見(jiàn)性和變化，敏捷開(kāi)發(fā)的方法論會(huì)將重點(diǎn)放在意識(shí)、審議、決策和行動(dòng)上，以便在不斷變化的現(xiàn)實(shí)中調(diào)整。例如，敏捷框架（如 srcum）通過(guò)每日站立會(huì)議和沖刺評(píng)審會(huì)議等儀式提高意識(shí)。如果 scrum 團(tuán)隊(duì)意識(shí)到新的事實(shí)，框架允許并鼓勵(lì)他們?cè)诒匾獣r(shí)及時(shí)調(diào)整路線。
要使團(tuán)隊(duì)做出這些類型的決策，他們需要高度信任的環(huán)境中的自我組織能力。以這種方式工作的高效績(jī)敏捷團(tuán)隊(duì)在不斷調(diào)整的同時(shí)實(shí)現(xiàn)快速的價(jià)值流，消除錯(cuò)誤方向上的浪費(fèi)。
批量大小
要了解 DevOps 在軟件開(kāi)發(fā)中的強(qiáng)大功能，這會(huì)幫助我們理解批處理大小的經(jīng)濟(jì)學(xué)。請(qǐng)考慮以下來(lái)自Donald Reinertsen 的產(chǎn)品開(kāi)發(fā)流程原則的U曲線優(yōu)化示例：
U-curve optimization illustration of optimal batch size
這可以類比雜貨店購(gòu)物來(lái)解釋。假設(shè)你需要買一些雞蛋，而你住的地方離商店只有 30 分鐘的路程。買一個(gè)雞蛋（圖中最左邊）意味著每次要花 30 分鐘的路程，這就是你的交易成本。持有成本可能是雞蛋變質(zhì)和在你的冰箱中持續(xù)地占用空間。總成本是交易成本加上你的持有成本。這個(gè) U 型曲線解釋了為什么對(duì)大部分人來(lái)說(shuō)，一次買一打雞蛋是他們的批量大小。如果你就住在商店的旁邊，步行到那里不會(huì)花費(fèi)你任何的時(shí)候，你可能每次只會(huì)買一小盒雞蛋，以此來(lái)節(jié)省冰箱的空間并享受新鮮的雞蛋。
這 U 型優(yōu)化曲線可以說(shuō)明為什么在成功的敏捷轉(zhuǎn)換中生產(chǎn)力會(huì)顯著提高?？紤]敏捷轉(zhuǎn)換對(duì)組織決策的影響。在傳統(tǒng)的分級(jí)組織中，決策權(quán)是集中的。這會(huì)導(dǎo)致較少的人做更大的決策。敏捷方法論會(huì)有效地降低組織決策中的交易成本，方法是將決策分散到最被人熟知的認(rèn)識(shí)和信息的位置：跨越高度信任，自組織的敏捷團(tuán)隊(duì)。
下面的動(dòng)畫演示了降低事務(wù)成本后，批量大小是如何向左移動(dòng)。在更頻繁地做出更快的決策方面，你不能低估組織的價(jià)值。
U-curve optimization illustration
DevOps 適合哪些地方
自動(dòng)化是 DevOps 最知名的事情之一。前面的插圖非常詳細(xì)地展示了自動(dòng)化的價(jià)值。通過(guò)自動(dòng)化，我們將交易成本降低到接近于零，實(shí)質(zhì)上是可以免費(fèi)進(jìn)行測(cè)試和部署。這使我們可以利用越來(lái)越小的批量工作。較小批量的工作更容易理解、提交、測(cè)試、審查和知道何時(shí)能完成。這些較小的批量大小也包含較少的差異和風(fēng)險(xiǎn)，使其更易于部署，如果出現(xiàn)問(wèn)題，可以進(jìn)行故障排除和恢復(fù)。通過(guò)自動(dòng)化與扎實(shí)的敏捷實(shí)踐相結(jié)合，我們可以使我們的功能開(kāi)發(fā)非常接近單件流程，從而快速、持續(xù)地為客戶提供價(jià)值。
更傳統(tǒng)地說(shuō)，DevOps 被理解為一種打破開(kāi)發(fā)團(tuán)隊(duì)和運(yùn)營(yíng)團(tuán)隊(duì)之間混亂局面的方法。在這個(gè)模型中，開(kāi)發(fā)團(tuán)隊(duì)開(kāi)發(fā)新的功能，而運(yùn)營(yíng)團(tuán)隊(duì)則保持系統(tǒng)的穩(wěn)定和平穩(wěn)運(yùn)行。摩擦的發(fā)生是因?yàn)殚_(kāi)發(fā)過(guò)程中的新功能將更改引入到系統(tǒng)中，從而增加了停機(jī)的風(fēng)險(xiǎn)，運(yùn)營(yíng)團(tuán)隊(duì)并不認(rèn)為要對(duì)此負(fù)責(zé)，但無(wú)論如何都必須處理這一問(wèn)題。DevOps 不僅僅嘗試讓人們一起工作，更重要的是嘗試在復(fù)雜的環(huán)境中安全地進(jìn)行更頻繁的更改。
我們可以看看 Ron Westrum 在有關(guān)復(fù)雜組織中實(shí)現(xiàn)安全性的研究。在研究為什么有些組織比其他組織更安全時(shí)，他發(fā)現(xiàn)組織的文化可以預(yù)測(cè)其安全性。他確定了三種文化：病態(tài)的、官僚主義的和生產(chǎn)式的。他發(fā)現(xiàn)病態(tài)的可以預(yù)測(cè)其安全性較低，而生產(chǎn)式文化被預(yù)測(cè)為更安全（例如，在他的主要研究領(lǐng)域中，飛機(jī)墜毀或意外住院死亡的數(shù)量要少得多）。
Three types of culture identified by Ron Westrum
高效的 DevOps 團(tuán)隊(duì)通過(guò)精益和敏捷的實(shí)踐實(shí)現(xiàn)了一種生成性文化，這表明速度和安全性是互補(bǔ)的，或者說(shuō)是同一個(gè)問(wèn)題的兩個(gè)方面。通過(guò)將決策和功能的批量大小減少到非常小，DevOps 實(shí)現(xiàn)了更快的信息流和價(jià)值，同時(shí)消除了浪費(fèi)并降低了風(fēng)險(xiǎn)。
與 Westrum 的研究一致，在提高安全性和可靠性的同時(shí)，變化也很容易發(fā)生。當(dāng)一個(gè)敏捷的 DevOps 團(tuán)隊(duì)被信任做出自己的決定時(shí)，我們將獲得 DevOps 目前最為人所知的工具和技術(shù)：自動(dòng)化和持續(xù)交付。通過(guò)這種自動(dòng)化，交易成本比以往任何時(shí)候都進(jìn)一步降低，并且實(shí)現(xiàn)了近乎單一的精益流程，每天創(chuàng)造數(shù)千個(gè)決策和發(fā)布的潛力，正如我們?cè)诟咝Э?jī)的 DevOps 組織中看到的那樣
流動(dòng)、反饋、學(xué)習(xí)
DevOps 并不止于此。我們主要討論了 DevOps 實(shí)現(xiàn)了革命性的流程，但通過(guò)類似的努力可以進(jìn)一步放大精益和敏捷實(shí)踐，從而實(shí)現(xiàn)更快的反饋循環(huán)和更快的學(xué)習(xí)。在DevOps手冊(cè) 中，作者除了詳細(xì)解釋快速流程外， DevOps 如何在整個(gè)價(jià)值流中實(shí)現(xiàn)遙測(cè)，從而獲得快速且持續(xù)的反饋。此外，利用精益求精的突破和 scrum 的回顧，高效的 DevOps 團(tuán)隊(duì)將不斷推動(dòng)學(xué)習(xí)和持續(xù)改進(jìn)深入到他們的組織的基礎(chǔ)，實(shí)現(xiàn)軟件產(chǎn)品開(kāi)發(fā)行業(yè)的精益制造革命。
從 DevOps 評(píng)估開(kāi)始
利用 DevOps 需要經(jīng)過(guò)大量研究或在 DevOps 顧問(wèn)和教練的幫助下，對(duì)高效績(jī) DevOps 團(tuán)隊(duì)中始終存在的一系列維度進(jìn)行評(píng)估。評(píng)估應(yīng)確定需要改進(jìn)的薄弱或不存在的團(tuán)隊(duì)規(guī)范。對(duì)評(píng)估的結(jié)果進(jìn)行評(píng)估，以找到具有高成功機(jī)會(huì)的快速獲勝焦點(diǎn)領(lǐng)域，從而產(chǎn)生高影響力的改進(jìn)。快速獲勝非常重要，能讓團(tuán)隊(duì)獲取解決更具挑戰(zhàn)性領(lǐng)域所需的動(dòng)力。團(tuán)隊(duì)?wèi)?yīng)該產(chǎn)生可以快速嘗試的想法，并開(kāi)始關(guān)注 DevOps 轉(zhuǎn)型。
一段時(shí)間后，團(tuán)隊(duì)?wèi)?yīng)重新評(píng)估相同的維度，以衡量改進(jìn)并確立新的高影響力重點(diǎn)領(lǐng)域，并再次采納團(tuán)隊(duì)的新想法。一位好的教練將根據(jù)需要進(jìn)行咨詢、培訓(xùn)、指導(dǎo)和支持，直到團(tuán)隊(duì)擁有自己的持續(xù)改進(jìn)方案，并通過(guò)不斷地重新評(píng)估、試驗(yàn)和學(xué)習(xí)，在所有維度上實(shí)現(xiàn)近乎一致。
