运维百家讲坛第5期：度小满陈存利 - 20年老“司令”聊运维、绩效、成长

陈存利@度小满 2023-03-02 08:06:10

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

这一期我们邀请到的是陈存利，度小满金融系统运维部总经理，20多年的职业生涯中绝大部分时间在互联网领域。在百度运维部期间由于带队风格过硬，兄弟团队称其为”陈司令”。今天我们请到“陈司令”来聊聊他的观点。

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

问题预览

您很早加入了百度，后来随度小满独立，我们了解到您身边有许多员工其实是很长时间一直跟随着您，经历了很多业务的运维考验，相信大家都很感兴趣，在运维这个辛苦的岗位上，如何能凝聚一群人一直走下去，想听听您的心得。
很多人认为工程师不写代码就没有价值，这个问题你怎么看？对于不写代码的工程师应该如何持续提升自己，你有什么建议吗？
您在百度和度小满经历了大小很多业务的发展和起伏，您认为不同阶段和不同体量的业务运维在理念和方法上有没有什么差异？是否有一些原则性的方法论指导做出决策？
您觉得当下，运维行业有没有哪些普遍做法其实是错的？为什么？
当下一些火热的技术方向，包括FinOps、可观测性、chatGPT等，您对这些技术方向的发展有什么看法，是炒概念还是有真价值，运维人员是否应该做出什么样的应对举措？
随着云的发展，传统的只做Ops的运维岗位长期来看必将消亡，您是否认可这个观点？对于这类朋友的转型路径您有没有什么建议？
很多朋友在脉脉上吐槽公司绩效打分不公平，您对他们有没有什么建议？另外您作为管理者，能否分享一下您是如何设计绩效考核机制的？

采访实录

问：您很早加入了百度，后来随度小满独立，我们了解到您身边有许多员工其实是很长时间一直跟随着您，经历了很多业务的运维考验，相信大家都很感兴趣，在运维这个辛苦的岗位上，如何能凝聚一群人一直走下去，想听听您的心得。

答：我理解你们这是在夸奖我，我深表感谢。

2000年创业做计算机培训开启了我职业生涯，后又在国企工作3年，2004年在北京开启我的互联网相关工作生涯。回顾我20多年职业经历，很多都是从零组建团队，因此运维类部门里工作过的同事应该超过千人，和我并肩打过几次硬仗的兄弟也有300-400人，18年在小满，再次从零组建了现在的团队，一直走到今天。其实每次离开原有团队和同学从零组建新团队是痛苦和伤感的事。但看到很多过去的同仁，现在的工作和生活状态都很好，部分人离开我的团队后自己挑战行业极限非常成功，当然赚的也比我多，我内心也替他们高兴。

如果说我带团队有啥特点，我总结有3点：

