节回来梳理工作，有向好的地方，也有面临困难的地方。好的地方，是一体化运维的建设工作己步入正轨，团队里同学都很棒，都能以做产品的心态去拼。困难的地方，是应用一线生产保障的团队还是面临”被动、计划性不够”的现状，尤其是看到GitLab误删数据，5份备份全部无效的故障事件，更有种不踏实，自己也不敢肯定团队里的备份策略是否完整，永久备份内容是否可用，再进一步想想应用可用性的监控是否100%覆盖，基本的应急手册是否都完整可用、备机与灾备环境是否随时可用状态、操作是否100%合规也都可能成为一颗定时炸弹。

为何会对这些看起来是基本共识的工作还有疑虑呢?总结起来，主要是还是因为对运维人员的工作引导不够，主因是意识上的问题。从专业条线角度看，运维保障可以分为系统、网络、应用运维，其中系统、网络两方面的运维对象往往来自大厂商、比较稳定、行业标准化程度高等特点，而应用运维的标准化则更困难，整体的工作更加被动，缺乏计划性，所以不少一线应用运维眼中的主要工作内容可能如下：

• 故障应急——业务恢复了就算结束
• 各种业务咨询——反馈业务了就算结束
• 各种业务工单——工单关闭了就算结束
• 监控——尽可能多配监控指标，反正就是覆盖面越全越好
• 变更——按时把版本投上生产、技术与业务检查通过就算结束
• ……当然，还有安全管理、配合监管、配合业务分析等工作

注：这里的一线应用运维主要指一线生产系统保障的团队，不包括计划性项目的团队。

对于上面的主要工作内容与结束标志看起来也属正常，但是进一步分析会发现这种工作导向会引发风险。比如：

• 故障应急——业务恢复了就算结束——没有引导运维人员如何做好故障快速恢复的事前准备工作，造成被动，比如应急手册不完善导致的延误故障处理时间。
• 监控——尽可能多配监控指标，反正就是覆盖面越全越好——一个应用涉及的监控面很广，不可能把将所有点都监控上，上述对监控的认识没有引导运维人员重点确保应用可用性监控覆盖情况，有可能配置了上百条监控指标，但是最为关键的开业、服务可用性的监控遗漏带来的重大生产问题。

那么问题来了，什么才是一线应用运维最基本的工作，或称为一线应用运维的及格线呢?这里，不提两地三中心、自动化、数据运营、智能运维这些思路，也不谈合规操作这些基本的行为准则，只站在一线应用运维角度先归纳几项运维最基本的运维工作，需要确保落实到位的工作职责(不同条线的运维人员会有不同的理解)：

1、备份：

“数据不丢”是运维的第一道生命线，对于数据不丢的目标，仅仅是做好架构的高可用是不够，还要对关键数据进行备份。备份机制从备份对象与备份手段两方面来看。首先是备份对象，运维人员需要确保备份策略里包括完整的应用程序、数据库、数据库日志、业务数据、配置数据等关键数据;其次才是对备份手段的保证，数据备份管理员一方面需要为备份介质、备份工具对备份策略执行的可靠性，另一方面需要牵头核实永久备份介质的可用性。

2、主备、灾备、同城环境：

负载均衡的部署架构的运行环境的正确性往往是有保证的，因为这些环境一直都在对外提供服务。但是对于备份机、灾备环境、同城应急环境，可能会出现环境不一致的情况，解决这种不一致的问题，需从以下几个维度：

– 意识：需要确保运维人员是否意识到备机是用来救命用的环境，是运维保障的底线。

– 技术：生产环境是在不断变化的，有些变化是计划中的，有些是非计划或未通知的，给备份、灾备系统和生产系统的一致性带来隐患。主备环境为何会出现不一致的情况，主要原因是两个环境之间采用人肉方式同步，这种完全靠责任心维系的方式很容易出问题，比如某一天应用运维人员实施应用变更部署到生产环境到凌晨，疲惫的他很容易忘了同步灾备的环境。所以备份机、灾备、同城应急环境需要采用技术方式同步，自动化实现监测，人工的同步只能作为一个临时应急的过渡方案。

– 管控：采用自动化同步、自动化监测一致性还不够，因为备份应急环境的启用是流程、机制、技术等一系列组成的工作，所以，对备份环境的验证也不是一次性的工作，需要进行实战演练，以确保环境在需要启用时能够马上就位。

3、应急手册：

