ITSM 是每个 IT 管理者和 IT 从业者进阶的必修课（itss经理题库及答案）

作者 | waitrabbit

来源 | 云中探索者

Sun公司CEO麦克尼利说过，“将来软件业将不再存在，也不应该存在。所有的事情就是服务，而没有产品。人们编写软件，这是肯定的，但他们在创造服务，而非产品。”

IT 服务管理（英文缩写 ITSM）就是这样一种把 IT 看作“服务”的管理视角和维度。而 ITIL 指的是 ITSM 的方法论和最佳实践操作手册，现已经成为事实上的行业标准。（IT Infrastructure Library 由英国人最早在80年代末发起的，19 年二月发布了第四版 ITIL 4) 。

在 IT 行业多年的工作经验让我深深的感觉到，ITSM 可能是最重要、最底层而又被最多 IT 从业者忽略的一门学问了。尤其是对于研发团队来说，如果你问一个产品经理、架构师或者开发人员什么是ITSM，他们多半会用无辜的眼神看着你，最多有人会说那是运维支持部门的事嘛，我的角色并不需要去了解这些。而事实上就像要把 IT 的本质要理解成服务一样，ITSM 是每个 IT 角色日常工作的基础，如果不了解，工作中难免会偏离方向。

尤其是还有很多 IT 管理者，虽然谈的都是产品理念、敏捷开发、云计算、大数据，但是对 ITSM 居然缺乏了解。要知道，对于一个 IT 管理者来讲，工作的出发点是什么、目标如何制定、IT如何规划设计、技术要解决什么问题，最后的工作成果和效益如何衡量的，所有这些重大问题都在 ITSM 的范畴之内。而 ITIL 这本书已经把最佳的方法、验证过的实践都网罗其中。如果我们不学习，不深入了解，在工作上必然会舍近求远。在信息爆炸、技术迭代如此之快的今天，又拿什么给我们的技术决策足够的底气？

是的，倚天剑就摆在我们面前，如果你接触过ITSM或者ITIL，是时候更加走近它、了解它、使用它了。即便是一个最简单的理由——它塑造了 IT 人员最基本的服务意识——我们也应该开始了。

下面我们就讲讲必须学习掌握 ITSM 的理由，当然，罗列这些“原因”并不仅仅是劝说大家学习 ITSM 这么简单，而更重要的是这些观点可能让我们明确了应用 ITSM 的“初心”。所以，对于那些通过了 ISO 认证，但在如何发挥它的效能上始终存在困惑的企业和组织，想来本文也是会让你有所收获的。

ITSM 是IT和业务的边界

对于 IT 管理者，ITSM 是IT和业务的边界，它定义了IT部门的工作目标和范围。

ITIL 提供了是一种一致的和结构化的框架的方式，来规划、构建和运行IT服务，确保 IT 投资创造实际价值。

它研究的主要内容是通过一系列流程和实践来保证IT 服务满足业务的各个层次的要求，包括需求、效率、稳定性、响应、成本等。

对于组织的 CIO 等管理者来讲，掌握 ITSM 的必要性在于：

1）ITSM 是业务与 IT 的边界，如果没有它，两者的边界就会不清楚，会失去管理的界面和抓手。

图1，ITSM和业务系统的关系

如上图所示，它横向贯穿了公司的所有业务系统和各类 IT 资源，在企业众多繁杂的应用中间，起到了“梳理”“归类”的作用。明确了 IT 是为业务“服务”的意识。

从盒装软件到BS架构应用，到今天的Saas、API 经济，尽管软件交付的形态发生了重大的改变，但背后都是服务价值的交付。所有的 IT 资源都是服务。没有服务价值的应用是不值得去构建的，失去服务价值的应用也是不值得去维护的。

2）ITSM 构建的服务组合蓝图，才能让 IT 工作对业务的覆盖没有遗漏，工作中没有遗失

图2：业务和系统矩阵

如上图所示，CIO 要把构建业务和IT系统的可视化关系作为一项工作来做，在表中业务与系统的交叉点即是我们关注的服务的集合。ITSM 中同样还有“服务组合管理 Portfolio management”来记录各服务之间的关系。

这里要注意，根据需要，如果一个业务用到的多个系统，我们要逻辑上把它合并成一个 IT 服务。目的是不要让业务部门误解。

3）ITSM 可以帮助我们合理划分 IT 部门的工作内容和工作角色。

一个产品究竟需要不需要研发；一个工具需要不需要购买；是否需要设定某个工作角色，是否组件某个团队。我们都可以借助 ITSM 的最佳实践——它是否属于某个 IT 服务，是否服务于该 IT 服务的生命周期的某个阶段，如规划、设计、构建、交付、运营还是持续改进——来回答。

4）ITSM 可以帮助我们客观公正的评价 IT 部门的绩效，指导我们如何持续改进。

在 ITSM 这个图书馆里有众多经过验证的有效技术指标可以拿来即用，如大名鼎鼎的 SLA，故障排查时间，发布时间等等。

而持续改进的方法，几乎就是 ITIL 各版本的重头戏。

甚至对于产品是开发还是购买，与第三方供应商如何合作，ITSM 都有对应的最佳实践给你（Supplier management）。

图3 ITSM 中的供应商管理

ITSM 是基础

重点是业务与技术需求的输入

对于产品研发团队，ITSM 是我们理解需求的基础，是重要的业务和技术需求的输入。

传统上理解，ITSM 是应用交付之后的事情，但事实远远不止如此，尤其是在 ITIL 4 出来之后，直接把架构管理（Architecture management）和软件开发管理（Software development and management）纳入其中。在 ITSM 的指导下，我们的管理可以做到没有独立于 ITSM 框架外的产品，也不应存在独立于 ITSM 体系外的开发任务。

