Как ИТ-специалист, вы за многие годы наверняка прочитали немало статей о том, как решать проблемы в различных «движущихся частях» ИТ-инфраструктуры, относящейся к вашим должностным обязанностям. Exchange Server, SharePoint, SQL Server и Active Directory (AD) — каждое приложение имеет свой уникальный набор проблем и методов устранения неполадок. Всем этим приложениям, однако, свойственна одна общая особенность. На самом верхнем уровне они имеют единую методологию решения проблем. К сожалению, многие ИТ-специалисты вполне осознанно не используют целостную методологию устранения неисправностей для решения своих проблем и, как следствие, тратят на это больше времени, чем нужно. . Таким образом, вы сможете тратить меньше времени на поиск ошибок в AD и выделить больше времени для полезной работы.

Использование научного подхода

Решение проблем — это, вероятно, наиболее важный технический навык, но большинство из нас не имеет системных знаний в этом вопросе. Обычно мы учимся в процессе работы, получая знания от более опытных коллег. Очень редко ИТ-специалисты профессионально учатся структурированному решению проблем. В результате мы имеем случайный набор инструментов, который работает обычно только для нас, и плохо структурированный процесс поиска и устранения неисправностей. Мы применяем эти инструменты и надеемся, что выполняемые действия решат проблему.

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

Компания Cisco разработала состоящую из восьми шагов модель решения сетевых проблем, основанную на научном подходе. Я добавил в эту модель некоторые принципы решения проблем из своего опыта работы в ИТ. Описанные ниже шаги представляют собой руководство для эффективного решения проблем.

1. Точно определите проблему. На данном этапе вам надо точно определить, в чем она заключается. Устраните из описания проблемы все неопределенности и неоднозначности. Например, нельзя утверждать, что DC1 некорректно осуществляет репликацию. Данное неточное утверждение подразумевает, что либо DC1 не может получить обновления от вышестоящего DC, либо у него не могут получить обновления нижестоящие партнеры. Точное утверждение может быть таким: «DC1 не получает обновления для раздела конфигурации от DC2». Точность утверждения отсеивает возможные предположения до их возникновения.

2. Соберите подробную информацию. Задайте себе вопросы следующего вида. Что не работает? Что работает? Что изменилось с того момента, когда это работало? Если это клиент, то испытывает ли кто-то другой такие же проблемы? Если да, то что общего у этих клиентов? Используют ли они операционную систему одной и той же сборки? Расположены ли они в одной и той же подсети? Используют ли они один и тот же сервер приложений? Имеется ли нечто уникальное в этой системе? Если это сервер, то находится ли он за межсетевым экраном? Если да, то испытывают ли такие же затруднения другие серверы?

3. Рассмотрите возможные причины сбоя. Это важнейший этап в решении проблемы, на котором вам потребуется организовать «мозговой штурм» и собрать возможные гипотезы или причины произошедшего сбоя. В таких сложных системах как AD могут быть сотни возможных причин, если вы не сузите круг возможных вариантов. Это наиболее подходящий момент для применения первого принципа поиска решения, так называемой «бритвы Оккама», согласно которому среди всех возможных решений проблемы самое простое является чаще всего верным решением. Возможно, вы уже используете принцип «бритвы Оккама» в процессе решения проблем, но не очень аккуратно; вы можете быстро обнаружить, что ваше первое предположение, или, быть может, второе, или даже третье предположение о причине проблемы — неверное. Что тогда?

Теперь следует применить принцип, который я называю «танцевать от проводов». Компонент, который вы обслуживаете, зависит от ряда других инфраструктурных компонентов. Стройте процесс поиска неисправности в соответствии с семиуровневой моделью Open Systems Interconnect (OSI), на основе которой построены современные сетевые системы, и начинайте поиск с самого нижнего, физического уровня до уровня вашего компонента. В случае распределенных приложений, таких как AD, продвижение в поиске решения происходит по следующим этапам: физическая сеть, разрешение имен в IP-адреса и серверная операционная система. Проверьте все эти компоненты, прежде чем приступить к AD. При построении набора гипотез обязательно включите тесты для проверки, что все уровни действительно работают, как положено. Прелесть этого метода «сверху вниз» заключается в том, что он работает для всех сетевых систем, так как все они построены по одному принципу.

