本文已参与「新人创作礼」活动，一起开启掘金创作之路。

序言

假设老板现在要把一个业务的运维工作全部交给你，习惯了拧螺丝钉的你肯定马上想到做工具、搞自动化提效、搞监控系统...等等。这时老板摇摇头表示：还不够。习惯了只做点状的工作，但是不能只做点状的思考。

我们从价值流动的视角来看整个过程：需求产生、开发、测试、交付、线上运营。运营阶段又有：故障预防、快速定位、快速恢复、恢复之后的故障管理机制等等。每个阶段都有体系化的方法论和系统建设思路，这样一想，是不是思路瞬间变立体了。

运维体系建设总览

老规矩，开局一张图：

图的顶部可以看到价值流的莫比乌斯环，从需求产生一直到线上运营，运营又会产生新的需求，持续反馈。

图的中间，价值流的各个阶段可以细化去做的事情，列举不一定全，欢迎补充。这其中很多细化赛道的系统建设细节和落地方式，跟技术架构和业务相关，比如，部署在物理机上的和部署在k8s上的业务，监控方案肯定有区别；再比如，移动端应用和web应用，灰度方式肯定有区别。在这边文章暂时不暂开。

需要说明的是：在持续交付阶段，各种灰度、回滚、扩缩容能力都是要有的，跟持续部署阶段一致，这里没有重复地写。并不是所有的业务都有交付阶段，重点写在了持续部署阶段。

图的底部，强调这是一个以长期价值为核心的事情，需要通过团队文档来沉淀信息。

如何衡量一个价值流动状态是否正常？图的右侧，就是一些参考衡量指标。比如，千行代码bug率很高，这说明过程质量不高；比如生产环境经常回滚，说明交付质量不高；发布非常耗时，说明工具或者流程需要优化啦。数据是北极星，能够体系化地暴露问题，通过科学的数据指引我们改进。

总结

文章的重点就是这张图，当我们按照价值流动的视角来规划，一切都变得有迹可循。此时再假设你是一个团队的运维leader，知道你自己该做什么了吧~