Как правильно написать запрос в техническую поддержку

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

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

Поиск готового решения в нашей базе знаний

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

Давая ответ клиентам на информационные запросы наши инженеры ссылаются на статьи в базе знаний. Обнаружив в ней нужную информацию вы уже сбережёте своё время, так как не придётся создавать запросы в техническую поддержку.

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

Формулировка задачи

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

Обязательно надо выяснить:

услугу к которой относится запрос

идентификационные данные оборудования/сервиса

текущее состояние сервиса

результат которого вы хотите достичь

Описание услуги

Список предоставляемых вам услуг вы можете увидеть в личном кабинете. Каждая из них имеет уникальный идентификатор (id) и подробное описание того, что она из себя представляет. При создании заявки есть возможность выбрать какую из услуг он будет затрагивать.

Другим способом указать услугу может быть описание её уникальных параметров, например: “на арендованном нами виртуальном сервере с IP адресом 185.147.80.140 …” , или “В нашей стойке 02.05.78 …”, или “На выделенном сервере DS2022 …” и т.п.

Идентификационные данные

Чем подробнее вы опишете конкретное оборудование/сервис, тем меньше наши инженеры затратят времени на его поиск, что положительно скажется на длительность выполнения запроса.

виртуальные сервера однозначно можно идентифицировать по IP адресу

выделенные сервера по IP адресу, уникальному идентификатору “DS…” либо ID услуги

оборудование можно идентифицировать по месту его расположения (ЦОД Миран-1 либо Миран-2, номер зала, номер стойки, номер юнита/юнитов в которых оно расположено), по вашей маркировке, по нашим Miran ID которые мы присваиваем каждой учетной единице при её приёме. Если перечисленная информация вам не доступна желательно указать хотябы IP адрес, производителя, модель, формфактор и размер оборудования. Это поможет нашим инженерам быстрее сориентироваться.

каналы передачи данных идентифицируются по IP адресам, уникальным номерам кроссировок и конечным точкам включения. Например если вы напишете что-то вроде “регистрируем обрыв связи на линии, включенной в порт eth1 сервера Ares в нашей стойке 02.05.78 …” мы вас скорее всего поймём и не будем задавать дополнительных вопросов

Состояние сервиса

Если наблюдается проблема следует сообщить нам сразу об этом факте. Инциденты имеют наивысший приоритет среди всех заявок технической поддержки, поэтому в случае деградации какого-либо сервиса в ваших интересах сообщить нам об этом как можно раньше для скорейшего устранения проблемы. Например из двух заявок (1) “прошу вас подключить консоль к нашему серверу и посмотреть что с ним происходит” и (2) “наш сервер не доступен, прошу вас подключить консоль к нему и проверить его состояние” с высоким приоритетом будет обрабатываться вторая, так как в ней в явном виде указано на наличие проблемы, первая же классифицируется как запрос на обслуживание и будет обработана в порядке очереди.

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

для диагностики интернет канала обязательно указать затронутые IP адреса

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

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

логи системы помогут увидеть что конкретно и когда именно произошло

скринш