恭喜自己，這是第一次生產事故，也是第一個 T0 事故
規範化自己伺服器的事故級別：
- T0: 極其嚴重事故。使用者資料造成不可逆的損失
- T1: 嚴重事故。使用者資料造成可逆損失，需要 ops 的接入恢復資料。或者服務功能出現不可用情況
- T2: 一般事故。使用者資料未損失，只存在顯示異常等展示型內容異常
- T3: UI 異常。因為 UI 佈局等問題，導致使用出現了麻煩
基本#
- 編號： 0x0001
- 發生日期： 2021-04-17
- 級別： T0
過程#
04-17 下午，登入生產伺服器，執行 yum upgrade update 命令，緣由是伺服器的 Docker 環境版本過於低，需要做一系列更新。 執行完命令後，伺服器自動重啟，並未給出對應的重啟提示，初步判斷是由於涉及到了內核的更新。更新後遲遲不能恢復服務，接入 VNC 查看後，虛擬機無法加載磁碟，至此事故發生。伺服器內容全部損失。
事後及時聯繫服務商，企圖拿到損壞的磁碟鏡像進行恢復，結果是拿不到，得到的建議只有重裝。
奇怪#
在重裝後，找服務商要回了同樣的磁碟系統模板，安裝後重新執行 yum upgrade update 命令，也沒有產生任何內核級別的更新，甚至一個更新都沒有，所以這次事故的根因到底是啥我一直沒太懂。
影響#
- 伺服器中帶狀態的服務只有 Miser，且使用者只有本人，由於沒有做及時的定時資料備份，導致資料只能恢復到 3 個月前人工恢復的版本。
- 服務相關檔案儲存傳到了 backblaze 伺服器，不受該次事故影響
Actions#
這件事情後，我思考了很久關於「正式運營一個產品」的事情，不幸中的萬幸是 Miser 自始至終都只有我一個人在使用，即便是朋友多次說想一起使用參與整個產品的發展。我個人的資料其實並不是那麼值錢，但是一旦有使用者真正的把內容放在你這裡，然後你還弄丟了，那麼誠信和信任度會變得很低很低吧。
關於監控#
在此之前我只在服務上面搭了 sentry，用來實時監控服務裡面未處理的異常情況，即 5XX 的錯誤的收集。而實際上在運營過程中還碰到過很多奇奇怪怪的問題，比如說突然間 CPU 彪得很高，內存突然吃緊了。
由於用的是傳統的虛擬機，並沒能上自由伸縮的雲，因此 CPU、內存等系統級別的監控也是應該提上日程的，也就是說一套完善的 prometheus + Grafana 的基本配合是一定要部署到生產的。
關於可靠性與備份#
說起來很奇怪，實際上我已經數個月，快半年的時間沒有動過生產伺服器，基本都是通過 GitHub Actions 來實現一套完成的 CI/CD 的。這次手動登入伺服器的緣由便是上去把備份服務部署上，而就是這麼一次操作導致了事故的發生，也有可能是生疏了。
服務商跟我講得很好，我的操作確實存在很大的問題。他說如果他來會這麼操作：先拍一個硬碟 snapshot，然後執行操作，沒問題萬事大吉，有問題用 snapshot 恢復整個磁碟。
確實，我這一次並沒有很好地做一次 dryrun，每次都是直接跑 docker pod 級別操作，出問題了就直接 rm，這次在宿主機的操作實在缺少了一絲敬畏。
為此
- 減少對宿主機的直接操作，docker 集群搭建起來之後應該都在 docker 層面操作
- 備份服務的優先級應該被提到最高，毕竟資料才是重中之重
- dryrun 的可靠性，一套跟生產一一對應的 dev 或者 uat 環境的必要行需要進行思考