大家好，我是讯享网，很高兴认识大家。

ITIL-IT运维管理-概述

中文名 IT服务管理 外文名 ITService Management

专家的研究和大量企业实践表明，在IT项目的生命周期中，大约80%的时间与IT项目运营维护有关,而该阶段的投资仅占整个IT投资的20%,形成了典型的“技术高消费”、“轻服务、重技术”现象。

ISO 20000，即"信息技术服务管理体系标准"，是面向组织机构的IT服务管理标准，目的是提供建立、实施、运作、监控、评审、维护和改进IT服务管理体系（ITSMS）的模型。ISO20000是国际标准化组织设立的国际标准

      

　服务战略(Service Strategy): 指导如何设计、开发和实施服务管理，包括组织能力及战略资产。

服务战略为组织在设计、开发和实施服务管理从组织能力和战略资产两个战略角度来提供指导。该部分内容提出了服务管理实践过程中整个服务生命周期的策略、指南和过程。服务战略是服务设计、服务转换、服务运营和服务改进的基础，它的主题包括了市场开发、、内部和外部的服务提供、服务资产、服务目录，以及整个服务生命周期过程中战略的实施。

服务设计(Service Design)：指导设计服务及服务管理流程

服务设计描述了对服务及服务管理过程设计和开发的知道，它包括将战略目标转变成服务投资组合和服务资产的原则和方法，服务设计的范围不仅限于新的服务，它还包括为保持和增加客户价值而实行服务生命周期过程中必要的变更和改进，服务的连续性，服务水平的满足，以及对标准，规则的遵从性。它指导组织如何开发设计服务管理的能力。

服务转换(Service Transition): 指导将新的或变更的服务引入生产环境

服务转换为如何将新的或变更的服务转换到运营过程中有关能力的开发和改进的指导，服务战略需求通过服务设计进行编码，而服务转换则是探讨如何将这种编码有效导入到服务运营的体系中，与此同时，还应控制失败的风险和服务的中断。

服务运营(Service Operation)：

服务运营包含了在服务运营方面的实践，它对如何达到服务支持和交付的效果与效率，确保客户与服务供应商的价值提供了指导，并最终通过服务运营实现战略目标。

事件管理(Incident Management)

问题管理(Incident Management)

持续服务改进(Continual service Improvement):

服务改进为创造和保持客户价值而用更优化的服务设计、转换和运营提供指导。它结合了质量管理、变更管理和能力改进方面的原则、实践和方法。组织要学会在服务质量、运营效率和业务连续性方面的不断提高和改进意识。此外，它还为改进所取得的成就与服务战略、服务设计和服务转换之间如何建立关联提供指导，为基于戴明环(PDCA)形成计划性变更的闭环反馈系统的建立提供思路。

服务战略流程︰活动组合管理、财务管理、需求管理

目的，帮助组织具备战略思考方式，使用战略资产，帮助组织将服务管理转换为战略资产。

年终的时候创作什么价值，IT运维的价值。

服务组合管理

包含了三个分类

·服务管道（Service Pipeline):建议或者开发中

·服务目录（Service Catalog）:在线或者可以部署

·退役服务（Retired Service)

服务组合管理（Service Portfolio Management，SPM)

·负责管理服务组合的流程

职责包括

·在生命周期中，将服务作为一个产品来管理

·围绕服务目录来协调和关注组织

·与业务关系经理（Business Relationship Manager ,BRM-业主）合作

·作为服务及服务目录的主题相关专家

财务管埋

预算（Budgeting )

会计核算(Accounting )

收费（Charging)

需求管理-一定要深入熟悉业务

影响客户需求的活动
满足这些需求的能力储备
 

主要有以下管理

服务目录管理

供应商管理

服务级别管理

能力管理

可用性管理

信息安全管理

IT服务连续性管理

服务设计的范围

新的或者变更的服务

服务管理系统和工具，尤其是服务组合（包括服务目录）

技术架构与管理系统

必要的流程

度量方法和度量指标(Measurement methods and metrics)

服务目录组织提供给客户服务的成文信息，可以明确能提供服务的项目。SLA服务级别协议是指提供服务的企业与客户之间就服务的品质、水准、性能等方面所达成的双方共同认可的协议或契约。

服务级别管理

·协商SLA

·确保满足SLA

·确保所有IT服务管理流程、OLA及基础合同对于服务

级别目标是合适的

. SLM监控和报告服务级别，保存阶段性客户回顾

