Базовая модель поиска ошибок

 

Базовая модель поиска ошибок предусматривает последо­вательное выполнение администратором системы следующих действий [30].

1. Убедиться в том, что ошибки действительно есть. Дру­гими словами после сообщения пользователя о некорректной работе ИС надо убедиться в том, что этот пользователь выпол­няет все процедуры корректно и правильно оценивает работу ИС. Например, некая операция действительно занимает много времени, а пользователь считает, что ИС медленно работает.

2. Провести инвентаризацию. Это означает, что необхо­димо выяснить, все ли части ИС на месте: все кабели су­ществуют, все части ИС взаимодействуют и правильно соединены. При этом NMS может помочь провести авто­матический опрос параметров работы оборудования и про­граммного обеспечения, дать план системы. У администра­тора системы должна быть исполнительная документация по ИС с картой сети и списками всех параметров загрузки серверов, рабочих станций, коммутационного оборудования (worksheet). Нужно убедиться в том, что «все на месте» и со­ответствует документации.

3. Сделать копии ИС (backup). Причем желательно это де­лать «быстрыми средствами» (например не утилитой копи­рования СУБД, а утилитами ОС «том в том» или «диск в диск»).

4. Сделать перезагружу всех компонент ИС (restart). Есть два режима перезагрузки: холодный режим (с отключением питания) и горячий режим (без отключения питания). При холодном рестарте заново загружается все ПО оборудования, все драйверы, все процессы ОС и СУБД, заново инициализи­руется память серверов. Поэтому при ошибочных ситуациях надо использовать холодный рестарт. Однако если есть ошиб­ки оборудования, то оно после этого может вообще не загру­зиться. Перед перезагрузкой нужно не забыть завершить ра­боту всех процессов различных ОС и СУБД (обычно команды типа Down или Shutdown).

5. После перезагрузки необходимо упростить работу ИС, например, завершить работу всех резидентных программ, не обязательных для работы в простейшем варианте ИС.

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

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

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

9. Необходимо разработать план по изоляции ошибки. Для этого строятся гипотезы о причинах ошибки в ИС. Это мо­гут быть ошибки каналов связи (80% всех ошибок), аппарат­ные ошибки, ошибки системного программного обеспече­ния, прикладного программного обеспечения. Всегда следует учитывать, что тираж аппаратных средств больше, чем тираж программных продуктов. Например, процессоров Intel выпу­скается больше, чем установок какой-либо одной ОС, поэтому аппаратных ошибок будет меньше, чем программных. Анало­гично тираж системного программного обеспечения больше, чем тираж прикладного ПО, поэтому в первом меньше оши­бок, чем в последнем. Просто чем больше тираж продукта, тем лучше он отлажен.

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

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

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

 

 

8.3. Стратегии определения ошибок

Существуют два подхода к поиску неисправностей — теоре­тический и практический.

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

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

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

Стратегия управления ошибками может быть проактивной либо реактивной. С ростом объема ИС возрастает потребность в ее надежности и, соответственно, возрастает потребность в предварительном мониторинге производительности системы, предупреждениях пользователям о возможных проблемах, постоянной бдительности администратора системы. Такая стратегия предупреждения ошибок называется проактивной. Стратегия, при которой АС не предупреждает появление оши­бок, а разбирается с ошибками по мере их возникновения, называется реактивной. АС должен приложить усилия и воспользоваться средствами MS или NMS для перехода от реактив­ной стратегии к проак­тивной.

Обычно системы управ­ления отказами (ошиб­ками) — NMS разбивают сложную задачу иденти­фикации и диагностики ошибки на четыре подза­дачи [64]:

1. Определение ошибки;

2. Генерация тревожно­го сигнала;

3. Изоляция ошибки;

4. Коррекция ошибки.

При этом возможны две технологии работы NMS — пассивная и активная.

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

Активная технология. Система NMS тестирует ИС (на­пример, с помощью утилиты PING) и опрашивает каждое из устройств на регулярной основе. Если какое-либо устройство не реагирует в заданный администратором системы интервал времени или его параметры отличаются от желаемых, посы­лается сообщение администратору системы о сбое устройства. Иногда этот процесс называют up/down monitoring.

АС должен выбрать систему управления, позволяющую ис­пользовать обе стратегии. Кроме того, правильно спроектиро­ванная система управления дает возможность администратору системы выполнять далее перечисленные логические действия по управлению ошибками [64].

1. Выбрать время, когда управление ошибками осуществля­ется полностью, не осуществляется вовсе или осуществляется частично. Время работы ИС определяется в специальном до­кументе — соглашении об уровне сервиса SLA (Service Level Agreement). И это время может отличаться от часов работы данного предприятия. Например, предприятие работает с 9.00 до 18.00, а ИС работает 24 часа, 7 дней в неделю и 365 дней в году. Часть времени ИС может быть занято под специальные действия, не требующие контроля над возможными ошибка­ми. Это можно указать в параметрах настройки MS. Например, мониторинг ошибок проводится в течение 20 из 24 часов. Если это требование выполняется, считается, что ошибок нет.

2. При настройке MS создать специальные триггеры, опре­деляющие, какую ситуацию в данной системе следует рассма­тривать как ошибочную. В некоторых случаях надо подавлять сообщения об ошибках. Например, сообщение о том, что про­изводительность упала на 0,5%, что не существенно для боль­шинства систем.

3. Настроить параметры автоматической перезагрузки си­стемы и переустановки параметров (reset). Можно настроить параметры MS так, чтобы в определенных случаях система сама перезагружалась и устанавливала определенные параме­тры в номинальные значения.

4. Установить подавление предупреждений об ошибках в некоторых случаях. Например, если известен дефект работы устройства, но он не влияет на работу ИС.