1）ITSM 是产品经理理解业务需求的重要输入

如果你从“服务”的角度来看待你的产品和应用，很多之前未曾考虑到的需求就会暴露出来，会让你的产品设计更加完善。

举几个例子：

• 作为服务的产品，当系统出错时，要如何设计异常界面和报错信息，才能让用户有好的体验和解决问题的途径。

• 如果产品（服务）出现问题，如何设计降级模式机制，做到用户无感知，而技术支持可以有时间来解决。

• 在“事件管理（Incident management）”和“故障管理（Problem management）”中，如何添加功能为后台人员设计一些功能方便定位问题和排查。

• 用户在使用服务过程中会有哪些意外和服务请求，比如遗忘密码怎么办。

还有很对例子，这些产品经理都可以通过 ITSM 中的检查方法来全面仔细考虑。

2）ITSM 是架构师理解技术需求的重要输入。

同样的 ITSM 对于架构师和开发团队的重要性不亚于产品经理，很多重要的非功能需求都被 ITSM 框架体系所覆盖，对照 ITSM 框架做系统架构时，才不会有重要遗漏。

比如：

• ITSM 中的“可用性管理 （Availability management）”“故障管理（Problem management）”，架构师要考虑如何做到系统（服务）异常的自动快速发现和恢复。比如你的系统支持不支持重启后的无需人工参与，自动恢复功能的能力；异常如何定义等等。

• “事件管理（Incident management）”“故障管理”将迫使架构师考虑要记录那些信息，做那些监控，做到故障的快速排查和定位。

• “容量管理（Capacity and performance management）”需要架构师考虑性能、容量的实现方案和成本的平衡

• “变更控制（Change control）”和“发布管理 （Release management）”需要开发团队思考怎么做到灰度发布、怎么做自动化测试，以保证变更后服务的连续性不受影响

还有很多，就不一一列举了，对于研发团队来讲，在大谈产品设计理念之前，不如研发、产品与 ITSM 紧密配合，先设计出交互友好、健壮、灵活性高的服务来。

图4，ITSM 中的事故处理流程

ITSM 提供新技术应用的整体框架和底层标准

对于新技术的挑战，ITSM 提供了新技术应用的整体框架和底层标准。

新技术革命无时无刻不再折磨着每一个 IT 人，云计算、AI、区块链、5G，尤其是 IT 管理者们，每一个夜晚都会辗转反侧：是及时跟进，弯道超车，还是密切关注，待其成熟，亦或暂时观望、去伪存真，我判断的依据在哪里，又如何度量新技术的功效？

比如最常见的：

• Devops 究竟要做到什么程度，发布的频率到底要做到多频繁？

• 企业的应用到底要不要上云，上的话，要考虑哪些问题。

• AI 究竟能在哪些方便提高服务的效率，如何评估投入和产出？

ITSM 就提供了一个统一的、结构性的框架帮你来考虑这些新技术带来的问题。当然这并不意味直接给你答案，它会告诉你有哪些点可以作为起点来考虑这些问题，对应的价值体现在哪里，度量的标准依据又在哪里。而缺乏 ITSM 的组织和企业，它的答案可能是随机的、不完整的，也会因无法有效评估而产生浪费。

拿企业应用上云这件事来说，哪些应用要上云，请参考 ITSM 中的业务和应用的可视化矩阵，以及\”服务组合管理（Portfolio management）\”；需要应用多大的规模，可以参考 ITSM 中的“容量管理（Capacity and performance management）”；有哪些风险需要应对，可以去翻阅“风险管理（Risk management）”。

Devops 的发布周期到底如何制定，请参考“部署管理（Deployment management）”和“发布管理（Release management）”

（ 这里我抑制住了把最新 ITIL 涵盖的实践都列举在这里的冲动，我们会在后文展开讨论）

图5. ITIL 4 19年发布

总结一下，通过上述的例子，我们也看到了 ITSM 简直就是 IT 部门的“百科全书”和 IT 管理“ERP 解决方案”。它的力量在于“全”，在于统一，在于贴近于实践，当然背后的基础是 IT 服务交付的价值理念和原则。IT 管理者错失它是要落伍的的，对每一个在事业上进阶的 IT从业者，这也是一本必修课。

人无完人，这里也得吐槽一下，之所以 ITSM/ ITIL 没有像本文所描述起到那么大的作用，被大家所重视，很大的一个原因是因为它更新的确实太慢了，最近的一个成熟版本 ITIL V3是 2007 颁布的，最近的一次大的更新也是 2011 年的事情了。

想想 07年那会云计算的概念也刚刚出来，这段时间又诞生了多少产生重大影响的技术，云计算、大数据、AI、5G，软件开发的方法论又更新迭代了多少代，RUP-敏捷-Devops。ITSM 具体操作操作和技术应用上难免会有些脱节，框架层面也亟待补充。针对这一点，今年2月版本 ITIL 4 是应时代而生，它的内容的发生了比较大的变化，光管理维度就多达 34 个，服务的价值交付理念上也更加完善。

我们相信，随着 ITIL 4 新内容的颁布，必然会引来企业应用 ITSM 一轮新的热潮。这是我们的好机会。

☞从 Nginx 到 Pandownload，程序员如何避免面向监狱编程？

☞新iPhone SE卖3299元起，香不香？

☞IntelliJ IDEA 2020.1正式发布，15项重大特性、官方支持中文了！|原力计划

☞企业打造自己的数据中台，需要的是一套硅谷方法论（文末有福利！）

☞只会高中数学运算就能发现算法？Google开源的AutoML-Zero有多厉害

☞Spring Cloud 云架构下的微服务架构：部门微服务（Dept）

☞从Spring Cloud到Service Mesh，微服务架构治理体系如何演进？