转型后的运维太叛逆了!和研发又打起来咋办?丨话题接力

一直努力营业的 2021-12-17 11:36:40
上一期提到,在云原生时代运维人员如何转危为机、应该精进哪些能力的话题:运维怕是要凉了???丨话题接力

 

既然运维面临转型,整个运维团队的组织架构也少不了升级,那么在云原生时代,运维团队leader在管理理念和方式上要做出哪些改变?团队乃至整个企业的技术知识体系如何建设?研发和运维同学如何协同合作?运维到运营如何演进?

 

本期,针对以上这些运维团队管理、企业运维体系建设的痛难点,京东科技数据库团队负责人-高新刚、美图SRE负责人-石鹏、腾讯游戏混沌工程负责人-吴召军,三位运维专家也不遗余力地给大家分享了很多经验和建议:

 

Q4

运维在“管理理念”上应该做出哪些改变?(支撑能力、架构能力、交付能力等)

 
石鹏

图片

图片

“管理理念”其实我也在学习,关于我们人才的梯队建设到底是T字型还是什么型?我觉得,在团队里面,怎么划分大家要钻研的方向?如何制定这方面的计划?这些问题可能会比较关键。要让大家有方向感,再去确定具体做的事情、要去钻研的东西。像高老师说的,在一个团队中,如果每个小伙伴都有一个精专的方向,最终大家组合起来,才能形成比较好的战斗力。这是关于整个团队对外交付能力的建设。

 

关于管理还有一个点比较重要:我们怎么去掌握整个团队的前进方向?我觉得比较好用的工具之一是OKR。我们要真正地把它用起来,因为现在可能有好多团队会把OKR用成KPI。但在我们内部的话,"O"是非常明确的,我们会把日常所有的工作都对应到"O"上,基本上你做的所有事情,像是监控、业务支撑等,最终它都会对应到我的稳定性的 "O"上,对应到我的支撑、效率"O"上。

 

这样会让大家有非常明确的目标感,并且如果你真的去用的话,不管你之前是什么样,你都会尽可能地把它做到可以量化,样就容易在团队内部形成一种公开的、透明的文化:你的工作是什么样子,大家其实都可以看到。因为OKR是公开的,你的"O"是什么样?你达成得怎么样?

 

前面有讲到,我们现在在做一个jira看板,jira看板其实也秉承着同样的理念,每位同学当前手头有什么任务?他的任务队列里面是什么?在做哪些事情?这些其实都可以被大家看到。这样的话就能形成一个非常良性的循环,比如说在团队里,如果某位同学的任务排得比较紧,那其他同学是不是就可以cover一下?相互协作去共同完成一件事情,这样就会逐步建立起来。

图片

吴召军
图片

我想站在一个员工的角度来试图回答这个问题。支撑能力在云原生场景下应该怎么去转换?我自己作为一个运维,在传统运维方式下主要工作是发布、扩容、缩容、处理故障这些工作。

 

在云原生的场景下,以我现在的工作为例,这种支撑的服务转变为建设云原生上云平台、可观测性平台、混沌工程平台、全链路压测平台等工具,使用这些平台提升研运效能。同时,日常的运维工作“左移”,比如交付能力,开始的交付是开发给了一个版本,然后我们去上线部署。但现在这是不够的,我们需要跟开发团队一起承担服务稳定性KPI。我们会一起去做架构上的评审,做服务可用性上的架构设计,我们运维对云IaaS、云PasS产品的特性非常熟悉,在架构设计、选型阶段我们可以提出非常好的方案,提前避坑。

高新刚

图片

图片

在这一点上我也想跟大家分享一下我的体会,因为在今年年初的时候,京东内部进行了一次组织架构的调整,以前的京东数科和京东云进行了合并。我们以前是京东数科的,那么在合并后,就会面临从传统运维到云原生运维的转变。合并之后,有很多小伙伴因为不适应而离开,也有一些在短时间内比较迷茫。

 

在这个时候,作为管理者,我们经常会跟小伙伴进行一些思想上的传递。像刚才石老师在发表自己的三个观点时也说到:通过从思想和认识上,让大家意识到,云原生的相关技术在这个时代能给我们带来什么样的好处?它的变化对我们的未来有多么好的帮助。

 

还有一个点就是,要从整个公司的战略层面,传递给大家我们这么做的原因。我们要做的不仅仅是云原生,还有多云的管理,以及很多的服务,像“上移”“左移”这些具体的事情。通过这种观念或者说理念上的传递,让大家能够寻找到自己的方向,得到战略上的认同。

 

这样我们的小伙伴才能够从传统运维到云原生运维的转变过程中,寻找到自己的方向,在未来的工作中更好地去发力,去建设未来的云原生!

图片

石鹏
图片

