运维百家讲坛第4期：又拍云邵海杨 - 25年Linux老兵聊DevOps八荣八耻

Posted 2023-03-20

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

这一期我们邀请到的是又拍云科技的邵海杨，一个25年的Linux老炮，邵总醉心技术，一步一步往上走，是普通运维人员的典型成长路径，希望今天的采访可以对你有那么一些启发。

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

您好邵总，请您先做个自我介绍吧，聊聊您的履历和现状，让大家更好的认识您，了解您的背景也有助于读者理解后面的采访内容

我是来自又拍云科技的邵海杨，从1998年开始使用Linux至今快25年了，资深(老鸟)Linux系统运维/架构师，DevOps八荣八耻倡导者，业余撰稿人；精通(心虚)系统优化及网络服务管理，Linux系统定制，CDN加速和安全防御; 擅长互联网高性能网络及架构设计、虚拟化KVM及OpenStack云平台, K8S容器云和Ceph分布式存储等新技术；喜欢交流分享，活跃于社区，一直积极投身于开源活动的组织和传播。

运维领域，每个公司都会制定自己的运维准则或者操作规范，能否分享一下贵司的经验，给我们一些参考？

又拍云是一家提供云存储，云分发，云处理服务的公司，也是国内首创可编程CDN 服务的专业云服务提供商，特点就是7x24全年不间断服务，所以云运维也有一些律条或原则，比如：

先保障稳定，然后再优化

过度设计或过早优化很可能会带来更多的故障停机时间，要先集中精力提高系统的可扩展性和高可用性。坚持 “先完成，再完善，后完美”，项目也是“先能用，再好用，后用好”的实施策略。

提供可靠的测试依据和时间验证

引入新技术到架构之前，要确保新技术的稳定性和足够时间久的考验，更要有运维工程化中开发出来的工具链的完整。一旦线上返工或变更造成的措手不及可能已经是故障的导火索。

使用可控的自动化手段提升效率

自动部署、自动编排、自动巡检、自动升级等自动化手段越来越多应用于云运维。这是适应云计算时代的趋势，但能力越强，责任越大，要谨慎自动化的雪崩和惊群效应，做好灰度/蓝绿部署和各种测试。

保持简单，监控一切

保持简单，别把事搞的太复杂。除了常见的异常问题报警外，面向业务指标，市场指标和销售数据，成本等都可以用来做趋势分析信息。定期的轮询查看各个趋势数据的峰值峰谷有助于见微知著。

面向预算的运维

运维团队通常是最大的花费者，因为预算不足，没有钱的运维是很难兼顾到日益增长的公司业务规模，除非公司业务已经停滞或不再有爆炸式的增长，面对这样的挑战，运维要学会降本增益，开源节流，利用新技术实现能效比的提升。

面向场景的智能运维

各种各样的负载场景，从高并发处理到视频转码，从高性能并行计算到海量的网络请求。这些不同的负载场景，对网络带宽，各种处理和IO的要求也各不相同。智能运维就是需要深入理解业务，合理配置资源和架构来满足不同业务场景的需求。

持续集成和发布系统

持续发布包括灰度发布、测试发布、滚动发布、回滚发布等多种场景，并且确保每种场景都应该是可以可控的。

确保任何人都可以被替换

铁打的营盘流水的兵，人挪活是常态，做好员工的共享文档管理和知识传递和分享，理论上所有人都可以被替换，任何人也不应该成为公司的天花板。

虽说成长是自己的事情，但如果有合适的场域、合适的项目机会、合适的团队、合适的机制，会让工程师的成长更快，团队更有战斗力，您能否系统的谈一下是如何促成运维同学的成长的？

公司一直是积极鼓励员工的技能自我提高和促进成长：

• 每月开放日：公司内技术委员会会定期举办讲座，分享前沿研究中的一些收获，要求有主题，有重点，有应用场景，最好有实例。
• 每周分享会：鼓励所有开发者定期分享新的技术，谈论他们面对的问题，或者任何别的他们正思考的东西，分享的内容会形成文档和视频存档，并根据评分给予奖金和积分激励。
• 公司悬赏项目：无论是公司还是员工自身都可以发起项目，技术委员会评审通过后，自行组队完成，根据产出文档，数据对比，技术分享后获取相应的项目奖金。申请专利还有相应的专利奖金。
• 培养个人影响力：鼓励员工通过发表文章或演讲的形式，走出去做工程经验分享、工作心得的梳理，提高个人的影响力，并根据受众的反馈给予稿费和讲师费激励。
• 订阅报刊，杂志等纸质书籍，了解最新动态。以部门为单位，配置一定的购书津贴。

