Каталогизация ИТ-услуг для среднего бизнеса

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

Эта статья будет посвящена проблеме приоритизации ИТ-задач для среднего и малого бизнеса. Почему только для SMB? Потому что крупный бизнес может себе позволить внедрить процессы ITIL (в данном случае управление изменениями, инцидентами и проблемами — эти три процесса являются основными для решения поставленной задачи) и купить программное обеспечение для службы поддержки, которое полностью автоматизирует управление инцидентами. Такое программное обеспечение стоит от нескольких сот до десятков тысяч долларов, и, кроме того, затраты на подобные системы для компании до 200 человек окупаться будут неоправданно долго. С чего начать?

Шаг 1

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

Например, отдел продаж пользуется следующими возможностями:

• e-mail;
• Интернет;
• Skype;
• ICQ;
• Microsoft Office.

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

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

Допустим, расстановка приоритетов для отдела продаж будет такой:

• Интернет — 3;
• Почта — 10;
• Skype — 4;
• Microsoft Office — 7;
• ICQ — 4.

В данном случае наибольшим приоритетом обладает электронная почта, так как она используется как основной инструмент коммуникаций с клиентами (телефонную связь как услугу для этой статьи я во внимание не принимал). Далее идет Microsoft Office для обработки информации, а за ним второстепенные средства коммуникаций с клиентами: Skype и ICQ. Последним по приоритетам поставлен доступ в Интернет. Заметим, что доступ в Интернет имеет самый низкий приоритет только для работы отдела продаж (в основном он будет использоваться отделом маркетинга), с точки зрения ИТ впоследствии услуга «Интернет» для этого отдела будет иметь высокий приоритет, так как на него опираются все остальные службы, кроме офисных приложений.

Шаг 2

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

• DHCP;
• DNS;
• подача электропитания;
• локальная сеть (маршрутизация, коммутация);
• структурированная кабельная система (СКС);
• антивирусная система;
• физические серверы;
• рабочие станции (компьютер + операционная система)

и другие.

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

Шаг 3

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

Карта зависимостей для отдела продаж показана на рисунке 1. Приведем краткое описание схемы. Начнем с фундаментальных служб. Я выделил три разные группы обеспечения питанием: для рабочих станций, для серверов и для локальной сети. Критичность этих групп отличается: если у одной рабочей станции отказал блок питания — это простой одной рабочей станции и одного человека, а если «умер» источник бесперебойного питания, который поддерживал сервер и теперь никто не может ни выйти в Интернет, ни получить доступ в домен — это проблема совсем другого уровня. Кроме того существуют серверные приложения, которые должны иметь доступность 99,999% (например, приложение для электронной коммерции), а значит, соответствующий сервер должен получать питание при любых обстоятельствах. Еще одним фундаментальным сервисом является СКС — это кабельная система, патчпанели, сетевые розетки. Как видно из схемы, СКС является опорным сервисом только для локальной сети, и действительно, рабочим станциям или серверам напрямую для работы СКС не нужна, а вот службам, которые могут работать на этих серверах или рабочих станциях, может понадобиться. Далее идут три сервиса: рабочая станция, сервер и локальная сеть. DNS и DHCP опираются на сервер и локальную сеть, но друг с другом не связаны. Active Directory опирается на сервер и на DNS. Интернет опирается на DNS, DHCP и рабочую станцию. Заметим, что сервис доступа к глобальной сети Интернет в нашем случае интересен непосредственно для сотрудников, именно поэтому есть опора на рабочую станцию (операционная система и браузер). Сервис «Интернет» для служебных устройств сети в этом примере нас не интересует. Следом идут службы высшего уровня, которые являются конечными в цепочке и не представляют собой опору для других: Microsoft Office (нужна только рабочая станция), Skype и ICQ (нужен доступ в Интернет и рабочая станция для установки клиента), почта (опирается на сервер Microsoft Exchange, Active Directory и Интернет).

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

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

1. Обеспечение электропитания (3 сервиса).
2. Рабочие станции.
3. Рабочее программное обеспечение (Word, Excel, Acrobat …).
4. СКС.
5. Локальная сеть.
6. Серверы.
7. DNS.
8. DHCP.
9. Active Directory.
10. Интернет.
11. Электронная почта.
12. Skype.
13. ICQ.

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

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

Шаг 4

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

• Microsoft Office — 0 (этот сервис не является опорой для других);
• рабочая станция — 4;
• локальная сеть — 10 (3 сервиса опираются на «Интернет» + 2 связи (Интернет — DHCP, Интернет — DNS) + 2 связи от AD (почта — на AD, AD на DNS) + 3 прямых связи от «Интернет», DNS и DHCP).

Шаг 5

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

Шаг 6

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

Для нашего примера я взял следующие цифры:

• отдел продаж = 10;
• отдел маркетинга = 5;
• отдел юриспруденции = 2.

Шаг 7

Добавляем приоритет отдела из предыдущего пункта ко всем приоритетам служб в общей таблице, полученной в пункте 5 в соответствующей колонке отдела. В таблице 1 показан пример конечных данных по приоритетам служб для разных отделов. Я включил сюда пару новых служб («Лига» и «Антивирус»). В моих подсчетах «Лига» имела для юр. отдела достаточно высокий приоритет (8), но, поскольку приоритет самого юр. отдела невысок (2) — финальное значение приоритета этой службы также небольшое.

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

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

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

