每日自问自答：如果线上服务出现故障，如何能够尽快解决问题？

就在不到 24 小时前，某不知名社区发生了一次较为严重的故障，从发现问题到解决问题大概花了 90 分钟，事故是由一次上线引起的，内部已经经过了复盘并打算落实各种改进措施，希望未来能做的更好。

关于事故本身我不打算具体讨论，这里想说一些放之四海皆准的原则性的东西，后续不管是谁如果遇到了问题都可以作为参考，提升解决问题的速度。

根据一些历史经验，线上事故一般会分为两类：人为事故和系统故障。这两种事故类型一般会各占一半，不过服务器越少的平台，人为事故的占比越多。系统故障是比较容易直接从运维层进行探测的，只要设置足够的报警就行，并且由于当前高可用云服务已经非常平民化，小团队也可以轻松使用同城三活多副本高可用架构，系统层面上要达到 99.95% 可用性难度不算太高，所以大多数情况下不太需要操心。因此，出了事故一般应该优先怀疑是否跟人为操作相关。

处理事故过程中要做三件事：止损、止损、还是止损。不管用什么方法，让系统重新正常运转是最重要的。

一般最好的止损方法就是回滚相关变更，要想第一时间回滚，那么系统必须具备几个前提条件：

1. 做好上线回滚的前置准备和预案，确保需要回滚的时候能够很快和可靠的执行，这一般需要搭建非常自动化的 CI/CD 系统才行。
2. 做好上线通报，方便相关人员能第一时间确定出问题的系统是什么，从而正确的找到相关责任人并执行回滚操作。
3. 做好关键服务的监控，有条件的话实行灰度放量（用户太少的时候就算了），确保上线后能主动发现问题，避免被动响应用户投诉。
4. 做好紧急联系人制度建设，如果实在影响了用户，也要能在收到用户反馈之后第一时间开始处理问题，避免将时间浪费在找人上面。
5. 尽可能避免在流量高峰期、通勤时段上线，一旦出问题之后影响面大且难以找到相关人员进行处理，切忌上班前或下班后上线，一旦出问题会非常的被动。

很显然，这个社区在很多方面都有改进的空间，每次事故都是所有人持续成长的机会，希望未来能够做的越来越好吧。