Всем привет. Меня зовут Дима, в Т-Банке я руковожу Центром надежности информационных систем. Мы проводим консультирование, обучаем и внедряем SRE-практики, нанимаем и аттестуем инженеров. В общем, делаем все, чтобы помочь командам Т-Банка — а их уже более 2500 — разрабатывать надежные сервисы для всех категорий пользователей и при этом крепко спать по ночам.

Мониторинг ИТ-систем — важнейшая составляющая надежности. Расскажу о том, какие подходы мы использовали, как и почему пришли к нынешнему состоянию и как планируем развиваться дальше.

A long time ago или начальное состояние мониторинга

Т-Банк давно развивал концепцию бизнес-мониторинга. Топ-менеджмент понимал, что первая важная задача не столько то, работает какое-то программное обеспечение или нет, а работают ли бизнес-процессы и насколько качественно. Успеваем ли мы вовремя обрабатывать кредитные заявки, сколько платежных транзакций проходит и сколько мы можем потерять, если какие-то из них зависли или были потеряны. При этом важно быстро реагировать на проблемы.

Второй важной задачей было обеспечение качественного клиентского опыта. У нас много партнерских сервисов, и не всегда проблемы происходят по нашей вине. Но клиент всегда наш, и мы должны ему помочь, причем даже до того, как он узнал о проблеме.

Например, мы предлагаем лайфстайл-сервисы, один из них — возможность купить билет на самолет. В этом процессе задействовано множество систем и может произойти ошибка при бронировании, когда пользователь получает список рейсов, успешно выбирает и оплачивает. Но вдруг авиакомпания сообщает о некорректном заказе, потому что на финальном этапе что-то пошло не так. Подобные сбои доставляют огромные неудобства нашим клиентам. Нам важно автоматически выявлять сбои, чтобы проактивно помогать клиенту. Мы можем позвонить, извиниться, вернуть деньги или предложить другой вариант. Главное — действовать до того, как клиент понял, что произошло что-то малоприятное.

Уже тогда существовало четкое деление на бизнес-мониторинг и технический. Команда бизнес-мониторинга строила свои процессы на базе американского решения — Splunk, мощной и гибкой системы аналитики машинных данных. 

Существовала специальная команда, которая работала с этим продуктом, настраивала дашборды и алерты. Также была команда поддержки, мы называли ее «первой линией».

В Splunk стекались журналы событий, имевшие отношения к бизнес-транзакциям, а в первую линию — уведомления о проблемах, ошибках и так далее. Сотрудники первой линии реагировали на проблемы — могли позвонить инженерам, чтобы те проверили систему, или передать информацию в контактный центр, инициировать этапы помощи клиентам.

При этом команды каждого сервиса самостоятельно обеспечивали технический мониторинг, то есть метрики загрузки серверов от свободного места до CPU, логи приложений… В общем, каждая команда была на самообеспечении. Кто как умел, кто что придумал — тот так и делал. Глобально был полный зоопарк решений. В контуре компании были Zabbix-ы, Nagios-ы, Prometeus-ы, Graylog-и, Elastic-и. И каждого по десятку инсталляций.

Такая схема работала довольно долго, успешно, но у нее был ряд недостатков. Основной — нарушение обратной связи и конфликты: команды инженеров, бизнес-мониторинга и первой линии постоянно ругались. Технари говорили, что им зря просто так звонит первая линия. Первая линия говорила, что они получают тысячи алертов, которые неправильно настроила команда мониторинга. Инженеры при этом показывали, сколько они отловили и исправили проблем и при этом первая линия их совсем не беспокоила. И так по кругу, но хуже всего было, когда все мониторинги радостно светились зеленым, а клиенты при этом разрывали колл-центр.

Несмотря на конфликты мы вылавливали много сбоев. Поэтому схема существовала и считалась успешной. Наверное, существовала бы и до сих пор в том или ином виде, но…

В 2019 году Splunk ушел из России

Когда Splunk ушел, это была проблема. Его нужно было чем-то заменить, чтобы обеспечить те самые механики, на которых строились и отслеживались процессы эффективности и лояльности. Ничего похожего на рынке не было.

Мы рассматривали два варианта:

Первый — построить модный в те времена «зонтик». Фактически задача сводилась к тому, чтобы облегчить командам построение собственного мониторинга, ввести некоторую унификацию и при этом собирать какие-то метрики со множества систем в зонтичную. Решение непростое, но более или менее понятное в реализации.

Второй вариант — написать собственный полноценный аналог Splunk. Неопределенная и сложная задача, особенно учитывая, что он существовал на рынке порядка 15 лет, а у нас не было ни команды, ни понимания, как подступиться к задаче. Только идея.

Почему мы не могли использовать какой-то open source, даже схожий? На тот момент часть программного обеспечения, что использовалось у нас, было вендорским, то есть приобретенным у внешних поставщиков, часть — разработано самостоятельно с использованием различных технологий. В разных системах проходили кусочки тех или иных процессов, при этом не существовало никаких сквозных идентификаторов, чтобы просто поискать по нему. Невозможно было собрать все логи со всех систем и понять, успешно прошел запрос или нет. 

Нам было очень важно иметь возможность джойнить данные из разных систем. Также важно было иметь возможность полнотекстового поиска, так как многие системы писали свои логи в слабо структурированном формате. Splunk же обладал довольно гибким языком запросов, который позволял эти задачи решить, реализовать сложную обработку данных, наблюдать и понимать происходящее.

В случае со строительством зонтичной системы мониторинга мы бы как минимум потеряли все предыдущие наработки в отлавливании проблем пользователя. При этом зоопарк систем, скорее всего, продолжил бы развиваться. В любом случае останутся слепые зоны, по мере внедрения новых функций работать со сбоями будет все сложнее. Останутся команды, вечно рычащие друг на друга и war room — аварийные созвоны, где каждый, сколько-нибудь имеющий отношение, будет генерировать идею, что же случилось и как это исправить.

