组织专业化

可持续扩展的运维知识体系按“组织、流程、工具”三部份整理，本篇为第一部份“组织”的“运维组织专业化”。

2.1组织专业化

2.1.1专业化分工

随着业务的发展，可以预见未来硬件服务器、应用复杂性将呈现指数级的增长，业务服务质量要求、监控要求等也将加大运维人员的工作量，与此同时，运维人员的规模则可能会相对稳定。如何在己有人员规模的基础上，满足业务发展要求同时，还要去创造更高的效益，是运维组织在组织层面需要面对的难题。

鉴于运维目前仍存在大量操作性的工作，上述难题可以转换为如何提高人员效率、降低操作成本的问题，专业化分工则是解决这一问题的一个方法。专业化分工是由经济学家亚当·斯密在《国富论》提出，他认为专业化分工能最大程度的改进人力效率以及提高人员的熟练、技巧和判断力，他的论点包括：

• 人员的技巧因专业化而更加熟练，在分工条件下每一个人员只从事某一种操作，就能成为“局部熟手”，不但能精益求精，还能减 少了技能的学习时间。
• 专业化分工能节省劳动时间，这是因为分工使人员从事某种固定操作，有助于操作经验的积累和操作方法的完善以及效率的提高。
• 分工最重要的一点是使到职责、权利和义务清楚，打破了吃大锅饭不利于个体绩效考核的平均主义。

结合当前运维组织的管理模式主要是以纵向职能型的划分，比如常见的按运维对象划分几个大的团队，比如：应用运维（或业务运维）、系统运维、网络运维、基础设施运维等；再在每个大团队中按对象或技术划分更细的对象，比如应用运维按不同的业务对象划分不同的业务运维团队，系统运维按技术对象划分数据库、中间件、系统软件等划分不同的系统运维团队。这种组织方式在某个领域内相对专业，各自履行职能，管理权限集中，在领域内的工作效率比较高。不过，随着工作量的增加、服务质量的要求不断提高，运维团队这种职能型的组织无法具备可持续改进的条件，容易出现一些弊端，比如：

• 整体的管理理念很难有效的落地；
• 缺乏持续改进，持续改进的团队建设的条件；
• 好的信息、经验无法实现共享，团队间协同成本高；
• 通用性、基础性的自动化建设多以烟囱式方式开展，重复性建设多；
• 操作性工作多，又很难抽出人力进行整合处理；
• 团队专家人才、经理工作量与强度突出，成为工作瓶径；
• 整个团队常规被动操作性工作太多，无法开展主动性、计划性的工作；

上述问题，适合采用在纵向职能型团队的基础上增加横向团队，负责整体性、通用性、计划性的工作，这样的划分能带来几个好处：

• 将同类的操作性工作可以从职能型团队中分离出来，比如服务台、数据集中维护、数据提取等，一方面通过集中操作提高这类工作的工作效率；一方面通过对集中操作提供的工具建设可以获得更大的投入产出比，比如服务台的经验库的建设；同时，集中标准化的处理还能减少操作风险；
• 职能型团队减少操作性工作后，可以分离出一些工作时间处理计划性、主动优化类的工作，比如运维分析、业务运营等工作； 针对整个运维团队进行的一些建设工作，比如自动化工具的建设，一方面可以提高工具间的互联互通，另一方面集中的投入更有助于获得更大的投入资源，以及收获更大的效益，减少重复建设； 对于一些管理、技术手段，可以通过一些横向团队进行持续的监督与优化，有利于规范化、标准化的落地，比如变更管理岗、故障分析岗、可用性分析岗等；

2.1.2 纵向职能型团队

企业内，不同的业务部门需要有不同知识和能力的IT服务团队提供支持，为了更好的支撑业务部门的需要，运维组织也需要有差异化、有业务侧重的划分不同的纵向职能型运维团队，通过将同类专业技能的人员整合在一起，可以更有效的提高服务质量，提高工作效率。可以说纵向职能型团队是运维组织的前线部队，他们最熟悉业务部门的需求，可以为业务部门提供最直接的服务。

不同企业的运维职能型团队根据自身的特点会划分不同的团队，在金融行业通常按这类方式划分：

• 应用运维：可以进一步划分不同的业务条线的运维团队
• 系统运维：可以进一步划分中间件、DBA、系统软件、容器、虚拟化等运维团队
• 硬件运维：可以进一步划分机房环控、服务器、网络、存储等运维团队
• 信息安全运维：（待完善）
• 流程调度运维：可以进一步划分不同的流程优化

