開發與維運

構建前端安全生產體系,給前端同學「穩穩」的幸福

作者:戊子

image.png

始於十八世紀中期的工業革命至今催生了傳統工業的數百年繁榮,安全生產便是一個在傳統工業領域提的比較多的概念,在傳統的生產、製造、建築行業,我們隨處可見安全生產相關的口號。近二十年來,伴隨互聯網行業的高速發展,互聯網已成為一個國家重要的基礎設施,出自基礎設施的任何一個故障,都可能對國計民生產生重大的影響。回到國內大型互聯網公司的內部,以阿里集團為例,2018年以來,集團內部高危故障頻發,穩定性形勢嚴峻,於是集團成立了安全生產委員會,一是運用技術手段提升能力,控制風險,保障業務穩定;二是明確行為準則,用機制保護人,減少犯錯,降低損失;三是打造安全生產文化,確保人人重視、有持續性的提升。而這便是互聯網行業安全生產的由來。

什麼是前端安全生產?

而最近⼗年來,隨著前端專業化分⼯的誕⽣、前端專業技術的發展,前端研發在整個互聯⽹ Web 應⽤研發⼯程鏈路上扮演著越來越重要的⻆⾊,前端安全⽣產的責任也隨之放⼤,在前端應⽤開發、發佈、線上運⾏的不同階段,如何讓前端⼯程師產出的代碼更加靠譜,不帶著問題發佈,即便在線上發現前端故障後也能及時⽌⾎?這便是“前端安全⽣產”需要解決的問題。

今天我們所討論的“前端安全⽣產”不同於傳統的“前端安全”這個領域,前端安全關注前端領域的線上安全攻防問題,⽽“前端安全⽣產”的定義顯然更⼤,“前端安全⽣產”專注於前端研發全鏈路的⾼質量交付,當然,也包含不要帶著“前端安全”問題去交付。

討論到這⾥,我們也有了“前端安全⽣產”的⼀個基本定義。“前端安全⽣產”專注於前端研發全鏈路的⾼質量交付,在前端應⽤開發、發佈、線上運⾏三個關鍵階段,通過⼀系列的⾃動化流程機制,控制前端代碼⻛險,保障線上業務運⾏穩定,⽤機制保護⼈,不給前端同學引發線上故障的犯錯機會,最終規避損失或者降低損失。

前端安全生產大圖

「善除害者察其本,善理疾者絕其源」,回顧過去歷史上的重⼤故障,以及盤點過去的故障列表,我們發現絕⼤部分故障都是由變更引起的,前端安全⽣產也不例外,也是從觸發故障的源頭變更流程開始切⼊。在前端版本變更前、變更中、變更後,我們通過⼀系列的措施去提升前端代碼質量、控制發佈⻛險、及時發現問題。這其中的關鍵過程包含:

  • 前端版本變更前:靜態代碼掃描、⾃定義⼯程規範校驗、單元測試 ;
  • 前端版本變更中:UI迴歸測試、迭代變更⻛險評估、灰度監控報告;
  • 前端版本變更後:1 分鐘發現問題、5 分鐘定位問題、10 分鐘修復問題。

image.png

從上圖可以發現,前端安全⽣產並⾮⼀個全新的領域,更多的是組合現有的分散在不同系統的能⼒,包括前端⼯程體系、前端 CI/CD 系統、前端測試系統、前端監控系統,讓我們更體系化保障前端研發全鏈路的⾼質量交付。

前端安全體系的建設

三個發展階段

整個前端安全⽣產體系的建設在我們部⻔內部⼤致分為三個階段,⽽直到第三個階段,我們才真正意義上完成了整個體系的 1.0 建設。這三個階段分別是:單點安全⽣產保障、多煙囪獨⽴安全⽣產保障、體系化的前端安全⽣產保障。

單點安全生產保障階段:線上前端監控

2015 年 8 ⽉,我們啟動了前端監控系統 retcode 的建設,通過線上實時監控⻚⾯訪問速度、JS Error、API 成功率核⼼的三板斧能⼒,為前端應⽤的運⾏態穩定性保駕護航。2016 年底, retcode 成⻓為阿⾥集團內部使⽤最⼴泛的前端監控產品,這個階段內,我們核⼼還是依靠線上前端監控的單點能⼒去保障前端的安全⽣產。為了持續修煉前端監控產品的核⼼能⼒,在 2017 年中我們啟動了 retcode 的上雲計劃,進⼊前端安全⽣產建設的第⼆個階段。

多煙囪獨立安全⽣產保障階段:雲化前端監控+其他保障

