运维组织的架构介绍和ITSS关键发现
20151106淡然
续上
3.2运维组织3.2.1现状描述
目前，某公司运营中心按照业务系统类型划分运维小组，包括：集中交易、投资交易、管理系统、网络管理、灾备运维、公共平台、数据机房和服务台等。每个业务系统又根据管理职能设置了AB角色作为备份。各个业务系统之间通过IT服务管理流程实现串联，形成纵横的交叉管理结构。
其中，总控中心的质量经理负责中心IT服务管理流程的规划、实施、回顾和改进工作，流程经理基本为代职，主要负责流程的审批、关单等环节的操作，其具体架构示意如下：ITSS考试
图3.3某公司运营中心组织架构
在实际运维过程中，各业务系统管理员对于B角的定义和要求差距较大，以“集中交易系统”为例，统计AB角职责及对应熟练程度现状：
表3‑1集中交易系统A/B角职责及对应熟练程度现状
职责 | 熟练程度（现状） | ||
熟练 | 一般 | ||
技术 | 每日开闭市操作 | A/B | |
系统日常运维工作（如例行重启、巡检） | A | ||
已知故障处理（例如应急切换） | A | ||
未知故障排查及处理 | A | B联系A或者开发人员处理 | |
测试支持 | A | ||
变更、升级 | A | ||
业务 | 常见业务操作咨询及处理（如如何调整参数） | A | |
特殊业务操作咨询及处理 | A | B联系A或者开发人员处理 | |
系统日常业务处理（例如清算、权限管理） | A | ||
同时，在访谈业务系统A角时，也对对应的B角提出期望：
表3‑2集中交易系统A/B角职责及对应熟练程度期望
职责 | 熟练程度（期望） | ||
熟练 | 一般 | ||
技术 | 每日开闭市操作 | A/B | |
系统日常运维工作（如例行重启、巡检） | A/B | ||
已知故障处理（例如应急切换） | A/B | ||
未知故障排查及处理 | A | B联系A或者开发人员处理 | |
测试支持 | A/B | ||
变更、升级 | A/B | ||
业务 | 常见业务操作咨询及处理（如如何调整参数） | A/BITSS认证 | |
特殊业务操作咨询及处理 | A | B联系A或者开发人员处理 | |
系统日常业务处理（例如清算、权限管理） | A/B | ||
对比现状与期望，我们可以看出从业务系统A角的角度，希望B角成为自身不在时的全备份，只有不常出现的“未知故障排查及处理”和“特殊业务操作咨询及处理”，可以允许B角联系A或开发人员处理，这对B角平时对业务系统的了解提出了较高的要求。
3.2.2关键发现
通过对某公司运维组织的了解与访谈，可以看出非常重视人在IT服务管理中的作用，作为流程的执行者，技术的使用者，人成为提供IT服务质量的关键。同时，运营中心的人员组织还需要进一步的完善，明确角色与分工，建立有效的沟通机制。
关键发现1：业务系统管理员B角定义与职责不清。作为业务系统管理员A角的备份，缺乏明确的定义，规范其职责范围、工作场景、业务技能以及绩效考核。使无论A角，亦或B角都对该角色的具体要求产生疑惑。A角认为“B角人员对系统的掌握远弱于A角。（杨利强）”而B角则对分配的任务范围感到力有不逮。这种差异的产生，恰恰是B角角色没有明确定义所导致。
关键发现2：对于运维工作量没有较好的统计方式。事件、变更等作为每天工作量的一部分，在ITSM系统中能得到部分体现，其他工作如：日常例行巡检、系统优化、协助开发、学习会议等则无法有效统计，无论业务服务目录，或是技术服务目录均无法反映业务系统管理员的运维工作全貌。针对“集中交易系统”我们做了抽查，工作内容与时间分布如下：
表3‑3IT运维工作内容及占比
编号 | 工作内容 | 占比 |
1 | ·故障类处理 | 15% |
2 | ·服务请求类处理 | 20% |
3 | ·非升级类变更处理 | 10% |
4 | ·升级类变更处理 | 10% |
5 | ·例行工作（巡检、开闭市） | 20% |
6 | ·项目相关 | 5% |
7 | ·系统优化 | 10% |
8 | ·其他（研究、会议、报告） | 10% |
其中，55%的工作位故障、服务请求和变更的处理，可以通过ITSM系统及时录入工单予以记录，但余下45%的工作却无法较好量化。这使我们在分析“系统数量、复杂度、业务发展与现有人力资源不匹配，造成运维能力下降。无法提供有效的数据支撑
待续
本帖关键字：ITSS