OPS02-BP02 确定流程和程序负责人
了解谁负责定义各个流程和程序、为何使用这些特定的流程和程序，以及为什么应由此人负责。了解使用特定流程和程序的原因有助于发现改进机会。
期望结果：针对运维任务，企业有一套明确定义并良好维护的流程和程序。流程和程序集中存储在一个位置，可供团队成员使用。按照明确指派的责任归属，经常更新流程和程序。尽可能将脚本、模板和自动化文档作为代码实施。
常见反面模式：
-
流程未记录在案。脚本呈现碎片化，可能分布在许多孤立的操作员工作站上。
-
脚本的使用方法只有少数人了解，或作为团队知识非正式地交流。
-
旧的流程需要更新，但不明确应由谁负责更新，原作者已不在企业中。
-
无法发现流程和脚本，因此在需要时无法使用（例如，在响应意外事件时）。
建立此最佳实践的好处：
-
流程和程序可改进您操作工作负载的工作。
-
新的团队成员可以更快地投入工作中。
-
缩短了缓解意外事件的用时。
-
不同的团队成员（以及不同的团队）可以一致地使用相同的流程和程序。
-
团队可以使用可重复的流程来扩展其流程。
-
在团队之间移交工作负载责任时，标准化的流程和程序有助于减轻移交造成的影响。
在未建立这种最佳实践的情况下暴露的风险等级：高
实施指导
-
确定了负责定义流程和程序的负责人。
-
确定为支持工作负载而开展的运营活动。将这些活动记录在易于发现的位置。
-
唯一标识负责活动规范的个人或团队。他们负责确保由技能娴熟且具有正确的权限、访问权限和工具的团队成员来成功执行活动。如果执行活动时遇到问题，那么执行活动的团队成员有责任提供详细反馈，推进活动改进。
-
通过 AWS Systems Manager 等服务、文档和 AWS Lambda，在活动构件的元数据中收集责任信息。使用标签或资源组收集资源责任信息，详细说明负责人和联系信息。使用 AWS Organizations 创建标记策略，收集负责人和联系信息。
-
-
随着时间推移，这些程序应该逐步进化为可以作为代码运行，从而减少人工干预的需求。
-
例如，考虑 AWS Lambda 函数、CloudFormation 模板或 AWS Systems Manager Automation 文档。
-
在相应的存储库中执行版本控制。
-
包括适当的资源标记，以便可以轻松识别负责人和文档。
-
客户示例
AnyCompany Retail 对“负责人”的定义是：负责某个应用程序或应用程序组（共享通用架构实践和技术）的流程的团队或个人。最初，这些流程和程序以分步指南的形式记录在文档管理系统中，可在托管应用程序的 AWS 账户上以及账户中的特定资源组上，使用标签进行发现。他们利用 AWS Organizations 来管理其 AWS 账户。随着时间的推移，这些流程会转换为代码，并使用基础设施即代码（例如 CloudFormation 或 AWS Cloud Development Kit (AWS CDK)模板）定义资源。运维流程成为 AWS Systems Manager 中的自动化文档或 AWS Lambda 函数，这些流程可以作为计划任务启动，用于响应 AWS CloudWatch 警报等事件或 AWS EventBridge 事件，也可以通过 IT 服务管理（ITSM，IT Service Management）平台内的请求启动。所有流程都有标签，用于标识负责人。用于自动化和流程的文档，保存在由该流程的代码存储库生成的 Wiki 页面中。
实施步骤
-
记录现有的流程和程序。
-
查看并保持最新状态。
-
确定每个流程或程序的负责人。
-
对流程和程序实施版本控制。
-
只要可能，对具有相同架构设计的工作负载和环境，分享流程和程序。
-
-
建立反馈和改进机制。
-
定义审查流程频率的政策。
-
定义审核者和审批者流程。
-
实施问题队列或票证队列，以便提供和跟踪反馈。
-
在可能时，流程和程序应由变更审批委员会（CAB，Change Approval Board）预先审批并进行风险分类。
-
-
确认需要运行这些流程和程序的人员能够访问和搜索到它们。
-
使用标签来指示可以在哪里访问工作负载的流程和程序。
-
使用有意义的错误和事件消息，指明用于解决问题的正确流程或程序。
-
使用 Wiki 和文档管理，确保可在整个企业内稳定地搜索流程和程序。
-
-
在适当时实现自动化。
-
当服务和技术提供 API 时，应开发自动化功能。
-
针对流程充分开展培训。开发用户案例和要求，用于实现这些流程的自动化。
-
衡量流程和程序的成功使用情况，并提出问题以支持迭代改进。
-
实施计划的工作量级别：中等
资源
相关最佳实践：
相关文档：
相关讲习会：
相关视频：
相关服务：