又拍云运维团队内的培养包括：

• 化“天花板为托板”：把自己放在一个培养新人的管理角色，不让自己成公司瓶颈和员工的天花板，鼓励新人们去尝新和处理故障，增加自身的技能和实战经验；信任，互助，激励，他们会持续不断创造惊喜。
• 制作“自动化工具”：利用自己的经验抽象业务成程序模型，制作或培训自动化脚本的编写，提高团队的工作效率，让员工节省精力和时间去学习其它新知识；
• 承担“高精专”项目：提前准备最新知识的研究和可行性分析，整理成文档作公开培训，再交给团队去深入研究和实施，转化成生产力，积累一线经验再反馈完善文档，良性循环；
• 积极提倡“知识分享”：各种案例和“坑”都会整理成wiki文档，通过文档共享，定期分享讲座，鼓励员工撰写高质量的，可读性很强的文档，开口培训，增加感染力和自信心；
• 鼓励“参与开源交流”：公司鼓励员工走出去参与技术交流大会，闭门造车耗时耗力，不如专业的人点拨。也会有购书经费，团建活动经费，茶歇文化；

运维工程师其中一个典型的职业路径是做管理者，但管理者和资深运维要解决的问题截然不同，对于那些刚刚步入管理岗的资深运维，是否可以分享一些您的经验？

对于刚步入管理岗的运维来说，我的建议是及时梳理遗留的技术债和人才技能的盘点和培养，先打好基础，后面才能有更大的空间进步，具体可以参考我的《DevOps的八荣八耻》的分享。

• 一、 以可配置为荣，以硬编码为耻
• 二、 以互备为荣，以单点为耻
• 三、 以随时重启为荣，以不能迁移为耻
• 四、 以整体交付为荣，以部分交付为耻
• 五、 以无状态为荣，以有状态为耻
• 六、以标准化为荣，以特殊化为耻
• 七、以自动化工具为荣，以手动和人肉为耻
• 八、以无人值守为荣，以人工介入为耻

人才上技能树的盘点，主要是配合人事做好人才九宫格的划分（如果是开发或运维，把左侧的绩效换成潜力，绩效针对销售而言），考查的是管理者对员工的全方面的辨析能力，知人善用。

再结合公司的OKR目标管理来激励员工，它的优点在于聚集目标的同时，还能：

• 激励个人自驱力，鼓励员工创新和反思；
• 考查的是相对结果，鼓励有难度的挑战和突破；
• 考核的协同配合能力，鼓励员工去全方位的协调推进；

Kubernetes火了好一段时间了，很多公司也在大规模应用了，但显然，每个技术都不是银弹，无法解决所有场景的问题，这几年观察下来，您觉得哪些公司不适合上Kubernetes？能否给一个这类公司的画像，并说明理由？

虽然Kubernetes代表着目前为止的devops的最佳工程应用实践(真香)，但也不是所有场合都能应用，如又拍云的CDN边缘服务器，数据中心的日志分析平台，Ceph分布式存储就以物理机为主。所以，我建议找一些合适的场景先试用起来，如：

• 机器资源错峰空闲浪费严重的；
• CPU，磁盘和网络IO都不密集的；
• 不需要持久化存储的或抢占资源的；
• 软件架构已经做了微服务改造的；
• 业务处理程序有周期性、可弹性扩容的；

运维和研发是最亲密的伙伴，贵司是如何做工作边界划分的？另外关于如何让这两个角色保持亲密合作，是否可以分享一些经验？

运维工程师 = 冲锋陷阵的将军
软件工程师 = 坐阵帐中的军师

