如何成為優(yōu)秀的技術主管？你要做到這三點
技術主管，又叫「技術經(jīng)理」，英文一般是 Tech Leader ，簡稱 TL。隨著工作經(jīng)驗的不斷積累，能力的不斷提升，每個人都有機會成為Team Leader。然而在機會到來前，我們必須提前做好準備，對TL的工作職責有一定了解。當然，這也會為當下更好地配合TL工作打下基礎。
今天，阿里巴巴高級技術專家云狄將結合自己多年的經(jīng)驗，從開發(fā)規(guī)范、開發(fā)流程、技術規(guī)劃與管理三個角度出發(fā)，分享對技術TL這一角色的理解與思考，歡迎一起探討交流。
「技術主管」是開發(fā)團隊中的某位程序員需要對一起創(chuàng)建系統(tǒng)的整個開發(fā)團隊負責時所承擔的角色。通常他既要對最終交付的軟件系統(tǒng)負責，另外也會像一個程序員一樣去開發(fā)實現(xiàn)系統(tǒng)。
一個技術主管的 60% ～ 70% 的時間可能花在了開發(fā)任務分解分配、開發(fā)實踐、技術架構評審、代碼審核和風險識別上，而余下的 30% ～ 40% 的時間則花在為了保障系統(tǒng)按時交付所需的各種計劃、協(xié)作、溝通、管理上。和團隊管理者不同的是，技術主管的大部分管理工作都是針對具體研發(fā)任務和技術事務的。
接下來基于我在技術TL這個角色上，在開發(fā)規(guī)范、開發(fā)流程、技術管理與規(guī)劃等方面我的一些心路歷程，和大家共勉。
一、開發(fā)規(guī)范
我當時負責的業(yè)務是集團收購一家子公司的業(yè)務，在整體技術標規(guī)范上與集團的技術標準存在很大的差異。開發(fā)規(guī)范可以說是我來到這個團隊干的頭一件事，我當時面對的問題是API接口格式混亂，沒有標準的RPC服務化，代碼沒有統(tǒng)一標準的開發(fā)規(guī)范，技術框架組件非標準化等一系列問題，作為一名業(yè)務上的新人，我趕快制定了一套相對標準、全面的技術開發(fā)規(guī)范，邊寫代碼邊梳理開發(fā)規(guī)范，帶領團隊走向統(tǒng)一標準化開發(fā)道路。
針對團隊研發(fā)規(guī)范暴露的上述問題，主要制定了如下規(guī)范：
命名規(guī)范
我自己非常注重搭建項目結構的起步過程，應用命名規(guī)范、模塊的劃分、目錄（包）的命名，我覺得非常重要，如果做的足夠好，別人導入項目后可能只需要10分鐘就可以大概了解系統(tǒng)結構。
具體規(guī)范包括包命名、類的命名、接口命名、方法命名、變量命名、常量命名。
統(tǒng)一IDE代碼模板
約定了IDEA/Eclipse IDE代碼的統(tǒng)一模板，代碼風格一定要統(tǒng)一，避免不同開發(fā)人員使用不同模板帶來的差異化以及代碼merge成本。使用IDEA的同學可以安裝Eclipse Code Formatter插件，和Eclipse統(tǒng)一代碼模板。
Maven使用規(guī)范
所有二方庫、三方庫的版本統(tǒng)一定義到parent pom里，這樣來所有業(yè)務應用工程統(tǒng)一繼承parent pom里所指定的二方庫、三方庫的版本，統(tǒng)一框架與工具的版本(Spring、Apache commons工具類、日志組件、JSON處理、數(shù)據(jù)庫連接池等)，同時要求生產(chǎn)環(huán)境禁用SNAPSHOT版本。這樣以來升級通用框架與工具的版本，只需要應用工程升級parent pom即可。
代碼Commit規(guī)范
基于Angular Commit Message規(guī)范生成統(tǒng)一的ChangeLog，這樣一來對于每次發(fā)布release tag非常清晰，Mac下都需要安裝對應的插件，IDEA也有對應的插件，具體可以參考阮一峰老師的《Commit message 和 Change log 編寫指南》。
此刻忽然想起Linus面對pull request里的騷操作所發(fā)的飚：
Get rid of it. And I don’t ever want to see that shit again. ——Linus
代碼的commit的規(guī)范對團隊非常重要，清晰的commit信息生成的release tag，對于生產(chǎn)環(huán)境的故障回滾業(yè)非常關鍵，能夠提供一些有價值的信息。????
統(tǒng)一API規(guī)范
統(tǒng)一Rpc服務接口的返回值ResultDTO,具體代碼如下：?? 
Http Rest接口規(guī)范約定同ResultDTO相差無幾，需要額外關注一下加解密規(guī)范和簽名規(guī)范、版本管理規(guī)范。
異常處理規(guī)范
異常處理不僅僅是狹義上遇到了Exception怎么去處理，還有各種業(yè)務邏輯遇到錯誤的時候我們怎么去處理。service服務層捕獲的異常主要包括BusinessException(業(yè)務異常)、RetriableException (可重試異常) 到 common-api，定義一個公共異常攔截器，對業(yè)務異常、重試異常進行統(tǒng)一處理，對于可重試的異常調用的服務接口需要保證其冪等性。
另外其他業(yè)務層有些特殊異常不需要攔截器統(tǒng)一處理，內部可以進行自我消化處理掉，根據(jù)場景對應的處理原則主要包括：
- 直接返回
- 拋出異常
- 重試處理
- 熔斷處理
- 降級處理
這又涉及到了彈力設計的話題，我們的系統(tǒng)往往會對接各種依賴外部服務、Api，大部分服務都不會有SLA，即使有在大并發(fā)下我們也需要考慮外部服務不可用對自己的影響，會不會把自己拖死。我們總是希望：
盡可能以小的代價通過嘗試讓業(yè)務可以完成；
如果外部服務基本不可用，而我們又同步調用外部服務的話，我們需要進行自我保護直接熔斷，否則在持續(xù)的并發(fā)的情況下自己就會垮了；
如果外部服務特別重要，我們往往會考慮引入多個同類型的服務，根據(jù)價格、服務標準做路由，在出現(xiàn)問題的時候自動降級。
推薦使用Netflix開源的hystrix容災框架，主要解決當外部依賴出現(xiàn)故障時拖垮業(yè)務系統(tǒng)、甚至引起雪崩的問題。目前我團隊也在使用，能夠很好的解決異常熔斷、超時熔斷、基于并發(fā)數(shù)限流熔斷的降級處理。
分支開發(fā)規(guī)范
早期的時候源碼的版本管理基于 svn，后來逐步切換到 git，分支如何管理每一個公司（在Gitflow的基礎上）都會略有不同。
針對分支開發(fā)規(guī)范，指定如下標準：
- 分支的定義（master、develop、release、hotfix、feature）
- 分支命名規(guī)范
- checkout、merge request流程
- 提測流程
- 上線流程
- Hotfix流程
雖然這個和代碼質量和架構無關，按照這一套標準執(zhí)行下來，能夠給整個研發(fā)團隊帶領很大的便利：
減少甚至杜絕代碼管理導致的線上事故；
提高開發(fā)和測試的工作效率，人多也亂；
減少甚至杜絕代碼管理導致的線上事故；
方便運維處理發(fā)布和回滾；
讓項目的開發(fā)可以靈活適應多變的需求，多人協(xié)同開發(fā)。
統(tǒng)一日志規(guī)范
日志是產(chǎn)品必不可少的一個功能，具備可回溯性、能夠抓取問題現(xiàn)場信息是其優(yōu)點，尤其在生產(chǎn)系統(tǒng)上問題定位等方面具有不可替代的作用。
這里著重強調一下針對異常的日志規(guī)范：
WARN和ERROR的選擇需要好好考慮，WARN一般我傾向于記錄可自恢復但值得關注的錯誤，ERROR代表了不能自己恢復的錯誤。對于業(yè)務處理遇到問題用ERROR不合理，對于catch到了異常也不是全用ERROR。
記錄哪些信息，打印一定的上下文（鏈路TraceId、用戶Id、訂單Id、外部傳來的關鍵數(shù)據(jù)）而不僅僅是打印線程棧。
記錄了上下問信息，是否要考慮日志脫敏問題？可以在框架層面實現(xiàn)，比如自定義實現(xiàn)logback的ClassicConverter。
正確合理的使用日志，能夠指引開發(fā)人員快速查找錯誤、定位問題，因此約定了一套日志使用標準規(guī)范，現(xiàn)在可以更多的參考《阿里經(jīng)濟體開發(fā)規(guī)約——日志規(guī)約》。
統(tǒng)一MYSQL開發(fā)規(guī)范
表的設計和 Api 的定義類似，屬于那種開頭沒有開好，以后改變需要花10x代價的，我知道，一開始在業(yè)務不明確的情況下，設計出良好的一步到位的表結構很困難，但是至少我們可以做的是有一個好的標準。
二、統(tǒng)一工具與框架
對開發(fā)過程中所用到的公共組件進行了統(tǒng)一抽象與封裝，包括 dao 層框架mybatis、cache 組件 jetcache、httpclien t組件、common-tools (公共工具)，同時抽取出全局ID、分布式鎖、冪等等公共組件，把以上公共組件進行集成到各個應用，進行統(tǒng)一升級、維護，這樣以來方便大家將更多的精力集中到業(yè)務開發(fā)上。????
開發(fā)流程
目前團隊的開發(fā)模式還是基于傳統(tǒng)的瀑布開發(fā)模式，整體開發(fā)流程涉及需求評審、測試用例評審、技術架構評審、開發(fā)與測試、驗收與上線，這里主要基于TL的角度從需求管理、技術架構評審、代碼評審、發(fā)布計劃評審幾個關鍵重點環(huán)節(jié)進行探討，歡迎拍磚。
需求管理
美國專門從事跟蹤IT項目成功或失敗的權威機構 Standish Group的CHAOS Reports 報導了該公司的一項研究，該公司對多個項目作調查后發(fā)現(xiàn)，百分之七十四的項目是失敗的，既這些項目不能按時按預算完成。其中提到最多的導致項目失敗的原因就是"變更用戶需求"。另外從歷年的 Standish Group 報告分析看，導致項目失敗的最重要原因與需求有關。Standish Group 的CHAOS 報告進一步證實了與成功項目最密切的因素是良好的需求管理，也就是項目的范圍管理，特別是管理好項目的變更。
產(chǎn)品因需求而生，在產(chǎn)品的整個生命周期中，產(chǎn)品經(jīng)理會收到來自各個方面的需求，但是每一個需求的必要性、重要性和實現(xiàn)成本都需要經(jīng)過深思熟慮的分析和計劃，避免盲目的決定需求或者變更需求，這樣很容易導致工作混亂，技術TL如果不能正確的對需求進行把控，會導致整個項目偏離正確的軌道。
需求管理的就是要梳理不同來源的需求，主要包括從產(chǎn)品定位出發(fā)、外部用戶反饋、競爭對手情況、市場變化以及內部運營人員、客服人員、開發(fā)人員的反饋。首先技術TL對產(chǎn)品有足夠認知和把控，簡單來說就是我的產(chǎn)品是為了滿足哪些人的哪些需求而做，產(chǎn)品需求一定要根植于客戶的需求、根植于客戶的環(huán)境。每款產(chǎn)品必定有其核心價值，能夠為客戶創(chuàng)造更多的價值，基于此考慮往往能得到一些核心需求，摒除價值不大的需求。
需求管理中最重要的就是對發(fā)散性需求的管理，往往因此也會導致產(chǎn)品在執(zhí)行過程中不斷的變更或增加需求。由于人的思維是發(fā)散性的，所以往往在產(chǎn)品構思的過程中會出現(xiàn)各種新鮮好玩的想法，這些想法可能來自領導或者產(chǎn)品經(jīng)理自己，但是這些想法往往都是和產(chǎn)品核心方向不相關的，但是由于這些想法能夠在當時帶來誘惑，因此這些不相關的需求會嚴重干擾了技術團隊的精力，打亂或者延誤產(chǎn)品原本的計劃。同樣技術研發(fā)同學也需要建立對產(chǎn)品的深度思考，不要把自己定位成產(chǎn)品需求的實現(xiàn)者，同樣需要對需求負責。
很多時候需求的變更或增加是因為我們面臨太多選擇和想要的太多，沒有適當?shù)目刂谱约旱挠?，并以自己的喜好來決定需求，這些因素很容易導致產(chǎn)品沒有明確的方向、團隊成員疲于奔命，但是卻沒有實際的成果。所以技術TL一定要能夠評估出重新審視產(chǎn)品和篩選需求的優(yōu)先級，識別每一個需求的必要性、重要性和實現(xiàn)成本。通過深思熟慮給團隊明確方向并專注，聚焦資源的支配，確保團隊的精力都聚焦在產(chǎn)品的核心需求上。
技術架構評審
互聯(lián)網(wǎng)時代，大家提倡敏捷迭代，總嫌傳統(tǒng)方式太重，流程復雜，影響效率，什么都希望短平快，在扁平化的組織中，經(jīng)常是需求火速分發(fā)到一線研發(fā)，然后就靠個人折騰去了，其實技術架構評審這同樣是一個非常重要的環(huán)節(jié)。架構評審或技術方案評審的價值在于集眾人的力量大家一起來分析看看方案里是否有坑，方案上線后是否會遇到不可逾越的重大技術問題，提前盡可能把一些事情先考慮到提出質疑其實對項目的健康發(fā)展有很大的好處。????
基于架構評審，我們的目標核心是要滿足以下幾點：
1. 設計把關，確保方案合格，各方面都考慮到了，避免缺陷和遺漏，不求方案多牛，至少不犯錯。
2. 保證架構設計合理和基本一致，符合整體原則。
3. 維持對系統(tǒng)架構的全局認知，避免黑盒效應。
4. 通過評審發(fā)掘創(chuàng)新亮點，推廣優(yōu)秀實踐。
架構設計既要保證架構設計的合理性和可擴展性，又要避免過度設計。架構設計不僅僅是考慮功能實現(xiàn)，還有很多非功能需求，以及持續(xù)運維所需要的工作，需要工程實踐經(jīng)驗，進行平衡和取舍。
架構評審需要以下幾點：
1. 技術選型：為什么選用A組件不選用B、C組件，A是開源的，開源協(xié)議是啥？基于什么語言開發(fā)的，出了問題我們自身是否能夠維護？性能方面有沒有壓測過？這些所有問題作為技術選型我們都需要考慮清楚，才能做最終決定。
2. 高性能：產(chǎn)品對應的TPS、QPS和RT是多少？設計上會做到的TPS、QPS和RT是多少？而實際上我們整體隨著數(shù)據(jù)量的增大系統(tǒng)性能會不會出現(xiàn)明顯問題？隨著業(yè)務量、數(shù)據(jù)量的上升，我們的系統(tǒng)的性能如何去進一步提高？系統(tǒng)哪個環(huán)節(jié)會是瓶頸？是否有抗突發(fā)性能壓力的能力，大概可以滿足多少的TPS和QPS，怎么去做來實現(xiàn)高性能，這些問題都需要我們去思考。
3. 高可用：是否有單點的組件，非單點的組件如何做故障轉移？是否考慮過多活的方案？是否有數(shù)據(jù)丟失的可能性？數(shù)據(jù)丟失如何恢復？出現(xiàn)系統(tǒng)宕機情況，對業(yè)務會造成哪些影響？有無其他補救方案？這些問題需要想清楚，有相應的解決方案。
4. 可擴展性：A和B的業(yè)務策略相差無幾，后面會不會繼續(xù)衍生出C的業(yè)務策略，隨著業(yè)務的發(fā)展哪些環(huán)節(jié)可以做擴展，如何做擴展？架構設計上需要考慮到業(yè)務的可擴展性。
5. 可伸縮性：每個環(huán)節(jié)的服務是不是無狀態(tài)的？是否都是可以快速橫向擴展的？擴容需要怎么做手動還是自動？擴展后是否可以提高響應速度？這所有的問題都需要我們去思考清楚，并有對應的解決方案。
6. 彈性處理：消息重復消費、接口重復調用對應的服務是否保證冪等？是否考慮了服務降級？哪些業(yè)務支持降級？支持自動降級還是手工降級？是否考慮了服務的超時熔斷、異常熔斷、限流熔斷？觸發(fā)熔斷后對客戶的影響？服務是否做了隔離，單一服務故障是否影響全局？這些問題統(tǒng)統(tǒng)需要我們想清楚對應的解決方案，才會進一步保證架構設計的合理性。
7. 兼容性：上下游依賴是否梳理過，影響范圍多大？怎么進行新老系統(tǒng)替換？新老系統(tǒng)能否來回切換？數(shù)據(jù)存儲是否兼容老的數(shù)據(jù)處理？如果對你的上下游系統(tǒng)有影響，是否通知到上下游業(yè)務方？上下游依賴方進行升級的方案成本如何最小化？這些問題需要有良好的解決方案，稍有不慎會導致故障。
8. 安全性：是否徹底避免SQL注入和XSS？是否有數(shù)據(jù)泄露的可能性？是否做了風控策略？接口服務是否有防刷保護機制？數(shù)據(jù)、功能權限是否做了控制？小二后臺系統(tǒng)是否做了日志審計？數(shù)據(jù)傳輸是否加密驗簽？應用代碼中是否有明文的AK/SK、密碼？這些安全細節(jié)問題需要我們統(tǒng)統(tǒng)考慮清楚，安全問題任何時候都不能輕視。
9. 可測性：測試環(huán)境和線上的差異多大？是否可以在線上做壓測？線上壓測怎么隔離測試數(shù)據(jù)？是否有測試白名單功能？是否支持部署多套隔離的測試環(huán)境？測試黑盒白盒工作量的比例是怎么樣的？新的方案是否非常方便測試，在一定程度也需要考量。
10. 可運維性：系統(tǒng)是否有初始化或預熱的環(huán)節(jié)？數(shù)據(jù)是否指數(shù)級別遞增？業(yè)務數(shù)據(jù)是否需要定期歸檔處理？隨著時間的推移如果壓力保持不變的話系統(tǒng)需要怎么來巡檢和維護？業(yè)務運維方面的設計也需要充分考慮到。
11. 監(jiān)控與報警：對外部依賴的接口是否添加了監(jiān)控與報警？應用層面系統(tǒng)內部是否有暴露了一些指標作監(jiān)控和報警？系統(tǒng)層面使用的中間件和存儲是否有監(jiān)控報警？只有充分考慮到各個環(huán)節(jié)的監(jiān)控、報警，任何問題會盡快通知到研發(fā)，阻止故障進一步擴散。
其實不同階段的項目有不同的目標，我們不會在項目起步的時候做99.99%的可用性支持百萬QPS的架構，高效完成項目的業(yè)務目標也是架構考慮的因素之一。而且隨著項目的發(fā)展，隨著公司中間件和容器的標準化，很多架構的工作被標準化替代，業(yè)務代碼需要考慮架構方面伸縮性運維性等等的需求越來越少，慢慢的這些工作都能由架構和運維團隊來接。一開始的時候我們可以花一點時間來考慮這些問題，但是不是所有的問題都需要有最終的方案。
代碼評審
代碼質量包括功能性代碼質量和非功能性代碼質量，功能質量大多通過測試能夠去發(fā)現(xiàn)問題，非功能性代碼質量用戶不能直接體驗到這種質量的好壞，代碼質量不好，最直接的“受害者”是開發(fā)者或組織自身，因為代碼質量好壞直接決定了軟件的可維護性成本的高低。代碼質量應該更多的應該從可測性，可讀性，可理解性，容變性等代碼可維護性維度去衡量，其中 CodeReview 是保證代碼質量非常重要的一個環(huán)節(jié)，建立良好的 CodeReview 規(guī)范與習慣，對于一個技術團隊是一件非常重要核心的事情，沒有 CodeReview 的團隊沒有未來。
每次項目開發(fā)自測完成后，通常會組織該小組開發(fā)人員集體進行代碼 review，代碼 review 一般 review 代碼質量以及規(guī)范方面的問題，另外需要關注的是每一行代碼變更是否與本次需求相關，如果存在搭車發(fā)布或者代碼重構優(yōu)化，需要自行保證測試通過，否則不予發(fā)布。????
CodeReview 我會重點關注如下事情：
1. 確認代碼功能：代碼實現(xiàn)的功能滿足產(chǎn)品需求，邏輯的嚴謹和合理性是最基本的要求。同時需要考慮適當?shù)臄U展性，在代碼的可擴展性和過度設計做出權衡，不編寫無用邏輯和一些與代碼功能無關的附加代碼。
在真正需要某些功能的時候才去實現(xiàn)它，而不是你預見到它將會有用。 —— RonJeffries
2. 編碼規(guī)范：以集團開發(fā)規(guī)約、靜態(tài)代碼規(guī)約為前提，是否遵守了編碼規(guī)范，遵循了優(yōu)秀實踐。除了形式上的要求外，更重要的是命名規(guī)范。目標是提高代碼的可讀性，降低代碼可維護性成本。
3. 潛在的BUG：可能在最壞情況下出現(xiàn)問題的代碼，包括常見的線程安全、業(yè)務邏輯準確性、系統(tǒng)邊界范圍、參數(shù)校驗，以及存在安全漏洞(業(yè)務鑒權、灰產(chǎn)可利用漏洞)的代碼。。
4. 文檔和注釋：過少（缺少必要信息）、過多（沒有信息量）、過時的文檔或注釋，總之文檔和注釋要與時俱進，與新的代碼保持同步。其實很多時候個人覺得良好的變量、函數(shù)命名是好的注釋，好的代碼勝過注釋。
5. 重復代碼：當一個項目在不斷開發(fā)迭代、功能累加的過程中，重復代碼的出現(xiàn)幾乎是不可避免的，通常可以通過PMD工具進行檢測。類型體系之外的重復代碼處理通?？梢苑庋b到對應的Util類或者Helper類中，類體系之內的重復代碼通?？梢酝ㄟ^繼承、模板模式等方法來解決。
6. 復雜度：代碼結構太復雜（如圈復雜度高），難以理解、測試和維護。
7. 監(jiān)控與報警：基于產(chǎn)品的需求邏輯，需要有些指標來證明業(yè)務是正常work的，如果發(fā)生異常需要有監(jiān)控、報警指標通知研發(fā)人員處理，review業(yè)務需求對應的監(jiān)控與報警指標也是Code Review的重點事項。
8. 測試覆蓋率：編寫單元測試，特別是針對復雜代碼的測試覆蓋是否足夠。
實際上維護單元測試的成本不比開發(fā)成本低，這點團隊目前做的的不到位。
針對以上每次代碼review所涉及到的經(jīng)典案例會統(tǒng)一輸出到文檔里，大家可以共同學習避免編寫出同樣的Ugly Code。
發(fā)布計劃評審
涉及到10人日以上的項目，必須有明確的發(fā)布計劃，并組織項目成員統(tǒng)一參加項目發(fā)布計劃review，發(fā)布計劃主要包含如下幾點：
1）明確是否有外部依賴接口，如有請同步協(xié)調好業(yè)務方；
2）發(fā)布前配置確認包括配置文件、數(shù)據(jù)庫配置、中間件配置等各種配置，尤其各種環(huán)境下的差異化配置項；
3）二方庫發(fā)布順序，是否有依賴；
4）應用發(fā)布順序；
5）數(shù)據(jù)庫是否有數(shù)據(jù)變更和訂正，以及表結構調整；
6）回滾計劃，必須要有回滾計劃，發(fā)布出現(xiàn)問題要有緊急回滾策略；
7）生產(chǎn)環(huán)境回歸測試重點Case。
三、技術規(guī)劃與管理
我在帶技術團隊的這些年，對團隊一直有一個要求，每周都要做系統(tǒng)健康度巡檢，未雨綢繆、晴天修屋頂，避免在極端場景下某些隱藏的bug轉變成了故障。
系統(tǒng)健康度巡檢
為什么要把系統(tǒng)健康度巡檢放到技術管理里，我覺得這是一個非常重要的環(huán)節(jié)。像傳統(tǒng)的航空、電力、汽車行業(yè)都要有一定的巡檢機制，保障設備系統(tǒng)正常運轉，同樣軟件系統(tǒng)也同樣需要巡檢機制保障業(yè)務健康發(fā)展。
隨著業(yè)務的不斷發(fā)展，業(yè)務量和數(shù)據(jù)量不斷的上漲，系統(tǒng)架構的腐蝕是避免不了的，為了保障系統(tǒng)的健康度，需要不斷的考慮對系統(tǒng)架構、性能進行優(yōu)化。
系統(tǒng)的監(jiān)控與報警能夠一定程度發(fā)現(xiàn)系統(tǒng)存在的問題，系統(tǒng)存在的一些隱患需要通過對系統(tǒng)的巡檢去發(fā)現(xiàn)，如果優(yōu)化不及時在極端情況會導致故障，巡檢粒度建議每周巡檢一次自己所負責的業(yè)務系統(tǒng)。
系統(tǒng)巡檢重點要關注如下幾點：
系統(tǒng)指標：系統(tǒng)CPU、負載、內存、網(wǎng)絡、磁盤有無異常情況波動，確認是否由發(fā)布導致，還是系統(tǒng)調用異常。
慢接口：通常rt大于3s的接口需要重點關注，極端并發(fā)場景下容易導致整個系統(tǒng)雪崩。
慢查詢：MYSQL慢查詢需要重點關注，隨著數(shù)據(jù)量上漲，需要對慢查詢進行優(yōu)化。
錯誤日志：通過錯誤日志去發(fā)現(xiàn)系統(tǒng)隱藏的一些bug，避免這些bug被放大，甚至極端情況下會導致故障。
技術規(guī)劃
技術規(guī)劃通常由團隊的TL負責，每個財年TL需要從大局的角度去思考每個季度的技術優(yōu)化規(guī)劃，去償還技術債，技術債也是有利息的，因為利息的存在，技術債務不及時償還的話，會在未來呈現(xiàn)出非線性增長，造成始料不及的損失。
這里的技術規(guī)劃包括如下幾點：
架構優(yōu)化：一些結構不良、低內聚高耦合的代碼則會使得哪怕是微小的需求變更或功能擴展都無從下手，修改的代價很可能超過了重寫的代價。同樣系統(tǒng)之間的耦合也需要重點去關注，遵循微服務化的原則，系統(tǒng)也要遵循單一職責原則，對于職責不清晰的系統(tǒng)去做解耦優(yōu)化，進行一些模塊化改造、服務隔離、公用服務抽象。
性能優(yōu)化：基于財年對于業(yè)務量、數(shù)據(jù)量的發(fā)展評估，根據(jù)目前系統(tǒng)服務的QPSRT,需要提前規(guī)劃對系統(tǒng)性能進行一些升級策略，包括重點關注對一些慢接口、慢查詢的優(yōu)化。
彈性與可靠性：系統(tǒng)提供的服務需要保障括數(shù)據(jù)一致性、冪等，同時也需要從熔斷降級、異地多活的角度去考慮存在哪些問題，目前系統(tǒng)的SLA指標是否能夠達到高可用，需要做哪些優(yōu)化保障系統(tǒng)的高可用。
可伸縮：應用服務是否保證無狀態(tài)，關鍵節(jié)點發(fā)生故障能夠快速轉移、擴容，避免故障擴大化。
總結
大家不知道有沒有類似的經(jīng)歷，某個時間段突然一些線上故障頻發(fā)，各種技術債、業(yè)務債被業(yè)務方窮追猛打要求還債，如果出現(xiàn)這種現(xiàn)象很大程度這個TL已經(jīng)失位了，這個團隊失控了。也曾經(jīng)有人跟我吐槽他的TL把活都分給他們，而TL自己什么都不干！這個技術TL真的什么都不干？曾經(jīng)有一段時間我也在思考技術TL的核心職責到底是什么？技術TL應該具備哪些素質？
首先技術說到底是為業(yè)務服務的，除非技術就是業(yè)務本身，必須體現(xiàn)它的商業(yè)價值。在很多公司里技術研發(fā)真的就成了實現(xiàn)其他部門需求的工具，我覺得這樣的技術TL肯定是不合格的。首先它不能影響業(yè)務發(fā)展，需求提出方會經(jīng)過很多轉化，如果不是不假思索傳遞需求，整個過程會失真。
第二個，我認為最最重要的是架構設計的能力，可能管理能力還次之。對于管理能力我認為最重要的是對團隊的感知能力，因為一旦到了技術TL這個級別，不能脫離一線太遠，業(yè)務細節(jié)可以不清楚，大的方向必須要明確。如果沒有很細膩的感知能力，很多的決策會有偏差。
如果他不是一個業(yè)務架構師，不是一個能給團隊指明更好方向的人，他最終會淪為一個需求翻譯器，產(chǎn)品經(jīng)理說怎么做就怎么做。他更多的只是負責保證產(chǎn)品的質量、開發(fā)的速度，最終被肢解成一個很瑣碎的人。一旦團隊上了一定的規(guī)模，團隊就會從單純的需求實現(xiàn)走向團隊運營，而運營是需要方向的，業(yè)務架構就是一個基于運營和數(shù)據(jù)的一種綜合的能力。
關于技術層面，技術TL需要具備如下素養(yǎng)：
技術視野良好，解決問題能力與架構設計能力出色。
技術TL要有良好的技術視野，不需要各種技術都樣樣精通，但是必須要所有涉獵，有所了解，對各種技術領域的發(fā)展趨勢，主流非主流技術的應用場景要非常了解。知道在什么場景應用什么技術，業(yè)務發(fā)展到什么規(guī)模應該預先做哪些技術儲備。產(chǎn)品架構的設計要有足夠的彈性，既能夠保證當前開發(fā)的高效率，又能夠對未來產(chǎn)品架構的演進留出擴展的余地。
動手能力要強，學習能力出色。
技術TL并不需要自己親自動手寫代碼，但是如有必要，自己可以隨時動手參與一線的編碼工作，技術TL不能長期遠離一線工作，自廢武功，紙上談兵。否則長此以往，會對技術的判斷產(chǎn)生嚴重的失誤。另外，技術TL也應該是一個學習能力非常出色的人，畢竟IT行業(yè)的技術更新?lián)Q代速度非?？?，如果沒有快速學習能力，是沒有資格做好技術TL的。
技術TL除了管人和管事之外，其他還有很多事情要做包括建立團隊研發(fā)文化、團隊人才培養(yǎng)與建設、跨部門協(xié)調與溝通等，這樣以要求技術TL也同時也需要具備良好的溝通和管理能力，以上觀點僅是個人的一些思考和觀點，僅供參考。
