Готовность команды к переходу на более частые релизы можно оценить по следующим критериям: уровень автоматизации процессов сборки и тестирования (чем выше, тем лучше); наличие стабильных и легко воспроизводимых тестовых сред; степень покрытия кода автоматическими тестами; способность команды обнаруживать и исправлять проблемы в течение короткого времени; размер типичных изменений в релизе (маленькие изменения предпочтительнее); зрелость процесса обратной связи от production; способность к быстрому развёртыванию отката в случае проблем; культура совместной ответственности за качество; опыт работы с практиками непрерывной интеграции. Также можно использовать метрики, такие как среднее время восстановления после сбоя (MTTR), процент прохождения автоматических тестов, время от коммита до развёртывания. Чем лучше выполнены эти критерии, тем выше готовность команды к частым релизам.

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

Согласно книге, каталог ИТ-услуг является ключевым звеном в управлении ИТ-подразделением, которое функционирует внутри компании. Он позволяет ИТ-директору управлять подразделением практически как бизнес-единицей, даже если реальных взаиморасчетов нет. Каталог служит основой для установления сервисных отношений с бизнес-подразделениями, определения стоимости услуг и организации Service Level Management. Авторы книги подчеркивают важность каталога как инструмента, который помогает ИТ-руководству позиционировать свою деятельность в терминах бизнеса и обосновывать необходимость организационно-культурных изменений при переходе на сервисные отношения.

Практика управления рисками тесно интегрирована с другими практиками ITIL, поскольку после реализации риска необходимо проанализировать ситуацию, извлечь уроки и внедрить улучшения. Например, управление инцидентами предоставляет данные о произошедшем событии, управление проблемами помогает определить его причину, а практика постоянного улучшения (continual improvement) использует информацию для оптимизации процессов и снижения будущих рисков.

Неформальная часть сервисных отношений заключается в ориентации на реальную ценность для заказчика, а не просто на формальные показатели. Это включает в себя выяснение настоящих потребностей заказчика, а не только его заявленных запросов, регулярные контакты и измерение удовлетворенности. Неформальная часть важна, потому что часто то, что можно точно измерить через формальные SLA, не соответствует реальным бизнес-результатам, которые необходимы заказчику. Например, в гостинице может быть кондиционер в номере (формальный показатель), но если он установлен так, что дует прямо на кровать, то реальная ценность для гостя теряется. Ориентация на ценность позволяет поставщику определять и предоставлять именно те услуги, которые действительно удовлетворяют потребности заказчика.

Для предотвращения деградации CI/CD процесса после внедрения необходимо установить четкие правила, что 'назад пути нет, а половины конвейера не бывает'. Следует договориться, что конвейер работать должен всегда, без исключений, и нет других способов доставки изменений в эксплуатационную среду кроме как через него. Нужно удалить административные права на объекты инфраструктуры у всех, кроме конвейера. Рекомендуется стремиться к полному Continuous Deployment вместо менее совершенных вариантов (CI или CD), чтобы убрать 'волшебный рубильник', когда человек принимает решение о ручном релизе. Это означает, что все изменения, прошедшие через конвейер, автоматически попадают в рабочую среду без ручного одобрения. Такой подход не оставляет места для временного отключения части системы, например, автотестов, и гарантирует устойчивость процесса в долгосрочной перспективе.

Цифровая компания использует в производственном процессе технологии, которые дают преимущества сразу по нескольким направлениям: сокращение производственных затрат за счет исключения операций, выполняемых людьми (что снижает число дефектов и потери времени); повышение эластичности производства (скорость и возможность реагирования на изменения спроса); повышение эффективности сбыта через расширение каналов приобретения, маркетинговую поддержку и сокращение дистанции между поставщиком и потребителем; повышение эффективности управленческих решений за счет объективной информации о процессах.

Процесс управления изменениями на начальном этапе может внедряться как простой способ обновления CMDB. В этот период цель по снижению негативного влияния изменений может быть отложена, и основное внимание уделяется единообразному проведению изменений. Стабильная работа процесса в части единообразия уже частично способствует улучшению ситуации с негативным влиянием изменений.

Мандатная модель (MAC) предполагает жёсткую привязку пользователей и информации к уровням допуска (например, 'секретно', 'совершенно секретно'). Все ресурсы одного уровня автоматически доступны всем, у кого есть мандат на этот уровень. Основной недостаток — негибкость: добавление новых классов секретности усложняет систему. Дискреционная модель (DAC) настраивает доступ на уровне отдельных объектов и операций для каждого пользователя через матрицу разрешений (таблицы доступа). Это даёт максимальную детализацию, но требует громоздкого администрирования при росте системы. Ролевая модель (RBAC) группирует права в бизнес-роли (например, 'бухгалтер', 'менеджер'). Пользователи получают доступ через назначение ролей, а не прямое управление объектами. Это сочетает структурированность (как в MAC) и управляемость (лучше, чем в DAC), так как изменения в правах вносятся на уровне ролей, а не пользователей. RBAC также поддерживает иерархию ролей и разделение полномочий, что недоступно в других моделях.

Логические модели приложений и услуг в CMDB должны включать не только физические ресурсы, такие как оборудование и сети, но и функциональные роли ресурсов. Например, отдельно указываются такие роли, как СУБД (базы данных выделяются отдельно), web-сервер, файл-сервер и другие. Функциональные роли являются обязательным элементом модели, поскольку именно с ними связаны единицы объёма потребления, специфичные для них затраты и зависимости мощности от обеспечивающих ресурсов. Это позволяет более точно планировать потребности в мощностях и ресурсах для поддержки услуг.