前几天很多朋友都经历了阿里云3个小时左右的故障，我们的业务也受到了一定的影响。我们的技术同事通宵达旦通宵达旦，终于观察到服务稳定运行了两个多小时。事故就像一场战斗。无论是失败过程中的处理，还是失败后的总结，除了骂阿里云之外，还有改进的余地吗？结合我们公司昨晚的处理过程，分享一下我的一些想法。画外音：技术人，还是谈技术，我们不能决定别人，我们应该做自己。一大早接到运维负责人的电话，说阿里云部分机房出现故障，接到了阿里云同事的反馈。问题还在定位中，恢复时间未确定。画外音：关键时刻手机欠费，运维负责人帮我充了200话费才打通。真的很曲折。整个过程中我们可以做什么？及时向业务方反馈：如客服、运营等，如果收到用户反馈，我们会及时说明情况；确定影响范围：因为不是所有的服务器都受到影响，确定范围后很容易有针对性的检查；这里，潜在的技术问题是：运维是否第一时间收到服务器告警，研发测试是否第一时间收到站点和业务告警？为什么他们没有收到？是没有报警，还是报警覆盖范围缺失？画外音：如果业务方先发现问题，问技术部门为什么服务出了问题，那有多尴尬？能否快速确定受影响的服务器IP？以及受影响的业务范围？我们运维同学第一时间通过脚本判断大概有50台服务器受到了影响。DBA同学也第一时间确认RDS数据库服务没有受到影响。画外音：未来需要自动化、可视化；除了能从前端查出A、B、C功能不可用外，还能从后端准确判断出哪些服务受影响，流量占比多少？潜在的非技术问题：技术团队和业务方是否建立了反馈渠道，沟通是否顺畅？有没有“在线服务至上”的意识，有没有“值班制”制度，还是关着手机睡觉？画外音：昨晚大部分二级部门，三级部门负责人立即上阵真好；关掉手机睡觉对技术人员来说是不可接受的。2、一个多小时过去了，阿里云还没有报修时间。众人此时都有点着急了。那么除了等待我们还能做什么呢？因为只有部分地区的部分服务器出现异常，是否可以申请一些新的服务器，在受影响的服务器上重新部署站点和服务，通过服务治理将流量切换到新的服务上，是否可以恢复（至少部分恢复）？在整个过程中，我们可以做的是：申请新服务器；确认受影响的站点和服务，重新部署；服务治理，流量迁移；这里潜在的技术问题是：（1）能否快速扩展服务器；画外音：昨晚我们火速采购了50台ECS，这就是云的好处。(2)知道了受影响服务器的IP，如何快速判断这些IP上部署了哪些站点和服务？这些站点和服务的上下游有哪些，共同影响的范围有多大？画外音：这是需要改进的地方。每个负责人都知道他们的IP上部署了什么，但他们没有可见性。（3）站点和服务如何快速扩缩容，服务如何发现，流量如何迁移？画外音：服务治理任重而道远。三个半小时后，我们购买了服务器，梳理了站点和服务后，阿里云专家反馈，“问题定位有了关键进展，如无意外，30分钟内恢复。”“这个时候我们内部的评估是50台ECS的初始化、服务部署、流量迁移可能在30分钟内完成不了。还是等阿里云吧。果然，半个小时左右，阿里云专家的反馈就恢复了。这时候我们需要做的：判断站点和服务是否在运行；判断日志是否异常；消费，执行定时任务。画外音：有些cron任务可能需要手动再次执行。这里的很多工作是通过手工、脚本自动化还是平台可视化来判断和执行的？技术平台的迭代还有很长的路要走。四大服务稳定后观察一段时间。朋友圈和微博开始吐槽阿里云，都提到了自己的优化方案：1、该换个云了；换个云能解决问题吗？使用其他云的朋友可以评论一下失败的频率。我相信每个公司都有自己的问题，我什至愿意相信阿里云的失败率是比较低的。2、是时候自己搭建机房了；自建机房能解决问题吗？自己搭建机房的朋友可以评论一下故障频率。说实话，让我自己建机房，我真的没有信心做的比阿里云好。3、机房要多，活动要多；“多机房多活动”不是四个字那么简单，需要多少成本，需要多少技术基础服务支持，需要多少结构改造，你考虑过吗？画外音：58同城2015年我在做机房迁移的时候，机房做的太多，工作也多，所以还是有一定的话语权的。我相信99.9%的公司以他们现在的业务阶段和现在的投入产出比，都不适合多机房，多活动。骂阿里云解决不了问题。我们必须继续改进我们在这次事故中发现的问题。尤其是服务治理体系、可视化监控和运维体系任重道远。不要给阿里云洗地，阿里云，你影响了我们几个小时的业务可用性，你应该付出应有的代价，争取双倍赔偿，让我们看到你的诚意。画外音：谁有XX云的联系人联系方式，求告知。最后，最让我感动的还是一起熬夜战斗的兄弟姐妹们。上午，有同学赶到公司，对运营上报不一致的数据进行更正。我相信，因为有你，生意才能做成。相信大家的付出都会被老板看到，3/4月份的涨薪一定是你们的功劳。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