是的,我们从19年开始上云,上云之后就意味着一些传统的基础运维的人员,像是管服务器的、管网络的,这些同学可能就没有或者说少有应用场景。当时我们的团队里新进了几位之前做基础运维的同学,在这个过程中,我们结合其优势以及目前的兴趣点去做规划和建议:上云之后你应该去做什么?

 

在这个过程中,我觉得比较好的一点是:上云之后,我们团队没有任何一位小伙伴是因为上云后工作和基础运维有差异、不适应而流失的(当然我们团队本身也不大),而且现在我们运行得还不错。当然,这里面有这些同学自身的原因,因为有些小伙伴可能本身就会有一定的危机感,会提前做一些储备。

 

比如我们有一位做网络的同学,他是资深的网络工程师,做了很多年网络,以前是在运营商那边工作,后来加入了我们团队。他自己就有主动提前去学习K8s的知识。还有另外一位是应届毕业加入我们团队的同学,一开始做的也是网络,但他自己也在学习运维开发的事情,在学编程语言,这样一来,上云之后的转型就会顺畅很多。

 

在这个过程中,结合他们以前的兴趣、已经在做的能力提升去进行规划,可能会比较好,所以我觉得理念真的是很重要的。

 

Q5

运维在“管理方式”上应该做出哪些改变?(制度、流程、体系、组织架构等)

 
石鹏

图片

图片

对于我这边来说,其实很多东西都还在实践过程中,没有形成一套自己的、比较可靠稳定的方法。

 

对我来说,“方法”可能更多的是一些工具的使用。比如怎么拆目标,让目标可衡量等。现在大家在讲用敏捷的思想管理目标、用 OKR看目标等。其实我觉得,把这些东西做好,就能够让整个团队的人有目标感,营造一种开放协作的氛围,这个就比较好。

 

目前,我们在团队里其实有明确地用标语的方式来宣传我们倡导做事的方式:开放、协作、共享,一定要有这样的思想才行。倒回到前面,高老师有讲过,有时候我们很多团队可能在做同样的事情,就是各个团队之间可能会在竖烟囱,相互之间的流通性没有那么好。

 

所以按照我的理解,一方面要有一个顶层设计,以一个更高维的视角来看我们所做的事情:怎么规划,怎么相互协作,才能给企业带来更大的价值,也就是人们常说的“力出一孔”,当然这是要在组织上做的事情。

 

另外一点,大家一定要形成良性的、协作的理念。这是比较理想的状态,但在推进过程中可能会因为一些原因而产生阻力。只要有人的地方就会有江湖,但我们不能因为有阻力就放弃这样的理想。至少要在我力所能及的范围里,我会去倡导开放、协作、共享的理念,用这样的方式来做事情。

图片

吴召军
图片

在管理方式方面我可能没有什么话语权,但也有一些感悟。上云之前,业务运维要做的事情是非常多的,要同时负责IaaS层和应用层工作。到了云原生时代, IaaS、PaaS托管给云厂商了,产品开箱即用,少了很多部署、管理工作,效率提高了。

 

运维职能也发生了变化,往往会朝两个走向去走,一个是做上云平台的规划和落地,让开发同学能平滑的将服务上云,负责平台易用性和可用性。另外一批同学还是负责业务运维,但业务服务是往微服务的方向去发展的,每个微服务的开发他只负责它开发的那一块服务的可用性。但一个服务要真正上线需要把各种各样的微服务串联起来,这个串联的工作,就是转给业务运维同学来负责的,也需要建设工具来提升效能,比如快速梳理清楚服务间的拓扑结构,确认服务间的调用关系是否合理,检验服务的容错能力等。

高新刚

图片

图片

我再补充一个点,其实从管理上来说,学习也是非常重要的。对于我们团队来说,从传统运维到云原生运维,有些同学在刚来到这个部门的时候,他对云原生的很多技术栈其实都不是很了解。有时候会找不到自己的方向,目标不明确。

 

那这个时候就需要管理者组织大家有针对性地去学习,这是一个非常重要的点。

 
Q6

运维在“知识体系”上应该做出哪些改变?(DevOps、SRE等新模式)

 
石鹏

图片

图片

其实我们刚好也在做这方面的改变,我们在内部有组织学习小组,去年搞过一整期。上云之后,因为有些小伙伴之前并不是做产品运维的,过来之后有一些通用的能力需要快速地拉齐。为了解决这个问题,我们组织了差不多七八个方向的专题,每周组织一次,有的专题可能会持续好几期,比如说我们讲容器技术时就分了7期。

 

我认为,用学习小组这样的方式,让大家把基础的、通用的能力快速地拉到一个差不多的水平线上,我们才能更好地去进行协作。这是去年的。

 

