Привет, Хабр! Это команда сервисной поддержки департамента телекоммуникаций КРОК. В прошлом году наши байки нашли теплейший отклик в сердцах хабровчан, и мы решили продолжить славную традицию.
Вообще-то прошлый год был непростым для всех, так что веселиться особо не хотелось. Однако, как показывает наш богатый на всякие нестандартные ситуации опыт, улыбка выручает в любой, даже самой напряженной ситуации. Вот мы и подумали по заветам Крошки Енота, почему бы не поделиться улыбкой с вами?
Поэтому устраивайтесь поудобнее, берите в руку чашечку с согревающим, а то и горячительным напитком, и летс гоу виз ас. Надеемся, что наши добрые, душевные байки хоть чуточку улучшат ваше настроение!
Задублированный IP
Случается, что даже мертвое оборудование способно доставлять траблы. В этом мы недавно убедились на примере кейса клиента из далекой сибирской глубинки.
Представим ситуацию: заказчик, не очень крупная компания в районе Новосибирска, регулярно жалуется на то, что после перебоев с электропитанием вне зоны доступа оказывается беспроводной контроллер. Проблема усугубляется тем, что точка вообще-то необслуживаемая, и узнать, в чем там загогулина, довольно затруднительно. Священное корпоративное SLA, которое для нас Конституция, Устав и Инструкция чуть ли не на все случаи жизни, требует отправки оборудования в день звонка клиента. Поэтому запрашиваем на складе новый контроллер, параллельно пытаясь прояснить картину происходящего.
Если не особо прищуриваться, это могла быть, как и живая физика, так и проблемы с программной частью устройства. Со временем выяснилось, что в эти моменты пропадал доступ к Web и SSH при доступности IP адреса через ICMP запрос. Продолжив наблюдение, мы уловили определенную цикличность в недоступности контроллера, поэтому решили проверить MAC-адреса на Core коммутаторе в офисе.
И вот, наконец, расследование принесло долгожданные плоды: оказалось, что несколько устройств у заказчика имели один IP-адрес. В результате, при перенаправлении трафика на паразитное устройство клиенты теряли возможность подключаться через беспроводную сеть.
Чуть позже случайным образом обнаружилась и причина. После очередного эпичного отключения питания местный эникейщик включил в стойке абсолютно ВСЕ оборудование, включая то, которое не работало со времен царя Гороха. Оказалось, что именно там-то и был настроен задублированный IP — его, конечно, тут же деактивировали, а потом и демонтировали, во избежание повторения внештатных ситуаций.
Любопытство до серверной доведет
В жизни бывает — общаешься с кем-нибудь по работе, решаешь проблему, между делом шуткуя, да и переходишь постепенно на уровень полной неформальности в переписке. И так человек становится мил и приятен, что его контакт перекочевывает из строго рабочей в дружескую папку, но, разумеется, не более, никаких брудершафтов.
Примерно также случилось с Лидой (имя условное), старшей по железнодорожной станции, которая как-то консультировалась по поводу неисправности ИБП после скачка напряжения. Тогда у нас все получилось, и контакт Лиды переместился в заветную папку контактов людей, которым с рекомендацией/советом не жалко помочь уже просто от души. Она позже обращалась еще несколько раз по каким-то мелочам: то телефон не работает, то компьютер, то снова ИБП шалит.
Волнительной интригой, однако, наполнилось то утро, когда от Лиды пришла фотография без какого-либо пояснения. Уже само фото намекало на что-то явно экстраординарное — это был симпатичный пес загадочной породы с мега-жалостными глазищами, выглядывающий из серверной. Через некоторое время подоспел и многозначительный комментарий Лиды: «Надо помочь».
Почесав затылок, решили все же позвонить девушке и расставить все точки над i. Выяснилось следующее: оказывается, в районе железнодорожной платформы поселился пес. Добродушный и совершенно незлобивый, но чрезвычайно любопытный, сующий свой шершавый нос во все дела железнодорожников. На этот раз, как пояснила Лида, четвероногий друг забежал в серверное помещение контроллеров и не желал оттуда вылезать ни за какие коврижки, даже на кусок колбасы реагировал с волшебным пофигизмом.
Пришлось включить все красноречие и обаяние, дабы убедить грустную Лиду, что инженерная магия в переговорном процессе с дворовыми псами бессильна. Впрочем, совсем уж огорчать девушку не хотелось, поэтому дали ей контакт знакомого ветеринара, который в результате и поделился рецептом по собачьему выманиванию из серверной.
Охотник за кабелями
Говорят, что привидений не существует. Однако череда таинственный событий, происходивших в течение месяца с уличным трансформаторным шкафом, заставляет в этом сомневаться.
А началось все с сообщения о падении коммутатора Enterasys 08G20G2-08. Отправленная на место происшествия служба спасения в лице монтажника обнаружила, что один из уличных серверных шкафов подвергся суровому, но специфическому акту вандализма. То есть серверная действительно была изнутри раскурочена (замок при этом цел), однако из оборудования ничего не пропало кроме кабелей питания. Стоимость подвергшегося атаке коммутатора на рынке около 40 000 рублей, красная цена пропавшего кабеля в базарный день — 200 рублей. Ничоси — у расхитителя социалистического имущества настолько плохо с арифметикой?
Как бы там ни было, мы подключили заново оборудование с новыми кабелями в надежде на то, что инцидент не повторится. Зря понадеялись: через несколько дней вновь поступает сообщение о падении оборудования ровно в том же самом месте. Монтажник выезжает и видит ту же картину — опять взлом, опять коммутатор на месте, а кабели сделали ручкой.
В течение месяца взломы той злополучной серверной повторялись еще несколько раз. Взбешенный проделками таинственного охотника за кабелями заказчик решил в конце концов просто поменять замки на шкафе, после чего серверное хулиганство в момент прекратилось. И что это было? То ли реально какой-то весьма странный охотник за дешевыми проводами, то ли бывший работник с ключами от шкафа мстил за что-то. А может, и правда призрак, или еще какой-то злодей? Злодей, который подзаряжается от кабелей…
Удаленная во всех смыслах работа
Можно ли чужими руками изменить мир? Интересный вопрос для тех, кто увлекается социальной инженерией. Это не наш профиль, и на весь мир мы в КРОК пока не замахиваемся, а вот починку оборудования удаленно, через видеосвязь, уже освоили.
Началось все с прилетевшей заявки о недоступности ПК на железнодорожной станции, до которой от Москвы пилить не меньше 8 часов. Поскольку в сумраке неизвестности завис всего один ПК, мы решили для начала попробовать выяснить причину неисправности дистанционно, без выезда на место происшествия. Прежде всего попросили переключить кабель в другой порт на коммутаторе другого компьютера, но это не помогло. Стало понятно, что скорее всего проблема с самим кабелем, который, видимо, был передавлен.
Тратить почти целые сутки на перемещение сотрудника в далекие края ради починки одного кабеля казалось нецелесообразным. Поразмыслив, спросили у кассирши — не завалялся ли где запасной, поскольку часто на дальних станциях монтажники оставляют кабели с запасом. И — бинго! Получаем в ответ фотографию с коробкой, полной джеков и необжатых UTP.
На горизонте замаячила задача посложнее — без кримпера с помощью технически не подкованного человека обжать кабель. Глаза боятся, а руки делают: связались с кассиршей по видеосвязи, начали объяснять да показывать, суть лайфхака. Тут же обнаружился и подходящий инструмент — ее величество отвертка, которая в умелых руках творит чудеса.
Весь вопрос, однако, как раз и заключался в том, чтобы выяснить насколько умелы руки. Девушка, впрочем, оказалась весьма толковой, действовала быстро, четко следуя поступающим по зуму инструкциям. И в течение нескольких минут все заветные цвета в правильном порядке легли в свои слоты.
Так мы и выяснили, что никакое расстояние инженерной работе не помеха. Главное, чтобы человек на той стороне попался слушающий, и с отверткой под рукой.
Первый блин ЦОДом
Свой первый выезд по заявке к клиенту, наверное, запоминает каждый наш сотрудник. А если этот выезд сопровождается каким-нибудь эпик-фейлом в процессе работы, то забыть о нем не получится даже при очень большом желании.
В этом кейсе специфика клиентского ЦОДа заключалась в том, что там была размещена серверная ферма с привязанными сервисами, к которым имеют доступ все филиалы. Работает это так: в стойку приходят два линка от провайдера в два разных свитча, далее по технологии MLAG все разводится на роутеры и серверы.
Собственно, в один из неприятных для клиента дней нагрянула беда — ферма отказалась работать. Клиент обозначил по телефону проблему так: «Сломался один из свитчей».
Что конкретно произошло и как перезапустить ферму? К расследованию был привлечен наш новенький сотрудник, отправленный к клиенту с пылу, с жару чуть ли не в первый день своей работы.
На месте доблестный новичок сразу ринулся в бой согласно правилам рабочей инструкции. То есть, опросив представителя заказчика с пристрастием, провел базовую диагностику и анализ конфига. В процессе работы заметил сбойную индикацию на передней панели свитча. Инженерная логика тут же подсказала верный ход: нужно подключить второе плечо питания, что и было сделано — индикация исчезла.
Далее новичок вернул MLAG в конфигурацию и подключил второй линк от провайдера. И тут случилось страшное — пропал интернет. Уже начавший заметно нервничать инженер продолжил работу, как вдруг поступил звонок от злющего админа ЦОДа, который добавил ситуации напряжения. Оказывается, на оборудовании клиента не был корректно настроен STP, поэтому инженер замкнул основной свитч на себя и сделал кольцо, положив интернет всем филиалам.
Из сложившегося положения тем не менее нужно было как-то выкручиваться: выборы STP тут же выиграл небольшой свитч Huawei, в который приходили management подключения, но заходов на него, увы и ах, не было и у заказчика. В этот момент поступил второй горячий звонок от админа ЦОДа, который сформулировал с вычетом виртуозной трехэтажной лексики весьма нетривиальный вопрос: «Что ты там делаешь?».
Несчастный, и должно быть проклинающий все на свете, инженер просто отключил второй канал. И вуаля, интернет мгновенно появился. Поколдовав с оборудованием еще немного, бедолага настроил BPDUfilter на портах в сторону провайдера, что и решило все проблемы. Ну а в следующий приезд наш крещеный в бою и уже слегка закаленный специалист перенастроил и Huawei.
Когда каналы были большими
Нередко причины возникающих у клиентов проблем связаны вовсе не с проблемным оборудованием. Чтобы докопаться до истины нашим спецам, конечно, приходится попыхтеть, но в этом же и весь кайф работы — процесс реально похож на детективное расследование, ниточки которого складываются воедино при учете всех мелочей и деталей.
Это наглядно продемонстрировал относительно недавний случай у заказчика, в компании которого настроены два канала связи от разных провайдеров. Оба канала в виде L2VPN между ЦОД и их офисом, и оба шириной в 1 Гбит. До поры до времени каналы работали без нареканий, в штатном режиме, но все изменилось в тот «прекрасный» момент, когда заказчик поставил фаерволл Palo Alto вдобавок к имеющемуся Palo Alto в офисе. В момент переключении маршрутизации на фаерволл в ЦОД упали все сервисы вообще, связь между офисом и ЦОДом нарушилась от слова совсем. Решение об обратном переключении маршрутизации на офис хоть и выручило, но очевидно, что глобально ничего не давало.
Запустив процесс «расследования», мы течение двух месяцев проводили с заказчиком регулярную ночную диагностику, отрабатывая массу возможных версий, но в результате ни к чему не пришли.
Впрочем, кое-что все же прояснилось: оказалось, что если при переключенной на ЦОД маршрутизации пригасить канал связи одного из провайдеров вручную, то работоспособность сети тут же восстанавливалась. Магия? Не то слово.
Как говорится, одна голова хороша, а две лучше, поэтому мы привлекли к расследованию инженера провайдера. И спустя время причины волшебства прояснились окончательно: все это время мы имели дело с каналом связи в 500 Мбит, а не 1 Гбит, как думали.
Озадаченный этим открытием инженер заказчика ушел общаться с коллегами, чтобы выяснить — как оно так получилось? Все объяснилось банальнейшей цепочкой случайностей: оказывается, раньше канал принадлежал другому провайдеру, который щедро откатывал скорость в 1 Гбит. После поглощения провайдера предоставляемую за те же деньги скорость подрезало до 500 Мбит, о чем все благополучно подзабыли.
Эту забывчивость мы и расхлебывали в течение нескольких месяцев. Теперь все встало на свои места: при переключении маршрутизации большое количество генерируемого трафика из-за скудной скорости урезалось на стороне провайдера, что и нарушало связность между ЦОД и офисом. А проблему решили просто — переводом канала обратно, на скорость в 1 Гбит.
Нестандартная схема работы
И все же в большинстве случаев приходится разруливать проблемы, связанные с техническими сбоями, дефектами и поломками оборудования. Иногда сталкиваемся с такой экзотикой, что голова сама тянется к руке удариться в жестком фейспалме.
Вот, например, ситуация: у заказчика в офисе установлены два шасси Cisco C6880-X-LE, объединенных в VSS-стек. Схема работы вроде несложная — active/standby, то есть с трафиком работает только активная нода в стеке, а вторая на подхвате. Внезапно возникает проблема: поочередно обе шасси уходят в перезагрузку. Заказчик чешет в задумчивости репу, звонит нам с просьбой приехать, разобраться и при возможности все поправить.
Изучив диагностические файлы, наш специалист выясняет, что шасси дико перегружены из-за переполненности ТСАМ памяти на 90% (это сверхскоростная память, необходима коммутатору для передачи данных). Причина тоже вроде понятна, весь 12-этажный офис заказчика подключен к этим двум шасси с помощью Fabric Extender’ов. Это такие специальные коммутаторы, предназначенные для подключения в шасси С6880, которые, впрочем, сами по себе работать не умеют. Итак, на секундочку: более 1800 портов офиса, на которых трафик контролируется одним из двух шасси С6880 (второе, как мы помним, «на подхвате»).
Но это только присказка. А сказка заключается в том, что на каждом из 1800 портов сконфигурирована Service Policy, которая как раз и занимает определенное количество ТСАМ памяти. Таким образом в момент, когда был применен конфиг, затрагивающий ТСАМ, активное шасси ушло в перезагрузку. Второе шасси перехватило управление на себя, но тоже не выдержало нагрузки и ушло в нокдаун пока первое шасси еще не загрузилось. Вот и получилась картина маслом: сеть легла полностью во всем здании, поскольку FEX сами по себе, без шасси ничего из себя не представляют и рулить трафиком не могут.
Немного придя в себя после шока от осознания столь своеобразной рабочей схемы, мы осторожно уточнили у заказчика — а зачем был выбран такой дизайн сети? На что получили в ответ красочную, роскошную презентацию от подрядчиков, где расписывались преимущества сети из двух шасси и FEX.
Сочувственно вздохнув, мы посоветовали клиенту обновить ПО на шасси и обновить конфигурации с целью экономии ТСАМ. Сказка на этом, разумеется, не закончилась, поскольку в процессе обновления одно из шасси повисло намертво и смогло загрузиться только где-то после четырех итераций выключения/включения питания.
Вконец изнуренный сбоями в работе заказчик попросил попросту заменить шасси. Когда к нам прислали железку, выяснилось, что одна из планок памяти неплотно сидела в разъеме. Что ж, планку мы подоткнули, продиагностировали шасси заново и вернули заказчику, который уже сам обновил ПО.
Две волшебные цифры в октете
Иногда на работоспособность ПК влияют настолько неочевидные вещи, что просто диву даешься — и вот из-за этого что-то пошло не так?
Недавно пришла стандартнейшая заявка, которую можно описать тремя простыми словами: «компьютер не работает».
Что ж, хорошо, не работает так не работает, сигнал получен, берем руку под козырек и начинаем действовать. Зашли в сеть, нашли машину, проверили настройки — все вроде бы ок, даже со шлюза компьютер доступен. Очевидно, запрос уже неактуален, поэтому звоним пользователю, чтобы подтвердить полную пионерскую готовность ПК к работе.
Не тут-то было, в ответ вновь получаем все те же полные мрачной горечи слова: «все равно не работает». И это очень странные дела, потому что компьютер получил настройки по DHCP. Разумеется, все адреса там прописаны верно, другие-то машины работают нормально.
В разговоре с пользователем постепенно выясняется вся предыстория. Изначально они сами пытались восстановить работоспособность компьютера, и какой-то сверхразум с зашкаливающим уровнем IQ подсказал, что адреса DNS-сервера надо выставлять вручную. Сказано — сделано, и вот уже на компьютере прописывается вместо верного адреса 172.22.1.10. очень схожий, но совсем неверный адрес 172.221.10.0. И дело тут в тончайшем нюансе: если написать две цифры в октете (22), то курсор на следующий октет сам не перейдет. Вот так и получилось, что единица попала не на свое место.
Проблемы атрибутов шерифа не волнуют
Общие правила стандартов безопасности должны неукоснительно соблюдаться во всех браузерах всех компьютеров нашей галактики — это закон! Иначе может случиться что-то непредвиденное и страшное, как это произошло у одного из наших заказчиков.
Который обратился за помощью с банальнейшим на первый взгляд запросом: после обновления браузера перестал открываться сайт компании. А это ужасно, не правда ли, что может быть хуже, если не можешь зайти на любимый корпоративный сайт, почитать новости или насладиться свежей статьей в блоге?
При первой диагностике мы пришли к выводу, что проблема связана с балансировщиком нагрузки, устанавливающем заголовки X-Frame-Options. Однако череда тестов, разборов дампов трафика и анализ ошибок браузера привели к пониманию, что проблема с X-Frame-Options — не единственная и не главная.
Главная фишка, как оказалось, в том, что обновленный браузер не открывает страницы во фрейме без установленных заголовков SameSite и Secure. Это глобальное для всех браузеров требование, введенное с недавнего времени, которое и было прописано другим отделом компании, ведающим информационной безопасностью. А мужики-то не знали…
В общем, проблема по мановению волшебной палочки решилась настройкой iRule, которое проверяет и устанавливает необходимые поля в ответе от сервера клиенту. Все гениальное просто, но до простого решения еще ведь нужно добраться…
Когда на кассе хочется чаю
Нередко простота в соответствии с русской поговоркой оборачивается чем-то таким, что реально хуже воровства. Особенно если это простота несведущего в технических вопросах человека.
В мудрости старинной пословицы мы вновь убедились, получив в миллионный раз заявку о периодическом отключении оборудования в серверной кассы железнодорожного вокзала. О причине проблем с оборудованием мы уже догадывались в тот момент, когда только разговаривали с представителем заказчика, но решили для проформы все же разобраться во всем согласно рабочей инструкции. То есть оформили заявку и начали двигаться шаг за шагом: оценили работоспособность электропитания, осмотрели ИБП, проверили таймеры на запланированное отключение питания — по всем параметрам полнейший тип-топ, ни единого, как говорится, разрыва. Даже температурных перепадов в стойке и на оборудовании обнаружено не было.
И вот уже почти в стопроцентной уверенности проверяем ту версию, подозрение на которую пали в момент обращения. Все дело в том, что кассиры частенько сами отключают узел связи, особенно в ночное время дежурств. Казалось бы, ну зачем им? Как вам такая причина — людям мешает шум от серверной стойки. И почему бы не выключить оборудование на время смены, а утром включить заново, верно? Или же можно отключить от сети узел связи для того, чтобы врубить электрочайник, без чая с плюшками разве можно смену пережить?
Обрисовав возможную причину возникновения проблемы заказчику (а установить точную картину на месте преступления мы, естественно, не можем), подождали определенное время. И что же? Проблема с отключением оборудования чудесным образом испарилась сама по себе.
В череде рабочих будней, наполненных яркими и порой очень нестандартными событиями — унывать, в общем-то, было некогда. Надеемся, что наши байки вас хоть чуточку улыбнули.
А что было забавного у вас? Делитесь в комментариях собственными анекдотичными ситуациями, посмеемся вместе. Смех, он, как известно продлевает жизнь и помогает пережить даже самые темные времена.
