MLOps Path

2.1.2 · блок 2

Сеть и диагностика

Сеть и диагностика

Зачем это нужно

ML-сервис редко работает изолированно: он принимает HTTP-запросы, ходит в базу за фичами, тянет модель из S3. Когда «что-то не работает», нужно понять: проблема в коде, в сети или в соседнем сервисе? Базовая сетевая грамотность экономит часы дебага.

Вы не обязаны стать сетевым инженером, но должны уметь ответить: «порт слушается?», «DNS резолвится?», «HTTP возвращает 200 или 503?», «что в логах?».

Основные идеи

IP и порты. Каждый сервер имеет IP-адрес (например, 10.0.1.42). Сервис слушает *порт* — число от 1 до 65535. HTTP обычно на порту 80 (или 443 для HTTPS). ML inference API часто на 8080 или 8000.


ss -tlnp                    # какие порты слушаются (современная замена netstat)
curl http://localhost:8080/health   # запрос к локальному сервису

DNS — система имён. scoring.api.company.com → IP. Если DNS не работает, curl по hostname падает, по IP — работает.


nslookup scoring.api.company.com
dig scoring.api.company.com

curl — швейцарский нож HTTP:


curl -v http://localhost:8080/predict -H "Content-Type: application/json" -d '{"features": [1,2,3]}'
curl -I https://api.example.com/health    # только заголовки
curl -w "%{http_code} %{time_total}s\n" -o /dev/null -s http://localhost:8080/health

Флаги: -v verbose, -H заголовок, -d тело POST, -w формат вывода метрик.

Логи. Приложение пишет в stdout/stderr или в файл. На Linux с systemd журнал централизован:


journalctl -u scoring-service -n 100      # последние 100 строк сервиса
journalctl -u scoring-service -f            # follow (как tail -f)
journalctl -u scoring-service --since "1 hour ago"
journalctl -u scoring-service -p err      # только ошибки

Файловые логи:


tail -n 50 /var/log/scoring/app.log
grep "ERROR" /var/log/scoring/app.log | tail -20

Типовая схема диагностики:

1. Сервис отвечает локально (curl localhost)? → если да, проблема снаружи (firewall, load balancer).

2. Процесс запущен (ss -tlnp)?

3. Что в логах (journalctl)?

4. Доступен ли upstream (БД, S3)?

Как это выглядит на практике

QA сообщает: POST /predict возвращает 502. MLE на staging-сервере:


# Шаг 1: жив ли процесс?
ss -tlnp | grep 8080

# Шаг 2: локальный запрос
curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8080/health
# → 503

# Шаг 3: логи
journalctl -u scoring-service -n 30 --no-pager
# → "Connection refused to postgres:5432"

# Шаг 4: проверка БД
nc -zv postgres.internal 5432
# → Connection refused → задача для DBA, Incident в Jira

Runbook в Confluence содержит именно эту цепочку — on-call не импровизирует.

Что сделать после занятия

Официальные материалы

Открыть интерактивную версию