«инцидент менеджмент»: как карельские чиновники работают с жалобами граждан в соцсетях

Спрашивали — отвечаем

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

«Мэрия, а где детская площадка на Кукковке, которую в мае демонтировали под предлогом установки новой площадки?»

Ответ она получила в том же паблике – в течение суток – в комментарии на свой вопрос от группы «Администрация Петрозаводского городского округа»:

«Новое оборудование для детской площадки закуплено. Работы по его монтажу будут выполнены после его поступления».

К слову, новая детская площадка появится на пересечении улиц Сортавальской и Питкярантской уже в августе этого года.

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

Через несколько часов куратор системы разъяснил ему, что в обязанности регоператора не входит вывоз использованной авторезины, потому что она не относится к твердым коммунальным отходам – винить регионального оператора за свалку шин неправильно.

А уже 15 мая петрозаводское муниципальное предприятие «Автоспецтранс» бесплатно начало принимать  в утилизацию использованные шины у частных лиц. Контейнер для сбора резины установлен рядом со второй проходной «Автоспецтранса» на Вытегороском шоссе, 82. Приемник расположен в общедоступном месте: чтобы сдать авторезину, проезжать на территорию предприятия не нужно.

Третий пример. На сей раз про дороги. Комментарий об огромных лужах (в огромных ямах) на улице Кайманова появился вечером 15 апреля в паблике «Подслушано в Суоярви». Пользователи жаловались, что не могут ни подъехать, ни подойти к колодцу, который расположен на этой улице.

Уже на следующий день куратор системы инцидент-менеджмента ответил горожанину, что подрядчик воду откачает «завтра, затем данная дорога будет отсыпана и отгрейдирована».

Услуги по мониторингу и анализу СМИ

Компания «Медиалогия» предоставляет клиентам широкий перечень сервисов для решения ряда задач. Основные услуги:

1. Для PR – открывается доступ к онлайн-базе СМИ с возможностью самостоятельно мониторить сведения из средств массовой информации, анализировать заголовки и материалы СМИ, формировать отчеты в пару кликов.
2. Для SMM – автоматическая система мониторинга соцмедиа. Заказчик получает полные данные по всем существующим источникам, лимиты по объемам сообщений для проведения исследований отсутствуют. Можно проводить комплексный анализ целевой аудитории, сосредотачиваться на требуемых сегментах. Есть удобные инструменты визуализации, быстрой выгрузки отчетов. API открытый – «Медиалогия» дружественная для широкого перечня интеграций с системами CRM, сквозной аналитики.
3. Реагирование в соцмедиа – или инцидент, предполагает отработку негатива в социальных медиа, быстрое реагирование на важные упоминания, контроль качества коммуникаций, скорости передачи данных. Можно отбирать важные сообщения, классифицировать их, автоматизировать согласования по ответам, управлять коммуникациями, оценивать скорость реагирования.

Тариф зависит от конкретного пакета услуг.

Problem management vs. incident management

While there are a few differentiating factors when it comes to problem management vs. incident management, one key difference stands out. That is, problem management is the process of correcting the root cause of a project hazard, while incident management involves correcting a project interruption with a quick fix.

You can visualize this difference with a simple analogy. If incident management is the bandaid over a wound, then problem management is the ointment. Both are important in protecting the wound but have different purposes. 

While both systems are needed, they provide different outcomes and happen at different times in the project lifecycle. Incident management happens when an incident occurs, while problem management looks to solve the underlying issue after the fact to ensure it doesn’t happen again. 

What is incident management?

An incident is defined as a single event that causes disruption. In this case, a quick approach is needed in order to manage the incident before it becomes a problem. 

Here are some key differentiating characteristics of an incident:

• An incident is a single spontaneous event.

• An incident is an unplanned interruption.

• An incident is quickly solved in real time.

In short, an incident is a single event that is resolved quickly.

What is problem management?

A problem is defined as a cause of one or more incidents. An analysis will happen over time to resolve the underlying root cause.  

