Я хочу узнать больше о том, как выполнить анализ первопричин. В большинстве случаев наш отдел советует пользователю попробовать перезагрузку (система Windows XP), что на самом деле «решает» большое количество проблем. Когда я тороплюсь (а иногда этому способствует почасовая оплата), я могу попытаться найти обходной путь, чтобы быстро решить проблему, вместо того, чтобы выполнять анализ первопричин.
Большую часть времени я ищу эту информацию в файлах журнала или программе просмотра событий. Иногда я использую инструменты Sysinternals или иногда запускаю анализатор пакетов. Я, вероятно, не использую программы Sysinternals так часто, как следовало бы. Некоторые конкретные идеи о том, как вы используете эти инструменты, когда и почему, также будут полезны.
Я знаю, что это широко открытый вопрос, но не могли бы вы вкратце объяснить свою методологию, инструменты и т. Д., Которые вы используете? Похоже, что многие администраторы SF используют более глубокий процесс, о котором я хотел бы узнать больше. Если это поможет сузить вопрос, меня больше всего заинтересуют инструменты, советы, приемы и т. Д., Относящиеся к серверам и клиентам Windows в среде AD.
Выявление первопричины проблемы зависит от проблемы - ваш первоначальный инстинкт взглянуть на файлы журналов / инструменты sysinternals / анализаторы пакетов, как правило, верен.
Я бы добавил запуск MS Malicious Software Removal Tool и хорошей антивирусной программы в системах Windows (и убедитесь, что в них нет чего-то вроде CyberDefender или других вредоносных программ-троянцев.
Люди из Stack Exchange являются сторонниками метода «5 почему» (http://en.wikipedia.org/wiki/5_Whys, также этот красивый короткий PDF-файл, который показывает его в действии). Это довольно ценный инструмент для анализа первопричин.
Помимо этого, я выделю две широкие категории и некоторые вопросы, которые я обычно задаю / что проверяю:
Загадочное поведение, не связанное с сетью
например "Слово продолжает падать на меня"
Основные вопросы, которые нужно задать:
Проблемы, связанные с сетью
Во многом это похоже, но с некоторыми более конкретными указаниями.
В дополнение к отличным отзывам я бы добавил:
Определите дату / время возникновения проблемы. Это может показаться очевидным, но я видел слишком много проблем, когда это не было задокументировано, а позже были сделаны неправильные предположения. Это хорошо коррелирует с этапом «что изменилось».
Проблема воспроизводится или периодически? Это очень важно, поскольку воспроизводимые симптомы гораздо легче и быстрее разрешаются, чем периодические. Если это воспроизводимо, убедитесь, что шаги задокументированы.
Определите симптом (ы). Обратите внимание, что мы различаем «симптом», который является проявлением основной причины, и фактическую проблему / основную причину.
Локализуйте проблему в неисправном функциональном компоненте. Если в веб-приложении есть ошибка, то связана ли она с кодом приложения, веб-сервером, операционной системой, в которой размещен веб-сервер, сетью или удаленным концом? На данный момент это наилучшее предположение, чтобы ресурсы были сосредоточены на вероятной причине, поэтому убедитесь, что другие знают, что это теория / предположение.
Подвергните сомнению свои предположения и попытайтесь собрать эмпирические данные для подтверждения предположений и выводов. Довольно неприятно говорить кому-то, что с x нет проблемы, а позже выясняется, что она действительно есть. Обычно, когда есть неправильное решение, могли быть данные, поддерживающие правильное решение.
Похоже, вы просите общей помощи по устранению неполадок, например Ваши правила устранения неполадок, подход к устранению неполадок? а не как сделать конкретный вид RCA ( http://en.wikipedia.org/wiki/Root_cause_analysis).