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

Предлагается использовать три ключевых показателя, отражающих разные аспекты влияния простоев на бизнес: 1) Суммарное время простоев за период, отражающее общий объем недоступности; 2) Максимальный разовый простой, учитывающий критичность длительных прерываний, которые могут вызвать значительные убытки и репутационный ущерб; 3) Количество нарушений, важное для бизнес-процессов, чувствительных к частым кратковременным простоям (например, длительные вычисления, требующие перезапуска). Также упоминается альтернативный показатель - минимальная или средняя продолжительность работы без нарушений.

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

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

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

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

Цели процесса в ITIL должны соответствовать принципу SMART: - Конкретность и измеримость: формулировка включает метрику (например, "увеличить долю своевременно решённых инцидентов до 95%"). - Привязка к срокам: цель ставится на конкретный период (месяц, квартал). - Глаголы совершенного вида (дождусь, достигну, обеспечу). Цели не фиксируются в регламенте процесса, так как они часто пересматриваются, а учитываются в планах управления или картах показателей. Ответственность за определение и актуализацию целей лежит на владельце процесса. Цели должны быть чётко связаны с бизнес-требованиями и обоснованием проекта.

Связка стандартов RBAC (INCITS 359-2012, INCITS 494-2012 и INCITS 459-2011) устанавливает общую терминологию и определяет элементы, множества, интерфейсы, команды и модели, которые можно использовать при проектировании систем управления доступом. Это обеспечивает единообразие в подходах к реализации RBAC, позволяет создавать совместимые системы и облегчает процесс анализа их функциональных возможностей. Первый стандарт определяет базовую модель, второй добавляет гибкость за счет поддержки динамических ограничений, а третий обеспечивает корректную комбинацию всех компонентов и их взаимодействие. Совместное использование этих стандартов помогает создавать эффективные решения для управления доступом, которые соответствуют современным требованиям безопасности и бизнес-процессов.

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

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