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标准着重于通过“IT服务标准化”来管理IT问题，即将IT问题归类，识别问题的内在联系，然后依据服务水准协议进行计划、推行和监控，并强调与客户的沟通。该标准同时关注体系的能力，体系变更时所要求的管理水平、财务预算、软件控制和分配。
ISO20000的原理和方法如下
第一，集成的过程方法
过程：将输入转化为输出的相互关联或相互作用的一组活动。
集成的过程是系统的识别、定义和管理组织内所使用的各个过程，特别是过程间的接口和交互作用，形成可协调运行的过程集合。举例：一个服务事件会触发事件管理过程，从而可能进一步引发问题管理过程、变更管理过程等。
第二，质量管理的PDCA方法
一 术语定义与概述
1.1服务目录：提供给客户服务的成文信息
1.2服务级别协议 Service Level Agreement SLA
服务级别管理：为签订服务级别协议SLA而进行的计划、协商、监控、报告以及签订SLA后对服务品质的评价等活动组成的一个服务管理
服务级别协议SLA：IT提供方和客户就服务提供与支持过程中关键的服务目标及双方责任等问题达成的协议
运行级别协议OLA：IT服务提供方和组织内部某个具体的IT职能部门或岗位就某个具体的IT服务项目的服务提供和支持所达成的协议
支持合同：IT服务提供方和外部第三方供应商就某个特定的服务项目的提供和支持所达成的协议
有几大类 服务可用时段，服务响应时间，服务完成时间等等
服务级别协议
甲方：A
乙方：B
本协议覆盖 XYZ 服务的供成与支持，（简述服务内容）。
本协议有效期为 12 个月，从_年_月_日到_年_月_日。本协议将被每年审核，变更部分必须记录于附件中的表格由双方签宁确认。
服务级别定义：XYZ 应用的端到端响应时间
有效时间：每天 24 小时，从周日到周六，不包拈用户定义的国定假期。
服务级别指标：响应错误小于总连接数的 1%。
响应时间：小于等于 5 秒。
沟通：
(1).服务分联系方式：support.xxxx.com 或 800-XXX
(2).响应时间：乙方承诺在接到报告后 5 分钟内回拨ill话给客户
(3).升级行为：30分钟内违背 SLA，通知至乙方项目经埋；4 小时内 SLA 失败并未能找到恢复方法，通知至甲乙双方区域经理。
(4).升级管理：向甲乙双方项 B 经理提供 SLA 失败的月报。向甲乙双方区域经埋提供 SLA 失畋的季报。
双方责任约定：与 XYZ 应用相关的服务器由甲方拥有，并位于甲方数据中心，甲方应向乙方提供必要的访问系统的权限。乙方保证遵守甲方的安全规则。
计算公式：响应时间 <= 5 秒。所谓响应时间指从发出初始査询到用户屏幕上显示出所有字符。
测量间隔和报告周期：测量轮询间隔为 1 分钟。报告周期为周报（累积数据）。
数据源：测量指标将由 XX 自动化工具完成。内容包括测量点响应时间值及包含日期和时间的时间戳信息。
1.3服务可用性
在规定时刻或规定时间段内，服务执行要求功能的能力
可用性%=约定服务时间AST-停止服务时间/定服务时间AST
2个9：(1-99%)*365=3.65天
3个9：(1-99.9%)*365*24=8.76小时，表示该系统在连续运行1年时间里最多可能的业务中断时间是8.76小时。
4个9：(1-99.99%)*365*24=0.876小时=52.6分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。
5个9：(1-99.999%)*365*24*60=5.26分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。
1.4服务连续性计划
在尽量少的中断客户 业务情况下，提供IT 服务，并在IT 系统出现问题时，以可控的方式恢复。
IT服务持续性管理：负责预防灾难、增强IT基础架构的恢复能力和容错能力，需要确保组织在发生灾难后有足够的技术、财务和管理资源来确保IT服务的持续性运作。
每年执行一次或多次BC计划的演练是业务连续性管理系统（business continuity management system，BCMS）的一个关键组成部分。这个演练应该包括计划更新、应急小组训练、策略审查和审计、业务影响分析（BIA)、风险评估（RA）、宣传方案等各种BCMS活动。
1.5可用性-连续性-SAL
在签订SQL之前，首先需要明确客户的可用性和连续性需求，在确定SAL的可用性和连续性目标后，服务连续性和可用性管理应确保这些目标的实现和达成，并提供实际的运行指标。
服务连续性管理及可用性管理的最终目标是一致的，就是保证服务的持续可用、不间断。虽然ISO20000体系将服务连续性和服务可用性同作为6.3条款内的一个流程，但在组织内部进行操作实践中还是有所区别、各有侧重。
服务可用性管理贯穿于IT服务运行的整个过程，客户在提出服务可用性需求时，IT服务提供者将评估该需求所需的资源及基础架构，进而确定所需的资源及成本，以供客户进行选择和确定。随后IT服务提供者将根据这些可用性需求制订恢复方案和可用性计划，目的是在IT服务发生中断时，以最短的时间将业务/服务恢复至正常状态。
服务连续性管理首先需要对IT服务进行业务影响分析，明确需要重点实施连续性管理的范围，对IT服务进行风险分析及风险管理，识别组织提供IT服务过程中存在的薄弱环节及潜在威胁，并制订服务连续性策略，以最低的成本降风险控制在最低的接受水平。在完成IT服务连续性计划实施后，需要定期对风险以及连续性策略进行评审、测试。连续性管理与变更管理有着千丝万缕的密切联系，无论是业务需求发生变化、还是技术参数/架构等发生变更，都需要及时回顾并调整连续性计划。
可用性是整体可用性是全年的可用率例如99.9%，8.76小时。连续性连续性管理应与变更管理建立密切的连续，无论是业务需求发生变化，还是技术参数，技术框架发生变更，都需要及时回顾调整连续性计划，以确保其真正发挥作用。
二 重要知识管理
正所谓兵马未动，粮草先行；一个好的系统或者项目，必定有很多的文档（知识）进行支撑。比如系统建设前期，一定要做好系统的需求文档、设计文档、实施文档。在系统建设中要依据前期的文档进行实施和设计，并生成系统相关的问题总结文档和更新实施文档。系统建设完成后，要基于系统的业务能力和使用对象编写操作手册和运维手册等。有些业务在交付的过程中，并未按照要求提供相关的文档，系统上线后问题层出不穷，导致运维人员手忙脚乱，不知道从何下手处理，往往会让运维人员绕很多的弯路，错失良机。文档也分好多种，比如配置文档、实施文档、设计文档、系统规范性文档、项目管理文档等等。基于种种，所以要求运维人员一定要具备相应的文档编写能力和整理能力。同时一定要严格按照之前的文档进行实施，有问题要学会及时沟通，并把修正后的问题更新到文档中。
