Как в МТС Premium научились искать ошибки в распределенных данных с помощью собственного фреймворка

Качество данных (DQ) связано с технической зрелостью продукта, но не сводится к ней. В большой системе проблема редко ограничивается одной таблицей или ошибкой. Запись может быть технически корректной, но, например, появиться в базе дважды. Или другой пример: статус может быть допустимым для конкретной базы, но расходиться со статусом подписки в соседнем продукте. Итоговая бизнес-метрика при этом может выглядеть вполне правдоподобно, хотя ошибка уже возникла, причем давно.

Привет, жители Хабра! Я Ольга Жучкова, один из главных администраторов данных MWS. Я отвечаю за внедрение практик DG в кластере и выступаю амбассадором направления: помогаю продуктовым командам внедрять практики работы с данными и показываю, как эта работа улучшает продукт. В моем кластере работают более тысячи сотрудников. В каждом из этих продуктов, где есть БД, хранятся уникальные или критичные данные. А значит, есть свой администратор данных продукта, с которым я взаимодействую. На примере МТС Premium расскажу, как мы выстроили систему проверок качества распределенных данных — от локальных ошибок в базе до сквозных процессов и бизнес-метрик.

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

— контроль данных на уровне базы;

— анализ сквозных процессов;

— добавление бизнес-логики и итоговой отчетности. 

Такой порядок гарантирует реальное влияние на бизнес, а не просто красивые цифры в дашбордах.

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

Первый уровень: Structural Integrity (Технический фундамент — «Синтаксис»)

Цель: гарантировать физическую сохранность и корректность структуры. Сделать накопление мусора невозможным на уровне хранилища/первоисточника.

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

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

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

Однако проверки на этом этапе уже приносят большую пользу. С их помощью легко обнаружить типичные ошибки, которые могли допустить при релизе — например, ошибку неполучения данных, потерю данных и так далее. Это заметно ускоряет работу команды: поиск источника сбоя занимает в два раза меньше времени.

Второй уровень: Process & Flow Consistency (Логическая связность — «Логистика»)

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

Для пользователя подключение Premium максимально простое и интуитивное. Достаточно выбрать подписку в одном из каналов, подключить ее — и готово, можно пользоваться.

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

Один из первых кейсов оказался связан с двойными заказами на подключение Premium. Основной сложностью было определить в процессе движения заявки компонент/продукт, где запуск проверки давал бы максимальный эффект. Ход движения заявки на подписку тщательно проанализировали и расписали. Для проверки выбрали продукт, практически с последних этапов движения заявки. Нам нужно было на 100% понимать, что клиент согласен на подписку, готов ее оплатить, но при этом перехватить само списание. Саму проверку запустили 3 мая 2024 года на продукте, который отвечает за выполнение заказов на подключение, отключение и обновление различных услуг, в том числе Premium. Целью проверки было как раз выявление двойных заказов на подключение подписки. В логике этого процесса двойной заказ означал последующее двойное списание оплаты с пользователя. Для системы создание заказа с одинаковым составом и разницей во времени в несколько секунд — нормальное поведение, но выяснилось, что не для всех услуг это корректно. Чтобы выявлять такие случаи, проверка отслеживала дублирующие части jwt-токена, по которому и определяли заказы конкретного пользователя. За время работы удалось выявить 326 дублей, а анализ каждого обнаруженного случая позволил найти слабые места систем и устранить их.

Разбор показал, что один и тот же внешний симптом возникал по разным причинам и в разных компонентах. Далее — чуть подробнее о проблемах, которые собрали самое большое количество дублей. 

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

Кроме того, нам удалось исправить баги в работе платежного виджета на определенном типе витрин и доработать проверку публичного идентификатора продуктового предложения, что предотвращало создание повторных заказов по одному и тому же оферу. Исправили ошибки в приложениях:

— Мой МТС, где повторное нажатие кнопки подключения на кешированном экране могло создавать запросы на подключение Premium;

— в МТС Музыке для Android, в котором временная потеря сети могла также вызвать повторные запросы на подключение подписки.

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

Даже несколько ошибок важны

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

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