Показатели значений для рабочих станций говорят о том, насколько много ИТ-служб потребляет отдел относительно других. Отдел продаж в нашем примере имеет наивысшее значение приоритета для рабочих станций, так как пользуется наибольшим среди всех отделов числом ИТ-услуг (e-mail, Интернет, Skype, ICQ и Microsoft Office).

Шаг 8

Что мы делаем дальше? Берем табличные данные только для клиентских служб и ищем максимальное значение (таблица 2).

Наибольшее значение — это приоритет для рабочих станций отдела продаж (45). Теперь думаем, на сколько классов обслуживания мы будем разбивать нашу таблицу приоритетов (можно взять 3, а можно 4). В примере я возьму значение 4. Берем максимальное значение приоритета, то есть 45, и делим на желаемое число классов обслуживания. Получим:

45/4 ≈ 12

(с округлением к целому числу вверх).

Ниже дано краткое описание полученных четырех классов обслуживания.

Класс 4

Значение приоритета 1–12.

Обслуживание на уровне Best Effort, то есть когда будет свободное время.

Примеры: выполнение запросов на простое обслуживание (поменять картридж в принтере), поставить офис.

Класс 3

Значение приоритета 13–24.

Обслуживание на уровне среднего приоритета (в зависимости от выбранного алгоритма обработки очередей, о них будет идти речь далее).

Примеры: решение проблем с подключением к Интернету.

Класс 2

Значение приоритета 25–36.

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

Примеры: переустановка или ремонт рабочих станций и их компонентов.

Класс 1 (тревога по коду «красное»)

Значение приоритета более 37.

Обслуживание на уровне максимального приоритета, реагирование происходит немедленно.

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

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

Шаг 9

Выбор алгоритма работы с очередями. Для работы с очередями задач в нескольких классах можно использовать два алгоритма: PQ (priority queuing) и LLQ (low latency queuing).

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

Для Priority Queuing обработка очередей задач показана на рисунке 2.

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

Теперь рассмотрим LLQ. LLQ — это более «добрый» алгоритм, хотя не менее эффективный. Алгоритм также подразумевает наличие одной высокоприоритетной очереди, которая будет обслуживаться без ожидания, но внимание остальным задачам класса будет уделяться по циклическому алгоритму (Round Robin) в зависимости от приоритета. Например:

• очередь 2–3 задачи;
• очередь 3–2 задачи;
• очередь 4–1 задача.

Схема для обработки задач по алгоритму LLQ показана на рисунке 3.

Первые 4 задачи будут выполнены так же, как и в предыдущем алгоритме. Затем переходим к классу High priority, в котором можно выполнить 3 задачи, а осталась только одна — выполняем, переходим на класс ниже. В классе с Medium priority мы можем выполнить 2 задачи, после чего должны выполнить одну из очереди с минимальным приоритетом, затем опять 2 задачи из класса выше. Этот алгоритм не позволяет «голодать» задачам в низкоприоритетных очередях, и хотя такие очереди движутся медленно, но все же движутся.

Бонусы и модификаторы

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

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

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

Создание каталога

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

Каждый сервис должен быть охарактеризован следующими данными:

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

Пример представлен в табл. 3.

Завершающие шаги

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

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

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

Еще одним полезным эффектом является отслеживание тенденций инцидентов: допустим, за некоторое время произошло некоторое количество инцидентов, связанных с конкретным сервисом, затем отдел ИТ внедрил решение, которое решило проблему. Теперь можно смело показывать руководству число инцидентов, которое было тогда, и нынешние показатели. Подобные замеры должны проводиться для всех служб и на их основе должны формироваться Key Performance Indicator (индикаторы производительности) для отдела ИТ, показатели которых, в свою очередь, должны привязываться к программе мотивации сотрудников ИТ. Необходимость найма дополнительных сотрудников в отдел ИТ опять-таки может быть обоснована с помощью журнала инцидентов, где будут видны постоянные откладывания неприоритетных задач и длинные очереди при нормальных показателях времени для обработанных инцидентов.

Кстати, решение задачи, поставленной в начале статьи, будет таким:

1. Инцидент с вирусом в отделе маркетинга (приоритет 50), если антивирус пропустил вирус на компьютер — есть угроза эпидемии.
2. Мышка начальника отдела (приоритет 28, то есть рабочая станция).
3. Почтовый клиент отдела продаж (приоритет 20, в отсутствие доступа к почте, но при нормальном состоянии рабочей станции специалист по продажам может временно заниматься другими делами).

В основу статьи были заложены фундаментальные практики ITIL, которые я сильно изменил для адаптации под реалии среднего и малого бизнеса. Алгоритмы работы с очередями — это адаптированные версии алгоритмов Quality of Service для сетей компании Cisco, а система подсчета приоритетов для ИТ-услуг создана мной «с нуля».

Алексей Зайончковский (zedcenter@gmail.com) — инструктор академии «БМС-Консалтинг»; директор учебного центра Z-Center при факультете информатики Киевского политехнического института. Имеет сертификат CCNA