系统运维

在系统设计阶段为了保证系统的高可用可以采用上面几种方案，那么在系统的运维层面又能做哪些事情呢？其实，我们可以从灰度发布、故障演练两个维度来考虑提升系统的高可用。

你应该知道，在系统平稳运行过程中，系统是很少发生故障的。90%的故障发生在上线变更阶段。比如，你上了一个新功能，由于设计方案的问题，数据库的慢请求数翻了一倍，导致系统请求被拖慢而产生了故障。

如果没有变更，数据库怎么会无缘无故产生那么多慢请求呢？因此，为了提升系统的可用性，重视变更管理尤为重要，而除了提供必要的回滚方案，以便在出现问题时能够快速回滚之外，另一个主要的手段就是 灰度发布。

灰度发布指的是系统的变更不是一次性推到线上，而是按照一定比例逐步推进的。一般情况下，灰度发布是以机器维度进行的。比如说，我们现在10%的机器上进行变更，同时观察Dashboard上面系统性能指标以及错误日志。如果运行了一段时间系统指标平稳并且没有出现错误日志，再推动全量变更。

灰度发布给了开发和运维同学绝佳的机会，可以在线上流量观察变更带来的影响，是保证高可用的重要关卡。

灰度发布是在系统正常运行条件下执行的，那么如何知道系统发生故障时的表现呢？那就需要另外一个手段：故障演练。

故障演练是对系统进行一定破坏性的手段，观察系统局部出现故障时，整体系统的表现怎么样，从而发现系统中存在的、潜在的可用性问题。

一个复杂的高并发系统以来了太多的组件，比如说磁盘、数据库、网卡等，这些组件随时随地都可能发生故障，而一旦他们发生故障，会不会像蝴蝶效应一般引起群里性的系统可用性问题呢？我们不知道，所以 故障演练显得尤为重要。

在我看来，故障演练跟当前比较流行的 混沌工程 思路如出一辙，作为混沌工程的鼻祖，Netfix 在 2010 年推出的“Chaos Monkey”工具就是故障演练绝佳的工具。它通过在线上系统随机关闭线上节点来模拟故障，观察在出现此类故障系统会有什么影响。

当然这一切是以你的系统可以抵御一些异常情况为前提的，如果你的系统还没有做到这点，那么建议你搭一套跟线上系统一模一样的线下系统，然后再这套系统做演练，避免对生产系统造成影响。

总结

这三节 从开发和运维两个角度来聊 提升系统高可用的方案，侧重点不同：

开发注重的如何处理故障，关键词冗余和取舍。冗余指的是有备用节点，集群来顶替有故障的服务，比如文中提到的故障转移、多活架构等。取舍指的是 保障 主体服务的稳定性，可以舍弃非主流的业务过程。

运维角度看则更偏重于保守，注重的是如何避免故障的发生，所以更关注变更的管理，如何做故障演练等。

两者结合才是一套完整的系统高可用方案。

提高系统的可用性有时候会牺牲用户的体验这也是一种取舍。需要我们把我一个度，不该做的优化，坚决不做过度优化。根据不同系统的要求保证系统的可用性程度。比如配置中心的可用性 就要高于核心业务系统甚至，配置服务可以响应的稍微慢一些，但是一定要保证可用，否则 配置系统挂了，所有系统的配置信息都获取不到，带来的就是整体性的系统灾难了。