Файл: Вадим Алджанов итархитектура от а до Я Теоретические основы. Первое.pdf

Управление событиями работает со следующими типами событий: события, сигнализирующие о регулярной операции – , например, уведомления о том, что работы в соответствии с графиком выполнены; аутентификация пользователя для использования приложения;
E-mail достиг получателя; события, отмеченные как отклонения, например, попытка входа в приложение с использованием некорректного пароля; нестандартная ситуация в работе бизнес-процесса, которая может потребовать дальнейших действий; использование CPU выше установленной нормы; установка неизвестных приложений. события, отмеченные как нестандартные, но при этом не являющиеся отклонениями. При обнаружении подобных событий необходим более детальный мониторинг.
Разного рода события возникают постоянно, но при этом не все события нужно регистрировать и обнаруживать. Важно, чтобы люди, участвующие в проектировании,

разработке, развертывании и поддержке услуг, четко понимали, какие именно события необходимо отслеживать.
Конфигурационные единицы в большинстве случаев выдают предупреждения в случае выполнения определенных условий. Возможность формировать эти предупреждения должна быть спроектирована и встроена в конфигурационные единицы. Многие конфигурационные единицы генерируют предупреждения с использованием открытого стандарта SNMP.
В идеальном случае на этапе Проектирования формируется стандартный набор событий, которые необходимо отслеживать в отношении конкретных конфигурационных единиц.
В рамках этапа Внедрения этот набор тестируется и настраивается.
После того, как предупреждение сформировано, специальный агент в системе обнаруживает его, «читает» и анализирует значимость события. Следующий шаг – фильтрация событий.
На этом этапе выносится решение о том, будет ли данное событие проигнорировано или его необходимо передать менеджменту для осуществления необходимых ответных действий. Если событие игнорируется, оно просто записывается в журнал событий (лог). Никаких других действий не выполняется. Фильтрация является первым шагом к классификации событий. Этап фильтрации, по сути, является необязательным.
Каждая организация имеет свои критерии для оценки значимости события, но рекомендуется использовать как минимум три категории событий:
•Информационное событие
•Предупреждение
•Ошибка
Информационное событие – относится к событию, которое не требует никаких действий и не является отклонением. Такие события просто записываются в логи и используются для слежения за работой системы и ее компонентов, или контроля выполнения каких-то операций.
Они также могут использоваться для сбора статистики и дальнейших исследований. Примерами информационных событий могут быть вход пользователя в систему или успешное завершение транзакции.
Предупреждение – этот тип события формируется тогда, когда услуга или устройство приближается к пороговым значениям. Предупреждения предназначены для того, чтобы соответствующий сотрудник, процесс или инструмент проверили ситуацию более детально и приняли необходимые меры для предотвращения отклонения. Примерами предупреждений могут быть использование памяти сервера более 75% или увеличение количества коллизий в сети.
Ошибка – этот тип событий сигнализирует о том, что услуга или устройство функционируют неправильно (за пределами нормы). Это значит, что нарушаются SLA и OLA, что, как следствие, приводит к негативному влиянию на бизнес в целом. Примерами отклонений могут послужить выход из строя сервера, сегмент сети не отвечает на запросы и т п.
Если событие отмечено как значительное, необходимо определить точно его значимость и необходимые ответные действия – это этап корреляции. Корреляция обычно выполняется частью средства управления под названием «Correlation Engine», которая применяет к событию набор правил и критериев в определенном порядке. Основная идея в том, что событие может повлиять на бизнес, а правила помогут определить степень и тип этого влияния. В механизме корреляции событий прописывается способ реагирования на событие, например, что делаем при первом, втором и последующих проявлениях данного предупреждающего события, при сочетании или последовательности ряда событий – отклонений, одиночном, но имеющем очень серьезные для заказчика последствия, отклонении.
Примеры того, что может использовать Correlation Engine для оценки: количество похожих событий (например, большое количество попыток неправильного ввода пароля может свидетельствовать о попытке взлома устройства);

