一個價值560萬的經(jīng)驗教訓(xùn)感觸

在軟件工程中什么是我們的黃金生命線，是持續(xù)的業(yè)務(wù)增長，是不斷的需求吞吐量，是高效的生產(chǎn)運(yùn)維，還是健壯的代碼質(zhì)量亦或是超強(qiáng)的生產(chǎn)安全意識。其實什么都是，也什么都不是，因為這幾個緯度不是割裂的，而是彼此之間相互關(guān)聯(lián)或者說是相互影響的。

（圖1 當(dāng)前現(xiàn)狀）

通過1022的這次生產(chǎn)事故，相信大家都會有一些反思，最近一直在埋頭寫長城的代碼，一些事情還沒來得及整理，借著這次機(jī)會將之前的一些生產(chǎn)安全經(jīng)驗做一個整理。

1.1 變更前

雖然我們現(xiàn)在的應(yīng)用有級別劃分，但是不具備任何意義（大部分都是P0）。對于不同級別的應(yīng)用上線變更要有不同的制度。對于非核心鏈路上的應(yīng)用變更應(yīng)做到小組內(nèi)評審，而核心鏈路的黃金應(yīng)用最起碼要做到C3級評審。變更前要做兩件事：

• 準(zhǔn)備好變更工單

通常變更工單主要描述本次變更意圖和影響范圍，同時會把變更執(zhí)行過程和應(yīng)急回滾操作進(jìn)行描述。變更工單上的每一步操作都要可執(zhí)行，寫變更工單是一件很耗時的事情，如果我們不做好變更周期的把控，按照現(xiàn)在的上線節(jié)奏來說，變更工單太重了，并不適用，但是可以作為參考。（敏捷開發(fā)建議是兩周一迭代，我們現(xiàn)在是一周兩迭代）

checklist要把本次相關(guān)準(zhǔn)備工作進(jìn)行陳述并且要說明上線后的驗證方案和具體操作步驟。變更步驟和回滾步驟都是要可執(zhí)行，對于業(yè)務(wù)團(tuán)隊來說基本都是通過操作發(fā)布平臺或者配置中心，相對簡單一些，而對于基礎(chǔ)團(tuán)隊來說可能要把操作腳本貼上去。最壞影響分析是最重要的，體現(xiàn)了對本次變更的認(rèn)知程度。執(zhí)行人一般一次變更不會交給同一人執(zhí)行，即使是同一個人也要有對應(yīng)的復(fù)核人對變更過程進(jìn)行復(fù)核，審核人是對最終結(jié)果進(jìn)行審核確認(rèn)，這不是一個卡點(diǎn)流程，只是邏輯上的職責(zé)劃分。備注部分的架構(gòu)師主要對工程質(zhì)量負(fù)責(zé)，組長將承擔(dān)整個生產(chǎn)變更的責(zé)任。這兩個角色是最貼近生產(chǎn)的直接負(fù)責(zé)崗位。

• 變更評審

變更評審是對變更工單內(nèi)容進(jìn)行評審，通常變更評審是跨團(tuán)隊甚至是跨部門的，參與方均是該變更的相關(guān)方，對變更工單進(jìn)行最終確認(rèn)。通常變更評審會問幾個固定的問題：

1、比如新需求的影響范圍是什么？一旦發(fā)生影響如果兜底處理？

2、是否達(dá)到了生產(chǎn)變更的準(zhǔn)入標(biāo)準(zhǔn)？（單測是否達(dá)標(biāo)、案例回歸是否通過、組內(nèi)是否完成代碼評審等）

3、變更周期多久？如果做到版本兼容和生產(chǎn)灰度驗證？

4、監(jiān)控措施是否具備？

1.2 變更中

變更中最重要的是執(zhí)行人的操作和對應(yīng)的監(jiān)控告警，很多時候生產(chǎn)故障都是由于執(zhí)行人的操作失誤造成的，所以會有復(fù)核人對每一步操作進(jìn)行復(fù)核，現(xiàn)階段我們存在較高操作風(fēng)險應(yīng)該是NG的流量上線下和發(fā)布操作分區(qū)不匹配的話會造成有損（收銀臺）。同時發(fā)布過程中要時刻觀察生產(chǎn)監(jiān)控，由于一些小業(yè)務(wù)量或者一些批處理操作在短期內(nèi)不容易暴露問題，所以一般發(fā)版會采用灰度跨天發(fā)布的方式，拉長觀察周期。

1.3、變更后

變更結(jié)束后要想完整閉環(huán)需要對上線工單中checklist上線檢查部分進(jìn)行全量驗證，同時要得到產(chǎn)品經(jīng)理（需求提出方）的最終確認(rèn)才能關(guān)閉工單。

對于飛宇反饋的關(guān)于日常工作中開發(fā)時間被各種排查生產(chǎn)問題所支配，無法按照自身的計劃完成開發(fā)（之前劉蓮也反饋過）。對于這種場景需要先梳理我們的問題集中點(diǎn)，把共性問題找出來制定FAQ，讓問題方自行解決。對于純業(yè)務(wù)問題直接轉(zhuǎn)到運(yùn)營和產(chǎn)品經(jīng)理處，進(jìn)行解答。也就是問題邊界劃分要明確?？偨Y(jié)如下：

1、FAQ：提供共性問題解答

2、邊界劃分：純業(yè)務(wù)問題直接分配給一線人員（運(yùn)營或產(chǎn)品經(jīng)理）

3、工具開發(fā)：對于一些日常排查問題的執(zhí)行手段，可以沉淀下一些小工具，輔助大家快速排查問題。

4、制定值班制度（輪崗值班）：可以以天或者以周為單位統(tǒng)一分配給一名同事負(fù)責(zé)排查小組問題，值班同事不負(fù)責(zé)需求開發(fā)等任務(wù)，只負(fù)責(zé)組內(nèi)問題解答。這種制度的好處是可以讓整個小組人員互相了解彼此負(fù)責(zé)的項目，提高備份能力。難點(diǎn)在于前期需要很長時間的過度，因為想讓一個人了解全組項目還是有一定的投入的，而且對于團(tuán)隊內(nèi)不斷加入的新人也是一種挑戰(zhàn)。

這個話題太大了，只說最近了解的一些項目通病吧。

3.1、日志規(guī)范

目前很多項目的日志打印沒有統(tǒng)一的規(guī)范，日志格式和日志級別管理混亂，甚至部分應(yīng)用的日志輸出到了tomcat的catalina.out文件中，規(guī)范的日志輸出可以大大提升問題排查效率。建議規(guī)范如下：

對于error日志可以單獨(dú)分出一個文件，這點(diǎn)不強(qiáng)制。對于穩(wěn)定的業(yè)務(wù)rpc.log可以設(shè)置為debug級別，降低生產(chǎn)資源浪費(fèi)。

3.2、工程質(zhì)量提升

同業(yè)中的科技公司都在進(jìn)行數(shù)據(jù)化轉(zhuǎn)型，映射到我們軟件工程部分其實還是在工程質(zhì)量效能提升環(huán)節(jié)進(jìn)行改革。也就是說在數(shù)字化的時代，研發(fā)效能已經(jīng)成為一家科技公司的核心競爭力。這部分是一個巨大的、長期的投入工程。我們部門現(xiàn)在其實已經(jīng)具備了工程效能提升的前置條件，也就是一些基礎(chǔ)平臺的支撐能力（行云、JDOS、SGM、Digger、EasyOne、DeepTest、JCI等等），但是我們現(xiàn)在最缺的是技術(shù)人員對效能的認(rèn)知和決定攻堅這件事的勇氣。

3.3、故障經(jīng)驗沉淀

