Проверки снаружи важнее графиков внутри

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

Почему локальные проверки врут

Проверка «с той же машины, по loopback» проходит мимо входного фильтра, балансировщика и вообще любого сетевого уровня, который может отказать. Мы поменяли правила файрвола и дропнули входящий трафик на нужный порт — для всех, кроме lo.

nft list ruleset | grep -A2 'hook input'
ss -lntp | grep -E ':(80|443)\b'
curl -sS -o /dev/null -w '%{http_code}\n' https://example.org/healthz

Все три проверки нужны вместе: первая показывает правила, вторая — что процесс слушает, третья — что снаружи действительно отвечают.

Какие проверки ставить

1. Снаружи, минимум из двух сетей. Одна точка не отличает «наш сервис лежит» от «у проверяющего сломан маршрут».
2. По имени, а не по IP. Иначе не проверяется DNS и сертификат.
3. С проверкой содержимого. Ответ 200 с текстом ошибки — тоже отказ; сверяйте маркер в теле.
4. С контролем сертификата. Отдельная проверка на срок действия — за 14 и за 3 дня.

Внутренние метрики отвечают на вопрос «как работает процесс». На вопрос «работает ли сервис» отвечает только запрос снаружи.

Что добавили после

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

Что бы сделал иначе

• Не считал бы «процесс запущен» проверкой доступности.
• Любое изменение фильтра — с последующим внешним запросом, а не только с просмотром правил.
• Держал бы отдельный чек-лист «что должно быть закрыто снаружи»: служебные порты не должны быть доступны, и это тоже стоит проверять автоматически.

← На главную · Архив