2017 年 9 ⽉,retcode 升級為阿⾥雲 ARMS 前端監控,開啟全⽹公測。在直⾯⾏業競爭對⼿的同時,我們的多項核⼼能⼒得到極⼤提升,這其中包括⾯向全球化業務的國際極致性能、JS Error 出錯時⽤戶⾏為回溯、API 接⼝快照以及打通前後端的全鏈路追蹤等等,前端監控平臺也經歷了從“錯誤數據展示”到“專家級問題診斷”的升級,整個平臺每天處理的⽇志條數也超過了百億級別。

image.png

這個階段內,除了前端監控平臺在阿⾥雲上的產品能⼒升級助⼒前端安全⽣產,在我們部⻔內部,也開始藉助⼀系列其他的能⼒來保障前端安全⽣產,如靜態代碼掃描、TDD、UI ⾃動化迴歸等,這些可以保障前端安全⽣產的單點能⼒越來越多,但是⼤多是獨⽴煙囪服務模式,各個保障流程節點之間並未完全打通。

在阿⾥集團內部,也缺乏⼀套集團層⾯體系化的前端灰度發佈流程,表現在前端發佈與後端上線存在流程割裂、後端灰度發佈時前端⽆感、整個應⽤灰度階段⼤多是⼈⾁前端驗證或者驗證缺失。

體系化的前端安全⽣產保障階段:前端安全⽣產從0到1

為了解決前端安全⽣產各個保障節點的孤島問題,同時結合集團後端正在⼤⼒推進安全⽣產的時機,前端安全⽣產的體系化建設也應運⽽⽣。當前我們部⻔整個前端安全⽣產體系剛剛完成從 0 到 1,正在電商核⼼的基礎交易鏈路、⼤促穩定性保障、業務穩定性基線⽇常治理等項⽬中落地。

舉⼀個實際的場景例⼦,阿⾥歷年雙 11 穩定性保障依賴的最核⼼能⼒之⼀便是全鏈路壓測和驗收。我們都知道全鏈路壓測重點關注 API 級別的穩定性,在全鏈路壓測過程中 API 上的各種異常表現,並不能體現到前端 UI 層⾯上,這個時候前端同學並不清楚後端 API 異常和降級後,前端 UI 層⾯的表現是否符合預期。藉助前端 UI ⾃動化迴歸測試,我們將交易核⼼鏈路上的核⼼功能全部增加了測試⽤例,在後端開啟全鏈路壓測時候,前端同時開啟迴歸測試,便形成了前端的全鏈路壓測和驗收。進⽽,我們會藉助前端安全⽣產體系打造的前端變更時卡⼝能⼒,在每次前端⽇常變更時⾃動觸發前端迴歸測試,降低核⼼交易鏈路上每次前端版本變更的⻛險。

核心能力

通過前⾯的介紹我們已經可以瞭解到,構建⼀個完整的前端安全⽣產體系需要三項核⼼能⼒。

變更發生前 CI 卡口能力

靜態代碼掃描、⾃定義⼯程規範校驗、單元測試通過率&覆蓋率均是通過插件能⼒安裝到 CI 卡⼝上,這⾥可以根據實際業務場景下的痛點問題擴展更多的插件能⼒,在前端同學每次代碼提交後都能及時給予反饋, ⽽不⽤將問題拖到測試或者預發甚⾄是線上環境。

變更過程中的灰度卡口能力

UI 迴歸測試、前端迭代變更⻛險評估、灰度監控報告也是作為插件能⼒安裝到了灰度發佈卡⼝上,這⾥同樣也是可以根據實際業務場景下的痛點問題擴展更多的插件能⼒,在前端同學每次版本發佈前都能及時給予反饋,遇到異常問題時直接中斷髮布過程。

image.png

根據安全⼯程學上的海恩法則“每⼀起嚴重事故的背後,必然有 29 次輕微事故和 300 起未遂先兆以及 1000 起事故隱患”,我們在變更發⽣前的 CI 卡⼝、變更過程中的灰度卡⼝都是為了杜絕⼀切可能引發線上故障的潛在因素,不帶著有問題的版本上線。

變更完成後的線上實時監控能力

線上實時監控是最後⼀個⾮常重要的能⼒,⼀個強⼤的監控系統能夠幫忙我們 1 分鐘發現問題和 5 分鐘定位問題根因,為我們 10 分鐘快速修復問題也就是快速回滾提供決策依據。根據安全⼯程學上的瑞⼠奶酪模型,“故障的發⽣是各種防禦⾏為失效的累計效應”。在變更發⽣前 CI 卡⼝能⼒和變更過程中的灰度卡⼝能⼒全部都失效後,線上監控是我們的最後⼀道防線,能夠幫我們有效的扼制故障範圍進⼀步擴⼤,降低損失。

