Привет, меня зовут Катя Моисеева, я руководитель направления качества данных в Data Office Tele2. Мы не раз рассказывали, как с нуля строили процессы качества данных у себя в компании на различных площадках.

Сейчас для нас остро встал вопрос о ресурсах нашей команды, а точнее их «резиновости»: поток входящих инцидентов растет по мере подключения новых систем к проверкам качества, а команда так и остается в составе 3 сотрудников. Возникает вопрос — а какая она, идеальная команда качества данных, которая сможет создать процессы с нуля, внедрить и привить культуру внутренним заказчикам, свести к минимуму риски возникновения инцидентов, а еще минимизировать затраты компании?

В этой статье поделились своим опытом борьбы с хаосом из потока входящих задач и запросов от бизнеса и рассказали о маленьком роботе‑спасителе, который экономит нам ежедневно 5 часов сотрудника DQ и внедрить которого по силам каждому.

От количества людей в команде зависит количество и качество задач, которые они выполняют. Но в компаниях существуют разные подходы к распределению ответственности за качество данных. В одних компаниях ответственность за обнаружение и исправление ошибок DQ несет CTO или CDO, в других она ложится на бизнес‑подразделения, а бывает так, что ответственность делится (читай: теряется) между командами.

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

Один день из жизни DQ-шника Tele2 (Последний герой, режиссерская версия)

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

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

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

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

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

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

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

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

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

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

Как‑то так проходит наш обычный день.

Операционный хаос

Короче говоря, от количества задач голова идет кругом, внимание теряется, сроки отработки инцидентов качества и time‑to‑market падают. Для нас было очевидно, что если мы хотим продолжать развивать наши процессы, повышать уровень взаимодействия с бизнесом, то нам придется что‑то делать с хаосом из операционки.

Америку не откроем, если скажем, что начали с приоритизации и декомпозиции задач.

Например, сбор требований, реализация проверок, подключение новых систем — наши первоочередные обязанности приоритета -0. Но разбор мониторинга, заведение и систематизация входящих инцидентов и даже общение с пользователями такая же часть рабочего процесса. Хотя и кажется, что взаимодействие с пользователями, информирование о статусе инцидентов должно идти параллельно работе и не забирать много ресурса, это далеко не так. Мы информируем наших пользователей о заведенных инцидентах качества в Telegram‑канале, а в отдельном закрытом чате обсуждаем с ними причины, консультируем по вопросам качества и ведем образовательные активности. И все это отнимает больше времени, чем может показаться, даже при условии, что коммуникациями и развитием обучения у нас занимается отдельный человек внутри Data Office.

После анализа всех наших задач, мы определили для себя 6 основных направлений своей работы:

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

2. Работа с инцидентами качества данных
   
   Ежедневная рутина мониторинга ошибок, последующего заведения инцидентов и их анализ (ведь мы стремимся улучшать свои практики, узнавать чуть больше о бизнесе, с которым мы работаем). Часто в процессе работы с инцидентами мы принимаем решения о создании новой проверки или отключению уже неактуальной.

3. Контроль и отчетность
   
   Как и любая другая команда в любом другом бизнесе мы работаем и развиваемся не только потому что нам просто этого хочется, а потому что бизнесу требуется поддержка в развитии и масштабировании. Мы должны понимать, справляемся ли мы со своей работой, где наши точки роста, какие боли необходимо полечить. В общем, это наши показатели эффективности: мы работаем по KPI решения инцидентов (целевой показатель для нас – 24 рабочих часа), следим за time-to-market (он составляет 5 рабочих дней). Еще мы готовим отчетность о своей работе и регулярно презентуем результаты коллегам на статусах по качеству данных.

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

5. Информирование и data-просвещение пользователей
   
   Кажется, что это самое минорное из всего перечисленного, но если не заниматься развитием культуры data‑driven, не уделять внимание фидбеку от пользователей, не объяснять и не помогать им, то выхлоп от любой деятельности будет слабым. Как мы и сказали ранее, в команде нашего офиса есть отдельный человек, под чутким руководством которого происходят все коммуникации с пользователями (не только по вопросам качества данных), подготовка докладов, статей, обучающих курсов. Но без нашего участия и включения все эти активности просто‑напросто невозможны.

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

Единственный вариант — автоматизировать все и везде, куда только дотянутся наши руки.

Инцидент менеджмент

Это было первое направление нашей автоматизации. Раньше поток входящих инцидентов формировался в соотношении 40 к 60, где 40% поступают от бизнеса, а 60% заводятся в результате отработки системы мониторинга.

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

Что сделано? Все инциденты, которые выявляла система по контролю качества данных, теперь автоматически заводились маленьким роботом — скриптом, подключенным от нашей системы управления качеством данных к нашей корп.системе контроля (BPM).

Не уходя далеко, сразу заглянем под капот нашего робота.

Скрипт реализован на языке Python с использованием таких библиотек, как requests и zeep для работы с API системы BPM, а также библиотека psycopg2 для получения данных об ошибках из базы данных системы управления качеством данных — PostgreSQL. Запускается через Airflow по расписанию ежедневно каждые 10 минут с 7 утра и до 5 вечера.

Алгоритм довольно прост: скрипт обращается SQL‑запросом к таблице с результатами проверок. Если на момент запуска записей в таблице нет, то скрипт завершается. Если записи есть, то происходит формирование инцидентов с помощью метода API BPM create_request, который принимает на вход следующие параметры:

