Itil :
全称:
(Information Technology Infrastructure Library,信息技术基础架构库)。
是什么?
是一种提升IT服务的方法论和最佳实践,帮助IT服务的提供者以合适的成本提供满足要求的高质量的服务。
但实际上,该方法论不止用在IT服务,其他的服务提供者都可以借鉴和参考。
一,itil的核心和本质。
核心和本质是:服务,即用户价值的交付。
架构设计的几个重点要求,或者服务提供的要求,在itil中均有重点讨论:
1,可用性。是指系统面对异常的时候,是否有能力继续提供服务而不中断?
考虑点:1,业务的可用性级别如何? 是要求99.999%,还是可以要求低一些?
2,实现的成本和资源是否可以保证可用性级别的实现?
3,出现异常的有损服务和恢复流程,恢复时间等进行前瞻性评估。
2,可伸缩性。 即系统面对性能压力是否可以快速进行横向扩展,包括新的业务特性开发,是否可以在现有的基础上进行快速迭代,而不需要推倒重来。
3,安全性。 这个不同的业务形态要求是不一样的,对支付类,可能要求非常高,安全性是一个非常重要的话题,需要层层不信任,层层保护。
4,可管理性。 运营中缺少各种手段和工具的支持。
5,经济性。 需要满足一定的成本预算。
itil引导我们从内部走向外部,从技术走向业务,从救火走向预防。
二,itil几个重要阶段
1,服务战略(SS)
这是itil的最核心的部分,是整个服务生命周期管理的轴心,驱动整个生命周期不停的运转。
几个问题需要问自己:
包括:
服务生命周期管理;
服务财务管理;
服务投资组合管理;
服务需求管理;
(思考:这个点一般是开发人员比较欠缺的,需要加强针对价值点的提炼,关注问题的价值,不要被具体的操作细节所绑架)
2,服务设计(SD)
为了确保提供对应的服务级别,是否有足够的能力和资源,需要关注两点:
Ø成本意识:确保IT能力的费用是合理的;
ØIT能力能够符合当前及一定将来已经明确的业务需要。
题外思考:没有这个能力就不要提供这样的服务承诺,首先要有这块的能力。
3,服务转换(ST)
解决的问题:如果要调整环境,设备,人员,如何确保不影响到现有的服务或者把影响降到最低?
变更管理可能引起配置变更和发布管理。
配置管理要解决的问题:东西都放在哪里?如何快速找到?并且是井然有序的?
配置管理包括两个要素: 配置项(CI)和关系(RL)
参考config.itil.com
4,服务运营(SO)
服务台要解决的问题是:有问题,应该提交给谁,即谁受理?
正常服务请求的入口和门口,解决了在运营过程中,出现问题应该找谁,接口人的角色。
如有IT问题找8000,8000就是服务台;
事件管理要解决的问题:如果服务出现异常或者中断,如何快速恢复服务?
什么是事件?我们经常听说被突发事件干扰等等,这里的事件指的是:任何可被检测或者辨认,对IT基础架构以及IT服务交付有影响的各种事情。
目标:
事件分级,不同级别对应不同的处理流程,通过检测和感知事件,并确定对应的控制行动,并自动启动其他配套流程,作为服务运营流程的切入点。
思考:若突发事件比较多,则说明在在服务设计阶段没有做好,缺少前瞻性。
问题管理要解决:如何找到事故的原因,并确保不再出现?
目标:稳固IT服务(总结经验,避免同样问题多次发生)和提高资源利用率
有两种模式:被动的问题管理和主动的问题管理。
如我们要等到出了问题,如用户投诉了,才去定位解决 - 被动的问题管理;
设计阶段就考虑到了并通过设计进行预防,避免问题发生 - 主动的问题管理。
我们需要从被动问题管理向主动问题管理转变,从救火模式转向预防模式。
5,服务的立体监控和持续服务改进(CSI)
这个不是独立的一个步骤,而是贯穿上面各个阶段。对各个步骤需要进行持续监控,持续度量和改进IT服务提供者的绩效:
Ø改进流程,IT服务和IT基础架构;
Ø提高效用和效率以及成本效益;
持续服务改进遵循下面的循环
结论:我们需要重点关注1和2,即服务战略和服务设计上,把问题在设计阶段就进行解决,避免后续的“救火”式运营,掌控运营的主动权。