Įsivaizduokite, kad turite kritinę paslaugą, kurią palaiko jūsų komanda, ir ji priklauso nuo kitos komandos API. Kai kuriais momentais, paslauga pradeda grąžinti klaidą 500 ir klientai skundžiasi. Ką darytumėte?

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