軟件生產(chǎn)變更管理初探
一、基本概念
1.1 定義
????變更管理是指對人員、技術(shù)、設(shè)施資源、操作流程等永久性或暫時性的變換進行有計劃的控制，以避免減輕對安全生產(chǎn)的影響，保障系統(tǒng)SLA指標(biāo)運行。
1.2 目的
????為了規(guī)范研發(fā)與運維人員對生產(chǎn)環(huán)境的操作，消除或減少由于變更而引起的潛在事故隱患，加強對變更過程有計劃的控制，避免或減輕對企業(yè)安全生產(chǎn)的影響，結(jié)合公司生產(chǎn)實際情況，制定研發(fā)生產(chǎn)變更管理流程。
1.3 適用范圍
技術(shù)研發(fā)：負(fù)責(zé)日常生產(chǎn)迭代和系統(tǒng)優(yōu)化等變更操作。
技術(shù)運維：負(fù)責(zé)業(yè)務(wù)參數(shù)相關(guān)配置操作
二、現(xiàn)狀分析
2.1 生產(chǎn)問題根因分布
故障整理平臺統(tǒng)計集團全量生產(chǎn)故障根因歸類
2021上半年部門故障根因歸類
總結(jié)：根據(jù)對生產(chǎn)故障的分析可以看出，由生產(chǎn)變更操作造成的生產(chǎn)故障占集團的12.20%，占部門的9.52%。對于這個高占比的風(fēng)險點有必要進行管理，降低其風(fēng)險系數(shù)，提升安全生產(chǎn)質(zhì)量。?
2.2 生產(chǎn)變更操作方式分類?
總結(jié)：
問題一：目前來看生產(chǎn)配置推送是最大的風(fēng)險點，配置更改沒有審核卡點，完全靠人員自覺性，這是十分危險的。任何一個極端的念頭都有可能造成無法估量的生產(chǎn)故障，安全生產(chǎn)的一個核心原則就是不能相信人。同時配置推送也是制造生產(chǎn)故障成本最低的環(huán)節(jié)，值得關(guān)注。
問題二：online工單都是與運維團隊的交互留痕，一個online工單無法體現(xiàn)出一次生產(chǎn)變更的整個生命周期。比如服務(wù)器縮容，當(dāng)有online工單到組長審批時，實際開發(fā)人員已經(jīng)完成了機器下線等生產(chǎn)操作，最后的online縮容工單只是為了讓基礎(chǔ)運維回收機器而已，對于服務(wù)器下線這個變更沒有完整的閉環(huán)流程，操作過程黑盒，缺少監(jiān)控驗收手段。
問題三：預(yù)發(fā)環(huán)境和生產(chǎn)環(huán)境即使無法做到物理隔離，但也要做到完全的邏輯隔離，即可以避免生產(chǎn)操作影響，也可以避免一些生產(chǎn)臟數(shù)據(jù)的處理。目前缺失預(yù)發(fā)變更的管控能力，如果真的做好全面的邏輯隔離，其實倒也可以不進行管理。?
2.3 生產(chǎn)變更場景分類跟蹤
跟蹤周期：2021/12/13 -- 2021/12/17【部分?jǐn)?shù)據(jù)設(shè)計公司敏感系統(tǒng)，故模糊處理】
分析：
總結(jié)：
問題一：對于每周二、周四晚間統(tǒng)一變更的習(xí)俗是否合理，在此提出疑問。同行業(yè)中目前只有銀行還保持夜間變更的流程，且對銀行類系統(tǒng)來說是有必要的，而對我們來說是否有必要卻是一個未知數(shù)。
問題二：以上的變更跟蹤數(shù)據(jù)是人肉統(tǒng)計，對于團隊(C3/C2)內(nèi)的整體變更情況缺少跟蹤管理的途徑。?
三、支付產(chǎn)品生產(chǎn)變更流程規(guī)范
3.1 變更原則
任何發(fā)布都需要通過測試驗證（含測試允許的自測），有回滾計劃和灰度環(huán)節(jié)。
上線代碼必須經(jīng)過非本人外的研發(fā)人員code review，核心系統(tǒng)可選擇多人。
發(fā)布過程或者發(fā)布完成后，服務(wù)端和測試必先留觀30分鐘以上；相關(guān)核心服務(wù)發(fā)布需要持續(xù)關(guān)注30分鐘以上（監(jiān)控和輿情），并提前通知發(fā)布關(guān)聯(lián)方或受影響方；
資金類關(guān)鍵業(yè)務(wù)點上線前必先驗證及分版本監(jiān)控；
核心和敏感服務(wù)的數(shù)據(jù)庫變更務(wù)必選擇和業(yè)務(wù)低峰時間操作；
禁止一切未經(jīng)變更授權(quán)和一切變更方案外的操作，必須嚴(yán)格按照變更方案執(zhí)行
禁止非變更窗口（周二、周四為變更窗口）執(zhí)行變更（緊急變更需要向上申請報備）?
備注：上線過程建議使用三屏無腦原則進行發(fā)布，研發(fā)人員打開發(fā)布屏、監(jiān)控屏、回滾屏三屏，如有異常直接操作回滾 。
3.2 豐富技術(shù)設(shè)計方案
????所有的研發(fā)需求變更都要有對應(yīng)的研發(fā)卡片（研發(fā)人員直接在團隊空間下創(chuàng)建即可）和技術(shù)方案，并應(yīng)通過組內(nèi)評審（每周三舉行的設(shè)計方案評審）。
業(yè)務(wù)需求變更應(yīng)在技術(shù)設(shè)計方案中體現(xiàn)，需要明確評估變更影響范圍、變更時間、操作人和復(fù)核人。變更結(jié)束后需在設(shè)計方案中補充驗證截圖留痕。
todoList ：上線前的所有前置準(zhǔn)備公司以及上線步驟。
checkList：上線后的對應(yīng)驗證步驟，需要留下驗證痕跡（比如截圖）。
最壞影響分析：每個變更都要考慮影響范圍，并說明監(jiān)控方式和應(yīng)急處置手段。
3.3 配置變更
????統(tǒng)一配置推送在不具備線上審核的情況下，必須雙人復(fù)核（A：提交人 , B：推送人）,且配置推送后要持續(xù)留觀30分鐘。
3.4 online工單變更
????在online工單沒有明確實現(xiàn)自動化驗證能力的情況下，需盡量實現(xiàn)人工驗證覆蓋。
四、All IN Online
????按照傳統(tǒng)的生產(chǎn)變更流程來說，每次生產(chǎn)變更都需要填寫變更工單并通過評審，但考慮到我們迭代周期的緊湊性，詳細的變更申請工單投入太大，整個變更流程過重，但為了對生產(chǎn)變更進行有效管理，還需通過簡單的流程進行變更管理。綜合以上兩種情況，建議所有的生產(chǎn)變更都通過online來管理，在online上建立本部門的生產(chǎn)變更類型工單，根據(jù)不同的變更場景填寫必要的變更要素，其本質(zhì)為了多思考變更的影響，統(tǒng)一控制變更節(jié)奏，降低變更的影響范圍。
具體執(zhí)行工單模式可參考下表：?
我們目前最缺少的其實是變更前的思考，要多想影響范圍，考慮到回滾機制，即使是一個很小的常規(guī)變更，也要有思考、思考、思考的過程。?