淺談責任共享
在 AWS 當 Support 也滿一年了，很慶幸自己能夠在這個諸神雲集的叢林存活下來，也很高興終於有時間寫點工作以外的東西。審視一年前和現在的自己，我想最大的不同是心境上的轉折，也是我寫下這篇文章的最大動力。
作為一個技術支援，每天的日常就是和不一樣的使用者們打交道，面對各式各樣、千奇百怪的問題，都要能夠圓滑地解決。對我來說，從開發人員轉換到技術支援的最大挑戰，在於處理問題的方式。在我過去作為開發人員的經驗中，多數情況下並不太會直接面對到來自使用者的壓力，而且對於系統擁有非常大的控制權，因此不論是調閱各式各樣的 Log，以及修改程式碼或是調整架構等，都有非常大的靈活度。然而，對於技術支援而言，不論是 AWS Service 本體，或是使用者的系統/服務，基本上擁有的最大權限，只有調閱一部分安全層級較低的 Log 和 Metrics，以及向使用者索取 Troubleshooting 必要的資訊。但是處理案件的時間並不是無窮無盡，各類緊急程度的案件通常都對應到不同的 SLA，對於案件本身使用者而言也有不同的影響程度。那麼問題來了，在時間和可控範圍都非常有限的情況下，要怎麼有效率的解決使用者的問題？
剛開始正式上線的時候，我總是會想著要如何從來自使用者提問的隻字片語中，盡可能挖掘更多的訊息，盡可能排查 AWS 端各式各樣的設定、Log 和 Metrics，也盡可能進行測試與驗證，試圖盡可能還原出錯誤，找出錯誤的成因以及對應的處理方式，但這樣做往往需要消耗大量的時間，而且很多情況下，從使用者端拿到的訊息真的只有「隻字片語」，比如：
「我的 EC2 Instance 的網路好像有點慢，麻煩幫我看一下！」
「我存取不到我的 ALB ，是不是你們這裡有問題？」
然後…然後就沒有然後了 Orz，沒有提供 Region / Resource ID / 詳細的現象描述 / 如何觀測到問題 … 等等這些附帶資訊，這時候如果再加上帳號下面有成千上百台使用者所描述的 AWS Resource，光是要定位問題發生在哪邊就已經像大海撈針，何況還得進一步確認使用者描述的現象實際上是什麼，在這種狀況下，硬是順著這些訊息往下走，最後就是無窮無盡的加班加好加滿（別懷疑，我一直到前陣子都是這樣硬幹的）。
一直到今年 6月，那時候手上一次處理了三個非常棘手的案件，一個是在極大使用量和規模的情況下，才能夠觸發相關的問題，兩個則是只能夠在使用者端能夠隨機重現的的狀況。三者共通的地方在於，因為完全沒有辦法在我的環境中重現，所有的資訊都必須完全從使用者端取得，對應到的 AWS 內部的 Log 等級，也是到達只有內部開發人員可以檢閱的程度。在這個狀況下，我還是盡我可能地，只要從使用者端和內部開發人員處取得一些蛛絲馬跡，就大量進行測試和調閱任何可能的紀錄。處理那三個案件的那幾週，我幾乎每天都是從值班時間（那時是早上7點到下午4點）一直瘋狂加班到凌晨2–3點，弄到自己真的心力交瘁，甚至萌生放棄這份工作的念頭。
後來是我的老闆在檢視我的案件處理情況時，發現我在這三個案件上花費非常多時間，但還是沒有辦法讓案件收尾，趕緊請到資深的前輩出馬救場，才讓這個情況順利落幕。而與我不同的是，前輩的作法則是和使用者一起：
- 釐清這個問題對於使用者的痛點。
- 找到重現條件、或是能夠保留案發現場的方式。
- 讓使用者理解我們（Support）能做什麼、做不到什麼。
不過這並不代表最終這三個案件都找到真正的成因，然後根本地被解決，相反的：
- 其中一個問題最後是由開發團隊決定加入更多的監控，以便在未來再次被觸發的時候，能夠更深入地挖掘各種可能性。
- 餘下兩個則是和使用者達成共識，未來使用者會盡量確定觸發條件，以及未來再次發生時，盡可能保留現場。
從前輩的處理方式，以及最後的結果來看，我體悟到非常重要的一點 — — 「與使用者一同分攤處理責任」。
這個想法最基本出發點是，針對使用者提出異常的狀況，以及其它問題，使用者在調查的過程中，也有義務盡可能提供排查過程中需要的材料。打個比方，身為一個 Web Service Owner，假設今天你的使用者提出一個這樣的問題：
「網站很慢，我什麼都看不到」
那你的第一個反應該是什麼？是開始把整個網站留下的 Log、外加運作網站的主機的 System Log 和 Metrics都翻過一輪，再把網路層的測試都做過一次？對著問題硬幹並不是不行，但假設今天你是一位管理 100 個網站的維運人員，每天每個網站不定時地有 1 個隨機 User 會發生連線問題，一個一個都這樣檢驗的結果，最終導致的就是你的待確認問題清單無限膨脹到無法負荷的程度，這顯然不會是一個好作法。
相反的，還是你會先問問你的使用者，他的「很慢」、「什麼都看不到」是指什麼？有沒有看到什麼異常的 HTTP Response？瀏覽器裡的 Web Developer Tool 能不能檢查到什麼東西？甚至請他執行簡單的 Telnet 或連線測試，初步釐清問題的發生點，究竟是在使用者的網路環境中，還是在網站主機的所在位置。這些處理機制都能夠大幅減少向下挖掘功夫和時間，也可以讓自己有更多餘裕做點別的事（看看 Netflix 啦、滑滑手機啦、或是讀讀書也行）。
當然現實狀況肯定不會這麼理想，有時你的使用者會非常情緒化：
「你的網站爛透了」
或是完全不配合：
「哇謀營，歹勢，哇謀營，哩欸服務真正爛，恁爸不爽用了」
「不要叫我做一堆有的沒的，這都是你的責任，你應該想辦法修」
這時候就得針對所處的環境（白話：你的老闆允許你怎麼做）做出取捨，例如要再進一步和使用者溝通，或是將這一類狀況視為無意義的回報，直接忽視。「系統異常」確實反應出在某些條件下系統無法正常工作，但是開發或是維運人員該不該將所有排查責任承攬在自己的身上，或是要如何讓相關人員一起承擔責任，更是一門學問 — — 畢竟再厲害的人，一天能夠支配的時間還是只有 24 小時（除非你是閃電俠）。
當然這個心法並不限於維運的範疇，對於開發和日常生活都是如此，試想你的 PM / 老闆 / 業務 / 客戶 / 各個需求單位，告訴你有個功能 / Issue / Bug / 各種形式的 Task 馬上就要插進來做，那麼要做的是拼命的往前衝，還是先釐清這個工作的細節和必要性？不過還是老話一句，做事的彈性還是取決於環境，如果今天你的主管 / 老闆 / 上司 / 付你錢的人，就是希望你隨時跟進任何需求單位提出的工作，那也是莫可奈何。
至於我在 AWS 的老闆就給我很大的主導權，所以基本上有什麼樣的想法都可以拿出來討論，只要在不違反基本政策（比如說使用者的資料安全和隱私）的情況下，很多事情都可以試試看。在轉換心境後，也發現很多事其實都能夠海闊天空，這也是我這一年來除了技術之外，學到最為寶貴的一課。希望也能夠帶給讀到這裡的你一些啟發。
