Компьютерные сети
Мастер-класс: траблшутинг
Outage в 3 часа ночи. Мониторинг кричит. Пользователи жалуются. У вас 15 минут до эскалации. Как найти проблему быстро, а не гадать?
- **GitHub** в 2018 году лежал 24 часа из-за split-brain в базе данных. Быстрая диагностика сетевого partition'а могла сократить даунтайм.
- **Cloudflare** в 2020 имел глобальный outage из-за неправильного BGP анонса. Правильный troubleshooting flow помог найти причину за минуты.
- **Facebook** в 2021 был недоступен 6 часов - BGP withdraw убрал их из интернета. Диагностика осложнялась тем, что внутренние инструменты тоже не работали.
Предварительные знания
Методология траблшутинга
**Сетевой траблшутинг** - это систематический процесс поиска причины проблемы. Не 'попробую перезагрузить', а научный метод: гипотеза → эксперимент → вывод. Хороший диагност экономит часы, плохой - создаёт новые проблемы.
Ключевой принцип: **Divide and Conquer**. Сеть - это стек уровней. Если не работает HTTP, проблема может быть на любом уровне от физического до прикладного. Сужаем scope, пока не найдём сломанный уровень.
**Золотое правило**: меняй только одну вещь за раз. Если изменил три параметра и заработало - ты не знаешь какой из них был причиной. Если изменил три и сломалось ещё больше - не знаешь что откатывать.
Пользователь жалуется: 'сайт не открывается'. С чего начать диагностику?
Типичные проблемы
80% сетевых проблем - это 20% типичных причин. Зная их, можно быстро проверить самое вероятное, прежде чем погружаться в дебри. Вот hit-list частых проблем.
**Частая ловушка**: 'У меня работает'. Всегда тестируй с точки зрения пользователя - другая машина, другая сеть, другой браузер. Проблема может быть специфичной для одного клиента.
SSH соединение устанавливается, но при передаче большого файла через SCP зависает. Наиболее вероятная причина?
Инструменты диагностики
Каждый уровень OSI имеет свои инструменты. Знание когда какой применять - половина успеха. От простых (ping, ss) до тяжёлой артиллерии (tcpdump, strace).
**Pro tip**: mtr (My TraceRoute) = traceroute + ping в одном. Показывает packet loss и latency на каждом hop. Запускай на минуту, чтобы увидеть паттерны: `mtr -r -c 60 host`
Какой инструмент покажет что приложение не закрывает TCP соединения (connection leak)?
Case Studies
Теория - это хорошо, но реальный опыт бесценен. Разберём несколько реальных кейсов диагностики, показывающих как применять методологию на практике.
**curl timing format** (`curl-timing.txt`): ``` time_namelookup: %{time_namelookup}\n time_connect: %{time_connect}\n time_appconnect: %{time_appconnect}\n time_starttransfer: %{time_starttransfer}\n time_total: %{time_total}\n ``` Сохрани в файл и используй с `-w @curl-timing.txt`
Если ping работает - сеть в порядке
ping проверяет только ICMP connectivity. TCP на другом порту может быть заблокирован, MTU может быть проблемой для больших пакетов
ICMP и TCP - разные протоколы. Firewall может пропускать ping но блокировать HTTP. MTU проблемы проявляются только на больших пакетах. Всегда тестируй на том протоколе и порту, который нужен приложению.
tcpdump показывает много TCP retransmissions к одному серверу. Что это означает?
Итоги
- **Методология**: Define → Gather → Analyze → Test → Fix → Document. Меняй одну вещь за раз
- **Divide and Conquer**: начинай с нижних уровней OSI и двигайся вверх. Физика → L2 → L3 → L4 → L7
- **Top issues**: DNS, Firewall, Routing, MTU, ARP - проверяй их первыми
- **Инструменты**: ss для TCP состояния, tcpdump для пакетов, mtr для traceroute+ping, curl -v для HTTP
- **Retransmits и CLOSE-WAIT** - красные флаги. Первое = потери на сети, второе = баг в приложении
Связанные темы
Troubleshooting использует знания всех уровней сетевого стека:
- Packet Analysis — tcpdump и Wireshark - главные инструменты глубокой диагностики
- Network Monitoring — Мониторинг даёт baseline и алерты - отправную точку для troubleshooting
Вопросы для размышления
- Вспомните последнюю сетевую проблему которую решали. Какой была методология? Что можно было сделать лучше?
- Какие инструменты из урока вы ещё не использовали? Попробуйте их на рабочей системе (в безопасном режиме)
- Как бы вы документировали troubleshooting процесс для передачи знаний команде?