运维手册是运维标准化最基本的工作项之一，但由于运维涉及的问题很多，运维文档也演变成一个越来越复杂的文档，当文档复杂到一定程度时就会变成一个负担，很难保文档的及时更新。所以我让团队先保证应急三把斧的手册：重启、切换、回切涉及的应用手册的完整(涉及的动作、协作方式等需完整)、可用(涉及的内容需保持最新)、好用(能简则简)，且这个应急手册建议独立分开。

另外，应急手册可以通过自动化手段进行简化，比如原来采用命令行方式进行重启服务，在采用工具集中重启服务后，手册也可相应简化。

4、监控：

很难想象，哪一天我们的监控体系(由不同层次的监控工具组成)全部停业半天，哪怕是一小时，我们的运维团队该如何去做运维保障。监控己经深入到我们运维的方方面面，相信在过几年监控全面实现自愈、无人值守后，监控将变为无形角色贯穿在整个一体化运维体系。

但在当前，监控主要实现“监”的背景下，则需要运维人员把握“监”的覆盖程度。虽然我们针对生产系统的各层次都部署了监控工具，但还是有监控点不是标准化默认即插即用的指标，需要有管理员去配置。靠管理员主观能动性去让监控实现对某个生产系统所有运行状态进行实时监控还比较困难，所以我们需要让运维人员明确知道监控覆盖面的及格线，我归纳为可用性监控覆盖面为及格线，以应用系统管理员为例，他需要保证一个对客交易应用系统的所有服务可用性、端口监听、开业状态可用、重要批量按时完成、应用基本交易可用、重要业务交易可用、某个服务节点整体性能大幅度下降、上下游文件传输成功状态指标必须覆盖监控(资源类、网络等属于默认标准的监控覆盖)。

注：从监控平台建设角度，监控平台要尽可能让需要覆盖的监控指标从技术上落地，减少对运维人员主动性上的依靠，要快速从技术上响应新的监控指标的落地。这里最低要求是针对在面有实现完全自动化配置的情况下的要求。

5、容量：

有些人可能认为生产系统的容量问题是开发程序不够好导致的，我的认识是突发性的变更BUG导致的性能容量问题运维人员的确很难提前发现，但是对于非突发性的性能容量问题第一负责人应该是运维人员，因运维人员手上掌握着生产系统运行的所有数据却未发现容量不足，那是运维容量评估没做到位。所以，我们需要让运维人员对生产系统的主要运行指标进行数据分析，通过趋势分析、基线比对，发现系统的健康状况。

注：由于一线管理关注运行状态，所以这里的容量评估不涉及资源的成本控制;

7、演练：

运维过程中，针对可能出现的问题和风险点，会制定对应的应对措施、启用流程、操作方案，针对这些措施是否可用，需要预先进行演练。在实际的演练工作开展过程中，一是要梳理现有系统的问题、风险点;二是针对问题、风险点的应急措施;三是组织演练;四是通过演练将风险的解决方案进行沉淀与更新。演练的场景包括重启的应急、回切的应急、重要业务运营活动前的压测等;演练的方式包括实战、桌面;演练的目标包括操作、流程、方案等。

8、风险跟进及架构优化：

有应急、演练、故障跟进等基本工作，就会发现运行风险(这里不提合规操作风险，合规操作风险属基本操作准则)，运行风险则往往会有架构上的优化。我一直觉得一个好的应用运维人员至少需要是一个合格的架构师，运维人员并不要求要对每一个组件的实现方式很了解，但是需要对何时用、如何用这个技术组件要有准确的判断。所以，应用架构的优化，什么时候优化、如何优化、如何推动也是应用运维人员的基本工作。

9、业务工单、业务咨询：

业务工单(差错、参数、数据提取等)、业务咨询(服务台、电话、微信、邮件等渠道过来的问题咨询)属于应用运维过程中被动的工作，这方面的工作对于一线应用管理员直接的要求是及时反馈，保证服务满意度;深入一点要求是应用运维人员的主要负责人需要走进业务、了解业务对生产应用的具体期望，并作到反馈。

上面是针对应用一线运维人员的基本工作及格线要求的一些归纳，后续还会在实践过程中持续的优化，调整。近期，在团队中持续推动及格线思路的同时，对于每一项工作安排了专人横向管理，制定方案，持续推广落实，一方面是通过集众人力量将工作及格线落实到位;另一方面也可以让运维人员逐步减少重复被动的操作工作比例，做更多的事前工作。