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 时,应开发自动化功能。
-
针对流程充分开展培训。开发用户案例和要求,用于实现这些流程的自动化。
-
衡量流程和程序的成功使用情况,并提出问题以支持迭代改进。
-
实施计划的工作量级别:中等
资源
相关最佳实践:
相关文档:
相关讲习会:
相关视频:
相关服务: