Бэкапы, обновление, разбор падения

Данные базы лежат в томе, и том переживает пересоздание контейнера. Отсюда легко сделать вывод, что о сохранности можно больше не думать, — и вывод неверный. Том не спасает ни от команды, которая его стирает, ни от DELETE без WHERE, ни от диска, который кончился, ни от VPS, выключенного хостингом за неоплату. Во всех этих случаях данные пропадают вместе с томом или внутри него. Бэкап — это отдельная копия, которая лежит не там же.

У PostgreSQL копия бывает двух родов. Логическая — текст SQL, который восстанавливает схему и строки обычными командами: её снимает pg_dump, после сжатия она невелика, читается глазами и переносится между мажорными версиями. Физическая — побайтная копия каталога данных вместе с журналом упреждающей записи; она умеет «на минуту до аварии», но требует того же мажора сервера и места под журналы. Одному VPS с одной базой хватает первой, и весь раздел про неё.

Первая ловушка ждёт там, где её не ищут, — в версии клиента. Сервер у нас 18-й, а pg_dump на хосте приехал с каким-то другим пакетом и оказался 17-м. Прогноз: что напечатает каждый из двух клиентов?

# Один и тот же сервер, два клиента pg_dump разных мажорных версий.
# Каталоги клиентов приходят в CLIENTS: на хосте это тот postgresql-client,
# который поставил пакетный менеджер, в контейнере — клиент самого образа.
set -eu
export PGUSER=${POSTGRES_USER:-app}
DB=${POSTGRES_DB:-app_db}

echo "сервер: $(psql -tAc 'show server_version' -d "$DB")"
for DIR in $CLIENTS; do
  echo "--- клиент pg_dump $("$DIR/pg_dump" --version | cut -d' ' -f3)"
  if "$DIR/pg_dump" -d "$DB" > dump.sql 2> err.txt; then
    echo "дамп снят, строк SQL $(wc -l < dump.sql | tr -d ' ')"
  else
    echo "код выхода $?"
    cat err.txt
  fi
done
rm -f dump.sql err.txt

сервер: 18.4 (Homebrew)
--- клиент pg_dump 17.5
код выхода 1
pg_dump: error: aborting because of server version mismatch
pg_dump: detail: server version: 18.4 (Homebrew); pg_dump version: 17.5
--- клиент pg_dump 18.4
дамп снят, строк SQL 259

Клиент 17-й версии не знает каталогов 18-й и отказывается сам, кодом 1, не сняв ни строки. Отказ громкий и честный: половина дампа была бы хуже. Отсюда правило боевого сценария — pg_dump запускают внутри контейнера базы, а не на хосте: там клиент и сервер приехали одним образом и разъехаться не могут.

# deploy/backup.sh автора, сокращено: pg_dump идёт ВНУТРИ контейнера базы
set -euo pipefail
cd "$(dirname "$0")"
mkdir -p backups
FILE="backups/app_db_$(date +%F_%H-%M).sql.gz"

# --env-file обязателен: compose интерполирует файл стека даже для exec
docker compose --env-file ../.env.prod -f docker-compose.prod.yml \
  exec -T postgres pg_dump -U app -d app_db | gzip > "$FILE"

# свежий дамп только что создан, поэтому ls не бывает пустым (важно при pipefail)
ls -1t backups/app_db_*.sql.gz | tail -n +15 | xargs -r rm --

Строка set -euo pipefail несёт больше, чем кажется. Код выхода трубы — это код последней команды, а последняя тут gzip: упавший pg_dump отдал бы ему пустой поток, тот записал бы 20-байтовый архив и вернул ноль. Файл есть, дата свежая, сценарий доволен. Спасает pipefail — с ним сценарий обрывается до ротации и не успевает удалить рабочий дамп в пользу пустого.

Но проверять всё равно надо не «файл появился», а сам файл, и делать это должен не человек. Минимальный монитор — две проверки: свежесть и размер против того, каким этот дамп обычно бывает. Прогноз: сколько файлов из пяти он признает годными и что скажет про последний?

