解讀神書《鳳凰項目》,帶你跳出DevOps轉型的所有坑

提高DevOps工程師軟技能,可以瞭解一下筆者前一篇文章《DevOps工程師必備軟技能》

《鳳凰項目》是DevOps界神書,雖然內容表現形式是小說,但是依然是敏捷開發及DevOps領域的必讀書籍。很多知名的諮詢師都是通過此書開啓了DevOps及敏捷之旅,書中故事均來源於運維的日常工作,正是體現了藝術源於生活、高於生活的本質。筆者間隔兩年時間,閱讀此書兩次,希望可以講書中瞭解到的一些經驗分享給大家。

小說主人公比爾,臨時接任了IT運維經理的職位,然而此時,公司已經經歷了多輪裁員,生產線上故障不斷。董事會指望鳳凰項目重啓拯救公司,然而面對的着層層困難,比爾開始不停的應付突發的線上故障,身心俱疲。爲了生存及公司的正常運轉,嘗試出一套適合該公司的IT轉型方案,整個轉型過程就像我們從傳統開發模式轉型DevOps的開發模式一樣,踩過很多坑,總結出很多道理,小說的內容我不過多敘述,瞭解精彩的故事可以直接去購買圖書,下面會給大家總結一下書中的一些重要的經驗。

1.IT的四種工作形態

在故事中,主人公比爾在接替IT部經理後,通過一系列的故障處理與人際交流的過程中,得出了這個結論。IT的工作無非就是如下四種類型:

  1. IT部門內部項目
  2. 業務組項目
  3. 變更工作
  4. 救火工作

其實上述四種工作類型與我們目前運維部門的狀態基本一致,我們需要開發自己的運維與監控平臺,要參與到業務部門的開發測試中,要進行所有基礎設施及應用版本的變更與升級。而這些都是屬於正常的工作,我們往往最不願意處理的就是救火工作,比如線上的突發故障導致的所有用戶的功能無法使用,往往運維人員會在技術vp、cto、甚至ceo的注視下一行一行敲着命令,修復問題。大量運維人員應該都有過類似經歷,回想起來一定是慘不忍睹,所以我們要減少這種救火工作,並把前三種工作合理分配。

2. 加強變更管理,減少救火行爲

從IT的四種工作形態中,我們引申出一個問題,如何減少救火行爲呢,我們先看運維圈裏的兩個定律

  1. 著名的二八定律:線上80%的故障來自於20%的變更。
  2. GoogleSRE理論:大概 70% 的生產事故由某種部署的變更而觸發

我們不去糾結80%與70%的差異是怎麼產生的,但是結論是統一的,大量的線上的故障都是由於變更導致的,變更包括對應用程序、數據庫、操作系統、網絡或硬件進行的物理、邏輯或虛擬操作。可以看到,這些內容覆蓋了大量的運維工作了,爲什麼運維容易背鍋呢,就是因爲平時要處理這些高風險的變更操作,才容易引起線上的故障。而外人看來,運維就是在製造麻煩,之後開始救火工作、解決故障。爲了避免種情況,該怎麼處理呢?文章中給了我們很重要的方法,就是用看板的方法,規範化所有變更的管理,有計劃的進行每一次變更,評估每次變更帶來的風險點,就算出現故障,也可以快速修復。

3. 加強技術儲備,避免個人英雄主義

在解決所有變更導致的故障的時候,小說中出現了一個重要的人,杜倫特,這是運維團隊中的一個英雄角色,沒有他解決不了的問題。但是就是這麼厲害的一個人,所有開發人員都喜歡找他進行變更,所有的系統故障都需要他去處理,所以這麼厲害的人,每天都從事的是救火工作。這個角色就變成了我們運維規範化過程中的一個瓶頸點。只要他的工作無法被其他人員替代,就無法讓他去做運維團隊更重要的事,比如自動化的建設,比如重要的監控建設。小說裏爲了解決這個問題,比爾設置了故障處理分級機制,把杜倫特保護起來,不允許開發人員直接與杜倫特溝通,同時安排其他工程師接觸杜倫特原來的工作,讓杜倫特的工作重心在自動化建設與監控建設上。這樣在關鍵位置上增加了技術儲備的同時,也將核心技術人員用在了最重要的位置上。

4. 限制在製品數量,多做從0到1,減少0.5的數量(看板)

小說的名稱叫《鳳凰項目》,所以故事核心是圍繞着鳳凰項目來的,鳳凰項目是一個計劃了三年,經過了三年的憋大招勉強上線的一個項目,當然,準備了這麼久的項目最後以失敗告終,這個問題告訴我們什麼呢。主人公在工廠車間意識到,如果工廠的人力是固定的,如果半成品積累的過多,就會導致最終成品交付給用戶會變慢,這也就是我們在軟件開發領域常說的在製品數量影響着交付的速度,如果開發團隊同時迭代着過多的需求,那麼必然需求交付到用戶的手中的時間要延長。所以限制在製品數量是DevOps建設的一個核心內容,我們應該多做從0-1的事,而減少0.5的數量。書中總結的很好,一旦研發資本以半成品的形式鎖定超過一年而未向公司返還現金,他就幾乎不可能再爲公司產生回報。

 

5. 三步工作法

小說的最後作者總結了三步工作法,包含:

(1)流動原則

流動原則是DevOps建設的基礎,縮短滿足客戶需求的潛質時間,建立自動化工具鏈,減少人工干預過程,減小在製品數量,快速迭代,便可以有效地提高工作質量和產量。

(2)反饋原則

在源頭髮現問題,儘早發現問題,測試及安全左移,在生產的源頭就要保證質量。

(3)持續學習與實驗原則

把生產效率、工作流程上升到領導層,推進DevOps文化的落地。

總結:還等什麼,買書去看吧,《鳳凰項目》。

 

更多精彩內容可以關注我們的在線課系列課程

系列課程背景

在過去的一年中,微服務,持續交付和 Kubernetes等概念關注度持續提升,而互聯網,大型企業裏對於持續交付的培訓並不專業,導致團隊成員上手慢,對流程不清晰,溝通成本高。

基於此痛點,我們推出了基於 Sping Cloud 微服務,Kubernetes 的持續交付系列課程,並且以一個 GuestBook 的實戰項目進行持續發佈,讓學員從理論,到代碼實戰,深入的理解基於容器,微服務的持續交付過程。

系列課程收益

此課程是首個專注於微服務的持續交付課程,通過學習課程,學員能夠理解 Spring Cloud 的基礎知識,以及如何進行打包,自動化測試,Jenkins持續集成,以及基於 Kubernetes 部署,讓學員能夠端到端的提升職業技能,是學員升職加薪,走向全棧架構師的必備課程。

本期課程日程

1. 深入介紹 Spring Cloud 核心組件 Eureka
2. 網關 Zuul
3. 服務追蹤 Zipkin
4. 配置管理 Spring Cloud Config

本期課程收益

-學員能夠深入瞭解 Spring Cloud 組件的實現原理
-通過樣例代碼快速體驗 Spring Cloud

報名鏈接:https://www.bagevent.com/event/6423668

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章