服务级别协议(Service Level Agreement, SLA)

·IT服务提供者和客户之间的协议

·描述IT服务

·证明服务级别目标

·明确IT服务提供者和客户的职责

一个单独的SLA可能覆盖多个IT服务或者多个客户

服务级别需求（Service Level Requirement， SLR)

·客户对IT服务的需求

·基于业务目标

·用于协商服务级别目标

·清除差的服务

·改进IT和客户之间的关系

服务级别目标(Service Level Target )

。一个SLA的交付文档

·基于服务级别需求（SLR)

·保证IT服务设计满足目标

·支持合同(UC)

·IT服务提供方与外部供应商就某一特定服务项目的提供与支持所签订的协议

·操作级别协议（Operational Level Agreement, OLA)

IT服务提供者和同一组织中另一部分之间的协议

·支持IT服务提供者为客户提供服务

·定义提供的货物或者服务

·举例:服务台和一个解决事故的支持组

3.4 可用性管理

99.9 = 8760 * （100-99.9）% = 8760 * 0.001 = 8.76小时

99.99 = 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟

99.999 = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟

可靠性Reliability:是指IT基础架构可以无间断运作的能力，它主要取决于单个IT组件的可靠性和IT基础架构的整体恢复能力。有些设备出场就有可靠性，比如说，硬盘是质保3年。

主要是两个指标

1 MTBF：平均故障间隔时间，具体是指bai产品从一次故障du到下一次故障的平均时zhi间，是衡量一个产品的可靠性指标。

2 首次故障时间

可维护性Maintainability

可服务性Serviceability

  目的

·提供与服务和资源相关的所有可用性事宜的管理

·保证所有提供的服务的可用性级别被满足

·满足或者超过当前及未来业务可用性的需求

为保证系统在运维阶段能够得到有效的运行、维护和更新，在项目由实施团队交由运维团队运维的过程中，实施团队需要根据项目运维需要进行有针对性的技能、知识的系统培训，完成系统能力交接，使运维团队成员掌握项目相关知识，并且能够胜任该项目的运维工作，达到能独立解决运维过程中所出现的各类系统相关问题。

服务转换(Service Transition )

·通过管理变更和风险来定义高质量服务

讯享网

·包括的流程︰变更管理，服务资产和配置管理，发布和部署管理。

4.1 变更管理
4.1.1 理解变更和风险
 

变更管理

·控制所有变更的生命周期

·在最少的中断下实现有收益的变更

Goals（目的）

响应客户业务变更需求，实现价值最大化，减少事故、业务中断和返工

·响应业务和IT需求变更，使得服务和业务需求一致

价值

·提高可靠性和业务连续性，对任何组织的成功和生存而言都是最基本的。

变更管理推动业务，通过

·确定优先级并相应业务和客户变更建议

·实现变更满足客户认可的服务需求，同时优化成本

·减少失败的变更，以及服务中断，缺点和返工

·按照时间表及时提供变更

·在服务生命周期中跟踪变更

·提供更好的质量、时间和变更成本的估算

有没有应急预案和回退方案。

4.1.2 定义变更的范围
4.1.3 变更管理流程
RFC变更请求-变更管理始终要和配置管理同步，目前也是很欠缺的。

·配置管理:负责维护配置项的信息，（我的理解初级就是文档，知识管理）

·资产管理︰负责在整个生命周期中跟踪财务价值及所有权

·配置管理数据库(Configuration management Database CMDB)

·用于在整个生命周期中存储配置记录的数据库

·存储CI的属性，及其与其它CI的关系

·配置管理系统( Configuration Management System ,CMS)

·工具及数据库的集合，用于管理配置数据

·被所有IT服务管理流程引用

·发布管理

·负击将版本转移到测试和现场环境，包括计划和控制

·确保现场环境的版本以及发布的组件版本

·版本(Release )

硬件、软件、文档流程及其它组件的集合，用于实现一个或多个批准的IT服务变西，该并更作为—个卖体来管理、测试和部酱

·部署

负责将新的或者变更的硬性、软件、文档、流程等移动到生产环境的活动

手动备份数据

对变更的配置保留证据

应急方案

备件

应急响应预案

逐步更新—生产环境小范围测试后—再大面积升级。

·确保组织在整个服务生命周期中可以通过可靠的、安全的信息、数据来改进决策管理

·知识管理贯穿整个服务生命周期。服务转换中对知识

管理仅作基本概念的讲解

