上一篇整理了运维组织的“2.1 组织专业化”，在细化横向的专业化分工之前，本章先看看“运维底线保障能力”（由于本人主要工作经验在应用运维与自动化，相关内容以应用运维为主），主要的部份内容是基于公众号另一篇《回归一线应用运维的底线——先做好最基本的事》之上做扩展。下一篇计划是“2.3 可用性保障能力”
2.2.1基本能力模型
关于运维基本能力的范围界定很难，但实际上这又很重要。很难，是因为不同的企业对运维组织的定位、期望、规模不一样，很难有一个标准的能力模型；很重要，是因为如果一个运维组织对运维的基本能力没有一个基准，那很多事情只能靠主观来判断具体某个团队或个人做得好还是不好，它的可持续改进的效果将大打折扣。为了说明运维基本的能力模型，我尝试借ITSS.1的运维能力模型来做个简要的说明，不同的运维组织可以借鉴ITSS.1运维成熟度的几个分级进行一个定位，并参考这个成熟度持续改进的思路，结合企业自身的特点进行细化组织内不同团队及个人的能力要求。
ITSS.1是中国电子工业标准化技术协会信息技术服务分会组织研制《信息技术服务运行维护服务能力成熟度模型》(ITSS.1—2015 )，ITSS.1是中国境内针对运行维护而制定，包括谁来做，做什么，怎么做的一整套最佳实践，是一套运行维护的能力体系。
- 基本级：体系有没有，即实施了必要的运维能力管理，日常运维工作有序运行；
- 扩展级：体系全不全，即实施了较为系统化的运维能力管理，形成了较为完善的人员、流程、技术和资源方面的管理制度，并得到落实；
- 改进级：协同好不好，即以整合能力为主，组织的运维服务能力发展战略清晰，形成了完善的运维服务体系，综合运用ITSS能力标准，建立协同运行的能力；
- 提升级：量化管理精不精，即实现运维变革，可量化的运维能力管理，并实现推动业务发展的变革；
上述4个能力成熟度的级别是一个持续改进的过程，采用戴明的PDCA的持续改进理念，可以分为计划、执行、检查、改进四个闭环的步骤，即：
- 计划：根据自身业务定位和能力，对人员、资源、技术和过程进行规划，建立相适应的指标体系和服务保障体系 ，确保有能力提供运行维护服务，并进行持续优化的质量保证措施；
- 执行：按照运行维护服务能力的整体策划进行实施，确保服务能力管理和服务过程实施可追溯，服务结果可计量或可评估，提交满足质量要求的交付物；
- 检查：检查运行维护服务能力管理活动符合计划要求 和质量目标，定期评审服务过程及相关管理体系，以确保服务能力的适宜性和有效性 ；
- 改进：改进运行维护服务能力管理过程中的不足， 持续提升运行维护服务能力；
ITSS.1中从组织、流程、资源、技术等方面对运维能力进行指导定位，本节主要针对运维能力模型中找出属于运维最基本的底线运维能力，底线运维能力是一个特定的运维组织必须保障或完成的运维工作所具备的能力，是运维的及格线。所以本节并不重点提自动化、数据运营、智能运维思路，也不谈合规操作这些基本的行为准则，只站在一线应用运维角度先归纳几项应用运维最基本的运维工作（具体第一点后续有章节进行扩展），需要确保落实到位的工作职责(不同条线的运维人员会有不同的理解）：
2.2.2底线运维能力
1）高可用
（1）数据备份可用性
“数据不丢”是运维的第一道生命线，对于数据不丢的目标，仅仅是做好架构的高可用是不够，因为只要发生数据传输、数据存储、数据交换，当系统软硬件任一个环节出现问题都可能造成数据丢失，所以需要对关键数据进行备份。数据备份涉及的工作很多，这里从从备份配置与备份手段两方面来看。
- 备份配置：运维组织要有一份配置信息，包括需要备份数据、数据的重要性级别、备份的数据位置、备份策略、应急方案等。备份的数据配置项至少包括包括应用程序、数据库、数据库日志、业务数据、配置数据等关键数据；备份的数据位置则包括源数据与目标数据，目标数据针对不同等级的数据制定不同的存储方式；备份的策略和备份数据位置一样，针对不同等级的数据制定实时复制、日备、月备等方式；
- 备份手段：备份手段有很多，不同组织可以利用现有的资源或引入新的资源工具进行备份保障，除了备份工具以外，还需要数据备份管理员制定确保数据可靠性的保障措施，包括前期的保障策略的标准化、备份介质与工具的定性、备份的准入，备份覆盖率，以及备份介质的可用性检查等。
（2）备份环境可用性
备份环境是为了解决生产运行环境出现环境异常的紧急事件的一棵救命稻草，主要是针对备份机、灾备环境、同城应急环境，基于分布式与负载均衡的部署架构的运行环境一直都在对外提供服务，在环境可用性方面相对较好（需要正视的是当前也有不少认为是分布式或负载均衡的架构里，也存在局部模块非负载、多个服务部署一台机器或OS带来的“假负载”的情况，这些“假负载”的模块往往容易忽略）。针对备份环境可能会出现环境不一致的情况，可以从以下几个维度进行保障：
- 意识：需要确保运维人员是否意识到备机是用来救命用的环境，是运维保障的底线。
- 技术：生产环境是在不断变化的，有些变化是计划中的，有些是非计划或未通知的，给备份、灾备系统和生产系统的一致性带来隐患。主备环境为何会出现不一致的情况，主要原因是两个环境之间采用人肉方式同步，这种完全靠责任心维系的方式很容易出问题，比如某一天应用运维人员实施应用变更部署到生产环境到凌晨，疲惫的他很容易忘了同步灾备的环境。所以备份机、灾备、同城应急环境需要采用技术方式同步，自动化实现监测，人工的同步只能作为一个临时应急的过渡方案。
- 管控：采用自动化同步、自动化监测一致性还不够，因为备份应急环境的启用是流程、机制、技术等一系列组成的工作，所以，对备份环境的验证也不是一次性的工作，需要进行实战演练，以确保环境在需要启用时能够马上就位。
（3）架构的高可用
有应急、演练、故障跟进等基本工作，就会发现运行风险（这里不提合规操作风险，合规操作风险属基本操作准则），运行风险则往往会有架构上的优化。一个好的应用运维人员至少需要是一个合格的架构师，运维人员并不要求要对每一个组件的实现方式很了解，但是需要对何时用、如何用这个技术组件要有准确的判断。所以，应用架构的优化，什么时候优化、如何优化、如何推动也是应用运维人员的基本工作。
在架构优化的过程中，有些思路是可以借鉴的，比如：
- 架构上由冷备向热备、负载均衡、分布式架构改进；
- 纵向扩展的性能优化，比如加服务器资源，换性能更强的服务器提升服务能力；
- 横向扩展的性能优化，比如增加节点、拆分数据库、数据库读写分离、增加负载均衡的服务节点、按地区分拆应用、业务流程简化环节、同步改异步、限制峰值等方式提升服务能力；
通常来说，基于纵向的扩展优化相对简单，但对于业务快速扩展的业务系统则可能横向扩展的性能优化效果更好，具体选择哪一种需要视实际情况选择，可能有时候几个简单的SQL效率的优化即可快速解决性能的问题。
2）应急
（1）应急手册的精&准
运维手册是运维标准化最基本的工作项之一，它不仅是应急过程中操作步骤，还包括协作、沟通等约定，最终的目标是更快的解决问题。在实际的实施过程中，应急手册的建设很容易变成应付形式的工作，主要原因是应急手册的准确性与快速定位的问题，因为运维涉及的问题很多，运维的应急手册容易演变成一个越来越复杂的文档，当文档复杂到一定程度时就会变成一个负担，很难保文档的及时更新。针对应急手册的准确性与快速定位，建议如下：
- 缩小应急手册范围：优先保证应急三把斧的手册：重启、切换、回切的应急手册；
- 优化应急手册形式：可以将文档转化为卡片，更好的可以建立运维经验库工具支持应急手册的更高效的精准定位，经验库可以提供应急手册的使用频率、应急手册使用反馈情况、更新数据等数据；
- 整合在应急场景：可以将应急手册整合在故障应急处理场景，提高应急手册的利用率，手册利用率的提高可以提高手册准确性。
- 简化应急手册步骤： 通过自动化手段进行简化，比如原来采用命令行方式进行重启服务，在采用工具集中重启服务后，手册也可相应简化。
- 应急手册的持续优化：通过对运维经验库的应急手册的使用率、使用反馈情况、更新情况分析应急手册的使用情况，持续提高应急手册的准确性。
（2）监控的“不漏报、少误报、快处理”
很难想象，哪一天我们的监控体系（由不同层次的监控工具组成）全部停业半天，哪怕是一小时、十分钟，我们的运维团队该如何去做运维保障。监控己经深入到我们运维的方方面面，相信在过几年监控全面实现自愈、无人值守后，监控将变为无形角色贯穿在整个一体化运维体系。
评价一个运维组织的监控能力，最主要的不是各个层次的监控工具是否完善，而是应该从监控覆盖程度、准确性、监控事件处理及时性等维度的落地情况，即“不漏报、少误报、快处理”。针对监控管理的底线保障上，组织需要有手段、有数据可以直观的看到监控管理落地状况，基于此，建议每个运维组织需要尽量建立基于监控事件整合的事件集中管理工具，事件管理工具有助于我们提高监控管理的落地效果。另外，虽然我们针对生产系统的各层次都部署了大量监控工具，通常会存在一些监控点不是标准化默认即插即用的指标，需要有管理员去配置。靠管理员主观能动性去让监控实现对某个生产系统所有运行状态进行实时监控还比较困难，所以需要让运维人员明确知道监控覆盖面的及格线，可用性监控覆盖面为及格线，以应用系统管理员为例，他需要保证一个对客交易应用系统的所有服务可用性、端口监听、开业状态可用、重要批量按时完成、应用基本交易可用、重要业务交易可用、某个服务节点整体性能大幅度下降、上下游文件传输成功状态指标必须覆盖监控（资源类、网络等属于默认标准的监控覆盖）。
上面是针对一线运维人员的监控要求，从监控平台建设者的角度，监控平台要尽可能让需要覆盖的监控指标从技术上落地，减少对运维人员主动性上的依靠，要快速从技术上响应新的监控指标的落地。这里最低要求是针对在面有实现完全自动化配置的情况下的要求。
（3）应急演练
应急演练是检验、评估、提高运维组织可用性管理的一个重要手段，通过模拟故障的发生，发现软硬件运行环境、系统架构、系统性能、应急预案、协作沟通、人员技能等存在的不足，并持续改进应急体系，以下梳理了演练的目标。
在实际的演练工作开展过程中，一是要梳理现有系统的问题、风险点；二是针对问题、风险点的应急措施；三是组织演练；四是通过演练将风险的解决方案进行沉淀与更新。演练的场景包括重启的应急、回切的应急、重要业务运营活动前的压测等；演练的方式包括实战、桌面；演练的目标包括操作、流程、方案等。
3）常规
（1）开业巡检/开关机
在生产运维过程中“事前管理”始终是优先于“事后管理”，对于日常的巡检工作不但是故障防患于未然的关键，也是进一步释放IT运维管理价值和不断创新的基础，最为关键的是巡检是应用运维工作最基本的职责，在这个位置被放倒是没有任何解释的理由。对于巡检，可能会遇到过这些问题，比如：
- 依赖应用管理员的责任心、工作执行力，存在巡检点的覆盖率不够；
- 巡检的标准化不够，标准化落地到自动化也不够；
- 巡检的内容主要体现在系统可用性上，缺乏对巡检的趋势分析；
- 开业巡检的策略没有基限值，不利于同类系统的推广；
- 巡检完善工作没有将KPI指定到人，巡检的完善不够持续性；
针对上述巡检的问题，可以考虑以下方式：
- 强调应用管理员责任心、自觉性的无管理、无监督方式
- 制定巡检标准、要求，通过每天手工登记、定期抽查的方式
- 将常见的巡检方法标准化，并落地到监控系统、巡检系统，加上手工等多种方式组合
- 明确分工确保巡检覆盖率与执行力，统一巡检系统，巡检内容做到点、面结合，所谓“点”是系统可用状态，“面”是趋势方式的预防性分析检查
在巡检的工作过程中，如果缺少自动巡检的运维工具，无论是应用管理员，或是作为服务台、ECC值班经理、职能型团队经理、流程经理等的耐心很容易被消磨殆尽，接下来就是敷衍了事，或者无法完所有范围内的巡检，出现“假巡检”的情况，所以巡检的有效落实首先需要有工具作为支撑。另外，巡检工具的核心还是巡检策略的正确性与覆盖率，这方面需要精细化分工，要有值班人员完成巡检工作，要有二线人员完善巡检，还要有流程要促使巡检策略的完善。精细化分工需要精准的KPI到专人身上。也就是说巡检的主要方式应该是自动化为主，人工为辅的方式，以下是一些巡检建议：
- 确保巡检覆盖率，比如制定巡检最小值基限、基限标准化落地到自动化工具、专项的人来落实巡检覆盖率、巡检的完善需要在日常运维流程中体现。
- 点面结合的巡检策略，“点”即是有针对性对重要的运行指标进行巡检评价，“面”即通过运行数据分析预防性的主动式分析检查。
- 对巡检工作精细化分工：值班或服务台保证巡检工作的检查；技术运营保证巡检策略的完整、正确，与巡检自动化的实现；自动化团队：提供更利于巡检落地的工具
（2）变更交付
生产变更是运维的重点工作，如何提高应用或资源交付效率当然是运维努力的方向，但这些需要建立在保证变更成功率的基础之上。排除自动化工具对变更的支持力度，从变更实施工作具体的操作与流程看，还需要注重具体的工作方式与能力。比如，变更前的评审（CAB），变更影响面的分析，变更方案的制定，变更关联方的协调，变更前的性能及功能演练，变更的准入条件的落足，变更过程中的实施，变更后的技术及业务检查，变更后业务实际开展的持续跟进都需要从流程与基本技能的覆盖。我觉得devops理念的应用，并不代表上述变更交付的重点工作的忽略，而是通过自动化与协作手段简化这些工作的落地成本。
（3）业务咨询的响应
业务咨询的响应占用了应用运维主要的工作量，对于一线应用管理员直接的要求是及时反馈，保证服务满意度；深入一点要求是应用运维人员的主要负责人需要走进业务、了解业务对生产应用的具体期望，并作到反馈。基于业务导向的思路，业务咨询的建设可以作用应用运维从运维走向运营的窗口。业务咨询的工作包括各类业务工单，比如修改数据、参数、数据提取等。如果没有统一的服务台，这些业务咨询可能会从各个渠道向业务运维人员涌来，比如服务台、电话、微信、邮件等。
现实工作过程中，由于业务运维人员人均负责的系统越来越多、数据量越来越多、系统的技术栈越来越复杂，业务运维人员对于业务咨询的问题响应能力越来越差。因此，一线应用运维人员一方面需要考虑如何简化当前运维的工作量，减少重复性的工作；另一方面需要寻求工具提高实时掌控系统运行、快速解决问题的能力。比如通过数字化的建设提高可视化程度，通过经验库提高问题解决效率，通过日志工具提高日志分析效率，通过运维数据分析，反推开发团队优化系统可用性。
（4）针对性的运行评估：
运行评估这项工作特别值得运维人员去做，它的开展能转变运维人员工作思维，由被动操作向分析转变，由局部到整体把控，由被动应急向主动出击转变。运行分析可以做性能、容量、客户体验等方面的分析，以底线运维的角度来看，我觉得一线运维人员需要重点关注容量评估。有些人可能认为生产系统的容量问题是开发程序不够好导致，运维人员比较难发现，我的认识是突发性的变更BUG导致的性能容量问题的确如此，但是对于非突发性的性能容量问题第一负责人应该是运维人员，因为运维人员手上掌握着生产系统运行的所有数据却未发现容量不足，那是运维容量评估没做到位。我们需要让运维人员对生产系统的主要运行指标进行数据分析，通过趋势分析、基线比对，发现系统的健康状况，如果容量的运行评估做得更好可以考虑运行评估自动化，变成常规的开业巡检，或实现自愈。
