Если взглянуть на набор инструментов, используемых нашей аутсорс-техподдержкой в повседневной работе, можно увидеть, что все они служат одной цели — максимально быстро и эффективно отвечать на вопросы и заявки клиентов. И у каждого была своя веская причина появиться.

Во всем спектре существующих IT-услуг техническая поддержка всегда была солью земли, альфой и омегой оказания услуг, связанных с компьютерами. Поддержка существует как для программных продуктов, так и для инфраструктуры. И цель везде у нее примерно одинакова – помогать пользователю и решать его проблемы, быть связующим звеном между ним и обслуживаемой инфраструктурой. И если личные и профессиональные качества сотрудников техподдержки остаются вне пределов сферы моего влияния (я же админ, а не психолог), то создание комфортной экосистемы для работы – одна из прямых моих профессиональных обязанностей. Техподдержка поддерживает пользователей, а я – техподдержку.

Системы, о которых пойдёт рассказ

• Сервисдеск
• Система учета времени
• Мониторинг
• Сбор логов
• Внутренняя Wiki
• Хранение паролей
• Телефония
• CMDB
• Удаленное управление
• Терминал
• Система анализа рентабельности

И первым был сервисдеск

Сервисдеск, он же тикетница, решал одну из глобальных проблем технической поддержки – заматывание заявок в условиях ограниченности ресурсов. Все заявки и сопутствующие данные по ним ранее записывались на бумажках и в журналах. Все это периодически терялось, портилось, оно отращивало ноги и радостно отправлялось пешком в Зимбабве. Чем, несомненно, радовало местных туземцев. Достаточно сказать, что по одной заявке клиент ожидал от нас реакции в течение 4 месяцев да так и не дождался.

Внедрение сервисдеска превратилось в целую эпопею, потому что налагало на сотрудников дополнительные обязанности по его ведению. И они отчаянно сопротивлялись. Приходилось делать введение плавным и постепенным. Выбор сервисдеска тоже был нетривиальной задачей, но, в конце концов, я остановился на Request Tracker-е. В принципе, он удовлетворял мои основные потребности. Ну и, конечно, куда же без допилок. Сначала сервисдеск был установлен в пилотном, тестовом режиме. Каждый сотрудник нежно брался за рукав и усаживался за комп. Далее ему читалась горячая энергичная лекция о том, как круто живется с сервисдеском, как он улучшает нашу жизнь и вообще, дай только время, и взойдет звезда пленительного счастья. Мало-помалу его начали заполнять.

Система учета времени

Следующим шагом была система списания времени. Сервисдеск доработали, в заявках появились дополнительные поля, а у менеджера — возможность оценить на что и как у техподдержки тратится время. Для возможности работы технической поддержки «в одно окно» добавили возможность приема заявок на e-mail, а также из Zabbix. То есть при наступлении события определенного уровня важности в сервисдеске создается заявка, которую дежурный назначает одному из сотрудников. Сейчас на основе данных из сервисдеска готовятся отчеты для менеджеров. Они могут точно определить, на что техническая поддержка в течение недели тратила время.

Мониторинг

Система мониторинга была введена примерно в то же время, что и сервисдеск. В качестве такой системы я остановился на Zabbix, потому что именно она обладала достаточной мощностью и надежностью вместе с определенной легкостью управления. Ее развитие нельзя назвать целенаправленным, и сейчас, в рамках систематизации, система глобально переделывается и оптимизируется. Тем не менее, определенный круг задач она начала решать уже тогда. Я стал оперативнее узнавать о типовых отказах в системе клиента и быстрее реагировать на аварии. После интеграции с сервисдеском проигнорировать аварию стало гораздо сложнее, потому что незакрытая заявка сразу вызывала вопросы. Со временем Zabbix оброс моими собственными проверками, скриптами и оптимизациями. Также была введена рассылка SMS при возникновении критических событий.

Совсем недавно мониторинг переехал на PostgreSQL, потому что производительность MySQL перестала удовлетворять. Не обошлось без мелких корявок, но все их удалось победить. Сейчас уже сложно представить мою жизнь без этого инструмента. Рассчитываю серьезно улучшать и развивать его. Прежде всего, хочу полностью переработать систему шаблонов и триггеров, отойти от стандартных и взглянуть на мониторинг именно с позиции бесперебойного предоставления сервисов, когда успехом считается предотвращенный инцидент, а не быстрое устранение его последствий.

Сбор логов

