MIRAT is a software solution for IT Infrastructure service management automation. The software is owned and licensed by NovelIRS – Novel Inductive Reasoning Software (www.novelirs.com). Plainly put, MIRAT is an integrated service management tool and automation platform that is heavily aligned with Information Technology Infrastructure Library (ITIL) and can perform every ITIL process within the software itself. This solution can also be used for other IT Operations.
MIRAT’s main benefit lies in its automation platform. This offers the potential for support groups across Database, Operating System, Network, Middleware, and Application Spaces the opportunity to encapsulate their support process into automation.
Automation has the ability to pick up any type of alert that can be received through integration with the Event Management system, using the regular matching expression. A matched automation may then run through a similar set of steps that a human engineer would follow, by traversing a logic tree stored in MIRAT.
This means the operation process followed by engineers to resolve commonly seen issues can be encapsulated into MIRAT. The process captured may be anything from simple diagnostic work to deeper remediation efforts, wherein automation will attempt to resolve an infrastructural issue without any human intervention.
In the logic tree that automation will follow, there may be multiple outcomes including accounting for failures that are outside the automation’s scope. In broad terms, automation will always do one of the following:
MIRAT has an in-built Problem Management module that automatically builds problem cases of recurring events. Thresholds may be identified such that if a type of event hits a certain number of recurrences, then a problem ticket is automatically generated at an appropriate Operations team’s end. A problem ticket suggests that there are underlying issues with a CI that are causing recurrences of events and, therefore, should be looked at with greater attention. The Problem Management Module shows the group a way to track this.
MIRAT has a correlation engine that can group similar tickets to gather base on the specified criteria. This may mean that for noisy CIs or in the case of an event storm, the number of actionable tickets reaching the Operations Engineers may be reduced.
MIRAT includes change/request workflow engine that may be used to manage the requests from the standard Request Management Systems to automatically action request send from the systems. The request can also be fulfilled conditionally, taking into account any procedure and knowledge of the environment needed to fulfill requests. Example: Add new users only after the closure of business.
Event tickets are passed through MIRAT as a part of the flow. They originate from Monitoring Agent and are aggregated based on auto-ticketing table and correlation rules. Listener Module matches against Monitor and Workflow, which enrich the event-data with extra information.
This event is then picked up by MIRAT and it invokes respective automation if Routing=Automation defined.
Automation is a captured operational process which can run automatically with little or no human interaction, triggered by events/requests. Each Automation is based on a standardized operational process captured from the Operational Support groups – it is enclosed into pseudo code and a flow chart to capture both the processes is followed. Commands are used and signed off, as the authoritative process, by the Support group leads. This process is then created as Automation within MIRAT.
Automation may be written to react to an individual scenario or many. Automation ‘match’ to alerts based on a set of predefined criteria, called a matcher. A Matcher is a regular expression or a set of regular expressions, such that when fulfilled by one or more fields in an incoming alert/ticket, it will set the specific automation running.
Once Automation is matched to a ticket, it will proceed through a logic tree of decision points defined by the operational process. In event management terms, this could be attempting to resolve an issue. For example, bringing down a file systems space utilization below the defend threshold. In this scenario, Automation would work through each of steps an engineer would manually conduct – Logging in to the target CI, running commands to determine utilization, and then attempting to bring the utilization down below a threshold based on a series of signed off commands, and acceptable types of file to delete.
In real terms, the CI that is the Target Automation will either cut an alert ticket via a monitoring tool which triggers the automation, or will be included in a service request/change. Automation matching this will then attempt to connect into this CI using a Microservice API, JCH API to connect to DMZ JUMP HOST and then command line utility. This may be something like SSH/YML SCRIPT, or WINRM – PowerShell for OS level access. Automation will update the ticket and either restore automatically if the issue gets resolved or transfer on to an engineer for diagnosis.
MIRAT has an in-built Reporting Module. This module may be used to generate canned reports to show operational data about the platform. Current reports are set up to show the ticket-volume trends in automation success/failure, as well as in the distribution of tickets across the shifts.
MIRAT is based around a foundation of auditable actions; each Automation run is stored in the platform for a short-term, and archived. This means that any automated action taken by the tool may be recalled and reviewed for audit purposes. Similarly, any time that a password looked up and used from the Platforms Password Safe, an audit trail will be logged within the platform.