工作過載的解方¶
title
Google 針對「工作」有提出一系列見解， 放在 rework.withgoogle.com 之中， 建議對本篇有興趣的人可以到這裡做延伸。
這裡簡述一下網頁中提到何為優秀的團隊：
- 心理安全，在承擔風險時，是感到安全的，不會感受到被視為無知、無能或搞破壞；
- 可信賴的，當成員說想要做什麼，他們是被信賴會在時間內完成高質量的工作；
- 架構清晰，無論是個人或團隊層面都有目標，且清楚實現目標的流程，這些目標必須具體、有挑戰、可實現；
- 有價值的，這份工作對個人是有意義的，例如財務穩健、能有時間照顧家人、有成就感等；
- 有影響力，看得到自己工作對團隊甚至公司的實質影響。
還反面提到了以下因素對團隊效率影響是有限的： 是否坐在一起、共識決、外向的成員、單一個人的績效、工作量、資歷、團隊規模、團隊任期。
理想狀態下，SRE 團隊可以處理所有日常維運任務如解決記憶體堆積、記憶體區段錯誤、資源分配、持續推出等等， 同時也能有時間規劃和執行長期的計畫，以幫助更有效管理服務。 但事實是，團隊成員可能會請長假去旅行、內部轉職、公司規劃一個新產品需要 SRE 去協助等等， 進一步讓 SRE 成員負擔加劇，他可能會開始沮喪，明明更努力工作了，但計畫執行的項目卻沒有什麼進展。 而這些壓力又會進一步增加產品出錯的可能，造成惡性循環。
這時就需要開始思考識別哪邊工作過載了，該如何解決。
識別工作過載¶
工作過載（work overload）和認知過載 （perceived overload）是兩件事，工作過載通常會造成認知過載， 例如被維運任務佔滿了工時，但也有可能沒有工作過載卻造成認知過載，例如每天早上固定有數個維運任務需要去處理， 即使中午前就能全部處理完成，但每天一進班看到這些任務就有可能造成內心的壓力並加劇認知過載，就算客觀上並未工作過載。
在衡量是否過載時，有幾個指標：
- 日常維運占用多少比例的時間；
- 長期任務按時程完成的比例，這也讓我意識到原來按時完成任務的目標不只是為了完成承諾， 也是用來確保同仁工作分派是否合理；
- 工單（ticket）、緊急呼叫 （page）的數量。
在這背景下，建議衡量當下任務的工作負載當作基礎，並透過超過負荷時會有的徵狀，來確認是否該進一步調整指標的基礎值。 以下是一些常見的徵狀：
- 怨念，透過問卷調查（這裡推薦此前分享的 PLS-SEM 去找出抽象關係）或不加批判的傾聽去確認；
- 賣肝，頻繁加班且即使生病了仍然進班，這都是壓力會促成的行為；
- 更頻繁的生病，以年或月為單位的紀錄同仁的病假；
- 定期盤點單子的承接狀況，並適度的延後或捨棄單子，如果反覆讓專案延後或甚至這類盤點的會議都沒法召開，團隊很可能正超出負荷的工作。
指標請保有彈性
同時指標也要保有彈性，例如有人可能喜歡一天專注解單，另一個人可能喜歡數天分散的解決單子，這時透過關單的歷時天數來統計就會失準。
一但確認基礎值後，可以定期檢視這類指標，並進一步識別工作過載。 不過要注意的是，客觀（指標）上可能團隊並沒有工作過載，但是主觀上團隊成員可能已經因為過載而得不到工作的喜悅了（案例二）， 請記得反覆確認指標的基礎值是否要修正。
案例分享¶
情境一、人數減少
團隊三分之一成員因各種獨立因素而離職，導致工作過載。 徵狀包括專案進展落後，維運項目逐漸累積，而每個項目都是高優先度讓排定工項一再延後，加劇這些徵狀。 解決做法就是把團隊成員叫進一個會議室， 列出所有工項並逐一分類和重排優先度：
- 找出過時、冗餘的工項並移除它們；
- 找出同類且能透過自動化完成的工項；
- 找出同類且能利用文件把任務交付給使用者（或開發者而非 SRE）自身的工項；
- 找出不緊急的工項，先把進度文件化後擱置這些工項；
- 不確定屬性的工項先放進下一輪的篩選；
- 最終找出當下需要做的工項。
這過程花了兩天，一天分類、一天寫文件和自動化工具。 而此後每兩周，技術領導人會審視這些工項，並適度地分配和關閉一些工項。
情境二、人員品質滑落
技術主管（會值班）和其中一個同仁離職，且團隊又同時被指派到一個和過去差異較大的新服務。 因服務差異性導致告警（因 SLO 設計不當）、和開發者的溝通持續增加 （理論上這種狀況應該把維運交給開發者，但由於沒有這類經驗，並不知道這是可行的方法）， 再加上過去忽略的告警被發現是重要的，需要即時修正，on-call 值班時常常需要跟進上周的狀況， 進一步壓垮團隊成員的工作心態。 儘管和新主管有過討論，但因為新主管未輪班且身兼多職，所以沒有正確理解到同仁工作壓力大的狀況， 忽略了需要進一步處理的需求。
在這種大量時間被用來處理告警事件且主管不認為工作過載的惡性環境下，員工間的信任和工作效率也正逐漸被摧毀。 這狀況代表在 rework.withgoogle.com 中理論提到優秀團隊最基本的條件：心理安全，已經消耗完。 團隊成員不再認同這個團隊，也不再關心職涯發展和晉升。 這狀況在更上層推廣公司層級的專案時，有機會和更上層主管的討論中得到理解和處理。
- 重新指派一個備受尊崇的團隊成員為主管， 且以參與式管理的方式和部屬共事；
- 短期（馬上），降低同仁壓力，提供心理安全的環境；
- 輕鬆歡樂的實體會議，舒緩緊繃的工作壓力並一同討論過載的原因；
- 引入公司內經驗豐富的 SRE，因為沒有先入為主的觀念，所以可以用更獨立的角度去審視問題， 這項任務並不容易，但效果很好；
- 重新評估告警，允許靜音一天或一周避免持續告警的壓力、 不能及時處理的告警（例如重啟不能解決）會被轉成單子、 移除不會影響使用者的問題；
- 讓 on-caller 在輪班後繼續執行值班時的單子（承上列提的告警轉成單子）， 並把衡量指標從單數改成輪班後解單的時間， 這樣可以避免單子轉給不同人的成本還有看到單子被開出來時，指標下降的心理壓力；
- 中期（三個月內），建立各同仁的信心還有找出問題的根因；
- 把差異性大的新服務交給開發者維護；
- 把處理告警和單子時的知識散佈出來，文件或者會議分享，隨著成員獲得的知識越多，將越有自信，也能延伸好做法，加速工作；
- 引入遠端的 SRE 進行輪班和訓練，帶來新氣象和視角；
- 每周討論和解決重複或被靜音的單子，避免每日因為這些告警過載；
- 給予團隊成員承諾會找新同仁，並陸續填補人力缺口以釋放臨時的資深 SRE；
- 長期，有能力互助解決系統難題；
- 陸續同步不同服務的維運任務，簡化認知負荷，例如長期沒維護的服務、逐步增加流量的服務、搭配上游持續更新的服務。