今年上半年我们的事情比较多,就没有特别开展。从Q2结束差不多Q3开始,我们又开启了新一轮的学习小组计划,并且这一次我们给我们的学习小组起了一个非常宏大的名字,叫Pharos就是法罗斯,原意是埃及亚历山大灯塔。这一次我们设计了一个比较完整的课程体系,围绕整个产品生命周期,把在这个工作中可能会用到的所有技术点都绘制出来,以它为导航图去展开我们的学习。

 

从前面的 CI/CD一直到后面整个监控,把周边的体系全都搞起来,以此为灯塔。这也是这个名字的寓意,一方面,团队内部的同学可以用它来明确自己应该学习的方向,按图索骥,明白自己哪里有欠缺、应该去补齐哪里、哪里是需要去发力的点。

 

另一点还没有实现,但我们期望,等后面做的比较成熟之后,想办法把它分享出来,让以后可能进入美图公司的同学提前做储备。这就是我们团队每位同学的岗位技能要求和期待,只要能把这些技术搞定,我们非常欢迎你加入我们。

 

这是目前我们在做的一个事情。

图片

吴召军
图片

在知识体系建设上,我们团队的氛围很好,大家都很乐意去分享。在我们团队内部是这么运作的:每周一次微分享,大概30分钟左右。这个微分享选题是自由的,每次的微分享,一般来说是同学先准备,学习了一段时间之后,再把这个知识点分享给大家,分享的同学是先把知识内化吸收了,再讲给大家听,印象会非常深刻,很多年前我分享的内容,到现在记忆还很清晰,这对个人的总结、表达能力来说都是非常好的提升。

 

具体的内容上,从我的经验来看,我先会把云原生的知识图谱打开,因为云原生其实有一个很大的版图,像K8S,服务网格、可观测性、混沌工程等。根据版图,从我们的业务实际需要出发来钻研技术。判断这项技术有没有可能在我们实际的业务落地中产生一些收益。

 

比如,我发现服务故障率很高。于是想:能不能通过提前注入故障,将问题提前发现解决,所以我就去研究混沌工程的一些技术,包括Chaos Mesh等。在实践过程中,我们发现了它确实能产生一定的效果和收益,这样一来,我们知识体系建立起来了,人才团队也有了,业务也获得了收益。

高新刚

图片

图片

基本上我看到的所有公司都非常重视技术的分享和人才的培养,通过分享,分享者能够有一定的提高,对整个知识体系的认识会更加全面、系统;而受众可能会觉得这些知识对他来说非常新鲜,也会有学习的动力。最主要的是,你可以随时随地地在公司的内网里学习,这样就营造了一个很好的学习气氛。

 

我们公司其实除了这些技术分享之外,我们整个大部门,尤其是数据库的研发部门,可能更多地会去关注文档的建设。比如说,每一个人所做的事情,都要去整理出这一部分的文档,把整个实施过程中遇到的困难、经验,包括测试数据都写在文档里。这样一来,部门里的其他的同事可以不定期地去查看这些文档。这些文档可能就是一些琐碎的日常工作,但拿出来分享给大家之后,大家的经验会不断得到提升,这也是整个知识体系的一部分。

 

Q7

新一代运维平台的能力建设怎么做到智能、效率、协同的结合?

 
吴召军

图片

图片

智能和效率其实是相辅相成的,我们做云原生上云后,服务获得了弹性伸缩等能力,提升了运营效率,这点无需赘述。

 

但具体到协同这块,我有些感触。通过云原生上云之后,我们去落地DevOps这个理念,让开发同学参与软件全生命周期的管理,这个理念最开始去推广落地时,我们的开发同学是非常不认可的。

 

之前在传统运维时代,开发同学把代码开发好之后交给运维,他的工作就结束了,但现在在云原生时代,他要负责去配置发布流水线等工作,这样一来他的工作量其实增加了很多,所以最开始我们DevOps的落地阻力很大。

 

我们持续不断降低平台使用门槛,开发和运维通过平台实现了标准化对接,减少了非常多的沟通成本,大幅提升了效率。开发同学获得收益之后,DevOps这种方式才慢慢得到认可。所以在协同过程中,我们这边确实花了很多时间和精力,但最后还是取得了想要看到的收益。

图片

石鹏
图片

那我来说一下我们这边,首先智能化,刚刚其实有聊到 AIOps,目前我们这边也有这样的一个中长期的规划。按照目前的情况,你要想做智能化,前面还有很多路要走。像腾讯、京东这样的大厂可能做的比较前沿,但广大的一些中小企业,像美图这种公司,虽然他们也都有意识在尝试做一些探索。但在目前,以美图为例,我们需要先把前面自动化、标准化这些东西做好,先做好该有的流程体系,再逐步去做智能化,所以要有一个大的规划。

 

至于现在,当然我们也有一些点有待探索,包括刚才提到的弹性伸缩。我们现在在做的一个成本优化的点是自动调优。你的资源分配到底合理不合理?然后自动去进行调优。这也是用算法,根据历史的资源利用率和申请情况自动调优。

 

