基于产品思维驱动的运维服务建设

前言

技术人员转型产品经理（Product Manager）并成功的有很多例子，牛逼的如业界大佬 Pony马、雷布斯、张小龙、周鸿祎等等，不算牛逼的但也做出不俗成果的如你身边的 XXX、YYY、ZZZ 等等。现在互联网业界大多数 to B （即对企业级，区别于 to C）的 IaaS 或者 PaaS，如各种云计算服务、存储服务、安全服务、数据服务、监控服务、日志分析服务、DevOps服务等等，这些产品显然是一群既精通技术又懂产品设计的人所创造出来的。所以，技术和产品这两项能力并非相互对立的，而是根据工作所遇的实际业务情况来选择所需的思维能力，取长补短。

在知乎上看了大多数关于怎么入门产品经理的回答，基本上都是各有各说法，没有一个权威的培养模式。不像程序员的养成方法基本是有业界共识的，一般是「数据结构 + 编程语言 + 常见算法 + 常见框架 + 设计模式 + 大量编码」这样的主流套路。而产品经理本来就没有所谓的科班出身，大部分 to C 业务招聘 PM 也不限制专业，而且大多都是放养式的培养方法，一旦跟对了好导师或者好项目，成长飞快，否则呵呵，不然也不会存在那么多码农想砍 PM 的段子。

为避免离题，本文先预设前提，就是定位于技术型的产品经理，而非对各种 to C 的五花八门业务形态。另外，虽然 title 有经理二字，但这并非一个管理职能，而是一个专业职能，可以理解为产品规划师或者产品设计师。然后，我们再把议题聚焦到运维团队设计与开发自动化平台这一个具体的实践过程，运维工程师们该怎样理解和应用产品经理能力？

什么是产品经理能力

产品经理的职责是负责一个互联网产品的设计、规划以及其整个生命周期的管理，其能力高低有个比较核心的指标叫做「Product Sense」，翻译成中文一般叫产品思维或者产品感觉。其意思是指 PM 能在分析业务问题的过程中，可以以各个纬度的角度去全面思考问题，并得出一个逻辑完备、有效、透彻、综合的产品结果的能力。

作为技术人员看到这个指标首先会感觉很虚，因为我们通常都是习惯了「Talk is cheap，show me the code」的思维模式，但产品经理偏偏是一个以 Talk 为主的职能角色，这个核心思维模式的差异就决定了 PM 和码农之间必然存在着某种代沟。

然而，一个好的 PM 能透过各种繁杂的技术细节找到问题的核心本质，也能制作出一份逻辑清晰、细致、合理、能创造价值的 Talk，能大程度地避免无意义的需求变更和回炉。另外，好的 PM 也是 Dev 的良师益友，特别是技术型的 PM 会着重于逻辑、落地、可行性、价值变现等细节，而非三天两头突然给你来个拍脑袋的所谓创意。

总的来说，的产品经理至少需要具备以下能力：完备的逻辑能力、对业务细节的把控能力、对团队资源的统筹规划能力、时间和目标管理能力、ownership、自驱力等等，显然，这些能力对于的技术人员也是适用的，正如前文所说技术和产品能力并非对立而是可以互补。

产品经理能力在运维工作中的应用

回到正题，谈谈运维平台的设计和研发过程中该怎么应用 PM 能力。

一个产品的生命周期主要阶段有：市场调研、竞品分析、产品规划、产品设计、需求分析、需求评审、编码实现、产品验收、持续迭代等等，但我们真正做运维内部平台时肯定用不着每个步骤都刻意去走一遍流程，比如前期的竞品分析之类的权重可以弱化。

Step 1 产品规划

产品规划阶段包含比较多的子步骤，对于运维平台建设，我们至少要理清这些问题：

• 平台面向的用户有哪些，用户角色怎么划分权限，例如运维、项目研发、产品/策划、QA、运营等；
• 每周、每月预计有多少的使用频率，预计能为运维团队节约多少人力资源；
• 有无开源或者商业解决方案，和自研对比有何优缺点；
• 开发周期预计时长，研发人力成本预估，个版本需要达到怎样的效果；

