运维真的只是“背锅侠”吗？如何实现“翻身做主”？

作者：萧田国，高效运维社区发起人，AIOps标准发起人

本文为《技术运营》一书推荐序，未经授权请勿转载。

如何提高运维的地位？这是我和很多同仁苦苦思考的一个问题。运维向来处于软件生产链的后端，甚至有某百科给运维的定义就是“软件部署”。运维不就是把开发部门写好、测试部门验证过的软件，推送到服务器上去吗？这都搞不好，要你有何用！这样的运维离业务太远，因而很多时候沦为“背锅侠”，“人在家中坐，锅从天上来”。

如何改变这种现状？我们可以去和开发部门争辩，以证明我们是清白的（可是，真的能自证清白吗？）。我们可以拽着开发部门一起实践 DevOps，把可运维性（非功能性需求）前置到软件开发框架中（可是，依然容易被业务部门“鄙视”）。

还有没有其他办法呢？其实办法“远在天边，近在眼前”。运维离数据最近，我们可以通过精细的预核算及资源供应，有说服力的技术架构评审，合理的资源规划（业务指标预测、资源容量预测、资源策略与分布规划、运营优化），极致的产品体验优化及运营优化，真正为业务创造价值，提高DAU，提升公司产品的市场占有率、营收和利润。

这样的好处是什么？将“链”变成“环”。在软件生产链上，本来业务部门是头，运维部门是尾，平时没啥好聊的（除非出故障了）。当运维助力业务部门实现首尾衔接（没有中间商赚差价），让业务部门尝到了“甜头”时，那自然关系融洽，也有机会从源头上摘掉“背锅侠”的帽子。

这样意味着什么？意味着运维真的有机会“翻身做主”。在英文中，operation本来既可以是运维，也可以是运营。这样一来，运维成了技术运营，并有机会成为业务部门的一分子（例如在腾讯，应用运维就属于业务部门）。

但很多运维同仁业务场景小（服务器可能也就几百台），业务上又终日疲于奔命（各种非例行工作应接不暇），没有机会也没有精力从事技术运营相关的工作。这么美好的前景，却心有余而力不足，甚至只能“锅一直背”，影响身心健康、生活质量及家庭幸福。

幸运的是，互联网一线大厂如腾讯、传统名企如海尔，在海量资源场景下进行了多年的精细化运营实践，而且更重要的是，他们愿意分享出来，花了很多本来可以陪伴家人的业务时间，给业界呈现了本书。

《技术运营》

本书作者熊普江长期从事运维行业，在腾讯任职多年，他是我的好友，对我很是支持。早在2017年3月的GOPS全球运维大会·深圳站，熊普江就做过一个分享《运维价值新主张：精细技术运营优化》，在那次分享中他就已提及自己是如何帮助微信节省亿级成本的。从目前来看，那次分享貌似是本书的雏形。

本书作者盛国军（盛总）在海尔工作多年，也是高效运维社区主群的骨干成员，多年来对运维社区也是拳拳之心。盛总善于总结，提出三讲（讲观点、讲数据、讲案例）及三指数（体验指数、能效指数和弹性指数）。三讲即用观点指出问题的本质，用数据确保问题的客观性和真实性，用案例对成果具象化。三指数更是和技术运营的本质如出一辙。

两位作者多年的互联网企业和传统企业的工作经验，很好地融合在一起，使得本书的适用范围大大扩展。本书不再只是一本互联网行业的“自嗨”之作，更适合助力传统行业的实践落地。

即使在不久以后的 AIOps 时代，本书也不会逊色。虽然 AIOps 确实可以使技术运营更上一个台阶，但本书作为专家知识库更彰显价值，而技术运营是 AIOps 的能力来源。当然，说不定相关内容已经在作者的再版计划之内了。

非常开心能给本书写推荐序，希望读者也和我一样，从中受益良多，并付诸行动，产生实际的价值。路漫漫其修远兮，吾将上下而求索。虽然我已经不在运维第一线，但我及高效运维社区始终在服务天下运维同仁。在此谨代表高效运维社区祝贺本书顺利出版发行，让运维同仁得以享受大厂福利。