Второй частью системы мониторинга можно считать сбор логов. О нем не так много говорят админы, потому что бытует мнение, что ковыряться в логах – дело неблагодарное. С чем я в корне не согласен, потому что некоторые назревающие аппаратные сбои, например, нарушение работы оперативной памяти могут быть гораздо быстрее вычислены по соответствующим логам, чем при использовании каких-либо иных метрик.

Одно время у нас существовала система сбора логов в качестве пилотного проекта, но после переезда никак не доходят руки ее восстановить. В качестве ядра системы использовался ElasticSearch как один из самых качественных инструментов для быстрого поиска в гигантских массивах данных. Для визуализации сначала применялась Kibana, но после обновления до 4 версии она стала неудобна. Пришлось перейти на Grafana. В качестве первичного парсера выступал Logstash, который я хочу заменить на более легковесную Heka. В общем, классический стек для сбора логов. Чтобы уменьшить нагрузку на диски, планируется собирать только сообщения уровня warning и выше, и хранить их не год, как делалось изначально, а примерно месяц. Потом систему логирования обвяжу специфическими метриками и свяжу с Zabbix.

Внутренняя Wiki

Чтобы оказывать помощь своевременно и качественно, техническая поддержка должна хранить достаточно много информации, причем не только о клиентах. Это и внутренние регламенты, и руководства, и данные провайдеров, и всяческие заметки. Причем хранилище должно быть универсальным, не требующим установки специального ПО, желательно доступным отовсюду, где есть интернет. И это Wiki.

Начиналось все с MediaWiki, потому что уже был опыт использования данного движка. Однако за время применения накопился ряд претензий, в результате чего я принял решение поменять вики. Немного поискав, остановился на использовании Dokuwiki. И мне кажется, что это идеальный движок для ведения документации. Начиная с того, что все данные хранятся просто в файлах, а неймспейсы – это просто папки, в которых лежат файлы. И заканчивая всяческими удобствами, вроде плашек с замечаниями, встроенной поддержки подсветки синтаксиса, категорий, тегов, пользователей и групп, а также интеграцией с доменом.

Отдельная обалденная фишка – создание изолированных подвики, со своим главным меню, стартовой страницей и прочим, к которой можно дать доступ отдельным пользователям. Его очень удобно предоставлять сотрудникам клиентов для самостоятельного внесения информации в вики, при этом не давая доступа ко всему полю документации. Не все сразу шло гладко. Во-первых, статьи пришлось перенести «руками», синтаксисы немного разные и автопереноса не получилось. Во-вторых, на первых порах возникало много путаницы между неймспейсами, категориями и тегами. Регулярно приходилось вручную перемещать статьи, созданные где попало. В третьих, не все были знакомы с концепцией вики: «ищи, если не нашел – создай». Но все это позади, сейчас костяк документации сформирован, активно пишутся регламенты на процессы, налажена система валидации и разработаны правила по оформлению статей.

Хранение паролей

Следующей точкой боли стали пароли. Их оказалось много, несистематизированные, они хранились в нескольких местах, конфликтовали между собой, были некорректны и создавали много головной боли при удаленной настройке. Я стал искать, что можно с этим сделать. Мной были просмотрены практически все имеющиеся на тот момент (2013г.) web-приложения для хранения паролей. Почему веб? Универсальность, не требуется ничего, кроме браузера, есть доступ отовсюду, упрощенная установка (если у вас уже есть web-сервер, добавить туда еще один сайт – дело 10 минут).

Первым используемым инструментом стал Teampass. Он был могуч, поддерживал практически все, что требовалось, но… оказался предельно коряв внутри. Его движок был слеплен из нескольких других, прибитых друг к другу ржавыми гвоздями и примотанных синей изолентой. Половина заявленных вещей просто не работала, другая половина работала криво и рандомно ломалась, надо было постоянно что-то поправлять и патчить. Отдельное спасибо за процедуру установки. Она просто ломала базу при обновлении версии, причем окончательно и бесповоротно (вы все еще не бэкапите – тогда мы идем к вам). У меня есть статья с длинным списком патчей, которые надо было накладывать на инсталлятор, чтобы все прошло нормально. Ну и скорость его работы оставляла желать и желать. Кстати, недавно смотрел его последнюю версию в тестовом режиме – все стало гораздо лучше. Код почистили, баги почти все поправили, хотя в логе БД по-прежнему два миллиарда страниц, независимо от того, сколько реально есть записей.

