Техническая поддержка филиальной сети – достаточно типовая задача для ИТ-специалиста. Часто это были весьма специфичные решения: начиная от использования собраний в 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 и другие, office@itfb.com.ua или в раздел контакты