編者注：查看何世友完整版 PPT，請(qǐng)?jiān)?TGO 鯤鵬會(huì)公眾號(hào)回復(fù)“GTLC 成都站”自動(dòng)獲取。

當(dāng)我們聊到 DevOps 和 CI/CD 時(shí)，都會(huì)被形容成流水線。今天，我以愛(ài)范兒團(tuán)隊(duì)的一個(gè)產(chǎn)品實(shí)際流程為例，畫(huà)了下圖：

上圖中需要注意的是，研發(fā)和生產(chǎn)可以完全獨(dú)立的兩個(gè)生命周期，接下來(lái)我將從生產(chǎn)說(shuō)起。

生產(chǎn)環(huán)節(jié)中的所有系統(tǒng)都只服務(wù)于一件事——不宕機(jī)。那么如何才能實(shí)現(xiàn)不宕機(jī)呢？隨時(shí)隨地快速部署，每一次 Scale 都是一次部署。

上圖中列了生產(chǎn)中的必要組成部分——日志系統(tǒng)、APM 探針?lè)?wù)、統(tǒng)計(jì)監(jiān)控服務(wù)、錯(cuò)誤上報(bào)服務(wù)、OnCall 報(bào)警服務(wù)以及 AutoScale 機(jī)制。他們的關(guān)系應(yīng)該是下圖：

上述這些子系統(tǒng)，歸根結(jié)底不是給人看的，而是給 AutoScale 機(jī)制看的，人永遠(yuǎn)沒(méi)有機(jī)器響應(yīng)得快。我們擅長(zhǎng)的是：發(fā)現(xiàn)規(guī)律，制定規(guī)則；機(jī)器擅長(zhǎng)的是執(zhí)行。因此，我們需要通過(guò)編排這些系統(tǒng)的數(shù)據(jù)流向，讓這個(gè)生命周期自己運(yùn)轉(zhuǎn)起來(lái)。

以 AWS 的 ASG 為例，一個(gè)自動(dòng)擴(kuò)縮容組主要包括：一個(gè) ELB 彈性負(fù)載均衡器、一組應(yīng)用服務(wù)器、一個(gè)部署機(jī)制以及一些擴(kuò)縮容規(guī)則，下圖就是一個(gè)典型的常用規(guī)則：ELB 的指定單位范圍內(nèi)的平均響應(yīng)時(shí)間超過(guò)一個(gè)閾值時(shí)，增加一些機(jī)器到服務(wù)器組。

自動(dòng)擴(kuò)縮容機(jī)制會(huì)隨時(shí)根據(jù)這些規(guī)則對(duì)數(shù)據(jù)進(jìn)行測(cè)算，滿足條件后則執(zhí)行響應(yīng)動(dòng)作。

如果規(guī)則很多，互相干擾怎么辦？增加 Cooling Down 機(jī)制就可以在一定程度上避免干擾，讓不同的規(guī)則可以互相輔助。

Scale 解決了，再來(lái)看看讓 Scale 可以工作的各個(gè)背后的系統(tǒng)。

APM 探針?lè)?wù)是我個(gè)人認(rèn)為最該投入預(yù)算的地方，原因在于它可以近乎實(shí)時(shí)的細(xì)化到每一行執(zhí)行代碼中，將生產(chǎn)中的性能情況曝露出來(lái)，這對(duì)持續(xù)的性能調(diào)優(yōu)幫助非常大，比傳統(tǒng)的測(cè)試加線上日志、監(jiān)控來(lái)定位問(wèn)題效率高很多倍。

日志和統(tǒng)計(jì)監(jiān)控，相信大家多多少少都有實(shí)踐，這里我將分享愛(ài)范兒的一些實(shí)踐經(jīng)驗(yàn)。

從我們的實(shí)踐經(jīng)驗(yàn)來(lái)看，日志用 AWS 的 Cloudwatch 比較劃算，再結(jié)合自己寫(xiě)的 Node Exporter，可以通過(guò)比較廉價(jià)的方式將幾年的日志保存起來(lái)，并可以隨時(shí)檢索。

統(tǒng)計(jì)監(jiān)控主要就是在用了 APM 的基礎(chǔ)上， 再根據(jù)自己的業(yè)務(wù)情況，對(duì)感興趣的流程環(huán)節(jié)加強(qiáng)統(tǒng)計(jì)和監(jiān)控。比如電商業(yè)務(wù)，會(huì)對(duì)下單到派單關(guān)注比較多，因此需要增加更多維度的監(jiān)控。一般是使用 Prometheus 和 Grafana 來(lái)做 TS 數(shù)據(jù)的上報(bào)存儲(chǔ)，再和其他系統(tǒng)聯(lián)動(dòng)起來(lái)。

