ЛАБОРАТОРНАЯ РАБОТА №8

Тема: «Задачи управления: анализ производительности сети, анализ надёжности сети»

МДК.03.01 «Эксплуатация сетевой инфраструктуры»

Специальность 09.02.06 «Сетевое и системное администрирование»

Объём: 12 академических часов — 6 занятий по 2 академических часа. Формат: онлайн

Группа: ССА9123

ВАЖНО — ПРОЧИТАЙТЕ ПЕРЕД НАЧАЛОМ РАБОТЫ

1. Выполняйте пункты каждого занятия в тот день, когда оно объявлено в сообщении в мессенджере МАКС. Ссылка на видеовстречу одна и та же для обеих пар — она указана в том же сообщении.

2. Практическая часть каждого занятия оформляется в отчёт в день выполнения. Не откладывайте оформление на конец работы: к последнему занятию отчёт должен быть почти готов, там остаётся только итоговый вывод.

3. Работа рассчитана на обычный компьютер с Windows 10/11 — все основные задания выполняются встроенными средствами системы. Если у вас есть Linux (виртуальная машина или второй компьютер) — используйте вариант B, он равноправен варианту A.

4. Для каждого действия в отчёт требуется скриншот, на котором видны: команда (или окно программы) и результат её выполнения. Скриншот без команды не принимается.

Примечание об оформлении документа

Команды и служебные строки в этом документе выделены отдельно — серыми блоками моноширинным шрифтом Consolas (как в блокноте). Такое выделение сделано специально, для удобства записи в кодовом формате: команды легко найти глазами и точно скопировать в терминал. Весь остальной текст — обычный, его копировать не нужно.

1. Цель работы

Научиться оценивать состояние сети по измеримым показателям:

• измерять показатели производительности: пропускную способность, задержку (RTT), джиттер, потери пакетов;
• находить узкое место сети методом последовательного исключения;
• рассчитывать показатели надёжности: доступность, допустимый простой, MTBF;
• находить одиночные точки отказа (SPOF) и оценивать эффект резервирования;
• моделировать отказ элемента сети и наблюдать работу системы мониторинга;
• документировать результаты диагностики в отчёте.

2. Оборудование и программное обеспечение

Вариант A — Windows 10/11 (основной):

• встроенные средства: командная строка (cmd), PowerShell, Диспетчер задач, Монитор ресурсов (resmon), брандмауэр;
• iperf3 — один zip-архив с сайта iperf.fr, установка не требуется (инструкция в занятии 2);
• второй узел для замеров: компьютер напарника по паре или вторая виртуальная машина в той же сети.

Вариант B — Linux (Ubuntu/Debian или другой, равноправный):

• пакеты: iperf3, mtr, sysstat (sar), iproute2 — ставятся одной командой;
• второй узел для замеров — по тем же правилам.

Общее (обоим вариантам):

• доступ к Zabbix (если выдан преподавателем) — для занятия 5; при отсутствии — скриптовый контроль доступности по инструкции того же занятия;
• блокнот или документ для фиксации результатов по ходу работы.

3. Теоретический минимум (общий обзор)

Производительность сети описывают четыре показателя. Пропускная способность — реальный объём данных в единицу времени: «1 Гбит/с» на коробке интерфейса и реальная скорость канала — не одно и то же, на результат влияют протоколы, задержки и загрузка узлов. Задержка (RTT) — время прохождения пакета туда и обратно. Джиттер — разброс задержки между соседними пакетами; для голоса и видео он важнее средней задержки. Потери пакетов — доля потерянных пакетов; даже 1–2% потерь заметно «режет» скорость TCP.

Рис. 1. Четыре показателя производительности сети: определения, инструменты и нормы

Надёжность сети описывают другие величины. Доступность — доля времени, когда сеть работоспособна; её обычно выражают «девятками»: 99%, 99,9%, 99,99%. MTBF (Mean Time Between Failures) — среднее время наработки между отказами. MTTR (Mean Time To Repair) — среднее время восстановления после отказа. Одиночная точка отказа (SPOF, Single Point of Failure) — элемент, отказ которого останавливает работу всей сети или её части. Избыточность — дублирование каналов и устройств, позволяющее пережить отказ одного элемента. SLA — соглашение об уровне сервиса, фиксирующее целевой процент доступности.

Связь показателей надёжности описывает формула доступности:

