是能力更是文化,談談IT系統的安全發布

InfoQ 2022-05-14 13:52:58 阅读数:91

能力更是文化安全

引言

在前邊一篇文章
如果只有一周時間,怎麼快速提昇線上系統的穩定性?
中我們總結了影響IT系統質量和穩定性的因素以及如何快速提昇系統質量和穩定性的途徑。我們知道生產事故跟架構設計、代碼開發、上線變更、業務配置、運維操作以及外部依賴等研發運維全生命周期都相關,而其中架構代碼問題(代碼Bug+架構設計)約占30%,還有約70%的事故是程序編碼出來之後到實際運行過程之間產生的,與架構代碼本身關系不大。這些非架構代碼問題主要與IT變更失誤、業務參數配置失誤、性能容量不足、外部系統依賴錯誤以及IT運維操作失誤等因素相關。其中IT變更失誤及業務參數配置失誤其實都與版本發布相關,合並計算的話兩類因素占所有生產事故的20%以上,占非架構代碼問題的1/3左右。今天我們就來總結一下安全發布的相關實踐和經驗。

什麼是一次版本發布?

首先,我們有必要先明確以下幾個定義,以確保我們討論的和你所想的是同一件事情。
第一,什麼是一次版本發布
?任何由IT實施的,會對生產系統行為產生改變的內容(哪怕只是一個系統參數設置變化)和過程的集合是一次版本發布。它既包括版本自身,又包括發布過程。
第二,一次版本發布包含哪些過程?
既然一次版本發布包括發布過程,那有哪些過程呢?如下圖所示,筆者所在的團隊認為一次版本發布是從接到“版本需求”開始,到發布完成並開始“發布跟踪”結束,至少包括發布需求澄清、發布策略制定、准備待發布版本、執行發布以及發布跟踪等多個階段。
null
第三,版本分類
。在踐行安全發布理念的過程中,不同發布規模的版本所需要重點關注的內容以及安全保障流程會有較大不一樣。根據筆者所在團隊的實踐經驗,我們大致將版本按發布規模的不同做如下分類:
  • 小規模版本
    。發布需求可能是一個很小的Feature,也可能是一個BugFix,一般僅涉及一個系統模塊或一個微服務本身。
  • 大規模版本
    。發布需求可能是技術上的一次大型昇級迭代,比如系統架構從單體式應用昇級為微服務架構,或者是數據模型數據庫結構發生大的變化。也可能是業務上一次大型的業務上線,比如一個新業務從0到1發布,涉及上下遊多個系統或者服務配合,發布本身也有可能會分幾次才能全部完成。
  • 普通版本
    。介於小規模版本和大規模版本之間,可能涉及一個或幾個(不超過3個)不同的模塊或者微服務變更,系統架構或者業務模式沒有大的變化,一次發布可以完成一個普通版本上線。

如何實踐安全發布?

筆者所在團隊對過往因版本發布直接引發的生產事故(約占所有事故的20%)進行了細分,得到如下數據。
null
此處不包括代碼本身Bug導致的生產問題,因為我們在對生產事故統計時,將代碼Bug問題單獨進行了分類。根據長期實踐,基於版本發布生命周期概念及上述事故分類占比,筆者所在團隊根據不同版本規模采取不同的措施保證安全發布。
先來看看
小規模版本發布
。小規模版本發布一般不涉及上下遊協同,發布方案可以極簡為“開發-測試-發布”的簡單流程。也即是,小規模版本發布的關鍵是保證眾所周知的代碼本身質量可靠,上線部署過程不出意外即可。曆史事故分析也告訴我們,代碼質量問題至少占30%,“變更操作失誤+測試髒數據”等上線部署過程中的人為操作失誤也至少占10%以上。為了解决這兩類問題,業界有非常多的優秀實踐。如同事間的代碼評審、嚴格執行的質量門檻、自動化功能及性能測試等實踐可以確保代碼本身質量;而可重複的部署變更流水線則可以實現部署過程全自動化,避免人為操作失誤。這些都是DevOps和持續交付理論要著重解决的問題,相關材料不計其數,此處不展開。
再來看看
普通版本發布
大規模版本發布
。與一般的小規模版本發布最本質的不同在於,這兩類發布涉及更多系統模塊或服務,需要更多上下遊協調。如上述事故分類占比你所展示的,“發布方案錯誤”和“上下遊協同”相關的變更失誤生產事故至少占30%,如果只考慮需要詳細制定發布方案和上下遊協同方案的較大規模發布,這類問題導致的生產事故占比會更高。因此,對較大規模的版本發布,除保障小規模版本發布的DevOps和持續交付實踐之外,更重要的是制定完善的發布策略和上下遊協同機制,從源頭上保證發布安全。下邊,我們來重點討論一下這兩類問題。

