Service Delivery Risk Mitigation

It is important to identify current and ongoing risks of an IT service delivery failure. When assessing those risks, you should take into account the relative importance of different IT services. Business-critical services should naturally receive more attention and more planning to minimize risks and ensure consistent delivery of those services. Prioritizing IT services helps IT focus attention and resources where they are most needed in order to generate business value.

Both strategic planning and operational processes are required to mitigate service delivery risks. Planning failures occur when service demand forecasts are incorrect, resources to support demand are inappropriately sized, or planning for high availability is inaccurate. Operational failures include the failure of a hardware or software component, and capacity problems in the network, servers, or storage devices.

Business requirements, demand projections, architectural policies and IT process maturity all factor into the assessment of service delivery risks.

TeamQuest Software Addresses Service Delivery Risk Mitigation

In large data centers, it is very difficult to monitor every system for potential problems. Instead, IT organizations can create exception reports based on alarms that get triggered when a linear projection line exceeds a threshold. This method identifies, for example, that based on historical data, CPU will be in the 80% - 90% busy range in two months. Early notification of the impending problem is provided; there is time to react and determine how to avoid the problem, so that service-level objectives can be maintained.

In this example, a linear projection report of CPU percent busy shows a threshold of 85% busy for a server, and that the CPU percent busy linear projection will surpass that threshold on October 11. You have time to react to potential problems that may surface in the future.

To determine the most cost-effective way to avoid such a problem, you can model the system using TeamQuest Model.

This chart generated by TeamQuest Model shows App4 at a stretch factor of around 10, well above acceptable levels. Stretch factor is a relative gauge of the amount of time the process spends waiting to be serviced versus actually being serviced. A stretch factor above two usually requires attention.

Although investigation was initiated due to a CPU issue, further analysis shows memory to be the real culprit. This Components of Response Time report, also generated by TeamQuest Model, clearly identifies memory as a real problem. This is good news since buying memory is much less expensive than buying more CPUs. Not only is the hardware cheaper, but unlike CPU's, software maintenance fees are rarely priced on the amount of memory on a system.

Doubling the amount of memory in the model results in a dramatic decrease in stretch factor. The issue is resolved. However, stretch factors are still hovering around two, and another look at the new Components of Response Time report would be prudent.

This Active Resource Utilization chart shows that by doubling the amount of memory on the server, thereby allowing more work to flow through the system, a potential disk problem has been introduced.

To resolve the disk bottleneck, the I/O is balanced amongst a total of four disks in the model. Results show the server performing well and within Service Level Agreement specifications.

Using TeamQuest Model, you can accurately predict the performance effects of hardware changes. Implementing these hardware changes will effectively resolve the otherwise looming capacity limitations and allow you to maintain service-level objectives for the applications running on this server.