Мастерская IT решений

Если вы думаете, что после запуска в «промышленную эксплуатация» службы ServiceDesk  все административные вопросы закончатся — то это глубокое заблуждение. Вопросы останутся, просто они видоизменятся и трансформируются в новом направлении.

    1. Ротация сотрудников отдела Service Desk. Типовой пример на который нужно ориентироваться — первая линия поддержки. У операторов ServiceDesk зачастую очень быстро накапливаются необходимые навыки для перехода на другую должность или наоборот, т.е. быстрая ротация сотрудников при количестве операторов больше 4-5. Огромным плюсом правильно организованной ротации является то, что после операторской работы часто выходят перспективные кадры с пониманием проблем пользователей и базовым знанием всех ИТ-систем и предоставляемых ИТ-услуг организации.

2. Альтернативные способы работы. Ввиду того, что со временем Service Desk станет важным звеном при обслуживании пользователей, то перебой в ее работе стенает заметен заметен всей организации. Необходимо проанализировав ее работу иметь экспрессный план на случай оперативного восстановления доступа к нужной информации.

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

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

Итог:

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

На мой взгляд, когда мы слышим такой вопрос — значит само внедрение ServiceDesk  и его пост жизненный цикл прошели успешно. Это последний вопрос при внедрении ServieDesk, и на него я постараюсь ответить в следующих статьях.

Остается только один вопрос — а почему у Вас еще не внедрен SrviceDesk?

   Создание службы Service Desk является в прежде всего организационной (административной) задачей. А это накладывает соответствующий отпечаток в виде необходимости подготовки соответствующей нормативной базы в виде регламентов, приказов, распоряжений.

Давайте рассмотрим типовое решение по созданию службы Service Desk, тут стоит кратко описать подход, согласно которому будет развиваться проект.

В соответствии с этим подходом задачи проектирования службы Service Desk можно разбить на следующие этапы:

    1. «начало проекта» — это отправная точна, связанная с началом планирования работ, формирование проектной команды, решение организационных вопросов. Средняя продолжительность – 1–2 недели;

» Читать дальше »

    Первый вопрос который обычно ставит руководство — обязательно ли организовывать Service Desk?

Внедрение службы Service Desk целесообразно по многим причинам. Многие современные средства автоматизации предусматривают возможность регистрации заявок самим пользователем (через Web-формы, emai письма). Однако пользователь порой не в состоянии квалифицированно определить суть проблемы. Но даже если он может провести самостоятельную классификацию, все равно требуется уточнение (или, как минимум, подтверждение) специалиста. Автоматизированный ввод инцидентов самим пользователем не отменяет механизма ввода и модерации специалистом службы Service Desk, поскольку в ряде случаев пользователь просто не имеет возможности завести заявку (инцидент) для автоматической обработки.

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

» Читать дальше »

Взаимодействие с системой ServiceDesk (заявки).

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

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

В процессе работы с заявками стоит определится с иерархией в структурированном ИТ подразделении. Будем считать, что ИТ подразделение (отдел, департамент) четко структурирован по линиям поддержки (1/2/3…) в зависимости от размера подразделения, выполняемых обязанностей и т.д. В развитых подразделениях таких уровней поддержки может быть до 5. В нашем случае рассмотрим 3 уровня поддержки.

В процессе работы с заявками выделяются следующие роли:

Автор заявки – сотрудник, который имеет право формировать новые заявки.
Специалист – сотрудник, который проверяет корректность оформления заявки, распределяет заявки между Исполнителями.
Исполнители – сотрудники, которым поступают заявки на исполнение.

Рассмотрим самый простой алгоритм управления заявками Service Desk.

» Читать дальше »

Привязка IP адреса к сетевому интерфейсу

По умолчанию в Citrix Netscaler отсутствует привязка ip адрес – сетевой интерфейс, т.е. весь трафик идет по всем активным интерфейсам, своего рода хаб. Это может привести к положению, когда запрос пришел на один интерфейс, а ответ на него по-другому интерфейсу. А из-за топологии сети, это может привести к потере пакетов и нарушению связи.

Для решения данной задачи необходимо использовать VLAN.

Логика такая: IP адрес привязываем к VLAN который привязываем к интерфейсу.

Теперь поподробнее.

» Читать дальше »

Многим администраторам vSphere / ESX необходимо было в своей работе включать сервис SSH.

Но досадная неожиданность, сразу после включения сервиса — хост ESX выдавал WARNING, конечно его пугаться не стоит просто согласно политики безопасности рекомендованной vmware — прямой SSH доступ к хосту esx не безопасен.  Но что делать если надо, а предупреждение отвлекает?

Ту все достаточно просто:

» Читать дальше »

 Много раз я задумывался о резервном копировании NetScaler, для этого первое время достаточно было копировать файл настроек ns.conf. Но со временем, пришло понимание, что нужны и файлы лицензий, сертификаты.

» Читать дальше »