ITIL各版本的一些细节-基础篇-摩杜云开发者社区

ITIL并不是标准，而是一套规范和框架，真正的标准是ISO 20000，可以说ITIL是“事实上的标准”。
信息安全管理不是ITIL的强项，是ITIL V2的第十一个流程（并不在十大核心流程里面）。ISO 27000是信息安全的标准。
ITIL V3/2011包含五个模块，其中服务战略、服务设计、服务转换、服务运营是生命周期的四个阶段。而持续服务改进模块，只能算是一种思想。
服务的功用是指是否可用，服务的功效是指是否好用。
BS 15000是基于ITIL V2版本发布的，而ISO 20000 2005版本其实就是BS 15000。
ISO 20000引进了流程组的概念，而当时ITIL V2是没有的，且比V2多了三个流程：业务关系管理、供应商关系管理、服务报告。
服务管理中的干系人不一定是人，也可能是组织、合作伙伴、供应商等。
客户资产是指客户拥有的东西，服务资产是指服务提供商拥有的东西。
服务组合的流程是典型的非跨生命周期流程，这个流程只是和服务战略这个阶段相关。
现实中，ITIL中IT服务的财务管理的流程很难落地。
IT收费的好处：通过收费改善IT地位、通过收费来影响客户和用户的行为。
需求管理中，可以根据PBA（业务活动模式）和UP（用户需求）形成多个SLP服务级别包，适合大规模的组织。
BRM（业务关系管理）是为了把服务做的更好。IT人，应该经常在业务侧呆着。业务关系管理的主要工作包括：客户需求管理、满意度调查、客户投诉管理、关系管理。
治理比管理的层级要高。COBIT是IT治理的框架。治理主要靠审计、事后检查。
RACI（R负责、A批准、C咨询、I知会）职责模型中A只能且必须有一个，A和R可能在一个人身上。
面向客户的服务即核心服务，SLA是和核心服务对应的。而支持性服务偏后台，比如网络、存储等。
SLA包括基于服务的SLA、基于客户的SLA、多级SLA。应该先签公司级别的SLA，比如公司每个人都用的IT服务；然后再签客户、业务单元级别的SLA，比如财务除了通用的IT服务，还用到了他们自己的服务（报税系统等）。
SLR是指服务级别需求，目前国内做的比较少。客户提需求就会产生SLR。
SLA和SLR的区别：SLA是服务上线之后产生的，但是服务上线不代表都满足SLR。
可维护性MTRS，强调的是服务恢复；MTTR强调的是故障点的恢复；MTBSI可靠性就是平均出故障的时间频率间隔；MTBF平均无故障时间就是可靠性。自己恢复就是可维护性，第三方恢复就是可服务性。
26个大流程里面只有容量管理提供了子流程，但没有太大现实意义。
ITIL与DevOps：DevOps强调轻量级的ITIL，强调业务连续性，流程简化。
服务合同：关注多少钱，怎么付款。其他的都可以妥协，因为如果客户不想付钱，有多种多样的理由。
建议充分利用现有工具进行服务转换，如果现有工具实在是支撑不了，再考虑设计新流程。
新的服务、改造现有的服务，都需要转换落地。比如编码、测试、上线。比如盖楼，把图纸变成现实。
从IT运维的角度来看，变更和故障管理是很重要的，这两个做好了，基本不会出大问题。
变更管理和配置管理密切相关。变更流程和CMDB配置管理系统密切相关。
标准变更是指容易授权，可以直接做，经常发生的，风险很小的变更。标准变更一般不走流程审批；紧急变更走紧急流程；正常变更走正常流程。变更流程从单步授权到多步授权（走一步看一步）。不同级别的变更应该找不同的人审批，分散变更授权。
怎么区分服务请求和变更？比如日常重置密码属于服务请求，但如果用户账号存到CMDB的CI里面去了，就是变更。只要涉及到CI的更改，就需要走变更请求。
现实中会对变更进行分级，比如从1到5级，级别高的才需要制定补救（回退）计划。
CAB（变更顾问委员会），有两种。第一种是只提建议；第二种是可以直接批准变更的。通常变更经理只是组织大家开会。
CMS包含CMDB，不但能看到CMDB，还能看到各种记录。
CI配置项的识别是个费时费力的工作，需要厘清CI的范围、层次等。
变更管理主要是授权，而发布和部署管理主要是干具体的活。
ITIL书中的事件管理（Incident Management）就是故障管理。
KEDB是已知错误数据库，一线解决故障靠匹配，不靠研究，一线解决率要提高，知识库很重要。
对于已经关闭的流程，不建议reopen，应该再开一个新的，跟老的关联起来。
要不要做问题管理，取决于问题发生的频率。事件管理（故障管理）≠问题管理。
DevOps开发运维一体化，包括一个基础：精益。三个支柱：敏捷、持续交付、ITSM。
VeriSM是数字时代的服务管理方法。
SIP是指服务改进计划，即service improve plan。
SFA是指服务失效分析方法，是可用性分析的方法之一。
VBF是指关键业务功能。
容量管理，广义上来说是能力管理。做好容量管理，需要驾驭新的技术，注重创新，不仅仅满足现在，还要满足未来。好的容量管理流程，引入新技术提升性能、可用性并重视成本，但需要谨慎对待新技术。
应该定义容量管理和服务级别管理之间的接口，当前和未来的容量和当前的投入进行对比平衡。
应该在所有生命周期的阶段引入容量管理，并进行弹性设计。管理的难点是业务预期。
价值流是从需求开始，到价值实现结束。价值流侧重交付的步骤，而服务价值链侧重运营的关键活动和模式。
服务消费者：比如自己买手机，即是客户、也是用户、也是赞助方。
现实中，服务关系不一定是线性的，可能是网状的关系。
风险不确定性：风险发生时，可能是好事，也可能是坏事。
ISO 20000 2011对应的是ITIL V2；ISO 20000 2018对应的是ITIL V3。
机会是主动抓的，需求是被动响应的。
持续改进靠文化建设，需要培养员工的意识。持续改进，除了时间和预算因素，还有人。
公司层面治理和管理的不同：治理是资方的责任（比如董事会），管理是CEO为代表的管理层的责任。COBIT针对的是IT的治理。
IT服务收费的两种形式：方法一是成立一个公司，给业务开发票；方法二是分摊，并不是真的收钱。
在IT服务管理体系的全部文件框架中，通常情况下，不会都仔细去做，会按照要求做最重要的那几个，其他的主要是贯标，符合要求就行。
异常代表着故障，但不一定真的有故障。在ITIL 4中不再强调一定要根本解决问题了，在解决know error方面需要考虑成本效益，投资回报。ITIL 4提出了永久workaround概念。
问题管理与知识管理密切相关，比如KEDB是由问题管理流程维护的，但KEDB又属于知识管理的一部分。
服务级别协议SLA一般是对内，服务级别合同SLC一般是对外。
西瓜SLA效应：在许多情况下，使用单一的基于系统的指标作为目标可能导致服务伙伴之间的不一致和断开连接，从而影响服务交付和用户体验。例如，如果SLA仅基于服务正常运行时间的百分比，那么提供者可以认为它是成功的，但仍然会错过对使用者很重要的业务功能和成果。