Внутренний Чернышевский задал извечный свой вопрос: «Что делать?», и я начал искать дальше. В конце концов, остановился на Rattic. Да, он немного несерьезно выглядит, но внутри все не так плохо. Написан на Django, с Bootstrap интерфейсом (привет, мобильность), поддерживает все необходимое, интегрируется с LDAP. Есть отдельная страница пароля, то есть можно дать на нее ссылку в Wiki, например. Не поддерживает дерева категорий, только теги, но к этому уже привык. Не обошлось без мелких правок, впрочем, ничего фундаментального, скорее, повышение удобства использования. Главный недостаток отсутствия категорий – паролей по тегу может выпасть очень много – 12-15 страниц по 20 паролей на каждой. Поэтому сейчас запланирована следующая волна оптимизации – регламентирование списка тегов, жесткое ограничение по их количеству, панелька навигации по тегам наверху. В остальном все у Rattic в порядке – история изменения пароля, логи просмотра и редактирования, расшаривание в пару кликов (встроенного не было, сделал так: завел в AD-группу для каждого пользователя, кому надо расшаривать пароли, и, в случае необходимости, даю этой группе право на просмотр пароля), просмотр списка паролей, которые видел любой из пользователей. Причем, если удалить пользователя, система любезно покажет список паролей, которые он видел и предложит сразу добавить их в очередь на изменение.

В итоге, время поиска паролей сократилось с 20 до 1-2 минут, что являлось большим шагом вперед.

Телефония

Когда основной костяк инструментария сформировался, захотелось большего. И первым шагом стала собственная система телефонии. В свое время услуги телефонии покупались у облачного провайдера, но потом решил переехать на собственное решение, что было экономнее и универсальнее. И не прогадал. Решил не ставить стандартный Asterisk, а попробовать его конкурента – Freeswitch. И это было вторым удачным решением. Не все получилось сразу, некоторые вещи, скажем, перенаправление на мобильные пришлось допиливать еще почти неделю, а все потому, что у Freeswitch свои особые взгляды на мультиканальность. Но когда все закончилось, про него просто забыли. Потому что он не падал, просто месяцами работал и работал. После недавнего обновления я впервые за 200 дней перезагрузил его сам.

Постепенно он обрастал всякими дополнительными сервисами, связью с CMDB, черным списком, приемом факсов с пересылкой на почту, баном неугодных со звонками в Сомали. Единственным его минусом оставалась настройка через конфиги, в системе просто так не разберешься. Поэтому было принято волевое решение установить FusionPBX, который сейчас, как мне кажется, является наиболее готовым для продакшена. В итоге, техподдержка получила настоящие очереди с уведомлением, на какой мы позиции (правда, за все время использования телефонной станции ни разу не возникала ситуации, когда некому ответить на звонок), менеджеры — нормальное прослушивание разговоров, эксперты — дополнительные возможности мониторинга и управления станцией. Например, сейчас можно посмотреть лог каждого звонка в CDR, чтобы понять, что пошло не так. В дальнейшем имеется желание превратить Freeswitch в защищенный коммуникационный сервер, держать там и текстовые конференции, и голосовые, и видео, отказаться ото всех дополнительных средств коммуникации, а также скрестить его с OpenXCAP сервером. Жду выхода 18-й версии.

CMDB

Самым молодым, но очень перспективным инструментом в нашей обойме является CMDB. Она выбиралась по следующим критериям: веб, легкая, расширяемая, функциональная, удобная. В итоге, остановил свой выбор на Itop. Сейчас он находится на стадии внедрения, в нем есть только телефонная книга, взаимодействующая с телефонией, но перспективы у него хорошие. Он объединит в себе и хранилище документации, и сервисдеск, и портал самообслуживания, и, собственно, данные об инфраструктуре клиентов, договорах и прочем. Плюс в нем есть поддержка ITIL и ITSM, что создает нам задел на развитие. В последних версиях кардинально улучшился портал самообслуживания, и, я надеюсь, что в следующей та же участь постигнет и основной интерфейс. Сейчас он пока используется как телефонная книга с поддержкой нечеткого поиска и в него активно внедряется автоматизированный сбор данных от FusionInventory Agent-а.

Удаленное управление