Here are some key differentiating characteristics of a problem:

• A problem is the result of multiple similar events.

• A problem halts business operations.

• A problem is solved by resolving the root cause over time.

In short, a problem is the result of multiple events and is solved over time. 

Read: Ask “5 Whys” to get to the root of any problem

Процедура управления

Как любая корпоративная процедура, организация управления инцидентами информационной безопасности должна пройти несколько этапов: от принятия решения о его необходимости до внедрения и аудита. На практике менеджмент большинства предприятий не осознает необходимости применения этой практики защиты информационного периметра, поэтому для возникновения инициативы о ее внедрении часто требуется аудит систем ИБ внешними консультантами, выработка ими рекомендаций, которые затем будут реализованы руководством предприятия. Таким образом, начальной точкой для реализации процедур управления инцидентами ИБ становится решение исполнительных органов или иногда более высоких звеньев системы управления компании, например, Совета директоров.

Общее решение обычно принимается в русле модернизации существующей системы ИБ. Система управления инцидентами является ее основной частью. На уровне принятия решения необходима его локализация в общей парадигме целей компании. Оптимально, если функционирование системы ИБ становится одной из бизнес-целей организации, а качество ее работы подкрепляется установлением ключевых показателей эффективности для ответственных сотрудников компании. После определения статуса функционирования системы необходимо перейти к разработке внутренней документации, опосредующей связанные с ней отношения в компании.

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

В структуре документа, оформляемого в виде положения или регламента, должны выделяться следующие подразделы:

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

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

Кто больше?

За прошлый год система зафиксировала более 9,5 тысяч «инцидентов» в Чувашии. Лидером среди сообщений стали жалобы на дороги, то есть их отсутствие, неудовлетворительное качество или содержание – это 2 281 «инцидент». На втором месте – благоустройство (уборка снега, мусор, ямы во дворах, парковки, состояние детских площадок) – 2 099 сообщений. На третьем – работа общественного транспорта – 1 904 сообщений.  Большинство жалоб в прошлом году касалось проводимой в Чебоксарах транспортной реформы. Еще один крупный блок проблем – жалобы на ЖКХ – 1 275 сообщений. Далее идут проблемы с образованием, вывозом мусора, экологией и здравоохранением. Но здесь жалоб оказалось в разы меньше, чем по первым четырем блокам вопросов.

Разработка ядра корреляции (обработчика событий)

4.1 Оценка производительности хранилища данных MongoDB

MongoBenchmark/Program.cs.NET driver for MongoDB

• Широко цитируемый источник по вопросу «замера» времени выполнения операций: обсуждение Environment.TickCount vs DateTime.Now на Stack Overflow.
• Попытка вставить в коллекцию два документа c одинаковыми _id закончится неприятностью в виде исключения MongoDB.Driver.MongoWriteException с примерным пояснением:

проекте OSSECtest_webapp_rules.xml

well-formed

4.3 Реализация ядра корреляции

1. Ядро корреляции «слушает» очередь сообщений AirSIEM_ConnectorQueue.
2. При поступлении очередного сообщения (события) ядро пытается применить к нему заранее загруженные правила обработки событий (правила корреляции).
3. В случае применимости одного из правил к поступившему событию безопасности ядро при необходимости формирует инцидент безопасности и сохраняет его в коллекции alerts хранилища данных MongoDB.

AirSIEMNLog

инструкциипример содержания

Жизненный цикл управления ИТ-инцидентами

Процесс управления инцидентами включает следующие этапы:

• Этап 1 : Регистрация инцидента.
• Этап 2 : Классификация инцидента.
• Этап 3 : Присвоение приоритета инциденту.
• Этап 4 : Назначение инцидента.
• Этап 5 : Создание задач и управление ими.
• Этап 6 : Управление SLA и эскалация.
• Этап 7 : Предоставление решения по инциденту.
• Этап 8 : Закрытие инцидента.

Жизненный цикл управления инцидентами

