大家好，我是Stanley，今天聊一聊运维效率提升。最近CTO正在整理公司的效率提升方案，老板希望我能多提建议。因为刚好在整理这周的k8s技术分享，所以临时写了一些，大家也提了自己的想法，我一并提交。如果实施的时候有好的效果，我也会回馈社会。提前致谢。我对效率提升工具的回复如下：这个话题其实挺大的。应该是管理层看到了一些问题，很想解决，才发起了这样的头脑风暴。首先，我对这个方法非常有把握。公司终于有意识地向下寻求解决方案。虽然没有闭环评估，但总算停止了盲目求解。这种方法可以更有规律地组织，因为，基于临时收集，可能不容易遗漏，而且问题是逐渐发生变化的。回到效率提升的话题，我理解效率提升有几个维度：流程效率提升工具效率提升质量提升工程效率提升流程效率众所周知，最短路径流程是一把双刃剑。流程的本质，我理解就是，通过建议的监管约束，以最短路径、高质量的方式将最初的用户愿景交付到工程端，由工程端高质量、无差别地高质量交付。重要的是交付链条足够短，交付质量足够高。但要提高流程效率，正确的角色是辅助，而不是ADC。诺亚以前遇到过很多问题。压力之下，我们只能互换流程效率提升和工具效率提升的角色，通过抑制需求来解决很多失败的问题。在当时的场景下，这是必然的最优解，这是毋庸置疑的。很短的时间，但不会很长时间。我们要做互联网产品金融，需要改变的地方有很多。虽然公司在oa转型上做了很多努力，但还有很多工作要做。像oa这样的东西，我们的CICD流程已经比较完善了，但是要做的还有很多。比如发布当天的美术项目已经推送到平台，代表们也通过了审核，但还是要一一举手。意义真的很重要吗？项目测试的关闭窗口总是在变化，没有人严格执行。原因很简单，人事变动太多，文化没有传承。但这是每个公司都会有的问题，所以有很多很棒的技术产品解决了很多工程上人为因素的问题。比如git解决版本控制，springcloud解决java开发的架构拓扑能力。k8s解决了运维的高可用、高并发、扩缩容的架构能力。回归本质，还是要用技术手段解决人为因素。工具效率提升传统企业越来越重视工具效率，但重视程度值得商榷。一个真正伟大的公司，愿意在技术和文化上花费金钱和时间。提高工具的效率有两点需要注意：做的人要懂，要坚持。从问题中来，最终又回到问题中。做的人深受问题的折磨，终于受不了，跳出来，做出了一套工具，甚至是一套解决方案，解决了公司的痛点，乃至行业的痛点。Ansible、slatstack、jumpserver和k8s等工具都是一样的。他们提供的解决方案被业界所接受，因此也能得到社会的反馈。我们今天使用的成熟流行的工具都有一个特点：简单易用。但是公司级的产品就不一样了。cicd、art等还在路上，功能都有。它们是否易于使用或质量是否高尚值得商榷，但这不能归咎于我们的团队。公司必须愿意投入金钱和时间。为什么饿了么的外卖公司能在千变万化的前端产品线做出element来和ant、vue抗衡呢？招聘专家。当然每个公司都有自己的定位，要根据自己的特点去解决问题。就个人而言，我们还是缺少懂运维产品的人。质量改进质量管理不属于我们的管理范畴。我们不讨论太多。每个人都可以看到问题。不做无意义的讨论对提高项目效率很重要。它是一切的源头。公司也付出了很多，比如合并多个技术栈，推进统一架构，全面拥抱容器。大战略级就够了，但是中级的腰力就明显弱了。每个部门的KPI拆分同一个容器化项目，一分为二。容器化是一个部门的，上线成功是另一个部门的。KPI对KPI，OKR对OKR，这个锅建议高层次的自我反省。闭环还不够。看似意外聚合到PM，闭环完成，但实际效果与老板的关注度有很大关系。业务分级定位的业务那么多，但是还没有星级，什么星级才匹配相应的资源和支持。从来没有，谁先到谁先。谁占坑时间长谁优先。谁先叫谁优先。其他的，我再补充个人对效率提升的理解，最后回归一个词：共同价值。价值是认知的定义，共同是对所有人的认可。
