SRE DBA

Dodo Engineering — IT-подразделение международной компании Dodo Brands.
У нас много планов и нам нужны инженеры, которые помогут нам поддерживать и драйвить развитие бизнеса за счет надежности сервисов и инфраструктуры, а также облегчения жизни разработчиков.

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

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

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

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

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

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

• Перенос баз данных dev-окружений в Kubernetes

  У нас есть пайплайн по подготовке данных для dev-окружений, но ранее сами сервера баз данных разворачивались на одном хосте в докере в полуручном режиме. Мы перевели сервера баз данных в Kubernetes, что позволяет (пере)создавать их проще, динамичнее и без нашего участия.

Мы ожидаем, что ты возьмешь на себя работу по следующим направлениям:

Тюнинг производительности. Azure предоставляет нам несколько опций для разворачивания баз данных. Необходимо найти оптимальную конфигурацию для наших нужд, соблюдая при этом баланс между надёжностью и стоимостью, а в идеале построить методологию для проведения нагрузочного тестирования, которая будет помогать находить решения, подходящие под разные задачи.

• Мониторинг. Мы уже собираем метрики, которые нам предоставляет Azure, а также метрики и аналитику запросов с помощью Percona Monitoring and Management, которые обычно помогают нам обнаружить проблему. Нужно развивать систему мониторинга БД, чтобы находить, а затем и устранять источник проблемы можно было быстрее.
• Best practices. Необходимо выработать набор хороших практик и требований при работе с MySQL, а затем распространить их, закрепить в нефункциональных требованиях к нашим сервисам и по возможности помогать с обучением разработчиков.

Есть и конкретные задачи, которые скорее всего нужно будет делать. Например:

• апгрейд MySQL до 8.0;
• перевод Azure Database for MySQL на Flexible Server;
• переход к репликации с использованием GTID;
• настройка соединений к серверам БД через connection pooler.

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

Что мы ждём от тебя

• Экспертные знания MySQL, либо другой реляционной СУБД и готовность к переходу.
• Есть опыт расследования проблем, поиска узких мест в производительности и масштабировании баз данных.
• Умеешь работать в команде, можешь общаться с разработчиками на одном языке и находить баланс между идеальным решением в вакууме и текущими нуждами.

Будет плюсом, если ты:

• Работал с публичными облаками, понимаешь их преимущества и недостатки, а также основные концепции и применяемые практики.
• Имеешь опыт работы с RabbitMQ, Kafka, MongoDB/CosmosDB.

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

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