Site Reliability Engineer

О команде

Сейчас в нашей команде инфраструктуры 7 инженеров, среди которых как опытные разработчики, так и люди с большим опытом в качестве системных инженеров. Чем мы занимаемся:

• Повышаем автономность команд разработки.
• Увеличиваем надёжность системы.
• Снижаем количество рутинных операций.
• Снижаем стоимость инфраструктуры.
• Развиваем SRE-практики на уровне компании.

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

Примеры некоторых проектов за последний год

IaC 2.0

Мы постоянно эволюционируем, проходили этапы Azure ARM + Ansible, Terraform (HCL) + Packer + Ansible, экспериментировали с Pulumi, делали свое решение на базе вышеперечисленного с Python-оберткой (тесты, пробы, метрики и т.п) — до Kubernetes времен. В этом году мы написали решение на базе Jsonnet + Terraform (JSON) и движемся в сторону собственного K8s-оператора (Golang) (конечно же, мы смотрели на существующие реализации Terraform-операторов, но по разным причинам они не подходят (пока)).

Production-grade Kubernetes

Мы реализовали единый механизм для управления приложениями в наших кластерах с помощью собственного инструмента в формате CLI и чат-бота, помогли перевести по меньшей мере 80 приложений, сделали единый механизм управления секретами для приложений, настроили мониторинг и логирование и ещё много всего.

Автоматизация пейджинга, процесса ведения инцидентов командами

Чтобы было легче вводить новых сотрудников и команды в этот процесс, а также снизить когнитивную нагрузку на инженеров во время самого инцидента и после него, мы сделали Slack/Mattermost-бота — Reaction (Golang), который отправляет нотификации, содержащие полезную и необходимую информацию по алерту, автоматизирует большую часть ручных действий и помогает инженеру придерживаться принятого в компании процесса. Также у нас написан собственный инструмент пейджинга на замену PagerDuty/VictorOps/Grafana OnCall/etc — Pager (Golang), управляющий алертами, эскалациями, расписаниями, оповещением и даже расчетом компенсаций для дежурящих по своим сервисам команд.

Автоматизация миграций БД

На больших объёмах данных процесс выполнения скриптов миграций становится рутинным, длительным и ошибкоёмким, а также отнимает много времени и сил у наших инженеров. Мы разработали инструмент (MySQL Migrator (Golang)), чтобы применять DDL/DML изменения можно было без нашего участия, а сам процесс был надежным, прозрачным и автономным.

Чем предстоит заниматься

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

• Cloud Adoption. Сейчас всем, что связано с облаками, занимаемся преимущественно мы. Команды самостоятельно управляют своей инфраструктурой (через наши инструменты), но мы хотим расширять их ответственность, как пример — управление потреблением и затратами по своим сервисам.
• Infrastructure as Code. Наша облачная инфраструктура Azure полностью описана в коде, мы придерживаемся базовой единицы — сервис и это качественно описанная инфраструктура per service (Terraform + Jsonnet). В 2024 мы вводим еще одно облако — Yandex Cloud. Также, мы готовимся к описанию инфраструктуры на базе K8s CRDs (свои операторы).
• Kubernetes. Все наши сервисы развернуты в K8s, сейчас мы используем собственное решение для CD — env (GitOps + Oras + werf), но двигаемся в Argo/Flux, заворачиваем базовые сервисы в виде операторов с CRDs, готовим Kyverno, политики, Distroless и все, что необходимо для безопасной и управляемой работы.
• Service registry. Мы намерены собрать в одном месте всю информацию по сервисам, чтобы упростить поддержку и управление этой информацией и строить на её основе автоматизацию.
• Error budget. У нас уже есть набор инструментов для подсчёта бюджета ошибок, но нет процесса его контроля и отслеживания. С помощью автоматизации мы хотим превратить всё это в рабочую систему, позволяющую командам самостоятельно контролировать бюджет ошибок своих сервисов.

Мы ждём, что ты

• Имеешь практический опыт в дизайне и операционной поддержке и хотя бы небольшой в разработке высоконагруженных распределённых систем с доступностью 24/7/365.
• Имеешь опыт работы с публичными облаками, понимаешь их преимущества и недостатки, а также основные концепции и применяемые практики.
• Имеешь опыт работы с системами оркестрации контейнеров в production-окружениях.
• Умеешь работать в команде, можешь общаться с разработчиками на одном языке и находить баланс между идеальным решением в вакууме и текущими нуждами.
• Понимаешь принципы DevOps-культуры и SRE-практики и готов активно развиваться в этом направлении.
• Готов к нечастым, но существующим дежурствам.

Зачем идти к нам

• Классный онбординг. В течение первых трёх месяцев тебе во всём помогает опытный инженер, а потом останется твоим ментором. Не будет периода, когда ты не знаешь куда идти, у кого спросить и что делать. Погружение во все процессы максимально стремительное и гладкое.
• Независимая команда. Мы сами решаем, какие задачи для нас являются наиболее приоритетными и какие технологии и процессы использовать для их решения.
• Site Reliability Engineering. Мы идём в сторону SRE: некоторые практики уже используются в масштабах компании, над проработкой и внедрением других мы активно работаем. Например, мы используем алерты по SLO, пишем постмортемы и можем приостановить разработку новых фич, если доступность сервиса оказалась ниже установленного уровня.
• Жизнь в облаках. Мы стараемся по максимуму использовать преимущества публичных облаков и предоставляемых ими сервисов, чтобы тратить меньше времени на обслуживание, не переживать о железных серверах и не решать заново уже решённые проблемы.
• Есть возможность трудоустройства в Казахстане.

Больше материалов про работу нашей SRE-команды

• Внедрение SRE. Итоги 5 лет опыта.
• Настраиваем инцидент-менеджмент: от хаоса до автоматизации.
• Ensuring reliability: SLOs, on-call process, and postmortems.