Здравствуйте, меня зовут Юрий Юшкевич, я руководитель ИТ-разработки/CTO. В этой статье я расскажу о процессе замены APM-решения в крупной финтех-компании: почему мы ушли с Instana, как выбирали альтернативу и что изменилось после внедрения Proto Observability Platform.
Дисклеймер. Статья подготовлена на основе доклада с технологической конференции IT Elements, где я выступал вместе c Русланом Галимовым, руководителем центра компетенций по оптимизации и эксплуатации цифровых решений.
Если хотите посмотреть оригинал нашего выступления — вот ссылка на видео.
А также данная статья является логическим продолжением статьи Тимура Исхакова.
Содержание:
Контекст: когда мониторинга уже недостаточно
Цель: замена без деградации
Выбор решения
Как проходило внедрение
Подводные камни
Что изменилось
Что дальше
Вывод
Контекст: когда мониторинга уже недостаточно
В финтехе стабильность — не просто вопрос комфорта, а требование бизнеса и регуляторов. SLA 99,99%, контроль со стороны ЦБ и ФСТЭК, высокая скорость изменений — все это создает постоянное напряжение в инфраструктуре.
До 2022 года мы использовали Instana — зрелое APM-решение.
Оно позволило:
сократить MTTR на 60% (с 45 до 18 минут);
работать командам в едином контексте;
получать данные о системе в режиме реального времени.
Когда санкционные риски заставили нас уйти с Instana, задача звучала так:
Не просто внедрить что-то новое, а сохранить зрелость Observability.
Цель: замена без деградации
Мы понимали: Observability - не просто проект, а часть операционной культуры. Чтобы не откатиться назад, мы зафиксировали ключевые требования.
Функциональные:
автообнаружение сервисов и эндпоинтов;
поддержка пользовательского опыта (UX monitoring);
автоматическое оповещение (алерты);
разграничение прав доступа (RBAC);
визуализация данных (дашборды, графики).
Технологические:
on-prem (автономность);
поддержка .NET Core 2.1-3.1, .NET Framework 4.0+;
поддержка Linux, Windows, Kubernetes, OpenShift;
отсутствие дополнительной нагрузки на хосты.
Выбор решения
После анализа нескольких отечественных платформ мы выбрали Proto Observability Platform - единственное решение, соответствующее всем нашим критериям.
Почему Proto:
полная поддержка .NET без сложных обходных путей;
on-prem-развертывание в нашей инфраструктуре;
отсутствие дополнительной нагрузки на хосты;
служба поддержки, реагирующая <15 минут;
интеграция с CI/CD и Kubernetes.
Как проходило внедрение
Этап 1. Пилот (3 месяца)
подключили 6 ключевых информационных систем (250 микросервисов);
настроили агенты и трейсеры.
Этап 2. Масштабирование (4 месяца)
расширили покрытие до 450 микросервисов.
Этап 3. Промышленный запуск (8 месяцев)
подключили 1000+ микросервисов;
обучили 60+ команд: Dev, Ops, SRE, Security, Support.
Подводные камни
Недостаточная информированность.
Провели несколько обучающих сессий, чтобы выровнять понимание целей Observability.Сопротивление команд.
«Зачем еще один инструмент?» - классическая реакция. Решилось через демонстрацию пользы на живых инцидентах.Legacy и контекст логов.
Добавили кастомные хедеры и тюнинг агентов под старые сервисы.
Что изменилось
Технически:
единый источник правды по инцидентам;
интеграция Observability в CI/CD и релизный цикл;
MTTR сохранен на уровне Instana.
Организационно:
Dev и Ops перестали искать виноватых - стали искать причины;
повысилось доверие между командами;
SRE стала центром экспертизы.
Культурно:
от реактивной диагностики к превентивной аналитике;
observability стала частью ИТ-архитектуры, а не отдельным продуктом.
Что дальше
Мы движемся в сторону Predictive Operations - когда инциденты прогнозируются до возникновения.
Наши приоритеты:
интеграция с SIEM и системами безопасности;
внедрение AIOps и ML-анализ аномалий;
общие SLO/SLI на уровне компании;
ChatOps-интерфейсы для мгновенной аналитики («Что с платежами?» → автоматический отчёт).
Вывод
Observability - это способ видеть систему как живой организм. Инструменты дают метрики, но зрелость создают люди.
Главное - не внедрять Observability как «еще один проект», а делать ее частью культуры.