Что делать если сервер упал
Что проверяют
Понимаете ли приоритеты в инциденте: сначала вернуть сервис, потом искать причину. Знаете ли, от чего падает именно процесс на Go, и догадаетесь ли сначала подтвердить сам факт падения.
Как отвечать
По шагам, вслух проговаривая порядок.
- Подтвердить и очертить: лежит один инстанс или все, весь сервис или часть ручек, что видно снаружи и что в метриках. Ошибка у клиента может прилетать от балансировщика при живом приложении.
- Восстановить: вывести инстанс из балансировки, откатить последний релиз или изменение конфигурации, включить деградацию. Откат быстрее поиска причины и разбору не мешает.
- Сохранить улики до перезапуска: логи, стектрейс паники, дамп памяти, значения метрик на момент падения. После рестарта контейнера их уже не будет.
- Только потом искать причину и чинить.
Что валит процесс на Go: паника в любой горутине, а не только в обработчике, причём recover в middleware чужую горутину не спасает; нехватка памяти от неограниченного чтения тела запроса, когда процесс убивает ядро и в логах приложения при этом пусто; запись в nil map, выход за границы, закрытие закрытого канала. Отдельно стоит отличать «упал» от «висит»: исчерпанный пул соединений и дедлок выглядят снаружи похоже.
Профилактика: таймауты на HTTP-сервере, ограничение размера тела, корректное завершение по сигналу, перезапуск супервизором, проба живости и алерт на частые рестарты.
Где спотыкаются
Начинают расследование на живом проде, пока пользователи лежат. В инциденте первым идёт восстановление любой ценой, вплоть до отката на заведомо рабочую старую версию, а разбор причины наступает уже после.
Перезапускают и теряют данные для разбора. Причина остаётся неизвестной, и падение повторяется через сутки в том же месте.
Отвечают только про инфраструктуру и названия систем мониторинга. На позиции разработчика ждут конкретики про панику в горутине, нехватку памяти и таймауты, то есть про то, что чинится в коде.