pengjunlong
commented
6 years ago 过去四年，Netflix已经从不到5千万用户增长到1.25亿用户。虽然这种增长使我们不乏扩展性挑战，但我们实际上设法在这段时间内提高了我们服务的整体可用性。在此过程中, 我们学到了很多东西, 现在我们对如何使我们的系统具有更高可用性有了更深入的了解。但也有不好的地方，事实是, 我们花很大代价得到了很多经验教训: 通过英雄主义, 通过当事情发生差错时疯狂的慌乱 , 甚至更不幸的是通过用户侧的事故。尽管我们还没有弄清一切, 而且我们的系统还有很多改进空间, 但我们希望分享我们获得的一些经验和我们获得的技巧或最佳实践。希望你们中的一些人会学到一些东西, 这将避免你在凌晨3点被一个线上事故电话叫醒。 在 Netflix, 我们已经建立和使用Spinnaker作为一个平台, 进行持续集成和交付。这里讨论的许多最佳实践都加入了Spinnaker, 因此它们很容易遵循落地。在本文中, 我们展示了我们内部在Spinnaker中的最佳做法, 涉及的技巧和最佳实践尽可能通用, 这样可以帮助大家使自己的系统高可用。
- [x] Prefer regional deploys over global ones 灰度、部分部署，减小系统变更影响范围；各次发布间验证系统功能是否正常
- [x] Use Red/Black deployment strategy for production deploys 红/黑（或者蓝/绿）部署，红色部署新版本，黑色保留旧(之前线上正常)版本，红色部署好后下掉黑色流量；红色出问题时可快速启用黑色版本
- [x] Use deployment windows 部署新改动时关注：1、你能否观察线上现象并在有问题时及时处理；2、你能否把问题影响的用户范围尽可能减小 这要求你对业务流量随着时间变化规律有了解，我们的用户不论住哪一般都在晚上使用我们的服务，所以可以选在白天工作时间或其它非高峰期发布
- [x] Ensure automatically triggered deploys are not executed during off-hours or weekends 部署时间窗口也要对自动触发的部署进行限制，保证不在休息时间和周末（我们业务的高峰期）进行
- [x] Enable Chaos Monkey 故障演练：Chaos Monkey是我们构建和开源的，它随机、自动终止生产环境的实例，这就要求所有服务在设计时就考虑好容灾容错，否则就会被它发现；这可以让问题故障在被用户发现成为线上事故前暴露出来
- [x] Use (unit, integration, smoke) testing and canary analysis to validate code before it is pushed to production
快速迭代的关键是能在新改动上线前自动测试，理想情况下不需要任何人工干预；另外金丝雀分析也很重要，Google和Netflix联合发布了全新的开源Canary分析工具Kayenta
Canary(金丝雀部署)是现代Devops和持续交付中重要的一环，指的是把少量(通常1%-3%)的流量导到含有新版本的canary部署上运行一段时间并和当前的生产环境比较，再决定是否将新版本部署到所有机器的过程。
- [x] Use your judgement about manual intervention 尽可能自动化，但在适当的地方使用人工干预。例如，在将新版本推向生产之前检查金丝雀运行的结果可能人工参与更好。
- [x] Where possible, deploy exactly what you tested to production 将测试验证过的镜像部署到生产环境
- [x] Regularly Review paging settings 提前关联负责处理某类问题的人员（如“页面负责人”），这可以保证真正出问题时快速找到负责解决问题的人，定期检查保证最新。
- [x] Know how to roll back your deploy quickly 你们可能都会同意，即使有完善的测试、金丝雀分析等，仍会把导致问题的改动部署到线上，这可能因为只有在线上规模时才会触发问题，所以这时如何快速回滚到最近的稳定版本很重要。
- [x] Fail a deployment when instances are not coming up healthy 实例部署了但并不能提供服务（不健康），就不能给它流量；清楚地将实例状态标记为即将启动，等待发现，不健康和健康
- [x] For automated deployments, notify the team of impending and completed deployments 当出现问题时，重要的是要知道发生了什么变化以及何时发生了变化。因此，对于自动部署，通知团队以便他们知道如何密切关注服务健康状况尤为重要
- [x] Automate non-typical deployment situations rather than doing one-off manual work 非常用部署场景最好也自动化，而不是通过一次性手工操作；定时check这类自动化脚本是否正常
- [ ] Use preconditions to verify expected state We all operate in a world where systems change around us frequently. At Netflix, our hundreds of microservices change on an ongoing basis. Making assumptions, for instance about the state of other systems, can be dangerous. Learning from our own mistakes, we now use preconditions to ensure that assumptions are still valid when we deploy new code or make other changes. This is particularly important for pipelines that execute of long periods of time (possibly from a delay in manual judgement and/or deployment windows). Using precondition stages can verify expected state before potentially destructive actions.
- [x] Conclusion 这篇文章总结了我们多年来在Netflix积累的各种技巧和最佳实践，大部分从我们自己遇到的问题中学习总结的。我们的方法是尽可能地围绕这些最佳实践建立工具，因为我们发现，人工操作比较脆弱且让人不愉快，容易“陷入成功的陷阱”，尽量减少手动操作，这样让最佳实践更容易落地执行。 我们的目标是始终提高我们服务的可用性。对我们来说，这意味着在真正需要手动操作时才让人参与，否则尽可能自动化。通过这样做，我们将工程师的时间用于那些可以提高可用性的任务，同时还可以在不需要他们参与的情况下让他们专注于其他事情上。
https://medium.com/@NetflixTechBlog/tips-for-high-availability-be0472f2599c