《运维之下》第二章 | 运维的烦恼

如前一章所描述那样，随着业务和用户规模越来越大，公司对业务的稳定和质量开始重视起来，这时候公司才意识到需要专职的运维人员介入，而此时的业务系统已经变得非常庞大和复杂。此外，由于互联网产品快速试错的特点，服务架构也在不断地快速变化。
产品研发早期缺少相应的规范和标准，服务的部署方式、启停方式、配置和日志格式等都不统一，服务与服务之间的关联关系错综复杂，服务的各个环节都缺少监控；服务之间的耦合度很高，经常会由于一个小模块的崩溃，导致整个业务系统拒绝服务。
这个时候运维人员更像是保姆、消防员和拆弹专家。运维人员需要细心地呵护服务，让其健康地成长，就像照顾婴儿一样；成长中的服务，经常由于各种不规范带来的历史原因，出现很多意想不到的突发事情，这时候运维人员需要第一时间响应，进行业务的紧急恢复，类似消防员的角色；在日常的服务管理过程中，一个操作顺序或命令的错误，有可能直接让服务中断，这时候运维人员就像拆弹专家，既要细心大胆，又要有耐心，在危机时刻能够快速处理，做出正确决策。


运维人员需要处理各种突发的服务故障，在早期缺少统一规范、缺少业务监控、基础设施不成熟以及业务不断快速变化的时候，运维人员几乎每天都在忙于应付各种大大小小的服务故障。如图2-1所示是一个真实案例中，某个月统计到的服务故障分类和占比。


图2-1  服务故障分类和占比
根据监控项的重要程度对告警进行分级是一个很好的实践，Disaster级别优先级最高，需要立即处理。Warning级别需要24小时内完成处理，如图2-2所示。Warning级别大多数是CPU、内存、硬盘资源超限预警。详细的报警级别定义和划分，请参见后面监控章节的报警分级部分。


图2-2  各报警级别占比
注：根据监控项的重要程度对告警进行分级是一个很好的实践，P0级别优先级最高，需要立即处理。P3级别需要24小时内完成处理，P3级别大多数是CPU、内存、硬盘类资源超限预警。详细的报警级别定义和划分，请参见后面监控章节的报警分级部分。

业务快速变化、缺少统一规范、缺少文档和培训，运维人员基本上是摸黑接手服务。线上服务经常会埋着各种奇奇怪怪的坑，每一次服务变更都如履薄冰。

案例1 服务上下游处理超时时间不匹配，上游服务的超时时间设置为5毫秒，而下游服务的超时时间却设置成了10毫秒，下游服务还在正常处理请求中，可上游服务却因达到超时设置而将本次请求丢弃了，最终客户端不断重试，导致服务器端压力增大。

一个真实案例中，遇到过上下游服务超时时间单位不一致的情况，因为系统中的各个服务是不同的研发人员负责的，在联调过程中忽略了一些问题，导致上游服务使用秒作为超时时间单位，下游服务却使用了毫秒。某次下游单机故障时，运维人员发现上游容错机制完全无效，依然导致其堆积了大量请求，最终影响服务整体性能。经过了较长时间的追查，才发现是由于超时时间单位问题引起的。
由于缺少规范化，给运维带来了无形的风险，而且故障定位也比较困难。

案例2 集群服务是多台服务器共同完成一个任务，它们之间的调用关系是通过在程序配置文件中配置IP地址或服务器主机名来宣告的。由于IP地址的易读性较差，我们一般会使用内网DNS提供的主机域名。但有些研发人员却通过修改本机/etc/hosts文件的形式自定义域名解析。

这样的修改，使得对目标域名的解析是维护在每台服务器上的，这将极大增加运维管理的风险。试想100台相互存在调用关系的服务器，每台服务器上都需要维护与其他多台服务器的域名关系。当出现服务变更、故障处理、服务迁移时，需要所有上下游服务配合变更，带来很高的操作风险和复杂度。


运维属于技术线的末端（见图2-3），产品研发、测试、上线后将持续不断地在线上运行着。互联网产品很少有产品下线的情况，经常会出现某个产品的产品经理、研发工程师、测试工程师都没有了，而这个产品依然还有运维人员在维护，持续提供服务。上游引入的任何缺陷，最终都由运维去承担，上游往往无法感受到运维的压力。随着业务的增长、服务与主机数量的增加，产品各个阶段的缺陷会被进一步放大，运维压力也越来越大。


图2-3  运维属于技术线的末端
手工操作是初期运维团队的主要方式，渐渐的会形成一些工具或者系统，但都比较零散，适用场景较小，无法产生规模化。运维批量化和自动化所需要的信息非常少，这些信息基本上都靠人工录入，有哪些IDC，放置了什么服务器，服务器部署了什么服务，这些信息都没有自动采集和联动，无法给自动化系统提供必需的基础信息。运维的重复性工作非常多，又较多属于手工操作，不仅效率低，而且手工操作带来的失误率也比较多，几乎无法消除。

运维承受来自于外部不断增长的业务压力，以及快速发展中引入的各种缺陷。同时又面对内部生产力低下，导致工作效率低下和误操作较多的现状。运维是一个比较尴尬的工作，属于技术线的末端，人力、技术和资源的投入也属于末端。运维不出故障是正常，任何由于资源不足、基础设施不稳定、人员误操作导致的问题，都会被业务部门投诉。不过近年来，运维工作的价值越来越被大家认可，运维支持能力成为公司的核心技术竞争力之一。
运维工作需要从两个方向去解决上述提到的问题：提高内部运维效率和降低外部运维压力。
经过统计，运维工作中占比最多的是服务变更、监控管理、容量管理和故障处理。我们需要开发运维工具和平台，在运维数据准确的前提下让所有的工作尽量自动化起来。制定相关的标准和流程，运维人员在项目设计阶段就参与进来，进行设计评审，让研发人员交付的项目符合运维准入的要求。同时，让研发人员使用运维相关的工具，使研发、测试、上线阶段的部署行为一致，监控策略一致，且被测试验证过。
运维标准不是凭空制定出来的，需要满足运维自动化相关工具的最低要求。符合运维标准的产品，能够更加方便地进行一键部署，与监控联动等，这样才使研发人员有动力往运维标准靠拢，更积极地使用运维工具，我们的标准和工具才能进一步得到。