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

При переходе на продуктовый подход в организации появляются продуктовые роли: менеджеры, владельцы продуктов (product owners). Меняется структура отчётности и, возможно, подчинённости. Может быть проведена реорганизация структуры - например, создание продуктовых департаментов, где объединяются различные подразделения, работа которых ориентирована на конкретный продукт. В организации изменяется фокус управления: вместо оценки прибыльности отдельных проектов начинает учитываться жизненный цикл продукта и его общая прибыльность. Могут также появиться новые организационные механизмы, отвечающие за развитие продуктов.

Принцип 'Ответственность от начала до конца' (End-To-End Responsibility) означает, что команды DevOps отвечают за полный жизненный цикл продукта — от самой первой концепции и разработки до внедрения и, в конечном итоге, вывода из эксплуатации. Это подразумевает, что одна команда сопровождает продукт на протяжении всего его существования, что способствует лучшему пониманию требований, повышению качества и более быстрой реакции на возникающие проблемы. Ответственность за полный цикл также устраняет разрывы между этапами разработки и эксплуатации, которые часто возникают при классическом разделении обязанностей между разными отделами.

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

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

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

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

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

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

В части 2 стандарта ISO 20000 на странице 20 содержится рекомендация: «Целевые показатели разрешения должны быть основаны на приоритете». Эта формулировка указывает, что сроки устранения проблем или инцидентов следует устанавливать с учетом их приоритета. При этом важно отметить, что это именно рекомендация, а не обязательное требование, так как находится во второй части стандарта.