如何作到系統穩定——TL視角

對於一個開發工程師，一個團隊的負責人，系統穩定是咱們的追求，或者說是要求，若是作到系統穩定呢，整體仍是在於規範研發流程，以下是我工做幾年來總結的能有效確保系統穩定的點

需求評審
1 能跟產品經理撕是一種能力，從經驗上來看，不穩定的系統，產品需求就存在不少不合理的地方，
若是不能有效的梳理需求，明確業務上想要的是什麼東西，穩定性無從談起。產品經理設計的系統是否易懂易用是一個須要仔細評估的點，線上百分之八十的運營事故都是因爲系統難用，信息不對稱形成的
2 時間節奏也是個問題，要倒逼產品經理在什麼時間點必需要搞定，若是按照約定的節奏還有問題就須要上浮。
最優的實踐是按照固定的迭代節奏開發，好比兩週一個開發節奏，到點交付沒有問題的prd。
不少項目的延期都是因爲在設計開發階段還在跟產品經理聊需求致使的，在架構設計以前必定要確認全部需求問題。

架構設計
1 架構設計要遵循簡單原則，同等條件下哪一個方案是最簡單的，最容易理解的，哪一個就應該是第一選擇，遵循奧卡姆剃刀原則。
2 架構設計圖中最重要的是ER圖和時序圖和狀態機，爲何ER圖重要呢，ER圖確認了模型，只要數據模型設計的好，代碼即使是有點問題也不會形成大問題。不要求嚴格遵循三範式，可是必定要明確哪些是主數據，哪些是冗餘的數據，冗餘數據有沒有更新機制，爲何冗餘必定要想清楚。
在如今微服務背景下，對於不會變動的數據若是能冗餘就冗餘下，減小對其餘方的調用
時序圖能明確系統間的調用，詳細完善的時序圖能幫助開發理清邏輯，經過時序圖能一眼就明白這個系統作了什麼，因此時序圖很重要
狀態圖爲啥重要呢，業務狀態機是事件驅動的，在業務狀態較多的狀況下，狀態機尤爲重要
3 架構設計好以後須要架構評審，評審須要架構師和測試同窗的參與。要確保這套架構師方便測試的，容易測試，能以在測試或者冒煙環境驗證的架構就是爛架構，穩定性無從談起
4 要有固定的評審模板checklist，確保不要遺漏任何應該注意的問題，架構評審checkList將架構設計的過程制度化流程化

編碼/開發測例完善
1 編碼必定要遵循開發規範，按照團隊規定開發原則或者嚴格要求遵循阿里開發規範編碼，若是是java語言須要強制要求全員安裝p3c插件；協同軟件的規範也很關鍵，好比git,要明確好團隊git等協做軟件的標準姿式
2 完善的測試用例能規避很多線上問題，經過測例檢查工具規範測試用例的完成狀況，不符合要求的不容許提測

測試用例評審
上一步講的是開發的自測測試用例，這一步說的是測試同窗的用例，不少人都會忽略這一步，這一步實際上是很關鍵的，QA同窗編寫好測試用例以後，
在評審的過程當中，開發同窗去檢查一下是否是兩邊有理解不一致的地方，有沒有gap能夠確保QA會測試到你寫的任何邏輯，有效保證系統穩定性

codeReview
代碼review不少團隊都搞不起來，緣由無非是由於以爲不必浪費時間，二來是沒有輕鬆的環境能作這塊，review成了大型懟人現場，因此團隊氛圍很重要，TL對這塊的引導很重要，codeReview的做用第一是看問題，看代碼可讀性怎麼樣，這塊沒有工具，只能人肉，在這個過程當中QA也能夠參與，至關於你們一塊兒白盒測試了
第二是引發你們的重視，若是你的代碼會被codereview，爲了避免丟人，質量確定會更高一點

灰度上線/發佈sop
1.上線後必定不能全量，在架構評審階段就要想好怎麼灰度，按照什麼維度灰度，要確認好灰度節奏。若是講bug無法避免，灰度而不是全量至少會將問題縮小，在灰度階段若是發現問題影響面更小
2.上線發佈須要嚴格遵照公司及部門的發佈sop，好比先發一臺機器，再慢慢發佈完一個機房，再全量等，還有發佈的時候要注意查看監控，有明確的回滾策略等

資損覈對
不少公司的研發流程都沒有資損覈對這一環,沒有工具作覈對，沒有專門的系統搞這塊，由於這塊確實會耗費人力，可是對於問題發現卻頗有必要，業務層和能力層的核對，主訂單和子訂單的核對，模板和業務的核對，數據存儲字段跟列值是否匹配等都能提早發現不少問題，對於穩定性至關重要。實時和離線的資損/覈對系統能發現系統性的風險，至關於給業務系統上了一道保險，

監控/報警和報表
1.監控系統如今是各公司的標配，在現有各大廠都是微服務背景是監控的重要不言而喻，對於穩定性最重要的實際上是監控系統中的打點告警，經過在代碼中植入打點，在監控系統配置各類類型的監控能夠有效的提升穩定性，好比調用突然變多，變少或者掉底，都有可能有潛在的問題，在用戶/業務反饋以前提早發現問題，解決問題是一個高可用系統必須的要求。
2.跟大數據計算相關的服務，要配置數據質量校驗腳本，對於olap類型任務，數據質量校驗應該是標配
3.監控報警能發現都是單個問題，T+1報表能從全局發現問題，同比環比分析能發現不少隱藏的點，尤爲是跟業務相關的，開發要站在全局視角看是否是有問題，雖然T+1晚了一天，沒有實時性，可是總比過了好幾天才發現問題要好。

覆盤/反思改進
代碼是人寫的，如上環節任何一環若是執行的不完全，都有可能有bug，出現bug必定要覆盤，覆盤的第一個做用反思改進流程，梳理總結踩過的坑，避免其餘人再踩，
第二個做用是經過流程化的覆盤，使得你們重視這塊

寫在最後

研發流程複雜，重要的是流程化，不論是體如今項目管理系統仍是走郵件都是很好的形式，要有儀式感，這本質是個管理問題，TL要經過一系列的流程來怪範，而不是靠本身督促 。機器是靠譜的，流程是靠譜的，人是不靠譜的，任何人爲沒有流程化，想到哪算哪的點都有問題如上基本上總結了整個研發流程的全部過程，這些點須要有開發去落實，只有全部的開發能意識到穩定性的重要性，並在激勵層面願意作那些看不見的地方，穩定性纔能有保證，團隊的執行力決定了系統的可靠性，因此本質上都是人的問題，靠譜有擔當而且能力強的開發纔是穩定系統的關鍵，一切能爲團隊找到高P開發的方法都是值得的