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

Чтобы минимизировать сопротивление, важно объяснить сотрудникам, что цель учёта — улучшение процессов, а не контроль производительности. Например, показать, как анализ поможет снизить их нагрузку за счёт оптимизации задач. Нужно избегать жёстких нормативов (вроде 'минимум 15 минут'), обучить простым методам фиксации и учесть обратную связь. Ключ — превратить учёт из формальности в инструмент, который экономит время и упрощает работу.

Поток создания ценности (value stream) - это последовательность этапов, которая описывает решение задачи от начала до конца (сквозной процесс). Это конструкция, которая объединяет различные части организации во благо продукта(ов). В этом потоке ресурсы организации (включая людей) могут вовлекаться в выполнение работ на различных этапах. Отношение между организационными подразделениями и этапами потока является отношением многие-ко-многим: одно подразделение может участвовать в нескольких этапах потока, и для выполнения одного этапа может потребоваться несколько подразделений. Для структурирования анализа этих связей могут использоваться дополнительные слои сущностей, такие как практики в ITIL4 или 'способности' в TOGAF.

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

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

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

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

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

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

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