Администратор баз данных

Привет! Меня зовут Вадим, я руковожу одной из команд админов в Туту. Нас в команде 10 человек, и мы поддерживаем значительную часть инфраструктуры компании. Всего в компании более 1000 сотрудников, из них около 300 в ИТ. Мы работаем с бодрящим коктейлем из технологий: есть как проверенные временем, так и свежие, не сильно распространённые в стране. Мы понимаем, что погружение в нашу специфику и обучение редким технологиям может занять время, поэтому при выборе нового сотрудника, будем ориентироваться не на знание всего нашего стека, а на ответственное отношение к системам, способность быстро разбираться с новым и умение договариваться в команде и с разработчиками. Будет немало рутины, но из рутины вырастают задачи на автоматизацию или изменение архитектуры для повышения стабильности систем — а такие задачи очень сильно прокачивают в профессиональном плане.

Мы сработаемся, если вы

• Работали с MySQL или PostgreSQL (в крайнем случае с MongoDB) на реальных проектах, в продакшене от двух лет, желательно в ecom.

• Хотите изучать те СУБД, с которыми пока не сталкивались.

• Любите помогать разработчикам, можете их услышать и понять.

• Умеете находить не первое подходящее, а самое рациональное решение проблемы.

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

• Пробовали разбираться в чём-то новом и/или странном с помощью логики и Google (в том числе англоязычного).

• Хотите работать в команде. Придётся много общаться, нужно будет и аргументировать свою точку зрения, и слушать, и понимать других. Без этого никуда.

• Не боитесь писать скрипты и знаете или хотите изучить Python.

• Готовы спокойно, быстро и чётко реагировать в случае сбоев — они бывают.

• Ничего не имеете против «Котиков» — наша команда называется именно так.

Нужно

• Разворачивать существующей автоматикой новые сервисы БД (MySQL, MongoDB, Redis, PostgreSQL, ClickHouse), придумывать улучшения для этой автоматики.

• Реагировать на warning и алерты, отслеживающие аномалии и обычные события жизненного цикла софта (заканчивающееся место, к примеру).

• Находить причины нестабильного поведения сервисов и устранять их.

• Дорабатывать мониторинг, добавлять дашборды и алерты по итогам сбоев.

• Анализировать и выполнять изменения в схемах БД (редко, в случае их потенциальной опасности).

• Предоставлять разработчикам сервисы баз данных для preprod-окружений.

• Помогать разработчикам в сложных ситуациях, связанных с БД.

Зона ответственности ДБА

• MariaDB — в HA-варианте с использованием ProxySQL и GitHub Orchestrator, немного подробностей есть на Хабре. Всего около 50 продакшен-инсталляций с разными топологиями.

• MongoDB — ReplicaSet-вариант с небольшой обвязкой для HA — порядка 30 разных репликасетов.

• Redis — отказоустойчивая конфигурация на базе Sentinel. Около 30 кластеров, из них несколько — прямо очень высоконагруженных.

• PostgreSQL — в основном HA-инсталляции на основе Patroni/PgBouncer — пока около 15 на каждой из сред, планируем наращивать использование.

• ClickHouse — только OLTP-нагрузка, без OLAP (это у другой команды) несколько инсталляций.

Инструментарий (если уже сталкивались — будет плюсом)

• lvs — ключевой элемент нашей HA.

• Ansible, Terraform — инструменты внутренней автоматизации,

• Стек мониторинга: Prometheus, PMM, Grafana.

• Стек сбора логов: Fuentbit — Kafka — Vector — Elastic.

• Python — достаточно много своей скриптовой обвязки.

Кто в команде

• Лёха. Ведущий DBA. Сделал отказоустойчивым весь наш парк MariaDB, с использованием ProxySQL, GitHub Orchestrator и самописного «клея» на Python. Придумал архитектуру для HA-инсталляций Redis и PostgreSQL. У Лёхи 15-летний опыт с MySQL, и он готов им делиться.

