4.3Capacity management (demand forecasting, thresholds, trend analysis)

Capacity management is not a reactive task of "augment once performance runs short." Avoiding both over-investment (holding too much unused equipment) and under-investment (SLA breaches from insufficient performance), its essence is to read demand growth ahead of time and secure exactly the capacity needed, when needed, most cost-effectively. This section organizes what is managed via three sub-processes and builds the judgment to catch signs of shortfall at the early-warning stage through threshold monitoring and trend analysis, and to decide whether to augment or to level demand through demand management.

4.3.1The three sub-processes

• Business capacity management is the most upstream sub-process, forecasting mid-to-long-term required capacity from the business plan and future business demand (planned new services, expected user growth, etc.). Service capacity management monitors and manages end-to-end performance per individual service to meet SLA performance targets (response time, throughput, etc.). Component capacity management is the most downstream sub-process, monitoring and managing the utilization of individual resources (components) such as CPU, memory, disk, and line bandwidth.
• The three sub-processes connect from upstream to downstream: "business -> service -> component." Looking only at a single component's utilization cannot tell you how it affects the SLA (service performance) or business growth—for example, rising CPU utilization does not immediately require augmentation if it is not affecting the SLA response time. Conversely, if the business plan foresees a large user increase, an augmentation plan is drawn up ahead of time even with current headroom. Judging by cross-referencing the three viewpoints is the crux of capacity management.

4.3.2Threshold monitoring, trend analysis, and bottlenecks

• Threshold monitoring sets warning values (e.g., 80% CPU utilization) on resource usage and raises an alert on exceedance so action is taken before exhaustion. Trend analysis extrapolates and forecasts future increases from the historical progression of utilization, estimating when a threshold will be reached. Whereas threshold monitoring catches "an anomaly now," trend analysis reads ahead to "when the limit will be reached at this rate," and is used to plan augmentation with margin.
• A bottleneck is the resource with the least headroom that limits overall system performance. No amount of augmenting a non-bottleneck resource improves overall performance (e.g., adding memory when the CPU is the bottleneck does not shorten response time). Forecasting where the bottleneck will move via trend analysis and augmenting there specifically is the cost-effective capacity plan. Because a bottleneck can move to another resource as load rises, it is monitored continuously rather than once.

4.3.3Choosing between demand management and augmentation

• Demand management acts on demand itself to level peaks and reduce the required equipment capacity. Through time-of-day pricing (off-peak discounts), shifting batch processing to nighttime, reservation-based usage, and the like, lowering the instantaneous peak load avoids having to hold excess equipment sized to that peak. Whereas augmentation (adding capacity) "matches supply to demand," demand management is the reverse approach of "matching demand to supply."
• Augmentation and demand management are not either/or; they are chosen based on cost, feasibility, and impact on the SLA. If demand grows persistently, augmentation is the main route, but if the problem is a short peak, peak leveling (demand management) is often the cheaper fix. Discerning at the early-warning stage—"a structural shortfall requiring augmentation, or a temporary peak that leveling can absorb"—via trend analysis is the service manager's judgment.

Suppose the service manager of an internal business system is diagnosing a problem where, at month-end, response time exceeds the SLA target (within 3 seconds) and the user department complains. The component-capacity-management monitoring data shows the database server's CPU utilization spiking to 95% only during the few days at month-end, hovering around 40% at normal times. Deciding glibly to "augment the server because CPU utilization is high" is not necessarily optimal on cost-effectiveness. What should be checked first is whether this high load is a persistent demand increase (rising in trend analysis) or a temporary peak concentrated at month-end. Suppose trend analysis finds that normal-time utilization is flat and that the month-end monthly batch aggregation is competing for the same time window as daytime online work. In this case the cause is not a persistent capacity shortfall but a concentration of demand (a peak), so rather than server augmentation (increasing supply), demand management that moves the monthly batch to nighttime off-peak hours levels the month-end CPU peak with no additional investment and resolves the response-time SLA breach. Discerning the bottleneck also matters: even if memory were added, response time would not improve as long as the CPU is the limiter—augmenting a non-bottleneck resource is wasteful. Rather than reflexively responding to a threshold-exceedance alert (a present anomaly) with augmentation, a service manager uses trend analysis to separate "a structural shortfall from a temporary peak," identifies the bottleneck, and then judges which of augmentation or demand management meets the SLA more cost-effectively.

4.3.4Section summary

• Capacity management judges by cross-referencing three sub-processes: business (mid-to-long-term forecast), service (SLA performance), and component (individual resources)
• Threshold monitoring detects a present exceedance; trend analysis reads ahead to when the limit will be reached, enabling augmentation planned with margin
• Augmenting anything but the bottleneck does not improve the whole—a temporary peak can often be resolved cheaply via demand management (leveling)