7 мая 2026 г.·6 мин чтения

Change management на собеседовании системного аналитика

Проверь себя · 1/3разбор после ответа
Нужно посчитать число пользователей, которые сделали хотя бы 1 заказ (таблицы users(user_id) и orders(user_id, order_id)). Какой запрос посчитает правильно?

Содержание:

Зачем спрашивают change management

Change management (управление изменениями) — это процесс, по которому любое изменение в продакшене проходит контроль: заявку описали, оценили риск, согласовали, выкатили и зафиксировали результат. На собесе системного аналитика тему поднимают, когда речь про enterprise, банки, телеком и госсектор — там любое изменение боевой системы регламентировано, и SA участвует в подготовке заявок, оценке влияния и согласовании со стейкхолдерами.

Интервьюер проверяет не зубрёжку ITIL, а понимание, зачем вообще нужен процесс: чтобы изменения не ломали продакшен и чтобы после инцидента можно было понять, что и кто менял. Ниже — базовый минимум, который стоит держать в голове.

Типы изменений в ITIL

ITIL делит все изменения на три категории по уровню риска и скорости согласования:

  • Стандартное (Standard). Заранее одобренное, низкорисковое, повторяемое изменение — например, добавление пользователя или плановое обновление по known-процедуре. Проходит по преднастроенному сценарию, отдельного согласования не требует (auto-approve).
  • Обычное (Normal). Изменение, которое проходит полный цикл согласования: заявка, оценка риска, ревью на CAB. Сюда попадает большинство нетривиальных доработок.
  • Экстренное (Emergency). Срочный фикс боевого инцидента (hotfix). Согласование ускоренное — через emergency CAB или дежурного руководителя, — но задокументировать изменение всё равно надо, обычно постфактум.

Change request

Change request (RFC, request for change) — формальный документ, с которого начинается изменение. В нём фиксируют:

  • Что меняем — суть изменения и затронутые компоненты.
  • Зачем — бизнес- или техническая причина, ожидаемый эффект.
  • Оценка рисков — что может пойти не так и с какой вероятностью.
  • План отката (rollback) — как вернуть систему в исходное состояние, если что-то сломалось.
  • Проведённое тестирование — что и в каком контуре проверили перед выкаткой.
  • Затронутые стейкхолдеры — кого предупредить и с кем согласовать.

В строго регулируемых средах (банки, страхование, медицина) change request обязателен для каждого изменения в продакшене — без утверждённой заявки выкатка запрещена регламентом.

CAB

Change Advisory Board (CAB) — совет, который рассматривает и утверждает изменения.

  • Состав. Тимлиды, представители эксплуатации (ops), безопасности и бизнеса — те, кто может оценить изменение с разных сторон.
  • Периодичность. Обычно собирается раз в неделю и разбирает накопившиеся заявки. Для экстренных изменений созывается emergency CAB — ad-hoc, вне расписания.
  • Критика. Классический CAB часто становится бутылочным горлышком: изменение ждёт заседания несколько дней. Поэтому современный DevOps выносит стандартные низкорисковые изменения из-под ручного согласования и оставляет CAB только для по-настоящему рискованных.

Оценка рисков

Перед согласованием изменение оценивают по влиянию на систему и пользователей:

  • Затронутые сервисы — какие компоненты и интеграции задеваются.
  • Ожидаемый простой (downtime) — нужен ли технологический перерыв и насколько заметный.
  • Возможность отката — насколько быстро и надёжно можно откатиться, если что-то пойдёт не так.
  • Влияние на клиента — почувствует ли изменение конечный пользователь.

По совокупности этих факторов изменению присваивают уровень риска (risk score), а он определяет, на каком уровне нужно согласование: низкий риск — auto-approve, высокий — полный CAB.

Готовишься к собесу системного аналитика?
827 вопросов: REST, UML, OAuth, ERD, требования. Тренируйся в Telegram
Тренировать SA в Telegram

Современный подход (DevOps)

Традиционный ITIL с ручным согласованием медленный и плохо стыкуется с частыми релизами. DevOps перестраивает процесс:

  • Стандартные изменения полностью автоматизированы — выкатываются через пайплайн без ручного одобрения.
  • Преднастроенные плейбуки (playbooks) описывают типовые операции, которые не требуют отдельного согласования.
  • Непрерывное развёртывание (continuous deployment) — изменения едут в прод небольшими порциями и часто.
  • Ревью после выкатки (post-deploy review) заменяет тяжёлое согласование до неё: сначала выкатили под мониторингом, потом разобрали результат.

В регулируемых отраслях (банки, медицина) на практике работает смешанная модель: ITIL с ручным согласованием — для высокорисковых изменений, DevOps-автоматизация — для низкорисковых.

Как это спрашивают на собесе

Частые формулировки на интервью SA:

  • «Чем стандартное изменение отличается от обычного?» Ждут: стандартное преднастроено и низкорисковое, идёт без согласования; обычное проходит полный цикл через CAB.
  • «Что обязательно должно быть в change request?» Ждут: суть изменения, причина, оценка риска и — ключевое — план отката.
  • «CAB тормозит релизы, что предложишь?» Ждут: вынести стандартные низкорисковые изменения на auto-approve, оставить CAB только для рискованных, добавить post-deploy review.
  • «Как согласовать экстренный фикс продакшена ночью?» Ждут: emergency-процесс с ускоренным согласованием и обязательным документированием изменения постфактум.

Частые ошибки

  • Забыть про план отката. Change request без rollback-плана — красный флаг: интервьюер сразу спросит, как откатываться.
  • Путать change с release и incident. Change — управляемое изменение, release — выкатка версии, incident — реакция на сбой. Это разные процессы ITIL.
  • Считать CAB бюрократией без смысла. Совет нужен, чтобы разные стороны (безопасность, ops, бизнес) увидели риск, который автор заявки не заметил.
  • Игнорировать документирование emergency-изменений. Срочность не отменяет фиксацию: без записи после инцидента непонятно, что меняли.
  • Абсолютизировать один подход. «Только ITIL» или «только DevOps» — плохой ответ; в регулируемой среде работает смешанная модель по уровню риска.

Связанные темы

FAQ

Чем change management отличается от release management?

Change management отвечает за то, чтобы изменение согласовали, оценили риск и безопасно внедрили. Release management — за упаковку и выкатку набора изменений как версии (сборка, тестовые контуры, деплой). Одно изменение может быть частью большого релиза; процессы связаны, но решают разные задачи.

Кто входит в CAB и как часто он собирается?

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

Обязателен ли change request для каждого изменения?

В строго регулируемых средах (банки, страхование, медицина) — да, любое изменение продакшена требует утверждённой заявки. В продуктовых командах на DevOps стандартные низкорисковые изменения идут через автоматический пайплайн без отдельной заявки, а формальный change request остаётся только для рискованных.

Как DevOps меняет классический ITIL-процесс?

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

Это официальная информация?

Нет. Статья основана на фреймворке ITIL и практиках DevOps. Конкретный процесс управления изменениями зависит от компании, отрасли и уровня регуляторных требований.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.

Ещё по теме