Просто закрыть инцидент недостаточно

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

Так произошло с проблемой в МТС Музыке. Сначала появились отдельные инциденты. Затем они начали повторяться. Команда Premium, поняв, что ошибка не разовая, обратилась к владельцам продукта со списком примеров и проведенным анализом. Продукт также провел анализ на своей стороне и выявил баг в работе приложения.

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

Расследование инцидента и контроль за устранением занимают много времени, поэтому на эту работу рекомендуется выделять отдельного специалиста на фултайм.

Уровень 2,5: добавление бизнес-логики

После процессных проверок переходим на следующий этап. Это условный уровень «два с хвостиком». До полноценного третьего уровня команда еще не дошла, но простой проверки движения данных между системами уже недостаточно: в процессе появляется бизнес-смысл.

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

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

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

Что происходит, когда статусы расходятся

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

В первом случае компания теряет выручку. Во втором возникает неприятный клиентский инцидент. Для таких сценариев мы начали запускать проверки синхронизации статусов подписки Premium между МТС Premium и продуктами, входящими в пакет подписки. Первым продуктом для сверки был выбран МТС Cashback, потому что списание кешбэка зависит от наличия подписки. (МТС Cashback позволяет получать бонусные рубли от экосистемных сервисов МТС и партнеров и тратить их.) Проверка заработала с 1 сентября 2025 года. За время ее работы удалось выявить и исправить четыре бага у продукта МТС Premium, которые приводили к массовым расхождениям статусов подписки.

Ошибки не исчезают линейно

После исправления первых проблем число расхождений необязательно начинает снижаться равномерно. Команда может найти причину, исправить ее и некоторое время практически не видеть проблем. Затем меняется один из связанных продуктов, появляется новый баг — и тот же показатель снова резко вырастает. Такую динамику мы увидели при проверке Premium и Cashback.

В апреле проверка фиксировала в среднем 19 расхождений в сутки, в мае — 18, в июне — 13. А в июле среднее значение внезапно подскочило до 127 расхождений в сутки, а затем в августе вновь откатилось к 13. На графике за период с 18 июня по 18 июля видны отдельные пики: 179, 195, 219 и 191 расхождение за сутки.

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

У одного симптома может быть несколько причин

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

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

Отдельно отмечу два момента, на которые стоит обратить особое внимание:

1. При внедрении проверки качества продукт разработал бота, который после выявления расхождения моментально его устранял. Поэтому все клиенты были в безопасности. Это было сделано специально, чтобы специалист по данным мог получить больше времени для расследования расхождений и выявления взаимосвязей.

2. Как я и говорила ранее, для нас на первом месте стоит клиент, поэтому в продукте ввели жесткий стандарт качества: между МТС Premium и МТС Cashback не должно быть расхождений. Это значит, что расследовать нужно даже единичное срабатывание проверки качества.

Третий уровень: Business Semantic Validity (Бизнес-смысл — «Экономика»)

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

Речь об уровне, на котором объектом контроля становятся показатели, которыми пользуется бизнес. Здесь проверяется уже не отдельная запись и не статус подписки между двумя продуктами, а корректность изменения бизнес метрики. В описании фреймворка к этому уровню мы отнесли все бизнесовые метрики, которые относятся к клиенту: показатели воронки продаж, время жизни клиента (LTV), показатель оттока (Churn Rate), стоимость привлечения (CAC), индекс удовлетворенности (NPS) и другие подобные показатели.

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

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

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

Логика фреймворка строится снизу вверх: сначала базовая корректность, затем сквозной процесс, после этого бизнес-смысл и только затем итоговые показатели.

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

Как проверки бизнес-логики помогают антифроду

Еще один сценарий применения нашего подхода связан с антифродом. В этом случае речь уже о проверке поведения пользователя. Одну из проверок запустили 1 июня 2026 года. Она выявляет потенциально мошенническую активность по превышению количества отмененных транзакций или их общей суммы.

За время работы проверка выявила 39 пользователей с превышенными лимитами по отмененным транзакциям. Для них заблокировали возможность начисления кешбэка по соответствующему партнеру, в том числе при частых отменах.

