运维组织的架构介绍和ITSS关键发现
本帖最后由monicazhang于2015-11-611:25编辑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%
ITSS培训
其中，55%的工作位故障、服务请求和变更的处理，可以通过ITSM系统及时录入工单予以记录，但余下45%的工作却无法较好量化。这使我们在分析“系统数量、复杂度、业务发展与现有人力资源不匹配，造成运维能力下降。无法提供有效的数据支撑
待续http://www.ITILxf.com/thread-52993-1-1.html本帖关键字：ITSS
页:
[1]