Этот лобовой метод может быть избыточным для простых неполадок. Если вы, например, зарегистрировались на сервере удаленно, то вы уже знаете, что у сервера имеется электропитание и подключение к сети (по крайней мере, для определенных портов), так что вы можете исключить некоторые шаги. Главное, не забудьте, что вы их уже рассмотрели и исключили. Обдумав какой-либо шаг до его исключения, вы как минимум делаете мысленную отметку, к которой можно будет легко вернуться, если вы застрянете где-то в дальнейшем. Шаги 2 и 3 часто работают итеративно; сбор детальной информации нередко обнаруживает факты, которые формируют новые гипотезы.

4. Продумайте план тестирования гипотез. При планировании тестов, как бы вы ни спешили восстановить работоспособность системы, старайтесь следовать еще одному принципу решения проблем: изменять только один параметр в одном действии. Если вы сделаете более одного изменения и проблема будет решена, вы не поймете, решилась ли она изменением параметра A или изменением параметра B. Если сервер A не может установить связь с сервером B и вы изменяете сетевые настройки обоих серверов, вы не узнаете, что именно было неверно. Иногда требования ситуации (или руководства) заставляют сделать более одного изменения за один раз, в таком случае отметьте в качестве результата, что вы не смогли установить точную причину неисправности.

5. Приведите в исполнение свой план. Если возможно, выполните тесты с партнером или аудитором (проверяющим сотрудником). Нет ничего лучше второй пары глаз для схватывания информации, которая может ускользнуть от основного специалиста по решению проблемы. Для сложных планов всегда необходимо тщательно продумать их исполнение по времени, все записать и строго исполнять. Лихая «стрельба от бедра» в процессе исполнения плана может вылиться в получение неверного результата и повести вас по пути ошибочных предположений.

6. Проверяйте результаты исполнения плана. Решается ли проблема? Если нет, то изменилось ли что-либо в ее состоянии?

7. Повторяйте процесс с шага 3, рассматривая очередную наиболее вероятную гипотезу, пока не решите проблему. Продвигайтесь снизу вверх по уровням своего приложения. Если это проблема с SharePoint, то работает ли SQL Server? Если неполадки в репликации между двумя контроллерами домена, то имеется ли связь по сети между ними?

8. Документируйте изменения, сделанные в процессе решения проблемы. После решения проблемы выполните разбор всего процесса поиска решения. Задайте себе следующие вопросы. Было ли продвижение к правильному решению гладким или вам пришлось вначале несколько часов «биться головой об стол»? В случае второго варианта разберитесь, почему вы пропустили причину проблемы, и скорректируйте свою методологию решения проблем для следующего раза. Разбор постфактум не должен быть глобальным и формальным (если сам сбой не был катастрофическим). Здесь важно то, что вы таким образом совершенствуете процесс поиска неисправностей, поэтому аналогичные проблемы больше не застигнут вас врасплох. На рисунке 1 изображена блок-схема данного метода как часть блок-схемы процесса поиска неисправностей в AD, размещенной в блоге «AD Troubleshooting Tips & Tricks» по адресу http://tinyurl.com/adtroubleshooting.

 

Рисунок 1. Восьмишаговая модель поиска и устранения неисправностей

Поиск неисправностей в AD

Данная восьмишаговая методология поиска и устранения неисправностей применима к самым разным ситуациям, как внутри, так и вне мира ИТ. В оставшейся части статьи сфокусируемся на поиске неисправностей в AD и необходимых для этого инструментах. AD — это сложная система, которая базируется на других непростых компонентах. Какие именно зависимые компоненты должны быть в хорошем состоянии для правильной работы AD?

