Ваши правила устранения неполадок, подход к устранению неполадок? [закрыто]

Есть ли у вас какие-либо общие правила, к которым вы прибегаете при устранении неполадок в сложной сетевой / аппаратной / программной проблеме?

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

Просто список пунктов, которые я записал для себя после некоторой борьбы с проблемой:

1. Какова ваша основная цель ? Должно быть изложено четко и кратко. Цель должна быть очень конкретной. Это не должно быть общим. Желательно одно предложение .
   
2. В чем твоя проблема ?
   
3. Есть только одна проблема или много ? Если их много, решайте их по одному.
   
4. Попробуйте воспроизвести проблему с разными условиями . Может ли оно быть воспроизведено во всех возможных условиях или нет? Это говорит что-нибудь о природе проблемы?
   
5. Если это актуальная проблема, есть ли обходной путь ? Попробуйте найти как можно больше обходных путей.
   
6. Постарайтесь сделать как можно больше предположений о том, что является причиной вашей проблемы.
   
7. Попробуйте доказать свои догадки, поэкспериментируйте с системой.
   
8. Будьте внимательны в том, что вы пытаетесь сделать. Делай одну вещь за раз.
   
9. Следите за тем, что вы делаете, что вы уже пробовали.
   
10. Не отклоняйтесь от своей основной цели. Постоянно проверяйте, решаете ли вы свою основную проблему, а не другую.
    
11. Не зацикливайся тоже.

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

• Если проблема связана с Интернетом, это, вероятно, DNS.

• Если проблему трудно диагностировать, это, вероятно, ОЗУ.

• Если проблема связана с рабочей станцией Windows, возможно, ее быстрее всего переизобразить.

• Если проблема в пятницу, возможно, это что-то серьезное.

Мне нравится возвращаться к научному методу .

