推動 DevOps 變革的三個方面

避免痛苦是一種強大的動力。一些研究表明，植物也會通過遭受疼痛的過程以採取措施來保護自己。我們人類有時也會刻意讓自己受苦——在劇烈運動之後，身體可能會發生酸痛，但我們仍然堅持運動。那是因為當人認為整個過程利大於弊時，幾乎可以忍受任何事情。

推動大規模的組織變革的過程確實是痛苦的。有人可能會因難以改變價值觀和行為而感到痛苦，有人可能會因難以帶領團隊而感到痛苦，也有人可能會因難以開展工作而感到痛苦。但就 DevOps 而言，我可以說這些痛苦都是值得的。

我也曾經關注過一個團隊耗費大量時間優化技術流程的過程，在這個過程中，團隊逐漸將流程進行自動化改造，並最終獲得了成功。


圖片來源：Lee Eason. CC BY-SA 4.0

這張圖表充分表明了變革的價值。一家公司在我主導實行了 DevOps 轉型之後，60 多個團隊每月提交了超過 900 個發布請求。這些工作量的原耗時高達每個月 350 人/天，而這麼多的工作量對於任何公司來說都是不可忽視的。除此以外，他們每月的部署次數從 100 次增加到了 9000 次，高危 bug 減少了 24%，工程師們更輕鬆了， 凈推薦值 Net Promoter Score （NPS）也提高了，而 NPS 提高反過來也讓團隊的 DevOps 轉型更加順利。正如 Puppet 發布的 DevOps 報告所預測的，用在技術流程改進上的投入可以在業務成果上明顯地體現出來。

而 DevOps 主導者在推動變革時必須關注這三個方面：團隊管理，團隊文化和團隊活力。

團隊管理

最重要的是，改進對技術流程的投入可以轉化為更好的業務成果。

組織架構越大，業務領導與一線員工之間的距離就會越大，當然發生誤解的可能性也會越大。而且各種技術工具和實際應用都在以日新月異的速度變化，這就導致業務領導幾乎不可能對 DevOps 或敏捷開發的轉型方向有一個親身的了解。

DevOps 主導者必須和管理層密切合作，在進行決策的時候給出相關的意見，以幫助他們做出正確的決策。

公司的管理層只是知道 DevOps 會對產品部署的方式進行改進，而並不了解其中的具體過程。假設你正在幫助一個軟體開發團隊實現自動化部署，當管理層得知某次部署失敗時（這種情況是有的），就會想要了解這件事情的細節。如果管理層了解到進行部署的是軟體團隊而不是專門的發布管理團隊，就可能會堅持使用傳統的變更流程來保證業務的正常運作。你可能會失去團隊的信任，團隊也可能不願意做出進一步的改變。

如果沒有和管理層做好心理上的預期，一旦發生意外的生產事件，重建管理層的信任並得到他們的支持比事先對他們進行教育需要更長的時間。所以，最好事先和管理層在各方面協調好，這會讓你在後續的工作中避免很多麻煩。

對於和管理層之間的協調，這裡有兩條建議：

• 一是重視所有規章制度。如果管理層對合同、安全等各方面有任何疑問，你都可以向法務或安全負責人諮詢，這樣做可以避免犯下後果嚴重的錯誤。
• 二是將管理層重點關注的方面輸出為量化指標。舉個例子，如果公司的目標是減少客戶流失，而你調查得出計劃外的服務宕機是造成客戶流失的主要原因，那麼就可以讓團隊對故障的 平均排查時間 Mean Time To Detection （MTTD）和 平均解決時間 Mean Time To Resolution （MTTR）實行重點優化。你可以使用這些關鍵指標來量化團隊的工作成果，而管理層對此也可以有一個直觀的了解。

團隊文化

DevOps 是一種專註於持續改進代碼、構建、部署和操作流程的文化，而團隊文化代表了團隊的價值觀和行為。從本質上說，團隊文化是要塑造團隊成員的行為方式，而這並不是一件容易的事。

我推薦一本叫做《披著狼皮的 CIO》的書。另外，研究心理學、閱讀《Drive》、觀看 Daniel Pink 的 TED 演講、閱讀《千面英雄》、了解每個人的心路歷程，以上這些都是你推動公司技術變革所應該嘗試去做的事情。如果這些你都沒興趣，說明你不是那個推動公司變革的人。如果你想成為那個人，那就開始學習吧！

從本質上說，改變一個人真不是件容易的事。

理性的人大多都按照自己的價值觀工作，然而團隊通常沒有讓每個人都能達成共識的明確價值觀。因此，你需要明確團隊目前的價值觀，包括價值觀的形成過程和價值觀的目標導向。但不能將這些價值觀強加到團隊成員身上，只需要讓團隊成員在現有條件下力所能及地做到最好就可以了。