理论上，优秀的软件工程师是可以把部分(甚至全部)运维工程师的工作做掉，比如说业务软件性能的监控，如果程序员在程序中插入很多的钩子或探针，就可以统计出数据来，不需要运维劳心劳力的监控；比如说程序员在设计程序的时候，考虑到了分库分表，考虑到了大并发和分布式的设计，那运维就可以水平扩展机器就行；如果软件没有那么多bug，还有很多如果……但是，现实是残酷的，这种高水平的程序员太少了，尤其在中国，大家都忙于实现业务功能，连个文档甚至注释都不愿意写，更别提能够考虑这么周全了；同理，运维接触的很多是开源很优秀很成熟的软件，从中是可以借鉴知晓优秀软件是怎么设计的，比如优秀的程序，日志信息会非常详尽，我们可以通过标准的syslog或者日志去监控它，所以，资深的运维会:

• 积极参与事前的规划，配合开发做演练，自动化部署，协助架构改进
• 合理提需求，要资源，最好是有预算，做到防患于未燃
• 线上监控，故障复盘，反馈给整个团队，倒逼上下协调做改进

当然，要达到上述能力的运维管理，肯定需要潜心研究，承上启下，协调团队，任劳任怨的修行多年，到那个时候，运维就不再是对事情的结果负责，而是转变角色，主导和协调整个过程。当然，这里指的能力不仅仅是技能，还包括对业务的理解能力，站在公司管理层面对整个项目和资源的分配和把握。 因此，运维工程师其实是现实中的软件工程师的互补，因为大家的能力侧重点不同，所以大家更要团结一体，要能够打胜仗，离开谁都是不行的，这是一个共同修炼进步的过程。

最后，我的个人观点：架构师它可能不是一个人的角色，而是一个团队的统称，它可以:

• 不必冲锋陷阵，就可以纵观全局，运筹帷幄，调度所有的资源（运维架构师的功能）
• 可以带领和团结团队，高屋筑瓴，因时制宜的实现解决方案（软件架构师的功能）
• 可以把握公司业务方向和深度，洽谈合作，控制成本（业务架构师的功能）

运维需要和其他多个部门沟通协作，鉴于各个团队目标关注点未必一致，合作起来可能未必有那么顺畅，针对这个问题您是用什么招来让这个过程更加顺畅的？

其实沟通不顺畅的原因大部分在于对后果的不可预见性，你说冗余他说预算，你说架构他说工期，各有立场又各有苦衷，但就是没人对结果负责。我在工作中发现，当故障发生时，各部门的配合是空前团结，战斗力也是最强的，所以，沟通协作的关键在于：既要团队协作，也要责任分明

• 事前部门沟通时，确定好项目预期，成本，影响要素，故障后果及责任方；
• 事后故障复盘时，根据故障原因，有理有据的“甩锅”，同时要引以为戒，亡羊补牢；

比如说提供在线10W并发的能力，需要冗余带宽冗余服务器数量x2，因为预算不足减半所导致的后果及责任人；再比如软件设计不好，通过性能监控，发现指标异常的后果及责任人；当然，报警处理不及时，人为操作故障也会算到运维亦无可厚非；故障文化就是要关注问题和关注事情本身，对事不对人。大家都在故障中成长，在复盘中变强。

您觉得运维工作最重要的几个目标是什么？您是怎么落地这些目标的？

• 运维自动化；
• 监控常态化；
• 日志可视化！

这个篇幅太多了，不展开讲，可以参考《​​云运维的启示和架构设计​​》

工具选型这块，到底是自研，还是使用开源，还是使用商业产品，是如何抉择的？

又拍云通常不会重复造轮子，但一定会先用好轮子，或者把轮子改造得更加称手，选择自研往往具备了一定的开发能力，再加上某些必要原因，如：

• 找不到符合要求的开源软件，如我们自研的云处理软件…
• 开源软件有bug或者issue，社区短期内无法推进，但业务又急需，只能通过自研解决，如ats的内存泄露问题…
• 开源软件的功能特点跟公司的业务不相符合，不得不改造软件，如nginx的防盗链模块，需要与客户对接定制…
• 开源软件的设计目标过于高大上，通用性好但很臃肿，如果我们只要某个小功能点，就不需要牛刀了，如性能探针的埋点…
• 有数据保护要求，或者有隐私的场合…

越来越多的公司在迁往公有云，云原生架构下，SRE团队的核心职能是否有些变化？应该如何凸显团队的价值呢？