1. ID системы для заявки (в нашем случае это наименование базы данных, где возникла ошибка);

2. ID услуги для заявки (общая услуга, связанная с проблемами с качеством данных);

3. Доп. поля (для разных систем набор полей отличается, обычно туда входит наименование объекта, где возникла ошибка);

4. Описание инцидента;

5. Учетная запись, от имени которой создается инцидент;

6. Тип инцидента (запрос, ошибка, наряд на работу и т. д., в нашем случае это почти всегда ошибки).

При формировании инцидента запись о его успешном формировании добавляется в историческую таблицу, которая является join'ом в скрипте при обращении к основной таблице с ошибками (необходимо для исключения повторного заведения инцидентов по одним и тем же ошибкам).

Так что больше мы не разбираем инциденты вручную по 2–3 часа в день, а просто следим за выполнением процесса, что занимает 20 минут. Ну и, конечно, следим за новыми проверками, по которым процесс может работать с первого раза неидеально. Пропало дублирование инцидентов, потому что наш робот заводит инцидент сразу, как только ошибка появилась. Большинство пользователей в это время еще спят. Пропустить инцидент скрипт тоже не даст, роботы не устают и не отвлекаются.

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

Экономия по времени сотрудника DQ: 2 часа — 2 часа 30 минут.

Информирование пользователей

Да, не все новости или материалы data‑driven культуры можно автоматизировать. Но ту часть, которая отвечает за так называемые «отбивки» по статусу, вполне реально и даже полезно. Тут родился наш второй робот.

Что сделано? Как только инцидент появляется в системе инцидент‑менеджмента, наш робот забирает заранее параметры инцидента, которые мы ему задали, формирует новость по тематическим блокам и публикует в закрытом Telegram‑канале, закрепляя всю эту красоту ссылкой на обращение в системе.

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

Алгоритм следующий: отбираются заявки по всем системам с начала суток, проверяется, есть ли уже запись в БД по отобранным заявкам. Если записи нет, то для каждого ID инцидента делается запись в историческую таблицу, а в Telegram‑канал отправляется сообщение API Telegram с помощью бота. Используется функция post из библиотеки requests и метод /sendMessage.

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

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

Получаем экономию времени сотрудника DQ: 1 час 40 минут

(мы еще только на втором пункте, а уже высвободили сотруднику DQ примерно половину рабочего дня)

Автоматическое закрытие инцидентов

Именно так, вам не показалось.

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

Так на свет появился наш третий робот. В течение дня с определенным интервалом пробегает процесс проверки по наполнению данными и, если случается событие по пересчету данных и ошибка больше себя не проявляет, инцидент закрывается со статусом «решено (автоматически)».

Здесь оцифровать затраченное время сложнее, все зависит от множества факторов. Мы взяли среднее арифметическое количество таких инцидентов за 3 месяца и перемножили на среднее время, которое сотрудник направления качества тратит на закрытие заявки (поиск проблемы, ее устранение).

Получаем экономию времени сотрудника DQ: 30 минут — 1 час

Создание контролей качества данных

Задача под звездочкой, ведь создание контролей — вопрос индивидуальный и высоко интеллектуальный, даже творческий в какой‑то степени. Он предполагает переговоры с бизнес‑подразделениями, подключение новых систем и многое другое. А еще личное включение менеджера качества данных, навыки питчинга и обоснования предложений.

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

Как часто при создании новой системы, витрины или продукта мы слышали «Какие проверки качества? У нас новый продукт, мы сразу сделаем качественно, там нечего проверять»? А при выносе на продуктив выяснялось, что в каком‑то из полей совершенно случайно отсутствуют данные. Полтергейст какой‑то, не находите?

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

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

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

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

Отчетность и контроль эффективности

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

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

Здесь примерная экономия времени для нас более осязаема — раньше при подготовке к статусу команды сотрудник тратил около 30 минут, чтобы свести свои недельные результаты. Теперь же он не тратит их вообще.

Экономия времени сотрудника DQ: 30 минут

Ну и все это было чтобы что?

Путем нехитрых подсчетов перечисленных выше часов и минут мы получаем чистое высвобожденное время от 4 часа 40 минут до 5 часов 40 минут сотрудника команды качества данных в день. Неплохо, правда?

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

Итак, свободные 5–6 часов мы теперь тратим следующим образом:

Во‑первых, мы почувствовали себя увереннее и начали концентрироваться на развитии — говоря современным языком, роботы открыли нам портал в (ад) стратегическое планирование.

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

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

Что ждет нас дальше

Нам не пришлось нанимать еще 5 человек, чтобы выполнить работу, которую мы сейчас выполняем прежними силами (+ наши роботы). Освободившееся время мы направим на новые амбициозные проекты. Как большой телеком‑оператор мы постоянно обмениваемся данными с другими компаниями. И чтобы обеспечить передачу качественных данных, мы планируем разработать DQ Firewall, чтобы данные с ошибками не смогли проникнуть к нашим партнерам и надзорным органам.

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

У нас впереди еще много опытов и исследований, так что держим темп и двигаемся дальше.

Расскажите, у вас был опыт автоматизации в направлении DQ? С какими нестандартными кейсами сталкивались вы?