AMS 交接与应用资产基线
示意性用例，并非案例研究。
接管并非由我们构建的应用：盘点应用资产，商定范围与严重程度，转移知识，并在运营之前确立服务基线。
问题
应用在正常运行，但了解它们的人已经离开，或者现任厂商即将退出。文档残缺不全，定制内容没有记录，没有人能说清哪些集成是关键的。支持工作在被理解之前，无法得到改进。
当前做法
新的支持团队接手一个工单队列和一个共享盘。知识转移在与离任团队的几次通话中完成。严重级别定义、服务时间和升级路径沿用旧合同中的假设。最初几个月都在通过事件重新摸索应用资产。
查看场景
示意性工作流程。含字幕。
文字稿
- 应用在运行，但懂它们的人已经离开。文档不完整，定制内容没有记录，没有人说得清哪些集成是关键的。
- 我们盘点应用资产，商定支持范围和服务时间，记录流程和缺口，然后建立服务的起始基线。
- 盘点期间不对生产环境做任何变更。负责人在服务开始前批准各项定义，调研发现的问题用于完善改进待办清单，由负责人确定优先级。
- 衡量指标：应用资产覆盖率和未知组件引发的事件数。示意性用例。欢迎探讨您的用例。
拟议工作流程
- 盘点应用资产：模块、集成、定制内容、代理，以及它们运行所在的环境，证据从系统中采集，而非凭记忆
- 在接手任何工单之前，以书面形式商定范围、严重级别定义、服务时间和厂商升级责任
- 将知识转移到运行手册和经批准的知识库中，缺口列出而非隐藏
- 建立服务基线：当前事件量、解决时间、发布节奏和已知风险
- 按商定的定义运营，记录发现，并提出改进项供负责人确定优先级
人员保持掌控的环节
- 范围、严重级别、服务时间和升级责任在服务开始前由负责人批准
- 盘点期间不对生产环境做任何变更；发现只做记录，不当场修复
- 改进待办清单的优先级由负责人确定，而非由支持团队确定
平台映射仅表示可评估此构想的环境。实际实施取决于配置、许可、API、数据和权限。收益以定性方式表述；数值化的说法需要有书面记录的基线。