Categories
程式開發

紅燈區:DevOps 建設的思考和實踐


背景

眾所周知,在豐田精益生產中,核心觀念包含對人的尊重、消除浪費、持續改善,只有這樣,企業才能保持良性運轉,競爭力才會提升。而具體的浪費場景,被總結為「製造過剩、等待、搬運、庫存、加工、額外動作、次品」七種,後來又增加了「管理」的浪費。

筆者所在效能改進團隊,一直致力於精益的實踐,從降本增效的角度,來提升有贊軟件研發的效能,以應對這個充滿不確定性時代的變化的衝擊。而彼時的軟件研發,從過程管理的角度,已將「項目制」普及到團隊之中並持續發揮作用,但從工程實踐的角度,雖然各部門都有一些基礎設施,但僅為本部門服務,整體處於萌芽階段,需要有一條主線將各獨立的孤島串接起來,發揮協同的價值。

一、工程實踐的現狀

1.1 技術債

有贊作為一家初創公司,首要任務是在市場競爭中活下來,所以在技術沉澱方面,於某段時期內處於被動局面,由業務裹挾著往前狂奔,是可以理解的,而且是必須經歷的。但可以預見的是,長此以往,就會積累大量的技術債,而且會隨著系統複雜度的上升,技術債所帶來的研發成本會快速增加,直到它變成一堆無人敢碰的遺留功能。

從精益浪費的視角看,處理技術債就是一種「額外動作」,它是每次研發中一項繞不開的工作,但除了耗費大量人力物力和時間之外,並不產生任何價值。我們亟需掌握目前有多少技術債、風險如何、處理成本如何、在多少量級的範圍裡是合理和可控的。下圖是有贊在 DevOps 建設過程中,某個應用通過 SonarQube 靜態掃描得到的代碼質量情況:

紅燈區:DevOps 建設的思考和實踐 1

1.2 代碼改動的影響

我們常說:輸入的是垃圾,輸出的也一定是垃圾( garbage in, garbage out )。在充滿技術債和沒有任何保護措施的代碼上做增量開發,就好比行走在沼澤中,隨時會出現意外。也許有代碼註釋來幫助你理解歷史遺留業務,但經過多人之手增補過的代碼文件,註釋可能比代碼更冗長。

在這樣的技術環境中工作,很容易產生「次品」,也許大部分問題都能在上線前被撲滅,但流到線上就很可能成為故障,甚至成為未來新代碼的故障源。下圖是 DevOps 的佈道之作《鳳凰項目》的封面,就呈現了這樣一番觸目驚心的景象:

紅燈區:DevOps 建設的思考和實踐 2

1.3 集成周期

由於研發是一項需要多方協同的工作,而各方的產出成果非常明確:符合產品功能和質量預期的代碼。關於這個結果,在研發前期籌備時,各方按產品功能點目標進行任務分解時,就已經註定了的。既然是為了共同的產品目標,大家齊頭並進,分別進行研發生產後,就必然要將成果匯合到一起,以產生協同創新的價值。我們通常詬病瀑布項目模式最致命的缺陷之一,就是每個人開髮質量都很高,但大規模集成時就一塌糊塗。

所以,研發人員需要不斷嘗試與上下游進行集成,而集成又涉及到代碼的編譯運行,每次集成都是一場等待,對項目來說也是一次煎熬,時間進度難以控制,故精益認為這是一種「等待」的浪費。儘管我們在項目流程中定義了「接口先行」的管理動作,但在實際編碼過程中,還是會隨著對需求產生進一步理解和澄清後,研發人員隨手變動接口(但沒有及時通知上下游)的情況。下圖是有贊 DevOps 平台關於某一應用的時效情況:

紅燈區:DevOps 建設的思考和實踐 3

二、效能改進的切入點

2.1 理念導入

萬事開頭難。雖然研發團隊對在業界如日中天的「開發運維」已有一定的認知,但重點關注放在工具的運用上,目的是提升本團隊的工作效率。而經過一系列嘗試後,大家已經隱約意識到,「持續集成」才是在頻繁交付的壓力下提升研發效率的高槓桿點,而「規範單測」和「環境治理」是保障持續集成的前提,於是效能改進團隊攜手研發團隊、質量保障團隊和運維團隊共同商議決定,將這兩項工作進行深入宣貫。思考路徑如下:

1)如果有足夠覆蓋率的高質量單測用例,就能保護業務代碼的邏輯,在不增加額外測試成本的情況下,經得起任何變更和調整;

2)如果有健康穩定的測試環境,代碼就能在被提交到代碼倉庫後,自動觸發執行靜態代碼檢查和單測用例,快速驗證新增代碼的正確性和健康度,經得起頻繁交付下質量保證的考驗;

3)基於單測用例,可以根據業務場景組合形成集成用例,在健康穩定的測試環境下,無人值守地持續進行集成,自動觸發打包和部署,並驗證業務邏輯,甚至發布上線(一般實踐是發佈到預發環境),降低發布週期,提高發布頻率。

紅燈區:DevOps 建設的思考和實踐 4

2.2 志願試點

如果能找到一支願意參與試點的小組,再讓受益者向其他同行們分享改進成果,是一種不錯的實踐,這比我們僅僅通過理論說教更能讓人信服。彼時,有贊效能改進團隊在調研過程中,與 U 小組溝通比較通暢,其技術組長也非常認同基於頻繁交付的敏捷開發方法,這為我們推廣單測實踐找到了突破口。

