阿阿阿里云崩了

序

    今日突发消息，阿里云崩了，受影响的产品很多，经过了一轮重启之后，然后基本恢复了。

    故障应急第一刀，先杀意中人，重启之后就啥都不用记忆了。

风言风语

    双十一刚刚过去的日子，就经历这种大规模的故障，其实还是比较残酷的，昨夜，估计很多的核心骨干人员都在通宵，而在今天这个时间点出现故障，估计大部分的人都可能还在睡梦中，该联系的能联系的或者都联系不上，运维人员多与少，是否冗余，可能和这个恢复时间也有大大的关联。

    恢复时长，天时地利人和，缺一不可，这TM的莫非是一个玄学？？？无法预估故障的恢复时长，当所有的应急预案都失效之后。

    1 分析下可能的原因

    原因无非两类，一种是外部因素，一种是内鬼所为。

    如果是外部因素，那么要么就是外部的攻击，各种攻击流量蜂拥而至，但是如果要攻击这么大的区域范围，这种难度还是蛮大的，这种重启估计也恢复不了，只能封杀攻击流量或者是等攻击停止或者是无限扩容；要么就是业务流量突增，导致容量不足扛不住了，双十一过后大量的资源清退？各种退货导致的？资源不够从而引起的雪崩效应。

    所谓雪崩，就是本来可能是无限容灾的，但是如果是一个区域的扛不住，被打死了，那么就会请求下一个，立刻下一个也被打死了，容灾做的好，那就是无限循环的雪崩，这个就很难停止了。。。除非，把入口封了，把域名解析的负载均衡全干了，然后再次恢复负载均衡，从而故障恢复。

    双十一都快过去了，那么容量理论上来说是足的，除非有心人知道这个时候其实可能是大家最放松的时候，因为关键节点已经过去，如果要出问题，那么双十一就出问题了。

    如果是内部因素，可能变更导致，变更产生的故障率几乎达到80%以上概率，可能是缩容了，但是业务请求还是很多，降本增效，就看需要达到什么程度，如果对降本要求很高，那么估计会立刻进行缩容，从而来保证成本，降本。。。。这本来就是个伪命题。

    如果是内部因素，可能是线上误操作的，例如本来我做着测试环境的变更，一不下心，发到了线上，从而造成线上大规模故障，但是今天是周末，理论上没人上班变更，都在家休息，基本还在封版的时间内，禁止变更，年底了，大家都不想搞事情，所以，可能性也比较低。

    如果是内部因素，可能是突发的请求数翻倍，例如某个极小概率的代码BUG被触发，无限调用打死雪崩，碰到了盲点，那么这种事情也很难避免，测试覆盖率，复现率，迟早会遇到，只是运气的好坏而已。

    还有什么可能的原因呢？欢迎大家猜想。。。。

2 几家欢喜几家愁

    一般出现这种事情的时候，最高兴的估计是同行的竞争对手了，所谓同行是仇家，拉踩也是家常便饭，各种言论都会出现。

    最难受的，莫过于运维了，本来已经扛过了难熬的双十一，熬了几个通宵，做了各种准备工作，收尾的时候出现问题，功亏一篑。

    马上都年底了，绩效都要开始准备了，总结收与获，得与失，这来个巨大的故障，卧槽，没办法玩了。。。最大影响莫过于底层了，高层其实无所谓，又不缺那几个钱。

    其实故障了又能如何呢？每个人还是正常的吃了饭，只有那么几个相关的人各种叫唤，实际上，就算你的业务挂一天，你觉得你的业务影响多少营收？

    换一个角度，如果是你负责的这个运维，挂了几个小时，你又能做啥呢？

    3 如果是google干出了故障，他们会如何？

    如果是google干了这么大的故障，他们会干嘛？

    按照他们的理论，应该是该赔偿赔偿，该复盘复盘，对事不对人，可能是一个经典的案例。

    依据他们的理论，估计都不用找个扛锅的，可能他们对外就是说，发生了故障很遗憾，但是我们努力了，后面我们会改进，然后结束。

    内部人员依旧开心的工作，只是提高更高更好的自动化流程。不让具体的人员担责，而是整体扛了故障，可能也是极好的。。。

疯言疯语

    出现故障没那么可怕，当意外来临时，除了尽快的去修复，其实很多事情你也可能啥都做不了，考虑了无数的场景，学了无数的知识，可还是过不好这一生。。。

    放轻松一点，出现故障其实还好，只能说明某些地方没做好，而不是焦虑害怕问题的产生，这也是一种改进的机会。

    如果是你，你怎么应对大规模故障？

    如果是你，出了故障之后，你如何回应？

    如果是你，你该如何针对故障追责还是奖励？

    如果是你，这些故障是否让你变得更加成功还是更加失败？

    看了对手的演出失败，你该如何进行表演？你能确保你不出问题么。