

运维转型 | 运维人不再只是“救火英雄”

嘉为蓝鲸

2020-01-14

导读：各行各业都开启了数字化转型的进程，运维团队在这种时代大势的浪潮中又该何去何从？

已经进入21世纪了，各行各业都开启了数字化转型的进程，运维团队在这种时代大势的浪潮中又该何去何从？我在帮助一些企业落地了运维技术平台之后，开始反思这个问题，并将其中的所思所想整理成本篇文章内容。

虽然各行各业都开启了数字化转型的进程，但很多运维人员仍然非常辛苦，在企业中背负着 “救火英雄”的称号。往好的说是“救火英雄”，换一种糟糕的说法是“背锅侠”，似乎永远深陷于好事不出门坏事传千里的泥潭中。

为什么会这样？我认为这是由生产力决定的，熟悉政治经济学的人应该知道著名理论生产力决定生产关系，那么什么是运维生产力？企业数字化转型时代下，运维人应该具备哪些生产力？

▲ 传统组织中的运维职责

相信大家过往应该看过很多的分享、资料，有的围绕着ITIL讲述如何高瞻远瞩地去设计顶层，有的通过繁杂的技术语言讲述五花八门的落地经验，却发现在结合自身现状时，这些经验有着诸多不适。

我在帮助几个企业落地了运维技术平台后，开始反思，很多人习惯将运维理解为一个工种或一项工作，而我更倾向于将运维理解是管理和服务的组合。管理的意思是我能拥有什么，服务的意思是我能提供什么，我大体想表达的是：

管理是对内的，指的是对我所拥有的各种IT要素计划、组织、协调和控制的过程，强调效率。

服务是对外的，指的是我们运维团队具备哪些能力、用何种方式够进行对外输出，强调敏捷。

如何充分发挥核心要素？

我认为运维作为技术团队，其拥有的四样核心要素是人员、流程、技术和数据。那么数字化转型背景下，这个四个核心要素如何发挥作用呢？

▲ 数字化转型下运维核心四要素

人与技术

人是最重要的要素之一，当人与技术互动的时候就会产生创新。我们可以先用技术解决我们熟悉的事情，然后打开思路，尝试新的方法来做新的事情。

我们需要通过专注于技术创新和利用破坏性技术的跨职能小组，在整个运维团队中展开更多的协同，以实现更高阶的运维自动化，提升日常运维管理工作效率。

我们应确保运维人员尤其是新加入的运维人员对掌握技术是充满热情的，并感受到运维工作拥有未来职业发展的道路。我们甚至可以提供一些奖项，以表彰他们对运维技术建设所作出的贡献。

技术与流程

在数字化转型下，流程已经不是孤立的存在于流程系统中，更不能仅仅停留在线下的纸上，而是要与工具和技术结合起来。

流程 + 技术 = 自动化，用工具系统驱动流程的执行和落地，既能保证流程在管理活动中是被遵循的，又可以提升运维管理的效率。

而随着机器学习、深度学习以及无处不在的低成本云计算出现，机器执行流程的速度比任何人够快。一个人创建100台虚拟机要花多长时间，机器可以在数分钟内完成此任务。

流程与人

在固有思维中运维管理流程是影响效率的，其作用是管控和评级，是降低用户（指的是管理员）体验的一种存在。

通过数字化转型，人们要转变这种想法，实际上应该是流程+自动化=高效率。当人们能够与流程真正互动起来，我们就可以实现“复制”。

在流程完整的组织中，一个人可能与十个人有同样的影响力，试想快餐公司是如何进行标准化的，例如：去北京麦当劳与去香港麦当劳的就餐过程应该大致相同。

为了达到最佳状态，运维团队需要分析流程系统中留存下来的信息数据，逐步提升运维管理能力。

数据

数据是数字化转型的基础，在运维领域玩数据已经不是什么新鲜事了，AIOps在各种行业大会中出现的频度越来越高。

如果说自动化是为了解决运维人员的执行效率问题，AIOps就是解决运维人员的决策效率问题。目前AIOps应用最广的场景还是监控方面，如根因定位、故障影响分析、容量预测等。

然而，我认为运维组织手里的数据可不仅仅是运维数据，稍夸张的讲是企业的全量数据，如何利用好手里的数据，是运维团队持续提升生产力的主要因素。

