Резервирование компонентов повышает доступность системы, так как в случае отказа основного компонента система может быстро переключиться на резервный, минимизируя простои. Однако резервные компоненты простаивают, когда не используются, что негативно сказывается на общей мощности системы и ее экономической эффективности. Это создает противоречие: меры, направленные на увеличение доступности, могут уменьшать эффективное использование ресурсов системы и снижать ее мощность.

Правильная организация деятельности по управлению ИТ-сервисами включает несколько ключевых шагов: 1) Определение предоставляемых ИТ-сервисов (например, электронная почта); 2) Выявление важных для заказчиков параметров этих сервисов (например, доступность); 3) Определение способов влияния на эти параметры (например, через обработку пользовательских обращений, контроль компонентов инфраструктуры, аккуратное внедрение изменений); 4) Организация деятельности в виде процессов (управление инцидентами, событиями, изменениями), которые решают задачи, определенные на предыдущем этапе. Оптимально использование установленных подходов, таких как ITIL или ISO. 5) Постоянный контроль качества ИТ-сервисов и формирование предложений по совершенствованию как самих сервисов, так и поддерживающих их процессов. Такой подход позволяет достичь баланса между управлением процессами и управлением сервисами.

Прозрачность считается более эффективным инструментом, чем административное управление, потому что она создает естественную мотивацию к улучшению через открытость информации, а не через навязывание решений сверху. Когда люди видят реальные данные о работе своей команды и других команд, это создает внутреннее стремление к улучшению, а не формальное выполнение указаний руководства. Административные команды вроде 'срочно всем уменьшить time to market' без контекста и данных обычно дают краткосрочный эффект и могут вызывать сопротивление или непонимание. В то время как прозрачность позволяет каждому участнику процесса видеть свой прогресс, понимать, где и как можно улучшить работу, а также видеть успехи коллег, что создает здоровую конкуренцию и культуру постоянных улучшений на основе фактов, а не указаний.

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

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

Рекомендации по формулированию KPI в ITIL 4 представлены через факторы успеха практик (PSF). Для каждой практики определяются PSF, каждый из которых сопровождается подробным описанием и примерами метрик, которые можно использовать в качестве KPI. Например, для практики управления инцидентами PSF «раннее выявление инцидентов» имеет следующие примеры KPI: время между возникновением и обнаружением инцидента и доля инцидентов, выявленных с помощью мониторинга. Такая структура делает процесс формулирования KPI более простым и понятным, поскольку она предоставляет конкретные рекомендации и примеры измерений для каждого важного аспекта практики.

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

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

Наличие этапа 'Отложено' в потоке создания ценности приводит к следующим дисфункциям: размытой ответственности, так как команда перекладывает вину на внешние факторы; повышенным требованиям к контролю, поскольку процесс становится менее предсказуемым; управлению через жесткие дедлайны, что создает стресс и искусственно ускоряет работу; управлению дефектами как отдельной активностью, так как отложенные задачи теряют контекст и качество; смещению фокуса с создания ценности на простое выполнение работы без результативности. Все это приводит к тому, что команда может быть постоянно занята делами, но конечные результаты будут неудовлетворительными.

Высокий процент дефектов в бэклоге (от 50% до 70%) может считаться нормой в некоторых командах из-за искажения восприятия, вызванного изоляцией от внешних стандартов и отсутствием объективных метрик. В таких командах сложилась привычка, что большое количество ошибок — это обычная ситуация, особенно если нет возможности сравнить свою работу с работой других команд или отраслевыми стандартами. Коллективное мнение вроде «бывало и хуже» укрепляет это представление, и сотрудники перестают видеть проблему, так как ежедневно взаимодействуют с этим состоянием и перестают замечать его ненормальность.