A = MTBF / (MTBF + MTTR)

где A — доступность (доля времени работоспособности), MTBF — среднее время наработки между отказами, MTTR — среднее время восстановления. Чем реже отказы (больше MTBF) и быстрее восстановление (меньше MTTR) — тем выше доступность. Отсюда следует важный практический вывод: резервирование оборудования снижает MTTR (резервный элемент включается сразу), а хорошая диагностика и запасные части — тоже снижают MTTR.

4. Соответствие команд Windows и Linux

В таблице — пары команд для одинаковых действий. Используйте колонку своей системы; вторая пригодится, если попрактикуетесь на другой ОС или придёте на помощь напарнику.

5. Демонстрационные материалы

Видео просматриваются перед выполнением соответствующего занятия (5–15 минут) и служат демонстрацией приёмов, которые вы затем повторяете на своей машине. Все ролики обучающие, без неуместного контента. Текстовые материалы — по желанию, они глубже и для чтения во внеурочное время.

К занятию 1 (базовая диагностика):

• VK Видео — Диагностика подключения в Windows: ping, tracert, telnet, nslookup
• VK Видео — WinMTR, pathping, ping, tracert — диагностика сети

К занятию 2 (пропускная способность):

• Rutube — Тестирование пропускной способности сети с помощью iperf3

К занятию 3 (локализация узкого места):

• Rutube — Простейшая диагностика сетевых проблем на ПК с Windows (PING, TRACERT и PATHPING)

К занятиям 4–5 (надёжность, отказоустойчивость):

• Rutube — Анализ производительности Windows — сеть и память (разбор инфраструктуры)
• Rutube — Zabbix: проверка доступности запросом ICMP Ping

Текстовые материалы (по желанию):

• Статья — Что такое SLA, и сколько стоит девятка в аптайме (Habr)
• Статья — Отказоустойчивая IT-инфраструктура: принципы и способы организации (Timeweb)

6. Ход работы по занятиям

Каждое занятие ниже оформлено по одной схеме: когда выполняется → цели → теоретическая часть → демонстрационные материалы → практическая часть (вариант A Windows, вариант B Linux) → оформление практической части в отчёте → контрольные вопросы по занятию. Пункты занятия выполняются в тот день, когда оно объявлено в сообщении в мессенджере МАКС.

 Занятие 1. Базовые метрики сети: RTT, джиттер, счётчики интерфейса

Когда выполняется: в день, когда занятие объявлено в сообщении в мессенджере МАКС (первая пара из шести).

Цели занятия

1. Научиться снимать базовые метрики своего узла: адреса, интерфейсы, счётчики ошибок.
2. Измерить RTT и оценить джиттер командой ping.
3. Снять «базовую линию» — значения метрик исправной сети, с которыми будем сравнивать в занятиях 3 и 6.

Теоретическая часть (изучается в начале занятия)

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

Задержка (RTT, round-trip time) — время, за которое пакет доходит до получателя и возвращается обратно. Задержку меряют в миллисекундах. Для локальной сети нормой считаются единицы миллисекунд, для города — 10–30 мс, для межконтинентальных каналов — 100–200 мс и выше. Задержка важна для интерактивных задач: звонков, игр, удалённых рабочих столов.

Рис. 2. Джиттер: стабильная связь слева (разброс ~1 мс) и нестабильная справа (~40 мс)

Джиттер — это разброс задержки между соседними пакетами. Если пакеты идут через сеть за 12, 12, 13, 12 мс — связь ровная. Если за 5, 42, 10, 85 мс — связь «дёргается», и даже при маленькой средней задержке разговор или видеозвонок будет рассыпаться: пакеты приходят рывками. Именно поэтому джиттер считается отдельно, а не «прячется» в средней задержке.

Потери пакетов — доля пакетов, не дошедших до получателя. Потери до 1% обычно незаметны, от 1 до 2,5% уже ощущаются в звонках и играх, выше 2,5% — сеть явно болеет и нужно искать причину. Для TCP потери — ещё и тормоза: каждый потерянный пакет заставляет протокол останавливаться и передавать заново.

Все четыре показателя измеряются простыми инструментами, встроенными в систему. Задача первого занятия — снять «базовую линию»: значения метрик вашей сети в спокойном состоянии. Диагностика в занятиях 3 и 6 строится именно на сравнении с этой базовой линией: нельзя сказать «задержка выросла», не зная, какой она была раньше.

