运维团队组织架构设计

Posted 运维IT圈

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了运维团队组织架构设计相关的知识,希望对你有一定的参考价值。

运维团队组织架构设计

运维团队架构大概设计如下,如图1-1所示。


运维团队组织架构设计


图1-1 运维团队组织结构

当然,大型机构的运维团队如上所示,但大部分运维都达不到上面的规模。但尽量保证至少有一名运维开发人员。

我发现很多中小型应用运维人员几乎没有开发能力。然而现实是研发开发应用一般不会考虑运维问题,导致很多应用运维需要到数据库里面捞数据去分析,效率准确率极其低下,在我从事多年运维经验来看,在应用运维层面,运维开发就是解决该类型问题的首选,本质就是补全产品的运维层面的缺陷,让应用运维效率更高,故障率隐患情况更少。

运维团队依赖模型

能力

一个高性能的运维团队一定是以应用运维和运维研发为核心构建的!

具体的团队能力模型示意图如图1-2所示。


运维团队组织架构设计


图1-2 团队能力模型

对于我带过的应用运维团队,我都会从如上三个方面对组员提出运维能力要求。

1)业务运维。因为对这块能力的要求越来越低,因此其在我们的考核体系中所占的比重也越来越低。日常的变更、扩容、故障定位、运维规划对人的能力要求都非常低,这些工作都能模式化且平台化,从而减少了对人的倚重。

2)运维研发。我希望每一个应用运维人员都有运维研发的能力,但这在现实中是不可能的。对于应用运维团队和运维部门来说,运维研发的配备必不可少。在应用运维团队的内部,可以让有研发能力的人迅速承担面向业务运维平台的建设,或者参与到部门的运维系统建设中,可以抽出50%的时间参与研发。运维研发能力是能够让团队价值迅速达成的有效保证,没有研发能力的运维不能成为一个好运维。

3)技术研究。运维是一个技术团队,需要通过技术来体现价值,当找到好的技术时就要想着如何将技术应用到业务上,为用户带来价值,比如说提升用户体验,减少成本等。

这个时候就会产生一个问题,应用运维团队内的人也会运维研发,同时又有专职的运维研发团队,那么他们的职责分工如何解决,在工作上是否会存在重复建设?我的回答是这样的:

首先,可以把运维研发初期定位在公共服务平台的研发上,比如说DNS、LVS、配置管理、监控系统、CMDB、数据分析平台等。

其次,运维研发还需要制定相应的运维研发规范,代码规范、UI规范、测试规范等,让所有参与运维研发的人统一遵守,包括应用运维研发的组员。

最后来说一下应用运维小组内的研发能力该如何发挥的问题。其实在很多运维团队中,运维都是跟随业务的,一则可以让应用运维研发人员开发面向业务的运维系统,因为他们最了解该业务的需求,能够实现自己想要的;另外一种更好的操作方式,是让应用运维小组内的研发人员抽出50%的时间参与到以运维研发牵头成立的虚拟研发小组中。一则可以进一步提高应用运维的研发水平;另外还可以提高运维研发对业务运维的理解,同时还能提高带队作战的能力。

那么,运维研发和应用运维的比例应该设置成多少比较合适?我个人认为3:1比较合适,大家也可以自检一下,自己的运维团队到底设置了多少运维研发人员?另外想要检测运维研发配备是否足够,可以周期性地看看运维团队取得的进步,特别是效率和质量等维度。

驱动

具体的团队驱动模型如图1-3所示。



图1-3 团队驱动模型

团队的驱动力不同,带来结果的就会完全不同。为什么很多运维人员都说自己很辛苦?这时你可以思考一下到底是什么在引导着你进行运维工作?传统的维护,往往都集中在第一阶段和第二阶段,而进入到高阶运维体系之后,我们需要迅速切换到价值驱动和用户驱动的维度上来。有了用户驱动和价值驱动,对运维的效率和质量就都会有更高的要求,对于外部驱动我们必须走自动化和平台这条道路。建议大家在平时的工作中加入质量、效率、成本等一些KPI要求,不要只局限于自己所做的事情,而是要关注自己所做的事情对产品和用户的影响。

技能

BAT(百度、阿里、腾讯)很早就实施了职业通道体系,在运维侧细分了多个能力通道,比如说网络运维、业务运维、运维研发、DBA等。对于运维人员的成长也有明确的要求和衡量体系,在此我就不详细介绍了。

文章摘选来源:运维前线-一线运维专家的运维方法、技巧学习笔记

更多内容请关注:

后台回复“加群”,带你进入高手如云交流群


以上是关于运维团队组织架构设计的主要内容,如果未能解决你的问题,请参考以下文章

电商行业运维实践

Qunar Redis 高可用架构设计

一次教科书级别的Redis高可用架构设计实践

运维架构

Devops实践:运作模式

基于CMDB与SALTSTACK的运维自动化之路