Процесс поиска и устранения причин сбоев в сети

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

Ниже перечислены действия, отвечающие научному подходу к поиску и устране­нию неисправностей.

Этап 1. Определить в чем состоит проблема в сети или у пользователя

Этап 2. Собрать данные о возникшей проблеме

Этап 3. Проанализировать имеющиеся данные и подойти к возможному реше­нию проблемы

Этап 4. Реализовать предлагаемое решение и попытаться скорректировать работу системы

Этап 5. Если проблема не разрешилась, отменить внесенные изменения и внести поправки в данные

Этап 6. Вернуться к этапу 3

Методы устранения неисправностей

Наиболее успешными и эффективными научными методами поиска и устране­ния неисправностей являются метод устранения и метод "разделяй и властвуй".

Ниже описано как практически реализуются эти методы.

Метод устранения

Предположим, что пользователь сети обращается в отдел помощи и сообщает, что его компьютер больше не может соединиться с сетью Internet. В отделе помощи запол­няется соответствующий бланк и направляется сотруднику отдела поддержки. По­следний звонит пользователю, который сообщает что он попытался войти в Internet обычным образом. Проверка аппаратного журнала для сети на компьютере показыва­ет, что компьютер пользователя был модернизирован прошлым вечером. Первой воз­никает гипотеза о том, что драйверы сети на данном компьютере были сконфигуриро­ваны с ошибками. Сотрудник направляется к компьютеру и проверяет сетевую кон­фигурацию на компьютере. Она выглядит правильной и поэтому сотрудник отдела поддержки выполняет команду ping на сервер данной подсети. Как видно из вывода в примере 18.1, соединения не происходит.

Следующим возможным решением является проверка соединения кабеля с рабо­чей станцией. При этом проверяются оба конца кабеля и снова выполняется коман­да ping на сервер. После этого выполняется команда ping 127.0.0.1, в которой ар­гументом служит адрес петлевого интерфейса компьютера (см. пример 18.2). Ко­манда ping дает положительный результат, что снимает предположение о том, что проблема связана с взаимодействием компьютера, конфигурацией драйвера и кар­той сетевого интерфейса.

Возникает предположение, что проблема может быть связана с сервером данного сетевого сегмента. Другой подключенный к сети компьютер расположен на следую­щем рабочем столе, поэтому выполняется команда ping для адреса сервера, которая дает положительный результат (см. пример 18.3). Это снимает предположение о том что причиной проблемы могут быть сервер, магистраль или соединение сервера с ма­гистралью.

После этого сотрудник направляется к промежуточному распределительному шка­фу, переключает порт для рабочей станции и вновь направляется к рабочей станции и вновь выполняет команду ping с адресом сервера. Предположение по-прежнему не оправдывается (см. пример 18.4). Это сужает круг поиска причины сбоя до горизон­тальных кабелей и соединительного кабеля рабочей станции. Приходится снова вер­нуться к шкафу, вставить кабель в первоначальный порт коммутатора, получить новый соединительный кабель рабочей станции и вернуться к ней. Заменяется кабель рабо­чей станции и вновь делается попытка выполнить команду ping с адресом сервера (см. пример 18.5). В этот раз результат выполнения команды положительный, поэтому проблему можно считать решенной. Последним шагом является занесение описания того как решалась проблема в соответствующие документы. Это следует сделать в отче­те об устранении неисправности и вернуть отчет в отдел помощи, с тем чтобы пробле­ма была зарегистрирована как решенная. Следует также занести решение проблемы в инженерный журнал для будущих справок.

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