近期發(fā)現(xiàn)我們的技術(shù)同事對于故障復(fù)盤不是很重視，其實每一次故障復(fù)盤都有很多值得我們學(xué)習(xí)的東西，說句不中聽的話，我們是在消耗公司的資源在增長自己的經(jīng)驗。每一次的故障復(fù)盤都應(yīng)該是深刻的，且能互相傳播學(xué)習(xí)的。首先要有一份深刻的故障報告，建議可以參考以下模板：

對于部門的生產(chǎn)故障要周期性的討論分析，同時對沉淀下來的一些知識點(diǎn)要已問卷調(diào)查的形式，不定期做全員抽查考核，保證知識積累的傳遞。

3.4、監(jiān)控告警梳理

目前很多有價值的監(jiān)控告警都被淹沒了，這塊沒有太多好說的，就是需要對現(xiàn)有的監(jiān)控告警進(jìn)行一遍梳理，然后劃分級別，對于不同級別告警配置不同通知方式，每種異常都要有配套的應(yīng)急處理手段，且團(tuán)隊成員都要具備執(zhí)行能力。這塊是大家都能夠意識到的問題點(diǎn)，不做過多分析，后續(xù)排期整改就是。（將會放到工程效能項目中跟進(jìn)）

廊坊機(jī)房斷電演練失敗反思：由于前期沒有深入?yún)⑴c，對于細(xì)節(jié)不甚了解，但是通過該事件的結(jié)果足以暴露出我們系統(tǒng)存在各種各樣的問題，機(jī)房隔離這是金融機(jī)構(gòu)尤其是一家金融科技公司，應(yīng)具備的最基本的業(yè)務(wù)連續(xù)性保障能力之一。甚至科技司會對一些金融基礎(chǔ)設(shè)施(比如網(wǎng)聯(lián)、銀行)周期性的抽查演練。

4.1、機(jī)房等比建設(shè)

機(jī)房等比建設(shè)是說每個IDC要具備同樣的服務(wù)能力，一般是指基礎(chǔ)資源要對等，應(yīng)用服務(wù)要全面，但是很難做到每個機(jī)房完全一致，這里就要看具體的情況了。從SA的角度要保證每個機(jī)房的服務(wù)器資源最少滿足統(tǒng)一的基線標(biāo)準(zhǔn)；網(wǎng)絡(luò)帶寬要足夠且有固定的冗余，用于承接容災(zāi)能力；生產(chǎn)區(qū)域劃劃分面要保持強(qiáng)一致性，因為不同的生產(chǎn)環(huán)境規(guī)劃實際上對業(yè)務(wù)部署和組件搭建是有影響的，所以環(huán)境劃分要強(qiáng)一致，比如DMZ區(qū)域劃分、生產(chǎn)區(qū)防火墻異構(gòu)策略、IPS流量清洗、WAF/HIDS等安全策略、運(yùn)管區(qū)到生產(chǎn)區(qū)訪問策略等。

而對于應(yīng)用來說每個機(jī)房都要提供同樣的服務(wù)能力，且有一定的冗余可以保證跨機(jī)房容災(zāi)。直白點(diǎn)說，理論上每個機(jī)房都要部署自己的服務(wù)，并且規(guī)劃出一定的冗余處理能力。

4.2、應(yīng)用平等計劃

平等計劃需要從多個角度來理解，從應(yīng)用部署角度來說：

• 每個應(yīng)用單中心部署最少3個節(jié)點(diǎn)，多點(diǎn)多活。

• 多個中心部署應(yīng)用數(shù)量應(yīng)該相同，保證服務(wù)能力一致。

• 每個應(yīng)用應(yīng)該均勻離散在不同基礎(chǔ)設(shè)施上（應(yīng)用不能在同一個物理機(jī)、機(jī)柜、LEAF節(jié)點(diǎn)上，避免單點(diǎn)問題）

從服務(wù)采購層面來說：

• 網(wǎng)絡(luò)專線提供商不能使用一家服務(wù)（移動、聯(lián)通、電信應(yīng)該都具備）

