32
Рисунок 12. Lan State Pro
Такие инструменты особенно важны для сотрудников, которые входят в
курс дела по компании и не имели ранее опыта обслуживания этого
клиента/офиса. Очень важно отражать все изменения в компании на этой карте.
Неполная информация может привести к ошибочным действиям специалиста,
который не верно оценит ситуацию, и как следствие может вывести из строя
как отдельные сервисы, так и всю инфраструктуру компании в целом.
Можно привести простейший пример: поступает заявка с отсутствием
сетевого подключения на одном из компьютеров, специалист не имеет
информации по коммутации кабелей у клиента. Оказавшись около компьютера,
нашел коммутатор, из которого были вынуты коммутационные кабели. Принял
решение воткнуть кабели обратно и дважды это проделал с одним кабелем, так
как он был не подписан и вообще коммутатор не был задокументирован на
карте сети. Это, в свою очередь, привело к петле (кольцу) и привело к
неработоспособности всего сегмента сети.
33
Еще один важный инструмент, который требуется в системном
администрировании - это учет базы лицензий, стоимость которых зачастую
превышает стоимость оборудования. Потеря данных по лицензиям может
привести к крупным финансовым затратам организации, которые ко всему
могут повесить на IT отдел, который не относился с должным вниманием к
учету интеллектуальных материальных ценностей.
Существуют достаточно удобные инструменты для учета лицензий. Один
из основных игроков на рынке подобных продуктов – это «10-strike учет
программного обеспечения». На рисунке ниже изображен пример подобного
программного обеспечения (рисунок 13).
Рисунок 13. Учет программного обеспечения
Компьютеры можно группировать по отделам. Оперативно можно
просмотреть по каждому компьютеру список установленного программного
обеспечения с серийными номерами. Так же можно вести заметки по
34
программному обеспечению, которое должно быть установлено на
компьютере/сервере.
2.5 Системы управления заявками и инцидентами
Работа современной и эффективной IT поддержки не может быть
представлена без системы управления заявками (тикетной системы). Системы
подобного рода позволяют принять, классифицировать, отслеживать статус
инцидентов.
Качественная система должна быть гибкой и помимо базового
функционала должна иметь возможность изменять и дорабатывать функции
под конкретную компанию, в виду того, что у каждой компании есть своя
специфика взаимодействия, и видение разработчика порой может немного
отличаться от того, как этот процесс представляет себе клиент. Системы такого
рода, как правило, управляются не только с помощью браузера, но имеются и
свои программные клиенты.
Системы подобного рода порой имеют богатый функционал,
ограничивающийся не только управлением заявками, но и дополнительными
модулями, как платными, так и бесплатными, обеспечивающими управление IT
активами, функции управления взаимоотношений с клиентами, создание базы
знаний wiki и другие.
Некоторые из них [15]:
Open Ticket Request System – бесплатная helpdesk система,
качественно написанная на языке perl с поддержкой множества
СУБД. OTRS используют такие гиганты, как Яндекс, Mail.RU,
REG.RU, Mikrotik, RU-CENTER и многие другие;
hd.rustem – это HelpDesk веб-система, для организации учета
выполнения задач (заявок) между структурными подразделениями
и пользователями или клиентами организации;
35
vsDesk – это Российская разработка, которая имеет как платную
версию без ограничений, так и бесплатную с ограничениями;
Clarisdesk – это очередная российская разработка, имеющая как
свой клиент серверный вариант установки, так и вариант
использования SaaS(в аренду на серверах разработчика);
1С Bitrix – это известный продукт от одного из крупнейших
российских программных гигантов. Имеет огромное количество
дополнительных модулей и возможностей интеграции с
телефонией. Позволяет автоматически классифицировать звонок
как заявку. Имеет клиент серверный вариант установки, так и
вариант использования SaaS (в аренду на серверах разработчика).
На рисунке 14 виден интерфейс подобных систем на примере Битрикс.
Рисунок 14. «1С Битрикс»
36
Как правило, специалист технической поддержки должен видеть в
режиме реального времени заявки, сроки их выполнения, тему заявки, от кого
она пришла, ответственное лицо. Ответственные лица зачастую назначаются
шаблонно по заранее заготовленному алгоритму.
Например, при заполнении заявки клиент/пользователь выбирает из
всплывающих меню, какого характера у него проблема и по определенному
алгоритму заявки попадают к определенным заранее сотрудникам, которые
специализированы на решении характерных задач. На рисунке 15 можно
увидеть форму заявки.
Рисунок 15. Форма заявки
37
Внедрение такого рода продукта позволит руководителю
компании/отдела эффективно контролировать выполнение сотрудниками
заявок, отслеживать состояние нагрузки технической поддержки и
предпринимать меры по улучшению эффективности ее работы.
Так же зачастую в такие продукты встроены функции аналогичного
контроля со стороны клиента/пользователя. Клиент видит свои заявки.
Руководитель отдела видит заявки своих подчиненных. Руководитель компании
видит задачи руководителей отдела и их подчиненных.
Все это можно представить в виде древовидной структуры, которой
пользуется как клиент, так и техническая поддержка, показанной на рисунке 16.
Рисунок 16. Схема древовидной структуры
2.6 Определение полномочий
Очень важный аспект функционирования технической поддержки – это
понимание структуры полномочий клиента/пользователя. Необходимо на
начальном этапе документировать уровень полномочий пользователя,
создающего заявку/инцидент. Сделавши это заблаговременно, можно избавить
себя от:
лишних заявок;
38
несанкционированной утечки информации;
потери, порчи информации.
Для определения полномочий отделов/компаний/сотрудников требуется
для начала проанализировать все информационные ресурсы компании,
классифицировать их по типу. В ходе инвентаризации и классификации важно
предоставить информацию в удобном для понимания виде для клиента.
Обязательно требуется сделать поправку на тот момент, что сотрудник,
принимающий подобные решения, может быть некомпетентен в вопросах IT.
Например, имеется небольшая компания, у которой в активе имеется свой
файловый сервер, на котором хранятся данные сотрудников компании,
представляющие существенную ценность для нее. И для ее руководства
критично, чтобы сотрудники различных отделов могли получить только ту
информацию, которая соответствует этим отделам и некоторые общие
обменные ресурсы. Следует начать со сбора структуры папок файлового
сервера. Представим пример на рисунке 17.
Рисунок 17. Права доступа
39
Не следует опускаться на уровни ниже (внутрь папок), так как алгоритм
действий примерно одинаков. Нужно запросить у руководства компании
данные, какие должности могут запрашивать права в каких папках. Следует
акцентировать внимание не на конкретных сотрудниках, а на должностях, и
обусловлено это тем, что сотрудник может переходить из отдела в отдел и
менять при этом должность.
Например:
руководители отделов имеют права запрашивать доступ только к
своей папке – соответствующей его отделу;
рядовой сотрудник не может инициировать напрямую заявки на
предоставления доступа кроме общей папки.
Аналогично можно прорисовать политику доступа к базам данных,
предоставлению паролей от WIFI, предоставлению доступа к сети интернет,
установке программ.
Например:
заместитель директора – любые заявки;
руководитель отдела – заявки, касающиеся только сотрудников его
отдела внутри его папки, в том числе установка программ,
предоставление доступа в интернет.
рядовой сотрудник – заявки касающиеся проблем с его
компьютером.
Также можно дополнить полномочия на запрос закупки оборудования,
программного обеспечения, вызова сервисных инженеров и др.
Например:
заместитель директора – любые заявки кроме закупки нового
оборудования;
руководитель отдела – заявки на закупку расходных материалов и
мелкой компьютерной периферии.
40
В таком случае, если видим, что заявка сотрудника находится за
пределами его компетенций, то перенаправляем его к вышестоящему
руководству, а, соответственно, если у руководителя сотрудника тоже
отсутствуют такие полномочия, то переходим к следующему сотруднику в
иерархии компании.
2.7 Выводы по второй главе
В рамках общего исследования по теме работы были получены
следующие результаты.
1. Изучены общие методы и принципы, применяемые при системном
администрировании.
2. Выполнен обзор основных и актуальных на момент исследования
инструментов, применяемых при удаленном администрировании. Было
выяснено, что все инструменты с развитием технологий эволюционируют,
позволяют ускорить и упростить администрирование компьютеров, серверов,
других систем.
3. Рассмотрены основные принципы планирования в системном
администрировании, при этом можно использовать их как эффективный
инструмент предупреждения многих проблем в компании.
4. Показано, что управление активами можно также расценивать как не
менее важный инструмент, позволяющий объективно оценивать состояние
инфраструктуры компании и четко понимать чем владеет компания, насколько
отстало ее техническое оснащение.
5. Сделан вывод о том, что надежное хранение информации по компании-
клиенту – одна из гарантий отсутствия утечки и потери информации. Была
представлена группа инструментов, позволяющих реализовать эту проблему.
6. Определено, что ни одна современная компания не может обойтись без
хорошей системы управления заявками, которая позволяет структурировать все
41
проблемы и инциденты компании. Представлены основы определения
полномочий сотрудников.