打开运维团队思路：运维工具设计的套路你都知道吗？

Posted 2021-04-26 DBAplus社群

编者有言：对于运维工具产品设计，甲乙双方都有各自的视角。那么站在甲方，如何设计运维工具能争取乙方更多的资源支持？这其中都有哪些套路可启发思路？且看彭华盛老师有什么看法。

本文根据彭华盛老师在〖2018 Gdevops全球敏捷运维峰会广州站〗现场演讲内容整理而成。

（点击“阅读原文”可获取彭华盛演讲完整PPT）

作者介绍

彭华盛，现于广发证券负责数字化运营工具建设方向，热衷研究运维/运营领域相关技术，力求构建一个可扩展性的运维/运营体系。

我们的主题是“运维工具的设计思路”，会尝试探讨在甲方的运维开发团队如何获得乙方的资源倾斜，为企业创造更高的价值。

一、话题的背景

这个话题的产生来源于上个月初与朋友的一次关于产品经理的聊天，朋友跟我聊起了他们在产品设计过程中总结并落地的一条产品开发套路，很有启发。

结束聊天后，重新梳理中间一些抽象方法，其实在我日常工作过程中也有应用，但零散不成套路，遂决定尝试做一个小研究：金融企业中甲方运维开发团队的产品设计思路，本篇为这个小研究开个头。

在本篇中，我尝试将目前工作中与产品设计有关的步骤抽了出来，再串起来一个主线作了一个片子（文末有分享的片子链接）。

二、聊聊运维开发团队

自Google sre 50%开发的布道，以及互联网公司、dbaplus社群等技术社区的推动，很多运维团队都建立了运维开发团队，金融企业也认同这种新的思路，在人员招聘，组织团队等方面都有改变。我在上半年做了一个金融行业运维的调研（调研了几家银行，几家券商，几家保险），其中在运维开发团队的运作模式方面，主要如下：

• 基于开源平台或工具模块，以自主研发为主；

• 使用外部产品，整合在己有运维工具体系中；

• 购买外包开发资源，支持运维开发；

• 基于厂商的产品或平台，进行合作开发（实际上多是以厂商出技术平台与开发资源，甲方出idea）；

在实际的实践过程中，由于一些行业特点，比如系统异构、标准化程度不够、精细化管理程度、监管要求、企业里流程复杂度等，通常金融业里的运维开发团队面临的开发难题更为复杂，开发效率会低于互联网公司不少，所以互联网公司说他们20人可以支持企业所有运维开发工具的需求，但在金融行业里并不一定能实现（另外大部份同业的运维开发团队不超过6个正式员工）。

同时，从投入产出看，在运维这个非企业核心技术线的团队中，20人的运维开发团队所需要的人力成本，相比带来的效益及见效期的期望，往往不如基于成熟产品的合作开发模式。

从调研结果看，第4种“基于厂商的产品或平台，进行合作开发”的模式在同业中的运作效果更好。所以，本篇思路的基础是：金融企业甲方里的“运维开发”不等于“完全的自主研发”，探讨在“合作开发”的运维开发模式下，如何创造更高的价值。

1、甲方乙方

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

首先看看甲方：

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

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

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

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

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

2、差距分析

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

如果你是行业TOP5，或在一个大的区域范围内的TOP3，很好，乙方可能会基于战略考虑，给你更多资源；如果你给足够多的钱，项目够大，乙方也会给你更多的资源。也就是说如果你所在企业名气大或给的钱多，乙方的资源倾斜问题不大。

但，如果你的项目预算不算多，企业的名气又不能支持乙方的战略销售方向，我们应该如何获得乙方资源支持呢？

就这一点，我和不少厂商的朋友聊起，得到了这样一个回答：这个甲方可以作为产品孵化场所，甲方的团队对产品或场景的理解更有前瞻性、更深入。

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

上面的观点很重要，将是我们甲方在合作开发中的一个切入点。不过在现实中，我们很多运维开发人员或以技术导向进行工具开发与设计，或主要承担项目经理或实施经理，对产品设计及后期运营支持比较少，这个背景不利于乙方对产品功能完善的诉求。

所以在合作开发的模式下，我们甲方要充分发挥我们的优势，要去掌握一些产品设计的思想与方法，以下进一步介绍一些方法。

