Поиск неисправностей и устранения неполадок в сети благодаря армейским подразделениям стал неотъемлемой частью академических и профессиональных курсов по всему миру. Он представляет собой логический пошаговый подход для устранения неполадок системы. Мы можем применить этот подход к компьютерным сетям, электрическим и электронным схемам или бизнес-процессам. Когда мы используем методы поиска и устранения неисправностей в сети должным образом, устранение неполадок будет проходить быстрее и эффективнее, чем если бы мы ходили вокруг да около.

Поиск и устранение неисправностей

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

Семь шагов поиска неисправности в сети

Во-первых, мы остановимся на этих шести шагах. Во-вторых, рассмотрим, что каждый из них влечет за собой. В-третьих, применим семь шагов к сценарию перебоев в сети в реальном мире. Следующие семь шагов составляют формальный процесс устранения неполадок:

  1. Распознавание симптомов.
  2. Уточнение симптомов.
  3. Составление списка возможных неисправных функций.
  4. Локализация неисправной функции.
  5. Локализация неисправного компонента.
  6. Анализ ошибок.
  7. Изменение архитектуры.

Со временем формулировка шагов, первоначально разработанных для устранения неполадок электрических и электронных систем, была несколько изменена. Например, шаг 5 в оригинале звучал как «Локализация проблемы в цепи». Формулировка изменилась, но результат все тот же – обнаружение конкретной основной причины.

Распознавание симптомов

Первый шаг открывает общий процесс устранения неисправности локальной сети или других неисправностей. Часто у ИТ-специалистов он происходит, когда кто-то звонит в службу поддержки. ИТ-персонал также может быть предупрежден посредством мониторинга, что система отключена. На данный момент мы знаем, что «что-то не так», но нет никаких указаний на то, что именно произошло. Начните процесс устранения неполадок немедленно.

Уточнение симптомов

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

  • Что вы не можете сделать?
  • Вы могли это сделать раньше?
  • Это касается только вас, или происходит с другими тоже?
  • Это когда-нибудь работало?
  • Что-то изменилось недавно?

При работе с технически неискушенными пользователями важно понимать, что они не могут четко сформулировать проблему. Когда они отвечают на наши вопросы, им сложно описать то, с чем они столкнулись возможно впервые. Например, при устранении неполадок в сети можно услышать общее описание проблемы, — «Интернет не работает!». Хотя это не совсем верно, большинство пользователей не имеют знаний, чтобы понять различие между локальной вычислительной сетью, глобальной вычислительной сетью и Интернетом. Это не их работа, они не должны понимать, что локальная вычислительная сеть не работает, а Интернет все еще ждет их там.

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

Составление списка возможных источников неисправностей

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

Следующий список причин неисправностей может влиять на работу инфраструктуры по той или иной причине:

  • электропитание;
  • контроль окружающей среды;
  • сеть;
  • серверы;
  • безопасность.

Все они очень широкие, и являются сутью третьего шага. Мозговой штурм направлен на поиск неисправности и того, какое направление может быть ее причиной, а также исключение маловероятных и тупиковых версий. Отметание таких направлений сужает круг поиска до разумных границ и в итоге приводит к правильному общему направлению. Когда специалист идет в неправильном направлении и устраняет ошибку, не связанную с проблемой, это называют «спуском в кроличью дыру». Иногда поиск и устранение простых неисправностей в работе оборудования может предотвратить множество ошибок.

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

Локализация неисправной функции

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

Запуск трассировки на адрес сервера показывает успешные передачу пакетов до коммутатора, к которому непосредственно подключается сервер. Этот коммутатор является последним звеном, после которого все пакеты теряются. На основании этого исследования мы предполагаем, что в сети орудует злоумышленник.

Локализация неисправного компонента

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

несанкционированных изменений, а затем исследовать логи, так процесс может сильно затянуться. Список всех портов коммутатора показывает, что порт сервера включен, а скорость и дуплекс настроены на автосогласование.

Локализация неисправного компонента

Мы знаем, что наша сеть сегментирована с использованием VLAN, поэтому мы сверим VLAN, настроенные на коммутаторе, и связанные с ними порты с документацией. В результате мы обнаружили, что сервер подключен к порту, на котором настроен VLAN 1, он используется по-умолчанию для подключения несконфигурированных устройств. Это объясняет тот факт, что у нас хорошее физическое подключение — подтверждается индикацией, но нет сетевого трафика.

Анализ ошибок

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

Согласно моей методике поиска неисправностей при регистрации ошибки необходимо ответить на следующие вопросы:

  1. Что было не так?
  2. Какие симптомы мы увидели?
  3. В чем была причина?
  4. Как мы можем предотвратить это снова?

Документация о неисправности может выглядеть примерно так:

«Сетевой кабель подключен к серверу СЕРВЕР №1 с одной стороны и порт коммутатора №16 с другой стороны. Кабель был подключен в неправильный порт коммутатора. Порт был сконфигурирован  в неправильной сети VLAN, тем самым нарушая сетевую топологию. Сервер был включен и имел корректную сетевую индикацию, но пакеты от сервера по сети не ходили. Порт коммутатора функционировал (индикация подключения была корректной), но назначение VLAN-порта не соответствовало нашей документации.

Техник указал некорректный номер порта при смене номера VLAN для другого хоста и случайно отключил наш сервер. Возврат порта коммутатора обратно на серверный VLAN восстановил соединение».

Создание методологии предотвращения повторных ошибок может быть непростой задачей, требующей обширных знаний и смекалки. Сочетание обучения, наставничества, хорошей документации и процессов управления изменениями может помешать ошибке снова повториться. Даже неформальный обмен знаниями в ИТ-команде лучше, чем ничего.

Во время еженедельной встречи полезно быстро повторить алгоритм поиска неисправности по следующим пунктам:

  1. Что произошло.
  2. С чем столкнулись во время устранения неполадки.
  3. Как мы исправили ошибки.

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

Читать далее

Поиск неисправностей в сети за 7 шагов
Adblock detector