Приходит разработчик и говорит, что приложение недоступно, что будешь смотреть

Первичные действия: оценка ситуации и сбор контекста

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

• Какое именно приложение недоступно (его имя, компонент, сервис)
• Как проявляется недоступность (полностью не отвечает, ошибка 5xx, таймауты, частичная деградация)
• Когда началась проблема и были ли недавние изменения (деплои, обновления конфигураций, скейлинг)
• Кто ещё затронут (только один разработчик, вся команда, все пользователи)
• Как проверялась доступность (браузер, curl, внутренние инструменты)

Это помогает отличить локальную проблему разработчика от системного инцидента.

Базовые проверки: быстрая диагностика

Я начну с быстрых проверок по принципу «от простого к сложному», чтобы отсечь очевидные причины.

1. Проверка здоровья инфраструктуры

# Проверка состояния кластера/хостов
kubectl get nodes  # Если используем Kubernetes
kubectl get pods -n <namespace> --field-selector=status.phase!=Running

# Или для традиционных серверов
ssh <app-host> "uptime; systemctl status <service-name>"

2. Анализ доступности сервиса

# Проверка доступности эндпоинтов
curl -v -o /dev/null -s -w "HTTP: %{http_code}\nTime: %{time_total}s\n" https://app.example.com/health

# Проверка DNS
dig app.example.com +short
nslookup app.example.com

3. Мониторинг и метрики

Смотрю в системы мониторинга (Prometheus, Grafana, Datadog):

• Загрузка CPU/памяти на нодах с приложением
• Латентность и error rate сервиса
• Статус коды ответов (5xx резко выросли?)
• Пропускная способность сети
• Лимиты ресурсов в Kubernetes (OOMKilled, CPU throttling)

# Пример запроса в Prometheus для проверки ошибок
rate(http_requests_total{status=~"5..", service="myapp"}[5m])

Углублённая диагностика

Если базовые проверки не выявили проблему, перехожу к более детальному анализу.

1. Логи приложения

# Просмотр последних логов с критическими ошибками
kubectl logs -n production deployment/myapp --tail=100 --timestamps | grep -E "(ERROR|FAIL|exception|panic)"

# Или через централизованный сбор логов (ELK/Loki)
logcli query '{app="myapp"} |~ ".*(error|timeout).*"' --limit=20 --since=15m

2. Зависимости и внешние сервисы

Проверяю доступность зависимостей:

• Базы данных (PostgreSQL, MongoDB, Redis)
• Очереди сообщений (Kafka, RabbitMQ)
• Внешние API и микросервисы
• Кэши и CDN

# Проверка подключения к БД
nc -zv db-host 5432
pg_isready -h db-host

# Проверка Redis
redis-cli -h redis-host ping

3. Конфигурация и деплой

• Сравниваю текущую конфигурацию с предыдущей рабочей версией
• Проверяю deployment history на предмет проблемных релизов
• Анализирую ConfigMaps/Secrets на корректность
• Проверяю состояние миграций БД

# Просмотр истории деплоев
kubectl rollout history deployment/myapp

# Проверка различий конфигураций
diff <(kubectl get configmap app-config -o yaml) <(git show HEAD:configs/app-config.yaml)

4. Сетевые проблемы

Использую сетевые инструменты для диагностики:

# Проверка сетевой связности
traceroute app.example.com
mtr app.example.com

# Проверка правил firewall
iptables -L -n -v | grep <app-port>

# Анализ сетевых подключений приложения
kubectl exec -n production deployment/myapp -- netstat -tulpn | grep LISTEN

Если проблема неочевидна

В сложных случаях применяю следующие подходы:

1. Временный бэкап — если проблема появилась после изменений, делаю откат к предыдущей стабильной версии
2. Увеличение детализации логов — временно включаю debug-логинг
3. Профилирование приложения — анализирую использование CPU/памяти с помощью pprof или аналогичных инструментов
4. Трассировка запросов — смотрю полный путь запроса через Jaeger/Tempo для выявления узких мест
5. Тестирование в изоляции — проверяю воспроизводимость проблемы на тестовом стенде

Коммуникация и документация

Во время всей диагностики я:

• Держу в курсе разработчика о ходе расследования
• Документирую находки в тикете инцидента
• Создаю постмортем для сложных случаев с планом предотвращения
• Обновляю runbooks и чеклисты диагностики на будущее

Ключевой принцип — системный подход: не прыгать на первое предположение, а методично проверять все компоненты, влияющие на доступность приложения, от инфраструктуры до кода.