工程師意識
對有些同學來說,前兩週是非常忙碌的兩週。線上發生了幾起事故,雖不全是我們部門的,但很多同學也在羣策羣力的一起去解決、覆盤、改進。同時,我們上週也對部門H1的冒煙、事故進行了回顧。
我們希望通過對踩過坑的深度覆盤,去發現需要改進的點,然後下次不再犯同樣的錯誤。覆盤後發現,引發故障的原因中,變更佔比100%,其中代碼邏輯佔比45%,方案設計佔比15%。“變更是萬惡之源”。我們對變更的管理,有沒有達到10成的把握,這裏面有流程機制的問題,也有各位工程師的意識及執行的問題。流程機制上,我們想了一些對策,接下來會對變更三大件(技術方案 + Codereview + 上線回滾方案)進行強執行。接下來想談一談工程師意識和執行的問題。
回首這些冒煙和事故,是不是我們在技術方案設計的時候多考慮一下異常情況,就可以避免這次事故?是不是我們在自測的時候真正測試到改動的功能點、前後對比是否一致,就可以避免這次事故?是不是我們在寫每一行代碼的時候、認真的瞭解到調用的函數的副作用和運行機制,就可以避免這次事故?是不是我們在使用中間件的時候對實現機制有更透徹的瞭解和確認,是不是我們在巡檢的時候更細緻的檢查毛刺並追查原因,就可以避免這次事故?是不是我們沒有想當然,改過的配置真正去調一下接口,是不是就可以避免這次事故?
在我看來,一件事情沒有做到位,有兩方面原因。 一方面,是沒有這方面的意識,不知道應該這樣去做,如何去做。 另外一個方面,就是偷懶了,心存僥倖,但我們並不會一直這麼好運。根據墨菲定律,該發生的一定會發生。
對於工程師意識,百度已經有非常好的總結了,希望大家都每個字每個字的認真研讀,一個合格的工程師應該具備怎樣的意識。這都是前人的智慧,我們應該把它傳承下去。
- 質量意識
- 流程意識
- world class procedure:用流程解決具有共性的、重複性問題,提高效率
- 要對自己的工作質量負責,不要期待別人來發現自己的問題
- 不要“想當然”:
- 不要默認“沒問題”,而是缺省認爲“有問題”;“肯定沒問題”一定有問題
- “我以爲他們已經開始做,但我也沒有跟他們確認一下”—導致項目延期
- “我以爲這個接口是這樣定義,但誰想到是那樣的”—導致程序崩潰
- “我以爲發出郵件,他肯定就知道了”—實際上,他/她根本不在相應的郵件列表中
- 自我管理,自我推動
- 每件事情都有完成時間表,給自己一個約束,給別人一個承諾
- 每件事情有始有終,設立一些里程碑,在里程碑上檢查進度,主動向其他人通報進度
- 當面溝通,電話溝通,召集會議都是有效的形式,但要留下文字
- 如果沒有效果,應讓更多人知道,尤其是你的老闆和對方的老闆
- 杜絕“可能”,“大概”,“應該”這樣模棱兩可的用詞,而是用準確的數字和事實來論證
- Case study是一種文化,從事故中吸取經驗教訓
除了意識之外,我們還希望我們的工作夥伴有什麼樣的特質?
- 靠譜:凡事有交代,件件有着落,事事有迴音
- 別人交辦的事情,請第一時間給出預計完成的時間點。
- 過程之中注意按時通報進展。
- 如果預計要延遲,延遲多久,提前多久通報。
- 如果請求別人做事情,請給出期望完成的時間點。
- Ownership:高度負責,結果導向
- 對自己的代碼質量負責、線上系統負責,確保結果
- 對交辦的事情負責,確保結果
- 開發質量的保證,是自己的職責,不是測試的職責。寫優雅、可維護的代碼是自己的追求,決不妥協。
- 二八原則,確保自己的精力在解決主要問題,拿主要的結果
- 學會時間管理,4象限安排工作優先級,確保重要結果產出
- 工程師的核心競爭力就是解決問題的能力,不管你用什麼方法
- 認真負責,思考全面,提前計劃,步步爲營
- 自驅自發:我的工作我做主
- 不要等別人爲你分配任務,你就是自己的老闆
- 主動承擔更多的職責、主動學習更多的知識
- 自己盡力都搞不定的事情及時尋求幫助
- No Excuse,實事求是:不怕犯錯,不找藉口,主動反思,持續改進
- 主動溝通,善於協作
- 報喜亦報憂,確保協作方信息的及時性、有效性
- 主動語音聊,電話聊,跟進聊
希望我們的工程師,都具備以上工作準則,作爲球隊的不可或缺的一員,各自發揮自己的才能,一起贏!!!