количество конфигурационных единиц, генерирующих похожие события; сопровождают ли событие какие-либо специфичные действия с данными или кодом; является ли событие отклонением; категория события; назначение приоритета событию и т. п.
Механизм, который инициирует ответные действия, называется триггером. Существует множество типов триггеров, каждый из которых спроектирован для инициализации конкретных действий. Например,
Триггеры инцидентов, которые формируют запись в Системе управления инцидентами и, соответственно, запускают процесс Управления инцидентами;
Триггеры изменений, которые формируют RFC и инициируют процесс Управления изменениями;
Скрипты, которые выполняют определенные действия, например, перезагрузку устройства;
Триггеры баз данных, которые ограничивают доступ пользователей к определенным областям базы или удаляют/создают записи в ней.
Следующий этап – выбор ответных действий. Существует множество вариантов ответных действий, которые при этом могут комбинироваться.
Ниже приведены примеры вариантов ответных действий:
Запись события в лог. Вне зависимости от того, какое ответное действие будет выбрано, хорошей практикой является формирование записи о событии в логе. Должна быть стандартная процедура для операционного персонала, предусматривающая периодический анализ логов, а также четкие инструкции о том, как использовать конкретный лог. Также необходимо помнить о том, что информация в логах может не иметь значения до возникновения инцидента. В рамках
Управления событиями нужно определить период хранения логов перед тем, как они будут заархивированы или удалены.
Автоматические ответные действия. Для регулярных и «понятных» событий можно разработать автоматические ответные действия. Триггер запустит их и затем проверит результат выполнения. Если что-то пошло не так, будет сформирована запись о проблеме или инциденте.
Примерами автоматических ответных действий могут быть: перезагрузка устройства; повторный запуск услуги; изменение параметра устройства; блокировка приложения для предотвращения несанкционированного доступа и т. п.
Предупреждение и вмешательство людей. Предупреждение служит для уведомления о событии людей, которые имеют необходимые навыки и знания для его разрешения. При этом события должны содержать как можно более полную информацию о событии, на основании которой человек сможет принять правильное решение.
Создание Запроса на изменение (RFC). В Управлении событиями есть две точки, где могут быть созданы RFC: при возникновении отклонения. Например, проверка компьютера показала, что на нем установлено три неавторизованных приложения. В этом случае необходимо сформировать RFC, который поможет процессу Управления изменениями устранить отклонение.

на этапе корреляции была определена необходимость изменения. В данном случае на этапе корреляции определяется, что наиболее подходящим ответным действием будет изменение чего-то.
Создание записи об инциденте. Если Correlation Engine определяет то, что определенный набор событий является инцидентом, создается запись об инциденте. Запись об инциденте должна быть максимально полной и отражать связи со всеми событиями, относящимися к инциденту.
Создание записи о Проблеме или формирование связи с уже имеющейся записью. Инциденты обычно связаны с определенными записями о проблемах. При возникновении инцидента важно связать его с соответствующей записью о проблеме, а если такой нет – создать ее.
Особые типы инцидентов. В некоторых случаях событие может являться отклонением, но при этом не влиять непосредственно на услуги. Такие инциденты не включаются в расчет времени простоя и относятся скорее с проблем операционного характера. Информация о них должна быть записана в соответствующий лог и передана персоналу, который разбирается с инцидентами этого типа.
Каждый день может происходить десятки и сотни событий и зачастую невозможно детально рассматривать каждое событие. Обзорные действия предназначены для проверки того, как были отработаны инциденты, не пропущены ли какие-то события, сбора статистических данных и т. п. При этом обзорные действия не должны повторять то, что было сделано до этого.
Основными сложностями и рисками для Управления событиями являются недостаточное финансирование, выбор оптимального уровня фильтрации событий и упущение момента для своевременного развертывания агентов в рамках инфраструктуры.
Для того чтобы Управление событиями было эффективным, его механизмы должны быть разработаны на этапе Проектирования услуг в рамках процессов Управления доступностью и Управления мощностями. Но при этом Управление событиями не является статичным – в ходе эксплуатации услуг могут появляться новые требования и события, которые необходимо отслеживать. Проектирование Управления событиями должно включать следующее:
Инструментарий – что может быть отслежено в отношении конфигурационных единиц и как можно воздействовать на них. Другими словами, это точное определение и проектирование того, как контролировать и мониторить инфраструктуру и услуги. В рамках определения инструментария необходимо ответить на следующие вопросы: что необходимо мониторить? какой тип мониторинга необходим? когда необходимо формировать событие? какая информация должна содержаться в событии? для кого предназначены сообщения о событиях?
Сообщения об ошибках должны отображать критичные ошибки, свидетельствующие о сбое или вероятности его возникновения.
Механизмы обнаружения событий и формирования предупреждений. Проектирование этих механизмов требует: знания взаимосвязей всех бизнес-процессов, которые контролируются с помощью
Управления событиями; знания SLA для каждой услуги, поддерживаемой конфигурационной единицей; знания того, кто поддерживает конфигурационную единицу; знания того, какие значения параметров конфигурационной единицы являются нормальными, а какие нет; понимание того, что именно нужно знать для эффективного управления конфигурационной единицей; знания информации, которая может помочь эффективной поддержке конфигурационной единицы; осознания важности совокупности одинаковых или похожих событий; понимание взаимосвязей конфигурационных единиц;

