Классический подход предполагает полное согласование SLA со всеми бизнес-заказчиками до его введения в действие, что часто приводит к задержкам и сложностям с получением согласий. Альтернативный метод 'AS IS' заключается во введении базового SLA, отражающего текущее положение дел, без предварительного согласования со всеми сторонами. Такой подход позволяет быстрее запустить процесс управления сервисами, а бизнесу предоставляет возможность вносить изменения в соглашение по мере необходимости через механизм дополнительных соглашений.

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

Новый KPI использует плавную шкалу оценки между Tmin и Tmax, где решение ближе к Tmin дает максимальный балл, а приближение к Tmax — постепенно снижает рейтинг. Например, инцидент, устраненный за 30 минут при Tmin = 30 и Tmax = 240, получает 100%, а решение за 230 минут — уже около 4%. Это создает прямую мотивацию решать инциденты максимально быстро, так как каждый сэкономленный час напрямую улучшает итоговый показатель эффективности.

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

Definition of Done (DoD) - это концептуальное понятие в DevOps, которое определяет критерии завершения работы над задачей. Это согласованное понимание того, что работа считается выполненной. Согласно концепции DoD, важно иметь единообразное представление о том, что считается завершенной работой, чтобы избежать недопонимания между участниками процесса разработки и эксплуатации. В DevOps эта концепция получила развитие и дополнительное наполнение по сравнению с earlier практиками.

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

Для определения компонентов, влияющих на снижение производительности, следует сравнить текущие метрики с ранее зафиксированными baseline-данными. Если известно, как система вела себя раньше при аналогичной нагрузке, можно выявить те элементы, чьи характеристики изменились. Например, если ранее при 1000 операциях загрузка диска составляла 40%, а сейчас — 90%, это указывает на проблему в дисковой подсистеме. Важно учитывать влияние всех уровней: прикладного ПО, баз данных, серверного оборудования и сети.

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

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

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