知识管理在服务转换中尤为重要，原因是转换时需要相应的知识来保障。

业务价值

举例说明成功的转换以来知识管理:

·用户，帮助台等理解新的换变更的服务包括对于错误的知识有助于帮助他们各自的岗位工作。

·了解服务的使用包括之前版本。

·在转换的同时建立可接受级别的风险和信任级别。例如度量，正确理解和响应测试结果，并确保它们。

·知识管理是一种资产，个人或团队可以共亨数据，信息和知识。

包括的流程:事件管理、事故与问题管理、请求实现、访问管理、

包括的职能:服务台、技术管理、IT运营管理、应用管理

服务台是支持IT运维服务的核心功能，与各个流程联系密切。所有用户都要通过服务台进行咨询、报修、投诉等操作，服务台负责为用户解答相关问题和需求、为用户派遣现场工程师、处理用户投诉、记录统计工程师工作量等。

监视和监控IT基础设施中的事件和运营活动

控制台管理、应用状态、备份恢复、性能维护活动等

设备管理(Facilities Management)

管理物理的IT环境

数据中心、恢复中心、服务器、存储、网络、供电、空调等

提供技术专家意见，负责IT基础设施的技术管理

小组

部门

团队

角色

IT感础设施相关的技术知识和经验管理人

提供实际的资源，来支持IT服务管理生命周期

目标

帮助计划、实施和维护稳定的技术架构

文档

技术文档

-技术手册

-管理手册

-用户手册

维护计划

角色

技术经理团队Leader

技术分析师/架构师

当紧急故障得以处理，信息中心就会转而进入问题管理的层面，以便找到故障发生的原因，从而改变频于应付突出事故的局面。

   与事件管理的根本区别就在于，事件管理目的在于恢复企业生产，而问题管理在于找出IT故障的根本原因，制定解决方案，防止类似故障的再次发生。

六 运维交接
6.1 了解业务-第一步
6.2 了解系统架构-第二步
跟开发聊聊业务架构，了解所使用的技术，为什么使用，以及好处。最好让其准备PPT能演讲下，如果不行让其发发文档看看也是好的，梳理以下几点

了解各项目业务架构设计，及拓扑图

大流量场景业务

目前存在的业务瓶颈

有无历史遗留落后设计

有无应用最新技术及为什么这样选择

在这里只是了解，运维跟研发是会一直合作的，因此后面可以带着问题再找到相关负责人

了解阅读运维文档，一般有wiki（知识库），因此可以先看看大致了解，但不是所有wiki都有章有法，多数还是很乱

了解当前运维资产，服务器、网络、数据库等相关运维资源情况

了解当前运维方式，如人肉、脚本、自动化等等，看看当前处于哪个阶段

了解当前运维技术栈，毕竟运维技术、工具更新快，且多又杂，不一定都接触过

了解线下线上发布流程，是否自动化

了解各业务部署的运维架构

了解目前运维安全方面的防护

了解和开发测试运营等合作方式

减少踩坑风险

相信很多人如果接手其他人的工作时，前面都是比较痛苦的，因为其他人的工作方式、理念等都跟自己或多或少都有出入，就运维而言，自己当前的技术能力如果与接手的运维工作阶段(如自动化程度较高)有出入，则很难快速着手，比如工作中没有一定的标准、规范会导致很混乱，或者即使有标准规范，但执行得不理想。又或者工作中都靠口头相传，没有很好的文档记录，因此想要快速，首先自身的技术需要有一定的基础，其次就是努力熟悉了，这里我主要是提出几点减少踩坑坑的方法

《系统概要/设计/集成设计说明书 》包括总体技术架构、系统逻辑与物理拓扑图功能、实现、模块组成、功能流程图、函数接口、数据字典、集成等软件开发需要考虑的各种问题。  高

《数据字典》       高

《测试报告》       中

《使用手册》  系统/产品简介、功能列表、功能描述和解释、功能操作等。    高

《部署文档》       高

《常见问题处理说明》   高

《运维手册》  系统维护手册应说明系统的.总体技术架构、系统逻辑与物理拓扑图、系统设备详细组成清单、系统软硬件部署方案和步骤(特别是须准确说明配置参数要求和关键步骤）系统依赖的后台服务器﹑网络、数据库等的可用性与性能要求，以及日常维护任务及要求 。 高
————————————————
版权声明：本文为CSDN博主「syjhct」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/syjhct/article/details/