关于运维工作如何提效给您一下建议

网络时代来临让很多相关岗位人员的工作越来越繁复枯燥，当然也越来越具有挑战性。运维工作人员也避不开这个问题。如何提高效率成了大家经常探讨的问题，许多公司的管理层都在运维提效方面有所考量，其实运维工作提效的问题可以从这几个方面来说说。比如：流程提效、工具提效、质量提效、工程提效等等。下面分享一下具体想法，希望对从事运维工作的您有所帮助。

提效工具：这个话题其实挺大，应该是管理层看到了一些问题也真的是想去解决，所以才发起这么个脑爆。首先，我个人很肯定这种方式，公司终于有意识在真正的向下求解，虽然没有360度闭环考核，但也终于不再一味向外寻求解决方案。这种方式可以定期多组织，因为，凭一时收集，不一定能想起来容易漏，问题也是逐步变化的。

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

工具提效，在传统公司越来越被重视，但重视度有待商榷。真正伟大的公司在技术和文化的投入是很舍得花钱花时间。工具提效讲究两点：做的人要懂，更要执着。从问题中来，最终回归到问题中去。做的人在问题中深受煎熬，最后受不了，跳出来，做了一套工具，甚至一套解决方案，解决了公司痛点，甚至行业痛点。像 Ansible，slatstack，jumpserver，k8s 等工具都是一样的，他们提供的解决方案被行业接受，所以也能得到社会的回馈。

质量提效：质量管理不在我们的管理范畴，我们不做过多讨论，问题大家都看的到，不做无意义讨论。工程提效：工程提效很关键，是所有事情的源头。公司也付出了很多，比如多技术栈合并，统一架构推广，全面拥抱容器。大的战略层面是够了，但中层的腰部力量明显薄弱。各部门的 KPI 割裂，同样的容器化项目，还要分2个。容器化是一个部门的，上线成功是另一个部门的。为了 KPI 而 KPI，为了 OKR 而 OKR，这个锅建议高层自我反思。

闭环不够看似事故总体汇总到 PM，完整闭环，但实际效果和老板关注度有很大关系。业务分级定位，这么多业务，到现在还没有星级打标，什么星级匹配对应的资源和支持。一直没有，谁先来谁优先。谁占坑时间长，谁优先。谁会喊谁优先。

以上是我们对提效的方面给您的建议，当我们拥有共同价值的时候，都会朝着共同的目标而努力。价值是认知定义，共同是全体认同。如果您想了解更多关于运维的信息，请您及时关注中培教育。