Тысяча мелочей

Девин Вольф

Советы и рекомендации по диагностированию

Комментарий редактора. В июньской рубрике «Тысяча мелочей» Стив Литт уже делился своими советами о том, что делать, когда при диагностировании вы сталкиваетесь с, казалось бы, неразрешимой проблемой. В этом месяце Литт вновь предлагает свои советы и рекомендации. Другие статьи Стива Литта, в том числе об его 10-этапном универсальном процессе диагностирования, можно прочитать на http://www.troubleshooters.com.

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

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

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

Помните: диагностическое программное обеспечение — отличный инструмент, но плохое решение.

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

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

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

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

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

Я ввел контроль версий для нестандартного приложения и распорядился, чтобы все инсталляции осуществлялись с одной ленты с определенной версией. В результате количество проблем сократилось на 400%.

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

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

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

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

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

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

Лекарство от голубых экранов

Комментарий редактора. Следующий совет был предоставлен менеджером по технической поддержке Windows NT из компании Executive Software (http://www.executive.com).

Я нашел потрясающее противоядие от сообщений INACCESSIBLE_BOOT_DEVICE. Эта ошибка может случиться при инсталляции нового адаптера или контроллера SCSI, если в драйвере для загрузочного устройства произойдет сбой в процессе инициализации, либо после выполнения chkdsk.

Если у вас появился голубой экран с таким сообщением, то возьмите дискеты с Windows NT Setup Boot и начните новую инсталляцию. Не надо никаких обновлений, просто выберите N для новой инсталляции. Получив запрос ввести имя каталога, укажите WINNT2, просто добавив цифру 2 в конец предлагаемого местонахождения. Когда потребуется выбирать раздел, выберите Leave the Current File System.

Произведя инсталляцию в тот же самый раздел, вы сможете провести полное сканирование. То, что надо! После завершения полного сканирования вы увидите сообщение о том, что изменения были произведены, и запрос нажать F8 для перезапуска компьютера и перехода к настройке. Выньте дискету (или CD-ROM) и перезапустите компьютер. Когда вы зарегистрируетесь в своей обычной инсталляции, то не будет никакого каталога WINNT2 и никаких изменений в boot.ini, а будет просто восстановленная инсталляция NT.

Один раз мне довелось помогать администратору проделать эту процедуру, и, когда сервер ожил, я был вознагражден радостными криками.

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

Сообщения BugNet

Комментарий редактора. Мы регулярно публикуем сообщения BugNet в разделе «Тысяча мелочей». О других ошибках и исправлениях читатель может узнать на сервере http://www.bugnet.com.

AppleShare IP Mail

Apple выпустила AppleShare IP Mail 6.2.1 для исправления всего одной ошибки. Если поступающее сообщение электронной почты содержит пустое поле From:, то в версии 6.2 оно будет удалено, причем ни адресат, ни администратор не будут об этом извещены.

Lotus Domino Server

Lotus обнаружила несовместимость между своими Lotus Domino Server 4.5x и 4.6х и браузерами Navigator 3.x и Communicator 3.х компании Netscape. При использовании этих браузеров вы не сможете зарегистрироваться на сервере Domino с помощью своего имени и пароля, так как рамки для ввода имени и пароля будут содержать разные символы с акцентами, тильдами и умляутами. Как утверждает Lotus, это связано с тем, что браузеры Netscape несовместимы со стандартом ISO-8859-1 для имен и паролей пользователей. По сообщению той же Lotus, компания Netscape намеревается ликвидировать этот недостаток в пятой версии. Тем временем вы можете использовать браузеры Microsoft Internet Explorer.

Netscape Directory Server

Netscape представила файл с исправлениями к Netscape Directory Server 4.01 для предотвращения утечки памяти. Утечка происходит, когда пользователь регистрируется в каталоге обычным способом, и не происходит, когда он регистрируется как анонимный или с помощью корневого отличительного имени (Root Distinguished Name, RDN). Файл подходит как для американской, так и для экспортной версии Directory Server 4.0 и заменяет файл libslapd.file. Его можно получить на http://help.netscape.com/products/server/directory/401readme.html.

УВАЖАЕМЫЕ ЧИТАТЕЛИ!

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