三、一些方法

由于缺少一个成熟方法论的支撑，这里抽象出来的方法目前看可能比较分散，各位可以有侧重的阅读。

1、先讲项目背景

因为后面的方法介绍中需要举到一些例子，所以先把例子涉及的项目背景简要说一下。

我们是以“监、管、控、析”为主线的运维工具体系建设，分别对应监控工具集、流程管控及IT服务工具体、生产操作自动化、运维数据分析。这个工具体系思路是以领域驱动的设计思路，将运维工具体系中不同领域的工具进行分解，重点是领域深度上的扩展性。

虽然在扩展性方面解决了我们的工具建设问题，但在实际的工具使用过程中我们仍然会遇到几个问题：

• 由于一项工作场景通常需要使用到“监、管、控、析”多个工具，用户需要在多个工具中来回切换，工作方式仍以经验导向，缺少一个经验沉淀或最佳实践的落地；

• 有重复建设的问题，互联互通程度不够的问题；

• 大部份工具是面向与生产环境交互的自动化，但是对于日常运维管理及事务性的工作，线下程度高；

• 为了解决上述问题我们提出了场景可视化项目。项目在工具体系层面上是在“监、管、控、析”之上建立一个信息整合层：

上图的场景可视化层的核心目标是：结合团队背景，以“场景”的思想，以可视化为主要手段，构建管理及事务性工作自动化，整合”监管控析”工具集的工具调用与数据的互联互通，落地运维专家的最佳实践。

为了支撑上述目标重点要进行以下三个手段：

• 统一可视化；

• 自助式与关键场景构建；

• 管理及事务性工作自动化。

项目以“场景”作为核心思路，即“特定的时间+特定的环境+特定的人+特定的事件+特定的连接方式”，场景思想作作为后续所有的场景设计的指导思路，以提高扩展性。以下尝试用一个故事来介绍一下项目：

2、方法

关于产品设计的方法套路根据不同的行业，不同的角色会有不同，从甲方角度考虑产品设计相对更简单一些，我们通常重点要关注设计出的运维工具有足够的粘性，不需要考虑商业论证。

不过，我平时在设计一个工具时也会考虑商业价值，原因有两个：

• 一是我希望乙方也能在这个项目的产品设计过程中获益，你多为乙方想，乙方也会多为你着想，这样能建立更为长期的合作关系；

• 二是如果乙方的项目产品设计更为通用，后续的升级也能应用在我们的项目中，也是双赢的目标。

这里从简单考虑，不考虑商业论证的环节，包括发起、价值主张、技术方案、设计与选型、运营5个环节：

1）启动一个项目

通常来说，我们启动项目有两个思路，一是技术推动，二是需求拉动。

• 技术推动是从技术角度出发推动项目的发起，比如“应用XX技术，实现XX”，像我们金融行业里讲AIOps很可能是这种类型，或为了参加比赛，或提高技术储备，或为了工具体系的完整性与扩展性来进行这类项目，从这个角度看，我们也可以认为立足长远。

• 需求拉动是从用户痛点或需求拉动的角度出发接动项目的发起，比如“解决XX问题，实现XX价值”，像我们说的解决手工在多台服务部署程序，解决监控事件分散的问题等。

需要声明的是，上述两个思路都有存在的价值，关注这个点是希望项目的发起要清楚项目发起的源头，不要舍本求末，抓住关键。这里我举个例子来说明关注启动项目的思路重要性。

我曾经做过一个集中监控优化项目，当时项目目标是解决集中监控的性能问题，降低监控事件报警误报率，提高事件处理及时率。在拿到这个项目后，我们刚开始制定了以下解决方案：

• 将原来单节点的mysql数据库架构进行改造，以基于MyCat的分布式数据库中间件，扩展为17个数据库节点，对大表进行分片，对数据库进行读写分离；

• 建立动态基线，解决节假日与夜间的监控误报情况；

• 对监控可视化进行改造，建立事件集中、丰富、处理等全流的可视化策略，实现事件与ITSM关联。

在第1、2两个方案中虽然在技术上是亮点，但做的过程很痛苦的：

• 比如基于MyCat的分布式数据库中间件的应用上虽然最终也解决了数据库性能问题，但由于刚开始对表的分片没有设计好，实施过程中发现跨表访问的速度反而下降，另外后期的维护成本也变高。

• 再比如第2个动态基线的方案，由于算法选择问题反而带来了另外一些误报。

事实上，我们后来评估，第1个性能问题解决只要使用读写分离，并进行大表数据迁移就能解决问题，第2个误报情况主要原因是由于阀值策略不合理、监控事件级别设计不好、变更维护过程中没有设置维护期导致，所以我们在对阀值策略、事件级别分类、变更维护期与变更部署系统联动后，报警数量收敛明显。

总结下来，其实在一开始的选择方案中就出现问题，因为这个项目是为了解决实际的痛点，应该就痛点来选择技术方案，而不是选用一个更先进的技术架构方案来解决问题，技术架构原则上应该是演变过来才合理。反过来，如果这个项目是一个创新性的项目，那么应用分布式数据库中间件、基于算法的动态基线则是合理的。

最后，再强调一下，两个项目发起都没有谁对谁错，存在即合理，关键是做项目的人要清楚是技术推动，还是业务拉动。

2）价值主张

价值主张有一个成熟的思路方案，关于价值主张详细的说明，可以参考以下这本书：

书中以一种图文并茂的方式介绍了价值主张设计在产品设计过程中的实践，主要围绕以下这张价值主张画布：

我是上个月底看到这本书，在此之前没听过价值主张这四个字，实际上到目前为止我也只是粗看了一遍。所以接下来，我主要讲讲在价值主张这个环节中，我原来会做的一些事以及用到的一些工具，与价值主张原有意义可能会有些不同。在这个过程中，我们进行价值主张的方法来实现以下目的：

• 确定最准确的用户群与用户需求；

• 找到最迫切、最重要的工作目标，获得清晰明了的重点工作；

• 使团队行动协调一致；

• 避免无效或低效工作的开展，舍本求末，降低失败风险。

在这个环节中，我通常会使用四个方法：

• 用思维导图梳理思路，讨论明确逻辑关系，确定大的方向，并与厂商达成共识；

• 借鉴别人经验，我通常会去做些同业调研，厂商交流，也会跨界去看看2C方面的软件，有时候跨界能产生更棒的效果，因为好的生活软件实际上己培养了用户习惯，你只要参考这种方式设计就能更好的运营落地；

• 用原型图与厂商或用户达成共享，通常用粗细条是为了与厂商达成共享，用低保真或高保真的图是为了与用户达成共享，大部份时间里低保真的图也够，高保真的图通常是为了更好的传递设计思想或与重要用户的交互；

• 讲故事特别有用，尤其是要在短时间内给方案审批方讲解时，比如给领导汇报工作时就特别有用，在用户故事中还会结合原型图的方式讲故事。

Ok，以下进入这一环节的具体介绍，首先我以运维场景可视化的统一IT服务场景的设计作为例子。

在统一的IT服务的设计中，希望设计一个场景能实现IT团队从被动受理IT需求向主动进行IT服务供应转型，即建立一个类似一站式IT服务搜索的技术方案，运维人员可以将服务供应能力发布在上面，服务的申请方只要根据关键字快速就能获得IT服务，最终的方案如下：

为了实现上述的场景设计，应用以下的方法及工具。

（1） 思维导图

思维导图在整理思路、思维扩展等方面都很有用。通常是将一个问题或目标，通过某种结构拆解为多个部份，每个拆解的部份又可以进一步往下拆解，使用思维导图还有助于培养结构化思维，在处理问题上更有逻辑性。

我在很多场景中都会用到思维导图，比如工作中的写方案大纲、需求收集、功能设计、临时性的讨论等场合，以及工作以外的，梳理一篇好文章的内容时，也很有用。

思维导图主要是分解，在应用过程中可以提前形成一些套路：

• 比如技术方案大纲可以这样分解：背景（痛点或需求，解决思路）、技术方案（方案概述、方案分解及介绍、投入产出分析、实施路线）、展望；

• 再比如运维工具功能设计时通常会采用：概览（可量化的重要指标）、用户角色、用户提出的需注、实际的技术方案、主要前端功能（通常抽象几个大的功能点，再对功能点进行扩散）、后台功能（同上）。