公有云做为IaaS基座，容器云作为CaaS中间层，云原生做为SaaS应用层，整个云生态日新月异，SRE团队的核心职能会更加注重顶层系统性的容量规划，指标监控，高可用性和分布式的弹性设计，所以跨平台跨部门的职能互补、团队协作、持续精进、勇于承担包括：

• 积极参与事前的规划，配合开发做演练，协助架构改进；
• 合理提可用性需求，冗余资源，最好是有预算，做到防患于未燃；
• 线上监控，故障分析，反馈给整个团队，倒逼上下协调做改进；

团队的价值就在于是否总是能够接受新事物，新的挑战，各施所长，不做井底之蛙，也不是温水煮青蛙，在创新或者颠覆来临的时候，也能保持不被时代脱钩。

对于运维工程师个体，SRE的转型路径是？应该注意些什么？

技术领域：

• 学会抽象业务模型，标准化组件，定制化脚本，自动化部署，提升整体效率；
• 学会收集日志和日志分析并可视化，提升运维监控和预警报警的效率；
• 掌握和熟悉一门或若干语言，能够帮助你成长，提升你的战斗力；
• 勤做笔记，温故而知新，学思结合，要学会沉淀，举一反三；
• 勇于面对新兴技术的挑战，打不过就学它；

非技术领域：

• 学习能力，要知识面广；
• 沟通方面，了解客户的精确需求；
• 技术风险、人工、进度等成本，权衡取舍；
• 社区活动，积极分享，锻炼口才和交流能力；
• 提升自己的影响力，学会与人同行，可以交到更多的朋友；

面对当下快速发展的基础技术，您对给刚入行和入行已久的运维人员，分别有什么职业规划的建议吗？

首先不是工作选择人，而是人选择工作，一个人若对某方面有了兴趣，真正用心学习了近10000个小时，其实做什么都是可以的。比如说我毕业那个时候，都是强调复合型人才，根本没有运维这个职业，我们不光自己攒(DIY)机器，自学Linux操作系统，还学习编程，折腾网络，自己动手写论坛聊天室等程序；Linux给我们带来的是每天都有创新的，好玩的，优秀的开源软件让我们保持激情去尽情的折腾和学习，当互联网兴起的机会来临时，做个运维总监其实也是顺理成章的事； 其实，除此之外，我还转型做过售前，技术支持，跑过市场，经常做演讲培训，所以真正的高手是什么不会学什么，技多不压身，做个懂业务、会开发的运维工程师。

您觉得运维人员最重要的素养是什么？对新入行的运维人员有哪些寄语？

我认为最重要的能力是表达沟通能力，但不排除运维本身所需的技术储备、实践动手能力、编程能力和学习能力。考虑到运维大部分还是一个成本支出的岗位，如何把深奥隐晦的性能及瓶颈指标，用直观的图表展示来获取上层持续的投入是需要技巧的；然后面对你的同事，你的兄弟部门，也需要你的影响力去协调推进工作，如果能够做到这些，说明你已经具备了领导的才能，这样以后做什么事都会站在更高的水平，用全局观的格局去统筹规划整个项目的目标，人员，工期和资源的合理分配和把握。

更多运维讲坛内容，关注 SRETalk

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

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

这一期我们邀请到的是陈存利，度小满金融系统运维部总经理，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的运维岗位长期来看必将消亡，您是否认可这个观点？对于这类朋友的转型路径您有没有什么建议？

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

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

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

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

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

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

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

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

扩展阅读

• ​​运维百家讲坛第4期：又拍云邵海杨 - 25年Linux老兵聊DevOps八荣八耻​​
• ​​运维百家讲坛第3期：Flashcat来炜 - 如何把运维的饭碗端稳​​
• ​​运维百家讲坛第2期：作业帮聂安 - 运维如何转型，听听作业帮的OPaS思路​​
• ​​运维百家讲坛第1期：井源 - 运维几何​​

关于SRETalk

本公众号聊SRE相关的话题，方方面面的，主理人是秦晓辉，Open-Falcon、Nightingale 创始研发，极客时间《运维监控系统实战笔记》作者，Flashcat（创业方向是统一监控、稳定性保障方向，如有需求欢迎联系我做交流）合伙人。