Проверить сетевую доступность рабочей станцииПеремещён
Прежде чем диагностировать сервер, убедиться, что маршрут до него существует.
curl -s -o /dev/null -w '%{http_code}\n' https://github.comПроверить работоспособность системы мониторингаПеремещён
Открыть status.equiply.ru. При её отказе в Telegram поступает отдельное оповещение от watchdog.
curl -s -o /dev/null -w '%{http_code}\n' https://status.equiply.ruПроверить сервис из второй точкиРекомендуетсяПеремещён
Мониторинг наблюдает мир из одной точки. Рабочая станция — вторая независимая.
curl -sS -o /dev/null -w 'код %{http_code}, время %{time_total}s\n' https://ДОМЕНОпределить масштаб по заголовку оповещенияПеремещён
Заголовок содержит ответ: «netcup: не отвечают 3 из 16 сайтов» либо «ttinv.ru не отвечает».
Уточнить состав сервера по рееструРекомендуетсяПеремещён
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']]"Определить репозиторий по доменуПеремещён
Задача уже создана в репозитории затронутого проекта, в её тексте перечислено всё семейство.
repo-for --all ДОМЕНПодключиться по SSHПеремещён
Параметры доступа находятся в ~/.ssh/config и порождаются из реестра серверов.
ssh netcup # либо servicest4, braveДействия при недоступности SSHОпциональноПеремещён
Остаётся панель управления хостингом и перезагрузка. Ссылки на панели в реестре ОТСУТСТВУЮТ — известный пробел.
Выявить нездоровые контейнерыПеремещён
docker ps --format '{{.Names}}\t{{.Status}}' | grep -v healthyИзучить журнал отказавшего контейнераПеремещён
docker logs --tail 200 --timestamps КОНТЕЙНЕР 2>&1 | tail -60Проверить дисковое пространство и памятьРекомендуетсяПеремещён
df -h / && free -m && docker system dfПроверить связь с недавним развёртываниемРекомендуетсяПеремещён
docker ps --format '{{.Names}}\t{{.RunningFor}}' | sort -k2Перезапустить сервисОпциональноПеремещён
Наименее затратное действие, если причина в зависшем процессе, а не в коде.
docker compose restart СЕРВИСВнести исправление в кодОпциональноПеремещён
Исправить в локальной копии, отправить в main. Развёртывание выполняется автоматически.
Дождаться оповещения о восстановленииПеремещён
Мониторинг фиксирует восстановление и направляет отдельное сообщение.
Закрыть задачу с указанием причиныПеремещён
В том репозитории, где она создана. Указать установленную причину и выполненные действия.
gh issue close НОМЕР -R mikey-semy/РЕПОЗИТОРИЙ -c 'причина: … ; выполнено: …'**Когда применять.** Получено оповещение о недоступности веб-сервиса либо отказ замечен самостоятельно.Удалён
**Когда применять.** Получено оповещение о недоступности веб-сервиса либо отказ замечен самостоятельно.
Порядок построен так, чтобы каждый шаг **отсекал целый класс причин**, а не проверял наугад. Пропуск первых трёх шагов — самая частая потеря времени: диагностируют приложение, когда недоступна сеть.
**Масштаб определяет объект восстановления.** Один домен — восстанавливается приложение. Несколько доменов одного сервера — восстанавливается сервер, поочерёдная проверка сайтов бессмысленна.Удалён
**Масштаб определяет объект восстановления.** Один домен — восстанавливается приложение. Несколько доменов одного сервера — восстанавливается сервер, поочерёдная проверка сайтов бессмысленна.
**Дальнейшие действия принимает человек.** Ниже перечислено допустимое, а не предписанное. Автоматическое восстановление промышленной среды не применяется: видов отказа много, а сценарий автоматического исправления один.Удалён
**Дальнейшие действия принимает человек.** Ниже перечислено допустимое, а не предписанное. Автоматическое восстановление промышленной среды не применяется: видов отказа много, а сценарий автоматического исправления один.
**Не реализовано на текущий момент** — перечень приводится намеренно:Удалён
**Не реализовано на текущий момент** — перечень приводится намеренно:
- ссылки на панели управления хостингом для случая недоступности SSH
- учёт ложных срабатываний: каждое падение считается новым
- окно тишины на время развёртывания — собственное изменение способно вызвать оповещение
- приоритет по владельцу: простой клиентского сервиса равнозначен собственному
Пересмотр — после месяца эксплуатации. Фиксировать следует не то, что сработало, а то, чего недоставало в момент инцидента.