隨着前端技術的發展，加上前端代碼主要運行在客戶設備上的特性，導致前端穩定性問題層出不窮，稍有不慎就可能會給用戶帶來巨大損失。我們如何系統化地搭建前端安全生產體系，保障前端安全生產？
阿里提出“前端安全生產”概念，在前端應用開發、發佈、線上運行的不同階段，通過自動化流程機制，讓前端工程師產出的代碼更加靠譜，不帶着問題發佈，即便線上發現前端故障也能及時“止血”，旨在完成前端研發全鏈路的高質量交付。
榮先乾（戊子）是阿里巴巴高級前端技術專家，現任阿里巴巴設計中臺 & 業務平臺前端中臺技術負責人。他也是 GMTC 北京 2020 “前端安全生產”專題的出品人。InfoQ 在會前採訪了戊子老師，請他介紹什麼是前端安全生產，阿里在搭建前端安全生產體系時遇到的挑戰，以及如何搭建自己的前端安全生產體系等問題。
InfoQ：阿里首次提出“前端安全生產”這一概念，我們應如何理解？
戊子：近⼆⼗年來，伴隨互聯⽹⾏業的⾼速發展，互聯⽹已成爲⼀個國家重要的基礎設施，出⾃基礎設施的任何⼀個故障，都可能對國計⺠⽣產⽣重⼤的影響。而最近⼗年來，隨着前端專業化分⼯的誕⽣、前端專業技術的發展，前端研發在整個互聯⽹ Web 應⽤研發⼯程鏈路上扮演着越來越重要的⻆⾊，前端安全⽣產的責任也隨之放⼤，在前端應⽤開發、發佈、線上運⾏的不同階段，如何讓前端⼯程師產出的代碼更加靠譜，不帶着問題發佈，即便在線上發現前端故障後也能及時⽌⾎？這便是“前端安全⽣產”需要解決的問題。
今天我們所討論的“前端安全⽣產”不同於傳統的“前端安全”這個領域，前端安全關注前端領域的線上安全攻防問題，⽽“前端安全⽣產”的定義顯然更⼤，“前端安全⽣產”專注於前端研發全鏈路的⾼質量交付，當然，也包含不要帶着“前端安全”問題去交付。
討論到這⾥，我們也有了“前端安全⽣產”的⼀個基本定義。“前端安全⽣產”專注於前端研發全鏈路的⾼質量交付，在前端應⽤開發、發佈、線上運⾏三個關鍵階段，通過⼀系列的⾃動化流程機制，控制前端代碼⻛險，保障線上業務運⾏穩定，⽤機制保護⼈，不給前端同學引發線上故障的犯錯機會，最終規避損失或者降低損失。
InfoQ：爲了保障前端安全⽣產，阿⾥做了哪些工作？其中最典型的是什麼？
戊子：回顧過去歷史上的重⼤故障，以及盤點過去的故障列表，我們發現絕⼤部分故障都是由變更引起的，前端安全⽣產也不例外，也是從觸發故障的源頭變更流程開始切⼊。在前端版本變更前、變更中、變更後，我們通過⼀系列的措施去提升前端代碼質量、控制發佈⻛險、及時發現問題。這其中的關鍵過程包含：
- 前端版本變更前：靜態代碼掃描、⾃定義⼯程規範校驗、單元測試 ；
- 前端版本變更中：UI 迴歸測試、迭代變更⻛險評估、灰度監控報告；
- 前端版本變更後：1 分鐘發現問題、5 分鐘定位問題、10 分鐘修復問題。
從上圖可以發現，前端安全⽣產並⾮⼀個全新的領域，更多的是組合現有的分散在不同系統的能⼒，包括前端⼯程體系、前端 CI/CD 系統、前端測試系統、前端監控系統，讓我們更體系化保障前端研發全鏈路的⾼質量交付。
InfoQ：建⽴前端安全⽣產體系之初遇到哪些問題？針對這些問題我們是如何去解決的？
戊子：整個前端安全⽣產體系涉及到的⼤部分能⼒都是整合現有的前端相關係統等，整合過程中我們重點補⻬了多項核⼼能⼒。接下來我將挑三個有代表性的⽅向給⼤家介紹，主要涉及前端迭代變更⻛險評估、前端灰度監控報告以及 5 分鐘快速定位問題。
- 前端迭代變更⻛險評估
在迴歸測試階段，我們需要明確知道本次前端版本迭代所造成的影響點，以供開發同學⾃測或者是測試同學重點回歸相應部分，⽆論是⼈⾁測試，還是⾃動化迴歸，到很依賴這個關鍵信息。另外⼀種常⻅的場景是，前端代碼本身沒做任何改動，但是由於依賴的⼆⽅/ 三⽅包⾃動升級，導致某些場景出現⽆法預料的問題。這些都是因爲前端迭代影響點⾃⾏評估不全⾯可能觸發故障的典型場景。爲了解決前端迭代中⽆法準確給出迴歸點的問題，我們提供了迭代影響點評估⼯具，重點提供以下能⼒：
- 開發同學明確本次迭代相對於上⼀次迭代的顯示 & 隱式變更；
- 開發同學明確哪些項⽬⽂件將會受到所有這些變更的影響，並且能夠看到具體的影響路徑；
- 開發 / 測試同學能夠看到更加全⾯、有理有據的迴歸功能點。
- 前端灰度監控報告
前端灰度監控的核⼼⽬的是讓前端灰度發佈的結果有據可依。在灰度發佈期間，監控會重點關注前端灰度環境和線上環境對⽐後⻚⾯訪問速度變化、JS 錯誤率變化、新出現的 JS 異常以及 API 成功率變化，⾃動⽣成灰度監控報告，同時也會通過灰度流量⻚⾯覆蓋率、API 覆蓋率來判定是否需要延⻓灰度時⻓或加⼤灰度流量⽐例。
- 應⽤全鏈路的 5 分鐘快速定位問題
通過前端⽣成 traceId 並透傳到後端業務調⽤鏈路的⽅式，打通應⽤從前端到後端全鏈路問題追蹤，從前端發現的 API 錯誤問題，可以通過 traceId 關聯直達後端監控系統，⼤幅減少涉及到應⽤全鏈路的問題定位時間，⾄此前端同學發現 API 相關問題後不再“甩鍋”到後端，⽽是給後端同學提供診斷問題的有效線索。
InfoQ：目前，阿里的前端安全⽣產體系的現狀如何？
戊子：整個前端安全⽣產體系的建設在我們部⻔內部⼤致分爲三個階段，⽽直到第三個階段，我們才真正意義上完成了整個體系的 1.0 建設。這三個階段分別是：單點安全⽣產保障、多煙囪獨⽴安全⽣產保障、體系化的前端安全⽣產保障。
- 單點安全⽣產保障階段：線上前端監控
2015 年 8 ⽉，我們啓動了前端監控系統 retcode 的建設，通過線上實時監控⻚⾯訪問速度、JS Error、API 成功率核⼼的三板斧能⼒，爲前端應⽤的運⾏態穩定性保駕護航。2016 年底， retcode 成⻓爲阿⾥集團內部使⽤最⼴泛的前端監控產品，這個階段內，我們核⼼還是依靠線上前端監控的單點能⼒去保障前端的安全⽣產。爲了持續修煉前端監控產品的核⼼能⼒，在 2017 年中我們啓動了 retcode 的上雲計劃，進⼊前端安全⽣產建設的第⼆個階段。
- 多煙囪獨⽴安全⽣產保障階段：雲化前端監控 + 其他保障
2017 年 9 ⽉，retcode 升級爲阿⾥雲 ARMS 前端監控，開啓全⽹公測。在直⾯⾏業競爭對⼿的同時，我們的多項核⼼能⼒得到極⼤提升，這其中包括⾯向全球化業務的國際極致性能、JS Error 出錯時⽤戶⾏爲回溯、API 接⼝快照以及打通前後端的全鏈路追蹤等等，前端監控平臺也經歷了從“錯誤數據展示”到“專家級問題診斷”的升級，整個平臺每天處理的⽇志條數也超過了百億級別。
這個階段內，除了前端監控平臺在阿⾥雲上的產品能⼒升級助⼒前端安全⽣產，在我們部⻔內部，也開始藉助⼀系列其他的能⼒來保障前端安全⽣產，如靜態代碼掃描、TDD、UI ⾃動化迴歸等，這些可以保障前端安全⽣產的單點能⼒越來越多，但是⼤多是獨⽴煙囪服務模式，各個保障流程節點之間並未完全打通。
在阿⾥集團內部，也缺乏⼀套集團層⾯體系化的前端灰度發佈流程，表現在前端發佈與後端上線存在流程割裂、後端灰度發佈時前端⽆感、整個應⽤灰度階段⼤多是⼈⾁前端驗證或者驗證缺失。
- 體系化的前端安全⽣產保障階段：前端安全⽣產從 0 到 1
爲了解決前端安全⽣產各個保障節點的孤島問題，同時結合集團後端正在⼤⼒推進安全⽣產的時機，前端安全⽣產的體系化建設也應運⽽⽣。當前我們部⻔整個前端安全⽣產體系剛剛完成從 0 到 1，正在電商核⼼的基礎交易鏈路、⼤促穩定性保障、業務穩定性基線⽇常治理等項⽬中落地。
舉⼀個實際的場景例⼦，阿⾥歷年雙 11 穩定性保障依賴的最核⼼能⼒之⼀便是全鏈路壓測和驗收。我們都知道全鏈路壓測重點關注 API 級別的穩定性，在全鏈路壓測過程中 API 上的各種異常表現，並不能體現到前端 UI 層⾯上，這個時候前端同學並不清楚後端 API 異常和降級後，前端 UI 層⾯的表現是否符合預期。藉助前端 UI ⾃動化迴歸測試，我們將交易核⼼鏈路上的核⼼功能全部增加了測試⽤例，在後端開啓全鏈路壓測時候，前端同時開啓迴歸測試，便形成了前端的全鏈路壓測和驗收。進⽽，我們會藉助前端安全⽣產體系打造的前端變更時卡⼝能⼒，在每次前端⽇常變更時⾃動觸發前端迴歸測試，降低核⼼交易鏈路上每次前端版本變更的⻛險。
InfoQ：我們如何構建⼀個前端安全⽣產體系呢？在構建的過程中要注意些什麼問題。
戊子：通過前⾯的介紹我們已經可以瞭解到，構建⼀個完整的前端安全⽣產體系需要三項核⼼能⼒。
- 變更發⽣前 CI 卡⼝能⼒
靜態代碼掃描、⾃定義⼯程規範校驗、單元測試通過率 & 覆蓋率均是通過插件能⼒安裝到 CI 卡⼝上，這⾥可以根據實際業務場景下的痛點問題擴展更多的插件能⼒，在前端同學每次代碼提交後都能及時給予反饋， ⽽不⽤將問題拖到測試或者預發甚⾄是線上環境。
- 變更過程中的灰度卡⼝能⼒
UI 迴歸測試、前端迭代變更⻛險評估、灰度監控報告也是作爲插件能⼒安裝到了灰度發佈卡⼝上，這⾥同樣也是可以根據實際業務場景下的痛點問題擴展更多的插件能⼒，在前端同學每次版本發佈前都能及時給予反饋，遇到異常問題時直接中斷髮布過程。
根據安全⼯程學上的海恩法則“每⼀起嚴重事故的背後，必然有 29 次輕微事故和 300 起未遂先兆以及 1000 起事故隱患”，我們在變更發⽣前的 CI 卡⼝、變更過程中的灰度卡⼝都是爲了杜絕⼀切可能引發線上故障的潛在因素，不帶着有問題的版本上線。
- 變更完成後的線上實時監控能⼒
線上實時監控是最後⼀個⾮常重要的能⼒，⼀個強⼤的監控系統能夠幫忙我們 1 分鐘發現問題和 5 分鐘定位問題根因，爲我們 10 分鐘快速修復問題也就是快速回滾提供決策依據。根據安全⼯程學上的瑞⼠奶酪模型，“故障的發⽣是各種防禦⾏爲失效的累計效應”。在變更發⽣前 CI 卡⼝能⼒和變更過程中的灰度卡⼝能⼒全部都失效後，線上監控是我們的最後⼀道防線，能夠幫我們有效的扼制故障範圍進⼀步擴⼤，降低損失。
（圖片來源網絡）
除了上⾯提到的技術⼿段，安全⽣產的⾏爲準則和⽂化同樣必不可少，如制定變更紅線規約、安全⽣產專題分享等等。細⼼的讀者可能已經發現，GMTC 深圳 2019 的專題“前端測試”在今年已經升級爲“前端安全⽣產”，也是想傳遞⼀個信號，**我們正在經歷從過去被動的由測試同學主導的前端測試⾛向前端同學⼈⼈有責的主動前端安全⽣產保障時代，⽽過去的測試同學也升級爲了測試研發同學，正在給我們的前端安全⽣產體系提供強⼤的插件能⼒。
InfoQ：您認爲“前端安全⽣產”將是⼀個⼤的趨勢嗎？未來，它將會有怎麼樣的發展。
戊子：當互聯⽹已成爲⼀個國家重要的基礎設施，傳統⾏業正身處企業數字化轉型浪潮之中，互聯⽹安全⽣產必將越來越重要，⽽置身其中的前端安全⽣產也肯定會越來越受⼤家重視。從我的⻆度看到的前端安全⽣產未來將會由如下⼏個衍變趨勢。
- 前後端聯動的應用研發全鏈路安全生產；
- 借力 Cloud IDE 普及後自動集成的前端安全生產能力受益；
- 前端安全生產自動化免測版本比例提升帶來的效率提升和成本下降；
- 從提供錯誤信息到更智能的專家級診斷、主動風險預警、故障自動恢復。
還是那句話，前端安全⽣產並⾮⼀個全新的領域，讓我們⽤更體系化的系統，去控制⻛險並保障業務穩定， 同時讓每個⼈都更加重視前端安全⽣產，⽤機制保護⼈，不給前端同學引發線上故障的犯錯機會，最終規避損失，讓每個程序員都能愉快地發佈！
嘉賓介紹
榮先乾，戊子 (花名)，阿里巴巴高級前端技術專家，現任阿里巴巴設計中臺 & 業務平臺前端中臺技術負責人。曾是騰訊 Qzone 移動 Web 端技術負責人，2014 年從騰訊加入阿里，目前專注於前端安全生產、中後臺研發效能、設計協同領域。主導阿里內部使用最廣泛前端監控系統的建設，併成功在阿里雲商業化，在阿里內部倡導線下線上一體化的前端安全生產，在前端應用開發、發佈、線上運行關鍵階段聯動後端一起堅守安全生產木桶理論的“底”。
活動推薦
隨着前端專業技術的發展，前端研發在整個 Web 應用研發工程鏈路上扮演着越來越重要的角色，前端安全生產的責任也隨之放大，在前端應用開發、發佈、線上運行的不同階段，如何讓前端工程師產出的代碼更加靠譜，不帶着問題發佈，即便線上發現前端故障後也能及時止血？GMTC北京2020前端安全生產專場將詳細解答，詳情點擊GMTC北京2020。