A third post on the ‘Doing DevOps with EM13c’ subject.
Previous posts on this subject:
In this post, I will focus on how to do the Incident Management setup to support the DevOps way of working.
In order to keep things simple and understandable I will focus on a basic setup that includes:
- One ‘Dev’ team
- One ‘Ops’ team
Obviously, you could have multiple of these, for instance per application or department.
The scope of the DevOps teams will be based on the fact that we want:
- ‘Dev’ teams only have access to development and test lifecycle targets
- ‘Ops’ teams only have access to acceptance (staging) and production lifecycle targets
For demo purposes, we will limit our requirements:
Based on the target lifecycle stage, Incidents must be routed to the proper team
- Incidents on development and test lifecycle targets must be routed to the ‘Dev’ teams
- Incidents on acceptance (staging) and production lifecycle targets must be routed to the ‘Ops’ teams
Now let’s see how we could implement this in EM13c.
Teams and Scope
In order to implement the scope, we have created a dynamic group (Administration Group) per lifecycle stage:
We will use these groups to authorize teams to access targets.
For this we have created a ‘Developer’ and a ‘Operator’ role:
- EM_RL_DBA_DEVL – ‘Developer’ role
- EM_RL_DBA_OPER – ‘Operator’ role
This example shows the EM_RL_DBA_DEVL role is authorized to access targets in groups ‘DEV TARGETS’ and ‘TST TARGETS’.
Team members now should be granted the proper ‘Developer’ or ‘Operator’ role.
This examples shows administrator DBA_OPER_USER1 being authorized the EM_RL_DBA_OPER role.
In order to implement the requirements, we will:
- Create a NPA administrator per team to allow incident routing
- Create an incident view per team to support incident routing
- Create incident rules to support incident routing
Non Personal Account administrator
For each of the teams ‘Dev’ and ‘Ops’ we have created a NPA administrator.
Incident Rule Sets
In order to route incidents to the proper team we have created 2 Incident Rule Sets
Let’s take a close look at one of them:
The example above shows the incident rule set that gets triggered for events on Test and Development lifecycle stage targets.
Notice that the rule set only includes a rule for ‘Target Down availability status’ events. This is because of demo purpose only. Obviously, you would include rules that cover other events as well.
Notice that as part of the actions as a result of the event includes:
- Creation of an incident
- Set ownership to NPA_DEV_TEAM
In order to have every administrator keep focus on incidents his team is responsible we have created an Incident View per team
In this example, we show the creation of an incident view specifically for the ‘Dev’ team.
We have created these incident views as super administrator EMADMIN and next shared them. This will allow other administrators to use these incident views.
Next, we will stop one of the database to examine the incident creation and processing behavior.
In the example above we stop database orclref1 which is a ‘Development’ lifecycle database and therefor under responsibility of the ‘DEV’ team.
If we now navigate to the IV_DEV_TEAM incident view we will see: