Хорошо ли работать в техподдержке? Ну это зависит от того, что нужно поддерживать! Сегодня мы расскажем о том, какие задачи приходится решать саппортерам в Virtuozzo, а они поделятся своими секретами – почему пришли работать именно на эти должности.
Итак, техническая поддержка – это специфическая работа, связанная с постоянным общением с клиентами. Как бы мы ни старались сделать программный код лучше, проблем всегда хватает. Они могут быть связаны и с очередным релизом, и с нетипичным сценарием использования софта, и с непредвиденными ситуациями в личной серверной клиента. В нашем случае все эти неприятности приходится решать команде саппортеров, в которой работает 10 человек – и их количество планируется увеличивать.
Ведущие специалисты техподдержки Virtuozzo Мария Антонова и Анна Винокурова
— Я уже давно работаю в технической поддержке, и мне очень нравится эта работа с точки зрения языкового самосовершенствования. Английский – язык международного общения, для многих наших клиентов он не является родным, и это не может не накладывать свой отпечаток на манеру их речи и восприятие того, что вы говорите в ответ. Для тех, кто любит общение и лингвистику в целом, но при этом видит себя в техническом профиле, мне кажется, работа в подобной среде – очень полезна для прокачки языкового скила и карьерного роста, — говорит Анна Винокурова.
Практика работы службы техподдержки Virtuozzo вывела для себя несколько правил, которых нужно придерживаться при общении с клиентами из различных регионов. В этом случае работать оказывается проще, а результаты достигаются быстрее. Вот некоторые из них:
• Клиентам из азиатского региона не стоит писать слишком длинные и подробные письма, из всего письма вероятнее всего будут прочитаны только первые пара абзацев.
• При устном общении с американскими клиентами необходимо несколько раз давать подтверждение того, что вас поняли правильно.
• Немцам и австрийцам можно выдавать достаточно комплексные инструкции, состоящие из множества пунктов, и они будут применять их в точности так, как было написано
Вообще специфика работы саппортеров – очень высокая степень спонтанности. Никогда не угадаешь, в какой момент что-то пойдёт не так и инженеры должны быть, как uоворится, «всегда наготове». Клиентам бывает нужна срочная помощь по разным причинам, но в основном любая срочность связана с обязательствами перед конечными пользователями – ведь большая часть клиентов Virtuozzo это хостеры, а неработающие виртуальные машины или контейнеры – это чьи-то недоступные сайты или базы данных.
Однако есть и предсказуемые волны нагрузки, они как правило связаны с релизами новых продуктов, выпуском мажорных апдейтов или же с обнаружением очередной уязвимости Linux.
— Когда в интернете публикуется очередной бюллетень безопасности (security advisory), в саппорт начинают приходить взволнованные клиенты, которые хотят узнать какие версии затронуты уязвимостью, и как скоро мы выпустим апдейт, — отмечает Анна Винокурова.
— Мне очень нравится работать в технической поддержке, потому что эта работа сочетает в себе задачи эксперта в сфере программного обеспечения, программиста и детектива. Иногда проблема оказывается настолько замаскирована, что ее решение — совершенно неочевидно. И каждый раз, когда удается разгадать загадку, «почему ничего не работает», приходит чувство глубокого удовлетворения и даже торжества! – говорит Мария Антонова.
Чем же занимается саппорт Virtuozzo?
Для тех, кто раздумывает, не пойти ли работать в саппортеры, мы расскажем несколько историй из реальной практики нашей техподдержки.
1. Память не добавляется – ошибка CPU
Однажды ночью клиент сообщает в поддержку об ошибке на попытке увеличить RAM для одной из виртуальных машин. Однако ошибка почему-то «ругается» на CPU, а не RAM.
Сначала такая ситуация всех очень удивила, но через некоторое время мы разобрались в том, что возвращаемая ошибка не имела прямого отношения к выполняемому действию – она лишь обнажала сбой, крывшийся намного глубже внутри системы.
Причина оказалась весьма серьезной: на физическом сервере «выбило» сокет CPU, и он перестал определяться, а вместе с ним все виртуальные ядра в пределах сокета ушли в offline. Естественно, при изменении лимитов памяти для виртуальной машины валидация будущей конфигурации не проходила просто в целом, ведь количество ядер стало превышать количество доступных ядер на узле сервера.
Дело в том, что в процессе валидации конфигурационного файла происходит обработка массивов NUMA, и CPU, которые им принадлежат. На физически «здоровом» сервере ни одна NUMA не должна быть пустой, и ситуация возникла потому, что раньше никто не предполагал, что поврежденный таким образом сервер вообще сможет работать продолжительное время.
Решение
На клиентском сервере было внесено исправление в python-составляющую продукта, которое позволило продолжать корректную работу, несмотря на существование узлов NUMA, состоящих целиком из offline-ядер. После этого мы смогли выставить количество CPU в пределах реальных “выживших” ядер для виртуальной машины, а значит – стали возможными дальнейшие изменения конфигурации.
Впрочем, последовали и более глобальные улучшения: в коде продукта на постоянной основе было улучшено определение статусов CPU: пустой массив с виртуальными CPU, принадлежащими одной группе NUMA больше не вызывает ошибок в коде и считается легальной ситуацией.
«На самом деле клиенту очень повезло, что его сервер оставался доступен достаточно длительное время, несмотря на такой серьезный аппаратный сбой. Это позволило мигрировать виртуальные машины на другие хосты, пока они всё ещё были доступны», — отметила Мария Антонова.
2. Пропадание сетевого подключения в виртуальных машинах
Клиент заметил периодическое пропадание доступа к сети в виртуальных машинах. Однако если такую виртуальную машину мигрировать на другой физический сервер или перезапустить на текущем, сеть снова работает.
Для исследования проблемы необходимо было получить виртуальную машину в момент воспроизведения проблемы, но сервисы внутри виртуальных машин должны были работать без перебоев, и наши исследования в режиме «онлайн» вызвали бы проблемы для большого количества конечных пользователей. Поэтому клиент предоставил нам копию виртуальной машины, на которой мы смогли воспроизвести проблему и исследовать её в нашей среде без неудобств для пользователей. Баг нашелся в механизме выделения памяти для сокет-буфера виртуального устройства virtio-net – часть модуля ядра.
Решение
Увы, быстрого решения проблемы, без изменения модулей ядра просто не было, оказалось, что клиент просто не обновился до последней версии Virtuozzo Linux. На момент обращения уже было выпущено обновление, причем в формате ReadyKernel. Это позволило применить обновление и решить проблему за несколько минут, даже не перезагружая сервисы.
3. Пользователь удалил все контейнеры
Один клиент решил напрямую сменить путь до приватной области контейнеров, но из-за ошибки в подготовленном им shell-скрипте, путь у всех контейнеров стал указывать в одно и то же место – общее хранилище всех контейнеров. Далее, как и следовало ожидать, один из конечных пользователей решил удалить свой собственный контейнер. Удаление привело к исчезновению всех контейнеров в хранилище – ведь обновленная конфигурация указывала на этот путь.
Решение
Чтобы предотвратить дальнейшую потерю данных, для конечных пользователей временно была отключена клиентская панель управления, чтобы они не могли остановить контейнеры, так как это привело бы к дальнейшей потере данных. С полностью удаленными контейнерами было ничего не сделать, поэтому задача сводилась к восстановлению метаданных для тех контейнеров, которые оставались запущенными.
Поскольку пострадавших контейнеров было около 400 штук, задача была достаточно творческой – нужно было написать скрипт, который делал бы схожие, но не однотипные манипуляции для всех пострадавших. Как показала более глубокая инспекция, для 200 контейнеров данные были потеряны полностью, так как контейнеры в этот момент находились в остановленном состоянии. Но для запущенных контейнеров удаление не прошло полностью, так как их виртуальные диски были заблокированы. В таких контейнерах были потеряны все данные, кроме самих виртуальных дисков – метаданные, конфигурационные файлы и другие сервисные файлы.
Физически файлы виртуальных дисков были перенесены во временную директорию для удаления файлов, и остановка такого контейнера привела бы к конечному удалению данных.
Так как метаданные варьируются от контейнера к контейнеру, их необходимо создавать с нуля индивидуально. Конфигурационные файлы восстанавливались на основании биллинговой информации и тарифных планов конечных пользователей — это клиент делал сам, так как у нашей службы поддержки нет доступа к биллинговой информации клиента. Но мы, в свою очередь, предоставили что-то вроде «скелета» конфигурации, в который нужно было внести IP, имя хоста, лимиты ресурсов. Для восстановления метаданных диска, саппортеры Virtuozzo создали скрипт, который генерировал корректные метаданные на основе информации о смонтированных контейнерах из ядра, а также вычислял виртуальные параметры дисков, такие как количество цилиндров, головок и секторов.
Кстати, после этого обращения в механизм удаления контейнера была включена проверка, является ли удаляемая директория контейнером – это позволит избежать подобных проблем в будущем, даже если пользователь запустит скрипт с ошибкой.
И детектив, и лингвист, и программист
Таким образом, мы можем уверенно сказать, что наша служба поддержки – это очень интересный коллектив, готовый решать многоплановые проблемы и даже заниматься доработкой продукта. И если вы хотите попробовать себя в такой работе, можете работать по ночам и не боитесь азиатского английского, у нас как раз могут открыться новые вакансии!
Автор: Gummio_7