当运维团队开始改进人、流程、技术三个方面的互动，并尝试用数据创造价值时，我们运维团队就正走在数字化转型的路上了。如果你还不知道怎么开始行动，可以试着考虑以下几个问题：

我们不够快么？
我们效率不高么？
我们在创造价值么？

如果我们的速度不够快，我们是不是该考虑自动化了，做好技术与流程的结合。

如果我们的效率不够高，我们要审视一下我们流程与人的设计是否合理。

如果我们的工作体现不出价值，我们应该找找能创新的地方，充分发挥技术与流程、数据的作用。

如何提升运维价值？

过往我们会认为运维是保障性部门，职责就是为各个IT应用系统提供可用性保障。然而，我认为在企业数字化转型过程中，运维团队还应该借着转型的契机让自己能够提供更多，提升更多。

运维是几乎一切IT资源的供给者。如果把数字化转型比喻做一列高速行驶的列车，这趟列车的功力都是由运维团队提供和保障。与过往不同的是，运维团队应该让其他人获取资源的方式更容易、更敏捷、成本更低。我想这应该是企业都在大规模地上各种云的原因之一吧。

运维应该成为数字化能力的建设者。企业在数字化转型肯定是一个渐进的进程，这过程中需要建设各种各样的能力，比如大数据分析、人工智能、……等，企业数字化转型进入ABC（AI、Bigdata、Cloud）时代已经是必然趋势。

那么团队能在其中参与到何种程度，将一定程度上决定运维团队未来在企业中的地位。如果你的企业在考虑数字化转型，一定要抓住机遇，拥抱未来。

我认为还有一个重点，运维还应该成为成为数字化转型过程中的工具开发者。我们固有观念中，运维团队与开发似乎风马牛不相及。然而，企业在数字化转型后，将会有大量的工作需要转为线上处理，尤其是IT部门与其他部门的协作更要转变为线上操作，这就需要很多工具或系统需要建设。比如其他部门找我们申请IT基础资源、业务部门找我们提取业务数据、开发团队找我们查看应用日志……等等，我们不能指望所有事情都由专业开发团队或外包开发团队去实现，自有的开发力量是运维团队提升地位的重要保障。

到这里我再总结一下，运维团队在面对数字化转型的大势下，需要做好的三点升级：

效率升级

提升运维自身团队的效率，通过各类运维工具和平台的建设，提升运维工作的效率，如自动化工具，智能监控等。在一定程度上释放运维人的精力和时间，继而投入到数字化转型的思考上。

能力升级

要干大事总要有点像样的武器，运维团队可以先从自身的业务需求上着手，比如目前比较热门的AIOps、RPA等技术，可以结合日常的运维场景进行一定程度的探索，积累了经验后可以推广到其他业务场景。

团队升级

如果运维团队还是停留传统IOE体系架构下积累的经验，那面临来势汹汹的互联网时代就要小心了，抓紧时间提升自己的技能。很多金融行业、科技行业的企业已经组建了自己运维开发团队，或积极尝试开源产品，或借鉴互联网公司经验。

如何将运维转型进行下去？

有很多企业虽已经开始行动，但转型效果甚微。所以，我想再啰嗦另外一点思考，就是如何打破固有思维，保证转型持久地执行下去。我将其总结为5P。

目的 Purpose

在任何组织的转型中，都希望有更多的人能够参与到转型计划中，由此我们必须为组织转型设定有影响力的目标，这是我把Purpose放在第一位的原因。

很多人会觉得定目标很容易，不就是给自己立个响当当的flag嘛，如“建设智能化运维体系”、“打造SRE团队组织”…。事实上真的是这样么？你的目标需要与企业的战略结合起来，如在我接触到的一个银行中，提出了“提产能、促转型，为打造一流数字生态银行夯实技术基础”的总体目标。实际上当你设定Purpose的同时，你必须为你的Purpose回答下面几个问题：

你为什么相信自己能转型成功？—— 转型需要有力量Power

你需要让哪些人参与到转型中？—— 转型需要发动群众People

你打算如何影响相关的人们？—— 转型需要制定计划Plan

转型后会产生什么样的影响？—— 转型需要讲收益Payback

也就是我们接下来要讨论的另外4P。

力量 Power

