Хронология исправления не типичного сбоя dhcp, проблемы поиска решения
Не давние события в сети которую я администрирую натолкнули меня на проблему поиска решения в условиях ограниченной информации. Сначала опишу произошедшее в сети.
Первый пользователь пожаловался на сбои в четверг вечером. Основная претензия- отсутствие подключения к корпоративной электронной почте MS Exchange. С этой проблемой стал разбираться мой коллега. На следующее утро мы получили сеть с частично не работающем функционалом. Работали основные сервисы:
— 1С сервер
— Доступ к сетевым папкам
— Правовые справочные системы
Не работали:
-доступ в интернет
-доступ к корпоративной почте
Определённой сложности добавил факт работы всех сервисов на некоторых клиентских машинах. ICMP пакеты по всем серверам проходили с временем менее 1 мс. Основываясь на симптомах определил кандидатов на неправильную работу- это AD, DNS. Также опционально рассматривал возможность сбоев в DHCP. Дальнейшие действия свелись к доскональному анализу логов и настроек AD и DNS. Исправляя одни ошибки на их месте появлялись другие. После пары часов безуспешного восстановления, дальнейшее исправление симптомов, коими и являлись ошибки AD и DNS, были прекращены. Проверка сервиса DHCP на статус его запуска и проверка пула адресов не выявили проблем.
Следующим этапом был досконально проверен маршрутизатор Cisco на возможность сбоев. Не выявив проблем пришлось создавать мини стенд. Подключив контроллеры доменов, почтовый сервер и одну клиентскую машину на один, гарантировано рабочий, коммутатор проверил доступность почтового сервера. В очередной раз получив отказ, вернулся к рассмотрению основных сетевых служб AD, DNS, DHCP. В ходе более тщательной проверки состояния DHCP был обнаружен сбой в настройках пула адресов. По не выясненным причинам стерлись все поля настроек передаваемых клиентским машинам. Исправив ошибки DHCP, перезапустив службу вернул полный функционал сети. Дальнейший анализ выявил особенности поведения сети и почтового клиента. Клиентские машины, получая IP адрес от DHCP, не получали остальные настройки для нормальной работы в сети. Для большинства сервисов такое состояние оказалось не критично, в то же время почтовый клиент отказывался работать, не находя шлюза по умолчанию. Найдя ошибку и исправив её я остался не доволен своей работой. Первое, что вызвало не удовлетворение, время затраченное на поиск причин сбоя. Второе- не обнаружение первопричины подобного сбоя службы DHCP.
Остановлюсь подробней на времени затраченном для решения ошибки. Восстанавливая ход мысли при поиске ошибки натолкнулся на особенность. Несколько раз находясь в полушаге от необходимого решения переключался на не верный результат. После исправления ошибки её решение кажется логичным и простым. В реальности сказывается недостаток необходимой информации для правильного принятия решения. Рассуждая в данном направлении пришел к выводу, что поиск решения реальных инженерных задач является не оптимальным когда нет полной информации об объекте. В таких рамках человек начинает опираться на свой опыт и интуицию, что приводит к затягиванию нахождения решений. В математике существует раздел по проблемам нахождения решений при не полной информации, только в реальной практике нет возможности сидеть и вычислять оптимальное решение. Необходимо вырабатывать ряд правил на основе которых выполняется поиск решения. Для себя использую следующую методику. Проблему и решение рисую в виде начальной и конечной точки на плоскости. От начальной точки выходят несколько линий, на конце каждой линии, точка возможного решения. Проверяю на практике каждое возможное решение. После первого шага образуются новые направления с новым множеством точек решения. Некоторые направления приходят в одну точку. Точки с наибольшим количеством связей проверяю еще на два три шага, в случае не нахождения решения, перехожу к менее связанным точкам, и так до нахождения решения. Такой подход снизил время решения задач, хотя он всё еще далёк от оптимального способа.
Первый пользователь пожаловался на сбои в четверг вечером. Основная претензия- отсутствие подключения к корпоративной электронной почте MS Exchange. С этой проблемой стал разбираться мой коллега. На следующее утро мы получили сеть с частично не работающем функционалом. Работали основные сервисы:
— 1С сервер
— Доступ к сетевым папкам
— Правовые справочные системы
Не работали:
-доступ в интернет
-доступ к корпоративной почте
Определённой сложности добавил факт работы всех сервисов на некоторых клиентских машинах. ICMP пакеты по всем серверам проходили с временем менее 1 мс. Основываясь на симптомах определил кандидатов на неправильную работу- это AD, DNS. Также опционально рассматривал возможность сбоев в DHCP. Дальнейшие действия свелись к доскональному анализу логов и настроек AD и DNS. Исправляя одни ошибки на их месте появлялись другие. После пары часов безуспешного восстановления, дальнейшее исправление симптомов, коими и являлись ошибки AD и DNS, были прекращены. Проверка сервиса DHCP на статус его запуска и проверка пула адресов не выявили проблем.
Следующим этапом был досконально проверен маршрутизатор Cisco на возможность сбоев. Не выявив проблем пришлось создавать мини стенд. Подключив контроллеры доменов, почтовый сервер и одну клиентскую машину на один, гарантировано рабочий, коммутатор проверил доступность почтового сервера. В очередной раз получив отказ, вернулся к рассмотрению основных сетевых служб AD, DNS, DHCP. В ходе более тщательной проверки состояния DHCP был обнаружен сбой в настройках пула адресов. По не выясненным причинам стерлись все поля настроек передаваемых клиентским машинам. Исправив ошибки DHCP, перезапустив службу вернул полный функционал сети. Дальнейший анализ выявил особенности поведения сети и почтового клиента. Клиентские машины, получая IP адрес от DHCP, не получали остальные настройки для нормальной работы в сети. Для большинства сервисов такое состояние оказалось не критично, в то же время почтовый клиент отказывался работать, не находя шлюза по умолчанию. Найдя ошибку и исправив её я остался не доволен своей работой. Первое, что вызвало не удовлетворение, время затраченное на поиск причин сбоя. Второе- не обнаружение первопричины подобного сбоя службы DHCP.
Остановлюсь подробней на времени затраченном для решения ошибки. Восстанавливая ход мысли при поиске ошибки натолкнулся на особенность. Несколько раз находясь в полушаге от необходимого решения переключался на не верный результат. После исправления ошибки её решение кажется логичным и простым. В реальности сказывается недостаток необходимой информации для правильного принятия решения. Рассуждая в данном направлении пришел к выводу, что поиск решения реальных инженерных задач является не оптимальным когда нет полной информации об объекте. В таких рамках человек начинает опираться на свой опыт и интуицию, что приводит к затягиванию нахождения решений. В математике существует раздел по проблемам нахождения решений при не полной информации, только в реальной практике нет возможности сидеть и вычислять оптимальное решение. Необходимо вырабатывать ряд правил на основе которых выполняется поиск решения. Для себя использую следующую методику. Проблему и решение рисую в виде начальной и конечной точки на плоскости. От начальной точки выходят несколько линий, на конце каждой линии, точка возможного решения. Проверяю на практике каждое возможное решение. После первого шага образуются новые направления с новым множеством точек решения. Некоторые направления приходят в одну точку. Точки с наибольшим количеством связей проверяю еще на два три шага, в случае не нахождения решения, перехожу к менее связанным точкам, и так до нахождения решения. Такой подход снизил время решения задач, хотя он всё еще далёк от оптимального способа.
0 комментариев