恭喜自己，这是第一次生产事故，也是第一个 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 环境的必要行需要进行思考