Как мы внедрили Observability в крупной финтех-компании и сохранили цифровую зрелость
Привет, меня зовут Юрий Юшкевич, я руководитель ИТ-разработки/CTO. В этой статье я поделюсь своим опытом перевода компании с Instana на Proto.
Контекст: когда мониторинга уже недостаточно...
В финтехе стабильность - требование бизнеса и регуляторов. 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 как «еще один проект», а делать ее частью культуры.
Подписывайтесь на Telegram