Как перейти с зарубежного APM на российское решение: план миграции
Пошаговый план перехода с Dynatrace, New Relic или AppDynamics на российскую APM-систему без остановки мониторинга.
Переход на новую APM-систему без плана — гарантированный риск «слепой зоны» именно в момент, когда старая система уже отключена, а новая ещё не накопила данных. Даём пошаговый план миграции без остановки мониторинга критичных приложений.
Краткий вывод: ключевое правило безопасной миграции — никогда не отключать старую систему до подтверждённого параллельного покрытия новой системой минимум 2–4 недели на всех критичных сервисах.
Шаг 1. Составьте карту зависимостей
Зафиксируйте все сервисы, дашборды, алерты, интеграции с Service Desk и CMDB, которые завязаны на старую систему. Это основа для оценки объёма работы и приоритизации миграции.
Шаг 2. Выберите пилотный контур
Начните с одного некритичного сервиса или отдельного кластера. Разверните новую систему параллельно старой без изменения продакшена.
Шаг 3. Внедрите единый стандарт инструментирования
Если возможно, переходите на OpenTelemetry как универсальный стандарт передачи телеметрии — это снижает зависимость от конкретного вендора в будущем и упрощает повторную миграцию, если она понадобится.
Шаг 4. Сверьте данные двух систем
В течение пилотного периода сравнивайте метрики, алерты и трейсы старой и новой системы на совпадение. Расхождения нужно разобрать до расширения миграции на остальную инфраструктуру.
Шаг 5. Перенастройте алертинг с нуля, а не копированием
Пороги срабатывания алертов в старой системе часто были настроены методом проб и ошибок годами. При переносе на новую платформу их нужно пересматривать, а не копировать — иначе высок риск шума ложных срабатываний.
Шаг 6. Обучите дежурную команду
Проведите практическое обучение инженеров на реальных инцидентах в тестовом контуре новой системы до того, как она станет единственным источником данных.
Шаг 7. Постепенно расширяйте покрытие
После успешного пилота переносите миграцию волнами по группам сервисов, а не всю инфраструктуру одним релизом.
Шаг 8. Отключайте старую систему только после подтверждения полного покрытия
Финальное отключение — только когда новая система подтверждённо покрывает все критичные сценарии мониторинга и алертинга, включая редкие пиковые нагрузки.
Типичные ошибки миграции
- Слишком раннее отключение старой системы «для экономии»
- Перенос алертов без пересмотра пороговых значений
- Отсутствие фиксации исторических данных перед отключением старой системы
- Миграция всей инфраструктуры одним шагом без пилота
FAQ
Сколько длится типичная миграция на новую APM-систему?
Сроки индивидуальны и зависят от масштаба инфраструктуры — от нескольких недель для небольшого проекта до нескольких месяцев для крупной распределённой инфраструктуры.
Что делать, если новая система не покрывает часть старых интеграций?
Уточните у вендора роадмап разработки или рассмотрите промежуточные коннекторы; иногда быстрее донастроить интеграцию через универсальные протоколы, чем ждать нативной поддержки.
Что дальше
Изучите функциональность и интеграции доступных российских APM-систем в каталоге platforms.su перед началом миграции.