Демонстрационные материалы

• VK Видео — Диагностика подключения в Windows: ping, tracert, telnet, nslookup
• VK Видео — WinMTR, pathping, ping, tracert — диагностика сети

Практическая часть — Вариант A (Windows 10/11)

1. Откройте командную строку (Пуск → cmd). Определите параметры своего подключения и узла напарника: показания сетевого адаптера и IP-адреса обоих узлов зафиксируйте в отчёт.

ipconfig /all

2. Проверьте связность с узлом напарника серией из 20 пакетов. В выводе нас интересуют строки времени и итоговая сводка.

ping -n 20

3. Снимите расширенную серию из 50 пакетов — по ней оценим джиттер: разница между средним (Average) и максимальным (Maximum) временем даёт грубую оценку разброса.

ping -n 50

4. Повторите пинг до внешнего узла (например, DNS Яндекса) и сравните задержку локальной и внешней сети.

ping -n 50 77.88.8.8

5. Посмотрите счётчики интерфейса — ошибки и отброшенные пакеты с момента загрузки системы:

в PowerShell:

Get-NetAdapterStatistics

6. Посмотрите активные соединения: сводку и список TCP-соединений с группировкой по состояниям.

cmd и PowerShell:

netstat -an

Get-NetTCPConnection | Group-Object State | Sort-Object Count -Descending

7. Откройте Монитор ресурсов (Win+R → resmon → вкладка «Сеть») и зафиксируйте текущую скорость по сетевому адаптеру — это живой индикатор загрузки канала в реальном времени.

Практическая часть — Вариант B (Linux)

1. Определите адреса: свой и напарника; зафиксируйте в отчёт.

ip a

2. Проверьте связность серией из 50 пакетов:

ping -c 50

3. Повторите до внешнего узла и сравните RTT локальной и внешней сети:

ping -c 50 77.88.8.8

4. Посмотрите счётчики интерфейса — строки RX/TX: errors (ошибки) и dropped (отброшенные пакеты):

ip -s link show <имя_интерфейса>

5. Посмотрите сводку соединений и список TCP-соединений:

ss -s

ss -t

Оформление практической части в отчёте

В отчёте создайте раздел «Занятие 1» и внесите в него (здесь студент оформляет практическую часть за день занятия):

• таблицу «метрика — значение — инструмент»: RTT min/avg/max до напарника, RTT до внешнего узла, оценка джиттера, счётчики ошибок и дропов, число активных соединений;
• скриншоты: вывод ipconfig (или ip a), две серии ping, счётчики интерфейса;
• вывод 2–3 предложениями: какой канал стабильнее и почему, совпадает ли поведение с нормами из теории.

Контрольные вопросы по занятию

1. Чем реальная пропускная способность отличается от заявленной скорости интерфейса?
2. Что такое джиттер и почему для видеозвонка он опаснее средней задержки?
3. Что такое «базовая линия» и зачем мы снимаем её в исправной сети?

Занятие 2. Измерение пропускной способности: iperf3

Когда выполняется: в день, когда занятие объявлено в сообщении в мессенджере МАКС (вторая пара из шести).

Цели занятия

1. Освоить связку «сервер iperf3 + клиент iperf3» на двух узлах.
2. Измерить пропускную способность канала в TCP-режиме: одиночный поток, несколько потоков, обратное направление.
3. Измерить потери пакетов и джиттер в UDP-режиме — их даёт только он.

Теоретическая часть (изучается в начале занятия)

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

Замер в TCP-режиме показывает полезную пропускную способность: TCP сам подстраивает скорость под качество канала, поэтому в итоге мы видим то, что реально сможет использовать приложение. Замер в UDP-режиме нужен для другого: UDP не подстраивается, он шлёт пакеты с заданной скоростью — и по его выводу мы видим джиттер и потери пакетов. Поэтому грамотный диагност делает оба замера: TCP — «сколько влезает», UDP — «какого качества канал».

Рис. 3. Схема замера iperf3: сервер на одном узле, клиент на другом, варианты ключей