說(shuō)到這兒，生產(chǎn)環(huán)節(jié)基本上就搞定了——給機(jī)器們按照定義好的規(guī)則，自動(dòng)地進(jìn)行線上的運(yùn)維工作。實(shí)在處理不了的，通過(guò) OnCall 和 Error Report 的方式讓工程師加入進(jìn)來(lái)。

這里具備一個(gè)基本的原則是，處理線上的事情，機(jī)器永遠(yuǎn)可以做得比人快，比人精準(zhǔn)。所以，這套流程，盡可能的讓機(jī)器更多地參與到執(zhí)行上，工程師更多地參與到線上模式的觀察、規(guī)則的指定和數(shù)據(jù)流的編排中。

說(shuō)完生產(chǎn)，再說(shuō)回研發(fā)。

上圖中，左邊這條研發(fā)線，歸根結(jié)底是為了生產(chǎn)出一個(gè)可用于生產(chǎn)的安裝包（交付物）。恕我直言，當(dāng)前大多數(shù)吹噓自己可以實(shí)現(xiàn)快速迭代的公司都是都是虛假繁榮的，這是為什么呢？

我們來(lái)算一筆賬，團(tuán)隊(duì)日發(fā)布 100 次，假設(shè) 2 個(gè)小組并發(fā)工作，并不間斷地工作 10 個(gè)小時(shí)，然而算下來(lái)每次發(fā)布只有 12 分鐘。太多公司的主流程回歸測(cè)試就沒(méi)有做到自動(dòng)化了，這就變成測(cè)試工程師需要在 12 分鐘內(nèi)完成一次回歸，這幾乎不可能。以典型的電商產(chǎn)品為例，從瀏覽商品到發(fā)貨主流程，100 個(gè)用例就算最少了，人工 1 個(gè)小時(shí)都比較困難。

因此，想要研發(fā)的效率提速，首先需要解決自動(dòng)化測(cè)試，否則都是空談。

接下來(lái)，我將介紹下 CI 的部分。在嘗試了眾多 CI 之后，我們最終選用 Bamboo，主要原因有 2 個(gè)：

1、隨著項(xiàng)目規(guī)模變大，一次迭代產(chǎn)生的 CI 任務(wù)會(huì)快速增加，像現(xiàn)在我們的 SSO 模塊，一次提交，需要跑 20 個(gè)前端構(gòu)建任務(wù)，這很容易導(dǎo)致繁忙的時(shí)間段，需要上百臺(tái)機(jī)器才能完成所有構(gòu)建，不然就會(huì)排隊(duì)等待，影響開(kāi)發(fā)效率。Bamboo 很好的整合了對(duì) AWS 的 Spot Instance 支持，相當(dāng)于引入了 AutoScale 到 CI 系統(tǒng)。可以很好地支撐高峰期的需求，同時(shí)又不用提高太多成本；

2、CI 是串聯(lián)項(xiàng)目系統(tǒng)、代碼庫(kù)、生產(chǎn)系統(tǒng)的中間環(huán)節(jié)，系統(tǒng)的數(shù)據(jù)連通性必須要好。Bamboo 能很好地打通這些系統(tǒng)的數(shù)據(jù)。

說(shuō)回測(cè)試，單元測(cè)試和集成測(cè)試。單元測(cè)試的好處大家都清楚，或許大家多少也都經(jīng)歷過(guò)。我們的一個(gè)模塊，測(cè)試到 10,000 個(gè)的規(guī)模后，單臺(tái)機(jī)基本上跑不動(dòng)，花了點(diǎn)時(shí)間將測(cè)試框架改造成可支持跨機(jī)器的分布式系統(tǒng)，這才讓單次的測(cè)試控制在 10 分鐘之內(nèi)。然而這些都是必然會(huì)出現(xiàn)的代價(jià)，但能做還是要盡量做下去。

接下來(lái)，我將重點(diǎn)說(shuō)說(shuō)集成測(cè)試。

大家都知道自動(dòng)化集成測(cè)試，但都不怎么愿意投入資源做自動(dòng)化集成測(cè)試。