В зависимости от типа инцидента эти процессы могут быть простыми или сложными; помимо основного процесса, указанного выше, они также могут включать несколько рабочих процессов и задач.

Регистрация инцидента
Для регистрации инцидента можно использовать телефон, электронную почту, SMS, веб-формы, опубликованные на портале самообслуживания, а также живые чаты.

Классификация инцидента
В зависимости от того, какую область ИТ или бизнеса затрагивает инцидент, например, сеть, оборудование и т. д., инциденту можно присвоить категорию и соответствующую подкатегорию.

• Присвоение приоритета инциденту

  Приоритет инцидента можно определить с помощью матрицы приоритетов (степень влияния и срочность). Степень влияния на работу бизнеса означает степень ущерба, который проблема нанесет пользователю или организации. Срочность инцидента обозначает временные рамки, в которые инцидент должен быть устранен. Инциденту можно присвоить следующий приоритет:

  • Критический
  • Высокий
  • Средний
  • Низкий

Маршрутизация инцидентов и их оценка
После присвоения инциденту категории и приоритета он автоматически переадресуется соответствующему техническому специалисту, обладающему необходимыми знаниями и навыками.

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

Управление SLA и эскалация
При обработке инцидента техническому специалисту необходимо обеспечивать соблюдение требований SLA. SLA — это приемлемое время, в течение которого требуется предоставить ответ по инциденту (SLA в отношении ответа) или решение (SLA в отношении предоставления решения). SLA можно назначать инцидентам на основе таких параметров, как категория инцидента, автор заявки, влияние, срочность и т. д. В случае, когда требования SLA могут быть нарушены или уже нарушены, инцидент можно эскалировать для передачи другому специалисту или на другой уровень, чтобы обеспечить его оперативное устранение.

Предоставление решения по инциденту
Инцидент считается устраненным, когда технический специалист предоставил временное обходное решение или окончательное решение проблемы.

Закрытие инцидента
После устранения инцидента и получения от пользователя подтверждения того, что решение сработало и он удовлетворен результатом, инцидент можно закрыть.

Комментируйте больше

– Актуальность работы с гражданами с соцсетях достаточна высока. Многие уже не хотят обращаться к чиновникам по стандартной форме. Ведь в этом случае ждать ответа придется в течение 30 дней. Решение вопросов в режиме онлайн позволяет настроить прямой диалог между властью и гражданами. Жителям Карелии можно посоветовать одно – больше комментировать. Единственное, людям не стоит делать это анонимно, чтобы у власти была возможность им ответить, – считает Анна Шахник.

Анна Шахник. Фото: «Республика» / Любовь Козлова

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

В систему инцидент-менеджмента попадают лишь те жалобы, которые находятся в публичном пространстве. Если, например, написать сообщение в соцсети лично главе Карелии, то он его рассмотрит самостоятельно: система тут не работает.

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

Обзор основных проблем

Хорошая практика — проверять все основные проблемы. Но это требует затрат. Обзор должен изучить:

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

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

Исследование и диагностика проблемы

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

• Систему управления конфигурацией (CMS) необходимо использовать для определения уровня воздействия и определения точки отказа.
• База известных ошибок или KEDB должны быть доступны и проверены для того , чтобы выяснить , если проблема возникла в прошлом, если это разрешение должно быть уже на месте.
• При хронологическом анализе события, вызвавшие проблему, будут проверяться в хронологическом порядке, чтобы иметь временную шкалу событий. Цель состоит в том, чтобы увидеть, какое событие запускает следующее событие и так далее, или исключить некоторые возможные события.

Value Analysis Pain содержит более полное представление о влиянии инцидента или проблемах в бизнесе. Вместо анализа количества инцидентов / проблем определенного типа в конкретном временном интервале метод фокусируется на глубоком анализе того, какой уровень боли был причинен бизнесу этими инцидентами / проблемами. Формула для расчета уровня боли должна учитывать:

• количество пострадавших
• продолжительность простоя, вызванного
• стоимость для бизнеса

Метод Кепнера и Трего используется для исследования более глубоких проблем. Они определили следующие этапы:

