Руководство по технической поддержке

I. Общие положения

Настоящая должностная инструкция определяет функциональные обязанности, права и ответственность Специалиста по технической поддержке пользователей ООО «НОВЫЙ БИЗНЕС» (далее по тексту Компания).Специалист по технической поддержке пользователей осуществляет свою деятельность в соответствии с системой качества, принятой в Компании.

• Специалист по технической поддержке пользователей относится к категории специалистов.

• Специалист по технической поддержке пользователей назначается на должность и освобождается от должности в установленном действующим трудовым законодательством порядке приказом Президента Компании.

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

1. Квалификационные требования

1. Специалист по технической поддержке пользователей должен иметь высшее или неоконченное высшее образование.

2. Опыт работы от одного года в аналогичной должности.

3. Базовые знания AD, DHCP, TCP/IP, LAN, GPO, Wi-Fi, компьютерного железа и операционных систем на базе OS семейства Microsoft.

4. Базовые знания основ администрирования офисных телефонных станций Panasonic и LG.

5. Базовые знания работы с IP телефонией и облачной АТС.

2. Специалист по технической поддержке пользователей должен 

1. Твёрдо знать и понимать семейство операционных систем Microsoft Windows 8, Windows 10 (на уровне администратора локальной системы).

2. Знать продукты Microsoft MS Office 2016, Office365 cloud стандартные программы, утвержденные политикой компании.

3. Понимать принципы работы сетевого оборудования и внутреннего устройства компьютерной сети.

4. Иметь базовые знания серверных операционных систем Microsoft Windows Server 20016 — 2019.

5. Знать и уметь использовать технологию клонирования компьютеров и процесс создания мастер — образа для для ускоренного развертывания ПК.

6. Знать устройство персонального компьютера и периферийных устройств, включая умение настройки Wi-Fi роутеров и USB модемов.

7. Иметь опыт мелкого ремонт компьютеров (замена HDD, увеличение памяти и.т.д).

8. Уметь заменить картридж и устранить замятие бумаги в принтере или МФУ.

9. Уметь удалять вирус и устранять последствия его деятельности.

10. Иметь опыт выстраивания конструктивного взаимодействия с людьми, уметь ясно излагать свои мысли.

11. Знать порядок ведения и оформления технической документации.

12. Иметь базовые знания английского языка, достаточные для чтения технической литературы.

13. Знать и выполнять правила внутреннего трудового распорядка; правила и нормы охраны труда, техники безопасности, производственной санитарии и противопожарной защиты.

II. Должностные обязанности

Специалист по технической поддержке пользователей должен:

1. Осуществлять поддержку, обучение и консультирование сотрудников компании по вопросам, касающимся компьютеров и программного обеспечения.

2. Осуществлять оперативную помощь сотрудникам по устранению неисправностей, определять, локализировать и устранять ошибки (сбои).

3. Принимать и фиксировать в HelpDesk системе заявки от пользователей, контролировать процесс их устранения.

4. Осуществлять помощь в выборе программного обеспечения, необходимого компании для максимального удовлетворения потребностей.

5. Выполнять работы по установке и настройке программ и программных средств, утвержденных политикой компании.

6. Устанавливать новые рабочие места и осуществлять перенос существующих.

7. Настраивать ПК и КПК, мобильные телефоны на базе IOS, Android,  тестировать, выявлять и устранять неисправности компьютеров и копировальной техники.

8. Создавать и конфигурировать телефонные номера.

9. Вести учет приема/ выдачи техники, принадлежащей IT департаменту.

10. Осуществлять закупку и учет расходных материалов для обеспечения бесперебойного функционирования принтеров и копировальной техники.

11. Вести заказы на поставку оборудования в автоматизированной системе учета.

12. Осуществлять оформление документов (приход/расход) и учет оборудования на складе IT.

13. Вести учет лицензионного ПО.

14. Проводить ежегодную инвентаризацию IT оборудования.

15. Предоставлять информацию сотрудникам компании по общим вопросам в области IT.

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

III. Специалист по технической поддержке пользователей имеет право

1. Требовать обеспечения нормальными условиями труда (рабочим местом, средствами труда и т.д.).

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

3. Информировать непосредственное руководство о выявленных неисправностях в работе, вверенных ему технических и программных средств и недостатках в работе.

 IV. Взаимосвязи

1. Специалист по технической поддержке пользователей взаимодействует со всеми функциональными подразделениями (отделами) и должностными лицами фирмы в пределах своей компетенции.

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

V. Специалист по технической поддержке пользователей несет ответственность

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

2. За не использование и / или неправомерное использование предоставленных настоящей Инструкцией прав.

3. За несоблюдение, Инструкций, приказов, распоряжений, Правил и др. документов, регулирующих работу специалиста по технической поддержке пользователей.

4. За несоблюдение правил внутреннего трудового распорядка, техники безопасности и противопожарной безопасности.

5. За порчу или небрежное отношение к хранению и использованию, хищение имущества фирмы.

6. За грубое, нетактичное отношение (поведение) при общении с персоналом и посетителями фирмы.

7. За сохранность документации и несоблюдение интересов фирмы, выдачу конфиденциальной информации, документации (коммерческой тайны) о фирме и ее клиентах третьим лицам.

8. За предоставление непосредственному руководству ложной или искаженной отчетной и др. документации (информации).

VI. Режим работы

1. Режим работы специалиста по технической поддержке пользователей определяется в соответствии с Правилами внутреннего трудового распорядка, установленными в Компании.

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

3. Задачи, обязанности, права и ответственность работника могут быть уточнены в соответствии с изменением структуры, задач и функций Компании.

4. Изменения и дополнения в настоящую Должностную инструкцию вносятся приказом Президента Компании.

 VII. Заключительные положения

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

2. Задачи, обязанности, права и ответственность работника могут быть уточнены в соответствии с изменением структуры, задач и функций Компании.

3. Изменения и дополнения в настоящую Должностную инструкцию вносятся приказом Президента Компании.

Руководитель структурного подразделения ___________________________________

                                                                                              (подпись)   (фамилия, инициалы)

____.______________________.20____

Как на самом деле устроена техническая поддержка

Время на прочтение
9 мин

Количество просмотров 1.8K

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

Меня зовут Дмитрий Семин, я руковожу службой сопровождения клиентов в ITGLOBAL.COM. В этом материале расскажу, как устроена наша служба, сколько обращений обычно поступает от клиентов и систем мониторинга и кто их обрабатывает.

Поступление обращений в техническую поддержку

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

Команда технической поддержки работает круглосуточно и за неделю обрабатывает 1300-1800 обращений, в сутки их количество составляет примерно 180-260 штук. Сюда входят обращения от клиентов и оповещения прочих систем, потому что все они обрабатываются по одному алгоритму: классифицируются, приоритезируются и получают различные статусы в процессе работы над ними.

Количество обращений днем по московскому часовому поясу обычно выше, чем ночью. Потому что большинство компаний вносят изменения по будням в рабочее время. Но есть клиенты, которые, наоборот, стараются запускать обновления ночью. Еще все зависит от геолокации и часового пояса организации. Например, у нас есть клиенты из Казахстана, США, Канады.

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

Варианты обращения в службу

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

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

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

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

Чаще всего клиенты обращаются по почте, второй по популярности канал — это портал самообслуживания, на последнем месте — телефонная связь. Я это связываю с двумя факторами. Во-первых, все ИТ-специалисты отчасти интроверты, поэтому они не любят общаться голосом. Во-вторых, при неполадках проще и быстрее сделать снимок экрана с ошибкой и отправить по почте, чем пытаться объяснить по телефону, что произошло.

Линии технической поддержки

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

Фото офиса, где работают специалисты технической поддержки

Фото офиса, где работают специалисты технической поддержки

Первая линия

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

Для того чтобы попасть в техническую поддержку, специалистам нужно обладать базовыми знаниями в Linux, сетях, виртуализации и продуктах Microsoft. Желательно, чтобы было понимание ITIL. Например, что такое инцидент, запрос на обслуживание и чем они отличаются. Важно уметь грамотно писать и говорить не только на русском, но и на английском, потому что техническая поддержка предоставляется клиентам на двух языках.

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

Вторая линия

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

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

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

