极客时间已完结课程限时免费阅读

40 | 运维需要懂产品和运营吗？

40 | 运维需要懂产品和运营吗？-极客时间

40 | 运维需要懂产品和运营吗？

2018-01-19 赵成 来自北京
《赵成的运维体系管理课》
课程介绍

讲述：黄洲君

时长08:21大小3.82M

在《云计算和 AI 时代，运维应该如何做好转型》这一期内容中，我提到两个转型建议：一个是技术产品，另一个就是技术运营。今天我就更加聚焦地来分享这个观点。
我们运维接触更多的是软件生命周期中的运行维护阶段，我之前总结过一张图，就是在这个阶段要做的一些事情，把它们串起来就是下图：
这张图的思路应该非常清晰了，而且对照一下我们日常在做的工作，基本上也离不开图中所描述的这些事情。
这里我想表达的是，我们应该从这张图中敏锐地观察到，研发团队对运维团队的诉求，以及运维呈现的价值已经发生了变化，我们更加需要能够帮助团队建设出高效运维体系的角色，而不是能够被动响应更多问题的角色。

运维的角色转变和价值体现

打造一个运维体系，我们完全可以把它类比为一个产品业务体系。我们公司的组织架构中，针对一个产品或业务，如果要对其进行技术上的实现，自然就离不开类似运营提需求，产品分析设计、业务架构师设计建模、开发实现以及测试保障这样一环套一环的配合，每个角色都发挥着独特的价值。
那么，对于一个运维体系，就相当于是面向研发团队内部的一套技术业务体系，只不过我们的需求方和客户是开发人员，而不是业务人员。
我们对照一下可以发现，运维团队中技术环节的角色是不缺的，但是缺少的是业务环节的产品和运营角色。但是我们做事情，不一定非要有岗位上的明确设置才能往下做，只要有能起到这个作用的人承担这样的职责就够了。而这里，最合适做这个事情的，一定是运维，因为运维是日常线上运维的执行者，只有运维最清楚这里面的细节、问题和痛点，换其他人可能很难能够讲清楚。
当然了，我们也不能强制要求运维一定要完全具备产品经理和运营经理的专业素养，这样就本末倒置了。这里我们强调的是运维要有产品和运营意识，总结起来最本质的就两点：第一，能将需求讲清楚；第二，能将产品推广落地。

技术产品

关于技术产品，其实主要就是回答以下几个问题：
是不是能够把原本靠人工完成的很多工作转化成需求？
是不是能够把日常工作中运维和开发的痛点转化成需求？
是不是能够把当前系统存在的问题和隐患找出来，在解决的过程中，经过分析总结提炼成需求？
这个过程中，可以尝试把自己做的事情串一下，用流程图也好，时序图也好，把整个过程梳理一下。过程中每个环节具体要做的事情可以通过文字描述的方式写出来，尽量分条罗列，清晰有条理。这里也可以参考我们前面讲过的内容，把一些标准化和生命周期管理的方法论融进来。这样可以一举两得，我们的标准化制定能力，场景需求分析能力慢慢都提升上来了。
你可以按照我们刚才讲的内容动手做一下，这样整理出来的一份文档或者内容，其实就是一个产品 PRD 的雏形。如果你想要更进一步，有更加专业的输出，也可以参考了解一些产品设计方面的知识。
当需求提炼出来之后，跟对应的运维开发一起合作，将需求真正落地实现。这样一个过程下来，运维的价值和能力体现是不是就跟之前有了很大的不同呢？

技术运营

通过上面技术产品的工作，可以做出一些有针对性的工具和平台来。但是，仅仅有工具和平台还远远不够，因为只有把这个平台真正落地，并产生了实际效果，才是有意义、有价值的。这个“真正落地”就是技术运营要做的事情。
所以，接下来要做的就是落地。
平台推广落地。工具做出来了只是第一步，得要有人用，这就需要去推动落地，让大家都来使用，从而真正给团队带来规模上的效率提升。同时，我们的技术产品也是各种标准和规范的载体，在这个落地过程中，也是标准落地和执行的过程，就需要运维和开发配合做出一些改造，为后续更大规模的效率提升和平台建设打下基础。
线上运行数据分析。通过我们的平台和工具，对线上业务和应用运行时的指标进行数据分析。比如，应用上线或者每次变更上线后，线上运行的情况是怎样的，容量有没有降，RT 有没有上涨，监控有没有异常，用户体验有没有下降，用户和客服的反馈如何等等。以上这些维度和指标就需要通过数据、图表和曲线的方式呈现出来，并基于这些呈现进行分析和判断，做出后续运维决策，比如是否需要扩缩容，是否需要处理问题，是否有改进的地方。在这一点上，应该要形成对整个业务和技术架构体系改进和完善的正反馈才行。想想看，业务运营是不是也非常关注业务的数据报表，也要依赖数据情况决定后续的业务运营手段。
过程改进。平台更多的是一个执行工具，但是工具的使用是要配合大量的标准和流程一起来运作的。比如上面我们提到的，如果一次发布之后流量下降，RT 升高很多，面对这样的问题我们应该有怎样的应对机制，这里就体现出管理和流程的重要性了，要解决好不同角色和团队之间的协作问题。同时，过程中需要改进和完善的内容，能够落实到平台和工具的，也要形成正反馈，来提升我们工具和平台的效率。
这个过程可以用下图来表示：
我们面临的业务场景在不断发展和变化，这就决定了技术运营过程也必然是一个持续发展和完善的过程。所以从这个角度讲，技术运营的生命力和竞争力将会是持久的。
在腾讯，运维就被定义为技术运营，第一次听到这个岗位名称时，感觉还是很贴切的。另外，我在很多大会上听海外的华人工程师分享，Operation 这个词都是被直译成运营，但是在国内我们大多还是把 Operation 翻译成运维，从字面上就把这个岗位的定位给拉低了。
不过，叫什么不重要，只要我们通过今天的内容看到，具备技术产品和技术运营的能力才是最关键的，这一点最重要。

