本文是基于 中國DevOps社區峰會 2021·深圳 + 本人在作業中所遇到的問題進行一個簡單的梳理，本來是準備連帶著 《DevOps實踐指南》讀后感一起的，但是發現可能會導致這篇文章內容過于臃腫，決定分兩版產出，

DevOps

DevOps官方介紹

DevOps維基百科定義 DevOps（Development和Operations的組合詞）是一種重視“軟體開發人員（Dev）”和“IT運維技術人員（Ops）”之間溝通合作的文化、運動或慣例，透過自動化“軟體交付”和“架構變更”的流程，來使得構建、測驗、發布軟體能夠更加地快捷、頻繁和可靠，

由于博主本身不是做運維相關的作業，所以博主不會過多關注運維工具，以下介紹中可能會缺失運維工具這一塊，請大家諒解，

DevOps前世今生

我們的開發模式大致經歷了三個階段：單體架構+瀑布模式 -> 分布式架構+敏捷開發模式 -> 微服務架構 + DevOps

• 單體架構 + 瀑布模式
  • 需求回應慢、上線時間久、無法跟上市場的變化、一次寫眾多的功能代碼BUG多、服務冗余不易擴展；
• 分布式架構 + 敏捷開發模式
  • 開發與運維的隔離、多人協同開發效率上不來、版本與版本之間并行開發卻不同時間上線導致的代碼合并、腳本管理、分支管理、測驗環境A/B版本疊加后問題排查復雜化；
  • 但是小團隊依然適合這個模式，它依然很棒；
• 微服務架構 + DEVOPS
  • 吸取敏捷模式的優點并擴大化；
  • CICD、自動化測驗、無需復雜的代碼分支管理、更快的需求回應、更高頻的生產發布、開發運維一體化；
  • 主要體現在：人、流程、平臺、自動化；
  • 也是一種文化；
  • 團隊越來越大后需要思考和轉型的模式；

DevOps能做什么

• 更多的在技術視角上解決痛點、提升效率、團隊成員的成長是巨大的
• 一定的體現在業務交付更快、頻率更高更高頻率的生產發布
  • CICD（持續集成、持續交付、持續部署）
  • 自動化
  • 左移
    • 測驗左移；
    • 安全左移；
    • …左移；
• DevOps的目標一定不能是：提高開發團隊的需求吞吐量！！！雖然當您成功的完成DevOps轉型后吞吐量會有提升，但是請保持初心！！！

自動化與持續反饋

• 結對編程(PairProgramming)
  • 極限編程（ExtremeProgramming，簡稱XP）同樣也是提倡結對編程，敏捷中的一種方式，提倡兩個人來一起完成同一項任務，并互相了解閱讀對方的代碼，來保證質量和規范；
• 自動化測驗覆寫率問題
  • 不要被100%的代碼覆寫率欺騙，有些陳述句并沒有覆寫的價值，100%的代碼覆寫率會讓人迷失目標；

如何推動DevOps轉型

• 自上而下
  • 一定要有一個高層領導認可，且愿意去負責推動DevOps，并能給與你一定資源上的支持；
• 以點帶面
  • 先從愿意轉型且能夠承擔失敗風險的團隊開始最好只挑選一個團隊，集中全部精力，打造典范，這個團隊不能是太邊緣的團隊，制定階段性指標，并周期性復盤指標完成情況；
  • 當打造出成功案例后再去逐步推廣，此時遇到完全不愿意配合的團隊Leader，可以視情況放棄，先搞定那些愿意的、不抵觸的團隊人都是從眾的，當所有人都去這樣做，那么他也會選擇跟隨；
  • 最后再去瓦解"釘子戶"；
• 改變能改變的，接受不能改變的
  • 規范是死的，人是活的，因地制宜，不要死搬規范，硬走流程，退一步海闊天空；

技術債

什么是技術債

技術債是指我們當前所做出的決定會導致一些問題，而這些問題隨著時間推移會越來越難解決，未來可采取的措施也會越來越少，即使我們審慎地承擔債務，也會產生利息——摘抄自《DevOps實踐指南》

如何解決技術債

這一塊不論是書中還是DevOps社區峰會的大佬們的分享，都是采用每個版本或者說每個周期拿出 20%的資源 去做技術團隊 自提 的需求，可以是代碼 重構 、資料庫 表結構優化 、慢SQL優化 、 新技術 研究引入，等等用戶不可見的需求，
當然很多團隊都在做著這些，但是他們是讓技術團隊在滿足需求后再去做這些東西，這樣可能存在 作業量 的問題，使得開發人員的 抵觸情緒 ，同時沒有明確這件事的 重要性，也無法保證其 持續性，且多為團隊中極少數人提出或只有Leader提出，因為提出這些建議會導致他們的作業量的增加，

去QA是提高質量的有效手段

