Карта зависимостей: что нужно знать до любой миграции
Миграции систем срываются не из-за технических сложностей, а из-за скрытых зависимостей. Объясняю, как составить карту зависимостей и почему это работа до начала проекта.
Я видел немало миграций, которые начинались по плану и заканчивались на несколько месяцев позже с бюджетом вдвое выше запланированного. Почти каждый раз причина была одна и та же: в процессе обнаруживались зависимости, о которых никто не знал заранее.
Это не вопрос плохого планирования в привычном смысле. Это вопрос отсутствия карты того, что есть.
Что такое карта зависимостей
Карта зависимостей - это описание того, как системы и сервисы компании связаны между собой. Какая система что потребляет, что отдаёт, с кем и как взаимодействует.
В небольшой компании это может быть таблица на несколько строк. В компании со зрелой ИТ-инфраструктурой - граф из десятков узлов с разными типами связей: синхронные вызовы API, асинхронные очереди, файловые обмены, ручные операции с данными, задачи планировщика.
Проблема в том, что эта карта почти никогда не существует в актуальном виде. Она либо не создавалась никогда, либо была создана давно и устарела.
Почему зависимости остаются невидимыми
Первая причина - системы добавлялись постепенно, и каждая интеграция казалась локальным решением. Никто не обновлял общую схему, потому что общей схемы не было.
Вторая причина - часть зависимостей неформальна. Один сервис читает файл, который другой сервис туда кладёт. Это не документировано ни в одном API-контракте, но система на это полагается.
Третья причина - люди уходят. Человек, который помнил, почему система А и система Б связаны через промежуточную таблицу в базе данных, давно не работает в компании.
Как составлять карту практически
Я не рекомендую пытаться сделать полную карту всего сразу. Это дорого и почти никогда не доводится до конца.
Полезный подход - составлять карту вокруг конкретного объекта изменений. Если планируется замена системы расчёта зарплаты, начинать нужно с вопроса: кто ещё читает данные из этой системы? Кто туда пишет? Что произойдёт с этими потребителями при смене системы?
Это даёт ограниченный, но актуальный граф зависимостей, который достаточен для планирования.
Практический метод - серия коротких интервью с владельцами смежных систем и с аналитиками данных. Аналитики обычно знают скрытые зависимости лучше всех, потому что именно они разбираются с последствиями, когда что-то ломается.
Вопросы, которые стоит задать перед стартом
Прежде чем утверждать бюджет и сроки любой миграции или замены системы:
- Составлен ли список всех потребителей данных, которые эта система производит?
- Есть ли зависимости, которые не задокументированы формально, но существуют де-факто?
- Кто в компании знает эти скрытые зависимости и доступен ли этот человек для участия в проекте?
- Есть ли план для каждой зависимости на период миграции?
- Кто проверит, что после миграции все потребители работают корректно?
Если эти вопросы не заданы до начала - они будут заданы в середине. Только цена ответа будет другой.