故障反思

安全问题

​ 最近看了很多运营事故的复盘，让我有种后背发凉的感觉。因为自己在公司实习的时候，在线上环境的操作都是很随意的。并没有每一步按照流程进行执行，试过了很多的危险操作，至今还没出事属实是侥幸。

案例一：生产环境中执行危险脚本

​ 这是最近学校工作室发生的一起事故。事故的北京是这样的，工作室的师弟，手滑在正式环境上面误跑了“重新部署”的脚本。导致了，重要数据以及日志全部被删除。而且，对这些数据没有进行备份，导致了误删的东西不能恢复。

我觉得，这次事故的发生全是因为流程上有以下不规范的地方：

(1)重要数据没有做好备份

​ 因为一开始对这些不够重视，没有做好数据的备份。导致事故发生之后，没有任何办法进行补充。针对这个，建议以后对重要的数据至少都在另一台机器上面进行备份。异步备份，或者是同步双写方等方案都行。总之一定要保证，事故发生之后一定要有补偿手段。

​ 这也是做好异地容灾的必要性。虽然这次是因为误跑脚本导致丢失，但是总有很多意外会导致数据的丢失，比如说磁盘损坏，地震……如果只有一份数据的话，那就真的很危险了。因此，有能力做异地容灾的话，建议还是做好这个措施。

(2)线上环境的流程过于简单

​ 仅仅执行了一个简单的命令就导致比较严重事故，这暴露了一个问题，线上的流程过于简单。我现在觉得，在生产的一些比较敏感的操作，至少要有确认和验证。这样才能尽可能减少误操作的发生。

​ 在实习的时候，我一般的发布流程是这样的：(1)如果服务需要在测试环境上运行，我就直接在本地终端直接shell脚本，把服务推送到测试环境。 (2)但是，要把服务推送到正式环境则需要通过很繁琐的流程，最后还需要比较繁琐的确认操作。

​ 一开始，我还经常吐槽线上环境的流程很复杂，现在终于明白公司为什么要制定这些流程规范了。

​

(3)“删除”不应该出现在生产环境中

​ 任何“物理删除”都不应该出现在生产环境中…这个就不仔细说了，那个删除数据的脚本就不应该出现在生产环境里面。在腾讯实习的时候，数据从来都没有物理删除的…只有逻辑删除。

​ 现在想想真的有点后背发凉，实习的时候导师直接把生产环境数据库的root权限给我…要是当时做了什么误操作，后果不堪设想。针对这次事故，以后开发中一定要有敬畏之心，注意流程上的规范。

案例二:后台雪崩

​ 背景是这样的，我们的服务部署在上海和广州。碰巧当天通信发生了故障，导致导致服务A(广州)调用服务B(上海)全部失败，并且客户端还不断发起重试…

​ 随着时间的推移，请求量越积越多，等到网络通信的恢复的时候，所有流量瞬间涌到了服务B(上海那边)。导致服务B的节点大规模宕机。

​ 当时不知道怎么回事，就想着实在不行就先重启试试。但是重启一台死一台…

​ 最后故障是怎么解决的呢？无奈，只好在前端把流量入口关闭，然后再启动所有的节点，这样才慢慢把流量降下来…

解决方案

​ 雪崩过载，是一种比较常见的故障。但是很多时候，但是针对该案例发生做出相应的赶紧和优化，但这有些治标不治本…最好的解决办法，就是建立“快速拒绝”的机制。

案例三：硬件架构层面没做好

​ 这是四五年前，总监遇到的一个故障。当时的情况是这样的，有一个非常核心的业务部署在了上海，并且在软件架构上的层面已经做了比较充足的防备。业务部署了三台节点，并且三个节点互为住备..

​ 按理说，这应该没啥问题。因为除非它三台机器同时挂掉，不然这个服务都是可用的…但是，当初忽略了一个问题，这三个节点都是链接到了同一台交换机上面。然后，当天交换机宕机了，导致核心服务百分百不可用…

启示

​ 这个故障给我们的启示是什么呢？就是即使你在软件层面上做好了防护，但是硬件层面没做好的话，还是十分危险的…因此从那次之后，架构层面上做了很多异地容灾的改造。