В штате первой и второй линии технической поддержки ITGLOBAL.COM трудятся девять сотрудников. На данный момент у нас в штате есть только мужчины, хотя у нас были прекрасные примеры работы девушек в команде. Все специалисты работают посменно 2/2 по 12 часов. В смену выходят три человека: два сотрудника первой линии и один второй. Я и мой заместитель работаем 5/2 и готовы прийти на помощь, если не хватает рук или ребятам нужна помощь со сложными обращениями.

Третья линия

Третья линия подключается, если вторая линия не может решить вопрос клиента на своем уровне доступа и знаний. Это двадцать узкопрофильных квалифицированных системных администраторов. У каждого есть своя специализация: одни занимаются железом, другие — сетями, третьи — виртуализацией и так далее.

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

Классификация обращений

Все обращения автоматически фиксируются в ITSM-системе SimpleOne.

Скрин экрана специалиста технической поддержки, чтобы наглядно было видно, как выглядит работа в ITSM-системе SimpleOne

Скрин экрана специалиста технической поддержки, чтобы наглядно было видно, как выглядит работа в ITSM-системе SimpleOne

Специалисты первой линии определяют категорию обращения:

  • инцидент (incident). Деградация или возможная деградация услуги. Например, нет доступа в сеть интернет, не отвечает виртуальная машина (ВМ) и так далее.

  • запрос на обслуживание (request). Типовые запросы на изменение SLA или  функциональности услуги. Например, пользователь хочет, чтобы его проконсультировали, добавили новые лицензии, изменили количество ресурсов.

Определение приоритетов

Типовые обращения категории «Запрос на обслуживание» выполняются согласно модели, описанной в SLA. Обращения категории «Инцидент» получают приоритеты в зависимости от установленного значения срочности и влияния на бизнес-процессы согласно стандартной матрице.

Срочность

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

  • очень высокая влияние на бизнес существенное;

  • высокая — качество услуги сильно снижено, высокий риск увеличения влияния на бизнес до существенного;

  • средняя — незначительное ухудшение качества услуги, есть риск увеличения влияния на бизнес до существенного;

  • низкая — существуют неудобства при использовании услуги, риск увеличения влияния на бизнес до существенного низкий;

  • нет — обращение является пожеланием. 

Влияние

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

  • значительный инцидент — затронуты все пользователи или системы;

  • высокое — затронута большая группа пользователей или систем;

  • среднее — затронута небольшая группа пользователей или систем;

  • низкое — затронут один пользователь или одна система;

  • нет — пользователи или системы не затронуты.

Приоритет

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

Матрица ITGLOBAL.COM для расчета приоритета инцидента

Матрица ITGLOBAL.COM для расчета приоритета инцидента

Клиент может повлиять на определение приоритета. Например, попросить поднять срочность обращения. В этом случае изменится и приоритет обращения.

Статусы инцидента/запроса

Каждый инцидент и запрос проходит определенный путь в процессе работы над ними и имеет ряд состояний. Ниже таблица состояний инцидента/запроса с пояснениями и правилами перехода между ними.

Статус

Описание 

Условия перехода

Зарегистрировано (Registered) 

Инцидент/запрос зарегистрирован и ожидает классификации.

Назначено (Assigned)

Обращение назначено на конкретного исполнителя, который будет его выполнять.

В работе (In progress)

Классификация инцидента/запроса (определение времени выполнения) завершена, работа над ним началась и ведется.

Фактическое начало работ.

Завершено (Completed)

Работы над инцидентом/запросом завершены и дальнейшая деятельность по данному инциденту/запросу не планируется. Ожидание подтверждения выполнения инцидента/запроса от пользователя.

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

Закрыто (Closed)

Инцидент/запрос закрыт и работы по нему проводиться не могут. В случае возникновения необходимости проведения дальнейших работ потребуется зарегистрировать новое обращение.

Подтверждение Контактного лица об удовлетворенности проведенной работой над инцидентом/запросом либо отсутствие обратной реакции Контактного лица в течение 3 суток с момента установки статуса Completed. 

Отклонено пользователем (Rejected by user) 

Выполнение инцидента/запроса отклонено пользователем, его обработка должна быть выполнена повторно. 

