Better define change issue process
We've made good strides to forcing changes to production into a smaller set of pathways for change management. We primarily place environment changes into deploy
, automation
, and change issue
processes that each have their own set of requirements to mitigate risk and record changes. Of these paths, change issue
is the most time intensive for production engineering teams.
How can we reduce the impact of change issues on our teams?
Some options seem "obvious" to me.
- Maintenance and toil tasks to update application options via rails console, API, or pgsql should be encouraged to become application features, for example.
- In some change issues, the only reason the production engineering team is required is due to access limitations. Encouraging requestors to request access could allow reviewed self service for non production engineering individuals to perform change issue tasks. Services like teleport could help with this possibly.
- When a change issue could be performed by automation, we should encourage that become the preferred method to manage change.
Ultimately, this issue is for discussion and creation of issues that could help us reduce the requirement of production engineering teams to take up ownership and manage manual change issues when possible.