компания "dodo brands (dodo pizza, drinkit, doner 42)" dodo engineering — it-подразделение международной компании dodo brands, развивающей 3 бренда: додо пицца: более 830 пиццерий в 16 странах; дринкит: 4 кофейни, в москве и самаре; донер 42: 1 донерная в москве. у нас много планов и нам нужны инженеры, которые помогут нам поддерживать и драйвить развитие бизнеса за счет надежности сервисов и инфраструктуры, а также облегчения жизни разработчиков.сейчас в нашей команде 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, пишем постмортемы и можем приостановить разработку новых фич, если доступность сервиса оказалась ниже установленного уровня. жизнь в облаках. мы стараемся по максимуму использовать преимущества публичных облаков и предоставляемых ими сервисов, чтобы тратить меньше времени на обслуживание, не переживать о железных серверах и не решать заново уже решённые проблемы.
Адрес
Москва