УправлениеИТ в бизнесе

ИТ-детектив

Иван Козлов | 21.02.2017

ИТ-детектив

Нефункционирующая складская система — это практически парализованные отгрузки, то есть критические нарушения с самыми серьезными последствиями для бизнеса.

В качестве темы первого номера 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% случаев этого достаточно. А для того чтобы разобраться с последним процентом, может потребоваться документация. Поэтому, ее всегда надо держать под рукой и постоянно актуализировать.

Логистика и транспорт

Журнал: Журнал IT-Manager [№ 01-02/2017], Подписка на журналы

Об авторах

Иван Козлов

Иван Козлов

Директор по ИТ, Metsä Group. Россия




Поделиться:

ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

Также по теме

Другие материалы рубрики

Мысли вслух

Десять лет назад мы говорили о будущем цифры и управления с Пеккой Вильякайненом - технологическим предпринимателем и опытным инноватором. То будущее, о котором мы говорили тогда, наступило. День за днем, со скоростью времени.
Согласно прогнозам Gartner, к 2022 г. 75% организаций, использующих инфраструктуру как сервис (IaaS), будут реализовывать продуманную мультиоблачную стратегию, в то время как в 2017 г. доля таких компаний составляла 49%.
Все жалуются на нехватку времени. Особенно обидно, что его не хватает на самые важные вещи. Совещания, созвоны, подготовка внутренних отчетов, непонятно, насколько нужных, но которые начальство требует так, как будто это именно то, ради чего мы работаем.

Компании сообщают

Мероприятия

ТехноКлуб «Дефицит чипов: как выжить в новой реальности?»
Зеленоград, конгресс-центр ОЭЗ «Технополис Москва»
Бесплатно
04.08.2021
10:30
У лояльных хмурый день светлей.
ОНЛАЙН
09.08.2021 — 10.08.2021
19:00
Международная конференция по информационной безопасности ZeroNights
Санкт-Петербург, Кожевенная линия, 40, «Севкабель Порт»
3 490 руб
25.08.2021
09:00–23:00
Конференция «Кадровый ЭДО: цифровизация на практике»
Москва, отель Метрополь, Театральный проезд, 2
25.08.2021
09:30–17:00