• 服務(wù)資源、網(wǎng)絡(luò)設(shè)備采購最少需要倆家服務(wù)商（華為、思科等）

• 安全策略不能單一，需要多策略平等生效。比如防火墻要異構(gòu)不能同構(gòu)。

其他緯度忽略......

4.3、單元化部署

單元化部署是為了邊界清晰管理，可以提升生產(chǎn)運(yùn)維能力。對于復(fù)雜業(yè)務(wù)場景來說最難的是單元邊界的劃分和后續(xù)把控。該場景在騰訊（財付通）內(nèi)部有比較成功的落地案例，財付通早期是按照支付渠道實現(xiàn)單元化部署的，從流量入口到核心業(yè)務(wù)處理程序按照接入渠道(銀行渠道)劃分成不同的Set單元，每個單元里部署著最小業(yè)務(wù)單元，通過管理每個Set實現(xiàn)靈活的生產(chǎn)運(yùn)維。Set化的實現(xiàn)除了要做好單元邊界劃分之外還需要一些配套的基礎(chǔ)工具支撐，比如一個好的網(wǎng)關(guān)服務(wù)、簡潔的Set單元操作平臺等。

以上說的這幾點(diǎn)是要推行單元化部署的前置基礎(chǔ)條件，需要做好提前分析再落實。

業(yè)務(wù)閉環(huán)是業(yè)務(wù)連續(xù)性的重要體現(xiàn)，對于實時交易鏈路(一般是全鏈路RPC)來說通過處理異常失敗是可以做到業(yè)務(wù)閉環(huán)的，但對于一些異步場景，或者依賴數(shù)據(jù)最終一致性的場景是需要有一套業(yè)務(wù)閉環(huán)程序負(fù)責(zé)檢查和兜底處理的。比如差錯系統(tǒng)，差錯系統(tǒng)通常只有兩大主要責(zé)任，第一是負(fù)責(zé)發(fā)現(xiàn)差錯業(yè)務(wù)，也就是存在業(yè)務(wù)狀態(tài)不一致、交易業(yè)務(wù)異常阻斷等場景；第二是執(zhí)行差錯異常兜底方案，比如自動化的沖正、補(bǔ)償查詢、統(tǒng)一關(guān)單等。部分差錯系統(tǒng)還會提供一些數(shù)據(jù)異常導(dǎo)出等能力。1022事件也暴露了我們?nèi)鄙僖粋€交易狀態(tài)比對的系統(tǒng)，這點(diǎn)也得到了大家的共識，后續(xù)可以考慮補(bǔ)充這塊缺失的能力。

業(yè)務(wù)閉環(huán)還有一個重要的考核指標(biāo)，就是強(qiáng)依賴和應(yīng)急處理措施。對于交易鏈路的強(qiáng)依賴項(阻斷業(yè)務(wù)項)要有兜底方案，優(yōu)先是系統(tǒng)兜底，如果系統(tǒng)無法實現(xiàn)自動化，需要人工兜底。人工兜底就要依靠應(yīng)急處理措施的可執(zhí)行和運(yùn)維人員的操作時效性了。比如數(shù)據(jù)庫掛了有緩存，緩存又分R2M和JIMDB主備，這就是一個很好的數(shù)據(jù)源弱依賴場景。比如配置中心DUCC，很多降級操作都是通過DUCC下發(fā)配置，如果DUCC掛了我們還有什么其他的手段下發(fā)配置嗎？如果沒有，那么我們就是強(qiáng)依賴DUCC，當(dāng)然DUCC一般不作為交易鏈主鏈路的強(qiáng)依賴。

未完待續(xù)...（一些經(jīng)驗會同步給洪潘，納入他的項目中體現(xiàn)）

最后希望我們大家對生產(chǎn)安全意識要有一定的提升，同時也應(yīng)該下一些勇氣去改變，不要再以需求多，每天都有問題排查來作為犧牲質(zhì)量，降低生產(chǎn)安全的借口了。

（圖2 健康狀態(tài)）