// Монитор бэкапов: по списку файлов решить, есть ли пригодный дамп.
// Порог «не меньше половины медианы» грубый, но ловит главный случай:
// дамп не снялся, а файл всё равно появился.
const сейчас = Date.parse("2026-09-28T04:10:00Z");

const файлы = [
  { имя: "app_db_2026-09-24_03-30.sql.gz", байт: 5242880, снят: "2026-09-24T03:30:00Z" },
  { имя: "app_db_2026-09-25_03-30.sql.gz", байт: 5310072, снят: "2026-09-25T03:30:00Z" },
  { имя: "app_db_2026-09-26_03-30.sql.gz", байт: 5402311, снят: "2026-09-26T03:30:00Z" },
  { имя: "app_db_2026-09-27_03-30.sql.gz", байт: 20, снят: "2026-09-27T03:30:00Z" },
  { имя: "app_db_2026-09-28_03-30.sql.gz", байт: 20, снят: "2026-09-28T03:30:00Z" },
];

const размеры = файлы.map((ф) => ф.байт).sort((a, b) => a - b);
const порог = размеры[(размеры.length - 1) >> 1] / 2;
const годен = (ф) => ф.байт >= порог;

const последний = файлы.reduce((а, б) => (Date.parse(а.снят) > Date.parse(б.снят) ? а : б));
const минут = (сейчас - Date.parse(последний.снят)) / 60000;

console.log(`порог размера: ${порог} Б`);
console.log(`последний файл: ${последний.имя}, снят ${минут} мин назад`);
console.log(`свежесть (не старше 26 ч): ${минут <= 26 * 60 ? "ок" : "просрочен"}`);
console.log(`размер: ${последний.байт} Б — ${годен(последний) ? "ок" : "мал"}`);
console.log(`годных файлов: ${файлы.filter(годен).length} из ${файлы.length}`);

Свежесть у последнего файла в порядке, а размер — нет, и это самый частый вид мёртвого бэкапа: снимается каждую ночь, файл появляется, дата новая. Порог «не меньше половины медианы» груб, зато не требует знать, сколько весит база, растёт вместе с ней и ловит ровно тот случай, когда дамп не снялся вовсе.

Проверка, которая кажется разумной и не работает: сравнить два дампа побайтно. У PostgreSQL 18 в начале и конце файла стоит \restrict со случайным ключом, и два дампа одних и тех же данных не совпадают. Сравнивают содержимое базы, а не файлы.

Теперь о том, чего в дампе базы нет. Роли и их пароли — объекты кластера, а не базы, и pg_dump их не берёт; при этом строки вида ALTER TABLE … OWNER TO app в дампе есть, то есть роль app обязана существовать раньше восстановления. Фотографии лежат не в базе. Файла с секретами в базе нет вовсе.

А вот что в дампе есть, и об этом забывают: журнал миграций. Отметки о применённых шагах живут в самой базе, в отдельной схеме, и уезжают в дамп вместе с данными. База, поднятая из копии, для раннера миграций выглядит как база, где все шаги уже применены, — и это верно, схема в ней именно такая.

Дамп, который ни разу не поднимали, — это не копия, а файл. Между «pg_dump вышел с нулём» и «из этого файла встаёт работающая база» лежит целый класс поломок: прав не хватило на часть объектов, дамп снимали с фильтром по схеме, роль владельца в новой базе называется иначе, дамп снимали не с той базы. Каждая из них видна только при восстановлении.

Проверка — три шага: снять дамп, поднять его в чистой базе, сверить содержимое с тем, откуда снимали. Третий обычно и пропускают, ограничившись «команда не отказала». Прогноз: что напечатает сверка и какие таблицы попадут в её список?

# Проверка бэкапа: снять дамп, поднять его в ЧИСТОЙ базе и сверить содержимое.
# На боевой машине это идёт внутри контейнера с базой — клиент там заведомо
# той же мажорной версии, что и сервер:
#   docker compose exec -T postgres sh /backup/restore-check.sh
# Хост и порт libpq берёт из окружения; внутри контейнера это локальный сокет.
set -eu