但随着业务服务要求的不断提高，己有的纵向职能型团队以被动、人肉操作为主的工作越来越吃力，急需将有共性、操作性的工作独立出来进行自动化或由专业的团队的去做这类工作，以释放纵向职能型团队一部份的工作量，由被动保障的状态向主动运营的角度去探索，这是纵向职能团队更深一层的精细化、专业化分工的过程。

2.1.3横向服务团队

纵向职能型团队是运维或运营落地的基本保障，那横向团队是服务于纵向职能型团队，它可以是虚拟的组织或实体的组织，它也可以是临时性的组织或长期性的组织，具体的组织方式可以根据实际需要制定，将横向团队分为横向专项类与项目类。

2.1.3.1横向专项类

运维组织能力的持续改进，需要有专项的人员进行横向分析、服务支撑，以促进组织能力的改进。比如，提高纵向团队工作效率、防范操作风险，需要有运维开发团队建设合适的监控、巡检、安装等工具；纵向团队要实现运营的目标，需要有运维开发团队建设更好的数据化分析平台；管理规范的有效落地，需要流程优化人员不断优化，需要运维开发团队对TISM的建设。

持续改进类的方向有很多，作运维组织，以下三块团队最好有专业的人员负责：

• 信息安全：（待完善）
• 流程优化： 大部份运维团队会将各项规范制度通过某一个或多个成熟的方法论的方式落地，比如ITIL。但为了更加规范化、标准化，并让组织的日常工作能够持续的改善，最好有专门的人或团队去分析流程落地效果，去促进传达细化领导的决策，去优化ITSM的流程设计。通常，缺少流程优化团队的组织的团队经理会成为工作瓶径，流程人员在一定程度上是在分担经理的压力。
• 运维开发： 运维组织在经过百花齐放式的工具开发、引入后，通常会面临投入产出比低，工具烟囱式建设、功能重叠、工具间无法整合、工具无法优化修改或响应慢等问题。运维开发团队的建立主要有几个目标：

- 整体化的建设通用性工具平台、模块，整合己有工具的基础上，促进自动化水平，提高工作效率、控制风险；

- 快速响应运维纵向团队、流程、信息安全人员的需求，优化运维工具；

- 沉淀技术专家意见，减少对经验的依赖程度；

- 简化运维团队进行运维开发的门槛，为运维人员提供所见即所得的运维开发能力；

- 研究、积累新技术，为运维转型提供平台、技术上的支撑；

2.1.3.2项目类

项目的特征是有计划、有目标、有时间限度、可实现。虽然长期以来运维呈现出来的是被动的角色，但为了运维组织其实也有很多工作满足项目的特点，应该用项目管理的方法去完成这些工作。可惜的是运维组织里具备项目管理能力的人员比较少，所以很多计划性的、规划性的工作通常不如开发团队做得好。

因为项目类的工作通常会有一个时间限度，不像运维或运营的工作是长期的，所以通常项目类工作的团队的核心成员固定，团队里的技术专家可以是临时组建。运维工作中，只要满足有明确目标、有时间要求、可落地、涉及多方协调的很多工作都适合用项目管理的方式付出做，比如机房搬迁、重要业务系统上线、技术方案的制定等，这里以应用运行分析方案为例。

应用运行分析项目的目标是：为提高主动掌控应用系统运行状态，要在应用运维团队实行应用运行分析工作，主要包括性能、可用性的分析，该项工作需要有针对的对不同的应用系统制定指定频率的运维分析工作的落地。为了实现上述目标，需要落地应用运行分析项目，该项目需要在半年内制定一个相对通用、可落地、可持续的运行分析方案，并挑10个应用系统试点落地。

运维分析如何做在后续章节会提到，这里只是简单看这个项目会涉及不少人的支持，比如：

• 为了让运维分析更加高效，需要找监控或数据平台的同事分析有哪些数据可以提供运维分析；
• 为了分析数据库的性能，需要DBA提供一些专家建议的可操作的标准化方法；
• 为了梳理应用系统的分析频率，需要应用管理员提供应用重要程度等支持；
• 为了试点方案的可行性，需要领导支持安排运维人员实施；
• ……

这样的工作就需要以项目管理的方式，安排有经验的项目经理牵头项目计划，组织一个虚拟的、不同领域的技术专家小组完成技术方案的形成，项目经理做好相关干系人分析，控制好范围、时间、成本、质量，统一获得组织资源，横向推动相关方案的落地，并让纵向运维团队具备持续进行运维分析的能力。