浏览量 4364
2016/03/04 16:21
很多朋友经历了昨晚阿里云3小时左右的故障，我司的业务也受到了一定影响，技术的同事一起熬夜奋战，最终观察服务稳定运行了两个多小时，直到凌晨五六点多才逐渐登出VPN。
一次事故如一场战役，不管是在故障过程中的处理，还是故障后的总结，除了骂阿里云，我们自己有没有可以改进的空间呢？结合我司昨夜的处理过程，说一下自己的一点想法。
画外音：技术人，还是聊技术，决定不了别人，我们做好自己。
一
凌晨，收到运维负责人的电话，阿里云部分机房故障，并从阿里云同事收到反馈，问题仍在定位，恢复时间不确认。
画外音：关键时刻，手机欠费了，运维负责人还帮我充了200话费，才打通，真曲折。
整个过程中，我们能做什么呢？
1. 第一时间反馈业务方：例如客服，运营等，如果收到用户反馈，能够及时说明情况；
2. 确定影响范围：因为不是所有服务器都受影响，确定范围后好针对性检查；
这里面，潜在的技术问题是：
1. 运维在第一时间收到服务器告警了么，研发与测试在第一时间收到站点与服务告警了么？为什么没有收到，是没有告警，还是告警覆盖缺失？
画外音：如果让业务方先发现问题，反问技术部，服务怎么出问题了，是何等尴尬？
2. 能够快速确定受影响的服务器IP么？以及受影响的业务范围么？
我们的运维同学立刻通过脚本，确定了大概有50来台服务器受影响。
DBA同学也立刻确认了，RDS数据库服务没有受到影响。
画外音：
（1）未来要自动化，可视化；
（2）除了能从前端发现A、B、C功能不可用，能从后端精准确定哪些服务，多大比例的流量受影响么？
潜在的非技术问题：
1. 技术团队和业务方建立了反馈渠道么，沟通是否顺畅？
2. 有没有“线上服务第一”的意识，有没有“系统值班”的制度，还是说，关着手机睡觉？
画外音：
（1）昨晚绝大多数二级，三级部门负责人都第一时间投入战斗，很赞；
（2）技术人，关着手机睡觉，是不可接受的。
二
过了一个多小时了，阿里云仍未反馈修复时间，这个时间大家都有点着急了，那除了干等着，我们自己能做些什么呢？
因为只有部分区域的服务器异常，能不能申请一些新的服务器，将受影响服务器上的站点与服务重新部署，通过服务治理将流量切到新的服务上，是不是能恢复（至少部分恢复）呢？
整个过程中，我们能做的是：
1. 申请新服务器；
2. 确认受影响的站点与服务、重新部署；
3. 服务治理，将流量迁移；
这里面，潜在的技术问题是：
1. 能不能快速进行服务器扩容；
画外音：昨晚我们迅猛购买了50台ECS，这是云的好处。
2. 知道了受影响的服务器IP，如何能够快速确定这些IP上部署了哪些站点与服务？这些站点与服务的上下游是什么，连带影响范围是什么？
画外音：这是有待提高的地方，每个负责人都知道自己的IP上部署了什么，但并不可视化。
3. 如何快速站点与服务扩容与缩容，如何服务发现，如何迁移流量？
画外音：服务治理，任重道远。
三
又过了大概半个小时，我们购买完服务器，梳理站点与服务的过程中，阿里云专家反馈，“问题定位有了关键进展，不出意外的话30分钟恢复”。此时我们内部评估，30分钟50台ECS的初始化，服务部署，流量迁移恐怕完不成，还是等阿里云好了。
果真大概半个小时，阿里云专家反馈恢复了，这时我们要做的：
1. 确定站点与服务是否运行；
2. 确定日志是否异常；
3. 确定业务在线业务是否异常；
4. 一些容易遗漏的点的再三检查：例如MQ的消费，定时任务的执行。
画外音：有些定时任务可能需要手动再次执行。
这里面的很多工作，是通过手工，还是脚本自动化，还是平台可视化来判断与执行？技术平台的迭代，仍重而道远。
四
服务观察稳定后一段时机，大部分技术同学陆陆续续登出VPN下线了。朋友圈、微博上开始对阿里云进行声讨，都在提自己的优化方案：
1. 是时候换一个云了；
换一个云能解决问题么？用其他云的朋友，可以评论反馈下故障频率。
我相信，各家有各家的问题，我甚至愿意相信，阿里云的故障率是相对较低的。
2. 是时候自建机房了；
自建机房能解决问题么？自建机房的朋友，可以评论反馈下故障频率。
说实话，让我自建机房，我目前真没有信心做得比阿里云更好。
3. 是时候多机房多活了；
“多机房多活”不是四个字这么简单，需要多大的成本，需要多少技术基础服务支撑，需要多大的架构改造，有考虑过么？
画外音：58同城15年做机房迁移时做过多机房多活，我还算有一定发言权。
我相信，目前99.9%的公司，目前的业务阶段，目前的投入产出比，不适合做多机房多活。
骂阿里云不解决问题，这次事故过程中发现的自身的问题，我们要继续去改进。
特别是服务治理体系，可视化监控与运维体系，任重而道远。
引用自:沈剑
上一篇 搜索 下一篇