有句话叫每一起严重事故的背后，必然有 29 次轻微事故和 300 起未遂先兆以及 1000 起事故隐患。
而我最近更是碰到了 3 起比较严重的线上事故，都是大意惹的祸。
第一起事故发生在凌晨 4 点到 6 点，我们有个数据库被锁死了，无法更新和写入。
当天早上 5 点客服打电话给我，把我吵醒后紧急摇人，打电话给运维，打了 5 次才打通，他也马上开机排查。
原因很简单，就是有一张表，记录极速增长，超出了数据库的限定容量（1TB），从而导致库被锁，马上扩容。
去年对这张表做过一次清理，但当时没有引起重视，造成了今天这场事故。
幸亏这个数据库大部分的使用场景是管理后台，所以线上业务没有造成太大的损失，不过小范围内有点影响。
后续动作
将线上重要的业务与这个数据库做剥离，也就是不再依赖这个数据库。
对那张极速增长的表做剥离，即迁移到另一个数据库中，对于量比较大的各类日志数据，单独创建一个数据库，统一管理。
对此表做定期清理，例如只保留 3 个月的记录，其余全部删除。
第二起事故发生在凌晨 2 点，不过就持续了 30 秒，看来夜深人静的时候比较容易滋生意外。
虽然只存在了 30 秒，但仍然影响了 221 个用户。排查下来是 Redis 服务连接异常，导致服务意外重启。
在重启过程中，那些请求都无法被处理，从而让业务无法响应。
在确认不是代码逻辑造成的异常之后，开始摇运维，让他去找服务供应商，
一开始服务商认为是某个 Redis 命令阻塞了请求，不过在仔细核对代码后，发现并不是这样。
于是再次去挑战服务商的维护人员，故障发生的时间也再一次缩小了范围。
最终确认在那个时间有主备切换操作（不定期），导致了报错。
后续动作
一开始就仅仅是将切换时间改成凌晨的三点，但是随后几周又出现了 Redis 的连接问题。
虽然时间只有 20 多秒，不过还是影响了小部分的线上业务，对用户体验造成了极其糟糕的影响。
再次摇运维，让他去沟通解决，一开始他觉得这么短的时间应该问题不大，可以将升级时间配置到我们在办公的时间。
好像有点道理，但是细究下来，还是有点问题的，对于用户来说，他们只看结果，若自己碰到了异常，那么就会认定你的系统不稳定。
他们只会在意 0 和 1，不会在意你这异常发生的概率是多少，影响的范围是多少。
所以后面继续和运维拉扯了一下，他了解到可以从单区升级成双区，这样就能在升级的同时而不影响线上业务。
不过，在升级期间，还是会有 30 秒左右的断开时间，但各项缓存配置不用单独做修改。
短信服务已经被应用到日常业务的很多模块中，主要用于身份的验证，本事故与短信直接相关。
前两个事故并没有造成经济损失，但海外短信盗刷造成了比较大的经济损失。
攻击持续了 3 天，很巧的是，正好碰到双休日，大家都不在工位的时候。
第一天盗刷后，运维受到了费用受限的通知，告知了服务端，服务端再告知了我们组。
然后当天就让运维把短信总量降一半，为盗刷的国家增加每日的短信上限，我们组修改短信接口，接入风控保护。
隔了两天是周六，发现又在被刷，原来是手机号码和 IP 一直在变化，绕过了风控策略，并且运维并没有对所有的国家配置短信上限。
服务端在风控保护的代码中直接关闭了海外短信，原先设想是临时关闭两天，因为我们组的业务只会影响极小部分的用户。
结果服务端忘记发布代码，导致第三次被刷。
后续动作
首先将每日的海外短信上限调整到更小的数量，再缩小一半。
其次是设置海外国家白名单，如果为所有国家配置上限数量，不仅工作量大，而且还会有遗漏的隐患。
再有，查看日志发现，攻击者的手机号码都是随机生成的，因此，我们可以做一次身份校验。
因为我们使用到短信的业务都会有身份信息，所以可以对手机号进行校验，只有是数据库中的手机才能发送短信。
这部分的短信业务已经存在许久，但是一直没有引起我们的安全意识，非常脆弱，服务端之前也被攻击过，后面做了防御。
还有一种短信防御，就是加验证码，在发送接口中核对验证码，只有是合法的，才会提供发送服务。