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

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

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 имеет руководство по устранению неполадок
• Закон Мэрфи - Все, что может пойти не так, идет.
• Бритва Оккама - При прочих равных лучшее решение - самое простое.

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

Следует знать две вещи:

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. Мы этого не заметили, потому что наш текстовый редактор молча скрывал этот факт. К сожалению, программа, которая считывала файл конфигурации, превратила эти ^ M в неразрывное пространство, что мешало выполнению множества других процедур.

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

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

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

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

Позиции, которых я пытаюсь придерживаться:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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