為什么這個bug都測不出來；
測驗怎么測的，到底會不會測驗；
測驗快點啊，為啥總是測驗拖后腿，最后才測驗出bug；
不知道大家團隊中會不會遇到這個問題，到底漏測BUG是開發的問題還是測驗的問題呢？

• 去QA的目的去QA并非完全的砍掉，而是解決研發過度依賴QA的問題
  • 消除對職位的依賴
  • 提升對職能的要求
  • 構建質量內建的文化
  • 強化自身關聯性

研發效能分析

核心：研發效能指標分析不能和KPI掛鉤！研發效能指標分析不能和KPI掛鉤！研發效能指標分析不能和KPI掛鉤！

研發效能是什么

度量的方式

• 工具
  • 需要一個好的需求管理工具來根據實際操作生成圖表TAPD、禪道等等都能滿足；
  • 圖表有很多，請根據自身團隊情況與瓶頸選擇對應的指標圖；
• 規范
  • 有了工具自然還需要規范，大家需要依據規范操作，這樣產生的資料圖表才是準確的、有效的；
  • 流程管控需要更細粒度，這樣才能找到真正的 瓶頸 ，正如一條流水線，我們去優化瓶頸前的流程，會導致瓶頸處堆積更加嚴重；我們去優化瓶頸后的流程，會導致它們更加饑渴；只有對瓶頸的優化才能讓整體產能發生質變；
• 文化
  • 規范總是那么的冷冰冰，哪怕你還不知道我的規范的內容，你就開始抵觸，這是后需要灌輸文化，讓大家支持且認同我們所做的一切，我們的選擇是正確的，我們正在讓自己變得更加強大；
  • 而文化可以通過行為影響，也能通過培訓灌輸，培訓的形式可以是 分享會 、 有獎競賽等等方式；

度量的維度

• 交付效能指標
  • 多不多
  • 快不快
  • 好不好
  • 省不省
• 工程能力指標
  • 研發及架構
  • 代碼擾動率
  • 測驗及質量
  • 變更部署及發版
  • 監控排障

度量的誤區

• 過度依賴工時、代碼行數 等易于獲得的資料
• 忽視團隊成員的發展需求
• 缺乏統一的標準，主觀性強
• 缺少程序工具，指標資料人工錄入
• 度量指標的滯后性
• 單一評價維度

團隊資料收集

下面這些不管您的團隊是否正在推行DevOps，我認為它們都是對團隊有幫助的東西，
當然我們需要先明確一個事情，就是許多時候需要下面的同事們反饋表決的時候，會發現更多的人是不愿意敞開心扉來表達自己真實的想法，特別體現在舉手表決上，所以我們需要為這幫兄弟們提供一個絕對安全的環境，供他們暢所欲言——匿名投票、匿名反饋
特此鳴謝 中國DevOps社區，因為下面許多指數都是在本次學習中 謝意 老師分享的

作業資料

幫助最大的人

• 總分制、每人可投遞總分5分，可全部給一個人也可以按照最小單位為 1 的情況下給不同的人；
• 每個版本結束后或每個月一次，匿名或非匿名均可；
• 讓優秀的人得到肯定與表揚，可以定期給與拿分高的同事一定的獎勵，但是切記不要固定的去懲罰那些分數最低人！！！
• 在參與大會前其實我們團隊中也會有這個形式，但是并沒有形成這樣規范、固定的模式，導致沒有具體分值留底

開心與傷心

• 內容收集，并盡可能的當場確定行動方案；
• 每個版本結束后或每個月一次，按小組或按人提交均可；
• 這里注意用的是 開心 與 傷心，而不是 做的好 與 做的不好 ，避免在標題上讓人出現一種我在批評人的錯覺，而是用傷心來體現出這是我自己的情感，并非指責大家，

其他指數

起床指數

• 指數為1 - 5分，分數越高代表起床意愿越強烈，也代表今天對作業的意愿更強，也可以一定程度代表今天的心情；
• 每天早上、非匿名打分；
• 對于低分的同事給與更多關心，了解其今天的狀況，避免在不知情的情況下對其造成更大的傷害；

吃飯指數

• 指數為1 - 5分，分數越高代表聚一頓的意愿越強；
• 不定周期、下班前、匿名提交；
• 當大家意愿都很強的時候可以考慮來一頓說走就走及聚餐，團建無處不在建議提前訂好是Leader自掏腰包 or 團建經費 or AA制；

淺談敏捷

敏捷的誤區

• 擁抱變化 = 需求頻繁變更
• 過度依賴晨會進行溝通同步
• 對需求進行不合理的拆分
• 敏捷就是更緊密的迭代

文中大量內容來自 中國DevOps社區峰會 2021·深圳 大家可以關注公眾號 “DevOps社區Meetup” 回復內容 ：“深圳峰會” 可獲取本次分享的部分PPT內容，非常可惜有不少精彩的分享可能因為涉及敏感資料并未公開， 以上內容如有侵權，請聯系作者，將會立刻修改洗掉