运维百家讲坛第6期：途游邹轶 - 中小公司的运维怎么做？

运维百家讲坛，通过采访和约稿的方式，请运维领域老炮输出深刻洞见，共同碰撞，以期形成一些先进的共识，推动行业更好得前进。

这一期我们邀请到的是邹轶，途游游戏运维总监，邹总经常戏称自己是世界500万强企业的运维代表，可见内心中是觉得中小公司的运维建设思路和大型企业是有差别的，今天我们带着几个问题，来请邹总分享一下他的中小公司研运一体化之路。

这里是接地气、有高度的《运维百家讲坛》第 6 期，开讲！

问题预览

• 途游是游戏公司，您觉得游戏运维有哪些独特性？面临的最大运维挑战是什么？您又是如何解决这些挑战的？
• 游戏运维的人才技能是什么样子的，如果想在游戏运维方向发展，您对职业路径规划上有没有什么建议？
• 中型公司的运维团队通常不会很大，您是如何对这有限的人力排兵布阵的，有没有什么心得可以分享给大家？
• 您是否会遇到因为团队人才水平不行，导致自己的想法落地慢，落地难的问题，您是如何解决的？
• 您说您特别认同《运维的未来是平台工程》文章中的观点，您的团队也是一个产研式的全功能组织，想请您介绍一下：对于业务研发，相比直接使用云厂商提供的平台产品，您这个团队带来的Delta增益是什么？
• 您经常说成本节省要硬桥硬马，节省了大量成本，公司给发个奖状，说明这个FinOps的项目大概率是在自嗨，在云上、云下Infra建设上，您的团队为公司带来了巨额成本节省，而且得到了公司的物质奖励，能否分享一下相关的心得？
• 运维团队一直是站在公司业务的后面，离业务的距离相对远，对如何更好的支持业务，或如何说明运维对业务的价值这个点，您有什么建议？

采访实录

问：途游是游戏公司，您觉得游戏运维有哪些独特性？面临的最大运维挑战是什么？您又是如何解决这些挑战的？

整体游戏运维架构相对传统互联网业务来比较，相对简单，但是单机可靠性要求比较高，运维日常工作，相对事务性的工作较多，比如开服合服等等。 面临最大的运维挑战，其实不是技术层面的，更多的是价值认可度层面的，怎么让我们业务部门认可我们的价值，这个挑战我相信也是整个运维赛道同仁们一致的挑战。要去赢得业务部门的认可，提升运维团队的价值，从我以及我团队的实践来总结，其实就是一句话：扎扎实实的做好服务，以业务部门/用户为中心。

问：游戏运维的人才技能是什么样子的，如果想在游戏运维方向发展，您对职业路径规划上有没有什么建议？

游戏运维的人才技能和传统互联网行业没有太大的区别，对于运维这个赛道来说，认知比较低和缺乏体系的成长环境，是我们中小厂运维面临的比较现实的问题，我们常年和机器底层打交道，很少去认真思考过，未来10年，15年后的发展，更多的是追逐热点，追逐变化，很少去思考沉淀那些不变的内容，以及怎么去利用这些内容来做时间的朋友形成自己的竞争力。我个人建议中小厂的运维同学，还是要在理论方法论学习和技能提升两手抓，用理论指导实践，通过实践完善自己对理论的理解。学习理论和方法这块，我也提几点建议：

1. 持有开放的心态去学习，ITIL，SRE，lean, scrum，平台工程，可观测等等，不要纠结于门派之见，只要对自己有价值的内容，都可以去学习去吸收融合，比如ITIL抓住变更管理、故障管理、问题管理、持续服务改进，这几个流程去学习并应用于实践，其实就能解决好大部分运维问题。又比如对SRE的理念的学习，抓住SLO的理念，开展可靠性建设，引导业务部门与运维团队建立一个可靠性目标共担的协作模式。而在实践的SLO落地的过程中，又可以引入可观测性理念和方法，来加强自己对可观测性能力的建设。
2. 面向国外科技公司学习为主，面向国内大厂学习为辅，国外科技公司的理论和工程方法相对严谨和体系，不太受场景限制，可以学以致用，国内的大厂更多偏向于特殊场景的实践，理论和工程方法抽象不够，基本上都是万亿并发，千亿流量的场景，其实和中小厂的运维没啥关系，中小厂去深度对标学习，价值杠杆率不高。

