Each business’s experience will be different, and we encourage organizations to rate potential automations according to their needs.
For example, if you find that your team often experiences a considerable time lag between when an incident is detected and when the appropriate skilled person begins to react, you may find that automating the process of identifying the correct responder can have a high impact, can be relatively easily implemented and should be prioritized.
The level of difficulty to implement an automation will depend on a number of factors, including the maturity level of existing development processes, as well as available skills and tools.
For instance, to perform automated release validation, an organization will require a CI/CD tool, internal continuous development cultures and processes, and an integrated monitoring system for measuring the performance of new code.
It also involves important decisions about preferred approaches to testing, which could include canary and blue/green deploys, all of which requires processes and measurement before validating for production.
These tools, processes, cultures and decisions must be in place to achieve the most impact from automating release validation.
The tools required to implement an automation may vary, with overlaps in capabilities across tool categories.
For example, grouping alerts or issues into incidents can be done by a monitoring, incident management, alerting or event-correlation tool. Or, multiple tools may be used for different types of alert or issue groups. In complex automations, multiple tools may need to be strung together.
Additionally, there are general-purpose robotic process automation (RPA) tools that can be used to build some of the automations required in monitoring and incident response.
We encourage organizations to determine a comfort level in terms of human involvement for each automation. For some automations, teams may want a human to review the proposed action and authorize it.
Other automations, such as ticket creation and enrichment, may be regarded as low risk and thus not require human permissions.
Users of 451 Research’s taxonomy framework may want to add a column rating the potential risk of each automation based on the requirements of the business.