服務狀態
所有系統正常運作。
一個狀態頁只有在願意說壞消息的時候才有價值。這一頁是在事件進行中更新，不是結束後才更新，也就是說你有時候會看到某個元件旁邊寫著調查中，而我們當下還不知道原因。
元件
| 元件 | 狀態 | 目標 | 現在的情況 |
|---|---|---|---|
| API | 正常運作 | 99.9% 可用性 | 過去 24 小時沒有高於基準線的錯誤 |
| 開通 | 正常運作 | 99.5% 的付款訂單會拿到可用的設定檔 | 滾動一小時高於目標，安裝時間中位數 41 秒 |
| 付款 | 正常運作 | 授權和自動退款都在 60 秒內完成 | 金流商回報正常，退款也照時程送出 |
| 覆蓋數據 | 正常運作 | 公布的數字每天更新，維持 25 筆樣本的下限 | 上一次更新已完成，沒有任何國家因為資料過舊而被隱藏 |
| 客服 | 正常運作 | 首次回覆 60 秒內，一天 24 小時 | 所有有值班語言的排隊時間都在目標內 |
正常運作的意思是這個元件在滾動一小時內達到它的目標。這不是對下一個小時的保證。
99.5%
開通成功率目標
60 秒
開通失敗時的自動退款
30 分鐘
會觸發公開事後檢討的事件長度
72 小時
公開那份事後檢討的期限
每個狀態的意思
| 狀態 | 代表什麼 | 我們會做什麼 |
|---|---|---|
| 正常運作 | 這個元件在滾動一小時內達到目標 | 什麼都不做。這是正常狀態，也不是對未來的保證 |
| 效能降級 | 還能用，但比目標慢或比目標不穩 | 在這一頁點名，聯絡受影響的客戶，不用申請就補償入帳 |
| 部分中斷 | 對某個可辨識的族群失敗，例如某一家電信或某一個區域 | 點名該族群，擋掉會失敗的購買路徑，退款自動送出 |
| 重大中斷 | 大範圍失敗 | 指派一位事件指揮官，並且至少每 30 分鐘更新一次，直到排除為止 |
| 維護 | 有明確時段的計畫性作業 | 至少提前 72 小時公告，並排在流量最低的時段 |
沒有一個狀態的意思是應該還好吧。一個元件要嘛達到它的目標，要嘛就被寫在這一頁上。
事件處理原則
整件事由兩個承諾撐著，而且兩個都是刻意讓人不舒服的。第一，受影響的客戶在察覺之前就會先接到我們的通知。第二，任何超過 30 分鐘的事件，都要在 72 小時內公開一份寫成文字的事後檢討。
事後檢討點名的是系統和決策，不是個別員工，而且由當時待命的那個人親自寫，不是由主管來描述別人做了什麼。
如果我們趕不上 72 小時的期限，會在這 72 小時之內公開延遲和原因，因為錯過期限又晚一步說，等於失誤兩次。
- 偵測是從開通成功率和付款授權率自動判讀的，所以事件是在數字開始移動時開始，不是在有人抱怨時開始
- 這一頁上的元件狀態會在宣告後五分鐘內改變，在原因確定之前就會改
- 由一位事件指揮官指揮應變，另外一個人負責對外溝通，兩件事才不會互相排擠
- 我們會找出受影響的客戶並主動聯絡，服務降級的部分補償已經先入帳，不是等你來要才給
- 任何我們知道會失敗的購買路徑都會被擋下來，因為收下一筆之後必須退掉的錢，比少做一筆生意更糟
- 重大中斷期間至少每 30 分鐘更新一次，就算更新內容是我們還不知道也一樣要更新
- 在排除後 72 小時內公開事後檢討，內容包含時間軸、以數字呈現的客戶影響、原因，以及每一項修正的負責人和日期
為什麼目標不是百分之百
因為中間隔著一個電信網路，百分之百會是謊話。99.5% 的開通目標等於公開說出來：每一千筆訂單大約有五筆，會在付款和可用設定檔之間的某個環節失敗。
重點是那五筆的路徑有被設計過。退款在 60 秒內自動執行，不用開單，訊息會說明發生了什麼、可以改試什麼，沒有人需要去判斷這位客戶值不值得退款。
同樣的邏輯也適用於覆蓋範圍。在我們有一家以上電信合作的地區，如果某個合作網路壅塞，我們會把你換過去，而不是登記成一次事件，備註會寫清楚換到哪裡。
如果當地只有一個網路，而它今天狀況不好，我們會在國家頁面上寫出來。我們的覆蓋頁面會公布中位數、最慢的十分之一和樣本數，就是為了這件事。
事件紀錄
本期回報區間內，沒有宣告過任何超過 30 分鐘的事件。
這句話的價值，剛好等於我們願意去改掉它的程度，所以上面的原則才寫得這麼細。過去的每一份事後檢討都會永久留著公開，不會過了九十天就消失。