DBA

О команде

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

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

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

О проектах

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

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

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

Задачи

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

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

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

• Апгрейд MySQL до 8.0.
• Перевод Azure Database for MySQL на Flexible Server.
• Репликация между регионами.

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

Требования

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

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

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

Мы предлагаем

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

У нас удаленка по РФ и вне РФ, а также есть офисы в Москве, Питере, Нижнем Новгороде, Сыктывкаре.