ITIL把容量管理分为三个层次：业务层（Business Level）、服务层（Service Level）和组件层（Component Level）。
这三个层次的流程中有许多类似的活动，但是每个子流程有不同的侧重点。业务容量管理侧重于当前和未来的商务业务需求，服务容量管理侧重于支持业务的现有服务的交付，组件容量管理侧重于支撑服务供给的技术基础设施。
1、业务容量管理
业务容量管理把业务需求和规划转变为对服务和IT基础设施的需求，保证IT服务将来的业务需求得到及时的量化、设计、规划和实施。业务容量管理主要考虑将来的业务需求，这些需求来自新的业务或者是业务新的变化（Newly Changed Business）。例如：
- 新服务或者服务方向的改变所提出的需要。
- 已有服务需要改进以提供额外的功能。
- 旧的服务将会被淘汰，释放闲置容量。
这些改变都会影响对客户的SLA能力，容量管理的职责就是预测和管理这些变更带来的容量需求，并且管理这些需求。
2、服务容量管理
服务容量管理关注于端到端性能、现实状况的IT服务使用和工作负载的容量的管理、控制和预测。服务容量管理的主要目标是识别和理解IT服务、资源的使用、工作模式、高峰与低谷等，以保证服务达到SLA目标。
服务容量管理主要考虑目前的业务需求是否得到满足。主要的活动是监控、分析和相应的改进。
3、组件容量管理
组件容量管理是对单个IT技术组件的性能、使用和容量进行管理、控制和预测，保证拥有限定资源的IT基础设施内的所有组件得到监控和测量，并可以记录、分析和报告所收集的数据。组件容量管理的主要目标是识别和理解性能、容量及支撑IT服务技术的单个组件的使用，包括基础架构、环境、数据和应用程序，以保证当前硬件和软件资源得到最佳使用，从而达到和维持既定的服务等级。
容量管理相关的基础要素包含如下三方面。
- 容量阈值的管理和控制
每个应用服务或系统上的资源限制可以被用来建立容量阈值，这个阈值能够被监控活动用来产生警告和异常报告。在确定阈值时要特别小心，因为特定应用的限制是不同的。
服务与系统的阈值管理和控制是有效满足SLA中确定的服务水平的基础。这些阈值被连续和自动监测，并且每当监控阈值被超过或者接近时，将产生警告和异常报告，以促使人们采取合理的补救行动。
阈值监控不仅应该在超过阈值时报警，也应该能够监测变化的速率，并且预测何时将达到阈值，以达到提前预警的目的。例如，磁盘空间监测应监测增长速率，并以当前速率计算在未来几天内是否会引起磁盘空间用尽，以便及时警报。例如，500GB的磁盘已经使用了80%的空间，增长速率是每天20GB，那么5天内将会用尽。
- 新技术的出现
容量管理也应该充分了解新技术带来的优势，如使用虚拟化、公共云计算服务和按需计算（on-demand computing）这类技术和服务，以及如何使用这些技术来支持运营的容量改进。
此信息可以通过利用外部资源来收集，如供应商研讨会、技术博览会、行业或专业网站。在评估这些新技术时，核心是成本导向。在任何时候，容量管理的责任人都应该认识到，新技术的引进和使用必须在成本合理的前提下，并且新技术可以向业务提供实实在在的利益。技术运营需要的是技术带来的成本节约及可用性，而不只是技术的先进性。要充分理解容量管理的目的，不能为了技术而技术。
- 常规化
容量计划的制订和维护应该在规定的时间周期内。实际上，生产线的容量一定会涉及资金预算，因此，与业务或预算的计划周期一样，应该每年完成一次。每个季度的更新是必要的，目的是根据服务需求的变化做相应的调整，以保持容量预测的准确性。虽然需要额外的努力，但如果真的可以定期更新，容量规划则会更加准确，可以满足不断变化的业务需求。