总结

最后，我们再总结一下，运维虽然不是业务系统的实现者和代码的开发者，但是我们参与到了产品技术标准的制定、业务系统运维体系的建设以及后期的技术运营中，这个时候运维已然成了整个技术架构的设计者之一，而且是架构稳定和演进的看护者，这时我们所发挥的作用和呈现的价值已大不相同。
从技术产品和技术运营的角度再来思考一下运维，现在的运维还是之前那个运维吗？欢迎你留言与我一起讨论。
如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 8

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
39 | 云计算和AI时代，运维应该如何做好转型？
下一篇
41 | 冷静下来想想，员工离职这事真能“防得住”吗？
 写留言

精选留言(9)

  • easyops
    2018-01-19
    运维人员的思想不能在局限于解决日常运维场景问题，而更应该有外延和内收的增强知识面。外延可以把自己的技术推广，打造个人影响力；内收可以把更多的运维场景梳理出来，真正地了解运维的需求，痛点，从而更好的修炼自己的内功。

    作者回复: 老王就是内外兼修的大神！

    共 2 条评论
    8
  • 朱雯
    2018-01-21
    听赵老师的课，提到最多的词就是生命力和价值呈现。如果只是专注于技术，对这两个词感触很可能就只是迷迷糊糊。这个课程之中使用了很多例子描述这两个词，让我明白了我该做的一些事情。1解决问题而不是沉迷技术。2呈现价值，提高岗位生命力。

    作者回复: 期望对你有帮助，多交流。

    7
  • haormj
    2018-01-22
    对于小公司而言有没有推荐的运维平台，看蓝鲸的介绍不错，但是只是CMDB和作业平台还好，容器管理不开放，自己做不知道如何入手。

    作者回复: 业务在云上的话可以考虑云上的运维平台，但是应用层面的自动化运维，还是要自己做，这也是很多运维平台很强大，但提供的更多是通用服务，个性化的很难满足。

    2
  • 岑崟
    2018-01-25
    运维的转型不仅是一线运维人员所面临的问题，也是运维管理者所面临的挑战。管理者的思想不转变，团队也难以转型；亦或者思想转变了，没有一个可实施的路径，无法承受在转型中的阵痛，没有在高一层的有力支持，有时候转型也是徒劳

    作者回复: 运维管理者首先要转变，研发团队的管理者也需要转变

    共 2 条评论
    1
  • 怀揣梦想的学渣
    2022-03-18
    作者多次提到运维不应局限于被动维护这样一个思想，在我的工作中，是有这样感受的。若是局限于遇到问题-解决问题-输出经验-遇到问题-复用经验，整个人是被困在这样的循环中。当我发现某个问题是可以主动联系产品研发进行根源上解决时，当我发现联系产品研发解决某个问题，并且全国的客户都不会再遇到这个问题时，我感受到运维的价值应当站在产品全生命周期去看，不应与研发对立，也不应局限于我的工作完成就结束。或许公司给的薪资不尽人意，但个人应当珍惜职业口碑，塑造更有价值的自己。
    展开
    1
  • 大G来了呦
    2020-09-14
    代码能力就是运维同学的必修课

    作者回复: 未来一定是这样，其实代码能力是一方面，更核心的是，要具备代码思维

    1
  • 技术修行者
    2020-05-28
    站在不同的高度，看到不同的风景。 摆脱传统运维的固定思维，跳出舒适区，积极拥抱变化，和上下游一起协作，保证整体业务架构和技术架构的稳定性和可运营性。 忽然感觉运维变得高大上了！
    1
  • Raymond吕
    2020-03-03
    思想越成熟的公司，比如华为，腾讯，阿里等，对运维都有自己的定义，有成套的体系和方法论支撑。其实不管自己能不能做到那种高度，但至少要知道有人曾经在那里，而不是抱怨环境导致自己停滞进化。
  • 牧野静风
    2019-07-26
    现在才拜读到赵老师的文章，如遇甘霖，我一直也在思考如何将运维工作自动化，也有很多想法，可是编码能力有限，也是慢慢在摸索。

    作者回复: 编码能力是一点点锻炼出来的，可以所做起来再说，从shell到python，再到go和java，一点点来。