DevOps/Platform инженер

Что предстоит делать

Клиент — американская компания в сфере healthcare-данных, создающая платформу для менеджеров аптечных льгот (pharmacy benefit managers). Платформа принимает исторические данные пациентов и рецептов, прогоняет их через ETL-пайплайн в унифицированную модель данных и обслуживает модели машинного обучения, которые формируют рекомендации по лекарствам и лечению. Сегодня процесс ручной — данные готовятся на десктопе, модели разворачиваются вручную, CI/CD отсутствует. Цель — production SaaS-платформа с первым MVP в конце 2026 года. Инфраструктура — AWS, со средой выполнения на Docker и Kubernetes и сильным предпочтением open-source инструментов вместо управляемых проприетарных сервисов. Целевой показатель доступности — 99,9%, 24×7. Текущее использование — масштаб proof-of-concept, поэтому архитектура должна достигать этой цели без избыточного усложнения, а стоимость должна быть входным параметром проектирования с первого дня: окружение, которое соответствует чек-листу, но чей счёт удваивается через шесть месяцев, неприемлемо. Это full-time удалённое сотрудничество. Рабочие часы — 06:00–14:00 по восточному времени США, разработка ведётся на виртуальных десктопах, предоставленных клиентом. Ключевые обязанности Спроектировать инфраструктуру AWS и Kubernetes для платформы на основе целевой архитектуры и задокументировать её. Построить окружения — development, test и production — с чётким разделением и воспроизводимым провижинингом. Настроить CI/CD с нуля для кода приложений, пайплайнов данных и развёртывания моделей. Определить infrastructure as code и обеспечить воспроизводимость каждого окружения из неё. Спроектировать под доступность 99,9%, 24×7: мониторинг, алертинг, резервное копирование, восстановление и практику on-call. Отвечать за стоимость: осознанно выбирать типы инстансов, хранилища и политики масштабирования и отчитываться о расходах. Внедрить безопасность и контроль доступа, соответствующие чувствительным healthcare-данным. Работать с data-инженером для надёжного запуска пайплайнов и сервисов моделей на Kubernetes. Заменить ручные шаги развёртывания автоматизированными и аудируемыми. Предлагать подход и отстаивать его, а не ждать полностью сформированного требования. Писать runbook'и и документацию, необходимые команде для эксплуатации платформы без вашего присутствия. Обязательные квалификации Опыт DevOps или platform engineering, включая ответственность за production-окружение. Практический опыт работы с AWS. Практический опыт работы с Docker и Kubernetes в production. Опыт построения CI/CD-пайплайнов с нуля. Infrastructure as code с инструментом вроде Terraform и дисциплина поддержания воспроизводимости окружений. Опыт проектирования под определённый целевой показатель доступности и эксплуатации в соответствии с ним, включая мониторинг, алертинг и реагирование на инциденты. Подтверждённое проектирование с учётом стоимости и управление затратами в облачной среде. Реальный английский уровня C1 — роль требует прямых встреч с клиентом без посредника. Доступность в часы 06:00–14:00 по восточному времени США. Предпочтительные квалификации Опыт запуска пайплайнов данных и нагрузок машинного обучения на Kubernetes. Опыт работы с open-source стеком наблюдаемости (Prometheus, Grafana, Loki или аналоги). Опыт в области безопасности и комплаенса с healthcare-данными или другими регулируемыми данными. Опыт работы с GitOps-инструментами, такими как Argo CD или Flux. Опыт работы с Python или скриптами для автоматизации. Опыт перевода окружения proof-of-concept в production. Ваши первые 90 дней Первые 30 дней — Вы изучили целевую архитектуру, подготовили проект инфраструктуры с оценкой стоимости и согласовали его с CTO; первое окружение развёрнуто из кода. К 60 дням — окружения development и test работают из infrastructure as code, CI/CD развёртывает пайплайн данных и сервисы моделей без ручных шагов, а мониторинг и алертинг запущены. К 90 дням — production работает в соответствии с целевым показателем доступности, резервное копирование и восстановление протестированы, расходы отслеживаются относительно оценки, а runbook'и существуют, чтобы платформу мог эксплуатировать кто-то другой.