Получение сообщения от Контактного лица о неудовлетворенности проведенной работой над инцидентом/запросом при установленном статусе обращения Completed. 

Требуются уточнения (Information needed)

Необходима какая-либо информация от пользователя, но связаться с пользователем владельцу Инцидента/запроса не удалось. 

Инцидент/запрос переводится в указанный статус с добавлением соответствующей записи в Additional Comments до момента получения ответа от пользователя. 

На внешней поддержке (External Processing) 

К работам над выполнением инцидента/запроса привлечена сторонняя организация.

Обращение переводится в указанный статус с добавлением соответствующей записи в Additional Comments. 

Каждому обращению присваивается уникальный номер, который в дальнейшем помогает идентифицировать его. При регистрации и при изменении статуса обращения контактное лицо автоматически получает уведомление по электронной почте. Также клиент может просмотреть статус обращения самостоятельно на портале услуг или уточнить его по телефону. С некоторыми клиентами есть чаты в Telegram, в которых происходят дополнительные коммуникации для более оперативного устранения инцидентов или уточнения информации.

Выполнение SLA

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

Выполнение SLA контролирую я, как руководитель технической поддержки ITGLOBAL.COM: наблюдаю за потоком обращений и приоритезирую их для сотрудников в ITSM-системе SimpleOne. Специалисты второй линии следят за обращениями первой линии и корректируют их последовательность. Так как SLA входит в KPI специалистов технической поддержки, сотрудники сами заинтересованы в качественном и быстром устранении инцидентов и обработке запросов.

Планы по развитию службы технической поддержки ITGLOBAL.COM

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

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

Начало

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

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

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

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

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

3 линии

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

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

Первая линия

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

  • Первичная обработка и/или маршрутизация всех вопросов, возникающих у заказчиков, со всех каналов взаимодействия (чаты, почта, телефония): мы гарантируем, что ни одна задача не будет потеряна, а также будут соблюдены условия SLA по времени реакции на запрос.
  • Оповещение об инцидентах не только в чат, но и по звонку, в том числе, по сложным правилам эскалации, а ещё ребята могут сообщить краткие характеристики инцидента, основываясь на показателях мониторинга.
  • Формирование задач на основе запросов и комментирование статусов задач заказчику, дополнение задач согласно новой информации, полученной от заказчика, ведение календаря запланированных работ.

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

Вторая линия

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

  • Разрешение базовых инцидентов — кончилось место на диске, истёк срок действия SSL-сертификата и т.п.
  • Консультация клиентов по вопросам работы мониторинга;
  • Решение типовых задач.

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

Третья линия

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

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

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

Инструменты

База знаний

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

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

Всё это позволит увеличить желание сотрудников сначала искать ответы там, а не в гугле или личках у коллег.

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

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

Мониторинг

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

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

Бэкапы

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

  • Схема бэкапов должна быть задокументирована, чтобы каждый сотрудник техподдержки имел возможность быстро найти резервные копии нужного ресурса.
  • Система бэкапов должна быть обвешана инструкциями, как новогодняя елка шарами, чтобы у техподдержки не возникало вопросов “а как развернуть бэкап той базы?”
  • Наличие в схеме бэкапов времени восстановления конкретного ресурса — чтоб понимать, сколько времени потребует восстановление работоспособности системы или ее частей.
  • Наличие мониторинга бэкапов, чтобы видеть текущий статус конкретных резервных копий, ведь какие-то из них могут оказаться невалидными.

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

Тикетная система

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

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

Сейчас на выбор есть большое количество как платных, так и опенсорсных тикетных систем; многие из них позволяют шаблонизировать задачи и процессы, строить различные диаграммы (всем известного Ганта, например) и использовать разнообразные метрики для формирования аналитики по процессам решения задач.

Каналы взаимодействия

Под каждый канал коммуникации можно выбрать один или несколько инструментов — или использовать один для всех. У себя мы выделяем следующие каналы:

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

Менеджмент задач

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

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

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

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

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

Менеджмент инцидентов

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

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

Также хорошей практикой является на регулярной основе анализировать статистику срабатывания алертов и на основе этого вносить корректировки в систему мониторинга.

Вместо вывода: 50 оттенков и 100 нюансов…

