This article originally appeared on the Red Hat Blog. To read the original in its entirety, click HERE.
IT operations teams face challenges in Day 2 operations. But what are Day 2 operations?
According to Red Hat’s Bill Cozens, “We talk about three stages of operations: Day 0, Day 1, and Day 2. Day 0 is the “design” stage, where we figure out what resources and requirements are needed to get it all up and running. Day 1 operations describe the “deployment” stage, where we actually install, set up, and configure our software. Finally, Day 2 is the “maintenance” stage. Think of Day 2 as everything you do to make sure your software is cared for and healthy.”
But what kinds of challenges do they face?
- ongoing security risk mitigation
- upgrades and patches
- surrounding technology and environment changes and impacts
- consistency of change
- keeping solutions updated
- compliance needs
- limited staff
- skills gaps
- hiring challenges
- “agile” delivery of services
- short mean-time-to-resolution (MTTR)
- and more
Against this backdrop, IT automation solutions have been helping teams respond faster and with more consistency and efficiency.
For example, a team needs to patch 100 servers due to a newly-identified security risk. Red Hat Ansible Automation Platform can perform a task in minutes that would normally take hours or even days to complete.
This type of automation is in use across IT operations of all sizes, because of the benefits in streamlining operations.
Observe and respond: Event-driven automation
So, what’s next? Event-driven automation is a way that IT teams can advance their use of automation even further. In the use cases above, Ansible Playbooks are created and then an IT staff member manually initiates their execution. This is a great model for large-scale changes, such as the planned patching of 100 servers.
In an event-driven model, the automation is contained in Ansible rules in the format of an if-this-then-that approach. Event-driven automation is ready and waiting to be triggered by an event, so it is good for responding to an observed event. For example, if a router is not responding, event-driven automation will create a ticket and reboot the router. Ansible rules (via Ansible Rulebooks, see below) remain always on–ready and waiting for events or conditions that trigger their use–enabling an automated response.
Red Hat’s event-driven automation solution is Event-Driven Ansible, which works based on three constructs contained in a structure called an Ansible Rulebook:
Sources: Generators of events—for instance, a third-party monitoring tool that identifies and communicates when a web server is down. Event-Driven Ansible consumes events from third-party tools or your own custom sources using source plug-ins. Our ISV (independent software vendor) partners are currently working on creating plug-ins between their technology and Event-Driven Ansible, and you can create your own custom event source plug-ins as well.
Rules: Rules are conditional statements that attempt to match event conditions. Once a condition has been matched, a defined action can take place. For example, a rule may specify that when a web server is down, a service ticket is created and the web server is rebooted. While rulebooks and playbooks are both written in YAML, a rulebook specifies the event source, and is structured in an if-this-then-that approach. Note that existing Ansible Playbooks can be called within rulebooks as actions to be taken when conditions are met. Alternatively, actions can be directly described via modules. These rulebooks are ready when the event is communicated to the decisioning capability within Event-Driven Ansible.
Actions: Once a condition in a rulebook is matched, a corresponding action can be triggered. Some actions that can be triggered are the running of an Ansible Playbook, an individual module, a template in automation controller as well as the setting of facts or creating another event.
Why use event-driven automation?
Put simply, it helps reduce the burden on limited staff, and is fast, automatic, and consistent in the way it responds. The use cases can range from simple notifications and fact-gathering to remediation or other technical actions. Event-Driven Ansible is flexible enough for teams to decide what level of response they would like.
Due to its versatile rulebooks and overall flexible architecture, Event-Driven Ansible is use case-friendly and can be used in departments across the organization to reduce routine and high-volume reactive tasks. Its YAML capabilities make it an ideal advanced technology for today’s Ansible users, and can maximize your investment in Ansible Automation Platform. It avoids long and sometimes costly IT services and projects to build event-driven solutions–so anyone across your IT team has access to the technology to help reduce the manual burden in ways that serve their needs.
For IT leaders, this means operations can be much more responsive and resilient. For IT staff, this provides a better work-life balance and also reduces the need for manual responsive tasks, so teams can focus on the innovations that matter and take on more challenging work.
Check out the IDC QuickTake from AnsibleFest 2022, which discusses Event-Driven Ansible or get started yourself.