Техподдержка IT-инфраструктуры и пользователей немыслима без удаленного управления. От слова совсем. Не всегда можно объяснить пользователю, чего хочешь ты; не всегда и они могут рассказать, что происходит. Потому надо подключаться самому и смотреть. Средства удаленной поддержки сейчас есть на любой вкус и бюджет. Долгое время я использовал Teamviewer, который полностью отвечал моим требованиям, а также прост в управлении. Но за удобство надо платить. Трафик Teamviewer идет через сторонние сервера, алгоритмы хранения паролей и предоставления доступа закрыты, в интернете появлялись статьи о его взломе – никто не знает, что там происходит под капотом. Поэтому решил поменять средство удаленной поддержки и сейчас постепенно мигрирую на UltraVNC. Да, я прекрасно осведомлен о его недостатках и постарался максимально их скомпенсировать, не нарушая работу пользователей. К UltraVNC прикручен дополнительный плагин шифрования, причем вполне себе адекватного AES256/RSA2048, установлен и настроен UltraVNC Repeater для того, чтобы у клиентов не было проблем с подключением к системе удаленного управления. Разработана система генерации номеров на основе MAC-адресов сетевых карт, в систему ставится драйвер для более плавной работы. В дальнейших планах собственная сборка UltraVNC one Click, там надо долго думать над брендированием и правильной настройкой. В целом, инструмент вполне рабочий, у одного из клиентов успешно работает уже несколько месяцев без каких либо проблем. Конечно и без ложки дегтя не обошлось: если отключить плагин шифрования, UltraVNC не предупреждает об этом, а просто поднимает незащищенную сессию. Также его служба иногда страдает немотивированными падениями, что лечится настройкой сервиса на безусловный перезапуск. Также использование UltraVNC Repeater никак не защищает от дублей номеров, то есть UltraVNC с дублирующим номером запустится как ни в чем не бывало, а вот зарегистрироваться на репитере не сможет. Сейчас данная проблема решается регламентом создания номеров и помощью эксперта в случае необходимости. Подробнее об этой системе я уже писал здесь.

Терминал

Весь используемый инструментарий у меня работает в удаленном терминале. Это преследует сразу несколько целей. Самое главное – безопасность сессии, все защищенные данные хранятся в одном месте, на локальных компьютерах сотрудников нет ничего, компрометирующего меня или клиента. Я получаю достаточно простую схему управления и контроля периметра безопасности, доступ на удаленные рабочие столы и к системе паролей есть только с удаленного терминала. Рядом с терминалом размещен Active Directory, который является главным пультом управления доступами, с ним связаны все наши системы. Так как все бизнес-критические данные сосредоточены в одном месте, резервирование наших систем тоже не представляет из себя сложной задачи. Дополнительным преимуществом терминала является то, что твоя рабочая среда доступна тебе сразу и не зависит от места, где ты находишься, зашел на удаленный рабочий стол и вот все твои программы и документы открыты.

Система анализа рентабельности

Когда клиентов и заявок от них становится достаточно много возникает закономерный вопрос: а не работаю ли я зря, неэффективно или себе в убыток? Кто из клиентов отнимает максимум времени и приносит минимум дохода? Какого уровня задачи возникают у каждого клиента и сколько времени они отнимают у техподдержки? И, самое главное, сколько это все стоит? Ответом на все эти насущные вопросы стала система рентабельности клиентов, которая была создана на основе нашего сервисдеска. Но это забегая немного вперед. Первый вариант такой системы был вообще отдельной базой, в которую заносилось списанное время, тип работ и клиент. От нее отказались по причине громоздкости и неэффективности – ее заполнение отнимало время, а эффект был минимальным. После внедрения сервисдеска я написал обработки, которые раз в неделю делали выборки из базы сервисдеска и на их основе создавались представления для менеджмента. Неудобство этого варианта было в том, что приходилось отрывать сотрудника для подготовки этих отчетов. В итоге, был написан небольшой модуль к сервисдеску, в основу которого легли созданные запросы и менеджер теперь может самостоятельно подготовить отчет за любой интересующий его период. В этом отчете представлены часы, затраченные на каждого из клиентов, скоррелированные с соответствующей стоимостью часа каждого из сотрудников. Это позволяет практически в режиме реального времени видеть рентабельность работ по каждому из клиентов в любой интересующий отрезок времени, что позволило скорректировать наши усилия и затраты.

Итого

Каждый используемый инструмент оказался на своем месте и плотно взаимодействует со всеми остальными, а все вместе они помогают решать вопрос своевременного и качественного оказания помощи нашим клиентам.

P.S. Друзья, задавайте вопросы. Если какие-то системы и темы интересны, буду рад вашим комментариям. И подскажите, о чем мне стоит написать в следующий раз.