02 | 规划之问（2）：研发、测试、运维不同技术岗常见职业路线

Dec 20, 2023

02 | 规划之问（2）：研发、测试、运维不同技术岗常见职业路线-程序员职业规划手册-极客时间



下载APP





关闭

渠道合作

推荐作者

02 | 规划之问（2）：研发、测试、运维不同技术岗常见职业路线

雪梅 · 程序员职业规划手册

课程介绍



讲述：雪梅

时长21:23大小19.54M



你好，我是雪梅。
不知道你有没有这样的疑惑：
我现在的职业发展进行到哪一步了？
再往上走还需要往哪方面努力？
如果我想转岗，会面临什么困难？
更不用说在技术飞速发展的今天，还经常出现岗位消失、岗位融合的论调。
很多时候，我们的慌张来源于无法及时认清自己所处的位置。
这一节，我们就跳进技术人不同的角色，研发、测试、运维，去看看不同角色常见的职业发展路径和能力要求差异。有了这份导航，也会让你对未来有更清晰的认知，减少很多迷茫，甚至在别人的路径中找到适合自己的路。
这里先提一句，无论是研发、测试、运维，都有可能走向管理岗。转管理的事情，我们下节课再说，今天我们只探讨非管理岗的发展。
研发岗规划之问研发岗细分为前端、客户端、后端、算法等。无论哪个研发岗位，在我看来，目前的趋势都是朝着两个方向分化，一个是向上浮，靠近产品、业务的业务研发，一个是向下沉，做专业技术攻坚的底层技术研发。
这两个方向对于能力的要求会有哪些差异呢？
业务研发 VS 底层技术研发
以客户端研发为例。底层技术研发，主要负责客户端的基础架构设计，解决性能和稳定性问题，以及客户端的容器、配套工具链的设计研发等。这就需要研发同学对相应的底层技术掌握到炉火纯青的地步，有非常强的专业技术攻坚能力。除了技术，还要具备良好的服务意识，因为虽然不直接面向外部用户，但面对的用户是工程师。当然，还要有内部产品的设计、推广以及最终落地的产品闭环能力。
和底层技术研发相比，业务研发就不再单单是个工程师了。除了常见的编码、问题分析定位等研发基础能力之外，更考验的是把业务或商业问题转变为技术问题，并能最终解决掉的技术应用能力。最后，就是和产品、业务等职能的跨角色沟通协作能力。
这两种分工就好比练武。有的人对剑法很感兴趣，就每天苦练剑法，把剑法练到天下第一。有的人可能会一点剑法，也会短刀、大刀，可能还会点拳法，每一项都不是最精通，但他知道面对什么样的敌人，在什么样的场景下，如何组合运用这些本领打败敌人。前一种就好比底层技术研发，后一种好比业务研发。
未来的发展路线底层技术研发的发展，有三条路。当你的“剑法”练得足够好，你就会成为这个领域的专家。比如玉伯老师一直致力于设计语言 Ant Design、数据可视化 AntV 等的研发，在大前端圈享有盛名。
未来只要这个世界上还有场景需要你的独门绝技，你就有生存空间，甚至当你有足够的技术壁垒，还可以实现技术创业，这就是第二条路。
而一旦你成为某个领域的专家，也可以把技术传授给更多的人，帮助别人成长。这就是第三条路，知识付费。
如果说底层技术研发未来的发展，相当于我手里有一把厉害的剑，满世界去找什么场景需要用这把剑，那么业务研发的发展，就是手里没有厉害的剑，但我们背了一包武器，去找这个世界还有哪些场景有未被满足的需求、没解决好的问题，再用这些武器去解决。
所以，业务研发有两条常见的发展路径。
一种是成为某个业务方向的专家。当你聚焦于一个业务，解决的问题越多，对这个业务面临的问题和解决思路就会越来越熟悉，逐渐成为这个业务方向的专家。
比如我的一个朋友，最近几份工作都在金融领域，他本身也对互联网金融感兴趣，所以致力于成为互联网金融领域的资深架构师。这其实是技术与业务领域的深度结合。对他来说，不但技术架构能力要足够好，还要对金融行业的专业知识有一定了解。
业务研发的另一条路是往更综合的方向发展。因为业务研发本身对一个人的业务、产品、技术能力有一些综合要求，只是最开始用得更多的是技术手段。这个方向的同学会不断地解决真实世界中的问题，随着后续发展，逐渐组合运用更多的能力。我身边有不少四十岁以上的朋友，早就跳出技术人的标签，去做业务、做销售、做投资或者自己去创业，走出了一条更广阔的发展路径。
测试岗规划之问测试岗和研发有些相似，常规路径就是业务测试和测试开发。
业务测试 VS 测试开发
业务测试，顾名思义，做的是服务于业务系统的质量保障工作。日常的工作除了项目测试之外，还需要快速判断业务的质量状况，然后基于现状灵活制定方案、解决问题。
因此，一个优秀的业务测试，需要具备 4 项能力。
测试的基础能力。比如测试 Case、测试场景构建、测试方案落地的能力。
专项测试能力。指的是利用开源工具或公司现有工具，完成性能测试、稳定性测试、竞品评测等业务专项质量保障。
项目管理能力。因为测试属于发布前的最后一个环节，为了保证项目的顺利交付，测试同学就天然被赋予了一部分项目管理的职责。
测试架构能力。包括业务质量的识别能力，尽可能量化的质量分析能力，根据质量分析结果设计质量方案的能力，推进质量方案落地、复盘以及迭代优化的能力。
比如你负责的是一个交易系统，作为业务测试，你需要与研发一起梳理系统的关键链路，结合历史质量情况分析出当前系统的质量隐患。还要结合业务发展阶段以及当前的资源情况，给出明确的质量提升计划。这个提升计划可能涉及稳定性建设需要怎么加强，怎么设计核心链路的监控，哪些链路需要引入自动化测试，以及项目流程中哪些环节需要改进等等，这些都要想到。
再说说测试开发。和业务测试相比，测试开发负责的更多的是通用测试工具或测试框架的开发。但一个优秀的测试开发，所有的行动最终都要指向业务系统质量和效率的提升，不能局限在工具的开发，低头造轮子。除此之外，还需要深刻理解团队需要什么样的工具，跟进工具的落地以及工具使用的效果。而且你会发现，在目前的发展趋势中，测试开发同学越来越关注研发效能，要从全局维度思考如何提升交付效能，提升研发效率。
举个例子，小 A 负责外卖的检索服务系统，发现产品、研发每天都要花不少时间处理商户反馈的问题。比如商户经常会说，为什么我家的店铺没有展示在相应的位置上？其实这个诊断过程是可以流程化的。于是小 A 做了一个检索工具，输入商户 ID，搜索地点，就可以显示整个检索召回的中间步骤和结果，还根据研发和产品使用过程中的反馈，不断地将中间结果可视化，优化工具的使用，大大解放了研发和产品的人力。
测试开发的能力要求与研发有些类似，都需要有不错的编码能力。但相比研发对技术深度的要求，测试更关注技术的广度。测试开发同学要交付的产品一般都是公司内部产品，不像研发要面对高并发流量，但对测试开发同学来说，能快速地完成工具开发非常关键。
随着这几年测试人才的发展，很多大厂测试团队对于测试同学的编码能力也有了很多要求。很多业务测试小伙伴在日常中也会做测试开发的工作，有互相融合的趋势。
未来的发展路线测试岗整体来说是多面手，很多人调侃说，测试比开发更懂产品，比产品更懂实现。测试同学在日常工作中经常负责项目管理、质量运营等多个方面，因此长远发展路径有很多，我看到的主要分为三种。
专注于提升研发效能，做技术专家。比如业界知名的软件质量和研发工程效能专家茹炳晟。
业务领域的测试专家。即在一个行业深耕，技术上走专项路线，比如《云原生研发测试》的作者孙高飞一直深耕云原生领域，成为了这个领域的测试专家。
转型。因为测试岗的多面性，天然具备转型的可能性。比如我看到不少测试转研发，转产品，甚至转 PMO 项目管理岗。
“研发: 测试”比例持续下降，测试岗何去何从？关于测试岗，我们再多聊一个问题。
这几年，很多大厂都在降低“测试: 研发”比例，我记得 2008 年，很多团队的“测试: 研发”比例大概在 1:3 到 1:5 之间，而这些年，1:6 成了基础要求，有的成熟部门做到了 1:10，甚至在“去 QA（去掉测试岗）”。
不少测试小伙伴担心，未来测试岗会消失吗？我该何去何从？这个问题我跟几位从业十几年的测试大佬交流过，这里也分享给你。
我们先说说“去 QA”的本质。去 QA，本质是在解决效率冗余问题。程序在不同角色中间流转，一定会造成效率的浪费。一个产品的诞生，通常会经历“产品 - 研发 - 测试”这样的过程，然后测试发现 Bug，再反馈给研发。这期间确实存在资源的浪费。在理想情况下，如果研发能交付高质量产品，那么 QA 确实是可以被裁剪的角色。
因此，去 QA 的前提，是保障前置的研发步骤中开发出高质量的代码。再往前倒，就是让产品交付高质量的需求文档。质量的要求是恒定的，即使 QA 角色没了，质量保证工作并没有消失，只是转移到了其他角色身上，或者以其他方式提供。简单来说，就是质量还在，只是不用业务测试来保障。
现在我们再谈“去 QA”这个问题，就很清楚了。在“去 QA”趋势下，测试会逐渐从原来的业务测试、流动的团队，慢慢过渡到一个赋能的团队。不再是点对点去测试，而是提供质量保证的思路和能力，把质量保障框架的设计能力、方案实现能力以及测试落地能力，以培训、流程梳理或者工具的方式赋能给整个团队。
最后我想说，国内的“去 QA”是一个漫长的过程，即使在去 QA 的趋势之下，质量保障工作并不会减少，测试同学依然还有很多要去历练和成长的能力，依然有很多可供选择的发展路径，不用过于焦虑。
运维岗规划之问运维岗可以说是过去十几年技术岗中变化最大的一个岗位。不少运维小伙伴问我，现在系统都上云了，未来运维还有发展空间吗？要回答这个问题，就要先了解运维岗的诞生和发展过程。
运维岗的发展趋势运维岗在国内的发展大致经历了 4 个阶段。
第一阶段，打杂。大约在 21 世纪初，国内运维岗随着第一批互联网公司的出现而诞生。
那时候百度盛传关于第一代运维的段子：招运维是“靠称称的”。什么意思？就是体重得够。为什么？因为那个时代的运维是要扛机器的，要自己跑机房。这里有段子的成分，不过也从侧面反映了最开始运维的诞生是因为有很多杂活。但是招研发太贵了，那就招一些运维岗吧。
第一代运维一般对学历、经验的要求会比研发低一些。我有个朋友之前在新疆当计算机老师，后来决定北漂，面试研发岗根本没机会，最后通过运维岗拿了一个满意的 Offer。
第二阶段，规模化带来的精细化运维。随着互联网飞速发展，大概在 2008-2010 年之间，各大互联网公司快速扩招，研发人数迅速增加。人越多，犯错的概率越高，而且随着业务体量的扩大，一旦犯错，成本将也大大增加。
因此，这个阶段运维的主要职责是减少研发的失误，降低线上系统故障的概率。至此，运维岗有了精细的分工，比如网络机房、基础组件运维、业务运维等。
第三阶段，NoOps。随着系统工具的完善以及公有云的普及，在 2015 年左右，业内开始推 NoOps。很多之前的运维工作被系统和工具取代，运维岗大规模缩减，很多运维同学被迫转岗或离职。
第四阶段，面向业务的 SRE。上云之后，系统的问题没有彻底解决，故障依然存在，研发系统模块互相依赖，查 Bug 成本很高。于是，最近这几年出现了面向业务的 SRE，尽可能降低研发的开发成本，让研发将更多的精力聚焦到业务上。目前很多头部大厂都有专门的 SRE 部门。随着 AI 技术的发展，在运维领域可能也会出现更多 AIOps。
在运维岗的发展历程中，你会发现，当前运维岗的工作价值与业务规模强相关，规模越大，越能更好地发挥杠杆效应，因此好的运维离不开大厂。
其次，随着公有云的普及，运维越来越朝着与业务结合的方向发展，能力要求也逐渐综合。比如面向业务的 SRE 岗，既要有运维经验，懂网络、机房、常见中间件，又要了解业务架构。
而且，运维的能力模型，除了技术、经验之外，通用的软素质也越来越重要。比如要有大心脏，遇到故障不能慌，还要有很好的推动协调能力，最好还要有对问题的洞察力，也就是思考、分析以及解决问题的能力。
未来的发展路径那运维岗未来的发展路径会是什么样呢？前面提到的 SRE 是一条路径，很多的运维小伙伴都在大厂做 SRE 工作，还有一条路，就是做业务架构。
我的朋友杰老师做了几年运维，因为工作特别努力，也做了非常多的技术积累，对于高并发架构设计、多机房主备架构等都了解得非常清晰，还多次帮助业务搭建更稳定的架构。有了这些积累，后来他拿到一家央企的架构师 Offer，帮助央企下属子公司的系统上云。
在这段经历中，他已经成功转型为一名业务架构师，后来也做起了技术管理。这几年环境不好，央企也有很多变化，他用自己的复合经验和朋友创业，现在做着技术咨询工作。
岗位融合与能力发展前面我们分析了研发、测试、运维这些不同岗位的常见发展路径，其实，这几个岗位也有千丝万缕的联系。事实上，这几个岗位之间的转岗也很多。
其中，从测试或运维转到研发岗的相对更多。因为技术具备相通性，且研发处于上游角色，整体岗位需求量大。比如大厂现在的“测试: 研发”比一般在 1:6 左右，成熟业务可以做到 1:10，而运维（含 SRE）: 研发在 1:100 左右。
那你可能会问了，未来这几个岗位会融合吗？我觉得有可能。毕竟细化的分工是公司到一定规模之后才出现的，很多小公司就没有细致的划分，随着 AI 的渗透，可能还会有新的变化。
不管未来会不会融合，作为技术同学，都可以选择在自己擅长的领域不断打磨技术，走技术极客路线，成为某个技术领域的专家。
如果你不想走技术专家路线也没关系。由于过去技术的发展已经积累了和城市“水电煤”类似的基建基础，技术也能更好地解决真实世界中的问题。所以，无论是研发、测试，还是运维，都诞生了非常多和产品、业务贴合非常紧密的业务研发、业务测试以及面向业务的 SRE 岗位。这些都可以考虑。
这里我们再说远一点，说说能力上的要求。这些岗位，相比技术的酷炫，代码的优雅，未来更侧重的是解决方案的实用性。除了技术攻坚能力，也还有越来越多综合能力的要求。
在技术人的能力发展要求上，我推荐往 T 型人才发展，既有一技之长（｜），又不断去突破舒适区，历练自己的综合能力（一）。
虽然是老生常谈，但我们一定要记住，技术人的职业发展，技术只是打底，只是我们的“竖线”，是第一步，当横线越来越长，发展之路才会越走越宽。
我的一个朋友，之前在大厂做测试，虽然在外人看来，他发展得不错，但自己内心还是有焦虑。当时他说，“我怀疑自己除了测试，啥也干不了”。但他直面了这种焦虑，先是在公司内转岗，当时发现还是没有解决自己的问题。后来正好有领导创业，他就跟着去了，“当时想法就是要去做自己没做过的事”。虽然创业最后没有成功，但他打开了一个更大的世界。
为了更好地锻炼自己，他还尝试给创业公司做顾问。这几年做的事情，有的成功，有的失败，但对他来说，自己的综合能力比在大厂时提升了几十倍。大家都在讨论内卷，讨论 35+ 危机，他笑着说，“我快 45 了，依然活得好好的，还在找自己的下一个赛道”。
小结时刻这一节我们讨论了研发、测试、运维这几个岗位的常见发展路线以及可能需要的能力，你是不是对于自己的发展方向多了一些信心呢？
最后咱们聊聊别的，其实，无论我们当前的岗位是研发、测试还是运维，想要更好地发展，除了了解路径和能力要求之外，还要回到一个本源问题：理解自己岗位对于公司的价值。
比如业务研发岗，需要理解当下业务发展的阶段，是需要大力冲 GMV，还是要降本增效。那围绕这些目标，公司对研发岗位的期待有哪些呢？也许你可以通过提升业务链路的转化率，帮助 GMV 提升，或者将部分线下工作通过技术手段线上化，缩减开支，从而达到降本增效的目的。说白了，就是利用技术帮助业务达成目标。
举个测试岗的例子，看起来可能没有直接给公司创造营收，但在公司中是守门员的角色。基本的职责是把产品线测好，让所有的项目快速发布，线上质量还特别棒，这是一个测试岗位的要求。把岗位要求做到极致，就是给公司创造了极高的价值。
当你真正理解企业对于岗位的要求，就一定能帮助你在日常工作中不偏离，做正确的事，再加上日常我们在“事上练”，不断修炼正确做事的能力。做正确的事、正确地做事，两手都硬，你的职业发展之路一定会走得很扎实。内心笃定，眼里有光，相信我，职场上最靓的仔就是你！
聊聊发展你当下是什么岗位？对于自己的发展路径是怎么规划的？看完今天这节课，你有哪些收获和思考？欢迎留言讨论。
如果觉得有所收获，也可以把课程分享给更多的朋友，一起学习程序员职业规划手册，心里不慌，脚下不乱，做好每一天的成长。