此外, S 小組的 G 君和 Z 小組的 C 君是研發人員中的極客用戶,積極參與並沉澱了關於如何寫好單測的最佳實踐,非常樂於向同事們進行分享。於是,我們把握住機會,在推廣單測必要性和期望達成目標的基礎上,連續組織了好幾場技術分享,使其餘技術人員快速掌握了單測編寫的方法,將單測改進工作迅速得以推廣和落實。下圖是分享材料的截取內容:

紅燈區:DevOps 建設的思考和實踐 5

2.3 側翼助攻

從開發到上線的整個過程中,存在著三類角色:研發、質量保障、運維。隨著業界在自動化測試和自動化運維領域的不斷成熟,有讚的質量保障和運維團隊深知其價值,故在DevOps 領域的研究和實踐中一直走在行業前沿,並在落地推廣過程中長期保持積極狀態,充當了急先鋒的作用。一方面,質量保障團隊與開發約定,提測時必須保證單測覆蓋率,否則就退回拒測;另一方面,運維加強環境治理,規範了「Dev 環境」「QA 環境」「Pre 環境」的使用姿勢和工作台能力。多點共同發力,提高了技術團隊提升單測能力的主動性。下圖是某業務線單測覆蓋率達標應用的增長情況:

紅燈區:DevOps 建設的思考和實踐 6

2.4 工具支持

除了規範行為之外,在管理工具上也提供了不少配套功能。有讚的研發過程用自研的「起碼效能平台」進行管理,為方便開發人員的使用,故增加了與DevOps 平台聯動的快捷通道,可一鍵生成配套的環境、支持兩邊系統狀態同步、自動化執行結果如未達到閾值就限制進入下一環節、等等。下圖是有贊 DevOps 平台的持續交付流水線功能局部:

紅燈區:DevOps 建設的思考和實踐 7

2.5 氛圍打造

為幫助技術團隊提升對工程實踐的感知度,效能改進團隊也做了很多有趣好玩的周邊:

1)CI ( Continue Intergrate ,持續集成)指示燈。我們用樹莓派和LED 燈搭建了一套告警裝置,樹莓派通過網絡連接了DevOps 平台,當訂閱的應用在DevOps 平台上運行失敗(一般是單元測試執行失敗、集成測試執行失敗、覆蓋率未達標等場景下)時,對應的樹莓派就收到信息,並觸發紅燈閃爍,提醒應用的管理員及時關注,敦促本團隊中的代碼提交者盡快修復。效果如下圖:

紅燈區:DevOps 建設的思考和實踐 8

插曲:偶爾也會有開發同事晚上回家後連入公司VPN 進行遠程辦公,此時辦公室現場早已熄燈關門,如果該同事的代碼提交到倉庫,觸發DevOps 單測用例執行失敗時,就會看到如下圖的詭異畫面(有一次差點嚇壞了我們的HR 妹子):

紅燈區:DevOps 建設的思考和實踐 9

2)CI 大屏。公司有幾套閒置不用的觸摸屏,原來是地推時放在商場裡用作廣告宣傳的,被我們搬出來舊物利用,連上公司網絡,安置在辦公區域,用來展示各大應用在DevOps 平台上的狀態。一方面,對已經接入 DevOps 平台應用的開發人員來說,是一種提醒和相互競爭;另一方面,對尚未接觸 DevOps 的開發人員來說,也起到了一種廣告示範的效果。下圖是大屏的數據展示:

紅燈區:DevOps 建設的思考和實踐 10

插曲:由於經常會有客戶來公司訪問,所以走過路過的,也偶爾會被駐足觀看,行政部後來也索性就把它定位成帶領客戶遊覽的必經「景點」之一了。下圖是有贊工作人員在向客戶介紹大屏展示的內容:

紅燈區:DevOps 建設的思考和實踐 11

小結

正如前文提及的,有贊效能改進團隊並不是一個人在戰鬥,質量保障團隊和運維團隊也在其擅長的領域,為推動工程實踐的落地發揮著積極的作用,與此同時,開發團隊自己也在努力突破舒適區。正所謂:

開發運維心所繫,單測保障護我體。
三套環境在治理,紅燈照亮贏契機。

從精益的角度看,強化工程實踐的能力,能減少浪費並大幅度提升研發效率,是值得投入和加以改善的。而回顧有讚的落地過程,一方面要做宣傳和理念導入(最好能藉助志願者和試點團隊的力量和標杆示範作用),另一方面在工具層面加以強化,使之成為一項無法迴避的功能,進而強化肌肉記憶,再配合CI 指示燈、大屏等實踐,讓理念植入研發人員的內心,有了一種更有儀式感的傳播。

本文轉載自公眾號有贊coder(ID:youzan_coder)。

原文鏈接

https://mp.weixin.qq.com/s?__biz=MzAxOTY5MDMxNA==&mid=2455760408&idx=1&sn=c5d442552ab87748dc4793484f324747&chksm=8c68683dbb1fe12bd2fd5ca20f38f7893e3fecc4c2b3b0027dfb1d4f68271dbce90144e8abcf&scene=27#wechat_redirect