1.设计理论

生搬硬套itil理论,翻来覆去书本上的几个概念,做出来的ITSM功能不适用运维实战,
市面上很多搞一套流程引擎,照搬书本理论搞一套ITSM软件不在少数,其实根本无法落地

为什么会这样?
其实是被洗脑了,光翻了文字,却并没掌握运维管理的核心思想
世间所有管理目标:都是为了资源利用率
提高管理效率的核心:专业化处理
引申出来,itil运维核心思想
专业的人做专业的事

什么是专业的事
精通一个或多个领域的工程师
比如 有丰富的维护电脑终端的资深桌面工程师,处理他熟悉的终端电脑故障工单自然效率高

如果让精通oracle的数据库管理员去整天和输入法office双绞线打交道,大概率是效率不高的,或者需要很高的薪资才能聘用到这样的多专业人才

效率源于专业,专业的分工,专业的处理
想要高效运维,必然建立在专业运维之上

如何实现专业化运维,光说不练没有意义
通过数字化的手段是唯一的途径
运维资源信息通过数字化的方式存储在数据库中
运维人员可以快速获取运维资源信息
快速作出灵活应对
从而保证运维服务水平与效率

2.服务目录设计

统统一股脑地来一遍 请求 故障 事件 问题 变更 发布....千篇一律 纯属扯淡
这是大多数ITSM的通病

事实上服务目录必须是真实运维场景分工的体现 基于中等规模运维环境 比如是 现实有OA 那就有必要创建 oa运维服务 或 创建 OA故障报修 OA疑难诊断 OA变更 等一些列服务

又比如 桌面电脑端如果数量不多 直接一个 电脑服务(请求) 一个服务即可
如果桌面工程师较多 分工比较细致 应包含 个人电脑故障 邮箱申请...可以根据实际情况进行细化

个性化服务目录设计,并且作为工单入口 是可以明显区别劣质ITSM的 第一重关卡
任你吹得天花乱坠 如果不能做个性化服务目录设计,其实就是个失败ITSM

2.工单管理

工单管理范围

正式的各类itil工单肯定要支持的
为了保持统一IT服务入口 把需求工单也纳入管理
如果安全团队规模较大 也可以把安全工单作为一类管理起来

平时的杂事 开会 培训 写文档 领导交办的其他任务等等 巡检 盘点 都以任务单的形式保存在系统当中

工单生命周期管理

工单的发起处理关闭均要比较流畅方便才是好的工单管理
发起

处理

关闭

关于工单流程

勿忘初心 分门别类记录运维工作 是最根本的目的
但是人类的掌控欲望从没消失过,在运维工单领域上屡次败北
因为屈服物理定律的 IT硬件不可控,
应为经济规律掌控的业务逻辑不可控,
运维如果每次都想强行掌控控制权,难免"臣妾做不到"...所以很多人感觉ITSM落地不好,是因为没有认知到这个客观规律,视图全局掌控,所以失败难免

人性肯定是想控制 恨不得每步都来个审批
流程其实权力利益分配
一个技术管理实践 如果掺杂了太多权力利益分配 是脱离了技术管理的本质 做不好的