• Никита. В компании около полутора лет, специализируется в основном на PostgreSQL, успел обновить весь парк на Alma 9, параллельно существенно упростил и упорядочил автоматику и сопроводил процесс импортозамещения в контакт-центре на стороне баз данных. Основательно познакомился с особенностями работы ClickHouse, особенно в условиях неполного набора нод в кластерах, и смог прорваться через все его заморочки.

• Влад. В компании полгода, пока специализируется на небольших задачах в основном по PostgreSQL и MySQL, принял активное участие в переезде MySQL-виртуалок на Alma 9.

С этими ребятами нужно будет взаимодействовать больше всего. Кроме них в команде:

• Яша. Придумал и внедрил центральный элемент нашего видения HA — балансировщики на базе lvs и эникаст-адресов. Развернул систему централизованного мониторинга на базе Prometheus (вместо Graphite) и пайплайн сбора логов Fluentbit — Kafka — Vector вместо Rsyslog — Logstash, сделал distributed tracing на базе OpenTelemetry-стека.

• Антон. Внедрил в компании Kafka, главный эксперт по этому сервису. Отвечает за инструменты управления облаками — главный по Terraform (мы живём в нескольких ДЦ — и с тех пор количество ДЦ подросло) — и за слой фронтпрокси. Внедрил использование Vault в админской автоматике.

• Лёня. Специализируется преимущественно на инструментах мониторинга и логирования. Внедрил Pyroscope в Openshift для удобной профилировки продуктовых сервисов на Go, сделал пайплайн доставки логов аудита (Vector + ClickHouse), развернул awx. Кроме того придумал, как сделать кластеры MinIO одновременно и HA, и удобно сопровождаемыми.

• Виталик. Отвечает за envoy (фронтпрокси) и внутренние инструменты автоматизации вместе с Антоном. Запустил многопользовательский режим работы для нашего Terraform.

• Дима. Помогает Антону с Kafka, внедрил HA-конфигурацию RabbitMQ, дорабатывает систему обеспечения корректного поведения сервисов при отказе дисковой подсистемы.

• Саша. Разработчик, раньше занималась эксплуатацией монолитного приложения и кодила на PHP, а сейчас развивает инструменты внутренней автоматизации на Python. Написала и внедрила систему управления доступами к MySQL / MongoDB / PostgreSQL на основе данных из Active Directory. В процессе — разработка системы корректного выключения ЦОДа по кнопке.

• Вадим (я). Бывший разработчик, а сейчас главный зануда команды. Помимо руководства, помогаю ребятам с кодом, архитектурой и диагностикой сложных сбоев.

Как мы работаем

• Все новые конфигурации описываем кодом, храним в системе контроля версий. Из старого зафиксировано почти всё, но не 100%.

• Все существенные решения — роли, плейбуки, инвентори, скрипты и прочее — проводим через ревью внутри команды.

• Анализируем сбои и стараемся не допустить их повторения.

• По всем сервисам собираем метрики и логи, делаем алерты.

• По возможности автоматизируем типовые рутинные операции.

• Рисуем и пишем документацию. Стараемся, но пока есть пробелы.

• Используем в работе ИИ, но при этом не доверяем ему слепо.

• При выяснении требований напрямую общаемся с заказчиками (технарями) из других команд.

• Из регулярных встреч — командный созвон раз в неделю, one-to-one с Лёхой раз в неделю, стыковка по self review со мной раз в месяц. Всё остальное — по необходимости.

Что ждём

• Что вы вольётесь в команду и будете закрывать часть потока задач из нашего внутреннего сервис-деска — как минимум по двум из наших СУБД.

• На основе этого опыта сможете найти точки для автоматизации и оптимизации и с помощью коллег реализуете их.

Примеры задач из service desk

• Завести сервисного пользователя и БД в PostgreSQL.

• Перенести время бекапа БД Jira на ночь.

• Помочь разобраться с причиной возникновения дедлоков в MariaDB.

• Разнести репликасет MongoDB по разным ДЦ.

• Разобраться с ошибками на бекапном сервере PostgreSQL.