DB=${POSTGRES_DB:-app_db}
FRESH=${DB}_check
export PGUSER=${POSTGRES_USER:-app} PGDATABASE=$DB

echo "сервер: $(psql -tAc 'show server_version'), pg_dump: $(pg_dump --version | cut -d' ' -f3)"

mkdir -p backups
DUMP=backups/${DB}_$(date +%F_%H-%M).sql.gz
# дамп собирается файлом, а не трубой в gzip: у трубы код выхода берётся от
# последней команды, и падение pg_dump в нём теряется
pg_dump > "$DUMP.plain"
gzip -f "$DUMP.plain" && mv "$DUMP.plain.gz" "$DUMP"
echo "дамп: $DUMP, строк SQL $(gunzip -c "$DUMP" | wc -l | tr -d ' ')"

PGOPTIONS='-c client_min_messages=warning' dropdb --if-exists "$FRESH"
createdb "$FRESH"
# ON_ERROR_STOP=1: восстановление обязано остановиться на первой же ошибке
if gunzip -c "$DUMP" | psql -q -o /dev/null -v ON_ERROR_STOP=1 -d "$FRESH"; then
  echo "восстановление в чистую базу $FRESH: без ошибок"
else
  echo "восстановление в чистую базу $FRESH: psql отказал"
  exit 1
fi

psql -tAF' ' -d "$DB"    -f check.sql > before.txt
psql -tAF' ' -d "$FRESH" -f check.sql > after.txt
cat after.txt
if diff -q before.txt after.txt > /dev/null; then
  echo "сверка: содержимое совпало"
else
  echo "сверка: РАСХОЖДЕНИЕ"
  diff before.txt after.txt
fi

dropdb "$FRESH"
rm -f before.txt after.txt

сервер: 18.4 (Homebrew), pg_dump: 18.4
дамп: backups/app_db_<дата>.sql.gz, строк SQL 259
восстановление в чистую базу app_db_check: без ошибок
drizzle.__drizzle_migrations 1 2312873a52d92ca62794a1e90ee21023
public.notes 28 cc261ab230be28604ba2a5d3cd54089a
public.users 3 1d7010d87bc37d3c659b05d3678fb578
сверка: содержимое совпало

Таблиц в списке три, а не две: рядом с notes и users стоит журнал миграций из отдельной схемы. Сверка идёт не по числу строк, а по контрольной сумме содержимого — число строк совпадает и у таблицы, в которой перепутаны значения. Порядок внутри суммы задан явно: иначе она зависела бы от того, в каком порядке база вернула строки, а этого база не обещает.

Слово «чистая» во втором шаге — не про аккуратность. Что psql после ошибки дочитывает файл до конца и выходит с нулём, вы уже видели на трёх вставках; здесь та же механика стоит дороже. Прогноз: тот же дамп поднимают в базу, где схема уже есть и строки тоже, — сколько удалённых строк вернётся на место?

# Восстановление дампа ПОВЕРХ базы, в которой уже есть схема и строки, —
# так делают, когда «надо срочно вернуть удалённое».
# Хост и порт libpq берёт из окружения; PGUSER и имя базы — как в compose.
set -eu
export PGUSER=${POSTGRES_USER:-app}
DB=${POSTGRES_DB:-app_db}
LIVE=${DB}_live

# Дамп «за прошлую ночь»
pg_dump -d "$DB" | gzip > before.sql.gz

# Сцена: та же база, из которой кто-то удалил черновики. Это и есть инцидент,
# после которого хочется вернуть строки из ночного дампа
PGOPTIONS='-c client_min_messages=warning' dropdb --if-exists "$LIVE"
createdb "$LIVE"
gunzip -c before.sql.gz | psql -q -o /dev/null -v ON_ERROR_STOP=1 -d "$LIVE"
psql -q -d "$LIVE" -c "DELETE FROM notes WHERE status = 'draft'"
echo "после инцидента: users $(psql -tAc 'SELECT count(*) FROM users' -d "$LIVE"), notes $(psql -tAc 'SELECT count(*) FROM notes' -d "$LIVE")"