От ( http://en.wikipedia.org/wiki/Scientific_method )

1. Определите вопрос
2. Сбор информации и ресурсов (наблюдать)
3. Форма гипотезы
4. Проведите эксперимент и соберите данные
5. Анализировать данные
6. Интерпретировать данные и сделать выводы, которые послужат отправной точкой для новой гипотезы
7. Результаты документа

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

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

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

У О'Рейли есть хорошая книга « Инструменты для устранения неполадок с сетью», в которой есть хороший набор шагов, которые нужно выполнить, и это очень похоже на научный метод. Я нашел книгу очень полезной и настоятельно рекомендую ее. Книга углубляется в детали и предлагает множество полезных инструментов.

Из инструментов устранения неполадок сети

1. Укажите свою цель
2. Определить систему
3. Определить возможные результаты
4. Определите и выберите, что вы будете измерять
5. При необходимости укажите тестовые параметры и факторы
6. Выберите инструменты
7. Установить ограничения измерений
8. Обзор экспериментального дизайна
9. Собирать данные
10. Анализировать данные

Смотрите также:

• 3COM имеет руководство по устранению неполадок
• Закон Мерфи - все, что может пойти не так, делает.
• Occam's_razor - При прочих равных условиях самое простое решение - лучшее.

(Эти основные моменты перефразированы из главы «Отладка» «Практики системного и сетевого администрирования» )

Две вещи, которые нужно знать:

1. Знайте, как выглядит «фиксированная» версия. Предпочтительно команда, которую вы можете запустить, которая дает определенный вывод, когда все работает. Например: я пытаюсь выяснить, почему SSH запрашивает пароль, когда я правильно настроил ключи (или я так думал). Итак, мой тест: «ssh servername uptime», и он должен работать без запроса пароля.

2. Опишите проблему на правильном уровне. Пользователь, жалующийся на то, что он не может пропинговать сервер, не должен отправлять вас на запуск и исправление сервера. Работа человека не в том, чтобы сидеть и пинговать машину целый день. Они хотят выполнить какую-то задачу, например, использовать машину в качестве своего DNS-сервера. Пример: однажды пользователь пожаловался, что не может пинговать машину на полпути по всему миру. Я провожу день, выслеживая сисадминов в этой части компании, чтобы выяснить, что не так с этой машиной. Это было списано, и они были в панике, потому что они думали, что, возможно, они выключили не ту машину. Я связался с пользователем и сказал: «Помимо необходимости пинговать эту машину, что бы вы хотели с ней делать?». Оказалось, что он хотел выполнить на нем определенную работу, и если бы он следовал правильной процедуре, его задачи были бы автоматически перенаправлены на заменяющую машину. Я потратил впустую весь свой день и время местных сисадминов. Еще одна причина, по которой «я не могу пропинговать», не подходит для тестирования: часто брандмауэры настроены для отбрасывания пакетов ping, но пропускают другие пакеты. Проверьте, что вы хотите пройти.

Две стратегии:

1. Добавка: продолжайте добавлять компоненты, пока проблема не начнется. Последнее, что вы добавили, это проблема. Пример: веб-браузеры не могут общаться с сервером. Между сервером и пользователем находится балансировщик нагрузки, брандмауэр, кэш и локальный веб-прокси пользователя. Сначала попробуйте отправить запросы непосредственно на сервер, затем через LB на сервер, затем через межсетевой экран на LB на сервер и т. Д. И т. Д. Каждый раз, добавляя один компонент.

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

Два кусочка тупой удачи:

1. Забудь все, что я сказал. Проблема вызвана последним изменением в системе. (это работает в 99% случаев ... проблема в том, что в 99% случаев вы не знаете, каким было последнее изменение)

2. Когда все остальное терпит неудачу, проверьте на глупые вещи. http://whatexit.org/tal/mywritings/dumb-things-to-check.html Пример: сумасшедшую проблему просто невозможно объяснить. Затем мы проверили файл конфигурации: пользователь отредактировал его, скопировав его в окно Windows, отредактировав его, а затем скопировав обратно. Теперь он имел ^ M в конце каждой строки. Мы никогда не замечали, потому что наш текстовый редактор молча скрывал этот факт. К сожалению, программное обеспечение, которое считывает файл конфигурации, превратило эти ^ Ms в пространство без перерыва, которое испортило тонны других процедур.

Общие практики, которые я помню в течение всего процесса:

1. Запишите все, что я делаю вниз.
2. Сделайте только одно изменение за раз.
3. Если возможно, отмените изменение, прежде чем пытаться выполнить другое, если не достигнут определенный прогресс.

Во время устранения неполадок здесь определяется моя основная методология:

• Когда система работает и работает хорошо, прежде чем возникнет проблема, я пытаюсь понять, что она делает. Джо Ричардс объясняет, почему намного лучше, чем я мог в этом коротком пространстве .
• Я начну с самого простого решения. Например, нет подключения к сети? Проверьте физический уровень. Я не могу сказать вам, сколько раз прерывистые проблемы с подключением были не проблемой сервера, а сетевым кабелем, который был наполовину или неисправным.
• Я пытаюсь охватить все симптомы, которые я вижу из всех вероятных источников, прежде чем я начну вносить изменения.
• Я провожу предварительные диагностические тесты. Например, когда мне говорят, что сервер не работает, первое, что я делаю, это использую ping и nbtstat (Windows), чтобы проверить это. Проблема может быть на дальнем конце (если позаимствовать старое высказывание технического контроля ВВС).
• Я не боюсь проводить исследования. Google, support.microsoft.com, eventid.net и подобные сайты являются вашими друзьями.
• Я не боюсь просить помощи у сообщества. Не только такие сайты, как serverfault.com, но у меня есть хороший выбор людей, которым я доверяю и уважаю в Твиттере, с которыми поддерживаю связь.
• Я оцениваю ответы, которые я нахожу с тем, что я вижу. Я не предполагаю, что какое-то одно решение является правильным, пока я не смогу достаточно проанализировать доказательства, которые я вижу, с тем, что сообщается в решении.

Отношение я стараюсь придерживаться:

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

Это отношение, которое мне полезно удерживать - они мешают мне подбрасывать руки в воздух, объявлять что-то «странным» и затем сдаваться или становиться несчастными, потому что это кажется «неразрешимым».

Способы, которые я думаю об устранении неполадок:

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

Процесс устранения неполадок:

• В чем проблема. Убедитесь, что вы видите, что это происходит, и можете воспроизвести это сами, чтобы не было недопонимания. К тому времени, когда ко мне обращаются в службу поддержки, люди часто сталкиваются с проблемами, но никто не может объяснить мне, в чем проблема на самом деле.
• Это рекурсивное деление пополам снова - разделяй и властвуй, бинарный поиск - вы придумаете тест, который докажет, является ли проблема этой стороной теста, или той стороной, и проведете тест, чтобы он устранял как можно больше. Повторите, пока не решено.
• Не узнайте, можете ли вы избежать этого - лучше заблокировать учетную запись базы данных и доказать, что проблема по-прежнему возникает, когда база данных не задействована, чем часами изучать, как используется база данных.
• Слишком легко поймать себя на мысли: «Я не знаю, что делать дальше». Обратите внимание, когда это произойдет, и вернитесь к тестам, которые обнаружат проблему.

Интернет не работает? Проверьте проблему, найдите веб-сайт, на который они не могут попасть. Быстрые тесты вовлекают их интернет-соединение (работает), загружается ли оно для меня (нет). Быстрые тесты указывают на то, что это сайт. Видя, что проблема возникает для меня, я быстро отодвинул вероятность от их ПК, браузера, DNS, брандмауэра учетной записи пользователя и т. Д.

Так что сайт не загружается, что теперь? Это еще не решаемо, так что ищите места, чтобы разделить проблему на более мелкую. Сервер включен? Это пингует? DNS работает? Да. Служба отвечает на порт 80? Нет. Служба запущена? Нет, это начинается? Нет. Дает ли это ошибки в журнале событий / лог файлах? Да! Что они говорят?

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

Вырежьте куски «вещей, которых не может быть» настолько большими, насколько это возможно.

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

Обычно я спрашиваю: «Что изменилось, что могло вызвать эту проблему»? Большинство проблем вызвано изменениями в известных исправных конфигурациях. Если вы можете определить, кто внес изменения, вы обычно получите ответ.

Я думаю, что это навык, а не наука. Есть моменты, когда вы идете по неверному пути, но по большей части:

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

Однажды мой босс позвонил мне со «старшим» инженером по телефону - он говорил мне, что у него есть один сервер, который не может подключиться, и он пытался переключить кабель, но все равно не испытывал радости. Я мог слышать гудение на заднем плане, как ИБП на батарейках. Я спросил его, может ли он видеть активность на выключателе, он сказал нет. Я спросил его, идет ли звуковой сигнал от ИБП, он ответил да, я спросил его, может ли он видеть какие-либо огни в стойке, он сказал нет ... Посмотри за нос - это помогает!

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

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