工作過載的解方

理想狀態下，SRE 團隊可以處理所有日常維運任務如解決記憶體堆積、記憶體區段錯誤、資源分配、持續推出等等， 同時也能有時間規劃和執行長期的計畫，以幫助更有效管理服務。 但事實是，團隊成員可能會請長假去旅行、內部轉職、公司規劃一個新產品需要 SRE 去協助等等， 進一步讓 SRE 成員負擔加劇，他可能會開始沮喪，明明更努力工作了，但計畫執行的項目卻沒有什麼進展。 而這些壓力又會進一步增加產品出錯的可能，造成惡性循環。

這時就需要開始思考識別哪邊工作過載了，該如何解決。

識別工作過載

工作過載（work overload）和認知過載 （perceived overload）是兩件事，工作過載通常會造成認知過載， 例如被維運任務佔滿了工時，但也有可能沒有工作過載卻造成認知過載，例如每天早上固定有數個維運任務需要去處理， 即使中午前就能全部處理完成，但每天一進班看到這些任務就有可能造成內心的壓力並加劇認知過載，就算客觀上並未工作過載。

在衡量是否過載時，有幾個指標：

• 日常維運占用多少比例的時間；
• 長期任務按時程完成的比例，這也讓我意識到原來按時完成任務的目標不只是為了完成承諾， 也是用來確保同仁工作分派是否合理；
• 工單（ticket）、緊急呼叫 （page）的數量。

在這背景下，建議衡量當下任務的工作負載，若成員認為超過負荷就代表當下的負載是過重的， 並進一步調整上面的指標的基礎值。

案例分享

團隊三分之一成員因各種獨立因素而離職，導致工作過載。 徵狀包括專案進展落後，維運項目逐漸累積，而每個項目都是高優先度讓排定工項一再延後，加劇這些徵狀。 解決做法就是把團隊成員叫進一個會議室， 列出所有工項並逐一分類和重排優先度：

• 找出過時、冗餘的工項並移除它們；
• 找出同類且能透過自動化完成的工項；
• 找出同類且能利用文件把任務交付給使用者（或開發者而非 SRE）自身的工項；
• 找出不緊急的工項，先把進度文件化後擱置這些工項；
• 不確定屬性的工項先放進下一輪的篩選；
• 最終找出當下需要做的工項。

這過程花了兩天，一天分類、一天寫文件和自動化工具。 而此後每兩周，技術領導人會審視這些工項，並適度地分配和關閉一些工項。