IT Infrastructure Library для первой линии поддержки::БИТ 07.2016
 
                 
Поиск по сайту
 bit.samag.ru     Web
Рассылка Subscribe.ru
подписаться письмом
Вход в систему
 Запомнить меня
Регистрация
Забыли пароль?

Календарь мероприятий
октябрь    2020
Пн
Вт
Ср
Чт
Пт
Сб
Вс
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

показать все 

Новости партнеров

29.10.2020

VII конференция OS DAY.Online «Встроенные операционные системы»

Читать далее 

29.10.2020

НОРБИТ внедрил цифровую экосистему Центра опережающей профессиональной подготовки Забайкальского края

Читать далее 

28.10.2020

ПРЕМИЯ РУНЕТА 2020: новая концепция Народного голосования и старт подачи заявок

Читать далее 

27.10.2020

«BIM-форум 2020: теперь из любой точки мира

Читать далее 

показать все 

Статьи

11.10.2020

Soft skills или hard skills?

Читать далее 

10.09.2020

Как и чему учить будущих звезд ИТ?

Читать далее 

12.08.2020

Господдержка ИТ-отрасли

Читать далее 

11.08.2020

Интернет-маркетинг: второе дыхание

Читать далее 

15.05.2020

Жить под водой, мечтая о солнце

Читать далее 

13.02.2020

Чат-бот CallShark не требует зарплаты, а работает круглосуточно

Читать далее 

24.12.2019

До встречи в «Пьяном Сомелье»!

Читать далее 

21.12.2019

Искусство как награда Как изготавливали статуэтки для премии IT Stars им. Георгия Генса в сфере инноваций

Читать далее 

04.12.2019

ЛАНИТ учредил премию IT Stars памяти основателя компании Георгия Генса

Читать далее 

04.06.2019

Маркетолог: привлекать, продавать, продвигать?

Читать далее 

показать все 

IT Infrastructure Library для первой линии поддержки

Главная / Архив номеров / 2016 / Выпуск №07 (60) / IT Infrastructure Library для первой линии поддержки

Рубрика: Управление персоналом


Сергей Барамбазаместитель ИТ-директора ООО «БФТ»

IT Infrastructure Library
для первой линии поддержки

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

IT Infrastructure Library для первой линии поддержки

Зачем это нужно?

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

Согласимся с тем, что не очень хорошо, когда обращения в ИТ-службу решаются «по понятиям», особенно когда со стороны пользователей выступает сотрудник, имеющий высокую должность и всевозможные регалии. Разумеется, такой сотрудник требует срочного выполнения его обращения, даже в обход сложившихся процедур или заставляя ИТ-специалиста выполнять за него часть бизнес-процесса. В ход идут различные ухищрения с целью «продавить» ИТ-специалиста – упоминание топ-менеджмента компании («Моя задача на контроле у гендиректора»), включение силы денег («У меня срывается контракт на X миллионов рублей»), а порой истерия и давление на жалость.

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

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

Кстати

В классической ITIL-литературе при описании Service Desk линии поддержки делятся следующим образом:

  • 1-я линия – операторы по приему и маршрутизации обращений. Только они взаимодействуют с пользователями. Сотрудники первой линии в своей работе используют алгоритмы решения типичных задач и инцидентов.
  • 2-я линия – технические специалисты по разным функциональным направлениям (ПО, БД, сеть и поддержка рабочих станций).
  • 3-я линия – эксперты в своих областях.

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

Приемом заявок и выполнением менее квалифицированной и сложной работы занимаются специалисты первой линии.

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

Третья линия сохраняется без изменений.

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

В фильме «Узник замка Иф» в уста аббата Фариа, читавшего в тюрьме лекции будущему графу Монте-Кристо, вложили мудрую фразу: «Иногда надо понижать уровень изложения, учитывая аудиторию».

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

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

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

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

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

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

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

Кратко об ITIL

Все академические знания об истории и составе библиотеки можно свести к простой таблице 1.

Таблица 1. Сводная информация об ITIL

Расшифровка аббревиатуры ITIL IT Infrastructure Library, перевод на русский – «Библиотека инфраструктуры информационных технологий»
Произношение айтил
Первое упоминания 1989
Год публикации последней актуальной версии 2011
Официальное название актуальной версии ITIL® v3 2011 Edition (ITIL версии 3 в редакции 2011 года)
Состав библиотеки (Домены) 1. David Cannon, Majid Iqbal, Michael Nieves – Service Strategy, 2011
2. Lou Hunnebeck, Vernon Lloyd, Colin Rudd – Service Design, 2011
3. Stuart Rance, Shirley Lacy, Ivor Macfarlane – Service Transition, 2011
4. Randy Steinberg, David Cannon, David Wheeldon – Service Operation, 2011
5. Vernon Lloyd, Gary Case, George Spalding – Continual Service Improvement, 2011
Словарь терминов на русском языке Версия 2.0, 29 июля 2011 года скачать можно по ссылке [1]