下图是我在场景可视化项目中的某个需求分析阶段，集中几天梳理的功能设计并梳理的思维导图：

（2） 借鉴

上述的思维导图不仅有助于设计人员不断的拆散对功能实现的理解，在与用户收集或确认需求、与厂商沟通技术方案时都很有用。

在进入工具或功能设计后，我首先会去借鉴别的系统设计思想（我们设计工具目标是在内部让大家用起来，什么设计容易推广与运营是我们选择方案的重点，如果是创新则可能有另一种方式），在这方面的选择有很多，可以是领域领军企业的系统设计，也可以跨界2C的设计思路。

以IT统一服务场景为例，我有借鉴servicenow的服务前端设计（事实上IBM的服务支持中心也是类似的设计）：

除了同业的设计思路，一些日常2C的功能设计也可以借鉴，比如百度、Google极简的搜索方式己培养了很多用户习惯，我们只要按这个方向去设计，在推广运营过程会更加容易。

同理在移动端的设计上，也可以借鉴手机上的一站式搜索，以下是华为手机的一站式搜索，可以对手机及云上的多个渠道进行一站式搜索。

（3） 原型图

原型图也是一个特别好用的工具，它是思维导图分解思想及借鉴的案例在结合己有需求后的直观落地形式，是达成共识，减少后期改动，促进开发效率的办法。

通常我会用到粗细条、低保真、高保真的图，从可视化效果看越来越好，但投入成本也会越来越高。

由于我自己不会画高保真的图，所以通常只有要与重要用户（比如领导或项目初期的统一思想）时会用到高保真的图来辅助沟通。在与厂商开发人员沟通时采用精细条、低保真也能达到沟通交流目的。粗线条可以在白板、触控电视机，也可以纸上画，比如下面几张图就是粗细条的原型图，我们通常在讨论时快速画的图：

上面的精线条图主要是要将需求体现在原型上面，但在实际设计过程中还要考虑一些部局、简单的交互，需要细化设计的内容，指引开发人员的开发，这时就需要使用低保真的图。

低保真的图还会用来与用户需求提出方进行交流，并在这个图的基础上让用户提优化需求与建议，我们使用Axure来画低保真的原型图，还有一个在线的工具叫墨刀也可以试试（modao.cc）。比如下面这两张图：

高保真的原型图就是前面发出的两张图：

（4） 讲故事

讲故事是一个特别好的方法，故事能把一些零散的需求串起来，要讲一个好的故事并不容易，所以如果条件允许通常我会在故事中加上高保真的原型图，通常高保真的原型图是让厂商画出来的，因为我们没有这方面的资源。

关于讲故事可以参考前面讲项目背景时的故事方式，主要是什么时间，什么人，做工具做了什么事，得到什么效益，比如：

• 11点，小明根据指引，在ITSM中发起服务申请。

• 16点，IT运维人员根据服务申请单，支持相关申请。

• 次日10时，小明在统一IT服务场景中可以看到申请的进度，并可以根据SLA情况进行催办，服务台人员可以帮助进行催办。

• 在完成相关申请后，IT团队中负责互联网VPN的同事发现他的申请仍为邮件方式，所以他在ITSM中上架一个VPN用户申请的服务，在统一IT服务的服务目录中就可以找到这个服务。

如在上面的故事中，要有侧重的将产品的统一搜索、NLP、多渠道的信息整合、服务处理轨迹可视化、服务上架、催办等主要功能呈现出来，以更为生动和贴近用户的方式介绍功能。

3）技术方案

完成前面的价值主张后，我们和项目相关方之间就“重心是什么，要做什么，做得怎么样”达成共识，接下来就要开始评估如何实现，即技术方案。我会关注四个视角的架构：

• 用户视角：准确来讲这个视角不属于架构，只是下面的视角会与用户相关，所以暂时放在这里。用户视角是要对工具的用户进行梳理，了解这些用户的特点，重点关注重要用户及大部份用户的通用诉求。

• 功能视角：针对功能级别的分类与不断分解，通常我会以一个工具套路，比如至少要有一个面向不同用户的总览，有一个配置后台，再针对不同的工具设计不同的查询、操作类功能；

• 技术栈视角：以分层的方式梳理好使用的技术，需要重点关注技术选择与项目的发起有关系；

