在10 月 26 日結束的 GTLC 成都站上，愛範兒 CTO & TGO鯤鵬會廣州分會學習委員何世友進行了「日迭代 1000+，該拿什麼來換？」的主題分享。在本次演講中，何世友聚焦交付頻次，分享了現代研發流程該如何改造，高低頻次所能發揮的效果以及其所帶來的犧牲，帶來了不同的團隊該如何進行排兵佈陣，找到適合自己的最優解。本文根據其演講整理而成，分享給未能來現場參會的你。以下內容整理自何世友的現場發言：
編者注：查看何世友完整版 PPT，請在 TGO 鯤鵬會公衆號回覆“GTLC 成都站”自動獲取。
DevOps 是最簡單的問題
當我們聊到 DevOps 和 CI/CD 時，都會被形容成流水線。今天，我以愛範兒團隊的一個產品實際流程爲例，畫了下圖：
上圖中需要注意的是，研發和生產可以完全獨立的兩個生命週期，接下來我將從生產說起。
AutoScale 自動擴縮容
生產環節中的所有系統都只服務於一件事——不宕機。那麼如何才能實現不宕機呢？隨時隨地快速部署，每一次 Scale 都是一次部署。
上圖中列了生產中的必要組成部分——日誌系統、APM 探針服務、統計監控服務、錯誤上報服務、OnCall 報警服務以及 AutoScale 機制。他們的關係應該是下圖：
上述這些子系統，歸根結底不是給人看的，而是給 AutoScale 機制看的，人永遠沒有機器響應得快。我們擅長的是：發現規律，制定規則；機器擅長的是執行。因此，我們需要通過編排這些系統的數據流向，讓這個生命週期自己運轉起來。
以 AWS 的 ASG 爲例，一個自動擴縮容組主要包括：一個 ELB 彈性負載均衡器、一組應用服務器、一個部署機制以及一些擴縮容規則，下圖就是一個典型的常用規則：ELB 的指定單位範圍內的平均響應時間超過一個閾值時，增加一些機器到服務器組。
自動擴縮容機制會隨時根據這些規則對數據進行測算，滿足條件後則執行響應動作。
如果規則很多，互相干擾怎麼辦？增加 Cooling Down 機制就可以在一定程度上避免干擾，讓不同的規則可以互相輔助。
APM、日誌和監控
Scale 解決了，再來看看讓 Scale 可以工作的各個背後的系統。
APM 探針服務是我個人認爲最該投入預算的地方，原因在於它可以近乎實時的細化到每一行執行代碼中，將生產中的性能情況曝露出來，這對持續的性能調優幫助非常大，比傳統的測試加線上日誌、監控來定位問題效率高很多倍。
日誌和統計監控，相信大家多多少少都有實踐，這裏我將分享愛範兒的一些實踐經驗。
從我們的實踐經驗來看，日誌用 AWS 的 Cloudwatch 比較划算，再結合自己寫的 Node Exporter，可以通過比較廉價的方式將幾年的日誌保存起來，並可以隨時檢索。
統計監控主要就是在用了 APM 的基礎上， 再根據自己的業務情況，對感興趣的流程環節加強統計和監控。比如電商業務，會對下單到派單關注比較多，因此需要增加更多維度的監控。一般是使用 Prometheus 和 Grafana 來做 TS 數據的上報存儲，再和其他系統聯動起來。
說到這兒，生產環節基本上就搞定了——給機器們按照定義好的規則，自動地進行線上的運維工作。實在處理不了的，通過 OnCall 和 Error Report 的方式讓工程師加入進來。
這裏具備一個基本的原則是，處理線上的事情，機器永遠可以做得比人快，比人精準。所以，這套流程，儘可能的讓機器更多地參與到執行上，工程師更多地參與到線上模式的觀察、規則的指定和數據流的編排中。
讓高迭代有高質量
說完生產，再說回研發。
上圖中，左邊這條研發線，歸根結底是爲了生產出一個可用於生產的安裝包（交付物）。恕我直言，當前大多數吹噓自己可以實現快速迭代的公司都是都是虛假繁榮的，這是爲什麼呢？
我們來算一筆賬，團隊日發佈 100 次，假設 2 個小組併發工作，並不間斷地工作 10 個小時，然而算下來每次發佈只有 12 分鐘。太多公司的主流程迴歸測試就沒有做到自動化了，這就變成測試工程師需要在 12 分鐘內完成一次迴歸，這幾乎不可能。以典型的電商產品爲例，從瀏覽商品到發貨主流程，100 個用例就算最少了，人工 1 個小時都比較困難。
因此，想要研發的效率提速，首先需要解決自動化測試，否則都是空談。
接下來，我將介紹下 CI 的部分。在嘗試了衆多 CI 之後，我們最終選用 Bamboo，主要原因有 2 個：
1、隨着項目規模變大，一次迭代產生的 CI 任務會快速增加，像現在我們的 SSO 模塊，一次提交，需要跑 20 個前端構建任務，這很容易導致繁忙的時間段，需要上百臺機器才能完成所有構建，不然就會排隊等待，影響開發效率。Bamboo 很好的整合了對 AWS 的 Spot Instance 支持，相當於引入了 AutoScale 到 CI 系統。可以很好地支撐高峯期的需求，同時又不用提高太多成本；
2、CI 是串聯項目系統、代碼庫、生產系統的中間環節，系統的數據連通性必須要好。Bamboo 能很好地打通這些系統的數據。
說回測試，單元測試和集成測試。單元測試的好處大家都清楚，或許大家多少也都經歷過。我們的一個模塊，測試到 10,000 個的規模後，單臺機基本上跑不動，花了點時間將測試框架改造成可支持跨機器的分佈式系統，這才讓單次的測試控制在 10 分鐘之內。然而這些都是必然會出現的代價，但能做還是要儘量做下去。
接下來，我將重點說說集成測試。
大家都知道自動化集成測試，但都不怎麼願意投入資源做自動化集成測試。
招測試工程師時，我發現基本上 90% 的工程師還在用 Excel 來管理測試用例，稍微好點的用 XMind。我認爲，這是非常離譜的，原因很簡單：測試用例和架構設計一樣，甚至測試用例會更加複雜，因爲它既是項目管理的一個環節，也是指導研發的一個環節。比如，之前所提到電商主流程中的 100 個用例，這個主流程一般怎麼操作呢？就是對 100 個用例進行篩選，將主線分支的用例歸到主流程組，然後對這些用例編寫測試腳本，運行中的測試腳本每一輪都會將測試結果同步到用例管理系統、項目管理系統。因此，測試用例必須用工程化的管理系統。
目前，愛範兒採用 Qmetry 和 Jira 來進行整個系統的搭建，測試腳本這塊，我們從 Selenium 換到了 Cypress，因爲它能更好地處理前端的 UI 集成。
測試環節上自動化，才能從本質上讓高速迭代成爲可能，真正地實現從寫完代碼到代碼進入生產發生在 10 分鐘內，並且還不用提心吊膽，擔心隨時出大事。
讓代碼腐化速度儘可能延緩
下面來重點說下我們正在推行的一個環節——設計文檔。
設計文檔是從工程師領取需求後，到工程師開始寫代碼之前，必須要完成的一件事情。和代碼交付一樣，該過程必須經過審批流程，這是爲了解決什麼問題呢？
原因得從根源說起，軟件工程脫胎自建築工程，架構師的英文 title 是 Architect，也就是建築師。所以今天特別榮幸能和各位“包工頭”歡聚一堂，但是軟件工程無法使用建築工程那套東西。以當前我們所在的會場爲例，從會場立項到竣工，工程藍圖基本上就那份，從來不用改，房子建好了找個隱祕的角落把圖紙封存，等下次房屋損壞再拿出來，這是不是很省事？但是軟件工程辦得到嗎？
現在的互聯網項目，就算項目立項時準備了非常詳實、完備的架構設計文檔，但是隻要這個項目在正常迭代，過了半年後，基本上除了核心的地方之外，其他地方的代碼和當初的架構設計一點關係都沒有了。我相信現場肯定有同學接手過老項目對吧，你們覺得痛苦嗎？今天，我們就可以知道痛苦的根源在哪裏了。
設計文檔，就是爲了解決這個問題而存在的，可以讓架構設計和需求迭代同步起來。
那麼設計文檔怎麼操作呢？我認爲，設計文檔系統的要求只有兩點：
1、實時協作，隨時可以評審、討論；
2、文檔有版本管理，像代碼庫一樣，方便隨時查看心路歷程。
我們一直在用 Google Docs 和 Confluence，最終歸檔在 Confluence。
現代組織的知識體系建設是打造可追溯的現場
設計文檔可以解決代碼腐化問題，但是組織依然會陷入混沌，隔段時間加入的新人還是會面臨各種不知道狀況的 moment。產生這個問題的根源主要在於，研發流程涉及到的崗位衆多，各崗位使用的系統不一樣，系統間不打通，很難對當時的現場進行回溯，從而無法弄清楚當時的情況，如果只是做 Wiki 的建設，那是遠遠不夠的。
Atlanssian 公司做得最好的一件事就是通過買的方式，將研發流程中的系統串聯起來。任何時候，你都可以通過一次代碼提交找到對應的任務、測試結果、需求說明和線上事故。
現代組織的協作方式最後，聊一下最重要的話題——協作。
剛纔我提到了流程的建設，但歸根結底，流程是服務於各個崗位的人。而我也相信，隨着這幾年即時通信領域的發展，基本上每個團隊都有非常好的在線溝通體驗。但是仍然有一個問題需要解決——流程中有那麼多機器，那麼人和機器的溝通都應該變得更加高效纔可以。
在這裏，我可以提供一種參考，在 Slack 上，可以將 CI 系統的測試通知、OnCall 系統的報警消息集成進來，比如在代碼審查羣組中，除了需要參加審查的工程師和若干個關鍵的系統之外，都會在這裏發生直接的交流，讓一個上下文 Context 容納更多的信息。
Slack 還支持配置一些 Actions，讓我們可以直接在 Slack 消息對機器的消息進行交互，比如確認一個 issue 等。
如果能順利完成一切，那麼整個流程就可以愉快的運作起來。最後，就只剩下如何對工作結果進行評估的問題了。
不得不說，時至今日，仍然有很多團隊在實行日報、週報等彙報方式。有時候，我都不得不深思：這究竟是人性的扭曲，還是道德的（敗壞）……
大家想一想，上述提到的那麼多系統和工具，都已經將工程師每天做什麼任務、花了多長時間，這個團隊本月完成了多少需求、上線了多少個版本都記錄得非常翔實，那麼爲何還要採用人工彙報的方式？
一般我會推薦通過數據化的工作進行結果評審，或許能更好的判定績效，同時能提供給員工更多一對一面談的對等交流機會，實現有效關照員工和組織成長。
這裏可能有同學會疑惑，這些花費的時間是怎麼統計的呢？難不成是工程師還得去一條條填寫？不存在的。上述中所提到的系統間的連通，就是爲了解決這些低效的人工處理數據同步的問題。我們通過每一次代碼提交的描述信息，即可完成任務關聯、工作時間的上報，甚至是開啓下一個流程。
最後總結下，核心思想就三點：
1、關注項目和組織的長期生長，關注各個消耗環節，通過流程和系統斧正效率；
2、最大程度發揮崗位的核心價值，工程師的核心價值是在給定的資源和問題下，交付最合理的解決方案，其他都是額外的負擔，這些額外的負擔儘可能用機器和流程去節省掉；
3、最大程度實踐公司的核心價值，不要輕易投入資源到這些內部系統的研發中，該花錢採購就採購，隨着規模變大，內部系統的代價會超出想象。幫公司賺更多的錢，買更好的系統纔是王道。
此次分享受限於時間，未盡之處還請諒解，期待後續更多的交流。去年，我在《極客時間技術領導力》專欄中寫了兩篇文章，更加聚焦在實踐層面，歡迎各位感興趣的朋友閱讀指正。
活動推薦
是不是不想錯過本年度最後一次技術管理者盛宴呢？
11 月 23 日，GTLC · 深圳站將正式拉開帷幕。現場有環球易購 CTO & 前蘇寧科技集團副總裁喬新亮、Lazada Group CTO 郭東白、Mobvista 集團副總裁 吳峯、TalentX Consulting 創始人兼 CEO Tina Jiang 等一批業界優秀的技術領導者，分享領先的技術管理思考與理念，幫助你成爲一名優秀的 CTO！
快快點擊「詳情」，享受優惠購票吧！
TGO鯤鵬會，是極客邦科技旗下高端技術人聚集和交流的組織，旨在組建全球最具影響力的科技領導者社交網絡，線上線下相結合，爲會員提供專享服務。目前，TGO鯤鵬會已在北京、上海、杭州、廣州、深圳、成都、硅谷、臺灣、南京、廈門、武漢、蘇州十二個城市設立分會。現在全球擁有在冊會員 800+ 名，60% 爲 CTO、技術 VP、技術合夥人。
會員覆蓋了 BATJ 等互聯網巨頭公司技術領導者，同時，阿里巴巴王堅博士、同程藝龍技術委員會主任張海龍、蘇寧易購 IT 總部執行副總裁喬新亮已經受邀，成爲 TGO 鯤鵬會榮譽導師。