# Восстановление так, как его запускают в спешке: psql без ON_ERROR_STOP
set +e
gunzip -c before.sql.gz | psql -q -o /dev/null -d "$LIVE" 2> errors.txt
CODE=$?
set -e
echo "восстановление поверх: код psql $CODE, строк с ERROR $(grep -c '^ERROR' errors.txt | tr -d ' ')"
echo "первая ошибка: $(head -1 errors.txt)"
echo "после восстановления: users $(psql -tAc 'SELECT count(*) FROM users' -d "$LIVE"), notes $(psql -tAc 'SELECT count(*) FROM notes' -d "$LIVE")"

# То же самое, но psql остановлен на первой ошибке
set +e
gunzip -c before.sql.gz | psql -q -o /dev/null -v ON_ERROR_STOP=1 -d "$LIVE" 2> /dev/null
echo "то же с ON_ERROR_STOP=1: код psql $?"
set -e

dropdb "$LIVE"
rm -f errors.txt before.sql.gz

после инцидента: users 3, notes 8
восстановление поверх: код psql 0, строк с ERROR 17
первая ошибка: ERROR:  schema "drizzle" already exists
после восстановления: users 3, notes 8
то же с ON_ERROR_STOP=1: код psql 3

Ни одной: заметок было восемь, восемь и осталось. Семнадцать строк с ERROR в потоке ошибок — и ноль в коде выхода, то есть единственное, о чём этот ноль сообщает, — что файл дочитан. А вернуть удалённое дамп и не мог: COPY в нём — одна команда на всю таблицу, и она падает целиком на первом же конфликте ключа, не вставив ни строки. Тот же запуск с ON_ERROR_STOP=1 кончается кодом 3.

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

Из этого складывается регламент восстановления — короткий документ, написанный заранее: где лежит копия, кто её поднимает, в какую базу, чем сверяет и сколько это занимает по времени. Последнее важнее, чем кажется: восстановление гигабайтного дампа — минуты, а не секунды, и знать их лучше до аварии, а не во время.

Обновление версии на сервере — это три команды, и вся работа выката прячется в двух последних: первая только привозит код.

# 1. привезти код
cd /opt/stack-starter && git pull

# 2. собрать образы — по одному: сборка отделена от up и идёт с --parallel=1,
#    потому что на двух ядрах сервера параллельные сборки образов его кладут
docker compose --env-file .env.prod -f deploy/docker-compose.prod.yml build --parallel=1

# 3. привести стек к описанию: пересоздаются только те сервисы, чьи образы
#    изменились, а вышедшая одноразовая работа запускается заново —
#    схему меняет она, и api ждёт её успешного выхода
docker compose --env-file .env.prod -f deploy/docker-compose.prod.yml up -d

Сборка неслучайно отдельная команда: up -d --build собирал бы всё, что разошлось, разом, а на двух ядрах VPS три параллельные сборки уже роняли прод — поэтому сценарий выката автора собирает по одному образу и только потом поднимает стек. Сколько займёт вторая команда, решает при этом не мощность сервера, а ключ шага: правка обработчика не должна сбивать установку зависимостей. Отдельной команды для схемы в этом списке нет намеренно: миграция — сервис стека, который приложение дожидается по условию успешного выхода, потому что применять миграцию стартом приложения нельзя — копий приложения бывает больше одной. Выкат без правок схемы от этого не дорожает: джоба выходит с нулём, не сделав ничего.

Перед всеми тремя стоит нулевая: снять дамп. Не потому, что миграция обязательно сломается, а потому, что шаг, который её ломает, чаще всего не отказывает, а тихо портит данные, — и без копии «до» это не лечится.

Дальше начинается то, из-за чего выкат вообще может стоить данных. Контейнер — вещь одноразовая, и up -d после пересборки образа заменяет его целиком.

