OPS02-BP02 Processes and procedures have identified owners
Understand who has ownership of the definition of individual processes and procedures, why those specific process and procedures are used, and why that ownership exists. Understanding the reasons that specific processes and procedures are used aids in identification of improvement opportunities.
Desired outcome: Your organization has a well defined and maintained set of process and procedures for operational tasks. The process and procedures are stored in a central location and available to your team members. Process and procedures are updated frequently, by clearly assigned ownership. Where possible, scripts, templates, and automation documents are implemented as code.
Common anti-patterns:
-
Processes are not documented. Fragemented scripts may exist on isolated operator workstations.
-
Knowledge of how to use scripts is held by a few individuals or informally as team knowledge.
-
A legacy process is due for an update, but ownership of the update is unclear, and the original author is no longer part of the organization.
-
Processes and scripts are not discoverable, so they are not readily available when required (for example, in response to an incident).
Benefits of establishing this best practice:
-
Processes and procedures boost your efforts to operate your workloads.
-
New team members become effective more quickly.
-
Reduced time to mitigate incidents.
-
Different team members (and teams) can use the same processes and procedures in a consistent manner.
-
Teams can scale their processes with repeatable processes.
-
Standardized processes and procedures help mitigate the impact of transferring workload responsibilities between teams.
Level of risk exposed if this best practice is not established: High
Implementation guidance
-
Processes and procedures have identified owners who are responsible for their definition.
-
Identify the operations activities conducted in support of your workloads. Document these activities in a discoverable location.
-
Uniquely identify the individual or team responsible for the specification of an activity. They are responsible to verify that it can be successfully performed by an adequately skilled team member with the correct permissions, access, and tools. If there are issues with performing that activity, the team members performing it are responsible for providing the detailed feedback necessary for the activity to be improved.
-
Capture ownership in the metadata of the activity artifact through services like AWS Systems Manager, through documents, and AWS Lambda. Capture resource ownership using tags or resource groups, specifying ownership and contact information. Use AWS Organizations to create tagging polices and capture ownership and contact information.
-
-
Over time, these procedures should be evolved to be runnable as code, reducing the need for human intervention.
-
For example, consider AWS Lambda functions, CloudFormation templates, or AWS Systems Manager automation docs.
-
Perform version control in appropriate repositories.
-
Include suitable resource tagging so owners and documentation can readily be identified.
-
Customer example
AnyCompany Retail defines ownership as the team or individual that owns processes for an application or groups of applications (that share common architetural practices and technologies). Initially, the process and procedures are documented as step-by-step guides in the document management system, discoverable using tags on the AWS account that hosts the application and on specific groups of resources within the account. They leverage AWS Organizations to manage their AWS accounts. Over time, these processes are converted to code, and resources are defined using infrastructure as code (such as CloudFormation or AWS Cloud Development Kit (AWS CDK) templates). The operational processes become automation documents in AWS Systems Manager or AWS Lambda functions, which can be initiated as scheduled tasks, in response to events such as AWS CloudWatch alarms or AWS EventBridge events, or started by requests within an IT service management (ITSM) platform. All process have tags to identify ownership. Documentation for the automation and process is maintained within the wiki pages generated by the code repository for the process.
Implementation steps
-
Document the existing processes and procedures.
-
Review and keep them up-to-date.
-
Identify an owner for each process or procedure.
-
Place them under version control.
-
Where possible, share processes and procedures across workloads and environments that share architectural designs.
-
-
Establish mechanisms for feedback and improvement.
-
Define policies for how frequently processes should be reviewed.
-
Define processes for reviewers and approvers.
-
Implement issues or a ticketing queue for feedback to be provided and tracked.
-
Whereever possible, processes and procedures should have pre-approval and risk classification from a change approval board (CAB).
-
-
Verify that processes and procedures are accessible and discoverable by those who need to run them.
-
Use tags to indicate where the process and procedures can accessed for the workload.
-
Use meaningful error and event messaging to indicate the appropriate processes or procedures to address an issue.
-
Use wikis and document management, and make processes and procedures searchable consistently accross the organization.
-
-
Automate when appropriate.
-
Automations should be developed when services and technologies provide an API.
-
Educate adequately on processes. Develop the user stories and requirements to automate those processes.
-
Measure the use of your processes and proceedurees successfully, with issues to support iterative improvement.
-
Level of effort for the implementation plan: Medium
Resources
Related best practices:
Related documents:
Related workshops:
Related videos:
Related services:
