Здесь вы должны локализовать одну ошибку с помощью теста, сравнить ожидаемый и фактический результат и выбрать следующее действие. Этот метод можно применять к программе, контейнеру или сетевой службе. Вам потребуется известное пользовательское действие, которое должно было работать корректно, а также доступ для проверки соответствующего решения.

Начните с семи шагов и раздела «Сравнение ожидаемого с фактическим» и используйте их в Задаче 1. Порядок работы со сетью является вспомогательным материалом при устранении ошибок сети. Таблица Linux/Proxmox — это один пример, а не команды, которые необходимо выполнять для всех типов ошибок. Самопроверка является необязательным упражнением.

Если вы хотите увидеть применение метода к конкретной ошибке, следуйте по ссылке моделированное устранение неисправностей приложения. Там вам нужно обосновать следующий тест перед тем, как открыть предложение ответа.

Семь шагов

1. Оцените обстоятельства. Что произошло и когда это началось?
2. Воспроизведите ошибку, если безопасно сделать это снова.
3. Идентифицируйте и ограничьте возможные источники ошибок — какой слой или какая компонента может быть виновником?
4. Соберите информацию — журналы событий, сообщения об ошибках, результаты команд.
5. Определите возможные решения на основе того, что вы сейчас знаете.
6. Тестируйте по одному решению или гипотезе за раз. Если менять несколько вещей одновременно, вы не будете знать, что именно решило проблему.
7. Задокументируйте ошибку и решение, чтобы вы (или кто-то другой) могли распознать её в следующий раз.

Порядок устранения неполадок в сети и службах

Если вам неясно, где именно находится сетевая ошибка, этот порядок действий служит отправной точкой. Если у вас уже есть соответствующий результат теста, используйте его для выбора направления дальнейших проверок. Не обязательно выполнять все сетевые тесты при наличии ошибки кода.

flowchart TD
    A[Физическое соединение] --> B[Сетевой интерфейс]
    B --> C[Конфигурация IP]
    C --> D[Локальная сеть]
    D --> E[Шлюз и маршрутизация]
    E --> F[DNS]
    F --> G[Сервис]

Видео: Как проверить подключение к сети с помощью утилиты ping

Видео демонстрирует, как можно использовать команду ping для проверки доступности устройства в сети.

По каждому пункту вы должны уметь:

• объяснять, что именно проверяет данный этап диагностики
• находить соответствующие значения с помощью правильной команды (см. [[Протоколы уровня 1 — Сетевые протоколы|🌐 Сетевые протоколы]], чтобы узнать о командах ping, nslookup и других)
• различать наблюдение и предположение
• выбирать следующий шаг диагностики на основе результатов предыдущего этапа, а не по интуиции

Команды по уровням в Linux ВМ в Proxmox

Это применение метода на случай, когда Linux ВМ не может достичь службы. Выполняйте соответствующие команды в Консоли самой ВМ, а не в Оболочке (Shell) хоста Proxmox. При необходимости смотрите 🧭 Навигация в Proxmox VE. Выберите тест для того, что вы проверяете; таблица не является обязательным требованием для Задачи 1.

Если маршрут по умолчанию отсутствует, выясните, как ВМ должна достигать целей вне собственной сети; у некоторых целей могут быть отдельные маршруты. Некоторые сети блокируют ping, поэтому отсутствие ответа само по себе не доказывает разрыв соединения. Если разрешение имен и пакеты работают корректно, у вас есть конкретные результаты для дальнейшей работы. 🌐 IP, подсеть и шлюз по умолчанию объясняет адресацию, префиксы и маршрутизацию.

Тест ожидаемого против фактического

Тест отладки полезен только в том случае, если вы знаете, чего ожидаете до его запуска. Запишите:

Требование:      Что пользователь должен уметь делать?
Цель:              Какой адрес/сервис вы тестируете?
Ожидание:          Что должно произойти при правильной работе?
Факт:              Что произошло?
Доказывает:        Какое доказательство дает этот результат?
Не доказывает сам по себе:  Чего НЕ доказывает этот результат?

Задание 1 - Применение метода к реальной проблеме

Возьмите проблему, с которой вы столкнулись в другом курсе по эксплуатации или разработке (контейнер, который не запускается, сервис, недоступный для связи, скрипт с ошибкой):

1. Пройдите семь шагов выше один за другим.
2. Для каждого выполняемого теста запишите «ожидаемое против фактического».
3. Отметьте какой компонент или слой тест позволяет определить границей. Используйте сетевой порядок только если он подходит для проблемы.
4. Попробуйте одно обоснованное исправление в тестовой среде, где вам разрешено вносить изменения. Повторите исходное пользовательское действие и убедитесь, что исправление действительно работает. Сохраняйте возможность отката к предыдущему состоянию.

Если у вас нет доступной ошибки, проанализируйте этот пример: приложение возвращает ожидаемую страницу на /, но HTTP 404 на /status. Что показывают эти два ответа, и что бы вы проверили первым? Оба запроса получили ответ HTTP; первая проверка — существует ли /status фактически в приложении и использует ли клиент правильный маршрут. Пример является упражнением в анализе, а не доказательством того, что вы исправили собственное решение.

Контрольная точка: Ошибка изолирована и контролируется

Покажите журнал тестов и объясните, какое наблюдение подтвердило следующий тест или исправление. После исправления исходное действие должно дать ожидаемый результат. Вы можете объяснить это устно или письменно с командами и результатами перед вами. Если ошибка все еще не устранена, укажите, что было протестировано, что остается неуточненным и один точный следующий тест. Не записывайте предполагаемую причину как подтвержденную.

Проверьте себя

Необязательная самопроверка с обратной связью. Ответы не отправляются преподавателю. Используйте собственный журнал тестирования для демонстрации фактического устранения неполадок; самопроверка не заменяет практическую проверку.

Резюме

• Отладка — это метод, а не гадание — семь установленных шагов от выявления до документирования
• Метод бисекции позволяет сузить поиск в цепи, если вы знаете элементы, используемые тестом
• Для сетей: используйте уровни, чтобы выбрать соответствующий следующий тест на основе того, что вы наблюдали
• Всегда записывайте ожидаемое против фактического перед проведением теста и помните, что один тест редко доказывает всё