0
gx6060
Staff member
- Nov 10, 2019
- 259
- 313
Общие процедуры поиска и устранения неполадок
Устранение неполадок может занять много времени, поскольку сети отличаются друг от друга, проблемы различаются и опыт устранения неполадок различается. Однако опытные администраторы знают, что использование структурированного метода устранения неполадок сократит общее время устранения неполадок.
Поэтому процесс устранения неполадок должен быть ориентирован на структурированные методы. Это требует четко определенных и документированных процедур устранения неполадок, чтобы свести к минимуму затрачиваемое время, связанное с нерегулярным поиском и устранением ошибок. Однако эти методы не являются статичными. Действия по устранению неполадок, предпринятые для решения проблемы, не всегда одинаковы или выполняются в том же порядке.
Существует несколько процессов устранения неполадок, которые можно использовать для решения проблемы. На рисунке показана логическая схема упрощенного трехэтапного процесса устранения неполадок. Тем не менее более подробный процесс может быть более полезным для решения сетевой проблемы.
Семиэтапный процесс устранения неисправностей
Цель этого этапа заключается в том, чтобы убедиться, что есть проблема, а затем правильно определить, что проблема. Проблемы обычно определяются симптомом (например, сеть работает медленно или перестала работать). Симптомы могут отображаться в разном виде (предупреждения из системы управления сетями, консольные сообщения и жалобы пользователей).
В ходе сбора данных о симптомах важно, чтобы сетевой администратор задавал вопросы и расследовал проблему с целью локализации проблемы до более узкого круга возможных причин ее появления. Например, распространяется ли проблема на одно устройство, группу устройств, подсеть или всю сеть устройств?
В организации проблемы обычно назначаются сетевым специалистам в качестве заявок на неполадки. Эти заявки создаются с помощью программного обеспечения для продажи билетов на неполадки, которое отслеживает ход выполнения каждого билета. Программное обеспечение для продажи билетов может также включать портал самообслуживания для отправки билетов, доступ к базе знаний о неисправностях с возможностью поиска, возможности удаленного управления для решения проблем конечных пользователей и многое другое.
В ходе сбора данных о симптомах важно, чтобы сетевой администратор задавал вопросы и расследовал проблему с целью локализации проблемы до более узкого круга возможных причин ее появления. Например, распространяется ли проблема на одно устройство, группу устройств, подсеть или всю сеть устройств?
В организации проблемы обычно назначаются сетевым специалистам в качестве заявок на неполадки. Эти заявки создаются с помощью программного обеспечения для продажи билетов на неполадки, которое отслеживает ход выполнения каждого билета. Программное обеспечение для продажи билетов может также включать портал самообслуживания для отправки билетов, доступ к базе знаний о неисправностях с возможностью поиска, возможности удаленного управления для решения проблем конечных пользователей и многое другое.
На этом этапе необходимо определить цели (т.е. хосты, устройства), подлежащие исследованию, получить доступ к оконечным устройствам и собрать информацию. На этом этапе технический специалист может собирать и документировать больше симптомов в зависимости от выявленных характеристик.
Если проблема выходит за границы области контроля организации (например потеря связи через Интернет за пределами автономной системы), обратитесь к администратору внешней системы до сбора информации о других симптомах.
Если проблема выходит за границы области контроля организации (например потеря связи через Интернет за пределами автономной системы), обратитесь к администратору внешней системы до сбора информации о других симптомах.
Должны быть определены возможные причины. Собранная информация интерпретируется и анализируется с помощью сетевой документации, базовых показателей сети, поиска организационных баз знаний, поиска в Интернете и общения с другими техниками.
Если выявлено несколько причин, то перечень должен быть сокращен путем постепенного устранения возможных причин, с тем чтобы в конечном итоге определить наиболее вероятную причину. Опыт устранения неполадок чрезвычайно важен для быстрого устранения причин и выявления наиболее вероятной причины.
Когда выявлена наиболее вероятная причина, необходимо сформулировать решение. На данном этапе опыт устранения неполадок очень полезен при разработке плана.
Перед тестированием решения важно оценить влияние и актуальность проблемы. Например, может ли решение оказать негативное воздействие на другие системы или процессы? Уровень серьезности проблемы всегда следует соотносить со степенью влияния решения. Например, если критически важный сервер или маршрутизатор необходимо выключить на длительное время, то реализацию исправления лучше отложить на конец рабочего дня. В ряде случаев до разрешения фактической проблемы можно применить обходное или временное решение.
Создайте план отката, определяющий, как быстро можно отменить решение. Это может оказаться необходимым в случае если решение не привело к успеху.
Реализовать решение и убедиться, что оно решило проблему. Иногда решение создает неожиданную проблему. Поэтому важно, чтобы решение было тщательно проверено, прежде чем перейти к следующему шагу.
Если решение не удается, попытка решения документируется, и изменения удаляются. Специалист должен вернуться к этапу сбора информации и изолировать проблему.
Создайте план отката, определяющий, как быстро можно отменить решение. Это может оказаться необходимым в случае если решение не привело к успеху.
Реализовать решение и убедиться, что оно решило проблему. Иногда решение создает неожиданную проблему. Поэтому важно, чтобы решение было тщательно проверено, прежде чем перейти к следующему шагу.
Если решение не удается, попытка решения документируется, и изменения удаляются. Специалист должен вернуться к этапу сбора информации и изолировать проблему.
Для устранения проблем следует общаться с пользователями и любыми сотрудниками, принимающими участие в процессе поиска и устранения неполадок. Информацию о разрабатываемом решении должны получить другие сотрудники отдела ИТ. Наличие соответствующим образом оформленной документации о причине проблемы и способе ее устранения позволит другим техническим специалистам предотвращать либо устранять похожие проблемы в будущем.
Опрос конечных пользователей.
Многие проблемы в сети изначально сообщаются конечным пользователем. Однако представленная информация зачастую является расплывчатой или вводящей в заблуждение. Например, пользователи часто сообщают о проблемах, таких как «сеть упала», «я не могу получить доступ к электронной почте» или «мой компьютер работает медленно».
В большинстве случаев для полного понимания проблемы требуется дополнительная информация. Обычно это предполагает взаимодействие с затронутым пользователем, чтобы ответить на вопросы «кто», «что» и «когда».
При общении с пользователем следует использовать следующие рекомендации:
- Говорите с пользователями на том техническом языке, который ему понятен.
- Всегда слушайте или внимательно читайте, что говорит пользователь. Заметки могут быть полезны при документировании сложной проблемы.
- Всегда будьте внимательны и сопереживать с пользователями, давая им знать, что вы поможете им решить их проблему. Пользователи, сообщающие о проблеме, могут быть в состоянии стресса и стремиться решить проблему как можно быстрее.
| Рекомендации | Примеры вопросов конечному пользователю |
|---|---|
| Задайте соответствующие вопросы. |
|
| Определите масштаб проблемы. |
|
| Определите, когда возникла проблема. |
|
| Определите, является ли проблема постоянной или прерывистой. |
|
| Определите, менялось ли что-то. | Что изменилось с тех пор, когда все еще нормально работало? |
| Используйте каждый вопрос в качестве средства исключения или обнаружения возможных проблем. |
|
Сбор информации
Чтобы собрать симптомы от подозрительного сетевого устройства, используйте команды Cisco IOS и другие инструменты, такие как захват пакетов и журналы устройства.
| Команда | Описание |
|---|---|
| ping {host | ip-address} |
|
| traceroute destination |
|
| telnet {host | ip-address} |
|
| ssh -l user-idip-address |
|
| show ip interface brief show ipv6 interface brief |
|
| show ip route show ipv6 route | Позволяет отобразить текущие таблицы маршрутизации IPv4 и IPv6, в которых указаны маршруты ко всем известным сетевым пунктам назначения. |
| show protocols | Отображает настроенные протоколы и показывает общее и специфичное для интерфейса состояние любого настроенного протокола уровня 3 |
| debug | Отображение списка параметров для включения или отключения событий отладки. |
Примечание: Несмотря на то что команда debug является важным средством сбора данных о симптомах, она создает большой объем трафика консольных сообщений, существенно снижая производительность сетевого устройства.
Если команду debug необходимо выполнить в обычное рабочее время, предупредите пользователей сети о планируемых процедурах по поиску и устранению неполадок, а также о возможном снижении производительности сети. По окончании процедуры не забудьте отключить режим отладки.
Устранение неполадок с использованием Уровневой модели
Такие многоуровневые модели можно применять к физической сети для изоляции сетевых проблем при поиске и устранении неполадок. Например, если все признаки указывают на проблему с физическим подключением, то сетевой специалист может сосредоточиться на устранении неполадок на канале, который работает на физическом уровне.
Структурированные методы устранения неполадок
Существует несколько структурированных подходов к устранению неполадок, которые могут быть использованы. Какой из них выбрать, будет зависеть от ситуации. Каждый метод имеет свои достоинства и недостатки.
При поиске и устранении неполадок с помощью метода «снизу вверх» следует начинать с физических компонентов сети и перемещаться вверх через уровни модели OSI до тех пор, пока не будет определена причина проблемы, как показано на рисунке.
Метод «снизу вверх» хорошо подходит в тех случаях, когда предполагается, что проблема находится на физическом уровне. Большинство сетевых проблем находятся на нижних уровнях, поэтому реализация метода «снизу вверх» во многих случаях является довольно эффективной.
Недостаток метода «снизу вверх» заключается в том, что необходимо проверять каждое устройство и интерфейс в сети до тех пор, пока не будет найдена возможная причина проблемы. Следует помнить, что каждое заключение и каждую возможность необходимо документировать, поэтому при выполнении данного метода может быть необходимо выполнять много работы с бумажными документами. Другим потенциальным недостатком является необходимость определения устройств, с которых необходимо начать процесс анализа.
Метод «снизу вверх» хорошо подходит в тех случаях, когда предполагается, что проблема находится на физическом уровне. Большинство сетевых проблем находятся на нижних уровнях, поэтому реализация метода «снизу вверх» во многих случаях является довольно эффективной.
Недостаток метода «снизу вверх» заключается в том, что необходимо проверять каждое устройство и интерфейс в сети до тех пор, пока не будет найдена возможная причина проблемы. Следует помнить, что каждое заключение и каждую возможность необходимо документировать, поэтому при выполнении данного метода может быть необходимо выполнять много работы с бумажными документами. Другим потенциальным недостатком является необходимость определения устройств, с которых необходимо начать процесс анализа.
Сперва тестируются приложения конечных пользователей в оконечных системах, а затем процесс затрагивает более конкретные участки сети. Этот метод можно использовать для устранения простых проблем или когда предполагается, что проблема связана с некоторым элементом программного обеспечения.
Недостаток метода «сверху вниз» заключается в том, что необходимо проверять каждое сетевое приложение до тех пор, пока не будет найдена возможная причина проблемы. Каждое заключение и возможность необходимо документировать Другим потенциальным недостатком является необходимость определения приложения, с которого необходимо начать процесс анализа.
Недостаток метода «сверху вниз» заключается в том, что необходимо проверять каждое сетевое приложение до тех пор, пока не будет найдена возможная причина проблемы. Каждое заключение и возможность необходимо документировать Другим потенциальным недостатком является необходимость определения приложения, с которого необходимо начать процесс анализа.
В случае применения метода «деления пополам» сначала следует ознакомиться с накопленным опытом устранения аналогичных проблем, затем задокументировать симптомы, а потом на основе полученной информации сделать квалифицированное предположение об уровне OSI, с которого нужно начать свой анализ.
Когда будет установлено, что данный уровень функционирует нормально, можно будет предположить, что уровни, расположенные ниже, также функционируют нормально. Администратор может перемещаться вверх по уровням OSI. Если уровень взаимодействия открытых систем (OSI) функционирует неправильно, то администратор может перемещаться вниз по уровням OSI.
Например, если пользователи не могут получить доступ к веб-серверу, но могут отправлять эхо-запросы на сервер, это означает, что проблема находится выше уровня 3. Если попытка отправки эхо-запроса на сервер завершается сбоем, то проблема предположительно находится на более низком уровне OSI.
Когда будет установлено, что данный уровень функционирует нормально, можно будет предположить, что уровни, расположенные ниже, также функционируют нормально. Администратор может перемещаться вверх по уровням OSI. Если уровень взаимодействия открытых систем (OSI) функционирует неправильно, то администратор может перемещаться вниз по уровням OSI.
Например, если пользователи не могут получить доступ к веб-серверу, но могут отправлять эхо-запросы на сервер, это означает, что проблема находится выше уровня 3. Если попытка отправки эхо-запроса на сервер завершается сбоем, то проблема предположительно находится на более низком уровне OSI.
Это один из самых основных методов устранения неполадок. Подход сначала обнаруживает фактический путь трафика на всем пути от источника к месту назначения. Область устранения неполадок сводится только к каналам и устройствам, которые находятся на пути пересылки. Цель состоит в том, чтобы устранить каналы и устройства, которые не имеют отношения к задаче устранения неполадок. Этот подход обычно дополняет один из других подходов.
Этот подход также называется замена компонентов (swap-the-component), потому что вы физически заменяете проблемное устройство на гарантированное рабочее. Если проблема исправляется, то администратор сети убеждается, что причина этой проблемы находится внутри извлеченного устройства. Если проблема сохраняется, то причину следует искать в другом месте.
В некоторых случаях это может быть идеальным способом быстрого устранения проблем, например, если наиболее важный компонент (единая точка отказа), предположим, пограничный маршрутизатор, выходит из строя. В данном случае важнее просто заменить устройство и восстановить нормальную работу, чем устранить неполадки в работе устройства.
Если проблема находится в нескольких устройствах, возможно, не удастся правильно изолировать проблему.
В некоторых случаях это может быть идеальным способом быстрого устранения проблем, например, если наиболее важный компонент (единая точка отказа), предположим, пограничный маршрутизатор, выходит из строя. В данном случае важнее просто заменить устройство и восстановить нормальную работу, чем устранить неполадки в работе устройства.
Если проблема находится в нескольких устройствах, возможно, не удастся правильно изолировать проблему.
Этот подход также называется подходом, основанным на различиях, и предпринимаются попытки решить проблему путем изменения не рабочих элементов, с тем чтобы они соответствовали рабочим элементам. Вы сравниваете конфигурации, версии программного обеспечения, оборудование или другие свойства устройства, связи или процессы между рабочими и нерабочими ситуациями и обнаруживаете существенные различия между ними.
Применение данного метода может позволить получить нужное решение, но без четкого выявления причины проблемы.
Применение данного метода может позволить получить нужное решение, но без четкого выявления причины проблемы.
Этот подход также называется подходом к поиску и устранению неисправностей от бедра. Это менее структурированный метод устранения неполадок, который использует предположение, основанное на симптомах проблемы. Успех этого метода зависит от опыта и возможностей устранения неполадок.
Опытные специалисты добиваются большего успеха, поскольку они могут полагаться на свои обширные знания и опыт для решительной изоляции и решения сетевых проблем. Если сетевой администратор не обладает большим опытом, то данный метод может превратиться в метод проб и ошибок и часто походит на процесс случайного поиска неполадок.
Опытные специалисты добиваются большего успеха, поскольку они могут полагаться на свои обширные знания и опыт для решительной изоляции и решения сетевых проблем. Если сетевой администратор не обладает большим опытом, то данный метод может превратиться в метод проб и ошибок и часто походит на процесс случайного поиска неполадок.
Указания по выбору метода для поиска и устранения неполадок
Для быстрого устранения сетевых проблем найдите время, чтобы выбрать наиболее эффективный метод отладки сети.
Устранение неполадок - это навык, который развивается в результате этого. Каждая сетевая проблема, которую вы идентифицируете и решаете, добавляется в ваш набор навыков.
Last edited by a moderator: