DevOps-инженер (middle) (удаленная работа)

Вакансия: DevOps-инженер (middle)

Описание вакансии

О продукте

Examus система прокторинга: контроль честности экзаменов в онлайне. Нами пользуются вузы и компании, среди сценариев приемные кампании, внутренние и внешние экзамены, сертификации.

Нагрузка сезонная и пиковая: в дни экзаменов тысячи одновременных сессий с видеопотоками, а стоимость простоя измеряется сорванными экзаменами у конкретных людей. Это накладывает требования к доступности выше среднего по рынку.

Инфраструктура, с которой предстоит работать

• Облачная инфраструктура в VK Cloud, объектное хранилище в Yandex Cloud
• Backend Python/Django + DRF, Celery (worker и beat), Node.js + Socket.IO для сигналинга WebRTC
• PostgreSQL (в том числе managed), Redis
• Балансировщики нагрузки облачного провайдера, DNS, TLS, TURN/STUN (Coturn)
• Коробочные поставки продукта на инфраструктуре заказчиков: docker compose, установочные скрипты

Кластеры Kubernetes сопровождает внешний подрядчик по модели managed. Эксплуатация Kubernetes в зону ответственности этой роли не входит от вас нужно умение ставить подрядчику задачи и проверять результат, а не администрировать кластер.

Задачи

1. Мониторинг и алертинг. Довести наблюдаемость до состояния, когда деградация компонента видна до того, как о ней сообщил клиент: метрики, логи, трейсы, осмысленные алерты, дежурные сценарии реагирования.
2. Отказоустойчивость приема трафика. Убрать единые точки отказа в схеме балансировки, DNS и публикации сервиса, обеспечить предсказуемое переключение и проверяемое восстановление.
3. CI/CD. Развитие пайплайнов сборки и выката, сокращение времени и риска релиза, воспроизводимые окружения.
4. Инфраструктура как код. Перевод конфигураций в код, версионирование, отказ от ручных изменений в проде.
5. Коробочные поставки. Упаковка и сопровождение установки продукта в закрытых контурах заказчиков, поддержка внедрения.
6. Работа с инцидентами. Участие в разборе аварий, ведение постмортемов, доведение мер до внедрения, а не до протокола.
7. Взаимодействие с облачными провайдерами и подрядчиками. Постановка задач, контроль сроков и SLA, эскалация, проверка того, что заявленное подрядчиком действительно сделано.

Что мы ждем

• От 3 лет в эксплуатации production-инфраструктуры
• Уверенный Linux и сеть: TCP/IP, DNS, TLS, маршрутизация, умение локализовать проблему между приложением, облаком и сетью провайдера
• Docker, docker compose
• Опыт с системами мониторинга (Prometheus, Grafana или аналоги), настройка метрик и алертов с нуля
• CI/CD: GitLab CI, GitHub Actions или аналоги
• Инфраструктура как код: Terraform, Ansible или аналоги
• Скриптование: Bash, Python
• Опыт эксплуатации сервисов в российских облаках
• Способность самостоятельно вести задачу до результата и внятно писать: постмортемы, схемы, инструкции

Будет плюсом

• Опыт работы с внешними подрядчиками по эксплуатации: постановка задач, приемка, спор по SLA
• Базовое понимание Kubernetes на уровне пользователя: посмотреть логи, состояние подов, разобраться, где проблема, и корректно передать ее подрядчику
• Эксплуатация PostgreSQL под нагрузкой: репликация, бэкапы, проверка восстановления
• Опыт с WebRTC, TURN/STUN, видеотрафиком
• Опыт поставки продукта в закрытые контуры заказчиков (on-premise, изолированные сети)
• Понимание требований регуляторов к размещению данных, опыт прохождения проверок ИБ
• Участие в дежурствах и выстраивании процесса on-call

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

• Влияние на архитектуру эксплуатации: роль создается, чтобы выстроить процессы, а не поддерживать чужие
• Прямой контакт с руководством, короткий путь принятия решений
• Продукт с реальной нагрузкой и понятной ценой отказа виден результат работы
• Оформление по ТК + ДМС после испытательного

Вопрос для отклика

Ответьте, пожалуйста, в сопроводительном письме по ответу мы поймем, как вы думаете, и это ускорит нам разговор:

Представьте: во время экзамена часть пользователей теряет соединение, но сервис в целом зеленый все дашборды в норме. Клиент пишет раньше, чем сработал алерт. С чего вы начнете и как сделаете так, чтобы в следующий раз система увидела деградацию до звонка клиента? Ответьте в двух-трех абзацах, нам важен ход рассуждений, а не готовый рецепт.

Отбор

1. Короткий созвон-знакомство (30 минут)
2. Техническое интервью с разбором рабочих кейсов (60-90 минут)
3. Финальная встреча с руководством, обсуждение условий

Общение строго через hh.ru