Недавно мне было поручена задача по реанимации системы сервис деск системы на основе уже развернутой GLPI. Про развертывание самой системы писать не буду, благо этой информации в сети полно. Причины внедрения также, как мне кажется понятны (у все они одни и те же). Я же столкнулся с тем, что не смог найти ни одной нормальной статьи непосредственно по вводу в эксплуатацию данной системы. Собственно, об этом и будет этот пост.
Первая часть поста будет теоретической — о подготовке к вводу в эксплуатацию, вторая часть о настройке системы.
1. Анализ текущей деятельности отдела
Пару слов о компании:
Основное направление — строительство, постоянный штат >150 человек, >5 удаленных объектов.
О самом отделе:
В отделе работает 6 человек:
- 1С программист — решает вопросы по внедрению полезного софта для нужд компании;
- Специалист технической поддержки — ваш покорный слуга, основное направление — поддержка пользователей, второстепенно — разработка документации отдела и т.д.;
- Сетевой администратор — администрирование серверов компании, телефонии и т.д.;
- Веб-разработчик — отвечает за сайт компании;
- Специалист по инфраструктуре — внутренняя инфраструктура компании;
- Руководитель службы ИТ.
Вывод:
В результате знакомства с обязанностями сотрудников было выведено четыре основных направления для настройки и использования системы:
- Поддержка — сюда входят запросы на изменения, инциденты, критичные инциденты. Крайний срок для такого типа обращений устанавливается согласно каталогу сервисов (о нем ниже);
- Сопровождение — внесение изменений в используемые системы, ресурсы, настройки оборудования. Крайний срок устанавливается ответственным за решения заявки специалистом;
- Проекты (отдельный модуль GLPI) — работа над новыми проектами. Заданные критерии для определения проекта: есть время начала и время окончания, есть четкие задачи (вехи проекта), есть группа участников, есть цель. Крайний срок устанавливается проектной группой;
- Задачи руководителя отдела своим сотрудникам.
Также было принято решение оказания многоуровневой поддержки. Изначально рассматривался вопрос одноуровневой поддержки, но в таком случае обращения дублировались.
2. Подготовка к внутренней настройке системы GLPI (теория, документация)
Первый этап ввода системы в эксплуатацию — это описание теоретической части работы системы и работы с системой. Не буду кривить душой, многое вещи документировались уже в процессе настройки системы (как раз из-за отсутствия туториала по данной системе).
Каталог сервисов:
В лучших традициях itil было принято решение составить каталог сервисов компании и описать оказываемые услуги. После чего прописать метрики, SLA для заявок, ответственных за решение задач. Каталог сервисов имеет следующую структуру:
- Вкладка «Сервис» — наименование сервиса, например, почта, 1С, телефония и т.д.;
- Вкладка «Услуги» — услуги, оказываемые в рамках сервиса, например, настройка учетной записи, предоставление доступа и т.д.;
- Вкладка «Пользователи» — описание групп пользователей, использующих сервис, например, топ-менеджмент, администрация, канцелярия и т.д.;
- Вкладка «Доступность» — описание уровня доступности сервиса, например, 24х7, 5х40 и т.д.;
- Вкладка «Влияние» — описание уровня критичности сервиса, влияния на другие сервисы, влияние на бизнес-процессы компании;
- Вкладка «Ответственные» — ответственные за оказание услуг специалисты;
- Вкладка «Метрики» — описание измеримых метрик, например, время реакции на обращение, максимальное время решения обращения, допустимое количество обращений в конкретный срок и т.д.
Типы заявок:
Далее был процесс разделения заявок/обращений на типы:
- Запрос — все заявки на изменение чего-либо, например, предоставление/изменение прав доступа, установку программного обеспечения и т.д., решение таких обращений в режиме 5х40;
- Инцидент — временная приостановка доступа или работы сервиса для 1-3х человек единовременно, решение таких обращений в режиме 5х40;
- Критичный инцидент — недоступность сервиса для 4х и более человек единовременно, решение таких обращений происходит в режиме 24х7.
Группы:
Разделение отдела на группы (с заделом на расширение штата) и назначение ответственных:
Так как было принято решение использовать модель многоуровневой поддержки с разным направлением работы и взаимодействия с системой glpi, было выделено несколько групп:
- Инфраструктура — сюда вошли: сетевая инфраструктура, разработка стандартов, поддержка шлюзов, поддержка сетевого оборудования. Ответственный — сетевой администратор;
- Телефония — обслуживание АТС, администрирование абонентов, стыки с call — центром. Ответственный сетевой администратор;
- Пользователи и пользовательское оборудование — здесь собраны установка и поддержка рабочих мест, подключение периферии, ремонт техники, замена расходных материалов и т.д;
- Серверная инфраструктура — ответственный специалист по инфраструктуре;
- Веб ресурсы — создание, поддержка и сопровождение. Ответственный веб-разработчик;
- Корпоративные информационные системы. Разработка и релизы, администрирование прав пользователей, работа с подрядными организациями. Ответственные — 1С разработчик.
- Сторонние ИТ-услуги. Мобильная связь, КПД, Интернет — это то, что находится на аутосорсе.
Данное разделение позволило разграничить зоны ответственности и снять с повестки дня вопрос — почему сотрудников контролирует их коллега.
SLA:
Дальше наступило время проработки SLA (крайнего срока обращений). Ниже я привожу факторы, которые повлияли на установку SLA конкретно в нашем случае.
- Местоположение заказчика. Некоторые вопросы требуют выезда к заказчику на площадку, соответственно крайний срок для таких обращений закладывался с учетом времени в пути +20% времени от обычного SLA;
- Критичность/влияние — SLA для обращений, оказывающих заметное влияние на бизнес-процессы компании устанавливался минимально возможный срок решения (в рамках разумного);
- Ответственность за сервис. Здесь имеется ввиду чей сервис недоступен — наш или провайдера. В случае недоступности сервиса со стороны провайдера, например, интернет, SLA брался из договора оказания услуг.
Вот эти три показателя изменяли SLA в большую или меньшую сторону. Разумеется, SLA в каждой компании будет свой, здесь я просто обозначил те позиции, на которые, на мой взгляд, стоит обратить внимание.
После проработки данной теоретической части я приступил к внутренней настройке системы. Об этом во второй части.
Автор: Quattro805
