20150924 淡然

续上

Ø 工作细则定义和流程执行比照

在深圳某公司公司存在各种工作细则和规范，在新技术开发中心同样也针对具体的岗位定义了员工的行为规范和与之匹配的工作流程。而在实际工作和业务处理时，人们往往因为各种因素忽视和违背了这些工作细则。                       ITSS考试

IT运维工作是数量种类繁多，操作规范性要求严格的工作，通过对运维室各个小组的调研和访谈，一方面得出上面各种运维工作的得分，同时，也对工作细则的定义和实际流程执行做了对比，如下图所示。通过这张雷达图，我们可以很清晰地认识到，在运维工作范畴中，有哪些领域，我们的工作细则没有很好的定义，从而导致实际执行比工作细则更领先，即，存在管理跟不上、滞后的现象。同时，通过这张对比图，我们也可以了解到，在某些领域已经制定了工作细则，但是，由于执行力度不够，导致执行效果不好。

通过分析上述效果比照图，得出以下结果：

[td]

运维项目	细则定义和流程执行效果比照结果
1.1 客户管理和检查	存在相应的工作细则，但是执行力度不够；
1.2 性能趋势分析	目前关于性能趋势分析的工作细则较少，执行的是时候基本上都是手工分析，不准确；工作细则和执行都需要加强；                                       ITSS认证
1.3 性能数据搜集, 检查和汇报	目前对性能数据的收集基本都是手工方式，无法准确地获取相关性能数据，检查和汇报的内容存在偏失，收集手段需要改善；
2.1 系统配置和支持	作为运维工作的传统项目，关于系统配置和支持的工作细则没有跟上，如系统配置的审批机制、记录机制、跟踪机制、安全机制等；
2.2 打印机定义和管理	目前该部分工作尚未纳入运维室的工作；
2.3 预防性的数据库管理	目前在数据库预防性管理方面，主要依赖于有经验员工的技能，基本上都是手工处理，在工具上、细则和执行上尚需完善；
3.1 系统的备份和恢复	系统是IT的生命线，公司和中心都存在相应的工作细则，但是，目前中心在系统的备份和恢复上，往往只有备份，没有恢复的计划和相关测试。
3.2备份介质管理	依赖于员工的工作经验，一些工作细则和硬件资源没有跟上；
3.3 后台任务调度	依赖于员工的工作经验，相关管理手段滞后，如失败任务分析记录等；
4.1 用户管理	依赖于员工的工作经验，相关管理滞后，如用户权限的限制规则等；
4.2 物理场地安全	对于一些物理场地，如机房，存在管理机制，但在执行时存在漏洞；
4.3 系统安全	存在管理滞后，没有严格的系统安全细则；
4.4 病毒检测和防范	较其它领域，该部分较能够完成IT支撑；
5.1 呼叫管理	在呼叫管理方面较弱，虽然有相应的管理意识，但是执行力度和手段都滞后；
5.2通知和升级管理	流程执行、实现的技术支撑都存在不足；
5.3 被动的性能支持	在性能支持上，只有当发生故障时，才能够得以解决；
6.1 服务器事件检测和通知	没有相应的工具实时监控服务器；
6.2 数据库事件检测和通知	没有相应的工具实施监控数据库；
7.1 系统预防性维护	依赖于厂商和服务提供商；
8.1 灾难恢复	目前没有灾难恢复；
8.2 物理环境管理	没有灾难恢复的物理环境；
9.1 投入运行	在投入运行方面，通知、通告、测试、恢复计划等都有欠缺；

Ø 改进完善优先级分析

根据得分情况和上述工作细则和流程执行效果的分析，我们了解到针对深圳某公司新技术开发中心目前的运维工作在很多领域需要提高和完善，通过相关的评估工具的分析，按照紧急程度得出以下建议改进和完善的优先级雷达图。

在该雷达图的纵轴上有0～100的分数标识，分数越大的项目表示需要完善的迫切性越高，以两级为例帮助我们解读该图：

[td]

分数	紧急度	改进/完善的项目	描述
100	最紧急	灾难恢复及物理环境，打印机定义和管理；                       ITSS培训	目前在运维方面都没有定义，是否需要纳入运维过程，视运维室的工作职责而定；
90	紧急	性能趋势分析、性能数据收集，检查和汇报、系统的备份和恢复、呼叫管理、服务器事件检查和通知	由于这些方面在目前的运维工作中较弱，所以需要加强；

待续http://ITIL-foundation.cn/thread-52420-1-1.html

本帖关键字：ITSS