问：中型公司的运维团队通常不会很大，您是如何对这有限的人力排兵布阵的，有没有什么心得可以分享给大家？

有限的资源，往往容易激发创新，团队规模可以不大，但是要保持精干、敏捷，换句话说就是你团队要足够能打，而且应对不确定性能力要强，要想达到这个效果，我个人总结了我们这5年的组织能力建设实践：

1. 人才结构要做深度优化，要引入专业产研人才，用产研驱动团队价值输出。目前途游的运维安全团队，产研和传统运维比例接近1:1。
2. 研运一体化的组织模式去构建，要形成一支全职能，端到端的混合型团队。目前的途游的运维安全团队，有产品经理、研发负责人，前，后端工程师，服务运营工程师，运维工程师，IT工程师。
3. 围绕互信、目标一致、信息共享、去中心化去构建敏捷的文化氛围。通过敏捷的文化氛围，来形成一支能应对不确定性的敏捷组织。

关于敏捷组织的实践，可以看我的分享：https://tuyoo.feishu.cn/docs/doccnFlAD2m7WnSpcLYxFJRImZb

问：您是否会遇到因为团队人才水平不行，导致自己的想法落地慢，落地难的问题，您是如何解决的？

这个肯定会遇到，我们解决思路：

1. 保持耐心，对团队持续迭代，这个就和打牌一样，你不能期望上手一手好牌，这个都得不断的进出的换牌，最后把牌理顺去赢得比赛。
2. 对新人的标准是潜力要高于团队现有70%的人员，不符合标准宁可不招聘，招人谨慎，对人的培养才会用心。
3. 团队负责人自己一定是团队首席HR，要主动出击去找人才，我最近4年在BOSS直聘上大概聊过接近两万人吧，看过的简历应该超过2万多份，这个可能很难有中小公司的运维负责人会做到这点。
4. 利用敏捷组织作为基础支持，发挥集体智慧。

关于我团队转型实践分享：https://tuyoo.feishu.cn/docx/doxcnGMuijglK6NdENYC2vD7KKh

问：您说您特别认同《运维的未来是平台工程》文章中的观点，您的团队也是一个产研式的全功能组织，想请您介绍一下：对于业务研发，相比直接使用云厂商提供的平台产品，您这个团队带来的Delta增益是什么？

在回答这个问题之前，我还是想阐述下我们对造轮子和外采服务的认知：

我们其实对外采还是自研，蛮开放的心态，也是蛮简单的判断，就是看ROI的投入产出比，标准化的，投入巨大的，自己搞不定的肯定是尽量用外部三方的服务或者产品来帮助我们解决问题，我们更关注的是如何服务好我们的业务部门，关注我们提供的服务结果和质量，不太关注这个能力是我们自己具备的还是三方的服务能力，只要能帮助我们提升服务质量和效率的，我们都非常开放的心态去吸收和融合。

再来回答这个产研团队对我们的增益问题，每个公司都有它本身一些特性或者定制化场景需求，这些东西外来产品肯定不能完全覆盖到位，所以这样的一支端到端的团队，其实是让整个团队有了解决一些非标问题的能力。这种能力其实非常关键，很大程度决定了团队的价值实现。

另外再来说说我们对运维的未来是平台工程的理解，我对平台工程的理解有两点关键要素：

1. 平台工程面向的对象是以业务部门为主，而不是运维为主
2. 平台工程提供的是自服务，平台工程输出的产品和工具一定是业务部门自服务为主

我们团队转型探索，就是主要按照这两个要素来做的实践，但是理论水平不够，没有清晰的去提出平台工程的理念。我们游戏运维有一个蛮大的痛点就是琐事很多，比如CDN的上传发布，游戏的配置更新，例行起停服，都是游戏运维日常的事务，不可或缺，但是都是事务性的，价值很低，可能在我们游戏运维的常识里面，我们会想到做一些自动化的工具，去提升运维的人效，把运维从人肉或者写脚本的状态，变成WEBOPS状态，这个感觉杠杆率还是太低，并没有把运维释放出来，所以在解决这些问题过程中，诞生了我对平台工程理念的原始理解，目前我们游戏运维的日常事务性工作有50%都是项目组自服务，通过我们提供的工具，这在我们接触平台工程的理念后，发现是高度认知一致的。所以对运维的未来是平台工程，我相信只要尝过自服务的甜头，吃过人肉运维的苦的同学，应该都会有很深的认同感。