同時需要向團隊成員闡明，公司正在發生組織和團隊目標的變化，團隊的價值觀也隨之改變，最好也釐清整個過程中將會作出什麼變化。例如，公司以往或許是由於資金有限，一直將節約成本的原則放在首位，在研發新產品的時候，基礎架構團隊不得不共享資料庫集群或伺服器，從而導致了服務之間的緊密耦合。然而隨著時間的推移，這種做法會產生難以維護的混亂，即使是一個小小的變化也可能造成無法預料的後果。這就導致交付團隊難以執行變更控制流程，進而令變更停滯不前。

如果這種狀況持續幾年，最終的結果將會是毫無創新、技術老舊、問題繁多以及產品品質低下，公司的發展到達了瓶頸，原本的價值觀已經不再適用。所以，工作效率的優先順序必須高於節約成本。如果一個選擇能讓團隊運作更好，另一個選擇只是短期來看成本便宜，那你應該選擇前者。

你必須反覆強調團隊的價值觀。每當團隊取得了一定的工作進展（即使探索創新時出現一些小的失誤），都應該對團隊作出激勵。在團隊部署出現失敗時，鼓勵他們承擔風險、吸取教訓，同時指導團隊如何改進他們的工作並表示支持。長此下來，團隊成員就會對你產生信任，不再顧慮為切合團隊的價值觀而做出改變。

團隊活力

你有沒有在會議上聽過類似這樣的話？「在張三度假回來之前，我們無法對這件事情做出評估。他是唯一一個了解代碼的人」，或者是「我們完成不了這項任務，它在網路上需要跨團隊合作，而防火牆管理員剛好請病假了」，又或者是「張三最清楚這個系統，他說是怎麼樣，通常就是怎麼樣」。那麼如果團隊在處理工作時，誰才是主力？就是張三。而且也一直會是他。

我們一直都認為這就是軟體開發的自帶屬性。但是如果我們不作出改變，這種循環就會一直持續下去。

熵的存在會讓團隊自發地變得混亂和缺乏活力，團隊的成員和主導者的都有責任控制這個熵並保持團隊的活力。DevOps、敏捷開發、上雲、代碼重構這些行為都會令熵加速增長，這是因為轉型讓團隊需要學習更多新技能和專業知識以開展新工作。

我們來看一個產品團隊重構歷史代碼的例子。像往常一樣，他們在 AWS 上構建新的服務。而傳統的系統則在數據中心部署，並由 IT 部門進行監控和備份。IT 部門會確保在基礎架構的層面上滿足應用的安全需求、進行災難恢複測試、系統補丁、安裝配置了入侵檢測和防病毒代理，而且 IT 部門還保留了年度審計流程所需的變更控制記錄。

產品團隊經常會犯一個致命的錯誤，就是認為 IT 是消耗資源的部門，是需要突破的瓶頸。他們希望脫離已有的 IT 部門並使用公有雲，但實際上是他們忽視了 IT 部門提供的關鍵服務。遷移到雲上只是以不同的方式實現這些關鍵服務，因為 AWS 也是一個數據中心，團隊即使使用 AWS 也需要完成 IT 運維任務。

實際上，產品團隊在向雲遷移的時候也必須學習如何使用這些 IT 服務。因此，當產品團隊開始重構歷史代碼並部署到雲上時，也需要學習大量的技能才能正常運作。這些技能不會無師自通，必須自行學習或者聘用相關的人員，團隊的主導者也必須積極進行管理。

在帶領團隊時，我找不到任何適合我的工具，因此我建立了 Tekita.io 這個項目。Tekata 免費而且容易使用。但相比起來，把注意力集中在人員和流程上更為重要，你需要不斷學習，持續關注團隊的短板，因為它們會影響團隊的交付能力，而彌補這些短板往往需要學習大量的新知識，這就需要團隊成員之間有一個很好的協作。因此 76％ 的年輕人都認為個人發展機會是公司文化最重要的的一環。

效果就是最好的證明

DevOps 轉型會改變團隊的工作方式和文化，這需要得到管理層的支持和理解。同時，工作方式的改變意味著新技術的引入，所以在管理上也必須謹慎。但轉型的最終結果是團隊變得更高效、成員變得更積極、產品變得更優質，客戶也變得更滿意。

免責聲明：本文中的內容僅為 Lee Eason 的個人立場，不代表 Ipreo 或 IHS Markit。

via: https://opensource.com/article/18/10/tales-devops-transformation

作者：Lee Eason 選題：lujun9972 譯者：HankChow 校對：pityonline

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive