Комментарий редактора. В июньской рубрике «Тысяча мелочей» Стив Литт уже делился своими советами о том, что делать, когда при диагностировании вы сталкиваетесь с, казалось бы, неразрешимой проблемой. В этом месяце Литт вновь предлагает свои советы и рекомендации. Другие статьи Стива Литта, в том числе об его 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 в разделе «Тысяча мелочей». О других ошибках и исправлениях читатель может узнать на сервере 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.