Introduction

A third post on the ‘Doing DevOps with EM13c’ subject.

 

 

 

 

 

Previous posts on this subject:

• DevOps and EM13c – Best Practices
• Making DevOps work in EM13c – Database Privileges

In this post, I will focus on how to do the Incident Management setup to support the DevOps way of working.

Teams

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.

Scope

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

Requirements

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

Implementation

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.

Requirements

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

Incident views

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: