学习资料： ITIL培训基地专家讲堂直播 300期视频回放

服务转换知识串讲提纲

1、        总体目标：确保服务从设计到投入运营这个转换过程的效果与效率，并将当前与未来的风险降至最低，同时确保服务在运营或交付中所依赖的综合因素都得以支持和保障
            o        规划发布与部署所需要的能力和资源；在预期的成本、质量和时间范围内，规划和管理资源，建立新的或变更的服务；将稳定快速转换的管理过程进行量产，帮助客户快速适应新要求和市场的快速发展，增强竞争优势；
            o        发布前提供严谨规范的框架用于评估服务的能力和风险；确保将无法预料的影响控制在最小程度；保障变更和发布的成功率；
            o        在转换过程中建立与维护好服务资产和配置项的完整性；
            o        做好沟通和实施部署，提供高质量的知识，提高客户和服务管理人员的满意度；

2、        服务转换规划与支持：提供清晰、全面的服务转换计划；v2的变更计划与监控过程比较简单和破碎，仅仅在于变更窗口与发布窗口的协调，资源安排上没有独立的规划文档。举例：当一个服务供应商击败了另一个服务供应商，如何去替换掉这个旧乙方？需要考虑交接项目计划、人员安排、设备/数据/文档的交接方式和时间安排等；

3、        配置管理系统CMS、知识管理系统SKMS

4、        变更、发布与部署、资产与配置的铁三角关系，如同财务经理、会计、出纳

5、        V模型：Level1服务战略，Level2、Level3服务设计，Level4、Level5服务转换，多数企业只做好了组件和配件测试；

6、        变更管理
            o        变更流程活动：创建RFC、合规性审查、评估（分类分级与风险评估、变更计划和时间安排、回退或补救方案评估）、CAB会议和授权、实施协调资源和时间窗口、实施后评审
            o        标准变更：常发性、触发条件明确、操作规范、风险低、可预授权类型的变更，可采用穷举法或规则法明确界定，一般明确规定了需要遵循的SOP和WI；通常由服务请求来实现；事件一般提出标准变更，问题往往提出一般变更；
            o        回退和补救计划
            o        变更顾问委员会：将拍一个人的脑袋改为拍多个人的脑袋，避免单个领导的能力边界问题，如同国外的陪审团定罪制度，变更经理如同法官组织审理和宣布评审结果；变更经理需要实权来协调关系和调用资源；问题：如何在现有条件下建立CAB会议制度；
            o        ECAB：小范围审批，授权，测试和实施，同步记录，补录RFC，PIR研究是否还有更佳的方案；

7、        资产和配置管理
            o        目标：配置项的识别、控制、记录、报告、审计、检验；建立CMS确保配置项信息的完整性；将技术大佬的思维中的关联关系固化成CMDB；举例：配置管理做好了，就不应该有所谓的“历史遗留问题”了；
            o        配置项范围：9大战略资产均可以作为配置项，但要注意与广度和深度相关的工作量压力以及投资回报，如服务器网卡、交换机端口、网络节点是否作为CI？
            o        最终介质库DML：最终授权的软件版本
            o        备件库：库存管理、安全库存定义
            o        配置基线：里程碑标记、审计和回退标杆、服务是否正常的判定标准
            o        流程活动：管理与规划（政策、标准-深度和广度、管理资源、设施工具、培训指导）、配置识别与标识（确定分类、命名、标记、属性定义、关系定义）、配置控制、状态报告、验证和审计、主数据管理

8、        发布和部署管理
            o        问题：上线后的系统运维团队接不上手，资料移交不齐全，没进行必要的培训，与开发团队沟通不畅甚至闹矛盾；不适当的发布可能造成业务中断的灾难性后果
            o        目标：定义发布与部署计划，确保发布没有遗漏和组件之间的兼容性问题，确保变更需求能通过流程管好发布与部署活动，确保发布和部署的成功、有效、按时完成，不出现异常状况；发布政策来自于变更单的要求；
            o        发布单元：可以理解为执行小分队的整体任务，举例-服务器/存储/网络硬件、操作系统、存储驱动、数据库、中间件、应用、HA，既可分步安装（分阶段法），也可一次性安装（大爆炸法），关键看执行任务的团队能否承担，时间是否方便；大量重复性的发布与部署，也可以采用阶段式；
            o        流程活动：发布计划，构建、测试和部署准备，构建和测试，服务测试和试运行，计划和准备部署，实施部署和回退，部署检验，早期维护支持，评审和关闭部署，评审和关闭服务转换
            o        3个环境的管理：开发环境多了开发平台和开发工具，测试环境多了压力测试工具等
            o        落地问题：由于运维团队经手的变更项目其规模、内容、特征各不相同，往往很难通过实施一套管理软件平台来单独管控发布过程，通常将发布管理融入变更管理来实施，这样，发布与部署管理的具体过程很难标准化和规范化，比较可行的办法就是制定一份《发布与部署管理规范》。要重点排除用户因为不习惯而抵制新系统上线，要中肯地理解用户操作习惯，做好沟通和培训；举例：人体工学键盘很少人买。应该在开发阶段定好运维标准，上线后开发与运维团队并行工作两周；

9、        评估流程：它对服务转换进行有效的分析，可以理解为一个中立的内部评估机构，从变更执行的视角评估服务设计方案在通过服务转换进入服务运营状态整个过程是否取得了预期的绩效和是否遵循了标准化的流程，属质量保证措施，可以认为是对变更管理流程的评价；而变更管理的评估则侧重于对变更本身从资源和影响两个角度进行评估，从而为授权变更提供决策依据，属质量控制措施，是对变更申请单的评价；

10、服务验证与测试流程：它对服务转换进行有效的保障，验证新的或变更的服务是否能够支持客户需求并提供结构化的验证和测试流程的证明，可以理解为一个中立的内部测试验收机构，对服务的质量进行保障；举例：项目开发人员负责测试并向PM负责，造成运维团队不信任，最好有内部中立的测试机构负责；要留意，测试环境如果比正式环境先进，可能测不出某些问题

11、知识管理流程：
            o        目标：它确保正确的信息和知识以一种可高效利用的方式传递给所有的IT服务人员；
            o        业务价值：提升服务台一线解决率、降低对关键技术人员的依赖、确保服务转换向服务运营环节的顺利过渡、提高故障恢复效率、有助于团队整体技能水平的提高；
            o        DIKW模型
            o        服务知识管理系统SKMS
            o        流程活动：管理战略（角色职责、流程定义、资源安排、监控度量措施）、知识传递（与知识库管理的差异）、数据和信息管理、使用服务知识管理系统
            o        落地问题：重点不在于知识库的建设，而在于谁愿意用，哪个环节用？要提高编写和使用知识的积极性、提高知识的有效性和质量；知识记录要模板化，不要期望事件单会详细描述完整的知识；打造学习型的组织更重要，大量的知识通过无形的方式进行传递，盲目追求形式不一定收到好的效果；提高大家学习的积极性，举例：运动员99%的时间在训练学习，1%的时间在比赛，而我们IT服务人员有多少时间花在学习上？

支持

支持啊 归纳的很好 正需要~

:lol{:soso__4011813854091704040_4:}