Contents
概念
ITSM
IT服务管理(ITSM)是一套帮助企业对IT系统的规划、研发、实施和运营进行有效管理的方法,是一套方法论。ITSM起源于ITIL(IT Infrastructure Library,IT基础架构标准库)[1]百度百科 IT服务管理。
ITIL
ITIL是CCTA(英国国家电脑局)于1980年开发的一套IT服务管理标准库。它把英国在IT管理方面的方法归纳起来,变成规范,为企业的IT部门提供一套从计划、研发、实施到运维的标准方法[2]百度百科 IT服务管理。
目前最新版为 ITILv4。
ITSS
ITSS是Information Technology Service Standards的缩写,中文意思是信息技术服务标准,是在工业和信息化部、国家标准化委的领导和支持下,由ITSS工作组研制的一套IT服务领域的标准库和一套提供IT服务的方法论[4]百度百科 ITSS 。ITSS 是国内的 IT 服务标准。
ISO20000
ISO20000,即“信息技术服务管理体系标准”,是面向机构的IT服务管理标准[5]百度百科 ISO20000。ISO/IEC 20000:2018是当前版本的服务管理国际标准。这是第三个版本,之前的版本基于现在过时的bs15000和ITIL v3[6]https://www.bmc.com/blogs/itsm/。
DevOps
DevOps(Development和Operations的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。
它是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
它的出现是由于软件行业日益清晰地认识到:为了按时交付软件产品和服务,开发和运维工作必须紧密合作[7]百度百科 DevOps。
SRE
SRE 是 Site Reliability Engineering(站点可靠性工程)的缩写,起源于2003年。SRE 是一个可靠的运维大规模系统的框架,就是让软件工程师来设计运维功能所发生的事情。在运维层次上负责生成系统的运行。SRE 是构建和运行高可靠性系统的普遍适用的最佳方式[8]刘征 运维、开发和管理者们必备的 SRE 核心体系解读。
关系
这么多概念,它们之间有什么关系呢?
ITSM与ITIL
IT service management (ITSM) is what you do to manage the services you deliver to your customers, even if you don’t use that term. ITIL is a best practice framework for ITSM, and adopting some ITIL ideas can help you work more effectively. [9]https://www.bmc.com/blogs/itsm-or-itil-that-isnt-the-question/
DevOps与SRE
The term “DevOps” emerged in industry in late 2008 and as of this writing (early 2016) is still in a state of flux. Its core principles—involvement of the IT function in each phase of a system’s design and development, heavy reliance on automation versus human effort, the application of engineering practices and tools to operations tasks—are consistent with many of SRE’s principles and practices. One could view DevOps as a generalization of several core SRE principles to a wider range of organizations, management structures, and personnel. One could equivalently view SRE as a specific implementation of DevOps with some idiosyncratic extensions. [10]https://sre.google/sre-book/introduction/
ITIL与SRE
Both ITIL4 and SRE (as an example of a devops oriented framework) have their merits, and both claim to support the DevOps processes. Culturally, SRE is more aligned to DevOps values and agile principles in encouraging self-organisation, error budgets, smaller and faster increments, and an engineering mindset. You can also specifically recruit SREs. ITIL4 promotes a more command-and-control-oriented structure than do DevOps and agile.[11]https://neilfaganblog.wordpress.com/2020/03/17/is-itil-dead/
关系
如果画一个图,可能是这样的。
或者是这样的:
iTop对相关标准的支持
ITIL, ISO20000, ITSS 等都是一些管理方法论,需要依靠具体的软件工具来落地。iTop 是一个开源的 ITSM 软件,对 ITIL 和 ISO20000 的支持度很高,对 ITSS 也有一定程度的支持,见下表[12]长河,付剑波 开源IT运维管理软件iTop实施指南 p251。
ITIL
类别 | iTop 支持 | 主要支持内容 |
事件管理 | 支持 | 所有呼叫和联络的事件记录能力; 事件分级和分类,包括事件分配到组和人; 能够看到事件的发起人; 基于紧急度和影响度的事件优先级定义; 事件与配置项关联; 事件记录信息包含(配置项、联络者及临时联络人姓名、部门、电话号码); 工单来源信息记录; 事件信息记录中显示SLA,如解决时间要求; 事件包含简短和完整描述字段; 事件状态定义; 事件历史记录; 在违反SLA时候,事件自动升级,如逾期未处理; 事件自动解决和关闭,如类似事件自动解决; 事件与问题、变更关联; 事件可以添加文档、音视频等附件。 |
问题管理 | 支持 | 问题类型定义; 记录问题信息; 问题具备简短和完整描述字段; 问题处理方式定义; 问题状态定义; 问题历史记录; 问题与事件、变更关联; 问题可以添加附件描述信息; 可以通过问题记录关联知识。 |
配置管理 | 支持 | 资产配置项的基本信息记录,包括类型、基本属性、供应商、发 票、序列号、使用有效期等; 配置项之间能关联; 配置项变更的版本记录; 配置项与合同关联。 |
变更管理 | 支持 | 能够记录一个变更请求(FRC); 变更能够分配到组和人; 能够记录变更的所有者; 变更优先级定义; 变更关联到配置项; 每个RFC都有一个简短和完整描述字段; 变更状态定义; 变更历史记录; 变更关联到事件、问题; |
服务级别管理 | 支持 | 可按照组织、人员、配置项、优先级等制定服务级别; 可根据服务级别建立服务目录; 能够将服务级别协议和事件、请求相关联。 |
信息安全管理 | 支持 | 基于登录的ID,限制对功能模块、数据等的访问权限; 具备设定密码有效期等密码安全支持; 最大失败登录次数限制; 允许删除用户帐号。 |
报告 | 支持 | 能够报告由事件、问题和变更产生的反馈; 报告有关服务级别协议的能力,如服务级别响应程度; 报告IT相关的成本信息; |
工作流程管理 | 支持 | 流程流转自动通知责任人; 流程中角色授权和委托; 工作流进度跟踪; 流程监督及报告; 自定义新的工作流程,如企业内部的审批流程。 |
接口 | 支持 | 能够向客户自动发邮件进行满意度调查; 能够与CTI进行集成; 能够与短信进行集成; 能够与网络监控系统进行集成; 能够与单点登录进行集成; 能够与数据库进行集成; 能够导入、导出数据,如批量导入资产、人员数据等; 能提供部分源代码供二次开发使用。 |
ISO20000
类别 | 项目 | iTop支持 | 主要支持内容 |
服务提供过程 | 服务级别管理 | 支持 | 针对每项服务都有服务级别定义; 能够制定基于客户、项目的服务级别协议; 能够根据目标定期监测和报告服务级别的满足情况。 |
IT服务预算与财务管理 | 支持 | 通过计算服务所花费的人员工时量化服务成本,从而达到优化服务成本目的。 | |
解决过程 | 事件管理 | 支持 | 事件记录及分类; 基于影响度和紧急度定义事件优先级; 及时通知事件处理进度; 可以访问问题解决方案库(知识库)以便快速解决事件; 事件升级机制; 事件处理及关闭。 |
问题管理 | 支持 | 问题记录及分类; 问题更新、处理及解决; 问题关联到相关事件及后续变更; 把问题的解决方法提交为知识库。 | |
控制过程 | 变更管理 | 支持 | 变更记录和分类; 变更与配置的关联; 变更流程控制,如审批、考核; 变更报告; |
配置管理 | 支持 | IT资产记录、分类及关联(资产管理)。 |
ITSS
类别 | 项目 | iTop支持 | 主要支持内容 |
策划 | 根据自身业务定位和能力,策划运行维护服务对象的服务内容与要求,并形成服务目录; | 支持 | 支持根据业务需求创建服务目录,如针对用户不同部门创建针对性服务项目。 |
依据服务目录策划如何建立相应的组织架构和管理制度; 对人员、资源、技术和过程进行规划,建立相适应的指标体系和服务保障体系; 策划如何管理、审核并改进服务质量,建立内部审核评估机制。 | N/A | ||
实施 | 制定满足整体策划的实施计划,并按计划实施; 建立与需方的沟通协调机制; 按照服务能力要求,实施管理活动并记录,确保服务能力管理和服务过程实施可追溯,服务结果可计量或可评估; 提交满足质量要求的交付物。 | N/A | |
检查 | 定期评审服务过程及相关管理体系,以确保服务能力的适宜性和有效性; | N/A | |
调查用户满意度,并对服务结果进 行统计分析; | 支持 | 调查用户满意度,并对服务结果进行统计分析; | |
检查各项指标达成情况。 | N/A | ||
改进 | 建立服务能力管理改进机制; 对不符合策划要求的行为进行总结分析; 对未达成的指标进行调查分析; 根据分析结果确定改进措施,制定服务能力改进计划。 | N/A | |
人员管理 | 人员储备 人员培训 绩效考核 | N/A | |
岗位结构 | 管理岗人员及职责确立; 技术支持岗人员及职责确立; 技术支持岗人员及职责确立; | N/A | |
知识 | 基础知识 专业知识 综合知识 | N/A | |
技能 | 确定运行维护服务人员在运行维护服务中所必备的能力; 要求运行维护服务人员具备从事相关运行维护服务的资格; 特殊环境运行维护服务人员应具备相关资格。 | N/A | |
经验 | 运行维护服务人员应具备所从事运行维护服务活动的经验; 供方应具备一定的从事运行维护服务活动的经验; 从事运行维护服务的时间; 主持或参与运行维护服务项目的项目数量、项目金额、项目规模以及在项目中的角色作用等。 | N/A | |
运维工具 | 监控工具对运行维护服务对象进行数据的采集和监控,评估可能导致运行维护服务对象故障的因素; | 支持 | 系统支持与常用监控工具无缝集成,通过捕捉设备异常信号自动生成事件工单。 |
过程管理工具按照商定的服务级别协议管理运行维护服务的交付过程,过程管理工具宜包括日常运维管理、记录、测量、监督和评估等功能; | 支持 | 系统包含对日常运维的记录、测量、监督和评估功能。 | |
专用工具能够根据服务要求配备安全工具和用于特殊要求的工具。 | 支持 | 能够根据需方要求,提供与其他第三方工具进行集成。 | |
服务台 | 供方应设置专门的沟通渠道作为与需方的联络点,沟通渠道可以是热线电话、传真、网站、电子邮箱等; | 支持 | 系统整合集成电话、短信、邮件等方式实现IT部门与用户的唯一联络点。 |
供方应设定专人负责服务请求的处理; | 支持 | 设定服务台接线员或一线运维工程师负责服务请求的处理,同时支持工单的继续转派; | |
供方应针对沟通渠道建立服务流程和管理制度,包括服务请求的接收、记录、跟踪和反馈等机制,以及日常工作的监督和考核。 | 支持 | 支持服务响应、处理、反馈等机制及对IT工程师的工作量统计。 | |
备件库 | 备件出入库管理:能够对入库备件进行标识,规范备件的使用和核销,备件物品的帐务管理; | 支持 | 注:可能需要通过插件来支持,比如 Simple Stock Management[13]https://www.itophub.io/wiki/page?id=extensions%3Aitop-stock-mgmt |
知识库 | 组织应针对常见问题的描述、分析和解决方法建立知识库; 整个组织内的知识是可用的、可共享的; 组织应选择一种合适的知识管理策略; 知识库应具备知识的添加、更新和查询功能; 组织应针对知识管理要求制定相关管理制度,并进行知识生命周期管理。 | 支持 | 注:大致对应 iTop 问题管理下的FAQ |
技术研发 | 根据业务和市场分析,制定研发规划,包括新技术和前沿技术的应用、技术储备等; 配备与规划相适应的研发环境; 配备与规划相适应的研发队伍。 | N/A | |
与发现问题相关的技术 | 具有信息采集和监控的手段; 具有诊断和分析问题的方法。 | 支持 | 能够与第三方监控工具实现集成从而捕捉设备异常信号,实现故障实时响应处理。 系统支持故障的智能诊断。 |
与解决问题相关的技术 | 解决问题的技术指标或标准; 解决问题的方案或手册; | 支持 | |
测试环境、测试标准和方法。 | N/A | ||
服务级别管理 | 建立服务目录; 与需方签订服务级别协议; 根据需方的考核评估要求,建立SLA考核自评估机制,包括SLA完成情况、达成率; 在SLA评估后制定改进内容及改进措施。 | 支持 | 系统支持根据客户服务合同制定服务目录及定义SLA。 |
事件管理 | 与事件管理过程一致的流程,包括事件受理、分类和初步支持、调查和诊断、解决、进展监控与跟踪、关闭等流程; | 支持 | 支持对事件处理方式包括记录、分派、升级、调查、解决、关闭、重开。 |
事件分类、分级机制; | 支持 | 支持根据影响度和紧急度定义事件优先级。 | |
事件升级机制; | 支持 | 支持对违反SLA的事件进行优先级升级。 | |
满意度调查机制; | 支持 | ||
事件解决评估机制,包括事件解决率、事件平均解决时间等。 | 支持 | 系统以报表形式统计分析事件解决效率。 | |
问题管理 | 与问题管理过程一致的流程,包括问题建立、分类、调查和诊断、解决、错误评估、关闭等流程; | 支持 | 支持对问题处理方式包括记录、分派、升级、调查、解决、关闭。 |
问题分类管理机制,包括问题的影响范围、重要程度、紧急程度并确定优先级; | 支持 | 支持定义问题优先级。 | |
问题导入知识库机制; | 支持 | 支持把问题的解决方法导入知识库。 | |
问题解决评估机制,包括问题解决率、问题平均解决时间等。 | 支持 | 系统以报表形式统计分析问题解决效率。 | |
变更管理 | 建立与变更管理过程一致的流程,包括请求、评估、审核、实施、确认和回顾等环节; | 支持 | 支持变更处理方式包括新建、审批、编辑等。 |
建立变更类型和范围的管理机制; | 支持 | ||
对变更完成情况进行统计分析,包括未经批准变更数量及占比、不同类型的变更数量及占比、不成功的变更数量及占比、取消的变更数量及占比、变更关联的配置数。 | 支持 | 系统以报表形式统计分析变更完成情况。 | |
发布管理 | 建立发布类型和范围的管理机制; | 支持 | |
对发布完成情况进行统计分析,包括发布成功率、发布及时率、是否更新配置管理数据库等。 | 支持 | 通过报表形式对发布完成情况进行统计分析 | |
安全管理 | 建立与服务要求一致的信息安全策略、方针和措施。 | 支持 | 基于不同角色,设置对模块、数据的访问权限。 |
参考资料
↑1, ↑2 | 百度百科 IT服务管理 |
---|---|
↑3, ↑6 | https://www.bmc.com/blogs/itsm/ |
↑4 | 百度百科 ITSS |
↑5 | 百度百科 ISO20000 |
↑7 | 百度百科 DevOps |
↑8 | 刘征 运维、开发和管理者们必备的 SRE 核心体系解读 |
↑9 | https://www.bmc.com/blogs/itsm-or-itil-that-isnt-the-question/ |
↑10 | https://sre.google/sre-book/introduction/ |
↑11 | https://neilfaganblog.wordpress.com/2020/03/17/is-itil-dead/ |
↑12 | 长河,付剑波 开源IT运维管理软件iTop实施指南 p251 |
↑13 | https://www.itophub.io/wiki/page?id=extensions%3Aitop-stock-mgmt |
发表回复