阿里云“炸了”，又是运维的锅?

“

昨天，技术圈又出一次重大技术故障。这一故障，直接导致了国内半个互联网瘫痪。

6 月 27 日，据网友反映，阿里云官网出现大规模访问异常，图片服务等产品无法正常使用，官网账号也无法登陆。

这次故障于北京时间 2018 年 6 月 27 日，16：21 左右开始，16：50 分开始陆续恢复。官方给出的故障时间大概持续 30 分钟，陆续恢复时间有一个小时多。

阿里云挂了，技术圈沸腾了，以下是各路网友的吐槽：

最怕就是在上线交差的时候出现了 Bug。

随后，阿里云正式发布通告称，于北京时间 2018 年 6 月 27 日 16:21 分左右，阿里云官网的部分管控功能，及 NAS、OSS 等产品的部分功能出现访问异常。阿里工程师正在紧急处理中。

在 6 月 27 日凌晨时分，阿里云给了官方说明，故障起因是上线一个自动化运维新功能时，执行了一项变更验证操作，触发了一个未知代码 Bug，错误代码禁用了部分内部 IP，导致部分产品访问链路不通。

阿里云称，“对于这次故障，没有借口，我们不能也不该出现这样的失误！我们将认真复盘改进自动化运维技术和发布验证流程，敬畏每一行代码，敬畏每一份托付。 ”

阿里云近年故障历史：

• 云盾升级触及 Bug 造成服务器大量文件被误隔离。正是因为这一低级错误，影响了大范围的用户，造成了用 top 进程、top 命令、apt-get 相继被灭。

• 阿里云北京机房内网故障引发大面积服务异常。

• 阿里云香港服务瘫痪 12 小时主要是因为机房建设方和运营商电力故障，阿里云直到电力故障发生近 12 个小时后才得以进入机房抢修。

昨日美国媒体报道，据美国市场研究机构 Synergy Research Group 的数据，今年第一季度，阿里巴巴超越 IBM 成为全球第四大云基础设施及相关服务的提供商，落后于亚马逊、微软和谷歌。

阿里云故障，仅是运维操作失误？

对于昨日阿里云出现大范围故障，今天凌晨，阿里云官方微博公布了故障的原因，直接原因是由于"运维操作失误"，改进措施是"复盘改进自动化运维技术和发布验证流程"。

能坦诚的公布问题，而不是用系统抖动或者光纤挖断之类的词来敷衍大家，这一点值得肯定。

除了公告提到的增强发布流程验证之外，重新审视系统整体的隔离保护体系我觉得也值得一做。故障的时间偏长，暴露了对突发问题处理手段及预案的匮乏。

一个不断演进的系统，出现问题不可避免，反复的强调或者追求不出问题未必是最佳的方向，让团队具备快速解决问题的能力通常来说更加可行。

出了问题后，只要有相应的手段来隔断问题的范围（类似大楼里面的防火门），减少对非故障模块的干扰，通常不会对用户整体造成干扰。

从昨天的情况来看，要么就没有防火门的设计，要么系统有类似的机制，但是处理人员不能熟练地启用。

如果是前者，则需要重新审视整体架构，如果是后者，那就是团队内部需要反思的问题。

写在最后

每一次的故障确实不应该发生，但有时又难以避免。对此，不少网友表示，理解身为同行的程序员们，解决问题比解决人更重要。

但是也有不少人认为：

• 出了故障可以原谅，那客户的损失该如何算？

• 如果是没按规范操作导致的事故肯定是要处罚的，否则这次事故的复盘就是无价的经验啊。

• 技术人员肯定得背故障啊，但是这事应该要升级，不是说一个技术人或者开除就算了的。

对此，你怎看呢？欢迎底部留言分享！

来源：《阿里云故障，仅是运维操作失误？》作者Tim Yang，转载自高可用架构微信公众号，其他素材为互联网综合整理。

在云计算遍及业界的趋势下，以及 DevOps 和 SRE 等先进运维理念的强势助推，运维已然成为驱动各大公司研发运维流程和理念变革的关键角色，如持续集成和发布、场景化的运维自动化、智能监控等理念的落地执行。

同时，运维所从事的工作角色定位也在悄然地发生着变化，从原来的末端被动响应，逐步转向技术产品、技术运营和平台建设者的角色。

6 月 30 日（本周六），我们将会邀请一线运维专家，在基于容器的持续集成和发布、智能监控和故障自愈、成本和性能优化几个方向上，分享他们的实践和思考，看看专家们在技术高速发展的趋势下，是如何应对这些新的挑战的。

活动推荐

扫描图中二维码，与多位专家沟通探讨技术高速发展下如何应对运维新挑战！