На рисунке 2 показаны уровни архитектуры, наиболее важные для функционирования AD: физический, сетевой, разрешение имен, операционная система и проверка подлинности и, наконец, сама AD. Физический уровень достаточно очевидный — ничто не может работать без электропитания. Или, если сетевой кабель не подключен, пакеты не могут пересылаться, однако в моей практике было немало случаев, когда в процессе поиска проблемы обнаруживалось, что недоступный контроллер домена (DC) находился в сайте, в котором было отключено электропитание по причине государственного праздника, а сотрудники сайта забыли сообщить об этом сотрудникам центрального офиса. Этот уровень также включает сбои в оборудовании самих DC.

 

Рисунок 2. Архитектурные уровни, важные для функционирования AD

На сетевом уровне вы ищете ошибки в настройке IP-адресов и подсетей, сбои сегментов LAN и WAN, а также изменения в настройке брандмауэра, которые блокируют порты, используемые AD. Лучшие инструменты для этого уровня — команды Ping, Ipconfig и Tracert. Как показывает практика, последний вариант — наиболее частая причина неполадок, возможно, из-за того, что она не является технологической. Для ее разрешения нужно более тесное взаимодействие между специалистами по сетям и службе каталогов.

Помимо самой AD, разрешение имен — это тот уровень, на котором от вас требуются очень серьезные навыки в решении проблем, так как именно здесь сосредоточено большинство проблем, не относящихся к AD. Служба DNS осуществляет разрешение имен узлов в IP-адреса для функционирования AD, а также выполняет ряд других важных функций, таких как обнаружение служб и трансляцию DSA ID (уникального идентификатора, используемого в репликации). Инструменты, необходимые для решения проблем в разрешении имен, — команды Nslookup, Nltest, Dcdiag и Ipconfig.

Следующий уровень — операционная система. Выделенные контроллеры домена проще для поиска неисправностей на уровне операционной системы, чем другие серверы приложений, так как на них обычно установлены только операционная система, службы каталогов Active Directory Domain Services и служба DNS. В системе Windows 2003 Server вы можете использовать Netsh Diag GUI и Netdiag, а в Windows Server 2008 — диспетчер сервера Server Manager и монитор производительности Performance and Reliability Monitor. В версии Server 2008 R2 имеется также анализатор соответствия рекомендациям Best Practices Analyzer. Во всех версиях, конечно же, имеются журналы событий. Наконец, в центре загрузки Microsoft Download Center доступен инструмент MPSReports, средство сбора информации, используемое службой Microsoft Support Services для диагностики системы. Вы также можете его использовать, просматривая результаты его работы с помощью MPSReports Viewer (также доступного в центре загрузки Microsoft).

На уровне операционной системы имеется также процесс проверки подлинности (например, Kerberos), который я выделил особо, потому что он является более частым источником ошибок, чем операционная система в целом. Работа Kerberos зависит от синхронизации времени, а также от билетов предоставления билета ticket-granting tickets (TGT) и от сеансовых билетов session tickets, используемых для успешной проверки подлинности при предоставлении доступа к ресурсам в домене. Рабочие инструменты здесь — журналы событий, Kerbtray и Klist (загружаемые из центра загрузки Microsoft). Иногда проблема проверки подлинности возникает не из-за сбоев в самом этом механизме, а из-за человеческого фактора. Я встречал ситуации, когда контроллеры домена отказывали в успешной аутентификации из-за того, что в некоторых странах Латинской Америки утверждали свои особые правила перехода на летнее время. Контроллер домена в такой стране не имел исправления для выполнения процедуры смены времени, поэтому персонал изменял время вручную. Отклонение времени приводило к тому, что выданные контроллерами домена сеансовые билеты Kerberos оказывались недействительными и в журналах событий на DC появлялись серии ошибок.

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

Шон Дьюби (sdeuby@windowsitpro.com) — старший аналитик в компании Platform Vision с 25-летним стажем работы в области корпоративных информационных систем. Внештатный редактор Windows IT Pro, имеет звание MVP