тимлид SRE дейтинг-сервиса

Twinby Inc.; United States; Remote; USD 180,000 - 240,000; Full time

Benefits offered by this job

Конкурентная оплата

Возможность формирования команды

Job summary

Twinby — один из крупнейших российских дейтинг-сервисов, ищем тимлида SRE, ответственного за платформу и надёжность для множества продуктовых команд. Ваша задача — руководить SRE и DBA, развивать инфраструктуру, обеспечивать согласованность по SLA/SLO и минимизировать инциденты, сохраняя баланс между скоростью релизов и стабильностью. Вы будете писать код и выстраивать внутренняя платформа и инструменты, которые ускорят работу других команд.

Qualifications

• Опыт руководства командой SRE/инфраструктуры, умение проводить ревью и найм.
• Умение писать код для повышения надёжности сервисов и внутренних инструментов.
• Развитая инфраструктура наблюдаемости, SLA/SLO и управление бюджетом ошибок.

Responsibilities

• Вести команду SRE и DBA: набирать, развивать, оставлять высокий уровень.
• Писать код для повышения устойчивости платформенных сервисов и инструментов.
• Развивать инфраструктуру под рост и внедрять общие библиотеки и CI/CD практики.

Skills

Лидерство команды

Опыт SRE

Разработка инструментов

Наблюдаемость

Tools

Kubernetes

Prometheus

Terraform

Job description

Описание:

Twinby — один из крупнейших российских дейтинг-сервисов с миллионами пользователей: реалтайм (лента, матчи, чаты), подписки и покупки, антифрод и модерация. Ищем тимлида SRE — руководителя группы, которая отвечает за платформу для всех продуктовых команд и за надёжность продукта. Платформа здесь работает как продукт со своим бэклогом, а её клиенты — другие инженеры. Результат группы меряется тем, насколько быстрее, надёжнее и спокойнее работают остальные команды. Тимлид ведёт команду SRE и DBA и при этом сам пишет код: платформенные инструменты и изменения в продуктовых сервисах, когда узкое место там.

Задачи:

Вести команду SRE и DBA: нанимать, растить, держать планку, давать честную обратную связь — включая тяжёлую. Писать код ради надёжности: платформенные сервисы, библиотеки, автоматика — так, чтобы класс проблем исчезал; заходить с изменениями в продуктовые сервисы, когда узкое место там. Строить «мощёные дороги» для продуктовых команд: шаблоны сервисов, общие библиотеки, CI/CD и merge-gate как внутренний продукт, контрактные тесты. Правильный путь должен быть самым лёгким. Владеть надёжностью сервисов: SLI/SLO и бюджет ошибок как рабочая политика, осознанный размен между скоростью релизов и стабильностью. Строить наблюдаемость как систему: метрики, трейсинг, структурированные логи, алерты по симптомам и дашборды, по которым инцидент разбирается по данным. Владеть инцидент-процессом и дежурствами: разбор по данным до первопричины, постмортемы без поиска виноватых, доведение действий по итогам разбора. Команды держат свои сервисы сами — по принципу «you build it — you run it». Вести каталог сервисов: у каждого сервиса есть владелец, ранбук и дашборд; правило «нет владельца — не в прод». Развивать инфраструктуру под рост — эволюционно, без переписывания всего сразу.

Требования:

Опыт в роли тимлида или ведущего инженера с командой — от полугода: под тобой люди росли, ты давал тяжёлую обратную связь и сам участвовал в найме. Ты пишешь код сейчас: инструменты, сервисы, библиотеки с логикой. Готов показать, что именно и на чём написал за последний год-два. Ты можешь защитить каждое решение, которое уходит в прод: объяснить, что оно делает, что сломается без него и что будет при десятикратной нагрузке. И того же требуешь на ревью. Твои практики переняли другие команды: дежурства, постмортемы, владение сервисами или стандарт, которым пользуются люди, которыми ты не руководил. Опыт SRE, внутренней платформы или инфраструктуры на масштабе многих сервисов: paved roads, наблюдаемость и надёжность как постоянная практика. SLO и бюджет ошибок в работе: понимаешь, когда тратить бюджет на скорость, а когда тормозить релизы, и умеешь объяснить это продукту. Влияние без формальной власти: продуктовые команды тебе не подчинены, планку ты держишь через удобство, аргумент и инструменты. Уверенный низкий уровень: Linux, сеть, диск, память — понимаешь, как и почему система деградирует. Будет плюсом: Опыт построения платформы или наблюдаемости с нуля, на которой релизят и дежурят другие команды; Опыт в high-load, у облачного провайдера или в финтехе: настоящее дежурство, жёсткие SLA, дисциплина изменений; Опыт постановки инцидент-процесса и культуры постмортемов; Контрибьют в инфраструктурный open source, доклады на профильных конференциях, публичные разборы собственных инцидентов

Условия:

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