Последняя строка — самая дорогая. В каталоге данных лежит файл с номером мажора, и сервер другой версии этот каталог своим не считает. У образов с 18-й версии он вложен в том подкаталогом с номером мажора, так что образ нового мажора в этот каталог даже не заглядывает — зато находит его рядом со своим и вместо тихой пустой базы печатает объяснение и выходит с кодом 1. Итог один: одна правка тега образа с 18 на 19 превращает выкат в остановку базы, а лечится она не откатом тега, а переносом (pg_upgrade, которому нужны обе версии сразу) или дампом, снятым до обновления.

# в каталоге данных лежит файл с мажором сервера, который его создал
cat "$PGDATA"/PG_VERSION

Остаётся окно, в котором сайт мигает: прокси пересоздание пережил и продолжает работать, а приложения за ним несколько секунд нет, и читатель получает от прокси отказ. На одном VPS с одной копией приложения это окно не убрать — его можно только сделать коротким и знать, когда оно кончилось. Для второго и нужна ручка готовности вместе с пробой в описании стека: «контейнер запущен» и «сервис отвечает» — разные события, и выкат заканчивается на втором.

Старые образы копятся и занимают заметное место, но чистка — не действие момента аварии. При пересборке новый образ получает то же имя, и прежний остаётся без тега, то есть для команды чистки он мусор: после неё откатываться уже не на что.

«Откатимся» — самое частое предложение в первые минуты аварии, и почти всегда оно означает «вернуть прежний образ». С образом это и правда просто: он неизменяемый, лежит под своим тегом, и выкат прежнего тега — обычный выкат. Проблема в том, что образ — единственная часть стека, которая так умеет.

Схема назад не ходит. Миграция уже применена, и если она была расширяющей — добавила колонку, добавила таблицу, — прежний код на новой схеме работает: он про новое просто не знает. Если она что-то убрала или переименовала, прежний код на ней падает, и откат образа делает только хуже. Поэтому шаги схемы и разбиваются на выпуски: не ради красоты, а чтобы у отката оставалась хоть одна рабочая пара «код плюс схема».

Копия базы — тоже не откат, а возврат в прошлое: всё, что произошло после дампа, исчезает. Восстановление уместно там, где данные испорчены, и неуместно там, где просто выкатили плохой код: во втором случае дешевле выпуск вперёд.

А есть и то, чего восстановление не возвращает вовсе, потому что оно не в базе, — состояние клиентов. Прогноз: сервер синхронизации поднят из ночного дампа, в котором были только две первые операции. Телефон помнит курсор, взятый до аварии. Что он заберёт при следующем обращении?

type Fields = Record<string, string | number>;
type Op = { opId: string; rowId: string; fields: Fields; at: number };
type Entry = Op & { seq: number };
type Verdict = { opId: string; status: "applied" | "duplicate" | "rejected"; reason?: string };
type Page = { changes: Entry[]; cursor: number; hasMore: boolean };
interface Connection {
  push(batch: Op[]): Promise<{ verdicts: Verdict[] }>;
  pull(cursor: number, limit: number): Promise<Page>;
}
interface Server {
  as(user: string): Connection;
}
declare function createServer(): Server;

const op = (opId: string, exercise: string): Op => ({ opId, rowId: "r-" + opId, fields: { exercise }, at: 0 });
const имена = (page: Page): string => page.changes.map((entry) => String(entry.fields.exercise)).join(", ") || "ничего";

async function main(): Promise<void> {
  // до аварии: три подхода, телефон забрал все три и запомнил курсор
  const живой = createServer().as("u1");
  await живой.push([op("o-1", "жим")]);
  await живой.push([op("o-2", "присед")]);
  await живой.push([op("o-3", "тяга")]);
  const было = await живой.pull(0, 10);
  console.log(`телефон забрал: ${имена(было)} | курсор ${было.cursor}`);

  // сервер поднят из ночного дампа: в нём только два первых подхода
  const копия = createServer().as("u1");
  await копия.push([op("o-1", "жим")]);
  await копия.push([op("o-2", "присед")]);
  // и человек записал новый подход уже после восстановления
  await копия.push([op("o-4", "выпады")]);
  console.log(`в журнале после восстановления: ${имена(await копия.pull(0, 10))}`);
  console.log(`телефон с прежним курсором ${было.cursor} забрал: ${имена(await копия.pull(было.cursor, 10))}`);
}