Кратко о каждой из книг, входящих в состав ITIL.

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

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

Самая важная для первой линии книга – «Эксплуатация услуг» расскажет о практике ежедневных операций, требующихся для поддержания ИТ-инфраструктуры на плаву. Именно в ней разбираются тонкости управления инцидентами и запросами на обслуживание.

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

Последняя книга – «Стратегия услуг» описывает базовые принципы по созданию ИТ-стратегии в долгосрочной перспективе.

Что такое SLA и с чем его едят?

Говоря о сервисной модели, которую описывает ITIL, нельзя не затронуть такое важное понятие, как Соглашение об уровне предоставления услуги (Service Level Agreement, SLA). Подробнее о создании и тонкостях заполнения этого документа можно прочитать в журнале «БИТ» [2]. Сотрудникам первой линии поддержки нужно обязательно знать, что такое понятие существует и в нем описаны сроки и штрафные санкции за их нарушение. А в случаях, когда SLA нет или не определены условия, уровень доступности и обслуживаемости услуги считается по стандартной усредненной схеме:

  • 09:00-18:00 МСК
  • по рабочим дням
  • с уровнем доступности 95%

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

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

Два понятия, два типа отношений

Речь пойдет о Пользователях (Users) и Заказчиках (Customers). ITIL четко разграничивает эти два важных понятия, и у каждого из них своя роль.

Пользователь, как правило, использует то, что ему дают, и не имеет возможности попросить то, что ему, с его точки зрения, необходимо. Все запросы в ИТ-службу должны быть строго регламентированы, они имеют ограниченные рамки и выполняются в сроки, описываемые в SLA и сервис-каталоге.

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

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

Заказчик имеет возможность подтвердить свои требования, за ним остается право воздействовать на определенные важные ресурсы. Это может быть:

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

В качестве примера рассмотрим такую ситуацию. Рядовой менеджер, конечно, может прийти в ИТ-службу и начать требовать, чтобы ему выдали 27-дюймовый монитор, потому что табличка Excel, с которой он не работает, не помещается на экране. ИТ-специалисты ему откажут и скорее всего укажут на корпоративный стандарт рабочих мест, где написано, что ему положен монитор 22 дюйма, и менять никто ничего не будет, даже если этот самый большой монитор и будет стоять на складе.

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

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

Приоритеты и срочность. На что обратить внимание?

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

Сотрудники на первой линии должны понимать такие вещи, как Business Critical Hours – заранее определенное, важное для бизнеса время, когда счет реакции сотрудников идет буквально на минуты.

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

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

Все важные факторы в таблицу не внести, сотрудник должен сам определять, какой запрос на обслуживание требует быстрого реагирования, однако его решение должно опираться на предварительно загруженные руководителем базовые матрицы. И ничья истерика, слово «СРОЧНО!» в теме письма не должны приводить к тому, что ИТ-сотрудники, бросив все, мчатся удовлетворять потребность пользователя.

Три ежедневных кита первой линии

Ежедневно сотрудники первой линии сталкиваются с тремя основными процессами ITIL:

  • Управление запросами на обслуживание (Request Fullfilment).
  • Управление инцидентами (Incedent Management).
  • Управление доступом (Access Management).

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

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

Запрос на обслуживание

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

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

  • Если пользователь жалуется, что, например, система не работает, обращение всегда определяется как «Запрос на обслуживание». В рамках диагностики, выясняя подробности затруднений, может оказаться, что «вышел из строя сервер СУБД», обслуживающий систему, тогда это обращение превращается в инцидент. Если у пользователя просто не обновилась до новой версии платформа этой информационной системы, то обращение остается запросом наобслуживание.
  • Не все запросы можно выполнять в рамках классической очереди, для ряда запросов на обслуживание может существовать SLA (например, замена пустого картриджа в принтере за 30 минут).
  • Запросы на обслуживание, в которых первопричину затруднений пользователя не удалось обнаружить за отведенный промежуток времени, необходимо экскалировать или же переклассицифировать в инцидент и применять принципы Incedent Management. В таких ситуациях приоритетным является максимально скорое восстановление возможности пользователем выполнять бизнес-транзакции. Мастерство сотрудника будет измеряться правильностью выбора вкаждом конкретном сложном случае – экскалировать или использовать обходные решения, вплоть до замены целого рабочего места сотрудника.
  • Можно и нужно использовать возможности самообслуживания. Пользователю можно предоставлять инструкции и ссылки, позволяющие ему самостоятельно решить возникшее у него затруднение. Для этого необходимо знать положения общедоступных документов.

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