Пара важных наблюдений, которые вы сделаете сами. Один TCP-поток часто не «разогревает» канал целиком: окно перегрузки растёт постепенно, и на каналах с большой задержкой один поток недобирает скорость. Четыре параллельных потока (ключ -P 4) дают реальную картину. Обратный замер (-R) часто показывает другую скорость — каналы у провайдеров несимметричны: вверх и вниз рассчитаны по-разному. Это тоже нормально, но знать асимметрию своего канала полезно.

Демонстрационные материалы

• Rutube — Тестирование пропускной способности сети с помощью iperf3

Практическая часть — Вариант A (Windows 10/11)

1. Скачайте архив iperf3 с сайта iperf.fr (раздел Download → Windows), распакуйте в отдельную папку. Установка не требуется. Откройте cmd в этой папке (в проводнике: Shift + правая кнопка мыши → «Открыть окно PowerShell здесь»).
2. Договоритесь с напарником, кто сервер, кто клиент. На узле-сервере запустите:

iperf3 -s

3. На узле-клиенте выполните одиночный TCP-замер и запишите скорость:

iperf3 -c

4. Замер с четырьмя параллельными потоками — сравните с одиночным:

iperf3 -c -P 4

5. Обратный замер направления: без -R клиент шлёт данные серверу, с -R — сервер клиенту. Сравните скорости.

iperf3 -c -R

6. UDP-замер с ограничением скорости — обратите внимание на столбцы Jitter и Lost/Total в выводе:

iperf3 -c -u -b 100M

7. Выполните каждый замер три раза и занесите средние значения в таблицу отчёта.

Практическая часть — Вариант B (Linux)

1. Установите iperf3 на обоих узлах:

sudo apt install iperf3

2. Дальше — та же последовательность, что в варианте A: на сервере iperf3 -s, на клиенте — замеры с ключами c, -P 4, -R, -u -b 100M:

iperf3 -s

iperf3 -c

iperf3 -c -P 4

iperf3 -c -R

iperf3 -c -u -b 100M

Оформление практической части в отчёте

В отчёте создайте раздел «Занятие 2» и внесите (здесь студент оформляет практическую часть за день занятия):

• таблицу замеров: тип замера (TCP одиночный / TCP -P 4 / TCP -R / UDP -b 100M) → скорость → джиттер → потери;
• скриншоты вывода клиента для каждого типа замера;
• вывод: какова реальная пропускная способность канала, симметричны ли направления, что дают столбцы UDP-режима.

Контрольные вопросы по занятию

1. Почему один TCP-поток часто показывает меньшую скорость, чем четыре параллельных?
2. Что измеряет UDP-режим iperf3, чего не даёт TCP-режим?
3. Куда смотреть в выводе UDP-замера, чтобы оценить потери пакетов?

Занятие 3. Локализация узкого места в сети

Когда выполняется: в день, когда занятие объявлено в сообщении в мессенджере МАКС (третья пара из шести).

Цели занятия

1. Освоить метод последовательного исключения применительно к сети.
2. Научиться читать трассировку маршрута с расчётом потерь по хопам (pathping / mtr).
3. Научиться наблюдать нагрузку интерфейса в реальном времени и связывать её с происходящим в сети.

Теоретическая часть (изучается в начале занятия)

Узкое место — это элемент сети, который ограничивает общую скорость. Могут тормозить диск или процессор, но если они в норме, а приложение всё равно медленное — виновата сеть. Метод последовательного исключения для сети выглядит так: (1) проверить, что проблема в сети, а не в узле — счётчики CPU, диска, памяти в норме; (2) определить маршрут до получателя — где именно по пути сеть «режет» трафик; (3) посмотреть нагрузку интерфейсов — не забит ли канал; (4) сузить круг: если симптомы уходят при обходе одного элемента — он и есть узкое место.

Главный инструмент этого занятия — трассировка с расчётом потерь по хопам. В Linux это mtr, в Windows — pathping: обе команды отправляют много пакетов через каждый узел маршрута и показывают процент потерь на каждом хопе. Читать их вывод — отдельное умение, и оно неочевидное.

Рис. 4. Чтение вывода mtr: потери на промежуточном хопе при нуле дальше по трассе — не проблема

Ключевое правило: потери «наследуются» вниз по трассе. Если на третьем хопе теряется 45%, а на четвёртом и всех следующих — 0%, значит третий узел не теряет полезный трафик: он лишь ограничивает скорость ответов на наши служебные запросы (маршрутизаторы отвечают на ICMP в последнюю очередь — сначала настоящие пакеты). Тревожиться нужно тогда, когда потери растут к концу трассы и стабилизируются: 2% → 10% → 25% — узкое место там, где цифра перестала расти. Так же читается pathping в Windows: сначала трассировка, потом счёт каждого хопа.