招測(cè)試工程師時(shí)，我發(fā)現(xiàn)基本上 90% 的工程師還在用 Excel 來(lái)管理測(cè)試用例，稍微好點(diǎn)的用 XMind。我認(rèn)為，這是非常離譜的，原因很簡(jiǎn)單：測(cè)試用例和架構(gòu)設(shè)計(jì)一樣，甚至測(cè)試用例會(huì)更加復(fù)雜，因?yàn)樗仁琼?xiàng)目管理的一個(gè)環(huán)節(jié)，也是指導(dǎo)研發(fā)的一個(gè)環(huán)節(jié)。比如，之前所提到電商主流程中的 100 個(gè)用例，這個(gè)主流程一般怎么操作呢？就是對(duì) 100 個(gè)用例進(jìn)行篩選，將主線分支的用例歸到主流程組，然后對(duì)這些用例編寫(xiě)測(cè)試腳本，運(yùn)行中的測(cè)試腳本每一輪都會(huì)將測(cè)試結(jié)果同步到用例管理系統(tǒng)、項(xiàng)目管理系統(tǒng)。因此，測(cè)試用例必須用工程化的管理系統(tǒng)。

目前，愛(ài)范兒采用 Qmetry 和 Jira 來(lái)進(jìn)行整個(gè)系統(tǒng)的搭建，測(cè)試腳本這塊，我們從 Selenium 換到了 Cypress，因?yàn)樗芨玫靥幚砬岸说?UI 集成。

測(cè)試環(huán)節(jié)上自動(dòng)化，才能從本質(zhì)上讓高速迭代成為可能，真正地實(shí)現(xiàn)從寫(xiě)完代碼到代碼進(jìn)入生產(chǎn)發(fā)生在 10 分鐘內(nèi)，并且還不用提心吊膽，擔(dān)心隨時(shí)出大事。

下面來(lái)重點(diǎn)說(shuō)下我們正在推行的一個(gè)環(huán)節(jié)——設(shè)計(jì)文檔。

設(shè)計(jì)文檔是從工程師領(lǐng)取需求后，到工程師開(kāi)始寫(xiě)代碼之前，必須要完成的一件事情。和代碼交付一樣，該過(guò)程必須經(jīng)過(guò)審批流程，這是為了解決什么問(wèn)題呢？

原因得從根源說(shuō)起，軟件工程脫胎自建筑工程，架構(gòu)師的英文 title 是 Architect，也就是建筑師。所以今天特別榮幸能和各位“包工頭”歡聚一堂，但是軟件工程無(wú)法使用建筑工程那套東西。以當(dāng)前我們所在的會(huì)場(chǎng)為例，從會(huì)場(chǎng)立項(xiàng)到竣工，工程藍(lán)圖基本上就那份，從來(lái)不用改，房子建好了找個(gè)隱秘的角落把圖紙封存，等下次房屋損壞再拿出來(lái)，這是不是很省事？但是軟件工程辦得到嗎？

現(xiàn)在的互聯(lián)網(wǎng)項(xiàng)目，就算項(xiàng)目立項(xiàng)時(shí)準(zhǔn)備了非常詳實(shí)、完備的架構(gòu)設(shè)計(jì)文檔，但是只要這個(gè)項(xiàng)目在正常迭代，過(guò)了半年后，基本上除了核心的地方之外，其他地方的代碼和當(dāng)初的架構(gòu)設(shè)計(jì)一點(diǎn)關(guān)系都沒(méi)有了。我相信現(xiàn)場(chǎng)肯定有同學(xué)接手過(guò)老項(xiàng)目對(duì)吧，你們覺(jué)得痛苦嗎？今天，我們就可以知道痛苦的根源在哪里了。

設(shè)計(jì)文檔，就是為了解決這個(gè)問(wèn)題而存在的，可以讓架構(gòu)設(shè)計(jì)和需求迭代同步起來(lái)。

那么設(shè)計(jì)文檔怎么操作呢？我認(rèn)為，設(shè)計(jì)文檔系統(tǒng)的要求只有兩點(diǎn)：

1、實(shí)時(shí)協(xié)作，隨時(shí)可以評(píng)審、討論；

2、文檔有版本管理，像代碼庫(kù)一樣，方便隨時(shí)查看心路歷程。

我們一直在用 Google Docs 和 Confluence，最終歸檔在 Confluence。

設(shè)計(jì)文檔可以解決代碼腐化問(wèn)題，但是組織依然會(huì)陷入混沌，隔段時(shí)間加入的新人還是會(huì)面臨各種不知道狀況的 moment。產(chǎn)生這個(gè)問(wèn)題的根源主要在于，研發(fā)流程涉及到的崗位眾多，各崗位使用的系統(tǒng)不一樣，系統(tǒng)間不打通，很難對(duì)當(dāng)時(shí)的現(xiàn)場(chǎng)進(jìn)行回溯，從而無(wú)法弄清楚當(dāng)時(shí)的情況，如果只是做 Wiki 的建設(shè)，那是遠(yuǎn)遠(yuǎn)不夠的。

