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

本文来自网易云社区

做者：施勇

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

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

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

1、配置和部署

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

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

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

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

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

各种系统实际运维的过程当中，常常会出现下面的状况，须要尽可能排除：

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

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

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

2、监控告警

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

相似天网的监控

复杂系统至少须要监控：

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

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

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

• 系统异常日志的监控。

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

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

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

智能的告警策略

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

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

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

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

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

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

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

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

3、故障处理

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

故障预见

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

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

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

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

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

故障现场保留

当系统出现故障后，须要对故障现场作好保留，便于后续分析、处理和改进。故障现场保留的方式一般能够有：

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

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

故障智能处理

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

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

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

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

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

• 系统自动故障恢复，须要尽量以代价小的方式来恢复，并作到总体资源可控。

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

4、小结

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

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

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

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

相关文章：
【推荐】 数据迁移的应用场景与解决方案Hamal
【推荐】 Android优化以内存优化倒计时篇
【推荐】 聊聊WS-Federation