Привет, Хабр!

Я Никита Дубина, руководитель команды автоматизации Лаборатории ИИ Департамента больших данных РСХБ. В этой статье расскажу о том, что такое теневые ИТ, почему они возникают в крупных организациях, особенно в банках, какие риски несут и как при правильном подходе могут стать источником новых идей. Делюсь опытом борьбы с ними. 

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

 Думаю, почему существование теневых решений негативно для компании, достаточно очевидно:

• как правило, реализованы они так себе, в обход лучших практик и стандартов разработки;

• они неоптимально используют железо;

• они никак или плохо задокументированы и существует огромный риск утраты экспертизы, например, при увольнении того самого сотрудника, который их разработал;

• их сложно поддерживать и развивать;

• они не фигурируют ни в каких документах и при изменении ИТ-ландшафта миграция их функционала с вероятностью в 99% не будет учтена;

• они напрямую участвуют в боевых бизнес-процессах и несут прямой критический риск для бизнеса в части выполнения функций подразделений в случае какого-либо сбоя.

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

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

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

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

Несмотря на то что актуальный ИТ-ландшафт РСХБ состоит из современных ИТ-систем, которые функционально покрывают подавляющее большинство потребностей бизнеса, за 25 лет существования организации собралось большое количество пользовательской разработки. Да и как бы системы ни были хороши, у пользователей всегда остается потребность быстро сделать что-то самим. С этим наша ИТ-команда и столкнулась в период импортозамещения.

Практический кейс из банка по выявлению теневых ИТ

Перед нами стояла задача масштабной замены стека инструментов и программного обеспечения, на котором работают пользователи, — замещения ряда ключевых АБС, переход с операционной системы Windows со всеми ее компонентами на Astra Linux и смена офисного пакета.

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

Мы начали с опроса пользователей о том, что они используют в своей работе: направляли служебные записки и письма, проводили интервью с ключевыми сотрудниками, проводили аудиты содержимого серверов с СУБД, выписывали и агрегировали полученную информацию. И что получили в итоге?

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

Когда мы столкнулись с таким объемом теневых ИТ, первым шагом стала масштабная работа по оптимизации. Мы начали задавать бизнесу ключевые вопросы: «А точно ли это вам нужно? Действительно ли этот функционал критичен? А нельзя ли его выполнять в целевой системе?». Мы также пропускали этот функционал через себя, оптимизировали и объединяли несколько задач для решения более крупной задачи. Удивительно, что люди думают не одинаково: ряд подразделений решали одну и ту же задачу, но каждый именно своим способом. В результате этой работы удалось значительно сократить количество задач по миграции, оптимизировав их до порядка 500 сущностей.

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

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

В-третьих, мы помним, что у пользователя все-таки должна оставаться возможность что-то разработать для себя в формате решения ad hoc задач. Иначе «Бэрримор, что это за ужасный вой на болотах?»

 Мы поняли, что борьба с теневыми ИТ лежит через централизацию. Нам требовалось подобрать набор инструментов, который, с одной стороны, сохранял бы ключевой функционал по работе с данными, аналогичный тому, что предоставляли MS Office, Access или Excel. С другой стороны, этот инструмент должен был быть достаточно гибким, чтобы пользователи могли как в режиме self-service продолжать решать свои задачи, так и заказывать разработку кастомизированного функционала у IT-подразделения.

Решение: ИТ-платформа RAISA и профильные инструменты

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

Начали с простого — с различных СУБД на базе Access, SQLite, MS SQL Server, было очевидно, что нужно где-то это собирать.

 У коллег из нашего департамента по счастливому стечению обстоятельств  уже давно существует продукт, который позволяет на большом кластере Greenplum в режиме self-service развернуть себе песочницу, а Airflow есть на нашей платформе (о ней чуть позже). Супер, с хранением и батчовыми потоками разобрались.

Тут же становится понятно, что эти данные из СУБД надо как-то отображать, представлять в разных разрезах и строить графики — требуется BI-система, выбираем уже завезенную в банк Visiology.

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

 И тут возникает наша платформа RAISA. Не погружаясь в детали, это универсальная IT-платформа, связанная сетью почти с каждой АБС и СУБД компании, в основе которой лежит k8s, которая фактически может запустить любой код на Python, упакованный в контейнер. Она позволяет любому пользователю развернуть базовый образ с Jupyter-notebook и Airflow, дотащить библиотек из Nexus, коммитить в Gitlab и деплоить приложения через настроенный CI/CD. Выбор такого набора позволил нам не только централизовать код и данные, но и перевести их в контролируемую, безопасную и масштабируемую среду.

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

Сложности добавляло то, что большую часть инструментов мы должны были передать пользователям на поддержку и доработку, а значит инструменты и код должны были быть понятны и легки в освоении людьми, которые до этого буквально писали только на VBA и SQL. Поэтому набор библиотек пытались сильно не раздувать: для разработки интерфейса минималистичный Streamlit, в бэке в основном pandas, openpyxl, lxml и т. п.

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

Вообще в рамках всей этой деятельности у нас действительно неплохо получилось оптимизировать этот контур серого IT: все «серые» СУБД были собраны либо централизованно на едином кластере Greenplum, либо мигрированы на Postgres в одном контуре с платформой, практически целиком была переработана архитектура потоков данных, которые забирали данные из разных источников в локальные СУБД, оптимизированы модели данных этих СУБД. Избавились от привычки пользователей рисовать графики в табличных редакторах для предоставления управленческой отчетности: все, что могло переехать на BI, переехало на BI в красивом и, самое главное, продуктивном виде. Оцифровали и централизовали подавляющее количество пользовательской автоматизации в рамках платформы и получили мониторинг использования ресурсов, информацию о том, что пользователь выполняет и с какой частотой, ограничили несанкционированные походы в различные системы, а также сервисы вне банковского контура.

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

Так мы сформировали новую рабочую экосистему. Платформа RAISA дала возможность не только запускать готовые приложения, но и предоставила каждому пользователю персональную песочницу — контейнер с предустановленными Jupyter Notebook и AirFlow. Ключевым преимуществом платформы стала единая точка доступа к данным. Теперь пользователям больше не нужно было вручную собирать информацию с сетевых дисков и из разных систем — платформа предоставляла им безопасный и контролируемый доступ к нужным данным напрямую для работы в режиме self-service.

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

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

1. Регулярное обучение: цикл лекций по Python, возможностям RAISA и кастомным библиотекам.

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

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

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

 Итак, чего мы добились? Мы не просто спасли критический для бизнеса функционал — мы сделали его работу прозрачной и управляемой. Всё, что раньше было скрыто в тени, теперь разрабатывается «в белую» по правилам платформы. Мы видим потребности пользователей, понимаем, какие задачи они решают и какие ресурсы используют.

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