Начинаем неделю с полезных рекомендаций.
⚪️ Начинай с логов
Логи — первый шаг к разгадке. Освой фильтры и поиск, чтобы найти ключ к проблеме. Пример: сайт упал, а пользователи жалуются на 500-ю ошибку. Открываешь логи через
kubectl logs pod-name | grep "error" и видишь, что база данных не отвечает.⚪️ Отследи путь запроса
Пойми, как запрос идёт через систему — это ускорит поиск узкого места.
Пример: клиент говорит, что страница грузится 10 секунд. Используешь
Jaeger или curl -v, чтобы понять: запрос застревает на API из-за медленного ответа внешнего сервиса.⚪️ Действуй методом исключения
Проверяй компоненты по очереди, чтобы найти причину без лишних догадок. Пример: приложение не запускается. Проверяешь: Docker-контейнер жив (
docker ps), сеть пингуется (ping db), но env переменная не передана — вот и косяк.⚪️ Разберись, где сбой: инфраструктура или код
Сервер кривой, сеть тормозит или код глючит? Понимание сути экономит время. Пример: сервис выдаёт тайм-ауты.
netstat -tuln показывает, что порт открыт, но в коде забыли закрыть соединение с Redis — баг разработчиков.⚪️ Проверь внешние сервисы
Если зависишь от API, баз или сторонних инструментов — убедись, что они работают. Пример: пуш-уведомления не уходят. Заходишь на статусную страницу Firebase (
status.firebase.google.com) — там outage, и ты понимаешь, что дело не в коде.⚪️ Контролируй ресурсы системы
Память, процессор или диск на пределе? Это спасает от скрытых сбоев.
Пример: сервер стал отвечать медленно. htop показывает 95% CPU из-за утечки памяти в Node.js-приложении — пора рестартить и чинить.
⚪️ Повтори баг на тесте
Сможешь воспроизвести проблему в тестовой среде — разберёшься быстрее. Пример: юзеры видят "
Access Denied". В тестовой среде меняешь роль в IAM-политике AWS и видишь ту же ошибку — проблема в правах доступа.⚪️ Веди список известных ошибок
Если что-то ломается регулярно, запиши решение — не трать время заново. Пример: Kubernetes-кластер падает из-за OOM. Пишешь: "Увеличить лимит до 2Gi в
resources.limits.memory" — в следующий раз решишь за минуту.⚪️ Настрой проверки здоровья
Грамотные liveness и readiness-пробы ловят сбои заранее. Пример: поды перезапускаются без причины. Добавляешь
livenessProbe: httpGet /health на 8080 порт — Kubernetes видит, что сервис жив, и перезапусков нет.⚪️ Не тяни с помощью
Проверил всё очевидное, а решения нет? Зови коллег или эскалируй. Пример: деплой висит 2 часа, логи чистые, ресурсы в норме. Пишешь в Slack: "Ребят, SOS с CI/CD" — и Senior DevOps подсказывает, что GitLab Runner завис.
@DevOpsKaz 😛