编辑推荐

网易数帆开源API网关与容器云项目，让云原生生产落地“多快好

网易汪源：统一负载与多云环境的“开放姿态”，才是云原生

网易数帆如何用 Kubernetes“原语”搞定云原生中间件

快手打新挤爆券商系统，网易数帆推出券商稳定性保障方案

探索智慧校园新模式，网易有数在教育行业的实践分享

金融行业大数据治理之路——数据模型篇

复杂分布式系统的可运维性设计

叁叁肆2018-09-19 14:11

本文来自网易云社区

作者：施勇

可运维性

分布式系统的可运维性，发生在运维人员对系统进行运维操作的阶段，主要包含以下几个方面的含义：

运维操作的难易程度。系统部署、升级、修改、异常处理等运维操作是否容易，是否容易发生误操作。
运维操作产生的影响。各类运维操作对业务产品的影响大小。
系统运行状况监测及问题处理措施。确保系统正常稳定运行的各类监控措施是否完备，各类异常情况的预见和应对措施是否齐全有效，未曾预见的问题是否能够快速定位并加以解决。

这里所指的可运维性，与软件工程中的可维护性有所区别。软件的可维护性，在软件工程中包含可理解性、可测试性、可修改性、可靠性、可移植性及可使用性。我们这里讲的分布式系统可运维性，着重于系统的运维操作和确保系统正常稳定运行的各种措施。

基本原则

分布式系统的可运维性，需要在系统设计之初就做好规划与设计，在开发阶段加以实现，并进行上线前的详细测试和上线后验证测试。开发一个对运维友好的分布式系统，注意几点基本原则：

任何组件和部件都会出现异常，都可能在任意时间停止服务，需要优雅地处理各类异常和故障。
保持简单。做简单的事情容易做正确，避免不必要的依赖，组件和服务之间需要有隔离措施。
尽可能自动化，让机器做事。人是不可靠的，需要睡觉，容易在大压力下犯错误。经过测试和验证的自动化流程，比人可靠的多。

具体建议

保障分布式系统的可运维性，我们可以提供以下一些具体方面的建议：

1. 为运维考虑设计

有经验表明[1]，系统的80%的运维操作，源自于系统的设计和开发。在提供服务的系统中，将运维人员和设计开发人员分离的做法往往效率不高，可以倡导DevOps[2]来提升系统服务的质量。
提高系统的可运维性，从设计角度考虑：

故障设计，是分布式系统设计中的一个核心思想。系统中的组件和部件，可能经常会出现故障，如果系统某个组件或依赖的部件出现故障，必需运维人员马上介入，那么系统的可靠性和可扩展性就不会很好，可运维性也不高。系统设计之初需要考虑各个故障，其整体服务需要在部分组件出现异常且没有及时人为干预的情况下仍然提供必要的服务，为此故障自动处理和恢复的流程必须经常加以测试以确保执行正确。
冗余和故障恢复。系统组件需要能够提供冗余机制，并且在组件出现故障的时候，对整体服务没有影响，且能进行自动恢复。比如，当运维人员关闭系统中任何一台服务器的时候，系统是否还能正常服务，当服务器重新启动恢复正常的时候，系统能重新接纳此服务器。系统做冗余，也即避免出现单点故障，如果系统中的组件都是无状态的，那么做冗余避免单点故障比较容易，但如果是数据库呢？数据库可以作一个冗余备份节点，若一定要保证冗余和自动故障处理，则可以牺牲部分性能，对两个数据库作同步处理。
硬件规范化和适配性。系统服务部署的硬件尽量能够规划统一化，比如需要多少CPU、多少内存、多少磁盘、多少网络带宽等。但需要满足一定的适配性，既能用物理服务器，也能利用云计算的虚拟机来部署服务。
版本统一和兼容性。系统服务尽量只提供一个稳定运行的版本，但在系统版本升级等过程中需要兼容此前版本。
允许紧急人为干预。虽然系统设计的时候尽量保证将各类操作和故障处理都自动化，但当多个故障一起发生或者人为错误发生的时候，不得不马上进行人为干预，系统需要留有紧急人为干预的方法。在大多数情况下系统能自动处理，在必需的情况下能让运维人员进行干预。各种异常处理的脚本，需要事先编写好且经过测试，而不只是一个异常处理的文档。所以线上系统需要定期进行各类异常的演练，如果线上异常演练的代价过高，则说明系统设计的不够充分，需要重新加以考虑。
快速的健康检查。系统必须支持一个快速的健康检查方式，在系统部署、升级等各类运维操作完毕之后，进行一个快速的健康检查以确认系统核心服务没有问题。这个快速的健康检查方式，可以是系统回归测试的一个核心的子集。
服务隔离、准入控制和优雅降级。系统各个组件的服务之间需要加以隔离，确保服务之间不会互相影响和故障范围蔓延。每个层级的组件服务，都需要做好准入控制（流量、请求等），当超过自身服务能力的请求来临时能主动拒绝或优雅降级处理，来保证服务的稳定性。
管理运维脚本和工具。各类运维的操作脚本、工具和代码，需要经过开发人员的审核，与系统开发的代码一同进行管理和测试。