• определение проблемы
• описание проблемы с точки зрения личности, местоположения, времени (продолжительности) и размера (воздействия)
• установление возможных причин
• проверка наиболее вероятной причины
• проверка истинной причины

Анализ Парето или диаграмма Парето — это метод отделения важных потенциальных причин от тривиальных проблем. Необходимо предпринять следующие шаги:

Сформируйте таблицу с указанием причин и их частоты в процентах

Расположите строки в порядке убывания важности причин (сначала самая важная причина)
Добавьте в таблицу столбец с накопительным процентом
Создайте гистограмму с причинами в порядке их процента от общего числа. Нарисуйте линию на 80% по оси Y, затем опустите линию в точке пересечения с осью X

На диаграмме вы можете увидеть основные причины сбоев в сети. Они должны быть нацелены в первую очередь.

What is incident management?

Incident management is the process of detecting, investigating, and responding to incidents while they happen in as little time as possible. While it’s not always a permanent solution, incident management is important in order to finish projects on time, or as close to the set deadline as possible. 

Incident management can be implemented within any team, though IT teams use it alongside release management and sometimes refer to it as IT infrastructure library (ITIL) incident management.

Project managers use incident management during projects in order to prevent hazards from derailing tasks. This is done with the help of a five-step process that ensures incidents get solved efficiently and correctly. 

Читать статью «Эффективность и результативность в бизнесе — почему вашей команде нужно и то, и другое»

There is often confusion between incident management and problem management. Let’s compare each and uncover the differences. 

Управление инцидентами и управление изменениями

Процесс управления изменениями ITIL — это процесс систематического изменения ИТ-инфраструктуры организации в соответствии со стандартами. Это четко спланированный процесс, состоящий из нескольких этапов и включающий различные состояния, в которых могут находится ИТ-изменения.

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

Рекомендации по организации успешного управления инцидентами ITIL

1. Предложите несколько моделей создания заявок, включая отправку по электронную почту, по телефону или через портал самообслуживания.
2. Опубликуйте настраиваемые формы для эффективного сбора информации об ИТ-инцидентах.
3. Настройте автоматическую классификацию и приоритизацию ИТ-инцидентов на основе критериев заявки.
4. Свяжите SLA с ИТ-инцидентами на основе таких параметров заявки, как ее приоритет.
5. Если все технические специалисты обладают одинаковым уровнем знаний и навыков, им можно автоматически назначать заявки на основе таких алгоритмов, как балансировка нагрузки и циклический перебор.
6. Свяжите данные ИТ-активов, ИТ-проблемы и ИТ-изменения с заявками об ИТ-инцидентах.
7. Убедитесь в том, что закрытие инцидентов выполняется только после предоставления надлежащего решения. Для этого получите подтверждение от конечного пользователя и применяйте соответствующие коды закрытия.
8. Настройте процесс коммуникации с конечным пользователем на каждом из этапов жизненного цикла управления ИТ-инцидентами.
9. Создайте базу знаний и постоянно пополняйте ее соответствующими решениями.
10. Обеспечьте конечным пользователям и техническим специалистам доступ на основе ролей в зависимости от сложности решений.
11. Создайте уникальные рабочие процессы для обработки серьезных инцидентов.

Устранение причин и последствий события, его расследование

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

На этапе расследования от должностных лиц организации требуется:

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

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

Как расследовать утечки информации с помощью DLP-системы? Читать. 

Сведения о ServiceDesk Plus

ServiceDesk Plus, флагманский продукт компании ManageEngine, представляет собой программное обеспечение для службы технической поддержки, которое используется профессионалами в области ITSM по всему миру и обеспечивает поддержку ITIL. Благодаря функции ITSM, сертифицированной по отраслевым стандартам, удобству использования и собственным мобильным приложениям ServiceDesk Plus использует передовые технологии, чтобы помочь ИТ-отделам организовать высококлассное обслуживание конечных пользователей при одновременном сокращении затрат и снижении сложности. Программное обеспечение, которое доступно как в облаке, так и локально, предлагается в трех версиях и на 29 языках. Свыше 100 000 организаций в 185 странах применяют ServiceDesk Plus для оптимизации своих служб ИТ-поддержки и использования передовых практик в области управления ИТ-обслуживанием. Подробные сведения о ServiceDesk Plus представлены на странице по адресу manageengine.com/ru/service-desk.

