Networking

SRE без сетевого инструментария — наполовину слепой инженер. Половина инцидентов начинается на сетевом уровне: DNS, TLS, соседи по пирингу, сертификаты, mesh, балансировщик. И без умения читать рукопожатие, снимать дамп трафика и раскладывать сетевые события по времени диагностика превращается в гадание. Лист — про базовый набор: что читать, как снять дамп, какие симптомы различать с первой минуты инцидента. Соседи под L1 IT Infrastructure — Operating Systems, Containerization & Orchestration и Cloud Providers.

Что должен уметь

Главный навык на уровне L4 — снимать и читать дамп трафика. Когда curl отваливается по таймауту, это симптом, но не диагноз. Снять tcpdump, увидеть, что рукопожатие прошло, а подтверждения на первый пакет данных нет, — это уже сужает поиск до двух-трёх гипотез. Я регулярно вижу команды, где tcpdump знает один старший инженер, а остальные считают сетевые инциденты «магией балансировщика». Навык не требует года учёбы: достаточно один раз пройти зины Джулии Эванс и потом регулярно практиковаться.

Понимает базовую модель: TCP, IP, HTTP, DNS, TLS — что даёт каждый слой. Знает, что такое тройное рукопожатие, RST, ACK, ClientHello в TLS.
Пользуется ping, traceroute, dig и curl для базовой диагностики; читает их вывод и по симптому отличает недоступный хост от нерезолвящегося имени, упавшего рукопожатия TLS или отказа в соединении.

Снимает дамп (tcpdump, tshark, Wireshark) и читает основные события: рукопожатие, повторные передачи, RST, запоздалые подтверждения. Разбирает проблемы TCP через ss, netstat, iptables и nftables.
Понимает мультиплексирование в HTTP/2 и gRPC поверх него; знает, чем отличаются стратегии keep-alive и как они уживаются с таймаутами простоя в TCP.
Настраивает таймауты на всех слоях (подключение, чтение, запись, операция целиком); понимает связь с таймером повторной передачи в TCP и с keep-alive.

Проектирует устойчивость сети для сервиса: повторы с экспоненциальной выдержкой и разбросом, размыкатели цепи, таймауты на каждом слое, идемпотентность. Различает балансировку на уровне TCP и на уровне HTTP и знает, когда какая нужна.
Проектирует наблюдаемость сетевых границ: сквозная трассировка между сервисами, RED-метрики на каждом участке, бюджет задержки. Диагностирует DNS как часть приложения: поведение резолвера, кеширование, распространение записей.

L6+

Проектирует сетевую архитектуру сервиса или направления: ingress, разделение внутреннего и внешнего трафика, сетевые политики в k8s, несколько зон и регионов, service mesh там, где он оправдан. Понимает, во что обходится исходящий трафик.
Учит команду: разбирает сетевую диагностику на инцидентах как демонстрацию, гоняет «колесо неудач» по сетевым сценариям.

Материалы

Книги

W. Richard Stevens — TCP/IP Illustrated, Vol. 1: The Protocols (Addison-Wesley, 2-е изд., 2011). Канонический учебник по TCP/IP. Тяжёлый, но если хочется разобраться по-настоящему — это он.
Ilya Grigorik — High Performance Browser Networking (O’Reilly, 2-е изд., 2013). Бесплатно онлайн под лицензией CC. Современный стек с упором на производительность.
Andrew S. Tanenbaum, David J. Wetherall — Computer Networks (Pearson, 5-е изд., 2010). Теоретический фундамент, если нужна широта, а не только практика вокруг TCP/IP.

Статьи и доклады

Julia Evans — зин Bite Size Networking. Семнадцать сетевых инструментов Linux, по странице на каждый. По моим наблюдениям, самое доступное введение для дежурного — короче и понятнее большинства книг.
Cloudflare — Everything you ever wanted to know about UDP sockets. Внутренности сокетов UDP в Linux. Полезно тем, кто выходит за пределы HTTP.
Istio — What is a service mesh?. Каноническое определение service mesh — точка входа перед погружением.
Cloudflare 2019-07-02 incident report — публичный разбор сложного сетевого инцидента, см. ниже.
Мой разбор — Что происходит, когда ты открываешь сайт (jtprog.ru, июль 2026). Путь запроса от нажатия Enter до пикселя: кеши браузера, разрешение имени, Anycast и edge, рукопожатия TCP и TLS, версии протокола вплоть до QUIC, BGP между автономными системами и приём пакета на сервере. Grigorik заканчивает на стороне клиента, здесь дорога доведена до ядра и обратно.

Инструменты

Базовая диагностика — ping, traceroute, mtr, dig, nslookup, curl, wget. Должны лежать в каждом образе, из которого дежурный лезет разбираться.
Продвинутая диагностика — tcpdump, tshark, Wireshark, ss, netstat, iptables и nftables. Для разбора дампов и состояния сетевого стека ядра.
Трассировка через eBPF — bpftrace и bcc-tools: события TCP видно без тех накладных расходов, которые даёт tcpdump под нагрузкой. По моим наблюдениям, к 2026 это стандарт в командах с серьёзным сетевым трафиком.
Service mesh — Envoy (сам прокси), Istio (управление плюс Envoy), Linkerd (лёгкая альтернатива). Оправдан, когда нужны mTLS, управление трафиком и наблюдаемость на уровне HTTP без правок кода.

Best practices

