更如何做到高可用？

主要是管理部署期间的整个生命流程，通过将各个阶段的各个步骤进行罗列和长期维护，从而逐步形成针对特定变更场景的说明手册。

如果只是升级一台服务器的二进制代码，需要部署清单吗？答案是肯定的。不能把二进制代码变更等同于二进制文件替换，在替换动作之外，有很多的工作内容，仅仅是更新完毕以后，就需要考虑如下问题：

• 程序是否正常启动
• 日志是否存在异常信息
• 服务功能是否正常
• 服务性能是否符合预期
• 服务关键指标是否异常

对于多模块，多系统，多团队配合的变更操作，如果没有一份事前经过充分验证的部署清单，谁在什么时候应该做什么事情，准入条件是什么，交付标准是什么，有哪些操作禁忌和注意事项，那这种复杂变更的结果就只能靠运气了。

随着运维自动化水平的提升，部署清单并不会消失，而是在载体上有所不同，从早期的纸质上线单，到现在内置于部署系统中，实现了更好的经验传承，校验完善，流程管控，信息分享等。

绝大部分服务，都不应该由单个实例组成。那么，在变更的时候，就应该避免一次性升级所有实例，而应该分批次的逐步升级，并在每个批次间预留一定的时间间隔对上一批次进行观察和评估，从而决定是否继续进行升级，以此来保障变更的质量。

以 Google 为例，其灰度发布的比例，从 0.1% 开始，每 24 小时增长 10 倍推进，从 0.1%-> 1% -> 10% -> 100% （详见 Google SRE 中文版 162 页），并且灰度的初始比例一定不可以超过服务整体的冗余度。同时，在对服务进行变更操作的期间，需要将流量摘除，避免对线上产生影响，变更操作完毕后，方可引入灰度流量进行验证。

在灰度阶段，有针对性的选择灰度流量，尽可能完整的覆盖各类业务场景和用户类型，并通过流量调度形成局部热点，对服务的性能进行验证，避免全量上线可能出现的性能下降。

变更操作一定要有回滚预案，并能够快速回滚！日常的变更操作，只要有备份，大多数情况都可以进行回滚。那些无法进行回滚的，一般都是重大变更，这时候，等着你的基本上就是直接在线上调试并修 bug 以及超长的停机时间和大批的脏数据了。

不同公司对待回滚的态度不同，和其背后的专业能力有很大关系，因此不能盲从。如果对所有的回滚事件不加甄别的进行追责，那么导致的后果就是对于非核心故障，研发坚决不进行回滚操作导致带伤上阵，或者说将回滚美其名曰快速迭代。

比回滚更高效的方案是功能开关，在发现新功能上线有问题后，可以通过功能开关立即关闭该功能，从而起到更快速的止损效果。可以想象一个场景，一次上线后，发现 10 个功能里面有 1 个功能异常，且引发了部分脏数据，因为还需要确保其余 9 个功能正常，因此不能全并发回滚，只能按照预置的并发度进行回滚，那么回滚耗时就会较长，这时候，如果有功能开关，那情况就大不一样了。

既然线上有了变更保障能力，那为啥还要在线下费劲搞集成测试呢，直接在线上测不就行了吗？我们假设这个观点是正确的，那么所有未经测试的代码全部推送到线上开始灰度，在灰度阶段去发现各种问题，然后回滚，修复后继续上线。但灰度的流量，也是真实的用户，怎么能够拿用户的真实流量做这样的事情呢。因此，线下测试还是非常重要的环节，通过线下测试，将 80% 以上的基本问题拦截在线下环节，在灰度环节，更多的去解决线下环境无法覆盖的场景。

（编辑：大同站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!