image.png
(圖片來源網絡)

除了上⾯提到的技術⼿段,安全⽣產的⾏為準則和⽂化同樣必不可少,如制定變更紅線規約、安全⽣產專題分享等等。細⼼的讀者可能已經發現,GMTC深圳2019 的專題“前端測試”在今年已經升級為“前端安全⽣產”,也是想傳遞⼀個信號,我們正在經歷從過去被動的由測試同學主導的前端測試⾛向前端同學⼈⼈有責的主動前端安全⽣產保障時代,⽽過去的測試同學也升級為了測試研發同學,正在給我們的前端安全⽣產體系提供強⼤的插件能⼒。

三個最強擴展

基於CI卡口、灰度卡口、線上監控三項核心能力,本年度我們重點打造了三個最強擴展能力,主要涉及前端迭代變更⻛險評估、前端灰度監控報告以及 5 分鐘快速定位問題。

前端迭代變更⻛險評估

在迴歸測試階段,我們需要明確知道本次前端版本迭代所造成的影響點,以供開發同學⾃測或者是測試同學重點回歸相應部分,⽆論是⼈⾁測試,還是⾃動化迴歸,到很依賴這個關鍵信息。另外⼀種常⻅的場景是,前端代碼本身沒做任何改動,但是由於依賴的⼆⽅/三⽅包⾃動升級,導致某些場景出現⽆法預料的問題。這些都是因為前端迭代影響點⾃⾏評估不全⾯可能觸發故障的典型場景。為了解決前端迭代中⽆法準確給出迴歸點的問題,我們提供了迭代影響點評估⼯具,重點提供以下能⼒:

  • 開發同學明確本次迭代相對於上⼀次迭代的顯示&隱式變更;
  • 開發同學明確哪些項⽬⽂件將會受到所有這些變更的影響,並且能夠看到具體的影響路徑;
  • 開發/測試同學能夠看到更加全⾯、有理有據的迴歸功能點。

image.png

前端灰度監控報告

前端灰度監控的核⼼⽬的是讓前端灰度發佈的結果有據可依。在灰度發佈期間,監控會重點關注前端灰度環境和線上環境對⽐後⻚⾯訪問速度變化、JS 錯誤率變化、新出現的 JS 異常以及 API 成功率變化,⾃動⽣成灰度監控報告,同時也會通過灰度流量⻚⾯覆蓋率、API 覆蓋率來判定是否需要延⻓灰度時⻓或加⼤灰度流量⽐例。

image.png
image.png

應⽤全鏈路的 5 分鐘快速定位問題

通過前端⽣成 traceId 並透傳到後端業務調⽤鏈路的⽅式,打通應⽤從前端到後端全鏈路問題追蹤,從前端發現的 API 錯誤問題,可以通過 traceId 關聯直達後端監控系統,⼤幅減少涉及到應⽤全鏈路的問題定位時間,⾄此前端同學發現 API 相關問題後不再“甩鍋”到後端,⽽是給後端同學提供診斷問題的有效線索。

image.png

展望未來

當互聯⽹已成為⼀個國家重要的基礎設施,傳統⾏業正身處企業數字化轉型浪潮之中,互聯⽹安全⽣產必將越來越重要,⽽置身其中的前端安全⽣產也肯定會越來越受⼤家重視。從筆者的⻆度看到的前端安全⽣產未來將會由如下⼏個衍變趨勢。

  • 前後端聯動的應用研發全鏈路安全生產;
  • 借力 Cloud IDE 普及後自動集成的前端安全生產能力受益;
  • 前端安全生產自動化免測版本比例提升帶來的效率提升和成本下降;
  • 從提供錯誤信息到更智能的專家級診斷、主動風險預警、故障自動恢復。

還是那句話,前端安全⽣產並⾮⼀個全新的領域,讓我們⽤更體系化的系統,去控制⻛險並保障業務穩定, 同時讓每個⼈都更加重視前端安全⽣產,⽤機制保護⼈,不給前端同學引發線上故障的犯錯機會,最終規避損失,讓每個前端程序員都能愉快地發佈!


image.png
關注「Alibaba F2E」
把握阿里巴巴前端新動向

Leave a Reply

Your email address will not be published. Required fields are marked *