一步步實施 DevOps （一）

Netkiller Management 手札

 

Mr. Neo Chan, 陳景峯(BG7NYT)

中國廣東省深圳市望海路半島城邦三期
518067
+86 13113668890

<netkiller@msn.com>

Copyright © 2010-2018 netkiller

 

版權聲明

轉載請與做者聯繫，轉載時請務必標明文章原始出處和做者信息及本聲明。

http://www.netkiller.cn http://netkiller.github.io http://netkiller.sourceforge.net

微信訂閱號 netkiller-ebook (微信掃描二維碼） QQ：13721218 請註明「讀者」 QQ羣：128659835 請註明「讀者」

 

 

什麼是DevOps?

 

首先DevOps 不是一個產品，其次軟件工程方法論也不許確。

 

在 DevOps 模式下，產品，設計，開發，測試和運維團隊更緊密地結合在一塊兒，貫穿應用程序的整個生命週期。

經過自動化工具替代手工操做，實現快速，高效，安全的測試，構建，部署項目。

 

爲何會誕生DevOps?

 

隨着管理學的不斷完善，例如工商管理，被分紅不少縱深領域，行政管理，人事管理，財務管理，營銷管理，項目管理……等等。

 

因爲組織架構的須要，又把人分紅不少崗位，每一個崗位上牢牢須要一種知識體系。

 

同時咱們學校也按照知識體系劃分院系，本科教育程專科趨勢，不重視通識教育，最終學生牢牢掌握了微觀的知識。

 

若是說哲學是科學的科學，那麼 DevOps 就是管理的管理。因此我認爲 DevOps 是多維度宏觀管理學。

 

 

DevOps 雖好，爲何難以普及呢？

 

實施DevOps 第一個遇到的問題就是人才，DevOps 須要經驗豐富的跨界人才。第二個問題就是沒有案例可循，沒法參考。

 

實施DevOps須要具有管理，開發，測試，運維等等背景的人才。每一個領域至少也須要三年的積累，至少須要 3+3+3+3 = 12 年工做經驗，多少公司員工都比較年輕，廣泛在 3~5年。

通常員工工做10年以上，遍開始轉向管理崗位，或者尋找其餘出路。即便轉管理崗的員工牢牢負責開發管理或者測試管理…… 不太可能10年的開發，轉運維部重頭開始。

 

我上面說過咱們教育模式有問題，本科教育應該培養 「T」 型人才，專科教育培養 「I」 型人才，本科教育呈專科化。學校只教會學生一項技能（如Java 開發）,而沒有教會學生如何學習。

 

在中國企業的年齡歧視  「T」 型人才流失嚴重。「I」人才只能掌握一項技能解決一個領域的問題，沒法完成DevOps 的實施。

 

DevOps 不是產品，是一種管理思想，每一個企業根據自身特色，制定本身的DevOps規範，因此第二個難點就是，沒有案例可循，沒法參考。

 

 

軟件工程的歷史與進化

 

傳統軟件工程學出現的年代互聯網還不普及，主要是單機運行的軟件，或者C/S結構的軟件，其特色是開發週期長，迭代慢，每半年或者一年交付一次。流程主張：

 

需求->設計->開發->測試->交付

 

進入互聯網時代，已B/S爲主的軟件，交付週期縮短到一個月，在傳統軟件工程作了改進，放棄了瀑布開發模式，提出了快速迭代，螺旋上升，管理上也逐步完善。出現了軟件項目管理，CMM5軟件開發成熟度模型。

 

隨着Web 2.0 和 雲計算思想的提出，軟件也在發生變化，軟件運行不在限於一臺物理機，而是多臺服務器的集羣中，傳統的模塊或原件，被獨立部署在世界各地。

軟件的開發面臨史無前例的挑戰：

1. 異構平臺，軟件不限於那種操做系統，例如Unix,Linux,As/400,windows,Mac
2. 多語言混合開發，不在牢牢使用一種語言開發軟件。每一種語言都有他所在領域的優點。
3. 分佈式，軟件不再是隻運行在 一個CPU下，軟件被分紅不少模塊被分佈式部署到多臺服務上。

 

這時便出現了極限編程，敏捷開發….等等，新的思想不斷提出，可是仍然沒法解決面臨的問題。

 

• 產品部：需如雪片飛來，需求堆積如山
• 開發部：版本延期，質量問題頻發，疲於奔命修復 BUG，剛修復了一個， 又出現新的 Bug
• 測試部：手工測試，升級後問題爆發，測試環境經過，到生產環境就出問題
• 運維部：環境不統一，每次部署都是一場災難，配置易出錯，回撤時間長，
• 團隊現狀：加班嚴重，效率地下，天天奔波救火
• 測試環境沒法重現，開發人員直接在線上修改代碼，跳過測試直接將代碼交給運維升級
• 運維事故嚴重影響運營和廣告投放
• 人員流動致使代碼丟失

 

 

問題的緣由在於，他們牢牢從各自部門的角度解決問題，同時 KPI 考覈也不合理：

產品從產品的角度解決產品遇到的問題。

開發從開發的角度解決開發遇到的問題。

測試從測試的角度解決測試遇到的問題。

運維從運維的角度解決運維遇到的問題。

 

實際上如今的軟件已經不是當年交付後一個網管就能搞定剩下的工做。同時軟件開發交付週期縮的更短，一週甚至天天升級數次，遇到突發事件要作好隨時準備升級。

 

總結這個時期其實是： 軟件項目管理 加 ITSM (IT Service Management) IT服務管理

 

因此聚焦微觀管理解決宏觀管理問題的作法是錯誤的，因而誕生了 DevOps。 DevOps 是多維度宏觀管理學，是管理的管理。

 

 

開發，測試與運維三個部門的關係

 

開發，測試，運維不是三個獨立部門，他們相互緊密聯繫，但又相互制約：

 

開發只負責寫程序，將運行無誤的程序提交至版本庫中

開發不能私自將程序交給運維部署，也不能將編譯好的程序給運維測試。

測試部只能從版本庫提取代碼，而後編譯，打包，運行，測試

不容許測試部將代碼交給運維部部署

避免代碼沒有通過版本庫流入生產環境，線下與線上代碼不一致

運維部負責部署應用程序，配置管理，只接受測試部確認無誤的版本，部署代碼只能從版本庫中提取

 

開發 -> 測試 -> 運維 貫穿始終。

 

技術規範的誤區

 

幾乎全部的技術企業都會重視技術規範，爲此制定各類規範，並要求員工嚴格執行。同時員工會想出各類對策，就這樣造成了潛規則。

流程與規範的制定須要須要知足幾個條件，簡單，容易掌握，容易執行，可重複執行

企業管理層擅長制定烏托邦式的流程與規範，隨便拿出一條都堪稱完美，無懈可擊，但沒有考慮到執行結果，流程規範在執行過程當中每一個環節都會出現問題。

我16年的職業生涯中在不一樣的公司任職過，幾乎每到一家公司都會遇到各類規範，隨着職業發展最後我也成爲了規範的制定者，也曾經主持制定過開發規範，運維規範，測試規範等等。

我作過不少規範，文檔無數，技術人員根本不會去看，經過開會向下傳達，開會的人根本沒有心思理會你的規範，規範執行阻力是很大的，效果也差。

終於有一天我意識問題的存在，開始反思，企業是否須要制定這些規範？ 我發現與企業環境/文化有很大關係。

有些強制的規範能夠經過一些技術手段，避免出現。不會出現也就無需規範！

只有機器人才能100%執行流程

除了事，制定規範，後續無人跟進，

員工考慮的是儘快完成工做，

但這些規範起到的實質做用就比如「請保持室內衛生，不許亂團垃圾，禁止隨地吐痰」

故事一

例以下面一個小故事，公司某部由於將開發數月的代碼丟失了，致使測試沒法進行，領導打發雷霆，某管理層制定了下面的規範，大意爲。

 

1. 按期備份機制

2. 代碼註釋要求

3. 代碼訪問須要更高層的批准

4. 詳細的部署文檔

等等

我認爲源碼管理主要有兩種手段，技術手段與管理手段。

我先談談管理手段： 例如一般經過規章制度，責任追究等等手段，要求員工達到規範標準，但一般執行力都會打折，沒法達到預期，人的不穩定性因素太多。每每發現員工沒有按照規範操做爲時已晚，將該員工辭退也沒法挽回公司的損失。

就如公司規章制度寫的清清楚楚，要求員工提交代碼到版本庫，但各類緣由沒有被執行，當代碼丟失，從上至下追究責任，公司的損失沒法挽回。

 

因此我主張技術手段：

例如源碼若是發佈到線上，必須通過版本庫，只能使用自動部署，不容許程序員私自將代碼交給運維手工部署。另外發布代碼的同事，能夠不提供生產服務器登錄權限，他只能經過工具發佈代碼。

部署流程以下：

源碼(程序員) 提交到development 分支UAT階段 ----> 合併到 testing 分支Beta階段（主管合併，程序員沒有權限）------> master 分支(主管合併) -----> 自動部署系統(運維) ----> 生產服務器。

這樣經過技術手段防止了代碼因員工離職，硬盤損壞等等緣由，致使代碼丟失的可能。

代碼發佈者也無需對照部署文檔，手動登錄服務器逐條按照部署說明書操做，防止了人員誤操做，也提升了部署效率，節省了人力成本，一般在5分鐘以內能夠完成全部部署。

 

 

故事二

 

-----

我再來舉另一個例子，就是開發中的編碼規範，不少軟件企業都有是否是？

 

例如要求程序員：

if

(){}

要寫成

if ()

{

...

}

等等要求不一一列舉，甚至組織代碼評審解決編碼規範問題。

 

個人建議爲何不在IDE上設置自動格式化，或者在svn/git提交的時候經過hook調用格式化程序。

 

故事三

-----

管理層要求運維天天發送服務器狀態報告，運維人員須要登陸每一個服務器或者從cacti等工具中得到服務器運行狀態數據，而後製做一個報告文檔，天天給各位發送一次。

 

運維須要一個專職人員作這個報告，這種報告幾乎沒有人看，就像「人民日報」 人民歷來不看。

 

當運維事故該出現的時候仍是會出現，老闆一個一個罵，扣工資，扣獎金，運維以爲委屈，公司受到損失。平日裏的這些工做並不能避免運維事故，也不能改善運維工做。

 

故事四

-----

在舉一個例子，運維工做要求備份數據，A員工負責備份，B 員工負責檢查A員工的備份。

結果兩年之後出事了，須要恢復數據，發現A沒有備份，而B在一年前就再沒有檢查A的工做。

起初前一年仍是按流程備份，後來A發現B再也不嚴格檢查工做，備份工做逐漸減小，最後中止了備份，一直相安無事，直到事發。

 

故事五

-----

我曾經遇到過一個兢兢業業的管理者，他制定規範，要求值班的同事7*24小時，每間隔必定的時間作一次操做，驗證系統正常運行，以便可以第一時間通知運維處理故障。值班的同事而偶偷懶，他就半夜起來監控他們工做。一個打工者能作到如此，真讓人佩服。

可是咱們有更好的方法，真的沒必要如此操勞且效率低下。

 

這些故事是一個無休止的死循環

-----

出問題 -> 發上制定規範 -> 無人看/看了慢慢淡忘/石沉大海 -> 繼續出問題。連續出現問題，採用行政手段處分，扣獎金等等。不少管理者將其歸咎爲 「執行力」 弱，我並不這麼認爲。

 

 

我以爲不少規範是形式主義。我一貫主張實用主義。

 

經過技術手段可能避免不少沒有意義規範，開發自動化，測試自動化，運維自動化，這是趨勢也是個人努力的目標。

 

 

不少企業爲何實施 DevOps 以失敗了結？

 

不少企業實施DevOps 牢牢是軟件堆砌，根本沒有深刻理解 DevOps，吧devops 相關的軟件所有安裝上，而後作系統集成。這時各部門一片抱怨聲：

 

管理層說：項目管理工具很差用。

產品說：我不用那個Wiki寫需求

設計說：版本控制對於PSD這種大文件兼容很差

開發說：咱們不用 Docker，而咱們也不用 maven

測試說：怎麼隨意部署環境，咱們尚未測試完，就清空數據了。

運維說：我不敢用你的自動發佈

 

改變現有的工做方式是很是痛苦的，任何不合理的流程和工做方式已經使用了多年，習慣已經根深蒂固。

實施devops 須要各部門收集意見，對各個部門培訓，等各部門理解了 DevOps 原理和流程後，才能實施。

 

若是判斷你的團隊已經成功的實施了  DevOps ？

 

判斷標準是：

 

1. 項目管理，產品，設計，開發，測試，運維已經變成一條流水線。而不是每一個部門獨立工做。
2. 在生產環境上使用 DevOps ，而不是牢牢給開發和測試人員用是
3. 自動化程度
4. KISS（Keep it Simple and Stupid，簡單就是美）原則是最重要的

 

延伸閱讀《Netkiller Web 手札》《Netkiller Testing 手札》《Netkiller Linux 手札》