Процесс устранения проблем Владимир Борисович Лебедев ТТИ ЮФУ © 2010 кафедра

устранению проблем

проблем. Опытные специалисты при диагностике неполадок часто полагаются на интуицию,

но существуют и четко структурированные алгоритмы для установления наиболее вероятной причины и поиска решения.

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

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

проблемы. Подтвердив существование проблемы, можно приступить к ее решению, начав

со сбора информации.

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

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

Для сбора сведений о сети можно также применять инструментальные средства мониторинга сети – развитые приложения, получившие широкое распространение в крупных сетях для непрерывного сбора сведений о состоянии сети и сетевых устройств. Эти инструментальные средства могут быть недоступны для сетей малого масштаба.

После сбора необходимой информации можно приступить к устранению проблемы.

том числе следующие:
"Сверху вниз"
"Снизу вверх"
"Разделяй и властвуй"

Все

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

прикладного уровня. Проблема исследуется с точки зрения пользователя и приложения.

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

Прикладной
Представление
Сессия

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

соединения. Не выпали ли кабели из гнезд? Если оборудование снабжено индикаторами, горят ли индикаторы?

с одного из промежуточных уровней, после чего обследуются вышестоящие или

нижестоящие уровни. Например, можно начать диагностику проблемы с сетевого уровня, проверив конфигурацию IP.

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

своими знаниями, пытаясь установить наиболее вероятную причину проблемы. Он формулирует

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

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

с некоторым компонентом или файлом конфигурации. Дефектный компонент или ошибочный

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

Пример способа замены – замена Интернет-провайдером устройства, исправность которого вызывает подозрения, вместо командирования техника для диагностики и локализации проблемы. Замена наиболее целесообразна для недорогих компонентов, например сетевых плат и соединительных кабелей.