Сегодня мы продолжаем серию постов о работе команды технической поддержки, начатую в свое время Loxmatiymamont в статье о Veeam support.
Казалось бы, что такое Техническая Поддержка? Сидишь себе, решаешь технические проблемы, ты самый умный, самый знающий, ты тот самый Инженер, к которому приходят Испуганные Пользователи. Приносят свои страхи, боли, неполадки, а ты решаешь, помогаешь, советуешь, и, в конечном итоге, Пользователь уходит от тебя не Испуганным, а Окрыленным.
Вы уже прочувствовали всю значимость этой работы, содержащиеся в ней глубокие философские и педагогические начала?
Так вот, все немного иначе. Техническая поддержка она, в первую очередь, Поддержка, а потом уже Техническая, и потому вся работа на 99% процентов про людей и общение с ними, так что хрестоматийным мизантропам и патологическим интровертам у нас делать, конечно, есть что, но будет сложно — это раз, а два — люди не всегда предсказуемые, и потому, работая в Технической Поддержке, можно узнать, увидеть и услышать много интересного и необычного. Под катом я поделюсь с читателями парочкой таких историй.
История первая, детективная: Veeam Support и дюжина потерянных дней
Предыстория такова: у клиента засбоил его NTP-сервер (тот самый, что отвечает за синхронизацию времени в сети), и на самых разных хостах время прыгало абсолютно непредсказуемо. Разумеется, это не относится к Veeam, и клиент, как технически грамотный специалист, все решил сам, но: клиент с помощью Veeam бекапил свои сервера MariaDB, и отдельным скриптом делал как дамп базы, так и бекап бинарных логов. Каждый день.
Разобравшись с NTP, клиент проверил сделанные нашим софтом бекапы и увидел страшное: 12 дней бекапа бинарных логов куда-то исчезли, а отчет о задании показывал успех. Каждый день.
Именно для решения этой загадки призвали нас.
Быстрое расследование привело нас к главному виновнику, которым оказался тот самый NTP-сервер. Как?
А вот как: во время прыжков во времени NTP-сервер щедро выставил на сервере первые числа сентября года крестьянского восстания в Нормандии, подчинения Кашмира афганцами и начала строительства Тоболо-Ишимской укрепленной линии в Российской империи – то есть года 1752 от Рождества Христова. По странной прихоти истории, именно в сентябре этого года Великобритания и её североамериканские колонии решили перейти на Григорианский календарь, и потому месяц выглядит примерно так:
Так что и дампы базы, и бекап бинарных логов действительно делался каждый день, вот только дней этих в 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, возможно, там есть вакансия именно для вас.
Автор: kurojki