首先做这件事情可以回归到价值,另外,这个点你既可以说它是自动化也可以说它是智能,因为它比一般的自动化多带了一些决策的东西,这也是带着智能的。目前我们整体是要先回归到具体的业务场景,解决比较突出的问题,然后以点及面,先把各个痛点解决掉。

 

因为现在AIOps也在发展,而且发展得很快,后面我们也在持续关注,等有好的这种应用的这种东西了我们也可以再切进来。

高新刚

图片

图片

我非常认同石老师的观点,刚才石老师有说到一个词:以点及面。其实我们内部在做智能化运维的时候,是有一个理念的演变的,就是从精细化运维到智能运维。

 

就是说,不管是传统运维或者云原生运维,都要做到精细化。当你精细化到一定程度的时候,你就知道,你的运维的逻辑能不能被替代、被模仿,能不能被整个智能化的体系替代。通过这种精细化的梳理,再到智能化的替代,这个过程其实是一点点逐个场景去替换的,而不是说一下子能把所有的运维场景覆盖掉。

 

再一个就是协同方面,其实大家也公认:智能化并不能完全解决所有运维场景的问题。那么,在有了智能化之后,我们运维的协同要如何去展开?这也是一个非常好的点。目前我们是通过一些自动化和智能化相结合的方式,去保证我们现在的运维体系,后面可能会逐渐替换。而在整个替换的过程中,包括运维人员角色、职能的转变,可能都会发生新的一轮的变化。

 
Q8

都说企业IT运维的发展方向,是从运维向运营的转变,怎么理解运营这个概念?怎么实现从运维到运营的过度?

 
石鹏

图片

图片

从我的理解来讲,运营和运维其实就是你能力边界的扩充。或者你可以理解为:用传统的方式去做传统的事情,可能并不能再持续地优化我的工作。

 

比如说,我只关注服务的告警和解决这个问题,这可能并不能从根本上提升服务的质量。你可能需要在更早的时候就要去做自动化测试;再往前,你在代码设计、架构评审的时候可能就需要去介入,在更早的阶段去考虑这些点,这也是我们目前在做的事情,这就是刚才讲的“左移”。

 

再就是“上移”,你要看到你的业务价值,然后去思考,要怎么做才能更好地去支撑这个价值输出。用这样的思路去思考问题时,其实你的角色已经由运维转向了运营,这是我的理解。

图片

吴召军
图片

我的看法是,传统运维是被动的,运营应该是主动的。传统运维收到开发的一个版本,然后要去部署、线上发布、处理故障、监控告警等,整个过程是被动的,是别人安排的任务。而运营是主动出击,可能在一个版本还没有开发、还在讨论阶段的时候就去输出他关于选型的一些建议。

 

选型阶段运维去介入,在架构评审阶段就能够发现里面的风险点。传统运维方式下,在架构设计阶段一般都是由开发团队自己内部来完成。但是在云原生这种主动运营的场景下,我们的运维同学是要参与到这个过程当中的,我们团队跟开发团队协同非常紧密,迭代会一起开,架构一起评审,最后,线上出了问题也一起来扛,这个过程是一种非常主动的转变。

高新刚

图片

图片

我也有相同的认可。云基础资源提供了资源的容灾能力和扩展能力,运维重心偏向以应用为中心,注重业务运营,业务指标可视化和应用链路分析成为关键。服务网格可以帮助运维,实现服务注册、发现和负载均衡,分布式追踪,认证授权,加密通信和审计,以及多服务版本,分段服务等特性。

 

我认为,其实从运维到运营,更多的是从用户的需求出发去做运维,从用户的需求中寻找最佳的运维方式。只有这种方式,才能达到运营的这种效果。

 

在整个话题讨论过程中,我们发现,大家有很多理念是契合的、是相通的,不同公司之间的基本体制、OKR等做法也是可以互相借鉴的,包括平台上大家都有在做一些类似的建设。

 

云原生不是趋势,已是事实,五花八门的云原生技术,让不少运维同学对职业发展感到迷茫,同时也给企业IT管理带来了更高的要求,通过这次话题谈论,希望能给运维同学和企业们带来了一定的启示。

 

特别鸣谢

 
 
最后,感谢3位老师的倾情分享,有了你们的宝贵经验和建议,相信我们在云原生时代,将走得更加顺畅。小伙伴们还有什么独到见解,欢迎在留言区评论~
 

图片

 


最新评论
访客 2021年09月03日

有没有1000多张表

访客 2021年08月28日

metrics =》 metrix 错误

访客 2021年08月25日

只看到如何避免,如何减少书写慢 sql

访客 2021年08月25日

没看到如何治理呀

访客 2021年07月23日

果然k8s不是神!

活动预告