Организация службы техподдержки требует достаточно большого количества времени, ресурсов и не только. Обучение персонала, внедрение инструментов, адаптация процессов — всё это тернистый путь, полный скрытых грабель. На него можно вступить самостоятельно, получая зачастую сомнительное удовольствие от встречи с этими граблями и на собственном опыте разбираясь во всех оттенках и нюансах процесса организации службы техподдержки. Или можно довериться тем, кто уже разведал дорогу. У нас на поддержке находится более 400 разнообразных проектов, и мы всегда готовы принять к себе еще. Если же вы решили справиться собственными силами, мы всегда поддержим морально и проконсультируем по каждому шагу и этапу!

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

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

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

Определение понятия

Рассматриваемое понятие – процедура улучшения, устранения дефектов и оптимизации программных продуктов. Осуществляется после того, как софт передан на реализацию. Является одной из фаз жизненного цикла ПО. Она идет после передачи контента в эксплуатацию.

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

О границах использования

Сопровождение программных продуктов – понятие, которое имеет несколько точек зрения относительно своей применимости:

  1. Сопровождение автоматизированных информационных систем ничем не отличается от аналогичной операции относительно другого софта.
  2. Сопровождение ПО не предусматривает техническую поддержку АИС. Связано это с небольшой разницей при реализации.

ГОСТ 34.601-90 рассматриваемое понятие предусматривает выполнение работ в соответствие с гарантийными обязательствами (по гарантии), а также послегарантийное обслуживание.

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

Сопровождение – процесс, стандартизированный ISO/IEC 14764:99. Имеет более широкое понятие, чем поддержка. Сопровождением программных продуктов занимаются квалифицированные специалисты. Они лучше разбираются в ошибках и их исправлении, включая скрытые баги.

Структура

Сопровождение программного обеспечения – это характеристики продукта, которые позволяют свести к минимуму изменения:

  • для устранения обнаруженных ошибок;
  • при модификации в соответствии с потребительскими нуждами.

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

Чтобы лучше разобраться в теме, необходимо рассмотреть наглядную структуру процесса. За основу взят внешний контент:

  1. Линия 0. Информационный центр или «горячая линия». Здесь ведется обработка телефонных клиентских звонков с последующей передачей обращений техническим специалистам.
  2. Линия 1. Работает инженер по сопровождению. Он консультирует клиентов. При необходимости – настраивает софт и устраняет ошибки. Специалист занимается наполнением базы знаний и составлением руководств (мануалов).
  3. Линия 2. Здесь в дело вступает инженер техподдержки. Он отвечает за функциональное сопровождение и проектную деятельность на этапе установки и активации контента непосредственно на устройствах клиента.
  4. Линия 3. Осуществляется сопровождение и проектная деятельность на оборудовании в момент запуск софта.

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

Виды

Техподдержка бывает разной. Она включает в себя базовый и расширенный типы. В первую категорию включены следующие операции:

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

Это – основа, на которую опирается весь процесс. Остальные особенности базового обслуживания будут обсуждаться с клиентом в соответствие с его потребностями.

Расширенный тип предусматривает:

  • модификации эталонных сервисов и баз данных для развития и встраивания обновлений;
  • совершенствование для отладки работоспособности итогового контента.

Остальные задачи обсуждаются индивидуально.

Этапы

Рассматриваемая операция обычно включает в себя несколько этапов:

  1. Подготовка к необходимым исследованиям и действиям.
  2. Анализ имеющихся проблем, возникающих неполадок, ошибок. Здесь же обсуждаются и оцениваются корректировки.
  3. Внесение изменений.
  4. Проверка и приемка контента.

В процессе проведенного комплекса работ имеющийся софт могут перенести на другие устройства заказчиков или снять с реализации. Выше – пример процесса на базе цикла Деминга.

Как быстро освоить направление

Поддержка программного обеспечения – процесс, который сможет освоить любой IT-специалист. Особенно, если он занимается системным администрированием и разработкой.

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

Хотите освоить современную IT-специальность? Огромный выбор курсов по востребованным IT-направлениям есть в Otus!

Также, возможно, вам будет интересен курс «Руководитель поддержки пользователей в IT«.

