Техническая поддержка филиальной сети – достаточно типовая задача для ИТ-специалиста. Часто это были весьма специфичные решения: начиная от использования собраний в Outlook как HelpDesk-системы и заканчивая использованием антивируса в качестве системы мониторинга удаленных хостов. Так или иначе, за некоторое время удается подобрать системы, которые наилучшим образом подходят для решения задач подразделения технической поддержки.
Как правило, в технической поддержке нужны следующие категории систем:
- Система HelpDesk
- Мессенджер
- Система базы знаний
- Система мониторинга удаленных рабочих станций
- Система управления конфигурациями
- Система удаленного управления рабочими станциями
- Система централизованной установки софта и административных действий на рабочих станциях
- Система развертывания релизов (обновления конфигурации)
- Система учета ИТ-оборудования
Часто это неполный перечень информационных систем, которые используются в компаниях. Универсальные решения от вендоров (Microsoft/1C/SAP) достаточно хорошо выполняют одни задачи и абсолютно не проработаны для других. Поэтому со временем я пришел к выводу, что для каждой группы задач нужно подбирать свою систему, которая подходит для них наилучшим образом. Часто подобные узкоспециализированные системы не стоят денег, т.к. являются достаточно простыми Open Source-решениями. Если подходящей системы не существует, бывает проще вложить силы в разработку, чем использовать некоторые половинчатые решения. Далее рассмотрим отдельно системы каждой категории.
Система HelpDesk
Является, по сути, центральной системой для технической поддержки. От ее выбора зависит очень много.
У меня была возможность протестировать многие решения подобного рода:
- HP OpenView
- ManageEngine
- Mantis
- Redmine
- 1С Итилиум
- 1С ITIL
- OTRS
- JIRA Service Desk
Как правило, мой выбор всегда останавливается на решениях от «1С» – по элементарно простым причинам: вся техподдержка умеет с ними работать (1С-ный интерфейс знаком весьма неплохо) и кастомизация систем ограничена только личными фантазиями (в штате есть 1С-программисты). Наиболее выгодным образом выглядит 1С:ITIL. Данная система является достаточно функциональной, на рынке существует давно, весьма проработана. Исходный код полностью открыт, лицензии нужны только обычные 1С. В части функциональности при этом ничем особо не уступает дорогим продуктам от HP. Кроме всего прочего, содержит в себе модули управления конфигурациями и учета оборудования.
Но в настоящий момент мы используем JIRA Service Desk. Перед 1С ITIL у нее есть ряд преимуществ:
Полноценный веб-интерфейс, который позволяет с ней работать без проблем с удаленных компьютеров без установленного клиента 1С (веб-интерфейс от 1С все-таки оставляет желать много лучшего).
Удобный функционал очередей для распределения заявок (у 1С все-таки все в куче – другой принцип).
Для нас нормальный веб-интерфейс оказался критичен – много сотрудников, не знакомых с 1С, работают удаленно. Кроме всего прочего, сама система очень неплоха.
Система базы знаний
Каждая уважающая себя HelpDesk-система имеет внутри себя базу знаний. Использовать базу знаний внутри HelpDesk-системы кажется логичным на первый взгляд. К сожалению, только на первый. Мне не встречалось ни одной удачной реализации базы знаний внутри HelpDesk-системы. Это все-таки должен быть специализированный продукт, решающий подобные задачи. База знаний – это не набор неструктурированных документов Word, описывающих разные процессы, это не папка с инструкциями, это не набор бессвязных ответов на обращения. База знаний – некоторое структурированное хранилище информации, актуальность которого поддерживается и отслеживается, по нему должен быть доступен поиск. Разумеется, идеальная база знаний должна быть в формате Wiki, который уже давно стал стандартом для подобного рода решений. Из Wiki-движков как наиболее функциональные можно выделить следующие:
- MediaWiki
- DokuWiki
- Sharepoint Wiki MediaWiki
- Confluence
естественно, вне конкуренции по технической реализации и набору функциональности, но для корпоративной базы знаний, как оказалось на практике, он подходит не лучшим образом:
- Файлы хранятся в БД, соответственно, конвертировать из Word нет никакой возможности.
- Достаточно долго и проблемно работать с рисунками.
- Трудно использовать внешние ресурсы.
- Внешний вид практически не кастомизируется от стандартного.
Как вы догадались, всех этих недостатков лишен движок DokuWiki , на мой взгляд, конечно. DokuWiki – единственный мне известный движок, который не использует хранение статей непосредственно в БД. Это можно рассматривать как недостаток для современных систем, но, как показала моя практика, для корпоративных баз знаний хранение статей в виде файлов имеет ряд неоспоримых преимуществ:
- Простота конвертации из страниц других форматов. Перед тем как у вас появится Wiki, вы наверняка уже имеете кучу инструкций в формате Word, PDF или аналогичных. Собственно, первичная задача конвертировать их в Wiki; вот тут внедрение базы знаний часто и заканчивается. В случае с DokuWiki вы просто преобразовываете все эти файлы в html, а затем применяете обычный конвертер Wiki-разметки.
- Простота формирования разделов. При формировании разделов для переноса групп страниц и их переименования достаточно просто выполнить операции с файлами, что обычно делается быстро и проблем не вызывает.
- Простота настройки. В отличие от той же MediaWiki, DokuWiki ориентированана внутреннее использование, что позволяет сделать более простые настройки безопасности, более простое и понятное формирование разделов.
Мессенджер
Как это ни странно, мессенджер технической поддержке необходим. Для коммуникации с сотрудниками компании мы чаще всего используем Skype – не корпоративный, т.к. он вызывает много проблем с привязкой к домену, который есть не во всех удаленных узлах. Skype в последнее время стал намного хуже, и настало время подыскивать альтернативы.
Хорошей альтернативой был корпоративный Jabber – открытые протоколы позволяют достаточно удобно с ним взаимодействовать, кроме того, обслуживают мессенджер серверы внутри компании. Но для использования Jabber его нужно централизованно внедрять, в то время как Skype возникает «стихийно».
Существует также мессенджер внутри отдела – общий чат технической поддержки. В современном мире это стало уже «стандартом». Мы для него используем Telegram – пожалуй, наиболее быстрый, удобный, безопасный мессенджер. Для него существует нормальный (быстрый, удобный, не подвисающий, в отличие от того же Viber) десктопный клиент. Возможности передачи больших файлов тоже бывают полезны. Самое главное, почему мы выбрали Telegram, – это возможность разрабатывать диагностические боты. Открытый API для создания ботов сделал данный мессенджер чрезвычайно популярным среди ИТ-команд.
Система удаленного управления рабочими станциями
Набор данных систем достаточно узок. Скорее всего с большей частью из них вы уже сталкивались:
- Ammy Admin
- Radmin
- TeamViewer
- TightVNC
Рисунок 2. Система собственной разработки для развертывания релизов, мониторинга и административных действий на рабочих станциях
Открытый API для создания ботов сделал мессенджер внутри отдела технической поддержки чрезвычайно популярным среди ИТ-команд Администрирование 36 апрель 2017 системный администратор инструменты
Сразу оговорюсь, что основным требованием к этой системе была ее цена и открытость, поэтому TightVNC была вне конкуренции. TightVNC – бесплатное решение, кроме того, в отличие от AmmyAdmin она имеет достаточно широкий набор функций (передача файлов, служебные комбинации клавиш и т.п.), позволяет создавать ярлыки с автоматическим подключением и работает как служба.
Для нее необходимо иметь внешний IP в удаленных точках; это, конечно, неприятно, но не так критично – практически каждый интернет-провайдер предоставляет данную услугу.
Система мониторинга рабочих станций
Для решения этих задач у себя мы используем систему собственной разработки. К сожалению, перечень задач, которые приходится решать на рабочих станциях, часто слишком широк. Объединение их в рамках Active Directory накладывает некоторые ограничения и не представляется возможным.
Кроме того, даже возможностей AD было бы недостаточно. Выполнять удаленно скрипты умеет множество разнообразного софта, включая, к примеру, корпоративный антивирус, но часто перед административным действием на рабочей станции нужно организовать диалог с пользователем, получить статус этого действия, выполнять цепочку действий – каждое последующее в случае успешного завершения предыдущего.
В нашем случае также важен единый перечень рабочих станций, которые находятся под управлением. Ежедневно появляются новые или закрываются существующие. Данный список актуален в системе 1С:Розница, в которой каждая рабочая станция – это узел обмена. Плотная интеграция с системой развертывания релизов, мониторинга и административных действий – одно из основных требований. Существующие системы, как правило, имеют закрытые протоколы, поэтому для подобной интеграции понадобилось разрабатывать индивидуальные решения.
Еще одной необходимостью была возможность разработки скриптов административных действий на языке C#. Он имеет достаточно мощные средства взаимодействия с ОС, к слову, намного большие, чем у того же PowerShell. Нормальный синтаксис и удобство отладки делают скорость разработки подобных скриптов куда более высокой, чем на традиционных скриптовых языках.
Поэтому мы реализовали административные действия в виде отдельных плагинов к данной системе. Действия из каждого плагина можно выполнить по расписанию, включить в очередь, посмотреть состояние, прочитать лог и т.п.
Таким образом, развертывание релиза – это просто последовательность операций, которые выполняются последовательно, каждая следующая – в случае неуспешного выполнения предыдущей:
- резервное копирование,
- динамическое обновление,
- условное статическое обновление (ожидающее подтверждения пользователя),
- безусловное статическое обновления (с завершением работы),
- статическое обновление с перезапуском сервера.
Естественно, в системе есть очередь операций – если она не была выполнена из-за выключенной рабочей станции, она выполнится при ее включении.
Установка дополнительного софта происходит примерно по тому же принципу. Резервное копирование – тоже одна из операций, которая добавлена в расписание и включена в процедуры обновления в самое начало.
Мониторинг состояния процессора, памяти, жесткого диска и наличия интернет-соединения происходит просто при периодическом опросе агентов. В других показателях с рабочих станций из нашей практики не было необходимости. Внешний вид системы представлен на рис. 2.
Система учета ИТ-оборудования
Как было упомянуто выше, 1C ITIL мы не используем в качестве HelpDesk-системы из-за не очень подходящего вебинтерфейса, но есть задачи, для которых системы на платформе 1С просто незаменимы, – это учетные задачи внутри ИТ. В нашем случае это вопросы учета ИТ-оборудования. Для учетных задач 1С подготовлена как нельзя лучше, и 1С ITIL в частности. Решать задачи учета оборудования и конфигурации каждого ПК достаточно легко и удобно. Частично конфигурацию можно получить из AD или использовать тот же Everest. 1С ITIL поддерживает интеграцию и с тем, и с другим, но мы вполне обошлись ручными операциями.
Не возьмусь говорить, что тот набор систем, которые используем мы, самый верный и правильный, но повседневные задачи решает вполне успешно. Знать об их существовании, функциях бывает весьма полезно. Если не удается найти подходящую систему для ваших задач, не нужно бояться собственной разработки – самый простой путь не всегда самый верный.
Плотная интеграция с системой развертывания релизов, мониторинга и административных действий – одно из основных требований к системе мониторинга.
Установка, настройка и соспровождение ИТ отдела поддержки, современные продукты Jira SD, Jira confluence, bitbacket, jenkins и другие, [email protected] или в раздел контакты