4.8 聊聊运维研发

本章分三节：团队、协作、方法，本文摘前面两节。

4.8.1 聊聊运维研发团队

1.运维研发团队模式

虽然基于Google SRE布道推动了运维行业对于运维人员能力的深度思考，也有一些行业正在推动原来运维团队向SRE团队转型，在人员招聘、组织团队等方面进行改变。对于金融行业，但由于运维组织的人员流动性较低，企业已有的大部分运维人员都缺乏研发能力，无法达到Google SRE模式需要的研发技术能力要求，所以金融行业的运维研发更适合由一个独立的团队负责。这个团队当前关键价值是赋能运维职能团队，利用先进的理念与工具结合引领运维组织转型（当然，不排除后续技术架构的演进会颠覆当前的运维模式）。

金融行业运维研发团队通常需要集产品设计、项目管理、工具研发、工具运营、工具规划等多个角色的能力要求。哪个能力更重要与团队的研发模式相关。总的来说，由于运维研发将引入工具，带来线上化、数字化、自动化的工作模式变化，挖掘、引导、总结、明确最真实有效的需求是一个难点，所以我个人觉得行业运维研发团队能力排序大概：要做什么的能力>如何做的能力> 如何用的能力。

不同组织的运维研发团队研发模式有所区别。虽然都叫运维研发，但因为团队规划、产品、技术、资源投入的不同，研发模式也有一些不同，从调研看同业运维开发团队的研发模式主要有几种：

• 基于开源平台或工具模块，以自主研发为主；
• 使用外部产品，整合在已有运维工具体系中；
• 购买外包开发资源，支持运维开发；
• 基于厂商的产品或平台，进行合作开发（实际上多是以厂商出技术平台与开发资源，甲方出idea）；
• 基于上面几种的组合；

在实际的实践过程中，由于一些行业特点，比如系统异构、标准化程度不够、精细化管理程度、监管要求、企业里流程复杂度等，通常金融业里的运维开发团队面临的开发难题更为复杂，开发效率会低于互联网公司不少，所以互联网公司说他们20人完全可以支持企业所有运维开发工具的需求，但在金融行业里并不一定能实现。从投入产出看，在运维这个非企业核心技术线的团队中，20人的运维开发团队所需要的人力成本，相比带来的效益及见效期的期望，往往不如基于成熟产品的合作开发模式。所以从调研结果看，第4种“基于厂商的产品或平台，进行合作开发”的模式在同业中的运作效果更好。

2.运维研发团队定位

运维研发的核心价值是平台赋能。企业的运维平台建设者容易进入一个实现自我价值或唯技术领先为导向的错误方向，比如积极的引入更为先进的技术平台，应用工具，或落地领先互联网企业或行业大型企业的创新性的解决方案等，但引入的工具与企业运维组织的价值主张不匹配。这种情况在当前2B市场火爆的大背景下越来越突出，直接导致运维的“平台”与“组织”、“流程”、“场景”脱节，工具没有起到应有的作用。解决这个问题的关键是，运维研发团队要认清团队的核心价值是用平台赋能运维组织的价值创造，建平台要真实的反映运维管理期望或一线运维的痛点的解决。

运维研发是领先工作理念的布道师。要建什么工具来源于用户的价值主张，但是如何做需要运维研发团队与用户共同去沟通，通常来说用户习惯于尽量不改变原来的工作操作方式以运维研发在落地方案实现的过程中，会遇到“在汽车未面世前，大家需要的一辆更快的马车”的困难。所以，运维研发需要肩负领先工工作理念、模式的布道师的角色，以持续交付为例，项目的实施要做的不仅仅是将原来手工程序分发或配置修改做成自动化，而是要引入“持续”+“交付”的思路，从规范、标准、过程梳理、在线流程打通、制品管理、流水线管理、工具与数据打通等环节，形成一整套方案。

场景与数据是当前运维研发的重点。运维组织经过多年的过程，通常已经积累了“监、管、控、析”的平台能力，市场上对于这些平台也有了大量积累，我个人建议这类平台选择扩展性好的商业或开源解决方案，运维研发团队聚焦在与企业特点相关的场景研发。场景通常需要结合运维组织基本的组织、流程状况，对不同的时间、环境、人、事件下的打造的细分工作场景，每个场景将整合“监、管、控、析”的平台能力。

4.8.2 金融企业运维研发协作模式

金融企业运维研发在研发过程中，主要涉及内部用户、关联效率工具团队、外部厂商的协同，争取相关协同方的有效支持是一个很重要的工作。

1.产品设计来源用户

一切围绕用户真实痛点与客户价值期望。前面已介绍过运维平台的核心价值是通过平台赋能运维组织，所以在产品设计上，运维研发团队要对运维管理、一线运维痛点的敏感度。通常来说，具备大计算量、海量数据分析、操作性、规律性、流程化、7*24等特征的工作，可以作为痛点分析的切入点分析故障、变更、监控、值班等场景下的产品设计。另外，组织要发展也要建立对未来的价值期望，此时基于运维组织禀赋，设计面向组织发展需求的产品设计也是一个切入点。

挖掘有想法的团队或人。在运维组织中，总体来说不缺乏踏实勤劳的同学，但有改变想法并能够提出解决方案的同学则通常很少，这与整个组织或组织细分团队组织文化与管理方式有关。运维研发团队要善于挖掘有想法的团队或个人，一方面可能获得更真实的用户痛点与价值期望；一方面产品或解决方案落地后，他们可以作为种子用户进行应用，对于推广起来积极的作用。