Второй инструмент — наблюдение за нагрузкой интерфейса. В Linux это sar -n DEV, в Windows — Монитор ресурсов (resmon) и счётчики производительности. Если во время жалобы пользователя интерфейс загружен на 95% и выше — канал забит, и надо искать, кто его забивает, а не «чинить» оборудование.

Демонстрационные материалы

• Rutube — Простейшая диагностика сетевых проблем на ПК с Windows (PING, TRACERT и PATHPING)

Практическая часть — Вариант A (Windows 10/11)

1. Постройте маршрут до узла напарника и до внешнего узла (зафиксируйте число хопов):

tracert

tracert 77.88.8.8

2. Выполните замер потерь по хопам. Pathping сначала трассирует маршрут, затем около 100 секунд считает потери на каждом хопе — дождитесь завершения:

pathping -n -q 10

3. Во время активной передачи (напарник гонит iperf3) снимите счётчики интерфейса до и после передачи — сравните рост dropped:

в PowerShell, до и после передачи:

Get-NetAdapterStatistics

4. Откройте resmon → «Сеть» и наблюдайте скорость по адаптеру во время передачи напарника. Зафиксируйте пиковую скорость.
5. Решите три мини-задачи преподавателя (симптомы выдаются на занятии): по набору симптомов определите, где узкое место, и обоснуйте методом исключения.

Практическая часть — Вариант B (Linux)

1. Запустите mtr в режиме отчёта (собирает 200 пакетов):

mtr -rw

2. Разберите колонки: Loss% (потери), Avg (средняя задержка), Best/Wrst (лучший/худший). Примените правило наследования потерь из теории.
3. Наблюдайте нагрузку интерфейсов во время передачи напарника — найдите свой интерфейс и зафиксируйте rxkB/s и txkB/s:

sar -n DEV 1 10

4. Снимите ip -s link до и после активной передачи — сравните рост dropped:

ip -s link show <имя_интерфейса>

5. Решите три мини-задачи преподавателя — как в варианте A.

Оформление практической части в отчёте

В отчёте создайте раздел «Занятие 3» и внесите (здесь студент оформляет практическую часть за день занятия):

• вывод pathping (или mtr) с разбором: на каком хопе сколько потерь, что это значит по правилу наследования;
• наблюдение нагрузки интерфейса: скорость во время передачи, рост счётчика dropped;
• решения трёх мини-задач с обоснованием: какой симптом какой вывод даёт.

Контрольные вопросы по занятию

1. Опишите четыре шага метода последовательного исключения для сети.
2. Почему потери на промежуточном хопе при нуле на конечном — обычно не проблема?
3. Как выглядит в mtr/pathping картина реального узкого места?

Занятие 4. Показатели надёжности сети

Когда выполняется: в день, когда занятие объявлено в сообщении в мессенджере МАКС (четвёртая пара из шести).

Цели занятия

1. Научиться рассчитывать допустимый простой для заданного уровня доступности.
2. Научиться находить одиночные точки отказа (SPOF) на схеме сети.
3. Оценивать эффект и цену резервирования элементов сети.

Теоретическая часть (изучается в начале занятия)

Надёжность сети измеряется не «на глазок», а числами, и главное из них — доступность (availability): доля времени, когда сеть работоспособна. Доступность выражают процентами, и за каждым процентом стоит конкретное время простоя. Разница между 99% и 99,9% кажется косметикой, но на деле это разница между «восемью часами простоя в месяц» и «сорока минутами» — принципиально разные бюджеты и требования к инфраструктуре.

Рис. 5. Шкала «девяток»: допустимый простой в месяц для каждого уровня доступности

Доступность складывается из двух величин: MTBF — среднего времени наработки между отказами (как часто ломается элемент) и MTTR — среднего времени восстановления (как быстро его чинят). Формула из раздела 3 (A = MTBF / (MTBF + MTTR)) показывает оба рычага: можно реже ломаться, а можно быстрее восстанавливаться. Резервирование работает именно через второй рычаг: отказавший элемент мгновенно замещается запасным, и MTTR падает почти до нуля.

