2020 年轉眼結束了，本想寫年終總結和新年計劃，卻發現 2020 年除了技術進步，還總結了不少我自己的「工作技巧」，或者也可以叫做「工作守則」。我遵循著這些實踐中總結出來的方法工作，為我自己以及我所在的崗位，帶來了不小的時間效益和經濟效益。
當然，適合自己的才是最好的，我不喜歡一味模仿其它人，希望你也帶著這種想法讀這篇部落格。
沒有固定的計劃，只有 Todo、Doing 和 Done
有不少人曾向我推薦時間規劃 — 計劃每天每段時間應該做什麼。嘗試過後發現其實不適合我。相較於研發、科研崗位通常會制定長期的開發目標、論文目標；作為一名 DevOps 工程師，日常工作更多時候是在不斷地發現問題和解決問題。
因此，我更傾向於把待辦事項拆分成 Tickets，並使用 Kanban 管理它們。我的 Kanban 內通常包含幾列：
- LONG TERM：不緊急的、可以未來再做的任務。通常來源是在工作中發現的可優化項，或是來自同事的需求但調研後發現暫時不太容易解決的事。
- TODO：需要儘快完成的任務。通常來源是比較重要、緊急的需求。
- DOING：正在做的事。
- STALLED：由於外部因素暫停的任務。比如需要等待某個 PR 合併、等待同事的確認回覆等。
- DONE：已完成的任務。
有了 Kanban，我的工作流就清晰了：
當新需求出現時，我會檢視現在的 TODO 和 LONG TERM 有沒有類似的事；如果需要服務下線維護，我會查詢是否有可以一併在同一次維護中完成的任務，儘可能減少下線次數。
開始工作前，我會瀏覽一遍 TODO 和 LONG TERM，根據任務的重要和緊急程度，調整它們的先後順序、優先順序等；因為在實際工作過程中，很多工隨著時間推移、技術迭代、市場和產品計劃調整，可能瞬間從 LONG TERM 上升為較緊急，也可能從 TODO 直接消失，被 Archive。
我還會時不時看看 STALLED，這一列能幫助我管理和推動那些受到外部因素影響而不能立刻完成的任務，譬如等待開源專案的 Bugfix PR 合併，等待同事的答覆之類；這樣，我可以定期去 PR 催一下合併、提醒一下同事，進而推動「外部力量」儘快解決問題，避免我的任務長期由於外部原因拖延。
最後，當我認為某個事項是 DONE，那麼它一定是以下三種狀態之一：
- 已達成最初目的、解決了問題；或
- 未解決問題但準備了可行的折中方案；或
- 無法解決問題，並給出設想方案以及不可行的理由。
遇到問題要講，主動溝通並持續跟進
工作過程中遇到不熟悉的內容很常見。在著手新事項的第一時間，我可能會有大量的疑問。這些疑問大多是我在構想接下來應該怎麼做時，結合類似事項的經驗和經歷，提前預期到的。在開始做之前我會先問清楚這些問題；如果對方不能及時解答，或是指派給其他人解答，要主動地持續跟進。提醒自己 — 這些問題的答案有助於我工作的完成，我需要這些答案。
即時通訊降低了某些場景下的溝通成本，但同時也讓按下傳送鍵前一刻的思考變少了。為了提高詢問他人時的溝通效率，我一般會遵循這幾個原則：
- 將多個小問題合併成一條訊息傳送，避免對方遺漏訊息。
- 使用
1. 2. 3.數字編號，當問題之間有依賴關係時方便引用，同時對方能夠根據編號回答，不容易遺漏或跑題。 - 傳送需要複製貼上的內容時（例如報錯資訊 — 可能對方需要複製到 Google 內搜尋），不要截圖；同時儘可能使用程式碼格式，避免對方不小心複製多餘的內容，且能提升訊息閱讀體驗。
- 傳送之前，快速瀏覽一遍訊息，整理句子結構，避免冗餘的話術，確保排版格式正確，把即時訊息當作一封對方几小時後才能回覆你的郵件。
不進行沒有結果的討論，討論結束要有切實可行的「下一步」
當我認為即時訊息無法快速討論問題，或是有過多細節需要「頭腦風暴」快速交換想法時，我會發起一次討論或者會議。為了能夠快速推動進度，我通常會在接近會議尾聲時簡單總結，大致結構是：
「某人」應當在「某時間內」完成「某事」，過程中可尋求「某某」的幫助。
因此，會議結束後，參會同事能清楚地知道：自己下一步要做什麼、需要與誰協作、產出什麼結果。避免 A 以為 B 會做，B 以為 A 會做，再加上雙方欠缺溝通，結果誰都沒做的尷尬局面。
明確有時比優雅更重要
作為程式設計師，解決問題的過程中少不了寫程式碼。雖然有不少人堅持程式碼應該優雅而完美，而我認為某些時候明確比優雅更重要。當兩方衝突時，我需要權衡並儘可能取得平衡。例如以下幾個具體場景：
- 使用最簡化的預設值，當預設引數無法正常執行時，通過報錯引導使用者顯式地調整某個值，而不是隱式地自動修改預設值 —— 讓使用者逐漸熟悉配置，避免「雖然能執行，卻留下了未來才能發現的暗坑」。
- 當某個檔案不得不復制貼上時，在新舊副本各新增一段註釋，表示該檔案應當與另一處保持同步 —— 當未來的我或其他同事接手時，儘量避免潛在的問題。
- 讓邏輯儘可能簡單直觀、符合直覺 —— 在出現緊急問題需要修復時，我很難快速理解、回憶複雜的邏輯。
- 命名具有足夠清晰的指向性，使用
storageSize而不是storage，timeoutSeconds而不是timeout—— 便於理解且減少未來的 breaking changes。 - 版本限定儘可能嚴謹，能指定具體版本就不使用 latest，不通過複用 latest 來節約映象倉庫大小。
不要偷懶
不要偷懶體現在很多細節上，是需要長期堅持才能看到效果的過程。往往做的時候額外消耗了一些精力，但在未來或是時間緊急的時候，之前投入的回報率會很高。比如：
- 在 Commit Messages 上精確地概括改動的內容，附上相關的 Issue 連結、參考資料。當幾個月後我回憶起相關問題時，能夠快速定位相關 Commit，且有證據證明當時為什麼要這麼做。
- 發生生產環境事故後，覆盤並總結調查報告。事故的發生往往不是單一原因造成的，我的記憶不足以支撐我記住曾經事故的全過程，我選擇將它們記下來。
- 除了備份，還要做好演練，編寫成文件。需要緊急恢復環境時，每分每秒都非常寶貴，有一份自己演練總結而成的、能夠立刻參考的文件可以節省大量時間。
結語
我很喜歡看《空中浩劫》，我認為，某種意義上來說，DevOps 工程師的角色和飛行員有相似之處 — 需要通過「編排」讓整架飛機順利起飛，需要接受大量資訊輸入，需要與多名同事密切溝通、協作，需要在極短的時間內「拯救」故障的飛機。
我熱愛這份工作，相信 2021 年，我依然能夠做一名優秀的 DevOps 工程師，守護著飛機平穩航行。
歡迎關注我的技術部落格：wi1dcard.dev
本作品採用《CC 協議》，轉載必須註明作者和本文連結