В ITIL v4 практика управления сервисными конфигурациями связана практически со всеми остальными практиками, особенно с сервисными практиками: управление инцидентами, управление проблемами, управление доступностью, управление мощностями, управление уровнем услуг, управление безопасностью. Конфигурационная информация необходима для принятия оперативных и тактических решений в этих практиках. Практика управления ИТ-активами имеет более опосредованные связи с сервисными практиками: финансовая информация учитывается при принятии решений, но обычно на основе уже зафиксированных ценников, а не в реальном времени. Зато управление ИТ-активами тесно связано с общеуправленческими практиками, особенно с управлением финансами ИТ-услуг. Понимание этих паттернов связей помогает определить, какие информационные потоки критичны, а какие могут быть менее оперативными, и соответственно спроектировать процессы.

На этапе выявления требований осуществляется взаимодействие с бизнесом и сбор требований к ИТ-системе. Заказчики формулируют требования в терминах бизнес-операций, при этом ИТ-специалисты должны принимать активное участие в формировании требований. Важно получить информацию о потребительских характеристиках, которые могут повлиять на архитектуру решения и требования к мощностям: число одновременно работающих пользователей, доступность, время выполнения определённых операций. Эти требования могут не прозвучать в первоначальных требованиях бизнеса, но оказывают непосредственное влияние на архитектуру и ресурсы. Также желательно получить прогноз изменения требований в будущем.

В результате работ по мониторингу и прогнозированию могут быть определены мероприятия по управлению мощностями, направленные как на увеличение мощности ИТ-ресурсов, так и на перераспределение нагрузки между имеющимися ресурсами. В некоторых случаях возможно провести работы по изменению характера потребления ИТ-сервисов, позволяющие без изменения ИТ-инфраструктуры добиться приемлемого качества. Например, отказ от формирования отчётности в рабочее время может высвободить необходимые ресурсы во время пиковых нагрузок на ИТ-системы. Другой пример: вместо наращивания мощности оборудования банк может заблаговременно уведомить клиентов о возможных задержках при проведении операций в период пиковых нагрузок.

На этапе передачи в эксплуатацию осуществляется проверка выполнения всех требований, необходимых для начала эксплуатации ИТ-системы. С точки зрения управления мощностями важна проверка соответствия заявленных характеристик фактическим, а также наличие средств мониторинга характеристик ИТ-ресурсов, ИТ-систем и ИТ-сервиса.

Управление доступностью и мощностями объединено, например, в COBIT 5, где требуется одновременно обеспечить минимальное количество прерываний и достаточное быстродействие. Это создаёт конфликт, потому что требуемый уровень доступности, достигаемый резервными компонентами, является недостатком для управления мощностями: резервный компонент простаивает в нормальном режиме эксплуатации, а мог бы повысить производительность. И наоборот: повышенная производительность системы означает, что в ней задействовано большее число компонентов, сами компоненты сложнее и более ресурсоёмки, стоимость их выше — всё это угрозы для конечного значения доступности. Аналогичные конфликты возникают и в прочих сочетаниях процессов управления гарантией. Поэтому поиск равновесного значения будет более объективным, если каждая составляющая гарантии отслеживается отдельным владельцем процесса.

Все процессы управления гарантией ИТ-услуг создают планы, в которых зафиксирован хронологический порядок применения мер по обеспечению гарантии. В плане управления доступностью предусматривается не только внедрение средств повышения отказоустойчивости ИТ-компонентов, но и то, как эти средства должны эксплуатироваться (например, регулярные проверки механизма автоматического переключения на резервный канал связи). В процессе управления непрерывностью обеспечиваются аналогичные проверки аварийных мощностей. В процессе управления мощностями требуется регулярно анализировать нагрузку на мощности ИТ-инфраструктуры и предсказывать производительность на ближайшие периоды. Особняком стоит процесс управления информационной безопасностью, где основным артефактом становится политика информационной безопасности и её производные. При этом в соответствии с циклом Деминга (на котором основан и стандарт ISO/IEC 27001) есть требования к регулярно повторяемым проверкам и совершенствованию механизмов, знаний сотрудников и аудитам ИБ.

Ресурсно обоснованное планирование способствует управлению мощностями, поскольку требует детального учёта потребления ресурсов в натуральных единицах (ядра процессоров, гигабайты памяти, объём хранения, пропускная способность каналов). Это вынуждает организацию постоянно контролировать текущие и плановые мощности, прогнозировать изменение потребления, выявлять дефицит или избыток ресурсов. Заказчики, видя стоимость потребления, начинают управлять своим спросом, что также влияет на планирование мощностей. Таким образом, ресурсно обоснованное планирование естественным образом интегрируется с процессом управления мощностями и стимулирует его развитие.

Выделяются четыре класса угроз. Первый — сбои (отказы) в компонентах из-за их ненадёжности или нарушения условий эксплуатации; пример защитного средства — избыточные массивы для хранения данных; механизм может не сработать, если сбои на каналах передачи данных не позволяют наполнить массивы резервными копиями; минимизирует угрозу процесс управления доступностью. Второй — дефицит ресурсов для удовлетворения спроса; пример — гибкая система изменения количества лицензий на ПО; механизм может не сработать, если недостаточные аппаратные ресурсы для дополнительной вычислительной нагрузки не являются гибкими; минимизирует угрозу процесс управления мощностью. Третий — чрезвычайные разрушительные обстоятельства; пример — облачное хранение данных и настроек; механизм может не сработать, если лицо, ответственное за реквизиты доступа в облако, недоступно; минимизирует угрозу процесс управления непрерывностью. Четвёртый — искажение или утечка информации при потреблении услуги; пример — защита от сетевых атак, встроенная в ОС; механизм может не сработать, если новые сетевые угрозы появляются раньше средств защиты от них; минимизирует угрозу процесс управления безопасностью.

В категории «Инфраструктура» контрмеры связаны с процессами стратегического планирования (получение от бизнеса информации о грядущих инициативах для прогнозирования нагрузки), процессами управления доступностью и мощностями (в COBIT 5 они объединены в единый процесс, в отличие от ITIL, где они разделены), процессом управления сервисами безопасности (Manage Security Services), администрированием безопасности (Firewall, IDS, IPS), а также отчётами о статусе KPI и SLA с точки зрения текущего состояния и прогнозирования загрузки. Эти меры помогают не допустить реализации рисков невозможности масштабирования и отказов вследствие растущей потребности в мощностях.

2009 и 2010 годы заставили многих пересмотреть подход к управлению мощностями: от постепенного наращивания в сторону именно управления, включая пересмотр требований к ИТ-системам и характеру их работы. Например, вместо наращивания мощности оборудования некоторые банки предпочли заблаговременно уведомить своих клиентов о возможных задержках при проведении операций в период пиковых нагрузок.