У нас было чуть менее двух лет до окончания лицензии Splunk. Мы понимали, что если будем делать свое решение, то сможем реализовать что угодно. Так появился Sage.

Платформа наблюдаемости

Первый прототип мы собрали примерно за шесть месяцев. Он как-то работал, и первые пилотные команды смогли туда заехать. Интересно, что, когда мы начинали разработку, естественно, делали ее для замещения Splunk и в расчете на бизнес-мониторинг. Но первыми пользователями, адоптерами и фактически фанатами Sage стали технари, которые не хотели разворачивать собственную систему для логирования. 

Кроме логов технарям нужно было строить и мониторинг на метриках — временные ряды числовых показателей, характеризующие какой-то процесс. Поэтому мы занесли в продукт и их. Метрики удобны для детектирования, они требуют гораздо меньше ресурсов, правда, не имеют такой детализации, как логи. Но мы объединили логи и метрики в одной системе и разработали язык запросов, который может объединять и информацию из логов, и данные метрик в одних запросах. А сейчас уже реализовали и трассировки.

Кстати, язык запросов мы сначала хотели скопировать со Splunk, но в процессе реализации поняли, насколько он неудачный. И сделали очень похожий, но все же свой.

Sage рос, по мере развития в него заезжало все больше и больше команд. Через полтора года от начала разработки переезд стал массовым, и это была та еще задачка. Команды хотели лить в систему десятки терабайт данных в сутки — пришлось сильно потрудиться, чтобы сделать ее стабильной на таких объемах:

В итоге мы перевыполнили задачу. По сравнению со Splunk мы выросли в десятки раз. Ранее о таком и мечтать не могли. На начало лета 2024 года средний поток новых данных в Sage составляет 320 терабайт в сутки, а общий объем оперативного хранилища превышает 13 петабайт! Все данные доступны для поиска, для джойнов. Понятно, конечно, что, если искать сразу по всем данным, это будет очень долго и, скорее всего, операция будет прервана по таймауту. Но если локализовать область поиска, то все данные доступны из одного интерфейса, в одном месте.

В итоге мы объединили и технический, и бизнес-мониторинг, и аналитику данных. Вот что получилось:

Наше желание писать, анализировать данные превосходит наши возможности. В общем, все, что помещается, мы пишем туда: от данных о виртуальных машинах, загрузке CPU до того, что произошла бизнес-транзакция, перевод денег, кто-то залогинился в мобильное приложение. Вся эта информация стекается в Sage и доступна там для анализа с небольшой задержкой.

На старте мы бились за скорость в несколько минут. Сейчас в кейсах проактивной помощи проходит в среднем 46 секунд с момента, когда клиент сталкивается с проблемой, до того момента, как получает сообщение или звонок от нас.

Sage превратился в единый источник информации в компании. Мы видим ситуацию с минимальными задержками, можно анализировать, строить графики. Решение стало очень востребованным, к нему стали обращаться буквально все. У нас более 12 000 уникальных пользователей в месяц. Это представители всех профессий: аналитики, руководители, разработчики, инженеры, надежность, поддержка. 

Когда клиент звонит в колл-центр, специалисты могут посмотреть его последние действия и помочь с любым запросом, когда что-то не получается. Система стала вездесущей, вот что можно назвать наблюдаемостью: можно наблюдать все, что происходит.

Есть определенные сложности с тем, что данных слишком много и в них порой трудно что-то найти. Но мы все равно получили большую синергию и пользу и продолжаем развивать систему. О сбоях мы узнаем гораздо быстрее, все мониторится в одном месте.

Например, мы можем посмотреть, что у нас происходит с наймом и какую оценку поставили по интервью.

В такую систему пришлось встроить кучу защит и разграничение доступа. Не все данные доступны всем, они разграничены. Система в принципе мультитенантна, то есть мы можем выделять изолированные пространства для тех или иных групп пользователей или систем. Права доступа могут настраиваться на уровне тенанта. Есть и ролевая модель доступа к данным внутри группы. 

Так как Sage работает на всю группу компаний, есть очень много защит, чтобы одни системы своим потоком данных не положили кластер и не помешали работе других. Есть система квотирования — какой максимальный поток логов разрешено писать и как долго хранить те или иные данные. Система должна быть защищена от любого нехорошего использования.

Немного о будущем

Сейчас весь мир говорит об искусственном интеллекте, и мы, обладая большим объемом данных, тоже развиваем эту историю. Хочется автоматизированно искать и получать из данных инсайты, предсказывать сбои или показывать, что что-то прямо сейчас идет не так. 

У нас развивается проект Anomaly Analyzer — то есть анализатор аномалий. Он анализирует данные временных рядов, статистику, рассчитывает доверительные интервалы автоматически с учетом сезонности и может алертировать при обнаружении ненормальностей.

Вот так это выглядит:

Сейчас проект развивается в сторону автоматического поиска корреляций. Цель не просто выявить аномалию в процессе, а сказать, что аномалия тут связана с аномалиями там и там. Это очень помогает поиску первопричин и анализу инцидентов. Понимать первопричины очень важно, так как задача SRE — не просто устранить сбой и его последствия. Задача — найти причину и сделать так, чтобы этот сбой более никогда не повторился.

Поскольку я занимаюсь тем, что связано с надежностью, делюсь видеокурсом с лекциями. Основа — университетский курс, который я читаю в НИУ ВШЭ.

А еще мы обсуждаем вопросы, связанные с практиками, в открытом телеграм-канале SRE_pub. Там можно задать вопросы, я там постоянно сижу, много активных участников. Присоединяйтесь!