e.motion
Статьи

Вам требуется помощь?

Автор: Дмитрий Смирнов
Опубликовано в журнале «Домашний компьютер» №12 от 3 декабря 2007 года.

Нелегко приступать к рассказу о том, что мы любим и ненавидим. С чем сталкиваемся только тогда, когда нам плохо и от чего в определенных ситуациях оказываемся совершенно зависимыми. Встреча с чем почти всегда означает выход из нашей зоны комфорта. С чем мы расстаемся с легким сердцем, но рано или поздно обязательно возвращаемся. Предмет нашего разговора часто дает нам почувствовать себя детьми. Вы догадались? Все это — о ней. О службе технической поддержки. А поскольку наша рубрика посвящена сетевым технологиям, разговор пойдет о техподдержке провайдеров.

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

Однако, начнем с определения. Что такое техподдержка вообще, какая она бывает и кому она нужна?

Представим себе компанию-провайдера (ограничимся хостинг-провайдерами, иначе разговор потеряет всякие границы). Ее бизнес построен на продаже трафика и услуг самого хостинга. Трафик — это телекоммуникации, то есть все, что связано с широкими каналами связи. Услуги же — это виртуальный хостинг, выделенный сервер, колокейшен и им подобные. Каждая услуга связана с серверами как «в аппаратном» смысле слова, так и в смысле программном — то есть операционными системами, веб-сервисами и т. п. Поверх этих серверов устанавливаются программные среды и приложения — так, на хостинге нужны базы данных, обработчики скриптов PHP и Perl, а зачастую и предустановленные CMS (системы управления контентом) — то есть, по сути, готовые сайты.

Часть этого программного обеспечения — свободная, то есть является бесплатным ПО с открытым кодом. Другая часть — «проприетарная», платная, с закрытыми исходниками, принадлежащими разработчику. Но в любом случае это — программа, то есть инструмент, который не может быть безгрешен. В любом «софте» регулярно возникают уязвимости, которые исправляются заплатками или выпуском очередного релиза.

Бизнес провайдера напрямую зависит от работоспособности «железа» и «софта». Проблемы аппаратного свойства можно минимизировать путем грамотного построения серверной системы, распределения нагрузки между машинами, обеспечения отказоустойчивости и регулярного резервного копирования данных. В этом случае шанс получить серьезную проблему со стороны «железа» сводится к минимуму (но не к нулю). Программное обеспечение — гораздо более уязвимое звено цепи. Ошибки и недочеты в нем всплывают не сразу, но могут доставить массу беспокойства.

Если «железо» достаточно стабильно и подвержено, в основном, лишь физическому износу, то программам свойственно относительно интеллектуальное поведение, они взаимодействуют друг с другом и не всегда достигают полного взаимопонимания. Новая функция в одной программе может выявить ошибку или недостаток архитектуры другой.

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

Теперь займемся арифметикой. Одна из частей компании-провайдера — это собственная техническая служба. Она занимается установкой и сопровождением серверов и софта. Она же решает возникающие проблемы, общается с поддержкой производителей серверов и программ, установленных на них. Это — внутренняя служба, «движок» бизнеса.

Разумеется, сотрудники провайдера — это не только специалисты по серверам, управляемые напрямую генеральным директором. В такой организации должны быть менеджеры по продажам и работе с клиентами, бухгалтеры, маркетологи, пресс-служба и ряд других сотрудников, которые вовсе не являются экспертами в компьютерах и информационных технологиях; но им тоже нужна поддержка. Это, очевидно, уже второе подразделение внутренней технической службы, которое призвано заниматься собственной локальной сетью компании.

Развернутые серверы, подключенные к Интернету и готовые нести на себе сайты и сервисы пользователей, «публикуются» во внешний мир. Их начинают обживать клиенты. И этот процесс, разумеется, не может проходить абсолютно гладко. Ибо сервер — сложный технический организм, обладающий рядом одних качеств и не обладающий рядом других. Каждый сервер может нести на себе набор веб-приложений, из которых строится сайт. С развитием ПО с открытым кодом пользователям становится доступным все большее число дистрибутивов. Это может быть простой WordPress, а может и непростой WordPress, оборудованный тремя сотнями плагинов, которые загрузят машину на 220%. Если пользователь выбрал колокейшен, это может не создать ему проблем, но на виртуальном хостинге первые затруднения не заставят себя ждать: «тяжелый» сайт начнет нещадно тормозить.