可以看出，这些过程中已经包含了「市场调研」、「竞品分析」等子步骤，因为对于面向公司内部的系统，这两个子步骤的执行复杂度和权重都是比较低的，可以直接归并到「产品规划」中。

然而前面所述的都是一些具体问题细节，属于战术层面，而产品经理真正要做的是以更高的战略层面思考整个运维团队所需要规划的内容。

对于运维团队来说，产品规划是团队工作方向的纲领性指导思想，为了统一团队目标以及提高团队凝聚力，直白来说就是让整个运维团队都能围绕在一个核心目标来开展工作，形成团队合力。举个例子，比如当前我们面临的情况是监控不到位，故障发生时运维团队却后知后觉，所以季度规划就是建设一套精细化、层次化、模块化的监控体系，其他旁枝末节的事务在不影响线上环境稳定运行的前提下暂时搁置，整合整个团队力量来完成季度目标，业务结果导向。

战略面要思考的核心分别是运维团队面临的「问题」、我们所拥有的「资源」以及为了解决这些问题要达到怎样的「目标」，思维导图如下：

这是一个比较全面的问题集合，但我们还要在其中找到核心重点，按优先级逐个击破，不能面面俱到分散精力。

那么问题来了，我怎么知道当前面临的问题是什么以及该达到怎样的目标？能否分析出问题和得到解决方案就是体现运维团队价值的时候了，这只能取决于决策者的能力和经验。

Step 2 需求分析

需求分析阶段算是整个开发周期核心的部分，说其决定了项目成败也不为过。

• 平台由哪些功能模块组成；
• 众多模块的实现的优先级排序；
• 功能模块之间的相互依赖关系；
• 每个功能模块预计完成时间；

这个步骤在我另外一篇文章有详细描述：
中小型运维团队如何设计运维自动化平台

Step 3 需求评审

这一步需要和团队的运维和运维开发同事反复进行，特别是针对一些实现难度或者复杂度较高的环节。

这个步骤的目的也是为了完善上面的需求分析，Step 3 和 Step 2 可能需要反复执行几次，直到把需求完善到整个团队都能一致通过为止。

在这个过程中也需要帮助运维开发理解业务情况，通过反复的会议讨论加深他们对运维业务的理解，因为运维开发未必都真正操作过一线的运维工作，如何能让他们更快、更好地正确理解运维工作也是本阶段的重点。

Step 4 编码实现

在这里开始需要和开发同事有更多的互动，包含且不限于：

• 协助开发同事正确理解运维业务和功能需求；
• 将大的任务分解成可分配的独立小任务，统筹分配开发人力资源；
• 对需求迭代进行质量与进度的把控，推进功能上线，如有遇到方向跑偏则及时修正；
• 共同解决某些疑难运维技术问题；

在这个阶段为了更好地和开发同事沟通协作，运维产品经理要具备必须的面向对象思维，如：

• 面向对象：类、对象、接口、封装、继承、多态
• 设计原则：低耦合高内聚、单一职责、开闭原则、接口隔离
• 设计模式：单例、工厂、原型、反射、适配器、装饰器
• 软件开发过程：需求模型、领域模型、设计模型、实现模型
• 图例：UML、用例图、类图、结构图、系统顺序图

运维同事虽然编码能力远远比不上研发同事，但在某些宏观概念上的理解也要和他们达成一致共识，所以我们需要学习这些编码理论指导方法论。当运维深入理解这些理论之后，对于需求设计也是具有指导意义的，你会潜移默化地把一些功能模块化封装、分层、复用，尽管未必参与实际的编码过程，但对于整个软件架构体系的理解也是可以做到的。

另外对于开发实践过程也可以做更加合理地引导，如核心基础组件API化，向上提供业务层的服务能力，具体例子如修改XX功能，你会马上知道只需要稍微改一下底层的YY模块，不需要动ZZ模块。

作为技术型产品经理，需要理清所谓的技术边界，即什么事情在技术层面能否实现？是否容易实现？业务也必然存在约束与限制，成本与收益是否平衡需要在产品经理这一个环节就要确定，绝不能让开发花费了大量工作时间才后知后觉发现事情收益太小不值得做。技术层面的约束和限制在运维平台的设计中起着重要的作用，它可以作为是架构设计的原点环节，也可以是功能迭代的驱动元素。

在这个过程中，运维产品经理需要做到：

• 深刻理解系统的每个层次模块的定位和向上向下的意义延伸；
• 能结合运维业务理解和技术理解的双纬度协助开发同事对系统架构的优化和调整；
• 用少的研发人力获得大的边际收益，即简单问题简单解决，复杂问题则创造条件来简单解决；
• 能使得系统架构以及功能规划尽量得适用于后期的业务需求发展；
• 利用自身的运维技术背景来预见未来可能面临的问题，考虑长远并避免无意义的重构；

总的来说，就是在效率、性能、成本、可靠性、扩展性、时间进度、人力资源等众多因素中综合考量得出一个相对较优的方案，这个过程通常是很艰辛的。因为这几个因素是相互制约，如想快速出成果，就要多加人力资源赶进度；想做到高可用高性能的话就要考虑复杂的架构方案，可能会延缓进度和提高成本；想快速交付就不能太多考虑扩展性等等，又要马儿跑，又要马儿不吃草几乎是不可能的。

如果没有什么特殊考量的话，以小目标来驱动快速交付永远是正确的，因为老板、领导、业务侧不可能等你一年半载完成一个大project，需要快速落地见成果。佳策略是既能满足需求，又稍微超越用户的期望，让用户对我们的下一次迭代更新有更高的期待。不要奢望做一个完美主义者，互联网的工作模式是快速迭代、快速调整。

Step 5 产品验收

建设一个完整的运维平台是个大工程，需要注意产品验收需要先针对每一项独立的小功能，再上升到完整的产品层面。切忌不分主次、贪多求全，必须以小目标驱动整个系统研发的过程。

Step 6 持续迭代

打造一个好的系统是不可能一蹴而就的，需要经历反复打磨、推翻、重构等一系列的过程才能完善起来。

太鸡汤的内容就不多写了......

业务价值挖掘

这一部分主要是需要产品经理以更高纬度地提炼以及量化我们所做产品的价值。

先举一些其他业务形态的例子：比如某某业务功能同比增加了多少活跃用户、提高了多少付费率，为公司创造了多少GDP等等。

那我们做运维平台的意义在哪里呢？对内价值就是降低了多少故障率、提升了多少工作效率、节约了多少人力资源等；好是不仅将其定位为一个内部辅助系统，需要将其和业务侧的墙打破，介入业务发展的生命周期，这样做才能将运维价值大化地变现。

运维平台中和业务运营相关密切的功能模块一般有数据分析、弹性伸缩、成本核算、用户体验优化等等，如何才能包装好运维平台和为其讲一个好故事，也是运维产品经理的职责所在。如何能让不了解运维业务的领导们或者外部门的同事们都能理解、认可运维价值，其意义是非常重大的。

讲故事的核心一般是围绕四要素：「质量」、「效率」、「安全」、「成本」，每年的业绩、KPI、成果汇报不外乎都是落在这四个纬度。

怎么体现整个运维团队的价值体现，简单粗暴就是数据说话，因为老板们才不管运维团队具体用了什么黑科技。

比如：

• 核心业务全年可用时间达 99.999%，全年故障次数低于 3 次；
• 人均维护机器数 10000 以上，人均维护业务集群数 5 个以上；
• 日持续发布频率达到 30 以上，故障率低于 0.1%，发布时长低于 60 秒；
• 大数据平台数据量 1000T 以上， CDN 流量 10000G 以上；
• 硬件成本降低50%，每年为公司节省10个亿；

备注：以上数据纯属虚构！

总结

所谓的产品思维在不同的业务形态中可以演化出不同的能力，而运维也是一种特殊的业务形态，我们可以利用产品思维来更好地解决工作中遇到的问题。把运维服务当作一种产品，我们可以将这个产品平台化、精细化、实体化，通过实践 DevOps 理念，打破业务侧、研发侧、运维侧之间无形的墙， 然后用一种类似 PaaS 的方式来为业务团队提供高质量、高性能、高可用、低成本、快速的运维体系服务。而基于产品思维来驱动运维团队，也许能让运维工作更有意思。