記得剛讀大學的時候，熱門的專業叫軟件工程，這個專業用國外的教程，學費比一般的專業還要貴很多，大概是 1.5 倍以上，因此搞軟件從來都是很復雜甚至感覺高大上的一個事情。

后面去讀《人月神話》，說實話就記住了一句話，軟件開發沒有銀彈，再次印證軟件不好搞。(題外話是，這本書其實對大學在讀或者剛從事開發的同學其實門檻有點高的，過于抽象。只有在親身參與過一些比較大的項目之后才會越來越體會。)

這么多年走來，經歷了 CMM 模型，敏捷開發，devops，參與過幾千人一起開發的項目，也搞過幾個人的小項目，各種角色也都搞過一遍，開發，項目管理，產品、業務負責人等等，有了一些更多的體會，這里講講特別流行 devops 怎么搞合適。

可能我不是專業搞工程效率，這一篇也不是一個說明教程來討論怎么搞軟件工程或者怎么搞 devops。核心是來討論下 devops 的價值和關鍵的一些前置要素，以及背后的一些邏輯。

先來看看 devops 實施帶來的直接的價值：

(1) 對客戶的價值：響應更快

• 通過按 feature 發布，feature 發布可以到天
• 對客戶來說需求的響應速度更快

(2) 對產品的價值：提升質量

• 每次減少發布范圍，降低出錯的概率，提升質量
• 出現問題，可以及時響應;通過回退，或者快速修復，提升產品質量

(3) 對團隊的價值：激活組織，簡化管理，提升效能

• 通過合理的拆解，降低耦合度，通過 分田到戶 提高團隊積極性;減少吃大食堂，相互等待，上下文切換導致的效能降低。對團隊同學 ，可以快速成長，承擔責任也有很大幫助。
• 對管理者可以釋放低效的組織協同工作，聚焦到更 high-level 的業務機會和項目機會上。
• 打通開發、運維邊界，減少上下文切換。另外通過合理的微服務拆分，單個任務的難度變低

那要實施一個軟件變更，其實不是一個簡單的要求就能完成的，是一個系統工程，devops 里面是有一些關鍵的前置要素：

• 微服務架構拆分
• CI / CD 工具
• 灰度環境
• 團隊文化轉型：對理念的認可，工作方式轉變的認可、T 字形人才的持續培養

在很多團隊都面向開發模式轉型的問題，我的建議是：

(1) 早實施比晚實施好：早實施客戶和業務負擔小

(2) 立刻做比詳細規劃好了做好：

• 個體開發效率相差會比較大，所以帶寬估計是非常困難的，所以相比激活組織潛力，詳細估計帶寬的價值小很多;
• 規劃是需要有的，但是業務變化很快，一個敏捷的組織價值更大，所以相比每件事都詳細規劃，立刻做價值更大
• 宏觀的全盤的規劃是需要的，要不能會缺乏方向感

(3) 考慮從一個/多個模塊開始，逐漸實踐和收獲經驗，另外最重要的是團隊同學文化的轉型，大家都理解和接受新的模式。

前面講了很多實踐的野路子，回到 Devops 學術上也定義了精髓，有一個“CALMS” 的主旨：

• Culture(文化)- 是指擁抱變革，促進協作和溝通
• Automation(自動化)- 是指將人為干預的環節從價值鏈中消除
• Lean(精益)- 是指通過使用精益原則促使高頻率循環周期
• Metrics(指標)- 是指衡量每一個環節，并通過數據來改進循環周期
• Sharing(分享)- 是指與他人開放分享成功與失敗的經驗，并在錯誤中不斷學習改進

你會發現其實前面講的可以映射到 CALMS 上，對照上去，理解其實會更深入。

除了前面說的各種價值，我覺得 devops 其實更大的價值在人性的激發。和傳統的敏捷和 CMM 模型最大的區別在于管理邏輯的區別。這種區別如果用數據庫里面的經典的鎖來說明，那其實就是 樂觀鎖和悲觀鎖的區別，devops 除了要有各種工具和套路之外，核心還是要能激活團隊個體成員的主動 owner 意識，讓他們敢打敢干。

所以 devops 會是終點嗎?我覺得肯定不是，軟件工程管理會持續演進和發展，去釋放更大的生產率。

來源鏈接：

http://mp.weixin.qq.com/s?__biz=MzA3ODUxMzQxMA==&mid=2663997949&idx=1&sn=005bde119fa72fbc3ca00605f23032f6&chksm=847c5590b30bdc8643872bf702f50b3a282b3705f047e17f79b031bcc952e1f28c29d2c1f068&mpshare=1&scene=23&srcid=01232RZsxNpaSboNbmj9atAk&sharer_sharetime=1642908755701&sharer_shareid=9603544ecd5d7f3dc66603ae089636f4#rd