Кроме того, каждый веб-сервер состоит из сотен модулей. На нем почти наверняка будет стоять СУБД MySQL, но по умолчанию, скорее всего, — не PostgreSQL. Для установки или включения последнего зачастую надо «попинговать» службу поддержки.

Опять же, далеко не каждый, кто купил хостинг, — веб-мастер. Большинство клиентов хостинг-провайдеров — это или любители, или компании, заказавшие сайт сторонним разработчикам, которые зачастую тоже оказываются любителями, разве что более опытными. Простота и легкость развертывания приложений подобных WordPress может создать иллюзию, что будущее — вот оно, уже здесь, прямо в мониторе, и сейчас мы на него кликнем. IT начинает казаться легким и приятным делом, доступным каждому. И когда на определенном шаге настройки сайта очередной, двухсотый, и отчего-то так нужный именно здесь и сейчас плагин «Вордпресса» по непонятной причине откажется работать, естественным рефлексом нашего веб-мастера станет звонок в службу поддержки со словами: «Ваш сервер не работает!»

Итак, мы плавно подошли к описанию функций третьего, наиболее интересующего нас сегодня дивизиона поддержки провайдера — внешней службы «хелпдеска»1.

Больше всего она похожа на этакий мощный файрвол-маршрутизатор (наподобие Microsoft ISA Server). Представьте: провайдер опубликовал на сайте телефон, рядом с которым написано «поддержка». Даже если рядом в столбик приложить еще десяток телефонов — клиентской службы, бухгалтерии и т. д., люди все равно будут звонить в поддержку по любым вопросам. Поэтому самая первая линия обороны провайдера занимается «маршрутизацией» звонков. Обычно она совмещена с клиентской службой, которая в состоянии «авторизовать» пользователя, посмотреть статус его аккаунта (который мог, например, перестать работать по причине простой неуплаты), проверить, включена ли та или иная услуга и т. д.

Если выясняется, что вопрос пользователя типа, как пропатчить KDE2 под FreeDSD?2 выходит за рамки компетенции «первой линии», он передается техническим специалистам поддержки — боевым машинам, более подкованным в технических вопросах.

Трудности перевода

Банальное название параграфа, зато — правдивое: пользователи и поддержка — обитатели разных миров, говорящие на разных языках. Постараемся объяснить.

Представьте, что у пользователя не запускается свежескачанный PHP-скрипт, который точно работает у других (пользователь сам читал это на форуме разработчика скрипта). Выдает Internal Server Error и грубо падает (как вариант, предлагает обратиться к администратору сервера). Возникает вопрос: кого в этой ситуации назначить пресловутым «администратором»? Пользователь и рад бы считать себя таковым, но у него иссякли идеи. Поэтому он начинает звонить провайдеру.

Но стоп! Где-то здесь следует остановиться и подумать. Провайдер лишь предоставил площадку, на которой может выполняться программный код. Но скрипт не работает. Вероятно, это плохая площадка и плохой провайдер.

Однако другие скрипты (класса Hello World!) на сайте запускаются и великолепно бегают. Значит, это плохой скрипт.

Но скрипт-то хороший! Он полезный, красивый, бесплатный и работает на десятке других сайтов. И всего-то для его работы требовалось правильно написать файл конфигурации или указать верный путь к обработчику или задать нужные CHMOD-права на тот или иной файл. В самом крайнем случае, подключить в панели управления очередной PHP-модуль.

Провайдер, который предоставляет пользователю «электронную квартиру», не обязан быть заодно и бесплатным веб-мастером и ловить ошибки в его скриптах3. Сотрудник поддержки может лишь мягко намекнуть вам, что если другие приложения на сайте работают, значит, дело не в сервере и не в обработчике PHP. Посоветует внимательно вчитаться в «журнал ошибок» сервера и пожелает удачи.

Отсюда выведем правило первое: в случае возникновения нештатной ситуации не паникуйте и не поддавайтесь желанию сразу звать на помощь. Постарайтесь самостоятельно выявить корень проблемы. Зайдите на сайт разработчика скрипта, прочитайте FAQ, поищите на форуме похожий вопрос. Скорее всего, вы — не первый на этой планете, кто столкнулся с подобной проблемой. И — вчитайтесь в логи сервера! В них можно найти или внятное объяснение того, что происходит, или хотя бы симптом, который, будучи вбитым в Google в сочетании с названием скрипта, принесет вам решение.