Одиночная точка отказа — элемент, отказ которого останавливает сеть или её часть. В простой сети из одного коммутатора и одного маршрутизатора SPOF-ами являются и коммутатор, и маршрутизатор, и канал провайдера: каждый из них незаменим. Лечение одно — избыточность: дублирование элемента, чтобы сеть пережила отказ любого из них. Но избыточность стоит денег, поэтому инженер не «дублирует всё подряд», а расставляет приоритеты: что резервируем в первую очередь, а что остаётся единственным — и осознаём этот риск.

Рис. 6. Простая сеть с отмеченными одиночными точками отказа

SLA (Service Level Agreement) — соглашение об уровне сервиса: договор с поставщиком или внутренний стандарт, где зафиксирован целевой процент доступности и последствия его нарушения. Для администратора SLA — это переводчик между «инженерным языком» (девятки) и «бизнес-языком» (минуты простоя и деньги).

Демонстрационные материалы

• Статья — Что такое SLA, и сколько стоит девятка в аптайме (Habr)
• Статья — Отказоустойчивая IT-инфраструктура: принципы и способы организации (Timeweb)
• Rutube — Разбор отказоустойчивой инфраструктуры (видео)

Практическая часть — общая для вариантов A и B

1. Рассчитайте допустимый простой в месяц (30 суток) для SLA 99%, 99,9%, 99,95%, 99,99%. Считайте сами: простой = (1 − доступность) × 30 суток × 24 ч × 60 мин. Сверьте результат с рис. 5.

Пример расчёта для 99,9%:

арифметика в одну строку:

простой = (1 - 0.999) × 30 × 24 × 60 = 432 мин ≈ 43 мин 50 с

2. Получите у преподавателя схему учебной сети (или начертите свою: ПК → коммутатор → маршрутизатор → канал провайдера → интернет).
3. Найдите на схеме одиночные точки отказа: пройдите по каждому элементу и ответьте на вопрос «что произойдёт с сетью, если он откажет?». Отметьте SPOF на схеме (как на рис. 6).
4. Составьте таблицу «элемент → последствия отказа → есть ли резерв → что добавить для резервирования» (в отчёт).
5. Для каждого элемента словесно оцените: к какому уровню «девяток» приведёт его дублирование и что это будет стоить (второй коммутатор — дешевле, второй канал другого провайдера — дороже).

Оформление практической части в отчёте

В отчёте создайте раздел «Занятие 4» и внесите (здесь студент оформляет практическую часть за день занятия):

• таблицу простоя по уровням SLA с собственным расчётом;
• схему сети с отмеченными SPOF (фото рисунка или скриншот схемы);
• таблицу «элемент → последствия отказа → резерв»;
• вывод: какие две точки отказа вы бы зарезервировали в первую очередь и почему.

Контрольные вопросы по занятию

1. Что означает доступность 99,9% в минутах простоя в месяц?
2. Как связаны MTBF, MTTR и формула доступности? Резервирование через какой из них работает?
3. Почему полная резервная схема — не всегда правильное решение?

Занятие 5. Моделирование отказа и контроль доступности

Когда выполняется: в день, когда занятие объявлено в сообщении в мессенджере МАКС (пятая пара из шести).

Цели занятия

1. Настроить контроль доступности узлов сети.
2. Смоделировать отказ элемента сети безопасным способом и наблюдать реакцию мониторинга.
3. Научиться фиксировать отказ в журнале: что отключали, как выглядел отказ, как восстанавливалась сеть.

Теоретическая часть (изучается в начале занятия)

Отказоустойчивость нельзя проверить чтением — её проверяют опытом: намеренно отказывают элементу и смотрят, как поведёт себя сеть и как быстро заметит мониторинг. Такой опыт на реальной боевой сети проводят в техобслуживание, а в учебной лаборатории — прямо на занятии. Важно, чтобы отказ был управляемым и обратимым: мы должны уметь включить всё обратно за секунду.

В этой работе мы моделируем отказ самого «безопасного» элемента — ответов на ICMP-запросы. Идея: узел продолжает работать, интернет и видеосвязь не страдают, но для наблюдателя он «перестаёт пинговаться» — мониторинг фиксирует недоступность, как при реальной беде. В Windows это делается одним правилом брандмауэра, в Linux — одним правилом ufw. Снятие правила мгновенно «лечит» узел.

