SRE

Навыки

• CI/CD
• ClickHouse
• Дашборды и витрины
• Дисциплина
• Распределённые системы
• Docker
• Финтех и платежи

Задачи

• делать видимым то, чего сейчас не видно. Вести инциденты по данным (метрики
• низкий уровень), доводить до 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 обсудим на собеседовании — мы не молимся на конкретный тул и открыты к твоему опыту

Условия

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

Паспорт вакансии

История публикации

Откуда что взялось

Отмечено то, что вывели мы. Без пометки — значение назвал работодатель.

Почему на этом месте в выдаче

Порядок выдачи объявлен контрактом: свежесть решает между днями, полнота и зарплата — внутри дня.