main();

На живой базе дыра между откатившимся счётчиком и курсором телефона — не одна запись: сколько номеров человек сжёг после того, как дамп был снят, столько новых правок и пропадёт молча.

-- регламент восстановления: сдвинуть счётчик за любой номер, который уже выдавался
update sync_heads set seq = seq + 1000000;

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

Отсюда правило: в аварии откат — это выпуск вперёд. Прежний тег образа годится как способ выиграть время, но починка почти всегда оказывается новым выпуском, а не возвратом.

Когда прод лежит, соблазн один: открыть журнал и читать его сверху вниз. Это худший способ потратить первые десять минут. Вопросов всего три, и они идут по порядку: что именно сломано, с какого момента, что менялось до этого момента. Первый отвечает состояние контейнеров, второй и третий — журнал.

Собирать картину по сквозному номеру запроса вы уже умеете: сводка по запросам даёт число отказов, причину и маршруты, а одна причина на двух маршрутах значит, что сломалась общая зависимость. Здесь нужен следующий шаг — момент начала. И на нём легко обмануться, потому что самая заметная ошибка редко бывает первой.

Прогноз: в журнале десять записей от двух контейнеров, и в файле они не по времени. Какая ошибка окажется самой частой, какая — первой и что стояло в журнале перед ней?

// Журнал за минуты инцидента, слитый из двух контейнеров, — поэтому строки
// в файле не по времени. Ищем первую ошибку и самую частую.
const журнал = [
  '{"t":"09:12:33.014","level":"error","msg":"база не ответила","code":"ECONNREFUSED","requestId":"r-12"}',
  '{"t":"09:12:02.880","level":"info","msg":"слушаю","port":8000,"version":"1.4.0"}',
  '{"t":"09:12:41.507","level":"error","msg":"база не ответила","code":"ECONNREFUSED","requestId":"r-16"}',
  '{"t":"09:12:18.233","level":"info","msg":"ответ","status":200,"requestId":"r-9"}',
  '{"t":"09:12:31.902","level":"error","msg":"нет свободного соединения","code":"POOL_TIMEOUT","requestId":"r-11"}',
  '{"t":"09:12:52.140","level":"error","msg":"база не ответила","code":"ECONNREFUSED","requestId":"r-18"}',
  '{"t":"09:12:09.611","level":"info","msg":"ответ","status":200,"requestId":"r-7"}',
  '{"t":"09:13:04.775","level":"error","msg":"база не ответила","code":"ECONNREFUSED","requestId":"r-21"}',
  '{"t":"09:12:36.480","level":"error","msg":"база не ответила","code":"ECONNREFUSED","requestId":"r-14"}',
  '{"t":"09:14:10.006","level":"info","msg":"слушаю","port":8000,"version":"1.4.1"}',
];

const события = журнал.map((строка) => JSON.parse(строка)).sort((а, б) => (а.t < б.t ? -1 : 1));
const ошибки = события.filter((е) => е.level === "error");

const счёт = new Map();
for (const е of ошибки) счёт.set(е.msg, (счёт.get(е.msg) ?? 0) + 1);
const частая = [...счёт].sort((а, б) => б[1] - а[1])[0];

const первая = ошибки[0];
const запуски = события.filter((е) => е.msg === "слушаю" && е.t < первая.t);
const последний = запуски.at(-1);
const секунд = Math.round((Date.parse(`2026-09-28T${первая.t}Z`) - Date.parse(`2026-09-28T${последний.t}Z`)) / 1000);

console.log(`записей ${события.length}, из них ошибок ${ошибки.length}`);
console.log(`самая частая: ${частая[0]} (${частая[1]})`);
console.log(`первая по времени: ${первая.t} ${первая.msg}`);
console.log(`последний запуск до неё: ${последний.t}, версия ${последний.version}`);
console.log(`между запуском и первой ошибкой: ${секунд} с`);

