本帖最后由 monicazhang 于 2015-11-6 11:25 编辑
20151106 淡然 续上
3.2 运维组织3.2.1 现状描述 目前，某公司运营中心按照业务系统类型划分运维小组，包括：集中交易、投资交易、管理系统、网络管理、灾备运维、公共平台、数据机房和服务台等。每个业务系统又根据管理职能设置了AB角色作为备份。各个业务系统之间通过IT服务管理流程实现串联，形成纵横的交叉管理结构。 其中，总控中心的质量经理负责中心IT服务管理流程的规划、实施、回顾和改进工作，流程经理基本为代职，主要负责流程的审批、关单等环节的操作，其具体架构示意如下： ITSS考试
图 3.3 某公司运营中心组织架构 在实际运维过程中，各业务系统管理员对于B角的定义和要求差距较大，以“集中交易系统”为例，统计AB角职责及对应熟练程度现状： 表 3‑1 集中交易系统A/B角职责及对应熟练程度现状 [td] 职责
| 熟练程度（现状）
| 熟练
| 一般
| 技术
| 每日开闭市操作
| A/B
|
| 系统日常运维工作（如例行重启、巡检）
| A
|
| 已知故障处理（例如应急切换）
| A
|
| 未知故障排查及处理
| A
| B联系A或者开发人员处理
| 测试支持
| A
|
| 变更、升级
| A
|
| 业务
| 常见业务操作咨询及处理（如如何调整参数）
| A
|
| 特殊业务操作咨询及处理
| A
| B联系A或者开发人员处理
| 系统日常业务处理（例如清算、权限管理）
| A
|
|
同时，在访谈业务系统A角时，也对对应的B角提出期望：
表 3‑2集中交易系统A/B角职责及对应熟练程度期望 [td] 职责
| 熟练程度（期望）
| 熟练
| 一般
| 技术
| 每日开闭市操作
| A/B
|
| 系统日常运维工作（如例行重启、巡检）
| A/B
|
| 已知故障处理（例如应急切换）
| A/B
|
| 未知故障排查及处理
| A
| B联系A或者开发人员处理
| 测试支持
| A/B
|
| 变更、升级
| A/B
|
| 业务
| 常见业务操作咨询及处理（如如何调整参数）
| A/B ITSS认证
|
| 特殊业务操作咨询及处理
| 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‑3 IT运维工作内容及占比 [td] 编号
| 工作内容
| 占比
| 1
| · 故障类处理
| 15%
| 2
| · 服务请求类处理
| 20%
| 3
| · 非升级类变更处理
| 10%
| 4
| · 升级类变更处理
| 10%
| 5
| · 例行工作（巡检、开闭市）
| 20%
| 6
| · 项目相关
| 5%
| 7
| · 系统优化
| 10%
| 8
| · 其他（研究、会议、报告）
| 10%
|
ITSS培训
其中，55%的工作位故障、服务请求和变更的处理，可以通过ITSM系统及时录入工单予以记录，但余下45%的工作却无法较好量化。这使我们在分析“系统数量、复杂度、业务发展与现有人力资源不匹配，造成运维能力下降。无法提供有效的数据支撑
| 
转播
分享
淘帖
()