О продукте
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 в зону ответственности этой роли не входит — от вас нужно умение ставить подрядчику задачи и проверять результат, а не администрировать кластер.
Задачи
- Мониторинг и алертинг. Довести наблюдаемость до состояния, когда деградация компонента видна до того, как о ней сообщил клиент: метрики, логи, трейсы, осмысленные алерты, дежурные сценарии реагирования.
- Отказоустойчивость приема трафика. Убрать единые точки отказа в схеме балансировки, DNS и публикации сервиса, обеспечить предсказуемое переключение и проверяемое восстановление.
- CI/CD. Развитие пайплайнов сборки и выката, сокращение времени и риска релиза, воспроизводимые окружения.
- Инфраструктура как код. Перевод конфигураций в код, версионирование, отказ от ручных изменений в проде.
- Коробочные поставки. Упаковка и сопровождение установки продукта в закрытых контурах заказчиков, поддержка внедрения.
- Работа с инцидентами. Участие в разборе аварий, ведение постмортемов, доведение мер до внедрения, а не до протокола.
- Взаимодействие с облачными провайдерами и подрядчиками. Постановка задач, контроль сроков и 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
Что предлагаем
- Влияние на архитектуру эксплуатации: роль создается, чтобы выстроить процессы, а не поддерживать чужие
- Прямой контакт с руководством, короткий путь принятия решений
- Продукт с реальной нагрузкой и понятной ценой отказа — виден результат работы
- Оформление по ТК + ДМС после испытательного
Вопрос для отклика
Ответьте, пожалуйста, в сопроводительном письме — по ответу мы поймем, как вы думаете, и это ускорит нам разговор:
Представьте: во время экзамена часть пользователей теряет соединение, но сервис в целом «зеленый» — все дашборды в норме. Клиент пишет раньше, чем сработал алерт. С чего вы начнете и как сделаете так, чтобы в следующий раз система увидела деградацию до звонка клиента? Ответьте в двух-трех абзацах, нам важен ход рассуждений, а не готовый рецепт.
Отбор
- Короткий созвон-знакомство (30 минут)
- Техническое интервью с разбором рабочих кейсов (60-90 минут)
- Финальная встреча с руководством, обсуждение условий
Общение строго через hh.ru