Самая частая ошибка — «база не ответила», пять раз из шести, и починка началась бы с неё. Первая по времени другая: свободные соединения в пуле кончились раньше, чем база стала отказывать в новых. Порядок здесь и есть подсказка: сначала уже открытые соединения перестали отвечать и заняли весь пул, и только потом попытки открыть новое начали получать отказ. Смотреть надо на первую строку — она ближе всего к событию, которого в журнале приложения может не быть вовсе.

Вторая половина ответа — строка перед первой ошибкой. Последний запуск приложения случился за двадцать девять секунд до неё, и версия в нём новая. Это не доказательство вины выката, но это первое, что проверяют: совпадение по времени с выкатом сужает поиск до одного набора изменений. Если же ближайший выкат был три дня назад, искать надо не в коде, а в том, что менялось снаружи, — в объёме данных, в диске, в чужом сервисе.

Сортировка по строковому времени работает, только если время в журнале записано в UTC и с ведущими нулями. Смешанные часовые пояса от двух машин превращают «первую ошибку» в лотерею.

Первый вопрос — «что именно сломано» — отвечает список контейнеров. Отвечает он, впрочем, ровно на то, о чём спросили: по умолчанию список показывает работающие контейнеры — в том числе те, что крутятся в перезапуске, — а вышедшую одноразовую работу только с флагом -a. Ровно на этом и строится самая частая ошибка разбора.

Прогноз: пять сервисов, у одного код выхода 1, у другого 137 и шесть перезапусков. Кого модель назовёт первым подозреваемым в списке без -a и кого — в полном?

// Состояние сервисов так, как его отдаёт список контейнеров: имя, состояние,
// здоровье, код выхода, число перезапусков. Список без -a показывает только
// то, что сейчас существует и не вышло.
const все = [
  { имя: "postgres", состояние: "running", здоровье: "healthy", код: null, перезапусков: 0 },
  { имя: "migrate", состояние: "exited", здоровье: null, код: 1, перезапусков: 0 },
  { имя: "api", состояние: "restarting", здоровье: "unhealthy", код: 137, перезапусков: 6 },
  { имя: "web", состояние: "running", здоровье: "healthy", код: null, перезапусков: 0 },
  { имя: "caddy", состояние: "running", здоровье: null, код: null, перезапусков: 0 },
];
const без_a = все.filter((с) => с.состояние !== "exited");

const вес = (с) => {
  if (с.состояние === "exited" && с.код !== 0) return 3;
  if (с.перезапусков > 0) return 2;
  if (с.здоровье === "unhealthy") return 1;
  return 0;
};
const причина = (с) =>
  с.состояние === "exited"
    ? `одноразовая работа вышла с кодом ${с.код}`
    : с.код === 137
      ? `убит сигналом ${с.код - 128}, перезапусков ${с.перезапусков}`
      : `${с.состояние}, здоровье ${с.здоровье}`;

for (const список of [без_a, все]) {
  const подозреваемые = список.filter((с) => вес(с) > 0).sort((а, б) => вес(б) - вес(а));
  console.log(`видно сервисов: ${список.length}`);
  for (const с of подозреваемые) console.log(`  ${с.имя}: ${причина(с)}`);
  console.log(`  первый подозреваемый: ${подозреваемые[0].имя}`);
}

В коротком списке виноват api: он не может стартовать, его перезапускают, он снова падает, а код 137 уводит разбор в память машины. В полном списке первым оказывается migrate: одноразовая работа вышла с кодом 1, то есть миграция не применилась и схема осталась прежней. Её журнал читают первым: строк там немного, и они отвечают, доехал ли выкат до конца. Память и шесть перезапусков api — вопрос второй, и пока не прочитан первый, чинить начинают не то.

Дальше — журнал, и его берут не целиком. Окно задаётся флагом «с какого момента» (--since 20m или отметка времени), последние строки — флагом числа строк, а отметки времени включаются отдельно: контейнер печатает свои, а не время получения. Полезное упражнение — выписать окно инцидента из предыдущего раздела и взять журнал ровно по нему: всё остальное только мешает.

Код 137 — это 128 плюс 9. Так же читаются и остальные: 143 — это сигнал 15, то есть штатная остановка, а вовсе не авария.