如何打造运维团队不可替代的“L”型价值体系-上篇

运维的价值究竟何在?

运维在当代企业的IT管理中处于非常重要的位置，下至机房环境、服务器和网络等硬件，上至业务应用，都需要运维参与管理维护。运维人员通过正确的流程、工具和团队组织，确保对应的IT资源始终处于可用状态，或者短暂宕机后能够快速修复故障，又或者新的IT资源和应用能够快速安全上线，满足企业的业务和发展的需求。

从上面的描述中，我们可以归纳出运维人员（无论是基础架构运维、中台运维或者上层应用运维），他们的工作职责都可以被涵盖到这三个大的范围中：

• IT对象资源变更管理；
• IT对象资源故障处理；
• IT对象资源的发布上线。

其中，IT对象资源既可以是服务器、网络设备、存储设备、软件系统等底层对象资源，也可以是上层的Web应用、ERP应用、OA系统、销售系统等应用对象。

传统的运维向自动化运维转换的过程，本质是用更加先进的团队组织方式、运维流程、平台工具替换旧的落后的组织、流程和平台工具的过程。

这一个过程中，绝大部分的企业都经历了这样的阶段：全部手工操作→部分脚本自动化→部分Web自动化→部分调度自动化。

并且，大部分企业都在“部分调度自动化”这个阶段放慢了或者停下了脚步，再难以上升到更高级的运维层次。

企业运维状态和运维价值分析

把视角聚焦到“部分调度自动化”这个阶段，我们不妨来分析下，企业整体的运维状态和运维人员呈现给企业的运维价值是怎样的。

一、运维状态层面

CMDB现状

有统一的配置管理（CMDB）中心，统一存储各种IT对象的配置信息，但是：

• 对象覆盖不足：许多对象配置数据无法实时自动发现、自动采集
• 缺乏灵活性：配置对象、对象属性和关联关系无法自定义扩展
• 无法与流程联动：导致配置信息不全、实时信息不完整
• 数据质量差：缺乏机制确保数据的准确性与一致性
• 无法被消费：配置数据仅仅存储静态资产信息，没有把配置消费起来

配置孤岛：以上种种最终导致配置管理成为数据孤岛，一个死的数据配置中心。

一般2-3年之后，企业会再次重启CMDB梳理和重建的过程，费时费力，循环往复，价值极低。

二、脚本运维现状

绝大部分批量运维工作实现了部分对象或者部分操作的脚本化运维，但是：

• 脚本散落各处，无法统一管理、更新、使用和继承；
• 脚本的定时或者手动执行在每台服务器本地执行，需要频繁往返于各个服务器执行脚本操作、检查脚本执行结果、以及配置定时任务；
• 没有统一的可视化界面监控全部的脚本任务明细、执行历史、结果反馈和操作审计；
• 百台乃至千台的并发脚本执行能力和文件分发能力弱，出错概率大；
• 无法支撑复杂的大批量自动化脚本执行和文件分发的混合编排：大批量的操作单元、多步骤的执行过程、复杂的脚本执行和文件分发混合编排。

三、可视化工具运维现状

能够实现一部分对象或者一部分流程的web可视化工具管理，但是：

• 无论是自研或者外购的方式，每个可视化工具依然是竖井式的存在，管理功能是硬编码方式固化在应用内部；
• 面对同一批对象的新增的管理需求，需要自下而上从工具的数据采集和分发层、逻辑分析层、展示层等全部的代码更改，费用成本和时间成本高昂、周期长、基本完全依赖外部服务商；
• 工具难以直接消费配置管理中的数据，需要在每个工具中再次重复导入IT对象资源；
• 工具直接对接和管控底层IT对象资源，不具备中间原子功能层，工具功能层面变更能力和扩展能力弱；
• 工具与工具之间缺乏统一的架构和组织，没有统一的平台支撑，相互之间缺乏联动和交互。

四、任务编排运维现状

能够实现一部分对象或者一定程度的跨系统的任务调度自动化编排，但是：

• 调度自动化编排局限于某些IT对象资源或者某些流程片段，比如：只能在数据库层面实现各种任务调度自动化，想要把操作系统部署配置、存储资源自动调配、网络自动配置等加入调度任务中，就无法实现；
• 在每个对象上能够执行的调度任务是固化的，硬编码方式写入竖井式的应用本身的；对于单个调度任务的变更或者新增，又是一系列的自底而上的代码修改；这类需求，外部服务商要么直接拒绝，要么裹挟于昂贵的价格和冗长的交付周期，中间伴随着的是繁复的沟通、拉扯和讨价还价，最终影响运维的正常的高效率的展开；
• 自动化编排的流程模式是既定的，只有串行或者并行模式选择；当需要在编排流程流程中进行更复杂的编排和调度：比如针对上一步进行执行结果的判断，并根据结果的不同，执行不同的更加的后续分支编排任务的时候，竖井式的自动化编排工具束手无策；
• 自动化编排本身的IT对象资源需要再次导入和配置，无法直接提取现有CMDB中的数据进行消费。

综上所述

就运维整体的状态而言，绝大部分企业事实上还在向“自动化运维”这个目标艰难前进中；

现阶段的状态是：部分人肉运维+部分脚本运维+部分web界面运维+部分自动化编排运维的混沌状态；

但是由于整体缺乏统一性规划和平台型支撑，导致了事实上的整体运维结果依然是“人肉为主，各项工具为辅”；

依然是人肉监控和处理故障、人肉处理变更、人肉发布IT资源；运维人员手忙脚乱、身心俱疲的切换各种不同的运维工具，针对不同的IT对象，执行相互之间无法关联的运维任务；

整体运维阶段依然是手工为主的、零散的、低效率的、错误率高的、笨重的、缺乏扩展性和一致性的。

运维价值层面

那么在花钱聘请了一批并不便宜的运维管理人员和技术专家、购置了一批又一批昂贵的IT设备、部署了一套又一套复杂的基础架构和上层应用系统的企业家或者通俗点说公司老板的眼里，上述的运维团队呈现给企业的价值究竟是怎样的呢？

答案是：依然停留在运维保障和业务保障层面，没有更多的了！

并且这种保障，在仔细观察之后，还是停留在一个比较低层次的，无论在运维的效率、质量和成本层面，都存在很大问题的阶段：

• 不可靠的
• 不稳定的
• 缓慢的和效率低的
• 用户体验不佳的
• 费钱的和持续费钱的

要真正做好运维保障和运营保障，究竟该如何做是好？

除了基本的保障，运维团队和人员有没有更高的价值呈现？

如果有，是什么？

真正有远见的运维团队领导者，都应该去仔细思考以上问题，并给出一个自己能满意的答案。

对于不愿意思考上面的问题或者找不到能够说服自己的答案的人，“运维危机”是真实存在的。

面对这个危机，我们将在下一篇文章中解答：如何从运维效率和运维价值两个层面，打造运维的“L”型价值体系！