Iedomājieties, ka jums ir kritiska pakalpojums, ko jūsu komanda uztur, un tas ir atkarīgs no citas komandas API. Kādu brīdi pakalpojums sāk atgriezt kļūdu 500, un klienti sūdzas. Ko jūs darītu?

1. Проверка логов сервиса. Изучение логов поможет выявить специфику ошибки, время её возникновения и возможные трассировки стека.
2. Мониторинг метрик сервиса. Проверка графиков нагрузки, потребления ресурсов (CPU, RAM), количества запросов и ошибок. Это позволит понять масштаб проблемы и её динамику.
3. Проверка доступности и метрик зависимого API. Используем инструменты мониторинга для проверки состояния API другой команды. Смотрим метрики количества ошибок, задержки ответов и общую доступность.
4. Проверка сетевой доступности. Удостоверимся, что сервис может установить соединение с API.
5. Проверка контракта API. Убедиться, что форма запросов и ответов соответствует ожидаемой. Возможно, другая команда внесла изменения.
6. Связь с командой, ответственной за API. Предоставить информацию о проблеме, логи, метрики. Координировать усилия по диагностике.
7. Анализ недавних изменений. Проверить, были ли какие-либо развертывания или изменения в инфраструктуре как нашего сервиса, так и зависимого API.
8. Поиск обходного решения. Пока команда API работает над исправлением, искать способы минимизировать влияние на клиентов, например, временное кеширование данных или использование fallback-логики.
9. Сообщение о проблеме заинтересованным сторонам. Информировать о ситуации руководство и другие команды/клиентов, которые могут быть затронуты.

Пример диагностики в логах:

// Поиск ошибок 500 в логах сервиса за последний час
grep "HTTP/1.1\" 500" /var/log/my_service/access*.log | tail

// Поиск конкретной ошибки в логах приложения
grep "upstream connect error or disconnect/reset before headers" /var/log/my_service/app.log

Пример проверки доступности API:

// Проверка доступности API с помощью cURL
curl -v -I https://api.other-team.com/some_endpoint