Инфра-команда Yubo: дата-инженеры, DevOps, безопасность

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

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

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

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

Мы сосредоточены на двух ключевых направлениях:

Безопасность глубоко встроена в нашу философию инфраструктуры. Хотя мы cloud-first-компания, мы повсеместно внедрили строгие политики «минимального доступа» (least access). Это значит, что у каждого есть доступ только к тем ресурсам, которые ему абсолютно необходимы, — и ничего сверх того. Разумеется, наш IAM тоже автоматизирован с помощью YAML-шаблонов конфигурации.

Вот несколько ключевых моментов о наших практиках безопасности:

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

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

Ключевой элемент управления нашей инфраструктурой — дежурная ротация (on-call). Но мы реализовали её так, чтобы поощрять сотрудничество и гарантировать, что нужная экспертиза всегда под рукой.

У нас есть пул разработчиков-добровольцев, которые выступают первой линией обороны при возникновении проблемы. Они вполне способны справиться со многими типичными ситуациями, опираясь на документацию и post-mortem’ы, а с недавних пор им помогает искать в них информацию ещё и AI-бот; если же они заходят в тупик, то могут эскалировать проблему инфраструктурной команде. Такая система гарантирует, что проблемы решаются быстро и без выгорания инфраструктурной команды, и при этом воспитывает у разработчиков чувство ответственности за код, который они выкатывают.

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

Вся техническая команда работает полностью удалённо: её участники распределены по Франции, Италии и Германии, что позволяет выстраивать работу вокруг личной жизни, хобби и времени с семьёй. Но чтобы всё это работало гладко, мы во многом полагаемся на индивидуальную ответственность. Каждый участник команды сам управляет своим расписанием, поддерживает в актуальном состоянии свои доски задач и ведёт How-To-руководства и операционную документацию. Такой уровень прозрачности критически важен: он даёт менеджменту нужную видимость и при этом держит всех согласованными.

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

Так работает вся наша техническая команда, делая ставку на асинхронные процессы ради максимальной эффективности и минимума помех. Когда возникает инцидент или критичная для бизнеса проблема, мы создаём в Slack каналы-war room, чтобы быстро собрать нужных экспертов и решить всё в реальном времени. Такой подход сохраняет нашу гибкость даже при удалённой работе и гарантирует, что мы можем оперативно реагировать на любой вызов.

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

Поддерживая чёткую структуру, предугадывая будущие потребности и развивая культуру ответственности и гибкости, мы способны управлять инфраструктурой на 80 млн пользователей силами всего пяти человек — и мы всегда смотрим вперёд.

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