你为什么相信自己能转型成功？你必须为自己的转型计划找到力量源泉，并让这种力量在团队中能够被充分认识到，可以尝试从四个方向去找：

企业战略

影响：将运维转型目标与企业战略关联，从而得到更高层领导的关注与支持。

思路：很多企业将数字化转型定为企业的战略，而IT能力是数字化转型中的重点建设内容，运维（或运营）管理又是其中不可或缺的一部分。

业务形态

影响：在业务发展过程中，企业运营模式也会随调整，运维也是其中一环。

思路：比如，很多企业都在发展互联网+业务，其特点就是敏捷，从而要求运维既能适应敏态，又能兼顾稳态，也就是大家都说的双态运维。

外部环境

影响：多了解同业的发展情况，毕竟企业要面对的是市场竞争，确保自己领先不落后。

思路：据我所知金融业间经常走访交流，对比行业领先企业的发展，保持自身竞争力。同时，也可以多参考顶级互联网公司的经验，如BAT的分享。

运维现状

影响：同时，自身现状不可忽略，找到当前和未来工作中的切实痛点，对症下药。

思路：运维转型肯定会有一定的内驱力，很多运维团队都面临着人手不足、效率不高等问题，从这些具体问题开始，制定对应的行动计划。

另外一个获取力量的要点就是高层的支持，凡是涉及到组织转型的项目，必不可少的需要相应的资源向其倾斜。并且从过往的经历来看，越是得到层领导支持的项目，其获得的资源就越丰富，项目也就成功了一半。在得到高层支持的前提下，为了运维转型的气氛营造的热烈起来，可以采取一下行动：

让领导参加运维转型项目相关的重要会议
在公开场合讨论运维转型项目的进展情况
迫使有反对意见的领导参与到运维转型推进工作
组织更广泛的培训学习，让每个人感受到运维转型的决心

总而言之，运维转型必须让所有人感受到是有力量的，让每个人深刻感受到是一种大势所趋，不能消极逃避而要积极主动。

人 People

人是重要的，在运维转型项目中，项目经理必须是有力量的人，并且是有时间和精力专注推动转型工作的人。

在过往的观察中，有部分公司会指派专门的项目经理负责运维转型的推动工作，并赋予项目经理很大的指挥权。而兼职的项目经理往往难以抽出足够的精力推动项目，因为如果项目经理同时肩负运维管理工作，运维是一件琐碎而繁杂的工作，一个人很难同时兼顾运维管理和推动项目两件事情，这不是人的问题是客观规律。

关于项目团队组建，主要有线性组织结构和矩阵组织结构两种，选择适合自己公司的实际情况就好。实际上，在不同的公司两个组织方式都有采用，有的公司成立了专职的工具建设小组，还有的公司从不同的运维团队抽人组成虚拟工作组。我过去合作过的一个客户，他们发起了运维开发倡议，让大家自愿加入到运维开发学习中，效果也很好。

计划 Plan

定计划是非常难的，这会涉及到路线选择的问题，是选择全自主研发路线，还是找合作伙伴支撑？

选择完全依靠自有力量的企业是非常勇敢的，需要很大的决心。这个过程需要面对很多的难题，远远不是简单堆砌一些开源工具就能满足的。一旦走上了转型这条路就很难停下来，解决了自动化的问题，还有DevOps、AIOps在前面等着，对着转型逐渐进入深水区，需要投入的人力资源是巨大的，需要许多艰难的技术。

当然，还有部分企业选择跟随策略，现在如BAT这些大型互联网公司开放出来的运维平台都是很好可选项例如：腾讯蓝鲸智云，一套用于构建企业研发运营一体化体系的 PaaS 开发框架，提供了 aPaaS（DevOps 流水线、运行环境托管、前后台框架）和 iPaaS（持续集成、CMDB、作业平台、容器管理、数据平台、AI 等原子平台）等模块，帮助企业技术人员快速构建基础运营 PaaS。

罗马不是一天建成的，转型也不是一蹴而就的，必然是一个持续迭代的过程，每家公司的运维都涉及很多技术领域，如硬件、网络、系统、应用、安全、……。传统技术架构的稳态业务运维尚未完全解决，现在又开始面临容器化、微服务化的敏捷业务，实在令人头疼。ITOM、ITSM体系还没玩转，又出现了DevOps、AIOps等理论体系，该何去何从？