写点什么

度小满陈存利:20 年老“司令”聊运维、绩效、成长

  • 2023-03-13
    北京
  • 本文字数:4329 字

    阅读完需:约 14 分钟

度小满陈存利:20年老“司令”聊运维、绩效、成长

作者的话:我们观察到:国内运维行业,不同的公司做法差异巨大,从业人员水平参差不齐,缺少普遍性行业认知,难以形成合力(这也会让 To B 的产品异常难做,不利于行业整体发展),甚至在部分公司,运维人员处在技术鄙视链最底层,我们希望为行业带来一些新的思路和发展推动力。


这需要很多行业老炮一起,输出观点,共同碰撞,才有可能形成一些先进的共识,形成行业前进的思想旗帜。所以,我们准备策划《运维百家讲坛》这么一档栏目,诚邀 100 个运维总监(或更高)级别的老炮,通过采访或约稿的方式输出他们的观点,给行业一些借鉴。


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


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


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


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


如果说我带团队有啥特点,我总结有 3 点:

  • 首先,我们很重视团队文化。 每个新人入职的第一天就告诉他们我们团队的愿景要成为是“全球顶尖的技术保障团队”,团队核心成员的梦想是“用技术重新定义服务保障,让服务保障更简单”。我们招大家来不是来填坑的,招大家来就是为了改变,用技术去改变现实工作中的不合理之处。 有个小故事对我个人影响很大,今天也分享给大家:北方的早晨,母亲送孩子去上学的路上等红绿灯,这时旁边一位清洁工老人在辛勤的工作,这时母亲为了教育孩子说:“你看清洁工爷爷他们每天那么辛苦,你可得好好学习,学习不好长大了就只能当清洁工扫大街了。”同样场景,另外一位母亲教育孩子的语言就很触动我,她说:“孩子,你看清洁工爷爷每天很辛苦,你要好好学习,将来发明出扫地的机器,让所有人不要再辛苦的人工清理街道”,这个故事很触动我,有些岗位的工作总是需要人去做的,我们做了就要做得不一样,要用技术去改变它,让未来的人不再那么难。


  • 其次,我们很注意人才的培养,分阶段不同方式的来培养。 我们认为工作都是人来做的,只有提升这些人的能力才能做出不一样的工作。我在 2015 年的时候总结了一套 5-7 年工程人才的培养机制。 这套机制里边把人分做 3 个阶段,第一阶段是刚入职场的人,这类人前两年主要历练工作方法,技术深入的能力和成功的经历,这里每一项都很重要。随后他们将进入第二个阶段,我们会通过 2-3 年提升综合视野和实践能力,现在的计算机工程涉及太广,从网络到操作系统,到内核再到应用和数据库存储等等,一名优秀的工程师在架构设计和故障排查时应当每个方向都有所涉猎,如果只看材料没有实践的经历,会到处碰壁,在这个阶段我们会有计划的让人员轮岗,每个方向都历练一段时间,当然也会征求他们个人的意愿,通过轮岗历练后,我们认为这些人技术通常不是问题,那么就进入第三个阶段,在第三个阶段我们会和他们协作,让他们选一个自己喜欢并擅长的方向,一起去挑战行业极限,共同一起成长。当然,这个阶段离开的人也会比较多,因为他们能力强了,在外面也很容易获得有挑战且自己喜欢的方向,通常回报也会非常好,我常跟他们说,你们很多人未来都会比我走的更远,到时别忘了我们,做事要积极、正向,别给我们一起奋斗过的团队和人丢脸。


  • 最后,我们很关注团队人员的多样性和协作。 复杂的工作通常都不是一个工种可以独立完成的,我们把运维看做是一种技术保障,要想做好这个保障,必须从运维场景分析、运维能力提升、运维产品创新开始,对应的产品、研发,运维,运营是都必不可少的。这就好比军队的一个特战队,要有通讯员,卫生员、火力小组,狙击小组等,要根据团队需求寻找合适的人,并保证他们的协作效率,要在实践和团建中建立信任,做到坦诚相待。


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

2023-03-13 14:316950

评论

发布
暂无评论
发现更多内容

计算机的时间

伴鱼技术团队

分布式 服务器 技术交流

码农远程办公指北

大伟

如何用一台电脑制作一部动画短片?

zhoo299

动画 CG

Vol.3 人工智能这么热,你必须知道一点儿!

pyfn2030

人工智能

那些会阻碍程序员成长的细节[1]

MavenTalker

程序员 职业规划

Vol.6 几个数据库相关的词

pyfn2030

数据库 大数据 新手指南

Dataway 4.1.5 以上版本升级指南

哈库纳

string StringBoot Dataway Hasor

系统服务化构建-两方OAuth

图南日晟

微服务 软件工程 身份认证 架构设计

原创 | 使用JUnit、AssertJ和Mockito编写单元测试和实践TDD (十)在项目中准备测试环境

编程道与术

Java 编程 软件测试 TDD 单元测试

绝了!Dataway让Spring Boot不再需要Controller、Service、DAO、Mapper

哈库纳

StringBoot DataQL

说到做到

Yukun

拖延症

艺术生,我劝你Mac

zhoo299

Mac CG 艺术

免费领课的活动你错过了么?

池建强

极客时间

Vol.4 了解一下渗透测试

pyfn2030

黑客 网络安全

Vol.5 Go初探,新手必看!

pyfn2030

编程语言 新手指南

使用SpreadJS 开发在线问卷系统,构筑CCP(云数据采集)平台

葡萄城技术团队

数据挖掘 大数据 SpreadJS CCP

ARTS-WEEK01

子路无倦

ARTS 打卡计划

自己常用的一些快捷键 windows10

halapano

Windows技巧

从 0 到 1 搭建技术中台之技术文化篇

伴鱼技术团队

企业文化 技术管理

【快点查查】微信小程序使用流程

tomatocc

Dataway 整合 Swagger2,让 API 管理更顺畅

哈库纳

Spring Boot DataQL Dataway Hasor

Vol.2 谷歌不只有搜索

pyfn2030

谷歌Google

Gartner 【RPA市场竞争格局】:中国厂商首次进入国际视野

人称T客

AB 测试平台的设计与实现

伴鱼技术团队

架构 系统设计 后端 A/B

《程序员的数学》笔记

Rex

读书笔记

无需代码!通过 Dataway 配置一个带有分页查询的接口

哈库纳

spring springboot Dataway Hasor

Dataway 配置数据接口时和前端进行参数对接

哈库纳

Spring Boot DataQL Dataway Hasor

Anaconda与虚拟环境

halapano

Python virtualenv Anaconda

代码简洁之路 [持续更新]

hq

Java 大前端 编程习惯

Wi-Fi p2p & ap 共存

贾献华

wifi p2p ap

完美兼容老项目!Dataway 4.1.6 返回结构的全面控制

哈库纳

spring Spring Boot Dataway Hasor

度小满陈存利:20年老“司令”聊运维、绩效、成长_产品_秦晓辉_InfoQ精选文章