Яндекс сталкивается с вызовами масштабирования IDM
Внедрение системы Identity and Access Management (IDM) в Яндексе изначально было направлено на устранение разрозненности в управлении правами доступа. До её появления отсутствовала централизованная база данных, позволяющая отслеживать, кто, к каким системам имеет доступ, кем эти права были предоставлены и по какой причине. IDM должна была стать единым источником истины для всех этих данных.
Проблемы роста и перегрузка системы
Однако, как это часто бывает с быстрорастущими инфраструктурами, IDM быстро столкнулась с собственными проблемами масштабирования. Несмотря на свою первоначальную цель по борьбе с хаосом, система сама стала его источником. Основные сложности включали:
- Превышение спроса: Очередь на интеграцию новых систем в IDM начала значительно превосходить количество уже подключённых. Это создавало эффект «бутылочного горлышка», замедляя подключение новых сервисов.
- Накопление запросов на функции: Команды разработчиков и пользователи активно подавали запросы на новые функции (фич-реквесты), которые накапливались быстрее, чем команда IDM успевала их обрабатывать. Это приводило к недовольству пользователей и замедляло развитие функционала.
Таким образом, инструмент, призванный упорядочить процессы, сам оказался под давлением растущих потребностей огромной экосистемы Яндекса, насчитывающей до 1500 различных систем, требующих тщательного управления доступом.
Знакомо до боли! Мы у себя тоже внедряли подобную систему для управления доступом к сотням внутренних сервисов. Сначала эйфория, что наконец-то всё централизовано. Но потом начались те же проблемы с масштабированием и бесконечной очередью на интеграцию новых систем. Что реально помогло – это делегирование части задач по подключению систем на команды-владельцы, правда, с жесткими шаблонами и автоматизированной проверкой. Иначе IDM-команда просто захлебывается.