问：您经常说成本节省要硬桥硬马，节省了大量成本，公司给发个奖状，说明这个FinOps的项目大概率是在自嗨，在云上、云下Infra建设上，您的团队为公司带来了巨额成本节省，而且得到了公司的物质奖励，能否分享一下相关的心得？

对于FINOPS这件事，平时也和行业一些专家老师做过一些交流碰撞，结合我们团队自己的实践，我个人感觉FINOPS实践落地难，难在改变老板的认知，目前行业还是偏技术实现或者理念碰撞阶段，还停留在比谁更专业，更规范的阶段，个人感觉不能影响到老板认知的FINOPS，基本都是无价值，或者价值极低，做和不做没啥区别。对于FINOPS这个领域不过多评价，我们缩小到成本优化这件事来讲，在我们团队我没有设定过成本优化的OKR，我们一直用精益的理念在指导开展工作，精益有一个核心的理念，一切不产生价值的都是浪费，持续消除浪费， 这样在工作开展过程中，其实就不用搞运动式的成本优化。很多省了几个亿的成本优化，可能在老板眼里就是应该的，以前浪费太大了，现在只是消除浪费，这自然就不会得到价值认可。

成本优化实践过程中我个人总结了几点：

1. 要用精益的理念去持续指导成本优化，而不是简单的运动式降本增效。
2. 要拉齐价值共识，要和相关部门比如总办，财务等监管部门达成共识。
3. 成本优化的计算模型不能太复杂，模型计算太复杂，很难去达成共识。
4. 数据要统一按照财务口径进行核对，不能我们从技术角度想当然。

编者按：邹总做成本优化，具体节省多少钱是经过财务最终测算的，个人觉得很值得借鉴，很多公司的成本优化，都是自己测算的，缺乏公信力，老板较难有体感。

问：这是老问题了，运维团队一直是站在公司业务的后面，离业务的距离相对远，对如何更好的支持业务，或如何说明运维对业务的价值这个点，您有什么建议？

具体怎么去体现价值，我建议运维团队要想体现价值，首先是要有服务意识，然后是要对服务体系进行建设，再就是保持耐心和持续改善，通过这个去形成一个正循环，从而把时间做朋友。

在这块我简单分享下我们团队的服务体系建设指导纲要。我们以客户为中心，构建安全、可靠、高效、低成本、可持续的服务。通过服务运营输出价值，通过产品和工具落地服务运营，并持续改善。在这个指导纲要中，我们将团队里的运维、产研和运营三个职能角色进行了深度融合。通过服务运营的输出来把价值进行体现。很多时候，做技术的人往往不太容易意识到服务运营的重要性，我们常常听到人们谈论技术运营和产品运营，但很少有人谈论服务运营。这与我们做技术出身的惯性认知有很大关系，更多的是站在自己专业领域去表达，很少去站在我们服务对象的角度去看我们的价值。很多人提到服务可能就会简单联想到端茶倒水、跑腿这种角色，比较排斥提服务。但实际上，每个团队都是服务型团队。比如我们服务项目组，项目组服务我们最终的用户，我们的最终用户可能是在他的工作领域服务其他客户。因此，提供服务是一件非常重要的事情。只有服务好了客户，帮助他们获得结果，才能真正体现自己的价值。

扩展阅读

• 运维百家讲坛第5期：度小满陈存利 - 20年老“司令”聊运维、绩效、成长
• 运维百家讲坛第4期：又拍云邵海杨 - 25年Linux老兵聊DevOps八荣八耻
• 运维百家讲坛第3期：来炜 - 如何把运维的饭碗端稳
• 运维百家讲坛第2期：作业帮聂安 - 运维如何转型，听听作业帮的OPaS思路
• 运维百家讲坛第1期：井源 - 运维几何

SRE的烦恼，我们懂

我们观察到很多公司都搭建了林林总总的监控系统，但是不成体系，故障定位不够快，老板很焦虑。我们提供的Flashcat平台通过集成这些既有的数据源，提供业务、技术双视角的全局稳定性视图和驾驶舱，让监控、可观测性体系化落地，出现问题也能快速定位，彻底去除故障焦虑。如果您有类似痛楚，快来填写表单，联系我们交流试用吧！