Локальные сети охватывают разнообразные компоненты: принтеры, терминальные устройства, персональные компьютеры, IP-телефоны, серверы, устройства хранения, сетевое оборудование, программное обеспечение безопасности, сетевые приложения, корпоративные приложения, офисные пакеты и многое другое. Мы сосредоточимся на первом и втором уровнях сетевой модели OSI: физическом уровне (среде передачи) и коммутаторах. Кабельная система и коммутаторы — это основа современных локальных сетей.

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

МЕТОД НА ВСЕ СЛУЧАИ ЖИЗНИ

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

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

ПОДХОД К РАБОТЕ

Успешно обнаружить и устранить сетевые неисправности может лишь тот, кому досконально известно, как должна работать сеть в нормальном режиме. Только при таком условии можно быстро распознать отклонение от нормы и диагностировать неполадку.

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

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

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

Кабинетный ученый будет раз за разом анализировать ситуацию, пока однозначно не установит причину проблемы и хирургически точный метод ее устранения. Для такого анализа нужен многофункциональный (и потому очень дорогой) анализатор протоколов и колоссальная выборка данных по сетевому трафику — мегабайты информации. Этот подход дает вполне достоверные результаты, но мало кто согласится, чтобы корпоративная сеть простаивала те часы и даже дни, пока идет глубокий анализ.

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

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

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

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

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

Очень важно помнить: после устранения проблемы требуется проверка восстановленного оборудования или системы, сколь бы просты ни были проведенные действия. Слишком часто оказывается, что какой-то очевидный симптом, на самом деле, — следствие скрытой проблемы, и пока не устранить причину, сбой будет появляться снова и снова.

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

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

УСТРАНЕНИЕ СБОЕВ ЗА ВОСЕМЬ ШАГОВ

Шаг 1. Определение сути проблемы. Очень важно правильно описать проблему и определить ее суть. Попросите человека, сообщившего о неисправности, подробно охарактеризовать нормальный режим работы системы, а затем продемонстрировать, в чем проблема. Если сбой то появляется, то исчезает, попросите немедленно сообщить вам, как только проблема появится снова. Крайне сложно устранить причину, если в данный момент все работает замечательно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда сбой затрагивает аппаратную часть, самый верный путь — заменить неисправный элемент оборудования, чтобы попытаться отремонтировать вышедший из строя компонент позже, без спешки. Другой вариант — перевести соединение на свободный порт, а тот, который вызывает подозрение, закрыть заглушкой или отметить как неисправный. Помните, что первоочередная задача — максимально быстро восстановить работоспособность сети. Все остальное можно сделать потом.

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

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

Шаг 6. Удостовериться, что проблема устранена. После применения запланированных мер пользователь должен проверить, может ли он работать нормально: пусть он выполнит несколько типовых действий. Довольно часто решение одной проблемы вызывает появление других. Случается и так, что устранение одного сбоя лишь ведет к проявлению симптомов, которые не были заметны на его фоне.

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

Шаг 8. Информирование пользователя. Зачастую после устранения проблемы возникает искушение на том и закончить. Однако пользователь, раз уж обратился за помощью, будет признателен, если вы все-таки объясните ему, что произошло. В случае повторения подобного сбоя он сможет быстрее распознать опасную ситуацию и сразу сообщить о ней, тогда и работоспособность сети будет выше. Кроме того, разъясняя, что можно делать, а чего нельзя, вы снижаете вероятность возникновения аналогичного сбоя в будущем.

Умение поддерживать контакт с пользователями очень важно для отдела ИТ: это позволяет лучше обслуживать сеть, что выражается в уменьшении количества сбоев и времени простоя. Если вы не принимаете обращения сотрудников всерьез или делаете едкие замечания насчет их умений и навыков, то такое поведение не характеризует вас как профессионала. В результате ваши отношения с ними станут натянутыми, а такое противостояние только мешает успешной работе.

Как известно, решение любой сетевой проблемы на 75% состоит в разрешении проблем с пользователем. Если он не согласился с вами, что дело доведено до логического завершения (и неважно, устранили ли вы неполадку или привели тысячу причин — финансовых, технических, политических, — по которым она не может быть устранена), это означает, что работу по заявке вы не закончили.

С ЧЕГО НАЧАТЬ

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

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

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

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

И последнее: руководства и учебные курсы могут давать глубокие знания в одной области компьютерных сетей и не вполне корректные данные в другой. Один из признаков того, что вы хорошо освоили тот или иной аспект сетевых технологий — четкое понимание того, в чем состоит сбой и где он мог произойти.

Игорь Панов — региональный менеджер по продукции и поддержке парт-неров Fluke Networks в России и СНГ. С ним можно связаться по адресу: igor.panov@flukenetworks.com.