Старший разработчик на Go в service mesh
Команда внутреннего облака Яндекса ищет Go-разработчика в service mesh. Проект молодой и быстро растёт: мы строим слой межсервисного взаимодействия и подключаем к нему команды Яндекса — а это десятки тысяч приложений в перспективе. Ждём от вас опыта промышленной разработки на Go от трёх лет.Проектировать и развивать 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
Вы будете писать на 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