Updated document.txt

weirded authored
revision e7ab3dab5343fa3a8a44ff6789e0b2732640f171
document
# Приветствие
Добрый день, уважаемые члены комиссии!

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

# Структура предметной области

Итак, компания Carbon Soft занимается разработкой программного обеспечения для интернет-провайдеров и его распространением. Модель монетизации - ежемесячная подписка, включающая в себя доступ к обновлениям ПО и техническую поддержку, есть несколько уровней подписки, включающие в себя различные опции (доступ к телефону круглосуточной технической поддержке, приоритет в реализации пожеланий, помощь в настройке оборудования и так далее).

В компании имеются отделы маркетинга, продаж, технической поддержки и разработки. С разработанной системой работают в основном отдел технической поддержки и команда разработки проекта Carbon Reductor.

Техническая поддержка ведётся в основном с помощью системы хелпдеска, интегрированной с используемой в компании CRM. В ней обоими сторонами (клиенты/сотрудники Carbon Soft) могут создаваться заявки. В нерабочее время для части клиентов доступен телефон круглосуточной техподдержки с дежурным инженером, который может при необходимости связаться и попросить помощь у разработчиков продуктов.

Carbon Reductor - это система фильтрации трафиков для интернет-провайдеров, требующая крайне стабильной работы. Неполадки в её работе могут привести к штрафам от Роскомнадзора, для использующих её интернет-провайдеров, а получение таких штрафов безусловно скажется на их лояльности к Carbon Soft, что крайне нежелательно и чревато убытками.

Когда клиенты стали получать первые штрафы, а часть из них отказалась от продукта (и перестала платить деньги) было решено - Carbon Soft должен сделать всё, чтобы:

1. возникало гораздо меньше проблем
2. поскольку избавиться от всех проблем невозможно, возникающие проблемы должны устраняться сразу после обнаружения

Тогда и было решено реализовать данную систему мониторинга.

# Функциональная модель.

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

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

# Состав и структура ПО.

Сейчас система мониторинга состоит из четырёх модулей.
- **Система сбора данных** отсеивает поступающие данные от незарегистрированных серверов и сохраняет/обновляет данные от зарегистрированных.
- **Модуль анализа данных** проверяет время поступления данных и при устаревании более чем на два часа помечает наблюдаемый сервер как неисправный.
- **Модуль отправки уведомлений** раз в час для всего списка неисправных серверов, работа которых важна для Carbon Soft создаёт заявки в хелпдеске, обращаясь к специально доработанному для этого модулю CRM.
- **Веб-интерфейс** - позволяет просмотреть подробные данные по конкретному серверу, а также различные отчёты - список неисправных серверов, используемых в настоящее время версий продукта, а также различную статистику связанную с прибылью и вероятными потерями при отказе пользователей с неисправными серверами от продукта. Также содержит API, предоставляющее различные цифровые метрики, используемое системой аналитики.

# Интерфейс и формы

Интерфейсу было уделено довольно много внимания. Известно, что лучший интерфейс - который не замечаешь. Сотрудникам технической поддержки довольно редко приходится заходить в веб-интерфейс системы мониторинга, поскольку она работает "незаметно" для них - автоматически создаёт заявки от имени владельцев неисправного сервера в CRM, автоматически выбирает ответственного за заявку, сама добавляет первый комментарий с ссылкой на документацию, где описано как решать все найденные проблемы. Более того, система диагностики, ещё до отправки данных в систему мониторинга, предпринимает попытку автоматически исправить найденную проблему. Бывают ситуации, когда клиенты решают и закрывают заявку ещё до реакции технической поддержки (обычно в выходные или ночью).

Но иногда сотрудники всё же заходят в веб-интерфейс системы мониторинга, чтобы получить актуальные и более подробные данные о состоянии сервера - модели сетевых карт, нагрузку и её распределение на ядра процессора, время последней отправки диагностической информации. Состояние любого сервера можно узнать практически моментально по цвету тайла (квадратика) - зелёный - исправен, ярко-красный - неисправен. Найти сервер можно, воспользовавшись встроенным поиском браузера по регистрационному номеру сервера или названию компании (у большинства компаний один сервер фильтрации), эту информацию сотрудник техподдержки обычно видит в назначенной на него заявке, которой он сейчас занимается.

# Отчёты

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

# Создаваемая заявка в Helpdesk

Как уже говорилось - основная задача системы мониторинга - создавать заявки о неисправностях в хелпдеске. Задачу уведомления пользователя о заявке берёт на себя хелпдеск. Клиенту отправляется сообщение на почту и в смс, в случае длительного отсутствия реакции ему пытается дозвониться сотрудник технической поддержки, если ему не отдаётся - клиент передаётся отделу продаж, который пытается связаться с директором компании-клиента, чтобы тот предоставил контакты сотрудника, ответственного за сервер.

Модуль автоматического создания заявок на стороне CRM проверяет наличие уже открытой автоматически созданной заявки, если таковая имеется - в неё добавляется комментарий (после аналогичной проверки его наличия). Созданная заявка выглядит для сотрудника технической поддержки следующим образом.

# Заключение

В заключение можно сказать, что разработка и внедрение данной системы не прошли зря - за последние полгода от продукта отказался только один клиент, и то проблема была в том, что ему не получилось помочь с проблемой с оборудованием. В первое время число серверов с неисправностями у платящих клиентов составляло около 50, в текущее - не более 10. Также система очень сильно ускорила решение глобальной проблемы, которая затронула около 60% клиентов, сервера которых стали перезагружаться после обновления на новую версию. Также благодаря системе мониторинга и улучшению документации удалось снять обязанности по технической поддержке разработчиков Carbon Reductor, то есть с меня., чему я очень рад