首先，我们很重视团队文化。每个新人入职的第一天就告诉他们我们团队的愿景要成为是“全球顶尖的技术保障团队”，团队核心成员的梦想是“用技术重新定义服务保障，让服务保障更简单”。我们招大家来不是来填坑的，招大家来就是为了改变，用技术去改变现实工作中的不合理之处。有个小故事对我个人影响很大，今天也分享给大家：北方的早晨，母亲送孩子去上学的路上等红绿灯，这时旁边一位清洁工老人在辛勤的工作，这时母亲为了教育孩子说：“你看清洁工爷爷他们每天那么辛苦，你可得好好学习，学习不好长大了就只能当清洁工扫大街了。”同样场景，另外一位母亲教育孩子的语言就很触动我，她说：“孩子，你看清洁工爷爷每天很辛苦，你要好好学习，将来发明出扫地的机器，让所有人不要再辛苦的人工清理街道”，这个故事很触动我，有些岗位的工作总是需要人去做的，我们做了就要做得不一样，要用技术去改变它，让未来的人不再那么难。
其次，我们很注意人才的培养，分阶段不同方式的来培养。我们认为工作都是人来做的，只有提升这些人的能力才能做出不一样的工作。我在2015年的时候总结了一套5-7年工程人才的培养机制。这套机制里边把人分做3个阶段，第一阶段是刚入职场的人，这类人前两年主要历练工作方法，技术深入的能力和成功的经历，这里每一项都很重要。随后他们将进入第二个阶段，我们会通过2-3年提升综合视野和实践能力，现在的计算机工程涉及太广，从网络到操作系统，到内核再到应用和数据库存储等等，一名优秀的工程师在架构设计和故障排查时应当每个方向都有所涉猎，如果只看材料没有实践的经历，会到处碰壁，在这个阶段我们会有计划的让人员轮岗，每个方向都历练一段时间，当然也会征求他们个人的意愿，通过轮岗历练后，我们认为这些人技术通常不是问题，那么就进入第三个阶段，在第三个阶段我们会和他们协作，让他们选一个自己喜欢并擅长的方向，一起去挑战行业极限，共同一起成长。当然，这个阶段离开的人也会比较多，因为他们能力强了，在外面也很容易获得有挑战且自己喜欢的方向，通常回报也会非常好，我常跟他们说，你们很多人未来都会比我走的更远，到时别忘了我们，做事要积极、正向，别给我们一起奋斗过的团队和人丢脸。
最后，我们很关注团队人员的多样性和协作。复杂的工作通常都不是一个工种可以独立完成的，我们把运维看做是一种技术保障，要想做好这个保障，必须从运维场景分析、运维能力提升、运维产品创新开始，对应的产品、研发，运维，运营是都必不可少的。这就好比军队的一个特战队，要有通讯员，卫生员、火力小组，狙击小组等，要根据团队需求寻找合适的人，并保证他们的协作效率，要在实践和团建中建立信任，做到坦诚相待。

问：很多人认为工程师不写代码就没有价值，这个问题你怎么看？对于不写代码的工程师应该如何持续提升自己，你有什么建议吗？

答：这个话题可以参考军事管理，大家给我一个绰号叫“司令”，这可能跟我工作中喜欢经常用军事的方法来做参照物有关，在我看来，这个问题就和军人要不要上战场开枪是一个道理：军人要懂基本武器的使用，最好还有定期的锻炼，当然也不是所有的军人都拿武器去拼命才能打胜仗，打仗打的是后勤补给，打的是武器的先进性，打的也是正义，不论做后勤、做武器研究、还是做宣传的人，都是战争必不可少的一部分，但无论在哪个岗位，都应该把岗位职责做到极致，剩下的要交给战争的指挥者。所以回到这个问题上，我理解工程师首先要了解好自己岗位在公司的定位，再结合个人自身的定位，尽量做到二者匹配，如果不匹配的话，还是换到匹配比较好。

问：您在百度和度小满经历了大小很多业务的发展和起伏，您认为不同阶段和不同体量的业务运维在理念和方法上有没有什么差异？是否有一些原则性的方法论指导做出决策？

答：这是一个很好的问题。不同体量的工作遇到的困难是完全不一样的，维护10000台机器面临的困难和维护100台机器面临困难完全不一样。

在维护100台机器的时候，我们可能还不太需要一个快速发现机器故障并自动修复的工具，因为按行业机器故障率，靠体力就可以完成，且人们会觉得刚刚好，既不是很累，又有事干；但维护10000台机器的时候，如果只依赖人工，每台机器的巡检就忙不过来，再加上跟供应商和业务协调维修时间，我们会忙到忘记吃饭。所以我给的建议是如果想生活和工作做好平衡，小公司就很好，如果要提升自己的技术能力和视野，肯定要去大规模大流量，这样才能锻炼自己。

再谈另外一个话题，业务在不同的发展阶段有不一样的业务目标，那对应的运维的理念和方法也有很大的差异。很多公司初期能活下来就不错了，他们会希望快速部署上线，因为业务得抢市场，只有先活下来才能继续发展，所以很少考虑长远的规划。这个时候运维上来就跟老板说，我们应该考虑未来十年的业务增长，结合业务增长需求来构建基础设施，这是不现实的。但如果一个业务已经有了几百万，甚至几千万的核心用户，那么大概率业务会关注最终用户的体验，此时运维要围绕用户的最终体验来设计整个底层架构和设施，所有提升用户体验的工作都会获得老板的支持。当然老板还会关注投入产出的成本，是否可持续（业务增长速度和资源投入的比率）等其它问题。还需要注意的是，不同行业间差异也很大，比如金融和互联网之间，就存在巨大差异。

