Сегодня мы продолжаем серию постов о работе команды технической поддержки, начатую в свое время Loxmatiymamont в статье о Veeam support.
Казалось бы, что такое Техническая Поддержка? Сидишь себе, решаешь технические проблемы, ты самый умный, самый знающий, ты тот самый Инженер, к которому приходят Испуганные Пользователи. Приносят свои страхи, боли, неполадки, а ты решаешь, помогаешь, советуешь, и, в конечном итоге, Пользователь уходит от тебя не Испуганным, а Окрыленным.
Вы уже прочувствовали всю значимость этой работы, содержащиеся в ней глубокие философские и педагогические начала?
Так вот, все немного иначе. Техническая поддержка она, в первую очередь, Поддержка, а потом уже Техническая, и потому вся работа на 99% процентов про людей и общение с ними, так что хрестоматийным мизантропам и патологическим интровертам у нас делать, конечно, есть что, но будет сложно — это раз, а два — люди не всегда предсказуемые, и потому, работая в Технической Поддержке, можно узнать, увидеть и услышать много интересного и необычного. Под катом я поделюсь с читателями парочкой таких историй.
Предыстория такова: у клиента засбоил его NTP-сервер (тот самый, что отвечает за синхронизацию времени в сети), и на самых разных хостах время прыгало абсолютно непредсказуемо. Разумеется, это не относится к Veeam, и клиент, как технически грамотный специалист, все решил сам, но: клиент с помощью Veeam бекапил свои сервера MariaDB, и отдельным скриптом делал как дамп базы, так и бекап бинарных логов. Каждый день.
Разобравшись с NTP, клиент проверил сделанные нашим софтом бекапы и увидел страшное: 12 дней бекапа бинарных логов куда-то исчезли, а отчет о задании показывал успех. Каждый день.
Именно для решения этой загадки призвали нас.
Быстрое расследование привело нас к главному виновнику, которым оказался тот самый NTP-сервер. Как?
А вот как: во время прыжков во времени NTP-сервер щедро выставил на сервере первые числа сентября года крестьянского восстания в Нормандии, подчинения Кашмира афганцами и начала строительства Тоболо-Ишимской укрепленной линии в Российской империи – то есть года 1752 от Рождества Христова. По странной прихоти истории, именно в сентябре этого года Великобритания и её североамериканские колонии решили перейти на Григорианский календарь, и потому месяц выглядит примерно так:
Так что и дампы базы, и бекап бинарных логов действительно делался каждый день, вот только дней этих в 1752 году оказалось ровно на 12 меньше, чем всегда, и логи за третье сентября были датированы четырнадцатым, четвертое – пятнадцатым, и так далее.
Эта же проблема проявлялась и при использовании пользователями календаря Хиджры — в этом случае, бекапы проходили без сучка и без задоринки, а вот при восстановлении данных сервис упорно сходил с ума, пытаясь работать с базой, созданной примерно в 1400 году.
Но не всегда проблемы со временем — это проблемы софтовые: как-то раз нашему инженеру пришлось две недели доказывать клиенту, что второй день недели это вторник, но никак не четверг, чему клиент, вполне респектабельный европейский буржуа, напрочь отказывался верить.
История, сама вызывающая если не улыбку, то недоуменное подергивание одной бровью точно.
Клиент долгое время страдал от проблем во всех его бекапных заданиях: они раз за разом умирали, как и главный сервис, отслеживающий их работу. Инженер, разбиравшийся с проблемой, довольно быстро выяснил: перед каждым эпизодом время в наших логах прыгало на один час то в прошлое, то в будущее. Причину выяснили, просто спросив клиента.
Поверить в объяснение и подавить в себе вопрос «зачем?» оказалось куда как сложнее.
Представьте себе: идет где-то в Атлантическом океане корабль. На нем установлен наш софт, а рядом крутится маленький скрипт, отслеживающий 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 и также долго не хотел пробовать предложенную из мистических соображений перезагрузку (аптайм машины к тому моменту исчислялся годами), пока наконец не сдался и не объяснил причину своего сопротивления:
«Понимаете, на этой машине с Windows 7 крутится не только Veeam, но и контроллер Умного Дома: все камеры, датчики, освещение, сигнализация и вообще все. В последний раз, когда мы перезагружали его, у нас взорвался бойлер».
Есть у нас технология Surebackup, которая позволяет запустить бекапы в изолированном окружении и проверить, насколько они успешны не только в репорте, но и в реальности (и не превратились ли они с последним процентом выполненного задания в тыкву). Хорошая технология, достаточно надежная, построенная на использовании нескольких сценариев проверки, в том числе и на проверку доступности по сети (например, проверкой порта того или иного приложения).
Для того, чтобы работать с изолированной сетью, мы запускаем отдельный апплаенс (маленькую виртуальную машину), который живет как шлюз и как основной рабочий инструмент всех тестов – и вот тут что-то пошло не так.
Апплаенс запускался успешно, а вот подключиться к нему самому мы не могли – через раз сетевой порт оказывался недоступен. Циклическое сканирование портов IP-адреса быстро показало, что иногда наш порт есть, а иногда его нет, зато появляется откуда-то порт 544 TCP, которого быть не должно даже в теории. Пробуем другие адреса – сценарий повторяется, проверяем arp – mac-адреса разные.
В полной растерянности открываем адрес вэб-браузером и удивленно лицезреем логин какой-то китайской вэб камеры. Еще раз меняем IP-адрес для апплаенса, и получаем ровно такую же картину – по какой-то причине все IP-адреса в сети редиректят на эту камеру, чего ни мы, ни клиент так и поняли.
Загадка так и осталась нерешенной.
Думаете, это единичные примеры? Любой, случайно взятый инженер может рассказать вам с десяток подобных историй, не особо напрягаясь и ни разу не повторившись.
Это именно то, что дает нашей работе вкус и драйв. Такие истории помогают помнить о том, что не вся наша работа сводится к сухому решению технических проблем, в ней есть комедия и драма, загадка и вызов. Это наш ресурс. Это то, что помогает нам встречать каждый звонок не с усталым “ну что вам опять надо?”, а с радостным предвкушением ”и чем вы можете меня порадовать сегодня?”
Похвастаюсь словами одного из вице-президентов нашей компании, сказанными о саппорте:
Но это уже совершенно другая история.
А что у вас, дорогие читатели? Есть чем поделиться в комментариях?
Да, если вы узнали себя в предыдущем абзаце, загляните на careers.veeam.ru/departments/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, возможно, там есть вакансия именно для вас.
