工程無小事
2021年度工程故障專題
創新/學習/責任/時間/夢想/價值
百度-微算互聯（廣州）
輸入期刊名稱 ‖06-07‖
以下是2021年度工作中發生的16件故障。針對這些故障，我們做了簡單的整理和總結，希望大家在以后的工作中，能夠引以為鑒，杜絕踩進同一個坑。
工程無小事
事件概要：
某項目報障某機房設備某客戶端無法試玩游戲。
案例1
從建bug單到出現故障2個月，到修復耗時了1個月。Bug單沒有整體把控，在沒解決前就發生了故障。
報錯也沒有日志，無法分析問題，出現故障后加日志，導致修復周期長。
開發人員修改問題時在其他分支中改了，提測時沒有提及，導致測試人員不知道這部分修改。
【開發人員】
?1、所有修改內容必須有對應的單，必須提測給測試人員。不能因為改動很小而不提測，嚴禁搭車上載。?
2、在設計時需要考慮預留調試日志的設計。
故障診斷：
經驗教訓：
案例2
經驗教訓：
【開發人員】?
1、設計的時候應該充分考慮各方面數據，設計合理的方案，注重對歷史數據的處理。?
2、對涉及金額的需求要高度敏感，這也是紅線中的一條。應注意各環節充分評審和檢查。
事件概要：
某項目套餐綜合統計，匯總統計數據錯誤；金額數字展示成了分（實際單位為元）激活碼收入分攤統計時，未考慮到激活成功且激活時間為空的情況，造成部分激活時間為空的歷史數據未被統計。
故障診斷：
1、對數據的核查不夠周全，雖然有自測核查數據，但是邏輯思維受到限制。核查時不能按程序邏輯流程來核對，這樣會容易遺漏規則或者數據。?
2、設計方案考慮不周，對業務熟悉度不夠，激活碼首先考慮的應該是激活狀態，不能理所當然認為有激活時間就是激活成功。?
3、開發流程不夠完善，缺少部分流程環境，比如方案評審會議，第三方測試核查數據。?
4、財務相關需求重視程度還沒有深入人心，沒有真正的把財務需求和普通需求區分開來。
1
2
輸入期刊名稱 ‖06-07‖
工程無小事
事件概要：
某項目在某次上載前，運維人員對項目的saas業務服務（10.0.3.1）進行容災備份到數據庫服務器10.0.3.2，因命令少加了一個路徑，導致將10.0.3.2下數據庫的目錄覆蓋，數據庫的數據丟失。
案例3
運維人員上報小組長->暫停服務，嘗試修復硬盤（無法恢復）->恢復服務，檢查日志->通過本地保存的設備列表對丟失數據進行修復->通知測試進行全功能撥測->恢復客戶開放平臺業務安裝記錄。
處理時長：11小時20分
1、所有涉及生產環境的服務、設備、數據庫相關的變更，均應在操作前進行評審。
2、該項目進入正式運行期后一直未做數據庫的容災備份。
3、運維人員不應該做數據庫備份的操作，相關操作是系統管理員的職責范圍。在項目立項/進入正式運行后，生產環境相關賬號應該移交給系統集成部統一管理。
處理過程：
工程無小事
經驗教訓：
案例4
經驗教訓：
【開發人員】?
1、正常情況下開發人員不應該有生產環境的權限，但部分項目在轉線上初期并未將這些權限移交給運維，此時開發人員在做操作時要特別小心。也要盡快完成生產環境權限的轉交。?
2、對于關鍵數據，應考慮做數據準確性的監控。
事件概要：
運營人員反饋某項目分攤收入統計數據錯誤。
故障診斷：
開發人員在修改開發環境腳本的時候，不小心切換到了生產環境修改了腳本，導致故障。
此項目開發環境和生產環境沒有隔離，開發人員有修改生產數據庫和服務器腳本的權限。
3
4
輸入期刊名稱 ‖06-07‖
工程無小事
事件概要：
某項目出現已綁定設備被解綁的情況，受影響設備11000+。
案例5
1、設備查詢接口未做order by，導致返回數據沒有順序，單數據量到200+后，每隔一段時間會解綁一些設備。?
2、測試環境數據量與生產環境有較大差別，未測試到這情況。?
3、嘗試使用備份數據恢復時發現，備份任務失敗了，最新的備份數據是2個月前的數據。
【開發人員】
1、ToB的版本上線必須要在18點之前完成，如果未完成當天不再進行上載。
2、針對核心功能與客戶合同相關的如：客戶設備相關綁定、解綁等核心功能增加邊緣自測。
【測試】?
重點關注解綁，分組相關功能。用例增加異常場景。與解綁相關的功能要造大數據進行測試，盡量貼近生產環境。
【系統集成】?
制定完成備份策略（數據庫、配置文件、程序、日志等），對備份文件大小進行監控，定期進行還原測試或容災演練。
【通用】?
版本存在各類風險均應列在上載申請單上，走簽字流程讓各簽字人充分了解這些風險，以作為版本是否上載的評判標準。開發/測試/運維察覺風險后盡量先聯系項目經理看版本是否可以延期。
故障診斷：
工程無小事
經驗教訓：
案例6
經驗教訓：
1、對腳本格式一定要萬分小心。
2、執行過程中要看日志，及時發現問題。
3、新人操作要人審核方案，最好有老員工可以查看操作過程。
4、注意工程后續的觀察，有問題要及時提出并跟進。
事件概要：
1、某項目A機房在維護解除工程中，步驟有執行桌面緩存清理，由于運維人員上傳的虛擬IP文件格式是WINDOWS,導致腳本執行未成功、桌面未更新以及部分圖標未顯示。
2、A機房維護中，未刪除掉某種內置，導致部分程序無法正常使用。
3、B機房出現桌面內置失敗的情況較多，未進行后續處理分析。
故障診斷：
【運維人員】?
1、對于新人：沒有深入知道，工作細節把握不到位，人員分配存在風險。?
2、對于工程的效果和數據：缺乏分析，未對后續問題進行跟進。
5
6
輸入期刊名稱 ‖06-07‖
工程無小事
事件概要：
某機房受控離線，延遲500，后臺顯示異常。后臺查看為受控離線，設備并提示196615，然后出現了正常設備進去云手機延遲500，網絡地區無特征性。
案例7
主防火墻異常重啟導致主備長期搶占動作，從而影響控制延時增大；主防火墻重啟完成后恢復正常。由于沒有維保服務，無法真正定位原因，初步懷疑是硬件故障。
【網絡工程師/系統工程師】
1、服務器、數據庫、防火墻等需要定期進行補丁升級。安排定期重啟等措施。
2、定期做主備切換的演練。
故障診斷：
工程無小事
經驗教訓：
案例8
經驗教訓：
【運維人員】?
在工程前應該充分考慮各種因素，必要時應該拉上開發人員一起參與評審，或咨詢。
事件概要：
某項目某游戲加載資源報錯，導致游戲更新失敗。原因是虛擬機證書丟失。
故障診斷：
上傳出現部分鏡像補丁上傳失敗，問題是鏡像正在被應用占用無法釋放，導致無法掛載。
7
8
輸入期刊名稱 ‖06-07‖
工程無小事
事件概要：
某項目灰度測試中，少量設備游戲熱更新失敗，導致使用時報196631錯誤，影響用戶使用。影響24臺設備游戲熱更新，影響7個用戶游戲體驗。
案例9
由于28號凌晨批量對灰度測試使用的設備進行游戲熱更，少量設備因網絡問題文件下載失敗，導致24臺設備的原神游戲安裝失敗，29日用戶再請求使用時，報196631錯誤，原神程序拉起失敗，影響現網7個用戶的設備使用。
【運維人員】
在做大批量更新時，應該選取一個機房，操作完后，做觀察和驗證，確認無問題后再做剩余大批量的更新。
這是運維工程大批量操作的原則。
故障診斷：
工程無小事
經驗教訓：
案例10
經驗教訓：
提升運維意識，在啟用工具腳本時，特別是外部工具/中間件，需收集充足的資料，做風險評估，看是否會對現網服務或服務器造成壓力。
事件概要：
某項目灰度測試中，應服務器IO過高導致服務響應超時，報41009003超時錯誤，影響設備可用性。本次故障導致2次切用戶流量，此外700路設備3.5小時處于維護狀態不可用。
故障診斷：
由于核查現網日志需要，日志采集腳本在批量采集日志的時候導致IO過高，致現網服務響應超時，業務層面報出41009003超時錯誤。第三方工具filebeat（日志采集器）的處理機制不太了解，沒有評估出對現網服務的影響，后改用百度云bls。
9
10
輸入期刊名稱 ‖06-07‖
工程無小事
事件概要：
某次上載的IP庫，由于新庫與舊庫格式有差異，導致程序匹配不上而造成用戶使用設備不能分配到最近機房。本次故障影響網易全用戶在云游戲過程中，根據接入IP分配到最近機房的策略失效，全部IP都隨機分機房。
案例11
【測試人員】?
1、流程上不完善的地方是因為沒有建單，不管需求還是其他的工程，都應該有對應的單。在上載單中嚴禁再出現此類搭車行為，需要由測試把關。?
2、這個修改在上載評審會中說過，評審會上所有人沒有評估出這個修改對功能是否有影響，也證明所有人對此處經驗不足，測試運維應進行案例學習。
工程無小事
經驗教訓：
案例12
經驗教訓：
1、運維人員嚴格按照工單執行，按照工單上的時間、范圍、版本、md5、程序地址等信息進行設備更新操作。
2、項目經理應在工單上明確時間、范圍、版本、md5、程序地址等信息，以工單為準，避免轉單中出現的信息丟失。
3、運維人員在大批量設備更新前必須和項目經理進行確認。
4、建立項目基線/產品基線，更新以項目基線/產品基線作為依據。避免程序地址、md5、版本號這些信息在copy中出現錯漏。
事件概要：
在某次進行設備更新后發現設備全部異常，XPOSE沒有生效。
故障診斷：
1、運維人員提前了一天進行工程。
2、項目經理在群里告訴運維人員A要在制定一天執行工程，運維人員A將工單直接轉給運維人員B，運維人員B不知道日期，工單上也沒有注明。?
3、運維人員B在操作時取錯一個文件。
由于新庫與舊庫的格式差異，新庫對省份字段設置名稱為（廣東）而舊庫設置為（廣東省），現有程序邏輯判斷失效。
故障診斷：
11
12
輸入期刊名稱 ‖06-07‖
工程無小事
事件概要：
某項目出現部分設備恢復出廠值。
事件影響：最終客戶61個微信賬號數據丟失。
案例13
1、系統管理員從生產環境導出數據后首先要做脫敏處理。?
2、如果這些數據用于測試環境，運維人員必須對這些數據進行檢查，確保不能有任何影響生產數據的可能。?
3、從生產數據庫導出數據受到管控，必須經過業務線總監的審批。
工程無小事
經驗教訓：
案例14
經驗教訓：
1、運維腳本應該進行評審，在實施前主管應檢查，或者安排人檢查。
2、運維人員要養成良好習慣，在執行工程過程中要注意看日志。
3、運維人員要養成保持警覺，在故障發生后有敏感的嗅覺，快速定位問題。
事件概要：
運維進行新增機房擴容工程，B機房控制配置誤配置為A機房，導致A機房鏈路沖突，A機房使用用戶連接時報10006錯誤。最終影響用戶328個，A機房中斷6小時31分。
故障診斷：
運維工程師在該次工程前實施了A機房的擴容工程，在實施B機房擴容工程時，以A機房工程的腳本為基礎修改，但是漏改了一處，導致事故。
某項目客戶要求部署生產測試環境，運維人員讓系統管理員直接從生產環境導出數據放入生產測試環境（未做處理），生產測試環境SaaS定時任務掃描到續費到期設備，發起了重置任務。
故障診斷：
13
14
輸入期刊名稱 ‖06-07‖
工程無小事
事件概要：
某系統出現發不出消息，發消息慢的現象，嚴重影響客戶使用。
案例15
【運維工程師】
1、中間件和服務部署在同一臺服務器上存在風險，必須根據業務仔細評估中間件的壓力情況，對于壓力大且關鍵的中間件應該單獨部署。
2、定期做服務器主備切換的演練。
3、重要的參數如Nginx的配置文件需要遠程備份。
【系統工程師】
部分項目使用了較老型號的服務器，定期進行review，提出更換請求。
工程無小事
經驗教訓：
案例16
經驗教訓：
1、集中服務、計費服務、中間件應該拆分。
2、中間件應該獨立部署。
所有單節點服務在還未集群/主備前應該進行監控和告警。?
3、該案例其實在事件發生前已經識別了服務與中間件運行在同一臺服務器上的風險，但是工程前忘記了這個風險。所以項目/部門應該對所有風險進行記錄和管理，在做重大操作時應充分考慮還存在的風險。
事件概要：
多個項目的客戶新用戶設備受控失敗。影響時長24分鐘。
故障診斷：
研發方面：
流量計費：默認設置在流量超過1M時消息就會丟失。這個缺陷之前在X86上修改過，但未在ARM上修改。?
運維方面：由于流量數據丟失觸發了重跑流量，然而重跑流量的服務器上同時運行著集中服務、計費服務、多個中間件，重跑流量計費服務使得整個服務器IO上升到100%。
1、10.1.*.* 中間件服務器硬件故障?
2、 Mq掛了一臺，會有片刻影響
3、備機沒有同步主機文件
故障診斷：
15
16
總編輯：張燕燕
責任編輯：侯紅莉 李寶桃
廣州微算互聯信息技術有限公司
廣州市海珠區江南大道南榮熙中心
生產再忙，安全不忘；
質量關天，安全在先。
增值電信業務經營許可證：陜B2-20210327 |