Лучший публичный кейс сетевой сложности, который я знаю, — инцидент Cloudflare 2 июля 2019 года. Обычное правило в WAF с регулярным выражением привело к катастрофическому перебору в PCRE, процессор на пограничных узлах ушёл в полку, и весь трафик встал на 27 минут. Сетевой он только формально. Зато показывает, как сетевой слой — а WAF стоит ровно на пути запроса — становится источником системного отказа. Постмортем публичен и подробно разобран, и читать его стоит ради одного вывода: логика седьмого уровня на сетевом пути требует такой же осторожности, как код приложения. По моим наблюдениям, это лучший публичный разбор на тему «сетевая инфраструктура — это код, который тоже надо тестировать».

Таймауты ставятся на каждом слое, а не только на самом верхнем. Единый «пятьдесят секунд на всё» выглядит аккуратно ровно до момента, когда сервис под тобой висит сорок девять секунд, а ты всё это время честно держишь соединение и тянешь за собой всех, кто ждёт уже тебя. Рабочий набор: одна-три секунды на подключение, чтение и запись под реальный p99, общий потолок на всю операцию. Сетевой вызов без явного таймаута — это заготовка каскадного отказа, других вариантов у него нет.

Повтор разрешён только там, где операция идемпотентна, и только с экспоненциальной выдержкой и разбросом. Иначе получается шторм повторов: сбой прошёл, а все клиенты одновременно ломятся обратно и добивают сервис, который только начал вставать. Выдержка растягивает интервал. Разброс разносит попытки во времени. Без второго первое почти бесполезно: синхронные клиенты и повторяют синхронно.

Срок жизни TLS-сертификата — событие в календаре, а не сюрприз в три ночи. Инцидент «истёк сертификат» я до сих пор вижу регулярно, и каждый раз это диагноз не сертификату, а автоматизации. Мониторинг истечения с оповещением за 30, 14, 7 и 1 день, автоматическая ротация через cert-manager, Let’s Encrypt или Vault и runbook на случай, когда ротацию всё-таки придётся делать руками, — вот и весь набор, который закрывает этот класс инцидентов целиком.

DNS — часть приложения, а не «инфраструктура, которая просто работает». Позиция «DNS быстрый, мы его не мониторим» ломается на первом же инциденте: пять секунд на резолв кладут сервис ровно так же надёжно, как пять секунд ожидания базы. Кеширование на клиенте с учётом TTL, метрика времени резолва, алерт на проблемы резолвера — норма для прода, а не роскошь. И отдельная беда таких инцидентов в том, что отвечать за них некому: DNS живёт у инфраструктурной команды, а проявляется на продуктовых сервисах.

Circuit breaker нужен там, где сервис под тобой нестабилен. Бесконечное «попробуем ещё раз» убивает медленно. Разомкнуть цепь после N подряд ошибок и периодически проверять, ожил ли адресат, — это быстрый отказ вместо вязкой деградации, и особенно заметно это на вызовах через service mesh. Подробнее — в Resilience Patterns.

Сквозную трассировку на сетевых границах я считаю обязательной. Когда логи разбросаны по сервисам, дежурный собирает хронологию руками из шести разных grep, и половина времени уходит не на диагноз, а на склейку. Идентификатор трассы, проброшенный через каждый участок в заголовке HTTP или метаданных gRPC, восстанавливает путь запроса и точку отказа за секунды. Разница между «трассировка есть» и «трассировки нет» — это разница между десятью минутами и двумя часами до восстановления в распределённой системе.

Граница у листа простая: всё это про сеть, которой вы хоть как-то управляете. Если сервис живёт за чужим балансировщиком, чужим WAF и чужим резолвером, дамп трафика покажет симптом, но чинить его придётся не вам, а через заявку, и тогда полезнее не углубляться в стек, а заранее договориться, как быстро вы получаете ответ. Обратная сторона тоже есть: сетевой инструментарий соблазняет искать причину внизу, хотя в распределённых системах она чаще лежит в приложении — таймаут, который никто не выставил, или пул соединений, который кончился.

Связанные листья

SLI-based Alerting — задержка и доля ошибок в сети — основные SLI; качество алертов упирается в качество сетевого стека.
SLO Engineering — бюджет ошибок для сетевого слоя (доступность DNS, время рукопожатия TLS, связность между зонами) формулируется на той же модели.
Resilience Patterns — circuit breaker, повторы с выдержкой и разбросом, отсеки, таймауты на каждом слое — прямое пересечение с сетевой практикой.
Programming Languages — повторы, размыкатели и таймауты реализуются в коде; знание сетевых библиотек своего языка — половина практики устойчивости.
Incident Response — сетевые инциденты (DNS, TLS, пиринг, сертификаты, mesh) — отдельный класс со своим набором диагностических шагов.
Runbooks — runbook’и на типичные сетевые сценарии: истёк сертификат, лёг резолвер, заболел управляющий слой mesh.
Operating Systems — сетевой стек ядра и пространства имён — соседняя тема; границы пересекаются на tcpdump, ss, conntrack.
Containerization & Orchestration — плагины CNI, сетевые политики, kube-proxy и IPVS, контроллеры ingress — сетевой слой внутри k8s.
Service Mesh — прокси рядом с сервисом ради mTLS, перевода трафика и наблюдаемости на уровне HTTP — отдельная ось сетевой инфраструктуры со своим классом отказов.

Открытые вопросы

Resilience Patterns уже выделены в отдельный лист под Reliability Engineering. Граница: здесь про сеть как среду передачи, там — про архитектурные паттерны устойчивости.