Контроль доступности в мониторинге работает просто: сервер мониторинга с заданной частотой пингует узлы. В Zabbix для этого есть шаблон ICMP Ping с тремя проверками: icmpping (узел отвечает?), icmppingloss (процент потерь), icmppingsec (время ответа). Триггер «узел недоступен» срабатывает, когда несколько подряд проверок не прошли — так отсекаются случайные одиночные потери. Если Zabbix недоступен, тот же принцип реализуется скриптом по расписанию: ping узла, и в зависимости от результата запись в журнал.

Демонстрационные материалы

• Rutube — Zabbix: проверка доступности запросом ICMP Ping

Практическая часть — Вариант A (Windows 10/11)

1. Настройте контроль доступности узла напарника. Если выдан доступ к Zabbix — подключите к узлу шаблон ICMP Ping (проверки icmpping, icmppingloss, icmppingsec) и убедитесь, что узел зелёный. Если Zabbix недоступен — скрипт ниже: проверяет узел, пишет результат в журнал lab8.log, выходной код отражает состояние.

PowerShell-скрипт (сохранить как check-host.ps1 и запустить: powershell -File check-host.ps1):

# файл check-host.ps1

while ($true) {

  $r = Test-Connection -Count 3 -ComputerName -Quiet

  if ($r) { "$(Get-Date -Format s) UP"   | Out-File lab8.log -Append }

  else    { "$(Get-Date -Format s) DOWN" | Out-File lab8.log -Append }

  Start-Sleep -Seconds 10

}

2. Смоделируйте отказ: заблокируйте ICMP-ответы на своём узле правилом брандмауэра (интернет и видеосвязь продолжат работать — блокируется только пинг):

в cmd от имени администратора:

netsh advfirewall firewall add rule name="Lab8_Block_ICMP" protocol=icmpv4:8,any dir=in action=block

3. Наблюдайте: напарник запускает ping на ваш узел — ответы пропали. Следите за журналом lab8.log (или алертом в Zabbix). Зафиксируйте время, через которое система заметила отказ.

просмотр журнала:

type lab8.log

4. Восстановите «узел» удалением правила — пинг вернётся, зафиксируйте время восстановления:

netsh advfirewall firewall delete rule name="Lab8_Block_ICMP"

5. Поменяйтесь ролями с напарником и повторите опыт в обратную сторону.

Практическая часть — Вариант B (Linux)

1. Контроль доступности — скриптом по расписанию или через Zabbix (как в варианте A). Скрипт-эквивалент:

запуск: bash check-host.sh

# файл check-host.sh

while true; do

  if ping -c 3 > /dev/null 2>&1; then

    echo "$(date -Is) UP"   >> lab8.log

  else

    echo "$(date -Is) DOWN" >> lab8.log

  fi

  sleep 10

done

2. Смоделируйте отказ блокировкой ICMP-ответов (Ubuntu/Debian):

включить блокировку:

sudo ufw deny proto icmp

снять блокировку (восстановление):

sudo ufw delete deny proto icmp

3. Если ufw не активен — эквивалент через iptables: заблокировать правило iptables -A INPUT -p icmp -j DROP, снять — iptables -D INPUT -p icmp -j DROP.
4. Наблюдайте журнал lab8.log: отметьте момент перехода UP → DOWN и время обнаружения. Поменяйтесь ролями с напарником.

Оформление практической части в отчёте

В отчёте создайте раздел «Занятие 5» и внесите (здесь студент оформляет практическую часть за день занятия):

• скриншот алерта Zabbix или вывод журнала lab8.log с переходами UP/DOWN;
• журнал моделирования отказа по форме: что блокировали → как выглядел отказ (пинг «Request timed out» / «Destination host unreachable») → через сколько секунд это заметил мониторинг → как восстанавливали;
• вывод: сколько секунд заняло обнаружение отказа и от чего зависит это время.

Контрольные вопросы по занятию

1. Почему в этой работе мы блокируем ICMP, а не отключаем сетевой адаптер?
2. Какие три проверки входят в шаблон ICMP Ping в Zabbix и что показывает каждая?
3. Почему триггер срабатывает не на первую же пропавшую пинговку, а после нескольких подряд?

Занятие 6. Комплексная диагностика и оформление отчёта

Когда выполняется: в день, когда занятие объявлено в сообщении в мессенджере МАКС (шестая, последняя пара).