Правило второе: несмотря на то что сотрудник поддержки, безусловно, обладает техническим опытом и образованием, постарайтесь говорить с ним на максимально простом человеческом языке. Не стоит пытаться оправдывать свой звонок и демонстрировать «крутизну» путем использования сленга; это может изрядно затруднить взаимопонимание и затянуть процедуру решения проблемы. Помните, у разных «пород» айтишников и у разных поколений — разный сленг, зачастую не вполне совместимый.

Третье правило: не будьте категоричны, не делайте поспешных выводов и не заявляйте, что нашли ошибку сервера или серверного ПО. Вам будет крайне трудно это доказать (в идеале — лишь выпуском действующего патча, но если вы на это способны, зачем вам поддержка?). Опять же, несмотря на иммунитет, выработавшийся у сотрудников поддержки на пользователей, заявления типа «сервер не работает» или «баг сервака» в разговоре или письменном обращении может задеть сотрудника саппорта или настроить его против вас. Поймите, что вы и сотрудник поддержки — заодно; вы одинаково заинтересованы в работоспособности системы.

Отсюда — правило четвертое: описывайте лишь то, что видите. Сообщение Internal Server Error означает лишь… то, что вы получили сообщение Internal Server Error, и не более того. За этими словами может скрываться все, что угодно: их написал вам серверный «ловец ошибок», а у него на уме могло быть всякое.

Негласное пятое правило корректного поведения гласит: мыслите глобально. При общении с поддержкой описывайте не только частные шаги, но и общий результат, которого вы хотите добиться своими действиями. Возможно, вы уже давно пошли по неверному пути, который никуда вас не приведет.

Наконец, умейте признавать свои ошибки. Не мучайте сотрудника поддержки, если сами нашли решение проблемы или во время общения с ним осознали, что на каком-то шаге совершили глупость. Это знание также ценно; оно наставляет вас на путь истинный и экономит ваше бесценное время. Это та самая истина, что рождается если не в споре, то в траблшутинге. Сообщите сотруднику поддержки, который вам помогал, что решили проблему самостоятельно или с его косвенной помощью. Это сильно улучшит вашу «карму» и добавит нашему с вами миру толику гармонии.

Сам себе поддержка

Многие хостинг-провайдеры ограждаются от пользователей электронной системой подачи заявок. Она дополняет или полностью заменяет телефонную службу поддержки. Расчет абсолютно верен: если комбинированный провайдер «ISP+хостинг» еще мог бы предположить, что предлагаемое им подключение к Сети не работает и пользователь вынужден звонить по телефону, то у хостинговых компаний таких сомнений нет. Клиент хостера наверняка имеет доступ к Интернету, и ошибки быть не может.

Системы приема таких заявок максимально просты. Бесполезно предлагать пользователю самому классифицировать проблему: в 50% случаев на этом этапе произойдет ошибка. Форма заявки обычно предполагает авторизацию пользователя (или упоминание доменного имени, о котором идет речь). После этого страница обычно содержит лишь два поля: «тема» и сам текст заявки в вольной форме.

Когда сотрудник «первой линии поддержки» хостера получает заявку, он лично классифицирует ее и передает соответствующему инженеру, а он уже вступает в контакт с пользователем на внутреннем форуме сайта или по электронной почте.

Западные хостеры часто практикуют в качестве поддержки веб-чаты. Обычно скорость ответа в них крайне высока, сотрудника можно застать практически сразу.

Однако большинство задач, связанных с настройкой хостинга, делегируется самому пользователю. Все чаще появляются центры управления хостингом, где к своей площадке можно добавить или удалить домен второго и третьего уровней, сменить пароль на FTP, Shell, почту или базу данных, включить или выключить тот или иной серверный модуль, а также увидеть состояние своего счета и статус той или иной услуги. Опытным пользователям подобные органы управления сайтом в 99% случаев успешно заменяют общение с живыми сотрудниками компании-провайдера.

Ping провайдера

<damned>: kastor, попингуй!
<kastor>: Слышь, сам попингуй!
<damned>: От попингуя слышу!

