Lead Site Reliability Engineer - Imunify Reliability Platform (remote work)

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

Это задание в "зеленом поле" внутри уже существующего "коричневого поля". Вы не наследуете команду SRE, фреймворк SLO или культуру пейджинга. Вы определяете их совместно с руководителями инженерных команд и затем делаете их обязательными.

1. Определить, что означает "working" для ~70 компонентов

• Провести определение SLI совместно с лидерами сквадов и старшими инженерами. Вы фасилитируете процесс и поддерживаете стандарт; владеющий сквад подписывает SLI.
• Построить таксономию, действительно необходимую этому продукту, которая шире, чем доступность и задержка:
• Service SLIs — доступность, задержка, уровень ошибок для облачных сервисов.
• Fleet SLIs — достижимость heartbeat, согласованность версий и конфигураций по всей установленной базе.
• Control-efficacy SLIs — дифференциатор. Какая доля защищённых единиц имеет контроль, эффективно включённый и актуальный, а не просто установленный. Дрейф генерации правил, возраст подписи, покрытие сканированием, распределение режимов принудительного применения.
• Delivery SLIs — успешность публикации артефактов, время от правила до флота, время до конвергенции хотфикса.
• Pipeline SLIs — задержка ingest, задержка verdict, возраст очереди, сжигание бэклога.
• Применять одно недоговорное правило дизайна: SLI должен измеряться извне "ворот" измеряемого объекта.

1. Построить систему сбора

• Спроектировать и построить конвейер, который извлекает эти индикаторы из флота и помещает их в запросный хранилище: push‑based, sampled, privacy‑constrained, с бюджетом кардинальности, который вы задаёте и защищаете.
• Расширить инструментирование на стороне агента и сервиса там, где сигнал ещё не существует, используя Python, Go и Rust, совместно с владеющими сквадами.
• Консолидировать текущий разрозненный набор дашбордов, ad‑hoc запросов и путей отчётности в защищённый набор инструментов и избавиться от того, что не оправдывает себя.

1. Построить оповещения и управление оповещениями

• Оповещения, основанные на симптомах и привязанные к SLO, с семантикой burn‑rate по нескольким окнам. Не "суп" порогов.
• Трёхуровневая таксономия — page / ticket / dashboard — с явным правилом, что допускается пейджить человека в 03:00.
• Каждое оповещение должно поставляться с владельцем, runbook и задокументированным режимом отказа, иначе оно не поставляется.
• Гигиена оповещений как постоянная практика: квартальный обзор, удаление считается победой, отслеживание коэффициента действия.

1. Построить эскалацию

• Карта Component → owning squad, актуальная, машинно‑читаемая и интегрированная в маршрутизацию, чтобы оповещение дошло до нужных семи человек, а не в общий канал.
• Матрица серьёзности, SLA подтверждения, дизайн ротации follow‑the‑sun в диапазоне UTC−5 … UTC+8 и протокол чистой передачи.
• Практика командования инцидентами и безвиновные постмортемы в течение 24 часов.
• Спроектировать систему эскалации так, чтобы сквады несли свои собственные пейджеры. Вы строите и эксплуатируете платформу и обучаете практике; вы не являетесь буфером, поглощающим чужие оповещения.

Значительный опыт в production‑engineering или SRE, включая как минимум одну среду, где вы определяли фреймворк SLO, а не наследовали его. Сильные навыки Python. Умение читать и модифицировать код на Go или Rust — наши агенты написаны на этих языках, и туда попадает инструментирование. Глубокое практическое понимание телеметрии временных рядов и событий в масштабе: Prometheus/OpenMetrics, Grafana, слой маршрутизации класса Alertmanager и колонковое хранилище для данных флота с высокой кардинальностью (ClickHouse или эквивалент). Отладка распределённых систем на «bare metal» и длительно работающих хостах. Большая часть этой инфраструктуры не использует Kubernetes, и рефлексы, предполагающие наличие оркестратора, не перенесутся без проблем. Управление конфигурацией и CI в продакшн‑масштабе — Ansible, GitLab CI, Jenkins или близкие эквиваленты. Умение проектировать измерения для машин, которыми вы не владеете и которые нельзя опросить: push‑телеметрия, сэмплирование, сдвиг часов, частичная отчётность и ограничения конфиденциальности, возникающие при работе на сервере клиента. Письменная коммуникация, выдерживающая асинхронность. Эта роль на 40 % состоит из инженерии телеметрии и на 40 % из согласования с шестьюдесятью инженерами, что означает «здоровый», оставшиеся 20 % — отказываться от решения в виде дашборда, который никто не читает.

Опыт работы с продуктами безопасности — WAF, EDR, AV, управление уязвимостями — и понимание, что SLI контрольного механизма безопасности касается принудительного применения, а не времени безотказной работы. Мониторинг в рамках аудита: SOC 2 CC7.x, ISO 27001 A.8.16, NIST SP 800-137 continuous monitoring. OpenTelemetry, eBPF, Sentry. Проектирование телеметрии с учётом стоимости и кардинальности. Свободное владение инструментами разработки агентов — мы используем SDLC, ориентированный на Cursor/Claude, с внутренними и сторонними MCP‑серверами, и инженеры оцениваются по тому, насколько эффективно они работают с этой системой. Kubernetes, для единственной нагрузки, которая на нём развернута.

Полностью удалённая работа с гибким графиком, позволяющая планировать ваш день и работать из любой точки мира; Оплачиваемый отпуск — 24 дня в год, 10 дней государственных праздников и неограниченное количество больничных, чтобы поддерживать здоровый баланс работы и личной жизни; Компенсация частной медицинской страховки; Возмещение расходов на коворкинг и спорт/тренажёрный зал; Возможность получить вознаграждение за самую инновационную идею, которую компания может запатентовать, способствуя культуре креативности и инноваций.