доступности информации об известных ошибках, полученной от поставщика или из предыдущего опыта.
Определение пороговых значений для каждой конфигурационной единицы. При этом значения могут изменяться в зависимости от многих обстоятельств. Например, максимальное количество пользователей, получающих доступ к серверу, зависит от того, какие именно работы они на нем выполняют.
Показатели процесса и метрики, которые можно использовать для измерения эффективности
Управления событиями: количество событий по категориям; количество событий по значимости; количество событий, которые потребовали участия персонала; количество инцидентов, вызванных известными ошибками и проблемами; количество одинаковых инцидентов (или повторяющихся); количество инцидентов, связанных с проблемами производительности; количество инцидентов, свидетельствующих о наличии потенциальных проблем с доступностью и т. п.
Критерии результативности – (KGI)
Критерии эффективности – (KPI)
Количество событий
Количество событий по сервисам
Количество зарегистрированных событий
События, связанные с инцидентами
События, связанные с проблемами
Управление Инцидентами (Incident Management INM)
Процесс Управления Инцидентами является частью этапа «Сопровождения».
Управление инцидентами (Incident Management) – процесс, отвечающий за управление жизненным циклом всех инцидентов. Основная цель Управления инцидентами – скорейшее восстановление услуги для пользователей.
Данный процесс отвечает на такие вопросы как:
Формирование процесса управления Инцидентами.
Деятельность по процессу:
Утверждение процесса управления Инцидентами
Формирование процесса управления Инцидентами
Классификация Инцидентов
Определение реакции на Инциденты
Идентификация инцидента
Регистрация инцидента
Классификация и категоризация инцидента
Определение приоритетов
Первичная диагностика
Эскалация инцидента
Расследование и диагностика
Разрешение инцидента
Обзор значимых инцидентов

Реактивация инцидента
Закрытие инцидента
Документирование
Контроль процесса
Отчетность по процессу
Входы процесса:
Процесс Управления Изменениями
Процесс Управления Событиями
Политика Информационной Безопасности
Регистрация заявки
CMDB
Коммуникация с сотрудниками
Выходы процесса:
Утверждение политик и процедур
Регистрация проблем
Регистрация запросов
Регистрация запросов на изменения
Регистрация запросов на доступ
Формирование знаний
Участники процесса:
ИТ комитет, бизнес руководители
Сотрудники ИТ департамента
Представители Департамента Безопасности
Менеджер процесса
Ключевые моменты процесса:
ИТ департамент является владельцем процесса
Процесс Управления Инцидентами вводит такие понятия как:
Степень Воздействия (Impact / Severity) – определяет границы воздействия инцидента.
Срочность (Urgency) – определяет время решения инцидента.
Приоритет (Priority) – комбинация степени воздействия и срочности инцидента. При эскалации инцидента приоритет сохраняется. В зависимости от Соглашения об Уровне Сервиса
(SLA) определяет сроки и порядок реагирования на инцидент.
Эскалация (Escalation) – перенос инцидента на другой уровень. Различают:
Функциональная / горизонтальная – привлечение большего количества сотрудников данного уровня
Иерархическая / вертикальная – переход на верхний уровень поддержка
Запросы на обслуживание
Основные рекомендации для сотрудника подразделения Поддержки Пользователя при работе с пользователем:
Надо дать возможность пользователю объяснить проблему и высказать свою точку зрения
В процессе общения с клиентом концентрируйте внимание на том, чем вы можете помочь клиенту.
Попросите пользователя продемонстрировать проблему.
В конце разговора резюмируйте коротко все то, что было сказано пользователем, чтобы быть уверенным что поняли правильно.
Не спрашивайте вопросы так, чтобы он повторял только что сказанное. Это может создать у него впечатление, что его не слушают.

