Невероятно правдивые истории из жизни техподдержки

    Сегодня мы продолжаем серию постов о работе команды технической поддержки, начатую в свое время Loxmatiymamont в статье о Veeam support.

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

    Вы уже прочувствовали всю значимость этой работы, содержащиеся в ней глубокие философские и педагогические начала?

    Так вот, все немного иначе. Техническая поддержка она, в первую очередь, Поддержка, а потом уже Техническая, и потому вся работа на 99% процентов про людей и общение с ними, так что хрестоматийным мизантропам и патологическим интровертам у нас делать, конечно, есть что, но будет сложно — это раз, а два — люди не всегда предсказуемые, и потому, работая в Технической Поддержке, можно узнать, увидеть и услышать много интересного и необычного. Под катом я поделюсь с читателями парочкой таких историй.

    image

    История первая, детективная: Veeam Support и дюжина потерянных дней


    Предыстория такова: у клиента засбоил его NTP-сервер (тот самый, что отвечает за синхронизацию времени в сети), и на самых разных хостах время прыгало абсолютно непредсказуемо. Разумеется, это не относится к Veeam, и клиент, как технически грамотный специалист, все решил сам, но: клиент с помощью Veeam бекапил свои сервера MariaDB, и отдельным скриптом делал как дамп базы, так и бекап бинарных логов. Каждый день.

    Разобравшись с NTP, клиент проверил сделанные нашим софтом бекапы и увидел страшное: 12 дней бекапа бинарных логов куда-то исчезли, а отчет о задании показывал успех. Каждый день.

    Именно для решения этой загадки призвали нас.

    Быстрое расследование привело нас к главному виновнику, которым оказался тот самый NTP-сервер. Как?

    А вот как: во время прыжков во времени NTP-сервер щедро выставил на сервере первые числа сентября года крестьянского восстания в Нормандии, подчинения Кашмира афганцами и начала строительства Тоболо-Ишимской укрепленной линии в Российской империи – то есть года 1752 от Рождества Христова. По странной прихоти истории, именно в сентябре этого года Великобритания и её североамериканские колонии решили перейти на Григорианский календарь, и потому месяц выглядит примерно так:

    image

    Так что и дампы базы, и бекап бинарных логов действительно делался каждый день, вот только дней этих в 1752 году оказалось ровно на 12 меньше, чем всегда, и логи за третье сентября были датированы четырнадцатым, четвертое – пятнадцатым, и так далее.

    Эта же проблема проявлялась и при использовании пользователями календаря Хиджры — в этом случае, бекапы проходили без сучка и без задоринки, а вот при восстановлении данных сервис упорно сходил с ума, пытаясь работать с базой, созданной примерно в 1400 году.

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

    История вторая — комедия географического положения: Veeam Support и 20 тысяч лье над водой


    История, сама вызывающая если не улыбку, то недоуменное подергивание одной бровью точно.

    Клиент долгое время страдал от проблем во всех его бекапных заданиях: они раз за разом умирали, как и главный сервис, отслеживающий их работу. Инженер, разбиравшийся с проблемой, довольно быстро выяснил: перед каждым эпизодом время в наших логах прыгало на один час то в прошлое, то в будущее. Причину выяснили, просто спросив клиента.
    Поверить в объяснение и подавить в себе вопрос «зачем?» оказалось куда как сложнее.

    Представьте себе: идет где-то в Атлантическом океане корабль. На нем установлен наш софт, а рядом крутится маленький скрипт, отслеживающий GPS координаты корабля. Каждый раз, когда корабль пересекает очередной часовой пояс, скрипт меняет время на всех серверах и сервисах, в том числе и у нас, и более того, чтобы быть уверенным, что все работают с верным временем, он еще и часть сервисов перезагружает. Хороший пример творческого решения в стиле «мы решили одну проблему ценой появления двух других»).

    P.S. В процессе работы над этой статьей мне напомнили о почтовом сервере Dovecot и его способе обработки похожих ситуаций:

    Fatal: Time just moved backwards by 7 seconds. This might cause a lot of problems, so I'll just kill myself now. (Катастрофическая ошибка: произошел перевод времени на 7 секунд назад. Это может привести к массе проблем, поэтому я просто самоустраняюсь.)

    История третья — “ужастик”: Veeam Support и взрывающийся бойлер


    Позвонивший нам товарищ из США очень долго страдал от зависаний его сервиса Veeam и также долго не хотел пробовать предложенную из мистических соображений перезагрузку (аптайм машины к тому моменту исчислялся годами), пока наконец не сдался и не объяснил причину своего сопротивления:

    «Понимаете, на этой машине с Windows 7 крутится не только Veeam, но и контроллер Умного Дома: все камеры, датчики, освещение, сигнализация и вообще все. В последний раз, когда мы перезагружали его, у нас взорвался бойлер».

    История четвертая, мистическая: Veeam Support и око поднебесной


    Есть у нас технология Surebackup, которая позволяет запустить бекапы в изолированном окружении и проверить, насколько они успешны не только в репорте, но и в реальности (и не превратились ли они с последним процентом выполненного задания в тыкву). Хорошая технология, достаточно надежная, построенная на использовании нескольких сценариев проверки, в том числе и на проверку доступности по сети (например, проверкой порта того или иного приложения).

    Для того, чтобы работать с изолированной сетью, мы запускаем отдельный апплаенс (маленькую виртуальную машину), который живет как шлюз и как основной рабочий инструмент всех тестов – и вот тут что-то пошло не так.

    Апплаенс запускался успешно, а вот подключиться к нему самому мы не могли – через раз сетевой порт оказывался недоступен. Циклическое сканирование портов IP-адреса быстро показало, что иногда наш порт есть, а иногда его нет, зато появляется откуда-то порт 544 TCP, которого быть не должно даже в теории. Пробуем другие адреса – сценарий повторяется, проверяем arp – mac-адреса разные.

    В полной растерянности открываем адрес вэб-браузером и удивленно лицезреем логин какой-то китайской вэб камеры. Еще раз меняем IP-адрес для апплаенса, и получаем ровно такую же картину – по какой-то причине все IP-адреса в сети редиректят на эту камеру, чего ни мы, ни клиент так и поняли.

    Загадка так и осталась нерешенной.

    ***


    Думаете, это единичные примеры? Любой, случайно взятый инженер может рассказать вам с десяток подобных историй, не особо напрягаясь и ни разу не повторившись.

    Это именно то, что дает нашей работе вкус и драйв. Такие истории помогают помнить о том, что не вся наша работа сводится к сухому решению технических проблем, в ней есть комедия и драма, загадка и вызов. Это наш ресурс. Это то, что помогает нам встречать каждый звонок не с усталым “ну что вам опять надо?”, а с радостным предвкушением ”и чем вы можете меня порадовать сегодня?”

    Похвастаюсь словами одного из вице-президентов нашей компании, сказанными о саппорте:
    Technical Support — they are monster! They know not only how to solve technical issues, but also how to talk to customers.” (Техподдержка — это какие-то нереальные ребята! Они не только знают, как решать технические проблемы, но и умеют правильно вести диалог с клиентом.”)
    И мы это действительно можем, более того, мы этому учим: человека с хорошим языком (особенно вторым-третьим, помимо английского), умеющего общаться с клиентами и понимающего, зачем это нужно, мы знакомим с ИТ в целом и с нашим продуктом в частности (знали бы вы, сколько талантливых выпускников языковых вузов работают у нас — а ведь они начинали с практически нулевыми знаниями!). А хорошему техническому специалисту можем и английский подтянуть, и помочь soft-skills развить.

    Но это уже совершенно другая история.

    ***


    А что у вас, дорогие читатели? Есть чем поделиться в комментариях?
    Да, если вы узнали себя в предыдущем абзаце, загляните на careers.veeam.ru/departments/support, возможно, там есть вакансия именно для вас.
    • +24
    • 13,2k
    • 7
    Veeam Software
    127,07
    Продукты для резервного копирования информации
    Поделиться публикацией

    Комментарии 7

      0
      Про линию перемены дат слегка боян: n-t.ru/ri/mk/sk005.htm
        0
        Может быть даже и не слегка. Решение-то правильное и в чем-то очевидное, но «поломать шаблон» инженеру все-таки смогло.
          0

          Мне интересно, почему бы не использовать UTC?

          0
          >В полной растерянности открываем адрес вэб-браузером и удивленно лицезреем логин какой-то китайской вэб камеры. Еще раз меняем IP-адрес для апплаенса, и получаем ровно такую же картину – по какой-то причине все IP-адреса в сети редиректят на эту камеру, чего ни мы, ни клиент так и поняли. Загадка так и осталась нерешенной.

          Эммм… На камере кроме вебсервера крутился еще и DHCP с ну очень странными настройками?
            0
            Я бы скорее предположил, что это какое-то относительно хитрое колдунство с перенаправлением внутреннего трафика на стороне роутера.
            Например, микротики довольно спокойно можно так настроить одним правилом в разделе Firewall NAT. Такое бывает, когда пользователь пытается пробросить порт наружу и сделать устройство внутри сети доступным по внешнему адресу как снаружи, так и изнутри сети. Иногда что-то идёт не так, правило составляют с ошибкой и, в лучшем случае, лишь проверяют, работает ли нечто ожидаемое, забыв проверить, не поломали ли чего-нибудь другого.
              0
              Да, мы тоже предполагали что-то с кривым роутингом. Странно то, что когда убрали из сети камеру, то и воспроизвести то же самое поведение не смогли.
              Хотя тоже не показатель истины — все со слов клиента.
            0
            Техподдержка конечно круто, особенно если замалчивать 90% стандартных ситуаций в стиле «ни единого разрыва!!!!»

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое