апрель    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
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

показать все 

22.04.2024

Сообщество цифровых управленцев «я-ИТ-ы» проводит ЗАКРЫТУЮ встречу в рамках выставки «Связь-2024»!

Читать далее 

18.04.2024

Ассоциация разработчиков «Отечественный софт» отметила 15-летие

Читать далее 

17.04.2024

РДТЕХ представил Технологическую карту российского ПО 2023

Читать далее 

16.04.2024

RAMAX Group получила партнерский статус уровня Gold по продукту Tarantool

Читать далее 

показать все 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

18.04.2024

Цифровая трансформация в энергетике: как запустить проект с максимальным финансовым эффектом?

Читать далее 

05.04.2024

Мотивируй, не то проиграешь!

Читать далее 

22.03.2024

В 2024 году в России и мире вырастут объемы применения AR/VR 

Читать далее 

25.02.2024

Цифровые технологии: надежды и риски

Читать далее 

05.02.2024

Будут ли востребованы услуги технической поддержки софта Oracle в России в ближайшие годы?  

Читать далее 

31.01.2024

Здания с признаками интеллекта. Как Сергей Провалихин автоматизирует дома и производства

Читать далее 

показать все 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кратко об ITIL

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

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

Кратко о каждой из книг, входящих в состав 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. Пошаговый алгоритм разрешения инцидента

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

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

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

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

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

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

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

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

Проверка (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).

В начало⇑

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

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