Старший разработчик на Go в service mesh

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

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

Ближайший аналог того, что мы делаем, — Kubernetes, но мы позволяем запускать сервисы в одной инсталляции, масштабированной на весь Яндекс. У нас развёрнуты и крупные потребители вроде Поиска или YT, и микросервисы, которые сами по себе крошечные, зато их многие десятки тысяч — например, всё Такси. Кроме запуска мы даём пользователю всё для эксплуатации: балансировку, мониторинг, сбор логов, интеграцию с CI/CD.

Относительно новое направление — единая инфраструктурная платформа (PaaS), которая прячет от разработчика лишнюю сложность и позволяет хранить настройки сервиса рядом с кодом, применяя GitOps-подходы. Важная её часть — service mesh, подсистема, управляющая взаимодействием микросервисов друг с другом. Это молодой проект в фазе активного роста: техническая основа уже есть, и сейчас главный вызов — наращивать клиентскую базу и дорастать до масштабов всей компании. Пишем на Go, активно используем компоненты Kubernetes.

Проектировать и развивать service mesh
Вы будете писать на Go компоненты, которые решают, как трафик будет ходить между микросервисами: маршрутизацию, балансировку, политики безопасности. Проект растёт быстро, поэтому решения приходится принимать с запасом: то, что нормально работает на текущей клиентской базе, должно пережить её кратный рост. Вопрос «А что будет, когда так сделают все 50 тысяч приложений облака?» мы задаём себе на каждом дизайн-ревью. Отдельная часть работы — наблюдаемость: метрики, логи, трассировки и алерты, по которым видно, что именно происходит с сетевым взаимодействием конкретного сервиса.

Интегрировать mesh с остальной платформой
Service mesh не живёт сам по себе — он должен состыковаться с оркестрацией контейнеров, CI/CD и системой логов. Вы будете проектировать API и инструменты, через которые разработчик описывает правила mesh рядом с кодом своего сервиса и катит их тем же пайплайном. Главный критерий здесь — прозрачность: в идеале пользователь платформы получает работающий mesh, ни разу не столкнувшись с его внутренним устройством.

Отвечать за надёжность и безопасность
Мы разрабатываем mTLS, авторизацию и управление политиками доступа между сервисами — то есть отвечаем на вопрос, кто к кому имеет право ходить, и обеспечиваем это на уровне инфраструктуры, а не договорённостей. Отказоустойчивость mesh-слоя — тоже наша зона ответственности: он не имеет права стать единой точкой отказа для сервисов, которые через него ходят. Чем больше команд мы подключаем, тем дороже стоит каждая ошибка. Также мы отвечаем за нагрузочное тестирование и оптимизацию работы с gRPC и HTTP/2.

Разбираться с инфраструктурными ограничениями
Когда упираешься в потолок производительности на таком масштабе, причина обычно лежит ниже уровня приложения — в сетевом стеке или в ядре Linux. Такие места нужно находить и расшивать. Ещё мы берём опенсорсные решения — например, Envoy и Istio — и адаптируем под внутренние требования Яндекса. Иногда это доработка, иногда — своя реализация: готовое решение либо не выдерживает наших объёмов, либо не умеет того, что просят команды — пользователи платформы.

Больше о бэкенде в Яндексе — в канале Yandex for Backend

• Разрабатываете на Go в продакшне не меньше трёх лет
• Проектируете технические решения и умеете аргументированно их защищать
• Уверенно владеете классическими алгоритмами и структурами данных, понимаете особенности их работы в Go
• Читаете чужой код и разбираетесь в незнакомой кодовой базе без долгого разгона
• Доводите задачу до продакшна и отвечаете за то, как она в нём работает

• Проектировали и разрабатывали распределённые высоконагруженные сервисы
• Понимаете проблематику построения облачных сервисов
• Глубоко знаете Linux
• Писали многопоточный и асинхронный код
• Занимались сетевым программированием и хорошо ориентируетесь в сетевом стеке
• Работали не только с пользовательскими возможностями Kubernetes, но и с его компонентами
• Имеете опыт с Envoy, Istio или другими service mesh

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

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

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

Подписывайтесь на телеграм-канал Yandex Infrastructure, чтобы узнать больше о том, как мы делаем внутреннюю инфраструктуру Яндекса.