I. Общие положения

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

2. Опыт практической работы не требуется.

3. Назначение на должность оператора технической поддержки и освобождение от нее производится приказом руководителя организации.

4. Оператор технической поддержки должен знать:

4.1. Основные технические характеристики и архитектуру поддерживаемых инфокоммуникационных систем

4.2. Перечень наиболее часто задаваемых вопросов по поддерживаемым инфокоммуникационным системам и (или) их составляющим, типовые ответы на них

4.3. Виды, назначение программного обеспечения для регистрации и обработки заявок на техническую поддержку и правила работы с ним

4.4. Основы инфокоммуникационных технологий в части поддерживаемых инфокоммуникационных систем и (или) их составляющих

4.5. Структуру и содержание руководств пользователя, предоставленных разработчиками поддерживаемых инфокоммуникационных систем и (или) их составляющих

4.6. Этику и психологию общения с клиентом при оказании услуг по технической поддержке

4.7. Правила деловой переписки и делового общения

4.8. Законодательство Российской Федерации в области работы с персональными данными

4.9. _____________________________________________________________________

5. Оператор технической поддержки подчиняется непосредственно ____________________.

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

7. ________________________________________________________________

II. Должностные обязанности

В обязанности оператора технической поддержки входит:

1. Информационно-справочная поддержка клиентов по вопросам эксплуатации технологических составляющих инфокоммуникационных систем:

— Регистрация первичных обращений клиентов по вопросам эксплуатации технологических составляющих инфокоммуникационных систем

— Обработка обращений клиентов в соответствии со сценариями обслуживания и установленными стандартами качества обслуживания

— Выявление в обращениях клиентов типичных (часто задаваемых и не требующих дополнительной консультации со специалистом более высокой квалификации) вопросов и нетипичных (редко задаваемых или требующих дополнительной консультации со специалистом более высокой квалификации) вопросов по эксплуатации технологических составляющих инфокоммуникационных систем

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

— Ведение журнала событий по обращениям клиентов по вопросам эксплуатации инфокоммуникационных систем и (или) их составляющих

2. Инструктирование клиентов в решении типичных вопросов по эксплуатации технологических составляющих инфокоммуникационных систем:

— Поиск ответа на типичные вопросы клиентов на основе инструкций в информационной системе службы технической поддержки — базе знаний по поддерживаемым инфокоммуникационным системам

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

— Ведение журнала событий по обработке обращений клиентов по типичным вопросам эксплуатации инфокоммуникационных систем и (или) их составляющих

III. Права

Оператор технической поддержки имеет право:

1. Запрашивать и получать необходимую информацию, а также материалы и документы.

2. Повышать квалификацию, проходить переподготовку (переквалификацию).

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

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

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

6.___________________________________________________________

IV. Ответственность

Оператор технической поддержки несет ответственность:

1. За ненадлежащее исполнение или неисполнение своих должностных обязанностей, предусмотренных настоящей должностной инструкцией, — в пределах, определенных действующим трудовым законодательством Российской Федерации.

2. За правонарушения, совершенные в процессе осуществления своей деятельности, — в пределах, определенных действующим административным, уголовным и гражданским законодательством Российской Федерации.

3. За причинение материального ущерба — в пределах, определенных действующим трудовым и гражданским законодательством Российской Федерации.

4. ____________________________________________________________________

Настоящая должностная инструкция разработана в соответствии с положениями (требованиями) Трудового кодекса Российской Федерации от 30.12.2001 г. № 197 ФЗ (ТК РФ) (с изменениями и дополнениями), профессионального стандарта «Специалист по технической поддержке информационно-коммуникационных систем» утвержденного приказом Министерства труда и социальной защиты Российской Федерации от 29 сентября 2020г. №675н и иных нормативно–правовых актов, регулирующих трудовые отношения.

Поделиться ссылкой:

Понравилась статья? Поделить с друзьями:
  • Инструкция по эксплуатации фотоаппарата nikon d3100 на русском языке
  • Эдарби кло инструкция по применению цена в пензе
  • Honda civic руководство по ремонту 2006
  • Кваттрекс инструкция по применению цена отзывы
  • Должностная инструкция лаборанта в ветеринарной лаборатории