Atlanssian 公司做得最好的一件事就是通過(guò)買(mǎi)的方式，將研發(fā)流程中的系統(tǒng)串聯(lián)起來(lái)。任何時(shí)候，你都可以通過(guò)一次代碼提交找到對(duì)應(yīng)的任務(wù)、測(cè)試結(jié)果、需求說(shuō)明和線上事故。

最后，聊一下最重要的話題——協(xié)作。

剛才我提到了流程的建設(shè)，但歸根結(jié)底，流程是服務(wù)于各個(gè)崗位的人。而我也相信，隨著這幾年即時(shí)通信領(lǐng)域的發(fā)展，基本上每個(gè)團(tuán)隊(duì)都有非常好的在線溝通體驗(yàn)。但是仍然有一個(gè)問(wèn)題需要解決——流程中有那么多機(jī)器，那么人和機(jī)器的溝通都應(yīng)該變得更加高效才可以。

在這里，我可以提供一種參考，在 Slack 上，可以將 CI 系統(tǒng)的測(cè)試通知、OnCall 系統(tǒng)的報(bào)警消息集成進(jìn)來(lái)，比如在代碼審查群組中，除了需要參加審查的工程師和若干個(gè)關(guān)鍵的系統(tǒng)之外，都會(huì)在這里發(fā)生直接的交流，讓一個(gè)上下文 Context 容納更多的信息。

Slack 還支持配置一些 Actions，讓我們可以直接在 Slack 消息對(duì)機(jī)器的消息進(jìn)行交互，比如確認(rèn)一個(gè) issue 等。

如果能順利完成一切，那么整個(gè)流程就可以愉快的運(yùn)作起來(lái)。最后，就只剩下如何對(duì)工作結(jié)果進(jìn)行評(píng)估的問(wèn)題了。

不得不說(shuō)，時(shí)至今日，仍然有很多團(tuán)隊(duì)在實(shí)行日?qǐng)?bào)、周報(bào)等匯報(bào)方式。有時(shí)候，我都不得不深思：這究竟是人性的扭曲，還是道德的（敗壞）……

大家想一想，上述提到的那么多系統(tǒng)和工具，都已經(jīng)將工程師每天做什么任務(wù)、花了多長(zhǎng)時(shí)間，這個(gè)團(tuán)隊(duì)本月完成了多少需求、上線了多少個(gè)版本都記錄得非常翔實(shí)，那么為何還要采用人工匯報(bào)的方式？

一般我會(huì)推薦通過(guò)數(shù)據(jù)化的工作進(jìn)行結(jié)果評(píng)審，或許能更好的判定績(jī)效，同時(shí)能提供給員工更多一對(duì)一面談的對(duì)等交流機(jī)會(huì)，實(shí)現(xiàn)有效關(guān)照員工和組織成長(zhǎng)。

這里可能有同學(xué)會(huì)疑惑，這些花費(fèi)的時(shí)間是怎么統(tǒng)計(jì)的呢？難不成是工程師還得去一條條填寫(xiě)？不存在的。上述中所提到的系統(tǒng)間的連通，就是為了解決這些低效的人工處理數(shù)據(jù)同步的問(wèn)題。我們通過(guò)每一次代碼提交的描述信息，即可完成任務(wù)關(guān)聯(lián)、工作時(shí)間的上報(bào)，甚至是開(kāi)啟下一個(gè)流程。

最后總結(jié)下，核心思想就三點(diǎn)：

1、關(guān)注項(xiàng)目和組織的長(zhǎng)期生長(zhǎng)，關(guān)注各個(gè)消耗環(huán)節(jié)，通過(guò)流程和系統(tǒng)斧正效率；

2、最大程度發(fā)揮崗位的核心價(jià)值，工程師的核心價(jià)值是在給定的資源和問(wèn)題下，交付最合理的解決方案，其他都是額外的負(fù)擔(dān)，這些額外的負(fù)擔(dān)盡可能用機(jī)器和流程去節(jié)省掉；

3、最大程度實(shí)踐公司的核心價(jià)值，不要輕易投入資源到這些內(nèi)部系統(tǒng)的研發(fā)中，該花錢(qián)采購(gòu)就采購(gòu)，隨著規(guī)模變大，內(nèi)部系統(tǒng)的代價(jià)會(huì)超出想象。幫公司賺更多的錢(qián)，買(mǎi)更好的系統(tǒng)才是王道。

此次分享受限于時(shí)間，未盡之處還請(qǐng)諒解，期待后續(xù)更多的交流。去年，我在《極客時(shí)間技術(shù)領(lǐng)導(dǎo)力》專欄中寫(xiě)了兩篇文章，更加聚焦在實(shí)踐層面，歡迎各位感興趣的朋友閱讀指正。