ИТ-детектив
В качестве темы первого номера 2017-го редакция выбрала интригующее «В режиме правки». Это очень простая функция известного текстового редактора дает замечательную возможность автору (или редактору, соавтору и всем остальным, кто вовлечен в процесс) увидеть правки, сделанные другими пользователями, что называется, at a glance — то есть просто взглянув на документ. Такую функцию не зря любит наша уважаемая редакция — с ней можно быть уверенным, что, поправив в одном месте, наш партнер не внес коррективы где-то еще. Иногда это неважно, иногда может стать критичным.
Всегда легко писать о том, как здорово у нас все устроено: как мы наладили процессы, внедрили что-то интересное и как просто и весело теперь жить. Но о проблемах, которые есть всегда, о багах с косяками, рано или поздно всплывающих даже в самых отлаженных системах, люди предпочитают умалчивать, а это, по-моему, самый наглядный пример опыта. Опыт — это не когда ты завел машину и спокойно проехал по прямой икс километров. Опыт — это выбоины, резкие повороты, пьяные на дорогах и экспресс-ремонт на полпути, но ты все-таки проехал свои икс километров и успешно добрался в пункт назначения.
Образцово-показательный
Много лет назад одна европейская компания, чтобы завоевать российский рынок, решила расширить производство в нашей стране и построить новый завод. Завод большой, красивый, современный. И про ИТ-инфраструктуру не забыли, выполнили все по европейским стандартам: проводок к проводку, шкафчик к шкафчику, все промаркировано — в общем, любо-дорого смотреть. И помогать запускать всю эту красоту, конечно, тоже приехали европейские профессионалы, с похожего завода, чтобы сделать все по их образу, подобию и регламентам. Настроили они только инфраструктурные серверы — контроллер домена, DNS, DHCP и файловый сервер. А все, что касалось производства, решили делать не на дорогущем САПе, а на отечественной «1С УПП». Отличная система, кстати. Хотя история будет совсем не о ней или почти не о ней. Главное только в том, что автоматизацией занимались российские специалисты, без помощи европейских коллег.
Завод функционировал, продажи росли, и менеджмент решил установить складскую систему с адресным хранением и подбором заказов с мобильных терминалов. Система работала на мобильных терминалах Windows CE и связывалась с «1С» для получения заказов и сверки стоков. Такой простой файловый обмен, когда «1С» складывает файлы в специальной папочке, а терминалы их оттуда забирают и потом кладут свои с результатом. Куда уже проще и надежнее...
Детективная история
Как и положено любой системе, однажды наша складская система перестала работать... Внезапно, без объявления мониторинга, грузчики сообщили локальному ИТ-специалисту, что «ничего не работает», и ушли курить.
Нефункционирующая складская система — это практически парализованные отгрузки, то есть критические нарушения с самыми серьезными последствиями для бизнеса. Действуем незамедлительно: Как и следует в подобых случаях, создается критический инцидент и собирается специальная группа расследования, состоящая из инцидент-менеджера, локального специалиста, ИТ-менеджера и ответственных за различные ИТ-сервисы.
Итак, мы собрались первый раз, чтобы получить начальную информацию по инциденту. Локальный ИТ-специалист сообщил, что терминалы запускаются, сеть ловят, но не получают данные от «1С». Сам сервер тоже действует — все стационарные клиенты в «1С» работают без проблем. Файлики на файловом сервере появляются, но никто их не забирает.
Первая мысль: раз все по отдельности работает, а вместе нет, значит, дело в связи, в сетевых настройках. Серверы находятся в одном VLAN, офисные рабочие станции в другом, а терминалы сбора данных в третьем, отдельном VLAN. И первое предположение — наверное, нет маршрутизации, или файервол не пускает, или еще что-то между VLAN терминалов и VLAN серверов. Это предположение мне показалось правдоподобным, потому что некоторое время назад у нас уже был инцидент, когда партнеры по настройке маршрутизаторов случайно перепутали адрес и залили конфиг не на тот роутер, порушив всю сеть. В тот раз быстро все починили, но как говорится, осадочек остался.
Итак, первое собрание закрываем, итог — поручить подрядчикам проверить настройку маршрутизации и VLAN. Кажется, все просто и мы вот-вот все решим.
Второй раз собрались мы уже через час, поскольку подрядчики заявили, что они уже все проверили и с их стороны все работает. Только трафика они не наблюдают (эх, такая гипотеза провалилась, ну что ж, будем думать дальше.) Новая гипотеза состояла в том, что доменный сервер не пускает к себе недоменный терминал. С одной стороны, логично, с другой — а как тогда раньше работало? На всякий случай коллеги проверили все записи комитета по изменениям — и ничего существенного в них не нашли. Домен не перестраивался, политики не менялись, сети и маршрутизация, кстати, тоже без изменений. Но вчера все действовало, а сегодня уже нет. Ладно, решили по-быстрому развернуть файловый сервер вне домена, перенастроить на него «1С» и посмотреть, что получится. Развернуть его локальный специалист решил на офисном компьютере. Расходимся, и сбор через два часа.
В назначенное время, когда все собрались, локальный специалист сообщил, что при попытке подключится к серверу со склада связи не было, зато, когда он притащил терминал в офис, — устройство заработало. Как и почему, пока непонятно, но есть временное решение — надо просто заставить всех грузчиков ходить за заказами в офис с терминалом. Жаль, я не видел, как местный айтишник рассказывал это грузчикам и как они с терминалами приходили в офис, получали там заказ и возвращались на склад для подбора. Но это всего «на пару часиков», пока мы не установим причину, ведь опять показалось, что мы уже очень близки к цели. Действительно, раз в офисе оно работает, а на складе нет, то должна быть какая-то разница в Wi-Fi офиса и склада. Опять поручили сетевому подрядчику и опять дали ему два часа.
На следующем сборе подрядчик сообщил что, действительно, они допустили ошибку в настройках и одна офисная точка доступа не пускала терминалы в свой родной VLAN, а подключала всех к офисному. «АГА! — обрадовался я. — Значит, система работает только, когда терминал и сервер находятся в одном VLAN, тогда проблема все-таки с маршрутизацией, и злобные подрядчики, которые уже когда-то рушили нашу сеть, сделали это снова, только теперь еще и не сознаются. Окей, дадим им еще пару часов, чтобы все тщательно проверить. Надо же, как повезло, что тестовый сервер развернут в офисной сети и одна точка доступа оказалась неверно настроена». Какие были бы следующие гипотезы, если бы недоменный сервер терминалы тоже не увидели, я сказать не берусь. Но случилось так, как случилось.
На следующей встрече, когда рабочий день уже хотел заканчиваться, а перспективы быстрого решения все таяли, подрядчики, как и ожидалось, сообщили, что они еще раз все проверили и никаких проблем с их стороны нет. А с нашей стороны нет трафика.
Для того чтобы сотрудникам можно было расходиться по домам, а кладовщикам не приходилось за каждым заказом ходить в офис, решили «сломать» еще несколько точек на складе — тогда они всем начнут выдавать офисные адреса.
Последний на этот день сбор показал, что работа пошла в штатном (для грузчиков) режиме и можно по крайней мере пойти домой поспать. Следующий общий сбор — завтра в 9:00.
День второй... и третий
Ночь прошла без происшествий, и на следующее утро, когда мы все собрались, локальный специалист объявил, что со стороны производства и отгрузок претензий нет.
– Все работает. Отлично, давайте закрывать инцидент! — предложил инцидент менеджер.
– Система, конечно, работает, но с помощью сервера, который совсем и не сервер, не подключенный к домену, не защищенный, и терминалы тоже подключаются к офисной сети вместо специально отведенного им VLAN.
Решили инцидент пока не закрывать, но собираться не каждые два часа, а два раза в день.
Два дня мы пробовали разные подходы к проблеме: меняли сетевые настройки, VLANы, пинговали все из разных подсетей, искали средства удаленного управления для Windows CE, чтобы все могли посмотреть, что же на нем происходит.
Два дня консультаций с разработчиками софта для терминалов, специалистами «1С» и линии поддержки «Майкрософта» ничего не дали. Проблему идентифицировать не удалось.
Спасло нас то, что инцидент-менеджер, светлая голова, снова запросила список всех изменений за последние две или три недели. И вот в этом списке нашли, что на одном из заводов был выведен из эксплуатации один сервер. А завод примечателен тем, что именно оттуда приезжали бравые ребята, помогавшие с запуском много лет назад и настраивавшие всю инфраструктуру. Стали смотреть список сервисов на нем: DHCP, DNS, WINS. Вот где надо копать! 25 раз перепроверили все настройки у нас, и таки нашли в нашем DHCP параметр WINS, нацеленный именно на тот самый недавно почивший сервер. Конечно, даже много лет назад, когда завод только строился, WINS уже был устаревшим и централизованных серверов таких компания не разворачивала, вот они и прописали по привычке что знали, «на всякий случай».
Похоже, что WinCE требует только WINS для своей работы и простой DNS для него не годится... Все же, прежде чем поднимать новый WINS-сервер специально для терминалов, решили попробовать просто удалить эту настройку из DHCP — и вуаля! Терминалы заработали, увидели свой сервер и получили все необходимые файлы.
Кто бы мог предположить, что при правильных настройках DNS терминалы даже и не думали к ним обращаться. У них была настройка WINS, и они стучались только к ней. А как только ее не стало, терминалы спокойно воспользовались DNS и подключились к серверу.
Про грабли, ухабы и опыт
Получилось, что три дня мы потратили на выяснение причин неочевидного события. А могли, вероятно, потратить и гораздо больше времени. Нас спасла светлая голова, которая догадалась не интерпретировать симптомы, чем мы все это время занимались, а почитать «историю болезни» — поискать в журнале изменений все, что хоть как-то может быть связано с данным кейсом. Именно эта история изменений помогла нам решить инцидент.
Мораль моего рассказа — если ваш документ или вашу инфраструктуру изменяют несколько человек, обязательно включайте «режим правки». А даже если и не несколько, все равно, лучше включайте.
Документировать необходимо абсолютно все изменения, которые на первый взгляд совершенно неважны и ни на что не влияют. Никто не знает всей полноты картины, какие скрытые связи могут быть между элементами сложной системы. И память человека в отличии от компьютера не хранит постоянно всю собранную информацию. Компьютер, кстати, это невообразимо сложная система и один человек не в состоянии постичь как переключаются логические вентили в процессоре для обеспечения вызова определенной процедуры языка программирования, на котором написано бизнес приложение. Мы можем понять общую логику и в 99% случаев этого достаточно. А для того чтобы разобраться с последним процентом, может потребоваться документация. Поэтому, ее всегда надо держать под рукой и постоянно актуализировать.
Опубликовано 21.02.2017
