回来整理工作。有好的地方，也有困难的地方。好在集成运维的建设走上了正轨，团队里的同学个个都很棒，都抱着做产品的心态在努力。困难的是，应用一线生产保障的团队仍面临着“被动、计划不足”的现状。尤其是看到GitLab误删数据和5个备份全部失效的失败事件，更是不靠谱。确定团队中的备份策略是否完备，永久备份内容是否可用，再想想应用可用性的监控是否100%覆盖，应急基础手册是否齐全可用，备份和备份是否可用。灾难恢复环境随时可用。是否100%合规可能成为一颗定时炸弹。为什么你对这些看似基本共识的作品还有疑虑？归纳起来，主要是对运维人员的工作指导不够，还有就是意识的问题。从专业线来看，运维保障可以分为系统、网络、应用运维。其中，系统和网络的运维对象往往来自大厂商，相对稳定，行业标准化程度高，而应用运维标准化难度较大，整体工作较为被动，缺乏规划.因此，很多一线应用运维眼中的主要工作内容可能是：故障应急——业务恢复时结束各类业务工单——工单关闭，监控结束-尽可能多的监控指标，反正覆盖的越全越好-版本按时上线，技术和业务检查完成……当然，还有安全管理，配合监管，配合业务分析。上述主要工作内容和结束标志看似正常，但进一步分析会发现，这种工作导向会带来风险。例如：故障应急响应——业务恢复就结束了——没有指导运维人员如何做好故障快速恢复的准备，造成被动，如应急手册不全导致故障处理时间延误.监控——尽可能多的监控指标，反正覆盖的越全面越好——一个应用涉及的监控范围很广，不可能监控到所有的点。以上对监控的理解并没有指导运维人员把重点放在保证应用可用性监控覆盖上，可能配置了上百个监控指标，但是最关键的开放和服务可用性监控的疏漏造成了重大的生产问题。那么问题来了，一线应用运维最基础的工作，或者说一线应用运维的及格线是什么？抛开合规运维的基本行为准则不谈，我只从一线应用运维的角度总结一些最基本的运维工作，以及需要保证落实到位的岗位职责（不同线路的运维人员会有不同的理解）：1、备份：“数据不丢失”是运维的第一生命线。对于数据不丢失的目标，仅仅做架构高可用是不够的，还要备份关键数据。备份机制从备份对象和备份手段两个方面来看。第一个是备份对象。运维人员需要确保备份策略包括完整的应用、数据库、数据库日志、业务数据、配置数据等关键数据。二是备份方式的保障。一方面，数据备份管理员需要为备份策略的执行提供可靠的备份介质和备份工具。另一方面，有必要带头验证永久备份介质的可用性。2、主动备份、容灾备份、同城环境：负载均衡部署架构的运行环境的正确性往往得到保证，因为这些环境一直对外提供服务。但是对于备机、容灾环境、同城应急环境，可能存在环境不一致的情况。解决这种不一致的问题，需要考虑以下几个维度：–意识：需要保证运维人员意识到备用机的使用拯救生命的环境是运维保障的底线.–技术：生产环境在不断变化。有些变化是计划内的，有些变化是计划外或未宣布的，这给备份、容灾系统和生产系统的一致性带来了隐患。主备环境不一致的主要原因是两个环境以人为方式同步。这种完全靠责任维护的方式，容易出问题。例如，某天应用运维人员实施应用变更并部署到生产环境是在凌晨，他很累，很容易忘记同步容灾环境。因此，备机、容灾、同城应急环境需要通过技术手段实现同步，自动实现监控。手动同步只能作为临时的应急过渡方案。–管控：仅仅采用自动同步和自动监控一致性是不够的，因为备份应急环境的激活是一系列过程、机制、技术等组成的工作，因此备份环境的验证不是一个过程一次性工作，需要实战走一遍，确保上线环境到位。3、应急手册：运维手册是运维标准化最基础的工作项目之一。但是，由于运维涉及的问题较多，运维文档也演变成了越来越复杂的文档。当文档复杂到一定程度时就会成为一种负担，而且文档很难及时更新。所以我要求团队首先确保应急三轴的手册：重启、切换、切回涉及的应用手册完整（涉及的动作、配合方式等必须完整）、可用（涉及的内容mustbekeepingup-to-date),易于使用（可以越简单越好），本应急手册建议独立分开。此外，可以通过自动化手段简化应急手册。例如，使用命令行方式重启服务。使用工具集重启服务后，手册也可以相应简化。4、监控：很难想象有一天我们的监控系统（由不同级别的监控工具组成）会关闭半天，甚至一个小时。我们的运维团队应该如何做运维保障。监控已经渗透到我们运维的方方面面。相信经过几年的监控完全实现自愈和无人值守监控，监控将成为贯穿整个一体化运维体系的无形角色。但在当前监控主要实现“监”的背景下，运维人员需要把握好“监”的覆盖范围。虽然我们对生产系统的各个层级都部署了监控工具，但仍有一些监控点不是标准化的默认即插即用指标，需要管理员进行配置。依靠管理员的主观能动性来实时监控生产系统的所有运行状态，仍然存在困难。所以我们需要让运维人员清楚的知道监控覆盖的及格线。我将其总结为可用性监控覆盖率的及格线。以应用系统管理员为例。他需要保证所有服务的可用性，端口监控，开通状态可用，重要批次按时完成，应用基础交易可用，重要业务交易可用，客户交易应用系统中一个服务节点的整体性能。必须监控幅度下降、上下行文件传输成功等状态指标（资源、网络等属于默认标准监控范围）。注：从监控平台建设的角度，监控平台应尽可能让需要覆盖的监控指标在技术上落地，减少对运维人员主动性的依赖，快速响应落地技术上新的监测指标。这里的最低要求是针对全自动配置的情况。5、容量：有人可能会认为生产系统的容量问题是开发程序不足造成的。我的理解是突然变化的BUG导致的性能容量问题运维人员确实很难提前发现，但是对于非突发性能和容量问题的第一负责人应该是运维人员.因为运维人员手中掌握着生产系统运行的所有数据，却没有发现容量不足，这说明运维容量评估没有做好。因此，我们需要让运维人员对生产系统的主要运行指标进行数据分析，通过趋势分析和基线对比，了解系统的健康状况。注：由于一线管理关注的是运营状态，这里的产能考核不涉及资源成本控制；7、演练：在运维过程中，针对可能出现的问题和风险点，制定相应的应对措施、激活流程和操作，这些措施的可用性需要提前演练。在实际演练工作过程中，首先梳理现有系统存在的问题和风险点；二是针对问题和风险点采取应急措施。三是组织演练。更新。演练场景包括应急重启、紧急切回、重要业务运营前压力测试等；演练方式包括实战和桌面；演练目标包括操作、流程、计划等。8、风险跟进和结构优化：如果有应急响应、演练、故障跟进等基础任务，就会发现操作风险（合规操作风险不是这里提到，合规运营风险是基本运营原则），而运营风险往往存在架构优化。我一直觉得一个好的应用运维人员至少需要是一个合格的架构师。运维人员不需要很好地理解每个组件的实现，但是他们需要很好地理解何时以及如何使用这个技术组件。准确的判断。所以，应用架构的优化，什么时候优化，怎么优化，怎么推广也是应用运维人员的基本工作。9、业务工单、业务咨询：业务工单（错误、参数、数据提取等）、业务咨询（服务台、电话、微信、邮件等渠道咨询）是应用运维中的被动任务过程。对这方面一线应用管理员的直接要求是及时反馈，保证服务满意度；更深入的需求是应用运维人员的主要负责人需要进入业务，了解业务对生产应用的具体期望，并实现反馈。以上是对应用一线运维人员基本工作要求的总结，并将在实践过程中不断优化调整。近期，我们在团队中继续推进及格线理念的同时，安排专人进行横向管理，制定方案，持续推进落实各项工作。让运维人员逐步减少重复被动运维工作的比例，多做前期工作。