总结起来可以概括为：技术是服务业务的，所有能够帮助业务发展的技术，都会获得资源的支持，无论什么工作，都需要从“如何让公司变得更好”这一角度出发思考，公司好，你才会好，你所在的团队好，你才能好。

问：您觉得当下，运维行业有没有哪些普遍做法其实是错的？为什么？

答：我暂时没有深入的思考过行业有什么做法是不对的，每家都有自己的现实问题，不好评价。

不过，有一点我想提一下，我从没有把自己限制在运维工作上，运维是我擅长的领域，是帮助公司守住用户基本连接体验的基础，但我通常更关注公司的业务现在急需什么？公司最核心的用户他们需要什么？他们需要什么我们就优先做什么，因为在我的视角里，保障服务稳定的工作，每家公司都欠了非常多的债，需要慢慢还。

问：当下一些火热的技术方向，包括FinOps、可观测性、chatGPT等，您对这些技术方向的发展有什么看法，是炒概念还是有真价值，运维人员是否应该做出什么样的应对举措？

答：我个人觉得这些方向都很好，如果大家只放在嘴上谈谈，那就是炒概念，只有实际做出来，才是先进的生产力。这些内容过去在百度时就做出不错的效果，或许在一个体量很大的环境里更容易实现，因为对应的数据量、人才厚度都会更充足。但如果有人只有100台机器，还谈FinOps，那可能真是炒一炒概念，其他也同理。

问：随着云的发展，传统的只做Ops的运维岗位长期来看必将消亡，您是否认可这个观点？对于这类朋友的转型路径您有没有什么建议？

答：运维的岗位不会消失，需求也会越来越重，但是否是人来做确实需要好好想想了。

一个软件工程中，运行维护是非常关键的环节，但这个环节是人来做，还是机器来做，要看科技的发展，就跟上面谈到的扫大街一样，只要有大街在，有人生活，扫大街这个需求是不会消失，且很旺盛，但替代的可能是无人的机器，现在已经逐渐替代为由人驾驶的扫路车。我们要意识到这一点，同时也要认识到另外一点，运行维护是一个极其复杂的事情，它远比扫路复杂，从云服务这么多年的成熟过程大家就能感受到，这是一个漫长的过程，我更建议这个运维自己革自己命的过程，由运维自身来主导和设计，最终我们会成为“运营维护”这个产品的拥有者。

问：很多朋友在脉脉上吐槽公司绩效打分不公平，您对他们有没有什么建议？另外您作为管理者，能否分享一下您是如何设计绩效考核机制的？

答：这个话题比较敏感，也是运维同学非常期待讨论的话题，所以下面观点只是我个人职业生涯的经验，不代表任何公司观点。

以下是我个人感悟，绩效是自己赚来的，谈你绩效好不好，就要看你为公司带来多少突出的业绩贡献，你通过自己努力让自己的本职工作发生哪些质的变化，绩效通常是相对的排序，因此是相对公平，很难做到绝对的公平。

我们在谈论绩效的时候不妨和公司的老板们换位思考下，一个是为公司赚钱的，一个是为公司守住基本用户体验花钱的，只有赚来更多钱才能给大家发工资，因此结果显而易见。

当然这也和大家吃的苦不一样有关，有人说人生有五种苦，第一种是体力的苦，强调拼加班，很多传统运维工作都能吃这个苦；第二种是思考的苦，拼的是你布局的周密性，做事的精细程度；第三种是耐得住寂寞的苦，要一个人不断的默默的学习很多知识，人家吃喝玩乐的时候，他自己耗费了大把时光在不断地学习新知识；第四种是尊严的苦，为了陪客户老脸都不要，见谁都是自己的祖宗一样点头哈腰的伺候；第五种可以让大家去猜一猜。不要说自己什么苦都能吃，不同角色吃的苦不一样，有个好的心态是身体健康的基础。

最后，我祝愿大家都能通过自己的努力获得好的绩效。以上观点只是我个人经验，不代表任何公司。

扩展阅读

SRE的烦恼，我们懂

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