20150924 淡然

续上

Ø 工作细则定义和流程执行比照

在深圳某公司公司存在各种工作细则和规范，在新技术开发中心同样也针对具体的岗位定义了员工的行为规范和与之匹配的工作流程。而在实际工作和业务处理时，人们往往因为各种因素忽视和违背了这些工作细则。                       ITSS考试

IT运维工作是数量种类繁多，操作规范性要求严格的工作，通过对运维室各个小组的调研和访谈，一方面得出上面各种运维工作的得分，同时，也对工作细则的定义和实际流程执行做了对比，如下图所示。通过这张雷达图，我们可以很清晰地认识到，在运维工作范畴中，有哪些领域，我们的工作细则没有很好的定义，从而导致实际执行比工作细则更领先，即，存在管理跟不上、滞后的现象。同时，通过这张对比图，我们也可以了解到，在某些领域已经制定了工作细则，但是，由于执行力度不够，导致执行效果不好。

通过分析上述效果比照图，得出以下结果：

[td]

运维项目	细则定义和流程执行效果比照结果
1.1 客户管理和检查	存在相应的工作细则，但是执行力度不够；
1.2 性能趋势分析	目前关于性能趋势分析的工作细则较少，执行的是时候基本上都是手工分析，不准确；工作细则和执行都需要加强；                                       ITSS认证
1.3 性能数据搜集, 检查和汇报	目前对性能数据的收集基本都是手工方式，无法准确地获取相关性能数据，检查和汇报的内容存在偏失，收集手段需要改善；
2.1 系统配置和支持	作为运维工作的传统项目，关于系统配置和支持的工作细则没有跟上，如系统配置的审批机制、记录机制、跟踪机制、安全机制等；
2.2 打印机定义和管理	目前该部分工作尚未纳入运维室的工作；
2.3 预防性的数据库管理	目前在数据库预防性管理方面，主要依赖于有经验员工的技能，基本上都是手工处理，在工具上、细则和执行上尚需完善；
3.1 系统的备份和恢复	系统是IT的生命线，公司和中心都存在相应的工作细则，但是，目前中心在系统的备份和恢复上，往往只有备份，没有恢复的计划和相关测试。
3.2备份介质管理	依赖于员工的工作经验，一些工作细则和硬件资源没有跟上；
3.3 后台任务调度	依赖于员工的工作经验，相关管理手段滞后，如失败任务分析记录等；
4.1 用户管理	依赖于员工的工作经验，相关管理滞后，如用户权限的限制规则等；
4.2 物理场地安全	对于一些物理场地，如机房，存在管理机制，但在执行时存在漏洞；
4.3 系统安全	存在管理滞后，没有严格的系统安全细则；
4.4 病毒检测和防范	较其它领域，该部分较能够完成IT支撑；
5.1 呼叫管理	在呼叫管理方面较弱，虽然有相应的管理意识，但是执行力度和手段都滞后；
5.2通知和升级管理	流程执行、实现的技术支撑都存在不足；
5.3 被动的性能支持	在性能支持上，只有当发生故障时，才能够得以解决；
6.1 服务器事件检测和通知	没有相应的工具实时监控服务器；
6.2 数据库事件检测和通知	没有相应的工具实施监控数据库；
7.1 系统预防性维护	依赖于厂商和服务提供商；
8.1 灾难恢复	目前没有灾难恢复；
8.2 物理环境管理	没有灾难恢复的物理环境；
9.1 投入运行	在投入运行方面，通知、通告、测试、恢复计划等都有欠缺；

Ø 改进完善优先级分析

根据得分情况和上述工作细则和流程执行效果的分析，我们了解到针对深圳某公司新技术开发中心目前的运维工作在很多领域需要提高和完善，通过相关的评估工具的分析，按照紧急程度得出以下建议改进和完善的优先级雷达图。

在该雷达图的纵轴上有0～100的分数标识，分数越大的项目表示需要完善的迫切性越高，以两级为例帮助我们解读该图：

[td]

分数	紧急度	改进/完善的项目	描述
100	最紧急	灾难恢复及物理环境，打印机定义和管理；                       ITSS培训	目前在运维方面都没有定义，是否需要纳入运维过程，视运维室的工作职责而定；
90	紧急	性能趋势分析、性能数据收集，检查和汇报、系统的备份和恢复、呼叫管理、服务器事件检查和通知	由于这些方面在目前的运维工作中较弱，所以需要加强；

待续http://ITIL-foundation.cn/thread-52420-1-1.html

本帖关键字：ITSS