С какими СУБД вы работали в контексте DevOps?

А, ну это про наши любимые базы данных, которые в проде то падают, то тормозят, то вообще нихуя не отвечают. Короче, в DevOps-то вся суть — не просто поставить PostgreSQL и забыть, а чтобы эта мартышлюшка работала, когда на неё овердохуища запросов навалится. Вот чем я, собственно, и занимаюсь.

По классике, SQL-шные:

• PostgreSQL: Тут, ёпта, не просто apt install postgresql и пошёл пить чай. Настраивал streaming-репликацию, чтобы если основная нода накрылась медным тазом, вторая тут же подхватила. Логическую репликацию для отдельных таблиц юзал — хитрая жопа, но иногда очень нужная. С расширениями типа pg_stat_statements возился, чтобы понять, какой запрос жрёт все ресурсы. Бэкапы — святое: pg_dump, pg_restore, а для серьёзных дел — wal-g, чтобы до облака всё летело.
• MySQL/MariaDB: Тоже не сахар. Master-slave репликация, танцы с бубном вокруг InnoDB, мониторинг через SHOW ENGINE INNODB STATUS — в общем, стандартный набор, чтобы база не легла и не сказала «да похуй».

NoSQL и кэши (тут веселее):

• Redis: Любимый всеми кэш, который внезапно становится хранилищем сессий, а потом и брокером сообщений. Разворачивал и Sentinel, и кластеры — это когда у тебя не один инстанс, а целая паутина. Настраивал persistence (RDB/AOF), чтобы после перезагрузки не оказалось, что всё чисто, как у кота сука собака.
• MongoDB: С ней тоже работал. Replica sets для отказоустойчивости — чтобы данные не пропали, если одна нода решит отдохнуть. Шардирование настраивал, когда одна машина уже не тянет — это как разложить гигантскую таблицу по разным сервакам.

А чтобы всё это не просто работало, а ещё и было под контролем, использовал:

1. Prometheus exporters: postgres_exporter, mysqld_exporter, redis_exporter. Это такие шпионы, которые постоянно смотрят, как там поживает база, и стучат мне метриками: «Слушай, а тут connection pool почти пустой, скоро будет пиздец!».
2. Инфраструктура как код (Terraform): Чтобы не тыкать в облачном провайдере кнопочки, а описать всё в коде: «Хочу RDS инстанс вот с такими параметрами». Нажал terraform apply — и через полчаса база готова. Волнение ебать, когда применяешь изменения к продакшену, но доверия к ручным действиям — ноль ебать.
3. Миграции (Ligquibase/Flyway): Чтобы схема базы обновлялась автоматически вместе с релизом приложения. Встроил в CI/CD пайплайн — разработчик залил изменения, и они сами накатились. Главное, чтобы скрипт отката был, а то будет вам хиросима и нигерсраки.

Вот, например, как health check для PostgreSQL в Kubernetes выглядит, чтобы кубер понимал, когда под готов принимать трафик:

readinessProbe:
  exec:
    command:
      - sh
      - -c
      - "pg_isready -U $POSTGRES_USER -d $POSTGRES_DB"
  initialDelaySeconds: 10
  periodSeconds: 5

Короче, суть не в том, чтобы знать синтаксис SQL наизусть. А в том, чтобы эта ебанутая система из серверов, баз, кэшей и мониторинга в распределённой инфраструктуре не развалилась и не заставила тебя в три часа ночи вскакивать с криком «ёб твою мать!». Вот это и есть работа.