SRE

О команде

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

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

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

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

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

• Cloud Adoption. Сейчас всем, что связано с облаками, занимаемся преимущественно мы. Некоторые команды уже самостоятельно управляют своей инфраструктурой и затратами в облаке, и мы хотим передать ответственность и в другие команды.
• Infrastructure as Code. У нас уже есть решение, которое частично закрывает это направление, но его сложно использовать как полностью self-managed инструмент, поэтому мы хотим пересмотреть подходы и построить решение, которое будет удовлетворять нашим запросам по автономности и масштабируемости.
• Service catalog. Мы хотим собрать в одном месте всю информацию по сервисам, чтобы упростить поддержку и управление этой информацией и строить на её основе автоматизацию.
• Error budget. У нас уже есть набор инструментов для подсчета бюджета ошибок, но нет процесса его контроля и отслеживания. С помощью автоматизации мы хотим превратить все это в рабочую систему, позволяющую командам самостоятельно контролировать бюджет ошибок своих сервисов.

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

• Production-grade Kubernetes. Мы реализовали единый механизм для управления приложениями в наших кластерах с помощью собственного инструмента в формате CLI и чат-бота, помогли перевести по меньшей мере 40 приложений, сделали единый механизм управления секретами для приложений, настроили мониторинг и логирование и ещё много всего.
• Автоматизация процесса ведения инцидентов. Чтобы было легче вводить новых сотрудников в этот процесс, а также снизить когнитивную нагрузку на инженера во время самого инцидента и после него, мы сделали Slack-бота, который отправляет нотификации, содержащие полезную и необходимую информацию по алерту, автоматизирует большую часть ручных действий и помогает инженеру придерживаться принятого в компании процесса.
• Автоматизация миграций БД. На больших объёмах данных процесс выполнения скриптов миграций становится рутинным, длительным и ошибкоёмким, а также отнимает много времени и сил у наших инженеров. Мы разработали инструмент, чтобы применять скрипты можно было без нашего участия, а сам процесс был надежным, прозрачным и автономным
• Передача дежурств в команды разработки. Вместе с ростом системы и её сложности инженеры нашей команды начали превращаться из дежурных, которые самостоятельно решают проблемы, в первую линию обороны, что привело к чрезмерной нагрузке и увеличению цикла обратной связи для разработчиков. Мы начали передавать ответственность за мониторинг и дежурства в руки команд, чтобы они самостоятельно реагировали на проблемы в своих сервисах и повышали их стабильность.

Требования

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

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

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

Если хочешь узнать больше о том, как мы работаем и какие проблемы решаем, посмотри выступления наших специалистов:

• Путь разработчика в SRE / Матвей Григорьев: ссылка.
• Как мы улучшали сервис SRE. Екатерина Глуховская: ссылка.
• Георгий Полевой — Архитектура производительности Dodo IS: ссылка.