• 数据视角：需评估数据来源、数据存储方式、数据整合方式、数据模型。

4）设计与选型

制定上述的技术架构后，需要评估自研还是厂商合作，如果选择厂商合作还要关注以下问题：

• 找一家什么样的厂商：是找一家产品成熟的厂商，还是找一家愿意与你一起打磨的厂商，对于需要客户化的工具的选型，我通常会找后者，不过前提是我们要有足够的建设思路来支撑这个客户化，否则建议找前者；

• 厂商的技术特点的分析：如果选定一个愿意客户化的厂商，需要考虑厂商的基因，有些厂商以集成为主，这种厂商的实施能力强，但缺少核心技术；有些厂商掌握技术平台的能力，扩展空间大会大一些，建议找后者；

• 厂商对业务的理解：还要关注你选的厂商对你的需求的理解能力，有些厂商只能理解你的需求的50分，有些能理解到80分，甚至110分给你带来惊喜； 

• 找一家思路统一的厂商很重要。

再具体到设计阶段，则要关注更多的事情，比如在场景可视化项目中会关注：

• 设计过程中融入项目的思想。比如这个项目的核心思想是“场景”，特定的时间+特定的环境+特定的人+特定的事件+特定的连接方式，在具体的场景设计中就要关注这几个特定的元素是否关注到位；

• 定义主要功能的设计策略。比如这个项目的大功能是大场景与小场景，大场景要集中力量去做通用的场景，沉淀最佳实践，小场景则赋能给用户自定义，所见即所得，两者的基础支撑是有区别的，前者是个性化方案，后者是通用方案；

• 制定一些设计标准。比如这个项目的可视化色彩的应用，白与白的相近色为底色，蓝与蓝的相近色为装饰搭配色，红色与橙色需慎用，红色是马上要处理，橙色是建议要关注处理。

• 场景下的功能设计模板。比如这个项目中每个场景工具的大布局保持一致，左边为菜单，右边主体，每个工具都带有一个多维用户的总览等，这样可以提高效率及用户体验。

5）运营

说到运营，很多时候我们都把主要精力关注在功能的实现，但功能用得好不好则关注度比较少，所以我们在设计功能前也要考虑运营的问题。

我们做工具的人要定位自己是一个服务方，做的工具是为了运维人员更好或更快或更合规的开展工作，只有他们把工具用起来，我们的服务价值才能体现出来。

所以，我们在设计过程中要考虑用户体验、行为习惯、操作方式，实现上要将使用的过程数据保存来支撑运营监控，并有效的运用运营数据来辅助推动优化与推广。在运营推广的过程中有些思路可供各位参考：

• 推动工作自上而下，获得支持；

• 先试点，再推广，试点的选择很重要，最好有示范效果，是一个好的例子；

• 推广是采用全做出来一次性推广，还是分功能迭代推广，选择重要功能迭代推广时应该如何选择，比如选择有使用粘性的功能是一个思路；

• 有运营数据来支持推广的进度，在统计运营数据时也有一些策略，比如多少频率发统计数据，发给哪些人，统计的口径要不要排TOP几，重点问题要不要点出来都需要灵活的选择；

最后，以陈傲寒聊过产品设计的几个“度”作为本章的结尾：

• 稳度：即核心价值是否实现，是否吻合项目发起初衷；

• 粘度：是否对用户有粘性？是每小时用、每天用、每周用、每月用、特定场合用？当然有时候用得少并不代表粘性不够，可能有些场景下的使用是高价值的；

• 广度：范围的蔓延与镀金情况的评估，有时候做多了未必是好事；

• 滑度与速度：交付能力与交付速度；

四、结语

本篇聊到的话题主要是针对在甲方运维开发团队中的产品设计思路的一些零零散散的整理，希望能给目前甲方运维开发团队的朋友向运维工具产品设计的角色转型提供一个思路，也是对今年来的几个运维转型研究的延续。

相比IT运营、IT服务、IT运维分析、IT运维横向管理这几个转型，产品设计是一个很有意思的方向，对个人的能力要求，知识面的广度要求都会更高一些。

因为我也不是产品经理，所以内容不专业，欢迎有兴趣的朋友留言交流。

近期热文

↓↓↓别忘了点这里可下载PPT~