This blog post is a follow-up to my series of running CMDB for Azure resources. In the previous parts, I shared some guiding principles for organizing your CMDB using Azure tags, so here, I will cover some practical examples of keeping your Azure tags neat and structured at scale.
In the second part of this series, I would like to focus on the Azure-specific aspects of implementing a CMDB. It will be rather a collection of best practices than a prescriptive implementation guide.
Keeping track of your IT resources is not an easy task, especially in enterprise-scale environments with hundreds of business applications, thousands of services, and myriads of dependencies among all of them.
I this part, I will talk a little bit more about the KPIs that are usually used to measure the performance of the Incident Management process implementation and what happens with incidents after they have been resolved.
In the first part of this series, I talked about what an incident is in IT Operation, why you should distinguish them from other types of support tickets and how to put them in order. In this post, I will continue exploring the basic concepts of Incident Management.