Use case walkthrough: A tour of Incident Management for DevOps users ►
This video steps through an example of how a DevOps engineer might use Incident Management to resolve an incident.
*Please note Moogsoft is now part of Dell's IT Operations solution called APEX AIOps, and changed its name to APEX AIOps Incident Management. The UI in this video may differ slightly but the content covered is still relevant.
Let’s sample a day in the life of a DevOps engineer in Moogsoft. This incident just came in. We are going to assign it to us and investigate.
![1_Devops_Scenario_with_Sit_Room.jpg](image/uuid-bfd0c2b8-1351-a5b1-89ae-8889a8f3a71b.jpg)
We’re in the Situation Room where our team can collaborate on this incident. And this is the timeline window. It logs how the incident unfolded.
![2_Devops_Scenario_with_Sit_Room.jpg](image/uuid-a227d016-539d-2727-a699-adf95c37fa8f.jpg)
Now, judging from the description, the issue seems to be with the message writing service. Interesting. Let’s take a look at the alerts that rolled up into this incident.
![3_Devops_Scenario_with_Sit_Room.jpg](image/uuid-da79c55d-08e7-b1dd-bc5d-e911f1e533dc.jpg)
This is the first alert. The description says we just deployed an updated message writer service.
![4_Devops_Scenario_with_Sit_Room.jpg](image/uuid-c93e8d1b-3d49-aac3-a17d-452f1db9c0d1.jpg)
Then minutes later, the process duration metric went out of bounds to the critical state. So there seems to be a connection here. Let’s see if this connection makes sense by looking at the metrics.
![5_Devops_Scenario_with_Sit_Room.jpg](image/uuid-fe715ec4-83f3-cf15-9f93-60c659c481f4.jpg)
By default, the metrics screen is set to show the incident range, but we want to see it in the context of what’s normal.
![6_Devops_Scenario_with_Sit_Room.jpg](image/uuid-b7e58550-d186-c1a2-50c0-02c55fb90bd3.jpg)
So we are going to zoom out a bit… and set the time range to the last hour.
![7_Devops_Scenario_with_Sit_Room.jpg](image/uuid-e9c9ade4-2feb-f43d-1d55-43401107ee7b.jpg)
This is where the process duration metrics alert was triggered. Normally, it hardly takes 20 milliseconds to write anything to the database, and now it’s taking several seconds. That’s not good.
![8_Devops_Scenario_with_Sit_Room.jpg](image/uuid-31e841bd-8b47-734f-6b23-15b46f25f604.jpg)
Now we have a choice- we could rollback the deployment and fix the issue in code that’s adding seconds to this process. Or, accept this as a new norm, and have Incident Management learn it. For now, we are going to roll it back.
So we rolled back the service update. And now a few minutes later. Looks like the metrics are back to normal. We’ll examine the message writing service and deploy an updated version when ready.
![9_Devops_Scenario_with_Sit_Room.jpg](image/uuid-0e2e075d-2172-58a8-f7ad-b11988eaf334.jpg)
So let’s go back to the incident view...and close it. There you go! Now you have seen a sample day in the life of a DevOps engineer in Incident Management. Thanks for watching!
![10_Devops_Scenario_with_Sit_Room.jpg](image/uuid-afa94694-bc5e-0a06-e0e9-7577a6bfbab9.jpg)