面向發布的研發上線流程

針對發布方案錯誤或上下遊協同帶來的生產事故作進一步分析,我們發現這些
錯誤錶現
其實大致可以歸結為如下幾類:
  • 對待大型業務需求時僅考慮系統架構變更和開發排期,
    未從發布角度考慮發布計劃和系統架構
  • 發布策略制定太晚
    ,主體需求臨發布前才識別到相關聯模塊影響,致使瘸腿上線或延期上線
  • 系統或架構太複雜,
    評估不到比特或者評估有遺漏
    致使系統上線存在缺陷
  • 發布策略太激進
    ,采取一次性的BigBang變更,未從業務影響角度充分考慮發布節奏和系統架構調整
  • 發布計劃欠考慮,流於形式
    。未制定應急回退方案或者應急回退方案無法實施
要解决上述問題,做到安全發布,需要明確以發布為中心的“
面向發布的研發上線流程
”。下邊,我們以一個典型的大規模版本發布為例來描述這個流程的關鍵內容。
例:
在公司的一個主力業務中,運行了兩套並行的系統,老系統是上個時代基於數據庫的單體式應用,新系統是基於內存計算的分布式系統。經過一段時間的並行運行驗證,業務方决定將剩餘的絕大部分業務流量遷移至新系統,遷移的過程要充分考慮已有業務的連續性,遷移後希望業務開展的延遲、TPS和容量等性能有巨大的提昇。新老系統在數據上不可兼容,新系統則涉及多個數據中心。

  • 制定可執行的發布策略並且將策略制定環節左移。
針對較大規模版本,發布需求確定後的第一件事即是制定可執行的發布策略,而不是一上來就做架構設計,有時甚至需要根據發布策略調整發布需求。一個好的發布策略是具備可行性的策略,要有明確發布內容和組織形式(版本),發布計劃,以及計劃執行中的組織和人力保障。
  • 發布策略至少包含“版本方案”和“發布計劃”兩部分。版本方案指根據版本需求確定的系統邊界和模塊組成部分。無論涉及的系統或模塊是否存在代碼或配置修改,只要是跟完成對應需求相關的系統,都是版本方案的一部分。發布計劃是針對確定好的發布版本,識別相關方並確定將版本落地實施的完整計劃。在制定發布策略的最初階段,或許不需要非常清晰的DayByDay計劃,重點是要識別出相關方和對應的職責,以及除IT系統變更以外為保證版本落地實施需要的組織保障。
  • 發布策略需要所有直接參與方認可和支持。直接參與方是指在“版本方案”中涉及到的所有業務方、產品管理方、研發團隊、測試團隊、運維團隊以及基礎設施和安全相關的團隊。
  • 發布策略要指定明確的發布負責人。
以示例中的業務遷移需求為例。此次版本發布包括老系統、新系統、業務在新老系統中的數據及對應的數據庫系統、運行新老系統的數據中心及網絡等基礎設施。因為新老系統數據不兼容且新系統涉及多數據中心,除關注新系統自身可能涉及到的改造外,發布計劃需要重點關注業務數據的遷移方案,業務遷移到新系統後底層基礎設施的保障方案以及業務遷移到分布式系統後的跟踪反饋機制建設。很明顯,要順利完成業務遷移,能够協調多方的產品負責人或者新系統的負責人是比較理想的發布負責人。在上述內容確定後的第一時間,發布負責人應召集所有相關方對計劃中的關鍵問題充分討論,形成一致方案和行動計劃。

  • 根據發布策略調整架構設計和測試方案
將發布策略環節左移到架構設計之前的主要原因在於,發布策略中制定的版本方案在很多時候需要架構設計及相應的測試方案配合才能實現。
比如示例中的業務遷移需求,至少有兩種不同的發布/遷移方案。
方案一:一次性將業務數據從老系統遷移至新系統,遷移後試運行期間保證新系統出問題時可以一次性將業務數據回遷至老系統。
架構設計:重點設計相應的回遷方案和工具保證業務數據一次性回遷的可行性以及低耗時。
測試方案:重點測試和演練業務數據遷移和回遷方案及耗時。
方案二:分批次將老系統的業務數據遷移至新系統,在客戶訪問環節根據不同客戶做路由,每批次遷移時先將訪問請求同時路由至新老系統,新系統接受請求並處理但不返回響應,僅作驗證用,驗證無誤後切換真實業務流量。
架構設計:新增客戶訪問網關同時支持新老系統,根據業務分批策略對業務訪問做路由,並支持在運行過程中更改路由邏輯;有可能老系統也許作相應的修改使得業務部分遷移是可行的。
測試方案:重點測試訪問網關的自定義路由能力及網關路由的穩定性和性能,測試時應盡可能100%模擬目標生產環境的真實部署情况。若老系統也需要架構修改,則對應的測試方案也是必須的。

  • 盡早組織所有人評審詳細發布執行計劃
發布版本的相關改造基本完成之後,應該在測試驗證的同時並行制定詳細的發布執行計劃並由發布責任人召集所有相關方評審以鎖定發布資源或作相應的調整改造。發布執行計劃應該至少包括以下基本元素:

實踐該執行計劃時,每一項主要內容都最好有一個標准的checklist,並以標准的方式(如執行計劃錶或者變更管理系統等)將所有的發布執行計劃統籌管理,便於與發布管理機制結合以及逐步改進。

  • 對涉及較多人工協調和操作的關鍵環節要做充分演練。
如示例中的方案一,業務數據一次性遷移和回遷過程本身可能會涉及多方協作,必須結合架構設計、遷移回遷工具等,組織所有人員進行提前演練,多做幾遍。

  • 發布執行完成不等於發布結束,發布後跟踪確認無誤才是發布結束的標志。
只有當“首次運行檢查列錶”中的所有檢查內容都已被覆蓋且檢查確認無誤,本次發布才算結束。

安全發布應成為一種文化

筆者所在的團隊進行了非常多的探索、實踐和改進,最終沉澱了一些實踐經驗和方法論。大家可能已經發現,上述安全發布提倡的“
面向發布的研發上線流程
”其實只描述了安全發布涉及的關鍵環節,每個關鍵環節的核心工作內容,並未對如何開展這些工作以及由誰來實施給出建議。
事實上,如何達成上述安全發布的形式是多種多樣的。筆者所在團隊踐行了包括變更評審、事故跟踪、事故分析、以穩定性為目標的演練和架構改造等等實踐,有得也有失。我們發現要使上述流程和工作實踐發揮最大效力,以最大限度保障發布安全的最重要因素其實是
每一個版本發布責任人/實施者是否能够高質量踐行該流程
,這包括其自身能力,也包括組織能力。因此,
如果說“面向發布的研發上線流程”能够幫助組織和人提昇安全發布的能力的話,那高質量踐行該流程則是一種安全發布的文化
。培養安全發布的文化需要堅持以下幾條原則:
原則一
:每一個版本發布責任人應當對版本安全發布負全責
原則二
:組織或管理者應當創造合適的機制使得版本發布實施者能够負全責
原則三
:堅持“面向發布的研發上線流程”,將發布安全性作為研發流程、架構設計等是否合理的重要評價標准
原則四
:小步快跑,盡最大努力避免大規模版本發布,只在不得已的時候做超大規模版本發布

參考資料

  • 《DevOps 實踐指南》
  • 《持續交付》
版权声明:本文为[InfoQ]所创,转载请带上原文链接,感谢。 https://gsmany.com/2022/134/202205141342145066.html