С подачи bash.org.ru слово «пинговать» прочно вошло в повседневный лексикон; но это лирика. Физика же в том, что построение сайтов, особенно ваших первых сайтов — дело чрезвычайно увлекательное. А это на практике означает две вещи. Во-первых, почти наверняка сайтостроительство грозит затянуться до глубокой ночи. А во-вторых, согласно закону падающего сайта, он может упасть не только днем, но и ночью. Поэтому при выборе провайдера имеет смысл «попинговать» его службу технической поддержки в ночное время.

Почти каждый провайдер заявляет о круглосуточной поддержке. Разумеется, это — маркетинг; на практике же это может означать очень разные вещи. Во-первых, сотрудники клиентской службы почти никогда не работают по ночам, поэтому решить проблемы, связанные с «ручным» добавлением услуг, ночью не получится. Во-вторых, ночной сотрудник саппорта обычно может лишь констатировать, что в полночь истек срок оплаты хостинга, однако помогут вам лишь аккаунт-менеджеры, которые появятся на работе лишь утром.

Обычно на ночное дежурство провайдер выставляет именно сотрудников «первой линии». Они могут решить наиболее общие вопросы (что, в общем, покрывает 80–90% проблем пользователей). Однако те самые 10–20% будут подвластны лишь техническим умам бэкенда, элитным подразделениям поддержки, а они по ночам имеют обыкновение отдыхать.

Также есть смысл проверить поддержку провайдера на адекватность каким-нибудь хитрым вопросом. Например, поинтересоваться, какие порты открыты для доступа снаружи на виртуальном хостинге; какой уровень загрузки канала, памяти и процессорного времени сервера вы можете себе позволить. Намекните, что вы собираетесь развернуть на своем сайте небольшое веб-радио и последите за ответами. Например, от сотрудников своего последнего хостера в ответ на это заявление я получил три разных и совершенно противоречащих друг другу ответа. Первым был осторожный вопрос, сколько именно трафика я собираюсь занимать (после небольшого торга сошлись на определенной цифре). Вторым был довольно резкий ответ, что согласно 325 пункту 18-го (подробностей не помню) параграфа договора я не имею права запускать «левые» резидентные сервисы без особого согласования с хостером. На просьбу уточнить формулировки и вообще правила игры, а также на упоминание того факта, что договор (в письменно-печатном смысле этого слова) мы не заключали, я никакого ответа не получил.

Наконец, третий сотрудник ответил, что в принципе, если сервис на моей площадке запускается, ничего особого я этим не нарушаю, однако стоит все же соблюдать приличия в плане аппетитов моего приложения.

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

Итак

Выводов из статьи сегодня будет два. Первый — здесь и сейчас.

Идеальный пользователь — редкая птица (как и любой идеал). Он первым сообщит провайдеру о проблемах с его оборудованием; даже раньше, чем эти проблемы отметит мониторинговая система. Он выступает в роли «маленького помощника мамы» — найдет ошибку в софте и потребует ее исправления. Вопросы идеального пользователя могут стать контентом страницы с «правильными вопросами и ответами». Такой клиент образован, любопытен, умеет читать мануалы и пользоваться поиском. Он не задает вопросов, которые, будучи правильно сформулированными, сами содержат в себе ответ.

В свою очередь, идеальный сотрудник техподдержки — такая же мечта. Он излучает спокойствие и уверенность знания; он умеет правильно построить допрос пользователя, в результате которого отсекается большая часть проблемы, казавшейся неразрешимой. Он разговаривает с пользователем на максимально возможном общечеловеческом языке, а не жонглирует специфическими терминами. В плане выдержки он — Будда.

Но бывает ли такое в природе? Об этом мы решили спросить профессионала, собственноручно организовавшего не одну службу поддержки; это и станет вторым выводом из нашей статьи. Читайте материал на следующем развороте.

А мы тем временем пожелаем читателям удачи в общении с представителями этой такой же древней, как сами глупые вопросы, профессии!


1 Сотрудники хелпдеска, правда, зачастую называют свою работу helldesk (от английского hell — ад).

2 Историю этого вопроса, а точнее, интернет-мема, см. в одноименной статье русской «Википедии».

3 Сотрудник одной российской хостинг-компании нашел удачное сравнение: «Обращаясь в службу технической поддержки хостера, помните, что вам продали удочку, а как ловить рыбу, вас учить никто не обязан».

  • WordPress

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!

e.motion