如何开发一个可运维系统的一点体会

本文来自网易云社区

作者：施勇

我们在开发一个复杂系统的时候，常常会强调服务化、模块化、松散耦合等要求以达到高可用、高可靠及高性能等目的；比较少的人会考虑到系统的方便部署配置和运维，至少是在刚开始设计系统的时候很少考虑到运维部署方面的需求。这样的复杂系统，在正式投入使用之后，常常会因为部署配置和运维等方面问题造成系统不稳定甚至出现异常。

根据整个系统的生命周期，运维占据的比例和时间远远大于开发设计的时间，当然是排除了一些夭折的系统。所以在开发设计系统的时候，需要加强对于运维方面的重视。一个好的系统，除了受到产品用户的欢迎之外，还需要得到运维人员的认可，才能让系统更加健康地发展。反之，如果一个系统运维性较差，那么运维人员和开发人员可能会逐渐形成隔阂，进而影响整个系统的服务。

结合自己在开发和运维方面的经历，以及多年被无数短信告警骚扰的烦恼，谈谈在开发设计一个系统的可运维性方面需要注意的问题。

一、配置和部署

复杂系统在开发上线及运维的过程中，肯定需要经历各个不同的阶段：开发测试、QA测试、上线前测试、上线、后续版本更新等。不同阶段和环境下，系统都需要有不同的配置，对于配置和部署，最好能做到以下几点：

• 提供详细的配置和部署手册。

• 提供适用典型场景的各个配置模板。

• 提供灵活的关键参数可配置，以适应各类复杂的运行环境；尽可能提供在线动态修改的方式。

• 提供自动化的部署方案或脚本，在异常情况下能自动重启恢复。

各类系统实际运维的过程中，经常会出现下面的情况，需要尽量排除：

• 针对线上环境，系统未能提供足够的参数配置以适应其负载或优化服务。

• 系统提供了足够多的灵活可配置的参数，但未针对线上环境进行优化配置。

• 系统程序写死了配置目录路径等部分参数。

二、监控告警

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

类似天网的监控

复杂系统至少需要监控：

• 系统整体服务的可用性、稳定性和性能指标。

• 外部依赖服务的可用性和稳定性；若外部依赖服务影响自身服务的性能指标，需要对外部依赖服务做好性能监控。

• 系统内部各个模块的可用性、性能指标以及各模块衔接的连续性。

• 系统异常日志的监控。

• 系统后台线程的健康状态，这点很容易被忽略。

• 系统部署所在服务器和网络的健康状态。

系统需要提供对各项监控内容的查询显示，以便运维人员能够随时了解系统的运行状态；此外，最好能够提供查询API，方面运维集成。

智能的告警策略

当一个复杂的系统出现问题时，需要及时报警通知到相关的运维人员。在告警策略设计时，需要考虑到：

• 不同的告警等级，根据系统服务异常的原因和影响的范围，划分为不同等级并便指导不同的告警策略。

• 多样的告警方式，至少支持IM、邮件和手机短信的三种方式告警。

• 不同层级的告警接收人员。

告警等级	描述	告警方式和策略	告警接收人员
事故级	系统整体服务不可用或异常，造成业务损失	IM、邮件和手机短信；持续短间隔告警	运维、开发和产品业务，以及各自部门领导
故障级	系统服务不稳定，未对业务造成明显影响	IM、邮件和手机短信；持续告警	运维、开发，以及各自负责人
异常级	故障前兆，系统可能在不久将来出现故障	IM、邮件；固定周期告警	运维和开发人员
缺陷级	系统已知的缺陷，目前不会对整体服务产生影响	邮件；当系统触发缺陷时告警	运维或开发人员

告警程序设计上，高等级的告警需要被优先处理，不能因为低等级告警过多而造成高等级告警被延迟。同时需要支持对同类告警的暂停报警功能（暂停一段时间后自动恢复监控报警），便于运维人员计划性的维护操作。

告警内容的可读性，对于运维人员也非常重要，特别是手机短信告警的内容，应该能够让运维人员马上定位到是哪个服务器所在的服务出现了哪类问题；最恼人的告警短信是各个环境系统都是相同的内容： xx服务出现异常，请检查邮件和log 。

设计良好的系统，需要有接入统一的报警监控中心的能力。

三、故障处理

一个复杂系统需要提供良好的故障处理机制，包括故障预见、故障现场保留、故障智能处理等。

故障预见

系统在运行过程中，对其利用的资源和自身的运行状态做好监控，如果预见系统可能出现不稳定等情况，需要加以处理和告警。系统可预见的故障可能有：

• 所处的服务器硬件资源利用率上升，不久将来会到达上限，需要及时告警。

• 系统设计的有限制的资源的使用量将达到配置限额，需要及时告警。

• 系统处理效率突然降低，及时告警。一个容错备份的分布式系统，需及时屏蔽处理效率地下的组件，用其它备份的组件代替。

• 系统接收处理的请求量突升或突降，及时告警。

故障现场保留

当系统出现故障后，需要对故障现场做好保留，便于后续分析、处理和改进。故障现场保留的方式通常可以有：

• 日志。最简单直接的方式，但在日志输出格式和内容方面，需要做好设计；既要保证对系统性能影响和资源占用足够小，又要保留足够的信息供运维人员和开发人员排查。

• 性能和资源监控平台。详细记录服务器运行状态和各类资源的使用情况，可以了解故障发生时候的服务器硬件运行状态。

故障智能处理

一个复杂系统，必须要做到可容错和故障的自动处理及恢复。如果系统的可容错和故障自动恢复做得还不完善情况下，至少需要提供可人工运维处理的接口。最怕的是系统做了部分的故障自动处理，但处理机制有问题，并且没有提供有效的人工处理方式去解决，这个简直是运维人员的噩梦！一个系统在交付运维的时候，运维手册中必须包含各类故障的详细处理方式。

系统可容错和故障自动恢复，典型的场景有：

• 当某个依赖的底层服务异常情况下，系统自动屏蔽依赖此服务的请求或通过升降级方式绕过异常底层服务；若不行，也必须在底层服务恢复正常后，系统能立即自动恢复。

• 系统各个模块之间的容错性，包括部分模块异常或者模块衔接出现短暂问题，当问题解决后都需能立即恢复。

• 包含多备份组件的系统，当少数备份组件出现异常时候，其它备份需要立即接管其服务，并能够自动恢复到正常状态。

• 系统自动故障恢复，需要尽可能以代价小的方式来恢复，并做到整体资源可控。

当系统出现故障时，需要及时告警，通知运维和开发人员系统故障及对应的处理方式。如果故障自动恢复需要一定时间，恢复的进度也需要定期报告。

四、小结

一个可运维和方便运维的系统，不仅有助于运维人员快速掌握和上手运维，又能及时发现系统中可能存在的不稳定的异常的因素，从而促进整个系统更好更健康的发展壮大。系统的可运维性，不单单是系统上线之后要考虑的问题，而是要在系统设计之初就应该关注的一面，并且是贯穿到开发设计的各个阶段中的。

以上仅仅是个人对可运维系统的一点体会，希望以后能多多出现这样的系统，助更多的运维和开发人员脱离疲于奔命救火的苦海。

网易云免费体验馆，0成本体验20+款云产品！

更多网易研发、产品、运营经验分享请访问网易云社区。

相关文章：
【推荐】 OBS源码编译开发
【推荐】 试水新的Angular4 HTTP API