技术岗位的职业发展一直备受关注。本文从研发、测试、运维三个不同的技术角色出发，探讨了它们的职业发展路径和能力要求差异。在研发岗位中，业务研发和底层技术研发是两个主要方向，分别要求不同的能力和技术深度。而测试岗位则包括业务测试和测试开发，分别需要不同的测试能力和项目管理能力。文章还提到了这些技术岗位的未来发展路线，以及对于技术人员的发展建议。总的来说，本文为技术人员提供了对不同技术岗位的职业发展规划和未来发展方向的指导。此外，文章还探讨了测试岗位的未来发展趋势，以及运维岗的发展历程和未来的发展路径。文章内容丰富，为技术人员提供了深入的思考和指导。文章还强调了技术人员需要不断提升综合能力，建议往T型人才发展，既有一技之长，又不断去突破舒适区，历练自己的综合能力。最后，文章强调了理解自己岗位对于公司的价值的重要性，指出只有真正理解企业对于岗位的要求，才能帮助在日常工作中不偏离，做正确的事，从而实现扎实的职业发展。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

2023-12-20

赞 18

提建议

01｜规划之问（1）：35+技术人都去哪里了？

03 | 关键抉择（1）：到底要不要转管理？

 写留言

全部留言(17)

最新
精选

华仔
2023-12-20 来自山东
是慢慢展开再深入，还是泛泛而谈？
作者回复: 华仔，你好，第一章只要是聊大家比较痛的问题，先解决大面的需求，后面两章再详细展开。当然职业发展这个话题跟很多技术话题不一样，没有标准答案，也没有最优解，所以是分享一些思考。欢迎多交流~
6
浩仔是程序员
2023-12-21 来自广东
5+年的业务研发，目前是做内容安全的审核平台，对接机审和人审的，对如何成为业务专家搞到迷茫？
作者回复: 浩仔，你好。有几个问题你可以参考一下： 1.谁使用这个内容审核平台？他们当下有哪些痛点？ 2.企业对于内容审核平台的目标是什么？审得更快，更准，还是什么？ 3.行业内内容审核都用到什么样的技术？你们对标行业是什么样的水位？把这些问题调研清楚，可能对于你了解这一块一些帮助。了解清楚之后，再思考一下，哪些问题技术上是可以去帮助改善的？内容审核这一块我经验不多，不知道这些问题能不能对你有些启发？
5
ququwowo
2023-12-20 来自美国
请问对于数据科学家(data scientist)这个岗位, 由于需要较强编码能力，可以认为属于“业务研发”吗？在大厂中是怎样的存在？谢谢
作者回复: 你好，数据科学我会倾向于是业务研发，因为数据是用来驱动业务，最终数据发挥价值也是要回到业务场景中。跟编程能力要求无关哈，业务研发本身对编码能力要求也挺高的。一对一教练陪跑好几个在大厂做数据科学家的小伙伴，这个岗位如果做得好确实是业务的“大脑”，但要做得这一步不但数据科学相关技术能力很扎实，更重要的事要深刻理解业务场景，能确定好的指标去做业务诊断，帮助业务更好地决策。
5
ShawnWu
2023-12-20 来自北京
现在是前端，但是中间做了很多产品沟通的工作，想向上浮，但是： 1. 具体怎么变成业务领域的专家不是很懂，开发咋往上浮呢？ 2. 业务向的思考与深度不是产品经理、销售更懂，在那搞需求吗？对于一线开发来说，具体的思路或者实践应该怎么迈出去呢
作者回复: ShawnWu，你好。是的，从分工的角度，业务的思考是产品经理、销售更懂，但技术要更大发挥价值，不能只是埋头接需求。至于具体如何向上浮，你是做前端的，下边这些问题你可以参考一下： 1.你做的产品整体日活/访问量多少？你负责业务的pv/uv多少？ 2.了解用户进入你的产品，动线是什么？也就是最常用的是哪些功能？他从哪里进，从哪里出？这里挺考验数据埋点的。 3.整个系统的流畅性如何？比如你负责模块的bug率？如果是APP，可能还有crash率？页面的秒开率？这些数据有哪些优化方案？ 4.今年业务对于这个产品的目标是什么？你这边可以提供的价值是什么？希望对你有帮助。也可以关注“码上破茧”公众号，之前也分享过不少前端大佬的成长经验。
3
程序员小跃
2023-12-20 来自浙江
老师这节课太棒了，我自己就是走的研发路线，期待下节课，我迫切想知道走管理是什么样子，因为现在有点沾边了。已经发给一些交流频繁的小伙伴看看这节课，希望对他们有帮助，噢耶
作者回复: 谢谢小跃，感谢你的转发。下节课会聊到要不要转管理，希望对你有帮助。
3
6点无痛早起学习的和...
2024-01-03 来自北京
目前是工作 4 年的 Java 开发，是做金融相关的业务，属于业务研发，发展路径： 1. 深造金融业务知识、通用技术问题解决方案 2. 学习一些业务建模、架构设计原则等毕业这 4 年一直都在滴滴待着，目前团队这 2 年都在做海外金融创新业务，第一个创新业务因政策黄了，第二个创业业务ing 中，也一直纠结过要不要换工作，但是一想，当前新业务正好是一个啃透业务的时候，学习是重要的，薪资满足即可
作者回复: 嗯，工作前几年，打好基石
2
花花大脸猫
2024-01-01 来自江苏
对于老师说的这个T 型人才发展深有感触，只有你的一技之长竖线足够的深，才能有效的支持横线的宽度，并且在接触横线上其他维度内容时能够触类旁通。
作者回复: 谢谢花花大脸猫，握爪，确实如此~~
2
missyou
2024-02-28 来自陕西
学梅老师，您好，我一直做后端开发快7年了，从开始做PHP开发4个年头，公司转岗做Java个也有3个年头，慢慢感觉面临中年危机比较焦虑。1、想着要不要深耕一门语言坚持下去？比如PHP，现在JAVA不是特别卷吗，php是不是相对在二线城市，竞争不是那么激烈？ 2、目前互联网环境下，转管理路线有中年危机吗？该如何规划路线。谢谢。
作者回复: 你好，技术人的职业发展其实跟语言关联度很小，越到后面，语言的影响非常小，重要的还是系统设计经验。你提到的两个语言，Java算是大语种，市场上需求量大，当然Java人才也比较多，PHP目前一线城市已经很少了，二线城市没有研究过。其次，所谓中年危机的本质，是市场上人才供大于求，转管理也不是什么逃避中年危机的方法，而且不是每个人都适合转管理。转管理只是帮你历练了一些新的能力，个人适不适合转管理，有没有机会，建议看下第3节。职业规划都是一事一议，没有标准的套路，如果说最根本的东西，花时间提升自己的能力，是最根本的，但具体路线需要结合每个人的具体情况来看哦。
1
丁丁历险记
2024-02-10 来自广东
这个时代开发自己会做unit test . 集成测试靠工具整合提效，code review 其实有白盒测试的功能，再招个更多的是打打下手，随时被轻松替代
作者回复: 工具确实可以提效，就像大家都担心ChatGPT会把自己的工作取代一样，不过当前的真实现状，工具能替代的部分还很有限，真实世界很多问题是充满不确定性，一直在变化，工具适合解决相对确定的场景，而更多的不确定性，比如对于真实业务的理解，把业务问题转化成一个技术问题，这个过程现在工具能做得还是很少。回到你的问题，优秀的测试，其实不只是研发的附属物，应该是对于整个业务有全面的理解，对整个业务架构的合理性，稳定性保障有自己更宏观的视角，还能设计更合理的方案来保障线上和线下的质量。个人观点，仅供参考。
1
花花大脸猫
2024-01-01 来自江苏
目前从事是SRE方向上的技术架构的工作，偏向于从前到后都需要关注，但是由于组织架构目前是有点难理解：运维是按照职能来分，但是开发团队是按照业务域来分，这就会导致只要跟运维相关的工作流程，沟通效率以及落地质量很难得到保证。比如要开展一项SRE稳定性的工作，对于服务团队来说只要按照业务域说明对应的技术改动步骤以及影响功能范围即可，但是对于运维团队就比较吃力，因为运维团队比较脱离一线业务，按实际技术来讲他们的深度也难达到，请问老师对于这种情况应该如何处理？
展开
作者回复: 花花大脸猫，你好。这个问题在很多大厂都存在，从流程机制设立来说，稳定性SRE是研发和运维要一起去负责的，很多大厂会要求每个业务单元有研发的稳定性接口人，与运维协同去把稳定性方案落地，这样双角色保障，会减少很多真空区。除了流程，从运维岗本身的要求来说，确实是一个综合性要求很高的岗位，技术上对于业务细节可能没那么懂，但对于一个系统常见的稳定性梳理思路要非常清晰。比如你可以给研发提要求，梳理核心链路图，从这些核心链路中对于研发的监控、故障预案，提各种细致的要求。还可以结合之前的故障和线上bug，明确哪些是重灾区，服务如何分级等等。这是技术方面，那除了技术方面，运维作为研发的下游，下游想要推动上游，就必须先得主动，还得有一定的流程约束，对研发提一些要求。希望以上的回复能给你一些参考。
1