将绩效给予用户。用户为什么愿意参与到产品设计中来，一定是对用户产生了利益，比如帮他解决了痛点，或实现个人价值，或获得了绩效等。在这个过程中，运维研发团队最好能够将平台工具带来的成效的绩效给予用户，比如每个工具设置一个用户侧的产品经理（因为知识背景原因，用户很难承担工具设计的大部分工作，研发团队还要有产品设计），这个工具打上这个产品经理的标签，更好的激励用户对工具的参与度。运维研发团队不在具体某个工具中体现绩效，而应该关注工具真正能够赋能一线运维的最终价值。

做好工具运营。评价一个工具好不好，要看工具是否真实的用起来，实现IT风险控制或提能增效等作用。通常来说，运维组织里没有用好的工具比需要新建的工具更多，或者说组织里有很多已经建立的工具没有得运营，造成浪费。做好产品运营是一个关键又容易被忽视的环节，一要争取一线用户参与到工作的使用，提供用户反馈的渠道，敏捷的响应用户的需求，让用户更加有参与感。二要让工具尽可能融入用户的运维主干工作场景上，在某些工作场景下必须使用工具，工具使用越高频价值越大。

2.互联互通

打破孤岛。企业虽然构建了不少工作工具，但工具间缺乏互联，没有形成协同网络，往往完成一件工作需要靠经验到多个系统上切换，甚至有很多工作只能在线下完成，没有留痕记录。结合当前国内外先进的工作方式，比如国外的slack、symphony，或国内的钉钉、企业微信、华为的welink，都在推动一个全在线的工作平台，将员工工作的工具进行有效整合，形成一个在线的工作平台。这个思路在运维组织中同样有效，尤其是随着devOps、敏捷、精准等思维的推动，多团队协同已经成为主流，运维内的工具，以及运维外的工具之间需要打破孤岛，互联互通。

数字化工作空间。构建IT运营数字化工作空间，一是需要从IT组织协同上进行优化，优化资源配置，强化信息传导机制，促进协同效率；二是利用在线数据构建更加安全、透明的工作环境，形成员工数字镜像，挖掘优秀员工，辅助员工成长，为IT运营管理水平的持续优化赋能；三是为员工提供全在线的工作装备，即综合运用线上、社交、移动、自动化、决策等工具实现组织连接、资源共享、减少低效率的工作，激发员工创新，提升团队的敏捷应对能力。

保持同理心。运维研发在推动工具建设，需要其他团队配置支持互联互通，或数据的整合时，要切记保持同理心，要多从对方角度考虑他能在这个协作过程中获得什么收益，去尽量帮忙对方考虑。比如，你让其他团队协助你做可视化参观大屏，你要让对方知道他能够将他好的成绩通过大屏呈现；你在与其他团队做持续交付时，你要帮助对方更好的控制变更发布的风险，减少发布时重复提交的文档，降低发布等待时间等。

3.长期的双赢

说到合作开发，通常会有甲方与乙方，所以需要分析一下双方的优劣势，才能看看如何取长补短，实现双赢。具体的分析则是如何从甲方角度让乙方将资源向我们倾斜，毕竟好的乙方人力资源通常是比较紧张的。

首先看看甲方：

甲方的运维开发团队，有些成员是从运维一线出身，对特定运维场景下的需求理解更深，更贴近真实的用户，对痛点或价值的把握更好；其次，甲方角色很容易得到市场中成熟的商业解决方案，并更容易理解并获取同业中真实解决方案及方案的应用状况。

有优势，劣势也明显，比如甲方实施人力资源少，且有大量的工作量分配在流程的消耗上，甲方的运维开发团队没有生存压力，在成本与效能的管控能力上比较弱等。

看完甲方，再来看看乙方：

乙方的优势在于，一个好的乙方通常见识面更广，他们见过行业及行业外各种客户需要，踩过各种坑，掌握行业更通用的需求与更完备的技术解决方案；同时，乙方有一个完整的研发团队，所以可以支持产品设计、开发、测试等人力与技术的支持；另外，乙方有生存压力，所以他们对成本与效能的管控更好，且实施效率快。

当然，乙方同样存在劣势，他们对特定的需求理解不够或他们需要放弃一些特定的需求，他们与真实用户的距离比较远，如何获得真实且正确的客户需求是一个难点；另外，好的乙方人力资源很紧张。

差距分析

有了上面甲乙双方优劣势分析，可以明显的看到将甲方和乙方的优势结合是一个很明智的选择方向。不过，从经验看，在这个过程中甲方要解决一个难题：“如何让乙方将资源向我们倾斜”。

如果你是行业TOP5，或在一个大的区域范围内的TOP3，很好，乙方可能会基于战略考虑，给你更多资源；如果你给足够多的钱，项目够大，乙方也会给你更多的资源。也就是说如果你所在企业名气大或给的钱多，乙方的资源倾斜问题不大。但，如果你的项目预算不算多，企业的名气又不能支持乙方的战略销售方向，我们应该如何获得乙方资源支持呢？就这一点，我和不少厂商的朋友聊起，得到了这样一个回答：这个甲方可以作为产品孵化场所，甲方的团队对产品或场景的理解更有前瞻性、更深入。

想想看，如果有一个甲方能分析乙方现有的产品能力，有针对性的梳理出优化的方向，或提出一种全新的模式，对于乙方来说是得到了一个更懂用户的产品经理或需求分析人员，将是一个很美好的事。

上面的观点很重要，将是我们甲方在合作开发中的一个切入点。不过在现实中，我们很多运维开发人员或以技术导向进行工具开发与设计，或主要承担项目经理或实施经理，对产品设计及后期运营支持比较少，这个背景不利于乙方对产品功能完善的诉求。所以在合作开发的模式下，我们甲方要充分发挥我们的优势，要去掌握一些产品设计的思想与方法，接下来一节针对具体的方法。