Представьте, что у вас есть критичный сервис, который поддерживает ваша команда, и он зависит от API другой команды. В какой-то момент сервис начинает возвращать ошибку 500, и клиенты жалуются. Что вы будете делать?

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