ITIL-IT运维管理-概述
IT服务管理（ITSM）是一套帮助企业对IT系统的规划、研发、实施和运营进行有效管理的方法，是一套方法论。ITSM起源于ITIL（IT Infrastructure Library，IT基础架构标准库），ITIL是CCTA（英国国家电脑局）于1980年开发的一套IT服务管理标准库。它把英国在IT管理方面的方法归纳起来，变成规范，为企业的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运维要紧跟业务，为业主提供，业务培训和指导，才能离不开你，创造价值。
负责设计新的或者变更的服务，引入生产环境，包括架构、流程、政第及文档。
主要有以下管理
服务目录管理
供应商管理
服务级别管理
能力管理
可用性管理
信息安全管理
IT服务连续性管理
服务设计的范围
新的或者变更的服务
服务管理系统和工具，尤其是服务组合（包括服务目录）
技术架构与管理系统
必要的流程
度量方法和度量指标(Measurement methods and metrics)
服务目录-运维管理SLA服务
服务目录组织提供给客户服务的成文信息，可以明确能提供服务的项目。SLA服务级别协议是指提供服务的企业与客户之间就服务的品质、水准、性能等方面所达成的双方共同认可的协议或契约。
供应商管理流程的目的是管理供应商以确保服务的无缝衔接和服务质量。服务提供者能调动供应商资源来运营部分流程和服务，或者提供服务组件(如硬件和软件）。
SLA服务级别协议是指提供服务的企业与客户之间就服务的品质、水准、性能等方面所达成的双方共同认可的协议或契约。
服务级别管理
·协商SLA
·确保满足SLA
·确保所有IT服务管理流程、OLA及基础合同对于服务
级别目标是合适的
. SLM监控和报告服务级别，保存阶段性客户回顾
SLA（Service Level Agreement）服务级别协议，是指提供服务的企业与客户之间就服务的品质、水准、性能等方面所达成的双方共同认可的协议或契约。
服务级别协议(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服务提供者为客户提供服务
·定义提供的货物或者服务
·举例:服务台和一个解决事故的支持组
可用性Availability：是指一个组件或一种服务在设定的某个时刻或某段时间内发挥其应有功能的能力。总时间-故障时间/总时间 99.9%，99.99%
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
目的
·提供与服务和资源相关的所有可用性事宜的管理
·保证所有提供的服务的可用性级别被满足
·满足或者超过当前及未来业务可用性的需求
能力管理，保证IT服务和IT基础设施的能力足以达到服务级别目标，考虑提供IT服务需要的所有资源。
为保证系统在运维阶段能够得到有效的运行、维护和更新，在项目由实施团队交由运维团队运维的过程中，实施团队需要根据项目运维需要进行有针对性的技能、知识的系统培训，完成系统能力交接，使运维团队成员掌握项目相关知识，并且能够胜任该项目的运维工作，达到能独立解决运维过程中所出现的各类系统相关问题。
信息安全是指为数据处理系统而采取的技术的和管理的安全保护，保护计算机硬件、软件、数据不因偶然的或恶意的原因而遭到破坏、更改、显露。保证组织资产、信息、数据及IT服务的机密性、完整性及可用性。信息安全管理过程应确保信息安全控制措施能保护信息资产，同时，新的和变更的服务的设计与转换应考虑信息安全需求。
通俗的说，基于设计的方案或者开发的环境， 平稳的落实到生产的环境。
服务转换(Service Transition )
·通过管理变更和风险来定义高质量服务
·包括的流程︰变更管理，服务资产和配置管理，发布和部署管理。
变更管理
·控制所有变更的生命周期
·在最少的中断下实现有收益的变更
Goals（目的）
响应客户业务变更需求，实现价值最大化，减少事故、业务中断和返工
·响应业务和IT需求变更，使得服务和业务需求一致
价值
·提高可靠性和业务连续性，对任何组织的成功和生存而言都是最基本的。
变更管理推动业务，通过
·确定优先级并相应业务和客户变更建议
·实现变更满足客户认可的服务需求，同时优化成本
·减少失败的变更，以及服务中断，缺点和返工
·按照时间表及时提供变更
·在服务生命周期中跟踪变更
·提供更好的质量、时间和变更成本的估算
有没有应急预案和回退方案。
RFC变更请求-变更管理始终要和配置管理同步，目前也是很欠缺的。
服务资产与配置管理
·配置管理:负责维护配置项的信息，（我的理解初级就是文档，知识管理）
·资产管理︰负责在整个生命周期中跟踪财务价值及所有权
·配置管理数据库(Configuration management Database CMDB)
·用于在整个生命周期中存储配置记录的数据库
·存储CI的属性，及其与其它CI的关系
·配置管理系统( Configuration Management System ,CMS)
·工具及数据库的集合，用于管理配置数据
·被所有IT服务管理流程引用
·发布管理和部署管理的职责
·发布管理
·负击将版本转移到测试和现场环境，包括计划和控制
·确保现场环境的版本以及发布的组件版本
·版本(Release )
硬件、软件、文档流程及其它组件的集合，用于实现一个或多个批准的IT服务变西，该并更作为—个卖体来管理、测试和部酱
·部署
负责将新的或者变更的硬性、软件、文档、流程等移动到生产环境的活动
最少要有系统部署说明，系统更新说明。
尽量和生产环境一致
回退计划
手动备份数据
对变更的配置保留证据
应急方案
备件
应急响应预案
逐步更新—生产环境小范围测试后—再大面积升级。
·确保有正确的信息，帮助决策和运营支持
·确保组织在整个服务生命周期中可以通过可靠的、安全的信息、数据来改进决策管理
·知识管理贯穿整个服务生命周期。服务转换中对知识
管理仅作基本概念的讲解
知识管理在服务转换中尤为重要，原因是转换时需要相应的知识来保障。
业务价值
举例说明成功的转换以来知识管理:
·用户，帮助台等理解新的换变更的服务包括对于错误的知识有助于帮助他们各自的岗位工作。
·了解服务的使用包括之前版本。
·在转换的同时建立可接受级别的风险和信任级别。例如度量，正确理解和响应测试结果，并确保它们。
·知识管理是一种资产，个人或团队可以共亨数据，信息和知识。
为有效和高效地完成服务支持和服务提供，确保客户和服务提供者的利益提供指导方针
包括的流程:事件管理、事故与问题管理、请求实现、访问管理、
包括的职能:服务台、技术管理、IT运营管理、应用管理
IT服务台可实现高效的IT运维管理，大大提高IT运维效益和降低风险成本，整体把控IT资源、优化资源配置，规范运维管理流程，每一个事件可记录、跟踪、统计。
服务台是支持IT运维服务的核心功能，与各个流程联系密切。所有用户都要通过服务台进行咨询、报修、投诉等操作，服务台负责为用户解答相关问题和需求、为用户派遣现场工程师、处理用户投诉、记录统计工程师工作量等。
运营控制(Operations Control)
监视和监控IT基础设施中的事件和运营活动
控制台管理、应用状态、备份恢复、性能维护活动等
设备管理(Facilities Management)
管理物理的IT环境
数据中心、恢复中心、服务器、存储、网络、供电、空调等
复杂事故处理、解决方案/构架
提供技术专家意见，负责IT基础设施的技术管理
小组
部门
团队
角色
IT感础设施相关的技术知识和经验管理人
提供实际的资源，来支持IT服务管理生命周期
目标
帮助计划、实施和维护稳定的技术架构
文档
技术文档
-技术手册
-管理手册
-用户手册
维护计划
角色
技术经理团队Leader
技术分析师/架构师
事件管理的宗旨是最短时候恢复故障，从而将故障的损失降到最低，在此前提下尽可能满足服务的要求。
当紧急故障得以处理，信息中心就会转而进入问题管理的层面，以便找到故障发生的原因，从而改变频于应付突出事故的局面。
与事件管理的根本区别就在于，事件管理目的在于恢复企业生产，而问题管理在于找出IT故障的根本原因，制定解决方案，防止类似故障的再次发生。
跟开发聊聊业务架构，了解所使用的技术，为什么使用，以及好处。最好让其准备PPT能演讲下，如果不行让其发发文档看看也是好的，梳理以下几点
了解各项目业务架构设计，及拓扑图
大流量场景业务
目前存在的业务瓶颈
有无历史遗留落后设计
有无应用最新技术及为什么这样选择
在这里只是了解，运维跟研发是会一直合作的，因此后面可以带着问题再找到相关负责人
这里就涉及到我们的主要工作了，了解运维的方式，技术栈等等，列了如下
了解阅读运维文档，一般有wiki（知识库），因此可以先看看大致了解，但不是所有wiki都有章有法，多数还是很乱
了解当前运维资产，服务器、网络、数据库等相关运维资源情况
了解当前运维方式，如人肉、脚本、自动化等等，看看当前处于哪个阶段
了解当前运维技术栈，毕竟运维技术、工具更新快，且多又杂，不一定都接触过
了解线下线上发布流程，是否自动化
了解各业务部署的运维架构
了解目前运维安全方面的防护
了解和开发测试运营等合作方式
减少踩坑风险
相信很多人如果接手其他人的工作时，前面都是比较痛苦的，因为其他人的工作方式、理念等都跟自己或多或少都有出入，就运维而言，自己当前的技术能力如果与接手的运维工作阶段(如自动化程度较高)有出入，则很难快速着手，比如工作中没有一定的标准、规范会导致很混乱，或者即使有标准规范，但执行得不理想。又或者工作中都靠口头相传，没有很好的文档记录，因此想要快速，首先自身的技术需要有一定的基础，其次就是努力熟悉了，这里我主要是提出几点减少踩坑坑的方法
如果跟人交接，则一定要做好记录，这点非常重要，因为人在短时间内接收一大堆东西是非常容易忘记的，俗话说的好，好记性不如烂笔头，最重要的是自己记录的过程也会形成一种记忆，可以回想当时为什么这样记录帮助回忆，另外很多wiki上找不到的考运维间口头相传的更要记录
现在运维DEVOPS理念很火，但其实好些团队做得并不完全，有些地方做了标准化，有些地方又保留了老的，导致运维过程中，有些自动化了有些还是人肉，这些需要好好区分开来，否则很容易出故障，当然后续是一定优化这样的不良运维
首先运维自己也要熟悉产品相关的业务，当我们业务出问题时，才能第一时间处理，比如某个页面打不开，那么是什么域名，什么业务，可能在哪些地方出故障，我们也要第一时间知道这些业务在哪些服务器上面，这样才能方面运维排查问题，所以要熟悉业务和服务器间的拓扑图
在运维里面流行一句话，没有什么是重启解决不了的，虽然不那么准确，但是运维工作中，的确有很多时候的故障是可以通过重启来快速恢复业务的，那么我们不同的服务进程如何重启一定要优先了解熟悉并记录，才能做到更快速的管理进程
运维工作中总会有变动，故障等，当需要修改配置文件，以及查看日志时，如果我们不熟悉则会查询许久，因此在交接过程中这些也一定要记录下来，才能快速处理运维需求及故障
开机启动或者有哪些还没有加入开机启动的进程一定要注意，有时候服务器宕机了进程没有启动，就影响了业务，因此要去了解如chkconfig、/etc/rc.local里面的内容及未添加的
跟运维及其他部门了解代码发布平台、流程等，这是经常用到的，问问有无哪些需要运维经常配合的，还有一些历史遇到的一些问题
对以前运维中发生的故障如果有记录那就最好去了解，看看当时的故障表现及处理方法，如果没有记录，也可以询问同事了解
运维技术工具众多，我们一般不会每一种都了解，如果接手的刚好有较多自己不熟悉的，可以先了解，然后知道怎么重启管理进程以及查看日志排查问题即可，等有富余时间了再逐渐深入学习，这样才不会消耗大量的时间在一些不熟悉的事情上面
要跟运维开发测试运营产品等了解哪些是非常核心的业务，是不可容忍停机停服的，这些是我们重点关注并且需要非常熟悉的，需要很仔细的对待交接，千万不能马虎
没错啦，无论是交接还是去了解学习，一定要跟同事们打好关系，可以适当的请客吃饭几次，这点非常重要，因为在交接的时候，有些坑如果对方不说，你不一定看得到。所谓害人之心不可有，防人之心不可无，大家相处融洽，其乐融融，相信在交接的时候也更愿意将经验之谈奉上，说不定还能多学习些运维知识，提升自己技术水平，还交个朋友，何乐而不为
《需求说明书》 详细描述系统的功能性需求和非功能性需求，包含相应的需求质量属性等。 高
《系统概要/设计/集成设计说明书 》包括总体技术架构、系统逻辑与物理拓扑图功能、实现、模块组成、功能流程图、函数接口、数据字典、集成等软件开发需要考虑的各种问题。 高
《数据字典》 高
《测试报告》 中
《使用手册》 系统/产品简介、功能列表、功能描述和解释、功能操作等。 高
《部署文档》 高
《常见问题处理说明》 高
《运维手册》 系统维护手册应说明系统的.总体技术架构、系统逻辑与物理拓扑图、系统设备详细组成清单、系统软硬件部署方案和步骤(特别是须准确说明配置参数要求和关键步骤）系统依赖的后台服务器﹑网络、数据库等的可用性与性能要求，以及日常维护任务及要求 。 高