Эта цифра не отражает весь возможный объем мошеннической активности: сама проверка покрывает только часть сценариев. Команда при этом не пытается по одному показателю восстановить точную механику действий пользователя.

Почему же это три со звездочкой? А потому, что специалисты по антифроду формируют гипотезу о возможном сценарии, описывают предполагаемую последовательность действий и предлагают проверку. После запуска данные показывают, подтверждается ли эта гипотеза. То есть специалист по антифроду берет на себя огромную работу по мониторингу за данными, накладывает поведенческие паттерны, и только после этого он может сформулировать гипотезу (то есть специалист своей работой закрывает первый и второй уровни). В данном случае проверка будет простой с точки зрения реализации, однако очень сложной на подготовительном этапе.

Вместо вывода: для фреймворка нужен отдельный специалист

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

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

Качество данных — это постоянная работа, непрерывный процесс. Главный результат этой работы — не 326 обнаруженных дублей и не четыре исправленных бага синхронизации. Важнее само построение системы контроля.

Давайте еще раз опишем фреймворк:

1. На первом уровне мы проверяем корректность данных в базе.

2. На втором — их прохождение через процесс.

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

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

Фреймворк позволяет:

1. Перейти от реактивного контроля к проактивному предотвращению (Shift-Left). Классический подход — это отчеты о качестве (DQ-reports), которые приходят постфактум, когда данные уже испортили дашборды. Предложенная модель выстраивает «конвейер доверия». Ошибка синтаксиса на первом уровне физически блокирует попадание мусорных данных в процессы второго уровня, а провал процессной проверки останавливает расчет бизнес-метрики до того, как она будет показана руководству. Это переход от очистки исторических данных к недопущению аномалий в реальном времени.

2. Обеспечить семантическую прозрачность уровней (End-to-end-трассировка). Новизна в том, что уровни не просто стоят друг под другом, они связаны контекстом. Бизнес-проверка третьего уровня («вырос показатель оттока») через единую систему метаданных автоматически декомпозируется в конкретные технические инциденты на первом и втором уровнях. Система сама отвечает на вопрос: «Отток вырос, потому что сломался ETL-коннектор с платформой клиентских данных (уровень 2) или потому, что в базе заказов изменился тип данных колонки «Скидка» с Decimal на String (уровень 1)?». Так мы устраняем разрыв между техническим логом и бизнес-проблемой.

3. Реализовать эволюционную экономическую оптимизацию. Вместо дорогостоящего внедрения тотального профилирования всех данных сразу, модель предлагает поэтапное инвестирование. Сначала закрываются самые дешевые и критичные риски (например, падение БД из-за неверного типа), затем устраняются угрозы среднего уровня (целостность интеграций), и только потом внедряются дорогостоящие механизмы защиты бизнес-показателей. Это делает внедрение управления данными финансово обоснованным для бизнеса.

4. Институционализировать ответственность (Ownership Matrix). Модель меняет владельцев качества по мере движения вверх:

• На первом уровне качество гарантирует СУБД (автоматически).

• На втором уровне — технологические команды (через мониторинг пайплайнов).

• На третьем уровне владельцем становится бизнес-заказчик, который сам определяет порог срабатывания алертов (например, «тревога, если конверсия падает более чем на 5%»). Четко закрепляется ответственность за смысл данных за тем, кто этот смысл создает.

5. Динамическая адаптация сложности. Модель предполагает, что система должна уметь масштабировать глубину проверок. В периоды пиковой нагрузки (например, акционные предложения) можно временно отключать тяжелые бизнес-контроли 3-го уровня, полагаясь на жесткие гарантии 1-го и 2-го уровней, чтобы не терять производительность транзакционной системы. Традиционные монолитные DQ-системы так делать не умеют.

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

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

Эффект от внедрения оценивается по нескольким ключевым показателям:

• снижение количества ошибок и инцидентов;

• повышение скорости обработки данных;

• рост доверия к данным у пользователей;

• улучшение бизнес-метрик (например, стоимости привлечения (CAC) или индекса удовлетворенности (NPS).

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