DevOps and Incident Management in EM13c


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

NPA Administrators

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

Incident Rule Sets

Let’s take a close look at one of them:

DEV Team responsible incidents

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

Incident View IV_DEV_TEAM

In this example, we show the creation of an incident view specifically for the ‘Dev’ team.

Incident Views

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.

Shutdown database orclref1

Stopping database orclref1

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:

Incident in IV_DEV_TEAM

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s