1 задание. Вадим Алджанов итархитектура от а до Я Теоретические основы. Первое
 Скачать 8 Mb.
|
|
ЭТАП СОПРОВОЖДЕНИЯ (Operation Stage) Введение Основной целью Эксплуатации услуг является координирование процессов и деятельностей, необходимых для предоставления услуг заказчикам на согласованных уровнях. Эксплуатация также ответственна за непрерывное управление технологиями, поддерживающими услуги. Цели и задачи: •Формирование процесса эксплуатации сервиса и его поддержка. •Организация ежедневных действия и операций по сопровождению сервиса •Организация процесса мониторинга и отчетности по производительности ИТ сервисов •Предоставление и сопровождение ИТ сервисов Данный этап определяется следующими процессами: •Управление событиями (Event Management) •Управление инцидентами (Incident Management) •Управление запросами (Request Fulfilment) •Управление проблемами (Problem Management) •Управление доступом (Access Management) Данный этап регламентируются следующими функциями: •Техническое управление (Technical Management) •Управление приложениями (Application Management) •Операционное управление (Operation Management) •Контроль ИТ операций (IT Operations Control) •Системы Обеспечения (Facility Management) Управление Событиями (Event Management EVM) Управление событиями (Event Management) – процесс, ответственный за управление событиями в течение жизненного цикла. Управление событиями одна из главных деятельностей операционного управления ИТ. Данный процесс отвечает на такие вопросы как: •Формирование процесса управления Событиями. Деятельность по процессу: Утверждение процесса управления Событиями Формирование процесса управления Событиями Классификация Событий Определение реакции на события Определение инструментов по мониторингу событий Информирование по событиям Определение события Фильтрация событий Определение значимости события Корреляция событий Формирование триггеров на события Реакция на события Обзор действий Закрытие событий Документирование Входы процесса: Процесс Управления Изменениями Политика Информационной Безопасности Процесс управления Изменениями Политика Информационной Безопасности Выходы процесса: Процесс Управления Изменениями Процесс управления инцидентами Политика Информационной Безопасности Процесс управления Изменениями Политика Информационной Безопасности Для того чтобы быть эффективным, операционное управление должно знать состояние инфраструктуры и ее компонентов, а также отслеживать любые отклонения от нормальной работы. Управление событиями реализовывается с помощью систем мониторинга и контроля, которые основаны на двух типах инструментов: инструменты активного мониторинга – опрашивают ключевые конфигурационные единицы с целью выяснения их статуса и доступности. Любое отклонение вызовет предупреждение, который перенаправляется необходимой команде или инструменту для принятия необходимых действий. Активный мониторинг (Active Monitoring) – мониторинг конфигурационных единиц или услуг, использующий автоматизированные регулярные проверки для отслеживания текущего статуса объекта мониторинга. инструменты пассивного мониторинга – обнаруживают и собирают события, без принятия каких-либо ответных действий. Пассивный мониторинг (Passive Monitoring) – мониторинг конфигурационной единицы, услуги или процесса, который основывается на предупреждениях или уведомлениях о текущем состоянии объекта мониторинга. Необходимо сразу отметить разницу между мониторингом и Управлением событиями. Эти процессы очень похожи, но, тем не менее, имеют отличия. Управление событиями сфокусировано на обнаружении значимых событий, касающихся статусов услуг и инфраструктуры. Мониторинг же следит за всеми событиями, и, по сути, имеет более широкий охват. Например, мониторинг может отслеживать состояние устройства, чтобы удостовериться, что оно функционирует в установленных рамках, даже если устройство не генерирует никаких событий. Таким образом, Управление событиями является частью системы мониторинга. Фактически, Управление событиями может контролировать любой аспект сервис-менеджмента. Объектами Управления событиями могут быть: конфигурационные единицы; условия среды (пожар или обнаружение дыма); мониторинг использования лицензий на программное обеспечение; безопасность; нормальная активность (например, использование приложений или производительность сервера). Ценность Управления событиями для бизнеса косвенная. Тем не менее, можно выделить следующие преимущества, которые дает Управление событиями бизнесу: Предоставляет механизмы для раннего обнаружения инцидентов. Во многих случаях Управление событиям позволяет обнаружить инцидент и принять соответствующие действия до того, как он значительно повлияет на услугу в целом. При интеграции с другими процессами сервис-менеджмента может повысить их эффективность. Он может сообщить об изменениях или отклонениях статусов, что позволит соответствующей команде своевременно предпринять необходимые действия. Раннее оповещение о необходимости обновления процедур или ресурсов; Управление событиями основано на автоматизированных операциях, что увеличивает эффективность и позволяет задействовать персонал на более «креативные» работы, в частности, проектирование новых услуг и поиск путей по улучшению существующих. Управление событиями работает со следующими типами событий: события, сигнализирующие о регулярной операции – , например, уведомления о том, что работы в соответствии с графиком выполнены; аутентификация пользователя для использования приложения; 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) срочность – Инцидент не требует немедленного вмешательства Порядок реагирования для каждой категории инцидентов: Время реакции на инцидент – максимальное время, в течении которого ИТ департамент обязуется среагировать на инцидент. Как правило это идентификация, классификация, назначение инцидента на группу поддержки с информированием сотрудника, контакт с пользователем и т п. Время разрешения инцидента – максимальное время, в течении которого ИТ департамент обязуется разрешить инцидент. Время закрытия инцидента – максимальное время ожидания реакции сотрудника, после которого инцидент будет закрыт. Определение источников поступления инцидентов: Контакт с пользователем Телефонный звонок Электронная почта Электронный портал Системы мониторинга Статусы инцидента: Активный В ожидании Разрешенный Отказанный Закрытый Классификация инцидентов по типам и подтипам (зависит от специфики организации, предпочтениям и т п): Проблемы с сервисом Х Проблемы с аппаратным обеспечением Проблемы с операционным обеспечением Проблемы с приложением Проблемы с конфигурацией Проблемы с доступом Проблемы с производительностью Прочие проблемы Проблемы конечных пользователей Проблемы с аппаратным обеспечением Проблемы с операционным обеспечением Проблемы с приложением Проблемы с конфигурацией Проблемы с доступом Проблемы с производительностью Прочие проблемы Прочие проблемы Определение групп разрешения инцидентов. Зависит от организационной структуры ИТ департамента, классификации инцидентов и т п: Оператор центра Поддержки Пользователей Первая линия поддержки Вторая линия поддержки Третья линия поддержки и поддержка производителя Определение категорий разрешения инцидента: Самостоятельное разрешение Отказан Разрешен Закрыт Определение метрик и показателей оценки эффективности и результативности процесса. Кроме элементов, выше указанных, необходимо также определить следующие элементы: порядок информирования пользователя, сотрудника ИТ и менеджера проекта или супервайзера на различных этапах жизни инцидента. Метрики соглашений Порядок эскалации инцидента Памятка оператору, для быстрой идентификации и классификации инцидента Критерии результативности – (KGI) Критерии эффективности – (KPI) Количество инцидентов Соотношение открытых инцидентов Тенденция инцидентов (рост, снижение) Количество инцидентов на устройство Количество инцидентов на пользователя Количество инцидентов, выполненных в срок Среднее время реакции Среднее время разрешения инцидента Процент инцидентов, выполненных удаленно Количество ошибочных инцидентов Среднее время устранения инцидента Количество повторных инцидентов Количество инцидентов решенных с помощью изменений Количество «важных» инцидентов Количество «срочных» инцидентов Количество инцидентов по операторам |