SRE / Site Reliability Engineer

Компания "Twinby"

О роли

Twinby — один из крупнейших российских дейтинг-сервисов с миллионами пользователей: реалтайм (лента, матчи, чаты), деньги (подписки, покупки), антифрод и модерация. Мы перестраиваем инженерную систему Twinby CIS и собираем команды практически с нуля. Ищем SRE в силос Platform / Infra — общий сервис, на котором стоят все продуктовые команды.

Это инженерная роль, а не эксплуатационная. Мы ищем человека, для которого надёжность — задача разработки, а не дежурства: ты не «обслуживаешь прод», ты меняешь систему так, чтобы класс проблем перестал возникать. Пишешь код платформы и заходишь в продуктовые сервисы, если ломается там. Это IC-роль без подчинённых, но с реальным мандатом менять то, как всё устроено.

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

Чем предстоит заниматься

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

• Держать надёжность платформы и продуктовых сервисов: SLI/SLO и бюджет ошибок (старт — 99.9%), осознанный размен между скоростью релизов и стабильностью.

• Строить observability как систему — метрики, трейсинг, структурированные логи, осмысленные алерты и дашборды, а не «график ради графика»; делать видимым то, чего сейчас не видно.

• Вести инциденты по данным (метрики → трейсы → логи → низкий уровень), доводить до root cause и blameless-постмортема, чинить причину навсегда — без культа героев.

• Проектировать деградацию и устойчивость: таймауты, retry с backoff, circuit breaker, backpressure, graceful degradation, изоляция blast radius.

• Развивать CI/CD и merge-gate: воспроизводимые пайплайны, зелёные тесты и проверка контрактов как условие слияния, независимый деплой команд без ручных кликов.

• Capacity planning и готовность к пикам: видеть узкое место заранее, готовить продукт к вечерним и выходным всплескам — а не тушить по факту.

• Поднимать инженерную планку вокруг себя: доводить постмортемы, владельцев сервисов и дежурства до нормы в командах — влиянием и удобными инструментами, а не приказом.

Что мы ждём

• Ты пишешь код. Не только конфиги и пайплайны — сервисы, библиотеки, инструменты. И готов зайти в продуктовый код чужой команды, когда надёжность ломается там.

• Ты можешь защитить каждое решение, которое катишь в прод: объяснить, что именно оно делает, что сломается без него и что будет при десятикратной нагрузке.

• Реальный опыт ответственности за надёжность сервиса или платформы под нагрузкой: нёс on-call, тушил инциденты на проде с живыми пользователями, писал постмортемы.

• SLO/SLI/бюджет ошибок как рабочий инструмент, а не лозунг: понимаешь, когда тратить бюджет на скорость, а когда тормозить релизы.

• Observability для тебя — инструмент номер один: знаешь, что и зачем измерять и чего из метрик, трейсов и логов НЕ видно.

• Уверенный низкий уровень: Linux, сеть, диск, память — понимаешь, как и почему система деградирует.

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

Будет плюсом

• Опыт построения observability или платформы с нуля — такой, на которой релизят и дежурят соседние команды.

• Зрелая культура надёжности из high-load, облачного провайдера или финтеха: настоящее дежурство, жёсткие SLA, дисциплина изменений.

• Контрибьют в инфраструктурный open source, доклады на профильных конференциях, публичные разборы собственных инцидентов.

• Бэкграунд разработчика, из которого ты осознанно ушёл в надёжность.

Чего НЕ требуем

Зубрёжки синтаксиса манифестов и флагов CLI, сертификатов ради сертификатов, знания именно нашего облака и набора инструментов. Пользоваться ИИ-помощниками — нормально и полезно; нам важно только, что ты понимаешь и можешь объяснить то, что уходит в прод.

Технический стек

Go и Python на бэкенде, Docker, GitLab CI/CD, PostgreSQL, ClickHouse. Инфраструктура — российское облако (Yandex Cloud), в том числе managed-сервисы. Реалтайм-нагрузка с пиковыми всплесками. Конкретные инструменты оркестрации контейнеров, observability и IaC обсудим на собеседовании — мы не молимся на конкретный тул и открыты к твоему опыту.

Что предлагаем

• Реальный масштаб и реалтайм — миллионы пользователей, лента, матчи, чаты, пиковые нагрузки, где инцидент стоит дорого.

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

• Ты задаёшь планку с нуля: наблюдаемость, дежурства, постмортемы, владельцы сервисов ещё не застыли — то, что ты выстроишь, станет тем, как тут работают все.

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

• Высокая автономия и прямой контакт с инженерным руководством.

• Формат: удалёнка, РФ.

Открыть контакты работодателя

Зарегистрируйтесь или войдите, чтобы открыть контакты работодателя