运维提效该怎么做？学会这4种思维，你就厉害啦~

大家好，我是史丹利「Stanley」，今天聊聊运维提效。

最近CTO在梳理公司提效方案，老板希望我能多提点建议看法。因为，刚巧在梳理本周的 k8s 技术分享，所以临时写了点，大家也多提自己的想法看法，我一并提交，如果届时落地有好的效果，我一并回馈给社区。在此先谢过。

提效工具

我的回复如下：

这个话题其实挺大，应该是管理层看到了一些问题也真的是想去解决，所以才发起这么个脑爆。

首先，我个人很肯定这种方式，公司终于有意识在真正的向下求解，虽然没有360度闭环考核，但也终于不再一味向外寻求解决方案。这种方式可以定期多组织，因为，凭一时收集，不一定能想起来容易漏，问题也是逐步变化的。

回到提效这处话题，我的理解提效有几个维度：

• 流程提效
• 工具提效
• 质量提效
• 工程提效

流程提效

最短路径

流程是双刃剑，大家都知道。流程的本质，我的理解是通过建议规章约束把最初的用户愿景以最短的路径且高品质的传递给工程端，并由工程端高品质无差别的高品质交付。重要的是交付链条足够短，交付品质足够高。

但流程提效，正确的角色是辅助，不应该是ADC。咱们诺亚前面遇到了很多问题，迫于压力，只能把流程提效和工具提效的角色互换，通过抑制需求，解决故障多的问题。在当时的场景下，是必然也是最优解，这毫无疑问。短时间行，长时间不行。如果要做互联网产品化的金融，要改的地方很多。虽然公司在oa改造发力很多，但要努力的地方还有很多。诸如oa这些的，咱们CICD流程相对完善，但要做的还有很多。比如，发布日的art项目已经推送到平台，代表已经过审，但仍要逐项目举手，意义真的很重要？项目提测的关闭窗口总在变，更没人严格执行，原由很简单，人员变动太，文化没有被传承。但这是各公司都会存在的问题，所以有很多伟大的技术产品出现，解决了很多工程学中人为因素的难题。比如git解决了版本控制，比如springcloud解决了java开发的架构拓扑能力。k8s解决了运维的高可用，高并发，扩缩容的架构能力。

回归到本质，还是要用技术手段去解决人的因素。

工具提效

[[389111]]

工具提效，在传统公司越来越被重视，但重视度有待商榷。真正伟大的公司在技术和文化的投入是很舍得花钱花时间。

工具提效讲究两点：做的人要懂，更要执着。

从问题中来，最终回归到问题中去。做的人在问题中深受煎熬，最后受不了，跳出来，做了一套工具，甚至一套解决方案，解决了公司痛点，甚至行业痛点。像 Ansible，slatstack，jumpserver，k8s 等工具都是一样的，他们提供的解决方案被行业接受，所以也能得到社会的回馈。

我们现在使用的成熟流行工具都有一个特点：好用。但公司级的产品不一样，cicd，art等还在路上，功能都有，好用和精品有待商榷，但这不能怪我们的团队不行。公司要舍得投入钱和时间，为啥饿了么送外卖的公司，都能在前端变化万千的产品线中做出element 和 ant、vue抗衡，那也是有原因的，值得花大价钱从行业招专家。当然，各家公司有自己的定位，要视自家特色解决问题。个人觉得，我们还是缺懂运维产品的人。

质量提效

质量管理不在我们的管理范畴，我们不做过多讨论，问题大家都看的到，不做无意义讨论

工程提效

工程提效很关键，是所有事情的源头。公司也付出了很多，比如多技术栈合并，统一架构推广，全面拥抱容器。大的战略层面是够了，但中层的腰部力量明显薄弱。

• 各部门的 KPI 割裂

同样的容器化项目，还要分2个。容器化是一个部门的，上线成功是另一个部门的。为了 KPI 而 KPI，为了 OKR 而 OKR，这个锅建议高层自我反思。

• 闭环不够

看似事故总体汇总到 PM，完整闭环，但实际效果和老板关注度有很大关系。

• 业务分级定位

这么多业务，到现在还没有星级打标，什么星级匹配对应的资源和支持。一直没有，谁先来谁优先。谁占坑时间长，谁优先。谁会喊谁优先。

其它的想到我再补充

个人对提效的理解，最终都回归到一个词吧：共同价值。价值是认知定义，共同是全体认同。