Не обвиняйте и не критикуйте клиента.
Старайтесь не использовать выражения «… я не знаю… вы должны…»
При организации процесса управления инцидентами необходимо ввести следующие важные элементы процесса:
Полная матрица категоризации приоритета инцидента, если имеется необходимое программное обеспечение:
Или упрощенная категоризация определения инцидента:
Инциденты Первой категории – Важные и Срочные
Инциденты Второй категории – Важные и Не Срочные
Инциденты Третей категории – Не Важные и Срочные
Инциденты Четвертой категории – Не Важные и Не Срочные
Определить, по возможности категоризацию воздействия с указанием метрик:
Высокое (High) воздействие – Инцидент воздействует на всех пользователей, или Инцидент приводит к деградации сервиса более чем на 50% или полному отказу, или Инцидент затрагивает критические компоненты сервиса
Среднее (Medium) воздействие – Инцидент воздействует на (значительную или нет) группу пользователей, или Инцидент приводит к ощутимой деградации сервиса в пределах 20—50%, но в пределах SLA, или Инцидент затрагивает критические, но зарезервированные компоненты сервиса
Низкое (Low) воздействие – Инцидент воздействует на одного пользователей, или Инцидент приводит к незначительной, не более чем на 20%, деградации сервиса, или Инцидент затрагивает не критические или второстепенные компоненты сервиса
Определить категоризацию срочности с указанием метрик:
Высокая (High) срочность – Инцидент требует немедленного вмешательства
Средняя (Medium) срочность – Инцидент требует вмешательства, но время разрешения в пределах SLA
Низкая (Low) срочность – Инцидент не требует немедленного вмешательства
Порядок реагирования для каждой категории инцидентов:
Время реакции на инцидент – максимальное время, в течении которого ИТ департамент обязуется среагировать на инцидент. Как правило это идентификация, классификация, назначение инцидента на группу поддержки с информированием сотрудника, контакт с пользователем и т п.
Время разрешения инцидента – максимальное время, в течении которого ИТ департамент обязуется разрешить инцидент.

Время закрытия инцидента – максимальное время ожидания реакции сотрудника, после которого инцидент будет закрыт.
Определение источников поступления инцидентов:
Контакт с пользователем
Телефонный звонок
Электронная почта
Электронный портал
Системы мониторинга
Статусы инцидента:
Активный
В ожидании
Разрешенный
Отказанный
Закрытый
Классификация инцидентов по типам и подтипам (зависит от специфики организации, предпочтениям и т п):
Проблемы с сервисом Х
Проблемы с аппаратным обеспечением
Проблемы с операционным обеспечением
Проблемы с приложением
Проблемы с конфигурацией
Проблемы с доступом
Проблемы с производительностью
Прочие проблемы
Проблемы конечных пользователей
Проблемы с аппаратным обеспечением
Проблемы с операционным обеспечением
Проблемы с приложением
Проблемы с конфигурацией
Проблемы с доступом
Проблемы с производительностью
Прочие проблемы
Прочие проблемы
Определение групп разрешения инцидентов. Зависит от организационной структуры ИТ департамента, классификации инцидентов и т п:
Оператор центра Поддержки Пользователей
Первая линия поддержки
Вторая линия поддержки
Третья линия поддержки и поддержка производителя
Определение категорий разрешения инцидента: