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

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

‍

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

• Работали с MySQL или PostgreSQL (в крайнем случае с MongoDB) на реальных проектах, в продакшене от двух лет, желательно в ecom.
• Хотите изучать те СУБД, с которыми пока не сталкивались.
• Любите помогать разработчикам, можете их услышать и понять.
• Умеете находить не первое подходящее, а самое рациональное решение проблемы.
• Не боитесь потока сервисных задач, способны расставлять между ними приоритеты.
• Пробовали разбираться в чём-то новом и/или странном с помощью логики и Google (в том числе англоязычного).
• Хотите работать в команде. Придётся много общаться, нужно будет и аргументировать свою точку зрения, и слушать, и понимать других. Без этого никуда.
• Не боитесь писать скрипты и знаете или хотите изучить Python.
• Готовы спокойно, быстро и чётко реагировать в случае сбоев — они бывают.
• Ничего не имеете против «Котиков» — наша команда называется именно так.

Нужно

• Разворачивать существующей автоматикой новые сервисы БД (MySQL, MongoDB, Redis, PostgreSQL, ClickHouse), придумывать улучшения для этой автоматики.
• Реагировать на warning и алерты, отслеживающие аномалии и обычные события жизненного цикла софта (заканчивающееся место, к примеру).
• Находить причины нестабильного поведения сервисов и устранять их.
• Дорабатывать мониторинг, добавлять дашборды и алерты по итогам сбоев.
• Анализировать и выполнять изменения в схемах БД (редко, в случае их потенциальной опасности).
• Предоставлять разработчикам сервисы баз данных для preprod-окружений.
• Помогать разработчикам в сложных ситуациях, связанных с БД.

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

• MariaDB — в HA-варианте с использованием ProxySQL и GitHub Orchestrator, немного подробностей есть на Хабре https://habr.com/ru/company/tuturu/blog/508872/. Всего около 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 (мы живём в нескольких ДЦ https://habr.com/ru/company/tuturu/blog/508872/ — и с тех пор количество ДЦ подросло) — и за слой фронтпрокси. Внедрил использование Vault в админской автоматике.
• Лёня. Специализируется преимущественно на инструментах мониторинга и логирования. Внедрил Pyroscope в Openshift для удобной профилировки продуктовых сервисов на Go, сделал пайплайн доставки логов аудита (Vector + ClickHouse), развернул awx. Кроме того придумал, как сделать кластеры MinIO одновременно и HA, и удобно сопровождаемыми.
• Виталик. Отвечает за envoy (фронтпрокси) и внутренние инструменты автоматизации вместе с Антоном. Запустил многопользовательский режим работы для нашего Terraform.
• Дима. Помогает Антону с Kafka, внедрил HA-конфигурацию RabbitMQ, дорабатывает систему обеспечения корректного поведения сервисов при отказе дисковой подсистемы.
• Саша. Разработчик, раньше занималась эксплуатацией монолитного приложения и кодила на PHP, а сейчас развивает инструменты внутренней автоматизации на Python. Написала и внедрила систему управления доступами к MySQL / MongoDB / PostgreSQL на основе данных из Active Directory. В процессе — разработка системы корректного выключения ЦОДа по кнопке.
• Вадим (я). Бывший разработчик, а сейчас главный зануда команды. Помимо руководства, помогаю ребятам с кодом, архитектурой и диагностикой сложных сбоев.

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

• Все новые конфигурации описываем кодом, храним в системе контроля версий. Из старого зафиксировано почти всё, но не 100%.
• Все существенные решения — роли, плейбуки, инвентори, скрипты и прочее — проводим через ревью внутри команды.
• Анализируем сбои и стараемся не допустить их повторения. Вот тут есть пример одного из самых эпичных — https://habr.com/ru/company/tuturu/blog/555274/.
• По всем сервисам собираем метрики и логи, делаем алерты.
• По возможности автоматизируем типовые рутинные операции.
• Рисуем и пишем документацию. Стараемся, но пока есть пробелы.
• Используем в работе ИИ, но при этом не доверяем ему слепо.
• При выяснении требований напрямую общаемся с заказчиками (технарями) из других команд.
• Из регулярных встреч — командный созвон раз в неделю, one-to-one с Лёхой раз в неделю, стыковка по self review со мной раз в месяц. Всё остальное — по необходимости.

Что ждём

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

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

• Завести сервисного пользователя и БД в PostgreSQL.
• Перенести время бекапа БД Jira на ночь.
• Помочь разобраться с причиной возникновения дедлоков в MariaDB.
• Разнести репликасет MongoDB по разным ДЦ.
• Разобраться с ошибками на бекапном сервере PostgreSQL.

‍