Практикум по разработке SIEM системы

• сбор и хранение поступающих событий безопасности;
• обработка и анализ зарегистрированных событий безопасности;
• обнаружение атак и нарушений политик безопасности в реальном времени (близком к реальному времени);
• выявление и разбор инцидентов безопасности;
• формирование отчетов.

• оценка защищенности ресурсов контролируемой системы;
• проверка соответствия системы управления ИБ существующим требованиям и нормам;
• управление рисками ИБ и др.

1. Организация тестового окружения.
     1.1. Установка и настройка веб-сервера Apache.
     1.2. Установка и настройка хранилища данных MongoDB.
     1.3. Установка и настройка брокера сообщений RabbitMQ.
     1.4. Установка и настройка среды разработки Visual Studio.
2. Разработка защищаемого веб-приложения Buggy Webapp.
3. Разработка коннектора для веб-сервера Apache.
4. Разработка ядра корреляции (обработчика событий).
     4.1. Оценка производительности хранилища данных MongoDB.
     4.2. Формирование набора правил корреляции.
     4.3. Реализация ядра корреляции.
5. Разработка консоли администратора безопасности.
6. Проверка работоспособности разработанной SIEM системы.

1. «Применение технологии управления информацией и событиями безопасности для защиты информации в критически важных инфраструктурах» – одна из первых статей (2012 год) коллектива исследователей лаборатории проблем компьютерной безопасности СПИИРАН (И. В. Котенко, И. Б. Саенко, О. В. Полубелова, А. А. Чечулин) с общими положениями по построению и функционированию SIEM систем. Полный список публикаций лаборатории.
2. «Security Information and Event Management (SIEM) Implementation» – замечательная книга Дэвида Миллера, Шон Харрис и др. Издание 2011 года, с отдельными устаревшими главами, но во многом по-прежнему актуальное. Системный взгляд на организацию SIEM систем, доступный английский язык, понятные примеры.
3. Magic Quadrant for Security Information and Event Management 2015. Тематические отчеты Gartner за 2016 и 2017 годы также будут полезны исследователям SIEM систем.

Выходит, что у нас появился аналог Большого Брата, который за всеми следит и может выявлять недовольных?

Вряд ли. Большой Брат из романа Оруэлла – аллегория тотальной слежки для выявления и преследования неугодных. У «Инцидента» более утилитарная задача – обнаружить проблему и помочь в её решении. Если пользователь просто ругает власть («Олигархи разворовали страну, как жить дальше?») или горюет о вселенской несправедливости, аполитичный робот просто не обратит на него внимания. А вот если в жалобе есть конкретика (в селе не вывозят мусор, в городе не ремонтируют дорогу, в поликлинике невозможно записаться на приём и так далее), вероятность рассмотрения такой жалобы (а значит, и решения проблемы) многократно вырастает. 

Получается, что новая система мониторинга соцсетей – это не Большой Брат из романа «1984», а скорее Маленький Брат из «Книги джунглей» (так герои Киплинга называли Маугли, который всем помогал). Специально для конспирологов разработчики системы поясняют: читать подзамочные публикации и мониторить закрытые аккаунты система не умеет. 

Разработка коннектора для веб-сервера Apache

детальным описанием форматаApacheConnector

1. На начальном этапе обращаемся к журналу доступа access.log и запоминаем размер файла.
2. Далее в бесконечном цикле с паузой между итерациями отслеживаем изменения размера файла. При увеличении размера читаем из файла последние добавленные строки и передаем в очередь сообщений RabbitMQ, запоминаем новый размер файла.
3. Файл access.log может быть перезаписан. Учитываем такой случай (уменьшение размера файла).

Джеффри РихтераСтива Макконнеллабиблиотеку .NET/C# RabbitMQ client library

github.com/fisher85/AirSIEM

1. Запуск приложения ApacheConnector. Коннектор начинает отслеживать изменения размера файла access.log.
2. В браузере несколько раз обновляем страницу веб-приложения Buggy Webapp, при этом в журнал доступа веб-сервера будут дописаны строки, соответствующие обращениям браузера к веб-серверу.
3. Приложение ApacheConnector обнаружит изменения размера файла и отправит последние строки в очередь брокера сообщений RabbitMQ.
4. Если все правильно настроено, в панели администрирования RabbitMQ (адрес для нашего случая – «http://192.168.137.1:15672/») мы обнаружим добавленную очередь AirSIEM_ConnectorQueue с ненулевой нагрузкой.

1. Первое, что стоит попробовать – отключить брандмауэр, антивирус, проксификатор и др. Если поможет – включить и правильно их настроить.
2. Если возникает ошибка несовпадения Erlang hash взаимодействующих компонентов, попробуйте оставить на рабочей станции одну единственную установленную версию Erlang.

1. Источники вдохновения: примеры из книги Джеффри Рихтера «Программирование на платформе .NET 4.5» (глава 27, «Асинхронные вычислительные операции») и проект Log Monitor.
2. Почему не используем FileSystemWatcher? В одном случае на миллион класс будет некорректно отслеживать изменения файла. Этот случай, по известному закону, наблюдался при проведении экспериментов.

Роли и области ответственности, участвующие в управлении ИТ-инцидентами

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

Конечный пользователь/пользователь/автор заявки
Это та заинтересованная сторона, которая обычно испытывает перебои в работе службы и создает заявку об инциденте для запуска процесса управления инцидентами.

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

Служба поддержки уровня 2
Технические специалисты этого уровня обладают глубокими знаниями в области управления инцидентами. Они обычно занимаются более сложными обращениями от конечных пользователей; от также получают заявки при эскалации проблем от специалистов уровня 1.

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

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

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

У каждой роли имеется своя уникальная область ответственности, как указано ниже.

• • Обращается в службу поддержки с заявкой об инциденте.
  • Отслеживает существующую заявку.
  • Четко сообщает все требуемые сведения техническим специалистам.
  • Подтверждает восстановление работы службы и выполнение заявки.
  • Принимает участие в контрольном опросе для предоставления обратной связи после выполнения заявки.

• • Регистрация всех входящих заявок об инцидентах со всеми применимыми параметрами, такими как категория, срочность и приоритет.
  • Назначение заявок техническим специалистам.
  • Анализ инцидента и предоставление решения для возобновления работы службы.
  • Эскалация неразрешенных инцидентов в службу поддержки уровня 2.
  • Сбор всей требуемой информации от авторов заявок и отправка им регулярных обновлений относительно статуса их заявки.
  • Точка обращения для авторов заявок и координация действий специалистов службы поддержки уровня 2 и авторов заявок, если это необходимо.
  • Проверка решения с конечным пользователем и сбор отзывов.

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

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

• Ответственный за процесс

  • Несет ответственность за весь процесс управления инцидентами.
  • Определение ключевых показателей эффективности (КПЭ) и их сопоставление с критическими факторами успеха (КФУ).
  • Проверка КПЭ и обеспечение их соответствия бизнес-целям и КФУ.
  • Разработка, документирование, обзор и улучшение процессов.
  • Обеспечение непрерывного совершенствования услуг: проверка и улучшение процедур, политик, ролей, технологии и других аспектов процесса управления инцидентами.
  • Отслеживание отраслевых рекомендаций и их применение в процессе управления инцидентами.

Похожие записи:

Дворец, где работает президент Объявляю вас оператором персональных данных Мясо из пробирки Возврат денег за купленный товар Внутренние и внешние источники привлечения персонала Нормативные требования к документальному оформлению договорных отношений