Цели занятия

1. Применить весь арсенал работы к одной комплексной задаче: найти узкое место и обосновать вывод.
2. Собрать итоговый отчёт по всем шести занятиям.

Теоретическая часть (изучается в начале занятия)

Комплексная диагностика — это способность собрать картину из разных источников. Ни одна метрика сама по себе не называет виновника: RTT может вырасти и от загруженного канала, и от загруженного CPU на промежуточном маршрутизаторе. Виновника называет только совокупность: счётчики узла в норме (значит, не узел), потери растут к концу трассы и стабилизируются на одном хопе (значит, виноват сегмент за этим хопом), канал между вами и этим хопом загружен в момент проблемы (значит, узкое место — его ёмкость). Такой цепочкой выводов и оформляется комплексная задача.

На занятии преподаватель выдаёт описание ситуации (симптомы: жалобы пользователей, выводы команд с трёх узлов). Ваша задача — пройти по цепочке и письменно обосновать каждый шаг: что проверили → что увидели → что это исключает → к какому элементу пришли. Именно обоснование, а не только «ответ», оценивается в отчёте.

Практическая часть — общая для вариантов A и B

1. Получите у преподавателя описание комплексной задачи (симптомы и данные с узлов).
2. Пройдите цепочку диагностики: базовые метрики → маршрут и потери по хопам (pathping/mtr) → нагрузка интерфейса → вывод.
3. Письменно обоснуйте каждый шаг методом последовательного исключения (в отчёт).
4. Проверьте свой отчёт по чек-листу из раздела 7 и завершите оформление: каждый день работы — отдельный раздел со своими выводами.

Оформление практической части в отчёте

В отчёте создайте раздел «Занятие 6»: решение комплексной задачи с обоснованием и общий вывод по всей работе (2–4 предложения: чему научились, какие показатели оказались самыми информативными).

Контрольные вопросы по занятию

1. Почему ни одна метрика по отдельности не называет виновника узкого места?
2. Как строится цепочка выводов при комплексной диагностике?

Содержание отчёта (чек-лист сдачи)

Отчёт собирается по ходу занятий — по разделу на день. Проверьте себя по списку перед сдачей: каждый пункт — одно действие, один скриншот, одна фраза-подпись.

1. Титульный лист, тема, цель работы.
2. Раздел «Занятие 1»: таблица метрик + скриншоты ipconfig/ip a, серий ping, счётчиков + вывод.
3. Раздел «Занятие 2»: таблица замеров iperf3 (TCP, -P 4, -R, UDP) + скриншоты вывода + вывод о пропускной способности.
4. Раздел «Занятие 3»: вывод pathping/mtr с разбором хопов + наблюдение нагрузки + решения мини-задач.
5. Раздел «Занятие 4»: расчёт простоя по уровням SLA + схема с SPOF + таблица резервирования + вывод.
6. Раздел «Занятие 5»: журнал отказа (скриншот алерта или lab8.log) + время обнаружения и восстановления + вывод.
7. Раздел «Занятие 6»: решение комплексной задачи с обоснованием + общий вывод по работе.

Правило оформления скриншотов: на каждом скриншоте должны быть видны команда (или окно программы) и результат её выполнения. Скриншот без команды не принимается.

Критерии оценки

9. Контрольные вопросы (сводные по работе)

1. Назовите четыре показателя производительности сети и объясните каждый своими словами.
2. Чем замер TCP-потока в iperf3 отличается от UDP-потока? Что даёт только UDP-режим?
3. Как по выводу mtr/pathping определить проблемный хоп? Почему потери на промежуточном узле — не всегда проблема?
4. Что означает доступность 99,9% и сколько минут простоя в месяц она допускает?
5. Что такое одиночная точка отказа? Приведите два примера из учебной сети.
6. Какие три проверки включает шаблон ICMP Ping в Zabbix?
7. Опишите алгоритм последовательного исключения при поиске узкого места в сети.
8. Как связаны избыточность сети, уровень доступности и стоимость инфраструктуры?

10. Источники и материалы

Все демонстрационные материалы перечислены в разделе 5 со ссылками. Дополнительные текстовые источники теории: статьи на Habr (SLA и «девятки») и Timeweb (отказоустойчивость инфраструктуры), а также видеоматериалы Rutube и VK Видео, указанные в разделе 5.