2. 自动化管理

分布式系统常常需要提供7x24的服务，如果系统出现故障就需要运维人员干预恢复，通常运维人员在做一些重大决定的时候往往出现错误，那么系统服务可靠性就得不到保证。系统的可运维性，要求系统提供自动化管理的机制。为了提高自动化水平，系统设计的时候可能需要牺牲一些性能（延迟和吞吐量），当分布式系统运维操作复杂或者系统非常大的时候，这种牺牲往往是值得的。有数据表明[1]，一个基本自动化的系统比一个基本人工处理的系统，在人力成本上节省近2个数量级。

可重复操作。所有运维操作都可以被重复执行，所有状态都是持久化冗余保存。
自助配置和安装。规范化系统的各类配置以及安装流程，进行自动化。如果由运维人员来手工处理服务的配置和安装，各个服务的细微配置差异可能扩散并影响服务，以及定位问题原因将比较困难。任何在线上需要作变更的操作尽量能作成配置，并且需要支持在线修改。
配置和代码作为一个单元。配置和代码是一体的，两者必须一起发布、一起打包部署。
依赖管理。对系统依赖的服务做好管理，比如服务调用超时控制、故障隔离（比如，调用服务出现故障情况下主动屏蔽调用接口一段时间）、使用成熟的软件或服务、降低依赖（比如，利用缓存等措施降低调用频率）。
网络命名，尽量使用CNAME及DNS，避免使用IP等直接提供服务。
自动故障处理和定期故障演习。当组件或服务出现故障的时候，自动进行故障恢复确保对整体服务不产生影响或限制影响范围。需要定期在线上系统对各类故障进行演练，比如关闭一台服务器、关闭一个服务组件等来验证系统是否都能自动进行处理，如果不在线上系统演练，那么各类故障恢复等处理措施可能在真正发生故障的时候不会正常工作。
资源利用跟踪和报告。自动对系统服务的资源利用情况和产品业务情况做好统计跟踪，并且识别出业务规模增长与资源增长之间的联系，能够实时查询系统服务的资源利用情况和产品业务情况；定期（每月）对业务关键指标（用户量、访问请求等）和系统资源使用情况做出统计报告，以评估硬件资源采购需求。
变更追踪。系统进行的任何变更，都需要记录下来，以便后续能够追踪，包括谁在什么时间做了具体什么变更操作。

3. 日志、监控和报警

一个复杂的分布式系统在实际运行过程中，难免会出现各类无法预见的问题。为了让系统在这种异常环境下还能提供稳健的服务，除了系统设计的容错和健壮性之外，还需要做好日志、监控和报警。

日志。系统的日志包括变更日志、服务日志等，变更日志详细记录系统进行的任何变更（谁在什么时间做了具体什么变更操作），服务日志记录从接收外部请求到内部各个组件处理过程的整个流程。对于服务日志，需要能够增加在线修改日志级别的功能，以便在排查问题的时候能马上进行详细的调试。服务日志中，需要增加对特定异常、关键服务性能指标以及故障自动恢复等的记录，便于监控服务状态的稳定运行。
监控。

系统监控：系统部署所在服务器和网络的健康状态。
服务监控：系统整体服务的可用性、稳定性和性能指标。
应用监控：外部依赖服务的可用性和稳定性；若外部依赖服务影响自身服务的性能指标，需要对外部依赖服务做好性能监控。系统内部各个模块的可用性、性能指标以及各模块衔接的连续性。系统异常日志的监控。系统后台线程的健康状态。

报警。报警的原则是报警内容必须有对应的行动措施，如果只有报警而没有行动措施，那么这个报警被运维人员忽略，很容易导致运维人员将需要关注的报警也忽略掉。一个优秀的报警系统，报警正确率接近100%，误报率接近0%。

跟踪故障处理并报警。故障自动处理会隐藏错误，对系统的故障自动处理需要作合适的报警机制，比如一个总共1000台服务器可容忍100台故障的系统，当系统中出现1台服务器故障可能需要邮件通知运维人员，当系统中总共有多达50台服务器故障的时候需要实时通知到系统整个团队成员。
智能的报警策略。根据各类故障影响和级别，利用不同方式和策略通知到不同层级的人员。
详细的报警内容。报警内容中必须包含有系统对应问题的详细描述，以便快速定位问题并响应。

4. 自助化用户系统

提供用户自助化帮助系统，帮助提升用户满意程度。

当用户在使用系统服务出现问题的时候，可以直接查询系统中获取对应问题的原因和解决方式等，降低沟通成本，比如各种FAQ或自助问题查询系统。
查询用户关心的服务数据，提供用户得到的系统服务的关键指标的统计，便于用户了解系统服务质量（比如，此用户在系统中的吞吐量、服务响应时间、数据量等）；当用户对应服务指标出现异常情况下，及时通知到用户。