🧙 Садовник: уточнил шаги, добавил проверки и обоснования. Примите, если полезно.
#1Итог · станет v2
1
Проверить сетевую доступность рабочей станции
Прежде чем диагностировать сервер, убедиться, что маршрут до него существует.
Зачем: Обрыв связи у рабочей станции внешне неотличим от отказа сервера. Диагностика и устранение при этом принципиально разные.
$
curl -s -o /dev/null -w '%{http_code}\n' https://github.com- –Код 200 — связь есть, продолжать
- –Пустой ответ — устранять связь, сервер ни при чём
2
Проверить работоспособность системы мониторинга
Открыть status.equiply.ru. При её отказе в Telegram поступает отдельное оповещение от watchdog.
Зачем: uptime-kuma и ntfy размещены на одном сервере. При его отказе замолкают оба, и отсутствие оповещений становится неотличимо от штатной работы.
$
curl -s -o /dev/null -w '%{http_code}\n' https://status.equiply.ru- –Мониторинг отвечает — оповещению можно доверять
- –Не отвечает — наблюдение за сайтами прекращено, это самостоятельный инцидент
3
Проверить сервис из второй точкиРекомендуется
Мониторинг наблюдает мир из одной точки. Рабочая станция — вторая независимая.
Зачем: Недоступность сервиса и недоступность маршрута от сервера мониторинга — разные инциденты, требующие разных действий.
$
curl -sS -o /dev/null -w 'код %{http_code}, время %{time_total}s\n' https://ДОМЕН- –Результат совпал с оповещением — отказ подтверждён
- –Сервис открывается — проверять маршрут от мониторинга, а не сервис
4
Определить масштаб по заголовку оповещения
Заголовок содержит ответ: «netcup: не отвечают 3 из 16 сайтов» либо «ttinv.ru не отвечает».
Зачем: Группировка по серверу введена именно для этого: при отказе netcup недоступны четырнадцать доменов, и четырнадцать раздельных оповещений скрыли бы существо инцидента.
- –Указан сервер — переходить к серверу
- –Указан домен — переходить к его проекту
5
Уточнить состав сервера по рееструРекомендуется
Зачем: Работоспособность соседних сервисов исключает отказ сервера целиком и вдвое сужает область поиска.
$
python3 -c "import yaml,pathlib; d=yaml.safe_load(pathlib.Path('/home/mike/Projects/arch-hq/registry/servers.yml').read_text()); [print(s['name'], [x['host'] for x in (s.get('sites') or [])]) for s in d['servers']]"6
Определить репозиторий по домену
Задача уже создана в репозитории затронутого проекта, в её тексте перечислено всё семейство.
Зачем: Домену соответствует несколько репозиториев: devon-pro — три, setfork — шесть. Без полного перечня отказ серверной части ищут в клиентской.
$
repo-for --all ДОМЕН- –Возвращён arch-hq — репозиторий не установлен, диагностика только по логам
7
Подключиться по SSH
Параметры доступа находятся в ~/.ssh/config и порождаются из реестра серверов.
Зачем: Ключи и конфигурация подготовлены заранее — поиск доступов во время инцидента исключён.
$
ssh netcup # либо servicest4, brave- –Подключение не устанавливается — перейти к шагу о недоступности сервера
8
Действия при недоступности SSHОпционально
Остаётся панель управления хостингом и перезагрузка. Ссылки на панели в реестре ОТСУТСТВУЮТ — известный пробел.
Зачем: Перезагрузка — крайняя мера: она уничтожает состояние, по которому устанавливается причина. Применять после исчерпания остальных способов.
Здесь нужен человек: Это зависит от реального опыта — добавьте свой.
9
Выявить нездоровые контейнеры
Зачем: Контейнер может находиться в состоянии Up и при этом не обслуживать запросы; признак healthy эту разницу показывает.
$
docker ps --format '{{.Names}}\t{{.Status}}' | grep -v healthy- –Контейнер отсутствует в выводе — он не запущен, проверить docker ps -a
10
Изучить журнал отказавшего контейнера
Зачем: Причина отказа фиксируется в конце журнала; начало занято загрузкой зависимостей.
$
docker logs --tail 200 --timestamps КОНТЕЙНЕР 2>&1 | tail -60- –Искать строки error, failed, denied, exit code
- –Журнал пуст — проверить docker inspect КОНТЕЙНЕР --format '{{.State}}'
11
Проверить дисковое пространство и памятьРекомендуется
Зачем: Значительная доля отказов без очевидной причины вызвана исчерпанием дискового пространства. Проверка обходится дешевле построения гипотез.
$
df -h / && free -m && docker system df- –Свободно менее 10% — причина установлена
12
Проверить связь с недавним развёртываниемРекомендуется
Зачем: Первый вопрос при отказе — не вызван ли он последним изменением. Недавно запущенный контейнер отвечает на него немедленно.
$
docker ps --format '{{.Names}}\t{{.RunningFor}}' | sort -k213
Перезапустить сервисОпционально
Наименее затратное действие, если причина в зависшем процессе, а не в коде.
Зачем: Тома с кэшами сохраняются при перезапуске и уничтожаются при пересоздании.
Здесь нужен человек: Это зависит от реального опыта — добавьте свой.
$
docker compose restart СЕРВИС- –НЕ применять docker compose down — приводит к потере томов и кэшей
- –НЕ применять docker system prune без фильтра
14
Внести исправление в кодОпционально
Исправить в локальной копии, отправить в main. Развёртывание выполняется автоматически.
Зачем: Правка непосредственно на сервере утрачивается при следующем развёртывании и не попадает в историю изменений.
Здесь нужен человек: Это зависит от реального опыта — добавьте свой.
15
Дождаться оповещения о восстановлении
Мониторинг фиксирует восстановление и направляет отдельное сообщение.
Зачем: Без подтверждения возможно продолжение работ над сервисом, восстановившимся самостоятельно, и ошибочное отнесение результата к принятым мерам.
- –Оповещение не поступило в течение 5 минут — проверить сервис вручную
16
Закрыть задачу с указанием причины
В том репозитории, где она создана. Указать установленную причину и выполненные действия.
Зачем: Закрытые задачи образуют статистику отказов. По ней через месяц видно, какие отказы повторяются, — а это и определяет, что подлежит исправлению в первую очередь.
$
gh issue close НОМЕР -R mikey-semy/РЕПОЗИТОРИЙ -c 'причина: … ; выполнено: …'