所在文集：InfoQ 迷你书
原文地址：https://mp.weixin.qq.com/s/Pak3ADWx5Wlgtkn8lTODVA
在 Netflix，我们使用 Spinnaker 作为持续集成和交付的平台。Spinnaker 是 Netflix 开源的持续交付平台，定位于将产品快速且持续地部署到多种云平台上。
优先考虑区域部署而不是全球部署
更具体地说，我们一次只部署一个 AWS 区域，这为我们的生产部署提供了额外的安全保障。我们能够快速地转移受影响的客户流量，这也是我们最重要的四大补救手段之一。
使用红黑部署策略进行生产部署
在红黑（也称为蓝绿）部署中，新版本的应用程序（红色）在通过健康检查之后立即开始接收流量。在确定红色版本的健康状态之后，之前的（黑色）版本将被禁用，并且不会收到任何流量。如果要回滚，只需要启用以前的版本即可，非常简单。这种模型加快了我们的部署流程，并可以在出现问题时回滚到之前的状态。
使用部署窗口
不要在非工作时段或周末自动触发部署
启用 Chaos Monkey
Chaos Monkey 以不可预测的方式随机终止生产环境中的实例，以此来增强服务，让服务具备应对单实例故障的弹性能力。如果某些服务不具备弹性能力，Chaos Monkey 将会暴露出它们的漏洞，服务所有者就可以在这些漏洞演变成影响用户的事故之前修复它们。
在 Netflix，生产环境中的所有服务都应该启用 Chaos Monkey，在 Chaos Monkey 终止应用程序实例时，服务所有者不应该检测到任何问题。
在将代码推送到生产环境之前使用各种测试和金丝雀分析来验证代码
金丝雀分析是一种通过实时流量来验证服务变更的有效方法。最近我们开源了内部工具 Kayenta，它可以轻松集成到 Spinnaker 中，并结合人工判断，成为放开所有生产流量之前的最后一道门槛。
必要的人工干预
部署时尽可能只用已经测试过的东西
定期检查联系人设置
知道如何快速回滚部署
如果实例运行不正常，将部署视为失败
多年来，有几次我们在部署成功后感觉状态不对，实例起来了，但不能正常处理流量。“成功”的部署给我们造成了一种假象，当一个关键的服务运行不正常时，请求很快会堆积起来，有时会导致重试雪崩，造成各种各样的破坏。因此，当实例运行不正常时，要将部署视为失败。
在进行自动部署时，需要通知团队有关部署的情况
自动化非典型部署，而不是进行一次性手动部署
使用先决条件验证预期状态
一个补充，什么是 A/B 测试？
参考 https://www.v2ex.com/t/344341
A/B 测试是用来测试应用功能表现的方法，例如可用性、受欢迎程度、可见性等等。 A/B 测试通常用在应用的前端上，不过当然需要后端来支持。
让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。
一个补充，什么是 灰度发布/金丝雀部署？
参考 https://www.v2ex.com/t/344341
灰度发布是在原有版本可用的情况下，同时部署一个新版本应用作为“金丝雀”（金丝雀对瓦斯极敏感，矿井工人携带金丝雀，以便及时发发现危险），测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现、调整问题。
灰度发布／金丝雀发布由以下几个步骤组成：
- 准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。
- 从负载均衡列表中移除掉“金丝雀”服务器。
- 升级“金丝雀”应用（排掉原有流量并进行部署）。
- 对应用进行自动化测试。
- 将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。
- 如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）
