昨天，科技圈又发生了一起重大技术故障。这次失败直接导致了国内半数互联网的瘫痪。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小时后，阿里云才得以进入机房抢修。据美国媒体昨日报道，根据美国市场研究机构SynergyResearchGroup的数据，今年一季度，阿里巴巴超越IBM成为全球第四大云基础设施及相关服务提供商，仅次于亚马逊、微软和谷歌。阿里云的失败只是运维失误？对于昨天阿里云的大规模故障，今天凌晨，阿里云官方微博公布了故障原因。直接原因是“运维失误”，改进措施是“检讨完善自动化运维技术和发布验证流程”。值得肯定的是，我们可以坦诚地公布问题，而不是用系统抖动、断纤之类的话来敷衍大家。除了公告中提到的增强发布流程验证外，我认为值得重新审视系统的整体隔离保护体系。长时间的故障暴露了应急处理手段和预案的缺乏。在一个不断发展的系统中，问题是不可避免的。反复强调或追求没有问题未必是最好的方向。团队具备快速解决问题的能力通常更可行。出现问题后，只要有相应的手段隔离问题范围（类似于大楼的防火门），减少对非故障模块的干扰，通常不会对用户整体造成干扰。从昨日的情况来看，要么没有防火门设计，要么系统有类似机制，但操作人员无法熟练启动。如果是前者，则需要重新审视整体架构，如果是后者，则是团队内部需要反思的问题。***写的每一次失败，确实不应该发生，但有时又是无法避免的。对此，不少网友表示，理解同为程序员的程序员解决问题比解决人更重要。但也有不少人认为：如果失败可以原谅，那么客户的损失又该如何计算呢？如果事故是因为不按规范操作造成的，就必须受到处罚，否则这次事故的检讨将是一次无价的体验。技术员肯定有过错，但是这件事应该升级，而不是只是技术员或者开除。注：部分资料来自高可用架构，其他资料整理自网络。