Что такое инцидент и как правильно его устранять?

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

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

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

Алгоритм разрешения инцидента должен придерживаться последовательности, приведенной на рис. 1

Рисунок 1. Пошаговый алгоритм разрешения инцидента

Рисунок 1. Пошаговый алгоритм разрешения инцидента

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

Управление доступом (Access Management)

Согласно словарю ITIL – это процесс, отвечающий за допуск пользователей к использованию ИТ-услуг, данных или других активов. Иногда в книгах данный процесс еще называют Управление идентификацией (Identity management) или Управление правами (Rights management). Сам процесс всегда основывается на политиках информационной безопасности, принятой в компании.

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

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

Важнейшие определения этого процесса сводятся к таблице 2.

Таблица 2. Основные определения, участвующие в процессе «Управление доступом»

Идентификатор (Identity) Имя, позволяющее точно понять, кто есть пользователь, и установить его статус и права доступа внутри организации. Именно на идентификатор в информационных системах налагаются права доступа для пользователя. Идентификатор является уникальным для пользователя
Ресурс (Resource) Элемент ИТ-инфраструктуры, использование которого необходимо контролировать в рамках процесса «Управление доступом». Может быть не только внутри компании, но и вне ее периметра, доступ к которым ограничен политиками. Например, сайты, доступ к которым недоступен по умолчанию, для всех пользователей из локальной сети компании
Доступ (Access) Тип и уровень предоставленных прав пользователю к приложению, информационной системе или ресурсам внутри или вне компании. В качестве простого примера «доступа» можно привести уровень прав к файлу в сетевой папке, где пользователь может:
  • только читать файл;
  • читать и производить в него запись;
  • читать, производить в него запись, удалить файл;
  • читать, производить в него запись, удалить файл, самостоятельно назначать права другим пользователям
Запрос доступа (An access request) Утвержденный в компании способ, которым пользователи могут обратиться за предоставлением ему запрашиваемых прав
Права (Rights) Набор предоставляемых возможностей манипулирования внутри информационной системы или ресурса, которые доступны пользователю. Еще используется термин «привилегии» (privileges). Они зависят исключительно от служебных обязанностей пользователя. При этом чем разнообразнее обязанности, тем сложнее определить принципы назначения этих прав. Например, пользователь может иметь доступ на просмотр отчета, но не может его редактировать или удалить
Группы доступа к сервисам (Service groups) Условное объединение пользователей, будучи включенным в которое, пользователь автоматически получает заранее предопределенный набор прав к сервисам в различных системах

Первая линия поддержки, обрабатывая «Запрос доступа», должна последовательно осуществить несколько действий.

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

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

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

Удаление и ограничение прав (Removing or Restricting Rights). В ряде случаев, при смене пользователем должности или подразделения, требуется ограничить или убрать ставшие не нужными права. И в случае обработки таких типовых запросов необходимо не упускать этот важный этап.

Что остается за кадром для первой линии поддержки и выполняется на второй или даже третьей, а, возможно, только службой безопасности компании? Это «Мониторинг состояния идентификаторов» (Monitoring Identity Status) и «Журналирование и отслеживание доступа» (Logging and Tracking Access).

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

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

  • «Я работаю над тем же проектом, что и Иванов, поэтому мне нужны такие же права на ресурсы, как у него».
  • «У него уже такие же права локального администратора на ПК, и поэтому мне тоже нужны такие же».
  • «У меня высшее техническое образование и я уже работал админом на прошлом месте. Поэтому мне нужно...»

***

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

  1. Словарь терминов ITIL® на русском языке – http://itsmforum.ru/ZAM-test/Russian_2011_Glossary_v2.0.pdf.
  2. Барамба С. SLR, OLA, SLA. Сложно о простых буквах. // «БИТ», №10, 2015 г. – С. 48-51 (http://bit.samag.ru/archive/article/1602).

В начало⇑

 

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи

Выпуск №08 (101) 2020г.
Выпуск №08 (101) 2020г. Выпуск №07 (100) 2020г. Выпуск №06 (99) 2020г. Выпуск №05 (98) 2020г. Выпуск №04 (97) 2020г. Выпуск №03 (96) 2020г. Выпуск №02 (95) 2020г. Выпуск №01 (94) 2020г.
Вакансии на сайте Jooble

           

Tel.: (499) 277-12-41  Fax: (499) 277-12-45  E-mail: sa@samag.ru

 

Copyright © Системный администратор

  Яндекс.Метрика