Сегодня я хотела бы поговорить, о том как работает техническая поддержка, каким именно образом там протекают процессы. Как именно происходит, разрешение инцидентов на стороне заказчиков, или как еще называют заявителей. Наверняка многие из вас пользовались "удаленными рабочими столами"
Используя при этом службу . Remote Desktop Protocol — протокол удалённого рабочего стола. Или же как их еще называют, программами удаленного администрирования. Но не многие задумывались о том, как именно происходит обслуживание ЦОД как и в целом домена, инфраструктуры.
Cтоит начать с того что обслуживание самих дата центров может происходить как на стороне заказчика, или же какого-либо предприятия. Так и осуществляться и вовсе на удаленной основе. Как и тот момент что компания, отвечающая за построение и проектирование дата центров, может и вовсе в дальнейшем их не обслуживать. Как и тот момент что само подразделение технической поддержки, в конечном итоге может располагаться непосредственно на территории самого заказчика, или же обслуживать его предприятие на удаленной основе. Потому что в большинстве своем процесс "автоматизирован" и даже при наличии каких-либо проблем, конфузов таких как отключение света допустим. На серверной части где располагаются сами дата центры имеется резервная система питания. Продуманная система циркуляции воздуха, также если косвенно затронуть часть виртуализации, то при наличии опять же проблем на программном уровне. Работа восстанавливается без потери рабочего процесса в этом и вся прелесть автоматизации процессов на стороне заказчика, какого-либо предприятия которая в конечном итоге. Затрагивает такие аспекты как повышенная работоспособность персонала, повышение продуктивности работы особенно в тот век когда компьютеризация как и автоматизация процессов идут рука об руку. Как и стоит затронуть тот момент что это, зависит и от внешних условий деятельности. Да и вообще помогает, разрешать многие конфликты возникающие на стороне персонала в техническом, и программном плане на стадии их развития. Что в конечном итоге повышает рентабельность самой компании, независимо от отрасли как и в целом её показатели эффективности.
Теперь когда мы вкратце разобрались в том что такое дата-центр,и как именно там протекают процессы я передлагаю плавно перейти к самой технической поддержке. Если вы работайте "допустим" в банке, или каком-либо другом серьёзном предприятии вы не раз могли слышать при обращении к саппорту.
Компьютерная помощь, Анастасия. Здравствуйте! Чем я могу вам помочь ? (примеч. это не имя автора xD)
А дальше как обычно, милая девушка на том конце провода просит вас назвать имя компьютера, или же например IP адрес, зависит о того на каком именно уровне выполнена автоматизация процесса на самом предприятии. Как и от использующихся там систем, сервисов, программ. Но пользователь, или же как я в дальнейшем буду использовать слово "заявитель". Наверняка не догадывается о том что сам саппорт, разделяется на несколько подразделений а иногда и вообще включает в себя целые группы. В зависимости от рода деятельности предприятия. Ведь сетевая самоорганизация процессов, как и автоматизация включает в себя очень многое. Названия самих подразделений тоже могут быть разными, в зависимости от рода деятельности, как и самого фронта работы.
Сейчас я постараюсь привести пример :
CyberNet - группа, в которую входят все остальные подгруппы
Service - группа, в которую входят все сотрудники технического отдела
AM - группа руководителей проектов
TVSM - группа, отвечающая за направление телефонии, маршрутизации и ВКС
Support - группа технической поддержки
Support 1-st line - группа операторов технической поддержки
Support 2-nd line - группа инженеров технической поддержки
WWCP - группа, отвечающая за направления коммутации, беспроводного доступа, систем бесперебойного питания и проектирование.
Монтажный отдел - группа, отвечающая за проведение любых монтажных работ
SSS - группа, отвечающая за направления виртуализации, автоматизации и программных сервисов
Функциональные же группы подразумевают участие человека в том или ином бизнес-процессе, и не привязаны к иерархии внутри компании.
Любой сотрудник может находиться в любом количестве групп.
Среди функциональных групп можно выделить следующие:
Support 1-st line - группа операторов, отвечающая за направление поступающих запросов, инцидентов, которая распределяет поступающие проблемы между подразделениями оговаривает сроки выполнения задачи, заполняет описание, выбирая при этом нужную категорию, первая реагирует на поступающие алерты, предупреждения, активно занимается мониторингом системы SolarWinds Orion на наличие неисправностей какого-либо оборудования, разумеется поступающие алерты активно отображаются в системе омнинет. (которую мы рассмотрим чуть позже)
Также от оперативности самой группы операторов, и их эффективности именно как специалистов и реакции зависит в конечном счете работа всей компании как и целого предприятия. Ведь если оператор выберет не ту категорию, неправильно заполнит описание какого-либо инцидента, или же попусту не прикрепит к самому инциденту конфигурационную единицу, как и укажет не те сроки, как и степень важности самой проблемы. Подразделение отвечающие за разрешение данного инцидента потеряет KPI (Key Performance Indicator) что в конечном итоге скажется на их команде отрицательно. Именно поэтому работать, приходится в данной области всем и попусту отлынивать от работы не получится. Если кто-то один безответственно относится к своей работе, велосипед не едет, потому что не хватает спиц.
Сама система SolarWindsOrion
Support 2-nd line группа инженеров технической поддержки, которая отвечает за выполнение работы технического плана, как иногда и программного может распологаться также на территории самого заказчика, предприятия или же работать удаленно. Инженеры как правило обладают более обширными знаниями и если первая линия, назначает и распределяет задания то вторая линия, их активно выполняет, как и другие подразделения. Но почему именно она имеет свою особую функциональность ? Потому что они располагаются в большинстве своём зачастую на стороне заказчика и разрешают инциденты на манер " где надо идти ножками ". Потому что группа первой линии хоть и тоже располагается в основном на территории заказчика, но не ходит ногами, а разрешает некоторого рода инциденты "удаленно" зачастую это около 60% обращений. Такого рода на банальном примере, подключиться к заявителю перезагрузив диспетчер печати, почистить папку spool/printers.
При этом редактировать время, категории, описания может только первая линия, и никакое из подразделений не имеет доступа к редактированию "инцидента". Как и не может его проигнорировать, оставить без должного внимания. Им доступно заполнение решения, как и то какой именно способ был использован для разрешения проблемы, и только после разрешения инцидента они имеют право его закрыть, или же отложить по time-period если не удается разрешить его в данное время, из-за возникновения каких-либо сложностей, трудностей, внешних факторов.
Роли :
Оператор - сотрудник компании, управляющий процессом, приема и обработки обращений.
Только сотрудники с ролью оператор могут создавать и изменять обращения.
Инициатор задания - сотрудник компании, имеющий права на поставку задач конечным исполнителям.
Исполнитель Задания - сотрудник компании, имеющий права на взятие заданий в работу и отвечающий за исполнение заданий в рамках присвоенных ему компетенций.
Супервайзер - сотрудник отдела технической поддержки, имеющий расширенные права на работу с сущностями обращений и заданий ( в зависимости от принадлежности к конкретному отделу)
Тим-лидер - сотрудник компании, стоящий во главе отдела и имеющий права на распределение ресурсов отдела, отвечающий за своевременное исполнение заданий своей группой, а также обеспечивающий все аспекты непрерывной работы своего подразделения.
Проектировщик - сотрудник компании, отвечающий за подготовку, актуализацию и контроль документации.
Теперь когда мы вкратце разобрались с вами кто и за что отвечает я предлагаю вам кратко ознакомиться с тем с чего начинается рабочий день IT специалиста, работа может начинаться в разное время суток как есть специалисты которые работают удаленно по 36 часов, а есть и те кто работает непосредственно в офисе компании, предприятия. Рассматривать будем на примере 1 линии.
Как правило сотрудники первой линии поддержки приходят на работу раньше на 1 час, так как им необходимо за час до начала работы, проверить все поступающие алерты которые ночники пропустили из-за того что спали, не удивляйтесь
такое бывает. Также им необходимо проверить почту Outlook на наличие каких-либо изменений в системах мониторинга, нововведениях, изменений внутри политики компании, а вот только потом они начинают свой рабочий день с заполнения календаря в системе Omnitracker. (Service Desk) сама система на выходе может быть абсолютно разной, но мы рассматривать будем именно омнинет.
1 - Пользователь, в календаре которого будет создана запись. По умолчанию выбран текущий пользователь, под которым выполнен вход, но сотрудники с ролью "Тимлидер" могут выбирать членов своей группы, и создавать записи в их календарях. (если кто-то загасился и не вышел на работу
)2- Причина отсутствия или присутствия на рабочем месте. ( если опять загасился)
3 - Тип записи в календаре. Если галочка активна, то создается запись об отсутсвии на рабочем месте в рабочее время. Если же пометка снята, то создается запись о нестандартном рабочем дне ( который может включать в себя как сверхурочные, так и более сложные комбинации рабочего, не рабочего времени)
4 - Дата начала записи в личном календаре.
5 - Дата окончания записи в личном календаре.
6- Время начала отсутствия на рабочем месте ( доступно только при наличии пометки 3, вот гасила то!)
7 - Время окончания отсутствия на рабочем месте ( доступно только при наличии пометки 3, ясно опять загасился)
8 - Пометка об отсутствии на рабочем месте с 00:00 по 23:59 в указанные в пунктах 4 и 5 даты. (доступно только при наличии пометки 3)
9 - Блок для записи нестандартного рабочего дня ( доступно только при отсутствии пометки 3)
При этом заполенение календаря сотрудником вне зависимости от подразделения является обязательным условием, если сотрудник по прибытии на какое-либо предприятие не заполнил календарь, часы рабочего времени не будут учтены. (как и опять же это скажется на KPI его команды)
Заполнять нужно и часы отсутствия на рабочем месте. (отпуск в том числе)
Теперь я предлагаю вкратце вам ознакомиться с интерефейсом самой программы.
Ну это момент конечно, на примере тим лидера, сейчас я постараюсь вам вкратце рассказать как именно происходит приём обращения.
Любой запрос от представителя заказчика, переданный оператору любым доступным для него способом обязательно должен быть зарегистрирован как новое обращение в системе управления обращениями.
Для инициирования приема обращения в клиенте оператора, на панели ярлыков в разделе Service Desk достаточно нажать кнопку новое обращение. И мы увидим вот этом окно.
1 Заявитель. Контактные данные заявителя, подавшего обращение.
2 Адрес, по которому зарегистрировано оращение, по умолчанию данное поле заполнено адерсом, указанном в контакте заявителя. В случае, если адрес обращения отличается от адреса заявителя по умолчанию, в обязательном порядке необходимо указывать корректный адрес.
3. Компания. Данные организации, в которой работает заявитель.
4 Тип запроса. Автоматически может принимать значения инцидент или сервисный запрос в зависимости от выбранной оператором категории. Тип запроса влияет на нормативные сроки, рассчитываемые для данного обращения и возможные значения поля " контроль времени " для данного обращения. Так же, обращения типа "сервисный запрос" не может стать " мастер инцидентом" и не может быть привязано к мастер инциденту.
5 Источник. Способ, которым заявитель донес суть своего обращения.
6. Категория обращения. Выбирается из дерева категорий, или ищется по началу названия категории.
Полный список древа категорий. ( может видоизменяться, как и имеет список подкатегорий)
7. Стандартное решение. перед сохранением обращения стоит проверить : не существует ли в базе стандартных решений готовой статьи, описывающей пути решения обращения. При нажатии на кнопку с лупой, будет выполнен релевантный поиск по базе стандартных решений с учетом выбранной категории и так же содержания полей "тема" и "описание" . Если нажать на кнопку + будет выведен весь список стандартных решений, отсортированных по номеру в базе. ( их могут пополнять любые специалисты вне зависимости от подразделения)
8. Тема. Краткое описание сути обращения.
9. Описание. Подробное описание обращения, содержащее все необходимые данные для нахождения места обращения, понимания инжнером сути проблемы и так же содержащие все детали, полученные в процессе разговора с заказчиком, о которых инженеру стоит знать.
10. Срочность исполнения обращения. Выставляется оператором вручную, исходя из результатов его общения с заказчиком. Чем быстрее необходимо заказчику чтобы его обращение было отработано, темы выше должна быть "Срочность". От установленной в обращении срочности зависят временные нормативы "Время реакции" , "Время в работу" и "Время решения", рассчитываемые для данного обращения, как и для подразделения которое будет его разрешать.
11.Уровень влияния обращения на бизнес заказчика. Выставляется оператором вручную, исходя из результатов его общения с заказчиком. Чем важнее быстрейшее разрешение обращения для заказчика на данный момент, так большим должен быть уровень влияния. От установленной в обращении срочности зависят временные нормативы.
12. Приоритет. Приоритет обращения рассчитывается автоматически, исходя из выбранных оператором значений полей "Уровень влияния" и "Срочность". Исходя из значения приоритета обращения и для всех связанных с ним заданий выбирается тот или иной уровень временных нормативов для параметров.
13.SLA. Контракт, определяющий временные нормативы, в рамках которого должно быть разрешено данное обращение. При создании обращения - это поле остается пустым в случае, если с компанией - заявителем не подписано какого-либо контракта на техническую поддержку. Если же в данном поле автоматически подставился какой-либо контракт, перед сохранением обращения обязательно необходимо проверить, что выбран наиболее подходящий к проблеме тип контракта.
14. Контроль времени. В случае, если "тип запроса" обращения "сервисный запрос" , то для него можно выбрать тип контроля временных нормативов. Для данного поля доступно одно из 2 х значений. Time period или ASAP ( as soon as possible)
15. + 16. Начало и окончание.
17. КЕ заявителя. Перечень КЕ, достоверно принадлежащих заявителю, служащий для быстрой привязки КЕ к обращению. Привязать одну из КЕ заявителя к обращению можно при помощи кнопки. При этом она отобразится в списке КЕ, привязанных к обращению в поле 21.
18. Затронутые КЕ. При любомй возможности, оператор. при регистрации обращения обязан привязывать конфигурационную единицу, по которой возникло обращение. Конфигурационной единицей может быть, как оборудование заказчика, так и его сервисы.
19. Владка для заполнения решения обращения : В случае, когда оператор разрешил проблему заявителя сразу, не прибегая к функциональной эскалации и на это ушло менее 10 минут, обращение можно закрыть в обход стандартной процедуры обработки обращения. Для этого необходимо заполнить поля решения на казанной вкладке и воспользоваться кнопкой FCR.
20. Ответственная группа операторов за обработку данного обращения, заполняет автоматически.
21. FCR. В случае, когда оператор разрешил проблему заявителя сразу, не прибегая к функциональной эскалации и на это ушло не мене 5 минут, после заполнения полей.
Конечно, имеются еще и другие аспекты работы с программой как и в целом взаимодействие с конечными инцидентами, но теперь вы вкратце знаете и осведомлены о том как работает техническая поддержка.
Последнее редактирование модератором:
