|
虽然面向云环境的迁移确实能够在稳定性与弹性方面为企业带来巨大帮助，但是各种不易被发现的依赖性也因此增加，单一服务失败可能引发大规模服务瘫痪。Nick建议云用户的开发与运营团队审查与云服务供应商间的核心依赖关系，制定策略以监控各项服务可能受到的影响，同时调整现有架构以提升关键性用户的冗余水平。 故障演习很重要 对于这次事件，陈皓在其博客中表示美国东一区作为老牌的服务区拥有海量对象，能在数小时恢复已属不易，并且幸运的是没有丢失重要数据。 陈皓重申了其观点：一个系统的高可用的因素很多，不仅仅只是系统架构，更重要的是——高可用运维。并且，他认为对于高可用的运维，平时的故障演习是很重要的。AWS 平时应该没有相应的故障演习，所以导致要么长期不出故障，一出就出个大的让你措手不及。比如，Facebook每个季度扔个骰子，随机关掉一个IDC一天。Netflix 有 Chaos Monkey，路透每年也会做一次大规模的故障演练——灾难演习。 在陈天看来，这种容错的操练适合大一些且工程团队有余力的公司。为什么Netflix 重度使用 AWS，却在历次 AWS 的宕机中毫发无损？其实Netflix之前也深深地被云的「不稳定性」刺痛过，而如今他们的 Chaos Monkey（之后发展为 simian army）服务，会随时随地模拟各种宕机情况，扰乱生产环境。比如说对于此次事件的演练，可以配置 simian army 去扰乱 S3：simianarmy.chaos.fails3.enabled = true。 这样，这群讨厌的猴子就会在不知情的情况下随机把服务器的 /etc/hosts 改掉，让所有的 S3 API 不可用。如此就可以体验平时很难遇到的 S3 不可访问的场景，进而找到相应的对策（注意：请在 staging 环境下谨慎尝试）。 8处理危机的方式能看出一个公司的高度 陈皓表示非常喜欢GitLab、AWS这样向大众公开其故障及处理流程，哪怕起因是一个低级的人为错误，也不会掩盖、不会文过饰非。AWS公布的后续改进方案都是为了让系统更加高可用，这是很技术范儿的表现。恐怕对比国内公司对于此类故障，基本上会是下面这样的画风：更多更为严格的变更和审批流程，限制更多的权限系统和审批系统，更多的人进行操作，使用更为厚重的测试和发布过程，惩罚故障人，用价值观教育工程师。 在陈皓看来——如果你是一个技术公司，你就会更多的相信技术而不是管理。相信技术会用技术来解决问题，相信管理，那就只会有制度、流程和价值观来解决问题。（注意：并非隔离技术和管理，只是更为倾向于用技术解决问题） 事故发生后，InfoQ联系了AWS工作人员并表达了采访意愿。AWS虽然最终婉拒，但是称媒体的客观报道可以督促其提升技术服务质量。 这段时间，IT界尤其是大公司发生的技术故障并不少见。当IT技术服务越来越多的人的时候，宕机之事也自然也会影响并引得广泛的关注。众目睽睽之下，如GitLab和AWS这样保持坦诚踏实的态度，其实是在用另一种方式赢得对技术的尊重。没有人愿意看到问题的发生；但是问题出现后，最重要的解决反思并从中汲取教训：这难道不是技术人应有的傲骨吗？ 9参考文章 https://aws.amazon.com/cn/message/41926/
https://www.infoq.com/news/2017/03/aws-s3-disruption https://www.infoq.com/news/2011/04/Amazon-EC2-Outage-Explained (责任编辑：本港台直播) |