Подтверждение, тестирование и оценка услуг на этапе внедрения. Управление знаниями

Подтверждение, тестирование и оценка услуг на этапе Внедрения. Управление знаниями Подтверждение и тестирование услуг Подтверждение(Validation) - деятельность, которая гарантирует, что новая или измененная услуга, процесс, план или другой результат отвечает нуждам бизнеса. Подтверждение гарантирует, что требования бизнеса удовлетворены, даже если они могли измениться по отношению к исходному результату проектирования. Подтверждение и тестирование услуг (Service Validation and Testing) - процесс, ответственный за подтверждение и тестирование новой или измененной услуги. Подтверждение и тестирование услуг удостоверяется, что услуга соответствует ее спецификации проектирования и будет отвечать потребностям бизнеса. Если не протестировать услуги корректно, при их передаче в промышленную эксплуатацию вырастет количество: • инцидентов, связанных со сбоями элементов услуг и несовпадениями между прогнозами и практикой; • количество звонков и обращений в сервис-деск, вызванных тем, что услуги не функционируют должным образом; • проблем и ошибок, которые труднее диагностировать в процессе эксплуатации; • издержек, так как ошибки сложнее и дороже исправлять в процессе эксплуатации, чем в процессе тестирования; • услуг, которые не могут использоваться эффективно пользователями и предоставлять им желаемую ценность. Основные цели процесса Подтверждения и тестирования услуг: • планирование и последующая реализация процессов тестирования и подтверждения, которые представят объективные доказательства того, что услуги предоставляют заявленную ценность заказчикам, пользователям и инвесторам; • оценка качества релиза и его компонентов; • идентификация, оценка и улаживание проблем, ошибок и рисков в процессе Внедрения. Таким образом, Подтверждение и тестирование услуг позволяет удостовериться, что услуга сможет предоставлять ценность заказчикам и их бизнесу. Услуга определяется пакетом услуг, который может состоять из нескольких пакетов уровней услуг (SLP) и компонентов, которые в свою очередь также могут быть услугами, например, поддерживающими. SLP определяет уровень полезности и качества, которые должны предоставлять услуги, и является основным входом процесса Подтверждения и тестирования услуг. Дизайн (проект) услуги зависит от того, где и как она будет использоваться. Атрибуты услуги характеризуют ее форму и функциональность в контексте перспективы использования. Таким образом, SLP определяет совокупность требований к услугам, а также набор ограничений для их использования. Процесс Подтверждения и тестирования услуг должен определить возможности устранения ограничений, определенных на этапе Проектирования, и проверить их корректность. Прежде чем начинать тестирование, необходимо сформировать стратегию тестирования. Стратегия тестирования определяет подход к организации тестирования и обработке его результатов. Она может применяться ко всей организации, набору услуг или отдельной услуге. Каждая стратегия должна согласовываться с инвесторами, так как они выделяют деньги на ее реализацию. Содержание стратегии тестирования: • цели и задачи тестирования; • контекст; • стандарты, требования законов и регуляторов; • контракты и соглашения; • охват и организация: ▪ команды поставщика услуг; ▪ организация тестирования; ▪ третьи стороны, стратегические партнеры, поставщики; ▪ бизнес-единицы и их месторасположение; ▪ пользователи и заказчики. • процесс тестирования: ▪ управление и контроль тестированием - запись, мониторинг прогресса, ведение отчетности; ▪ планирование и оценка тестирования; ▪ действия в рамках тестирования - планирование, реализация и документирование тестов и их результатов. • метрики тестирования и улучшения • идентификация объектов тестирования: ▪ пакет услуг; ▪ пакет уровня услуг; ▪ модель услуг, отображающая структуру и динамику развития услуг; • план эксплуатации услуг; • планы сервис-менеджмента: ▪ критические элементы, на которых необходимо сконцентрировать тестирование; ▪ месторасположение бизнес-единиц, на которых будет осуществляться тестирование. • интерфейсы поставщика услуг; • подход: ▪ выбранная модель тестирования; ▪ уровни тестирования; ▪ подходы к тестированию; ▪ степень независимости реализации, оценки и анализа тестирования; ▪ повторное использование - опыт, практика, знания и результаты тестирований в прошлом; ▪ распределение по времени; ▪ разработка и повторное использование проектов, инструментов, сценариев и данных для тестирования; ▪ контроль изменений и исправление ошибок; ▪ система измерения. • критерии: ▪ приема/отклонения; ▪ входа и выхода для каждой стадии тестирования; ▪ остановки или повторного запуска тестирования. • требования к людям: ▪ роли и ответственности; ▪ составление расписания тренингов для персонала; ▪ требования к степени вовлеченности заинтересованных лиц - поставщиков услуг, поставщиков, заказчиков, пользователей. • требования к среде: ▪ среды тестирования, которые будут использованы, их расположение, организация и техническое оснащение; ▪ требования к каждой среде тестирования; ▪ планирование и ввод в эксплуатацию сред тестирования. • результаты: ▪ обязательная и опциональная документация; ▪ планы тестирования; ▪ спецификации тестирования - процедуры, проект, обоснование тестирования; ▪ результаты тестирования и отчеты; ▪ проверка отчетов; ▪ суммарные отчеты по тестированию. Модель тестирования включает в себя план тестирования, то, что должно быть протестировано и сценарий тестирования каждого элемента. Сценарии тестирования определяют условия тестирования, цикл тестирования и результаты, которые должны быть получены. Таблица 10.1 . - Примеры моделей тестирования Модель тестирования Результат/цель тестирования Условия, на которых основано тестирование Тестирование контрактов Заказчик может использовать услугу с целью получения ценности Требования контрактов Модель тестирования требований к услугам Поставщик услуг может предоставлять услугу с характеристиками, которые требует заказчик Требования к услугам и Критерии приемки услуг Модель тестирования уровня услуг Поставщик услуг предоставляет услугу с заданным уровнем услуг, то есть тестирование времени ответа и исправления ошибок, доступности, вспомогательных услуг Требования уровня услуг, SLA, OLA Модель тестирования услуги Поставщик услуг способен предоставлять, сопровождать и управлять новой или измененной услугой с использованием модели услуг, включающей в себя модель ресурсов, модель затрат, модель прогресса, модель мощностей и производительности и т.п. Модель услуг Модель тестирования инсталляции Команда развертывания, инструменты и процедуры могут инсталлировать пакет релизов в целевую среду в заданных временных рамках Проект и план релизов и развертывания Модель тестирования верификации развертывания Развертывание завершено успешно, все услуги и конфигурации "на своих местах" и соответствуют критериям качества Тесты и проверки текущего состояния активов и конфигураций Существует множество подходов к тестированию. Они могут комбинироваться или использоваться по отдельности в зависимости от того, что конкретно тестируется. Например: • обзор документации; • моделирование и измерение - подходит для тестирования модели услуг и плана эксплуатации; • подход, основанный на рисках - концентрируется на областях повышенного риска, например, критичных для бизнеса услугах; • подход, основанный на проверке соответствия стандартам; • подход, основанный на опыте - использование экспертов в конкретной области для руководства тестированием; • симуляция; • тестирование по сценариям; • разыгрывание ролей; • макетирование; • тестирование в лабораторных условиях; • регрессивное тестирование; • пилотирование в отдельном помещении; • пилотирование в среде промышленной эксплуатации. Чтобы оптимизировать использование ресурсов в рамках тестирования, необходимо расставить приоритеты тестирования в зависимости от значимости услуги для бизнеса, влияния услуги и рисков, ассоциированных с ней. Существуют разные типы тестирования. Рассмотрим некоторые из них: • тестирование структуры услуги и требований к ней. Проверка атрибутов услуг в контексте контрактов, компонентов услуг и поддерживающих ее активов на совместимость; • тестирование гарантии. Как уже говорилось в предыдущих лекциях, пользователи видят и измеряют ценность услуги в двух составляющих - гарантии и полезности. При этом для каждой услуги определяются четкие показатели гарантии. Эта четкость позволяет провести тестирование гарантии или того, что услуга подходит для использования. В рамках тестирования гарантии могут проводиться: ◦ тестирование доступности; ◦ тестирование мощности; ◦ тестирование непрерывности; ◦ тестирование безопасности. • тестирование простоты использования услуги используется, как правило, для организации работы потенциальных пользователей услуги с ограниченными возможностями, например, глухонемых или дальтоников; • тестирование соответствия контрактам и требованиям регуляторов. Тестирование проверяет, что все критерии контрактов и требования регуляторов выполнены и удовлетворены; • тестирование Управления услугами - тестирование процессов в рамках Управления услугами; • операционное тестирование - включает в себя множество тестов, зависящих от типа услуги. Типичные тесты включают: ◦ нагрузочные тесты и стресс-тесты - проверяют способность услуги работать на требуемом уровне на доступных мощностях. В качестве мощностей может рассматриваться полоса пропускания сети, ресурсы сервис-деска, доступные лицензии, мощность процессора, доступная память и т.п.; ◦ тестирование безопасности - все услуги должны быть рассмотрены со стороны их влияния на аспекты безопасности организации; ◦ тестирование восстанавливаемости - тестирование плана восстановления, который должен быть разработан для каждой услуги. • регрессивное тестирование - такое тестирование повторяет успешные тесты и сравнивает вновь полученные значения с предыдущими. Оно позволяет протестировать услуги и их компоненты, которые раньше работали без сбоев и ошибок. Основные деятельности в рамках тестирования схематически показаны на рис. 10.1. Рис. 10.1.  Деятельности в рамках тестирования Не все деятельности в рамках тестирования выполняются последовательно, многие могут выполняться параллельно. 1. Управление тестированием. Управление тестированием включает в себя следующие действия: ◦ планирование ресурсов для тестирования; ◦ распределение что и когда должно тестироваться; ◦ управление инцидентами, ошибками, проблемами, рисками; ◦ проверка того, что известные ошибки и документация обработаны; ◦ отслеживание прогресса и сбор данных от обратной связи с различными этапами тестирования; ◦ осуществление незначительных изменений для уменьшения ошибок в промышленной эксплуатации; ◦ фиксация базового состояния конфигураций; ◦ тестирование набора метрик, анализ, ведение отчетности и управление. Метрики тестирования используются для оценки деятельностей в рамках тестирования. Они позволяют персоналу, ответственному за тестирование, контролировать прогресс и успешность тестирования. 2. Планирование и проектирование тестирования Планирование и проектирование тестирования рассматривает следующие вопросы: ◦ обеспечение ресурсами; ◦ программное, аппаратное обеспечение, персонал и другие мощности; ◦ необходимые ресурсы со стороны бизнеса/заказчиков; ◦ поддерживающие услуги; ◦ определение дат контрольных точек; ◦ согласованное время предоставления результатов тестирования; ◦ точка и время приемки; ◦ финансовые требования. 3. Проверка плана и проекта тестирования контролирует то, что: ◦ модель тестирования предоставляет адекватные и подходящие тесты, покрывающие все риски, связанные с услугой; ◦ модель тестирования покрывает все ключевые аспекты интеграции и интерфейсов; ◦ сценарии тестирования точные и завершенные. 4. Подготовка среды тестирования, в том числе фиксирование базового состояния для начала тестирования. 5. Осуществление тестирования - проведение тестов с использованием ручных или автоматизированных процедур. Если тестирование провалилось, причины должны быть документированы. Тестирование должно проводиться в соответствии с принятыми планами и стратегиями тестирования. 6. Достижение критериев выхода и формирование отчета Результаты тестирования должны быть сравнены с прогнозируемыми. Они могут быть интерпретированы в терминах "прием/отклонение" тестирования; рисков для бизнеса или поставщика; изменении спроектированной ценности, вызванное увеличением издержек или уменьшением выгоды от использования услуги. По результатам тестирования формируется итоговый отчет. 7. завершение тестирования. Входами процесса Подтверждения и тестирования услуг являются: • пакет услуг; • Пакет уровня услуг (SLP); • интерфейсы поставщика услуг; • проектная документация (SDP); • планы релизов и развертывания; • критерии приемки; • Запросы на изменения. Основными выходами процесса Подтверждения и тестирования услуг являются: • формирование базового состояния конфигураций для проведения тестирования; • осуществляемые тесты; • результаты этих тестов; • анализ результатов - сравнение реальных и прогнозируемых данных, анализ выявленных в ходе тестирования рисков. Ключевые показатели производительности процесса Подтверждения и тестирования услуг: 1. первостепенные показатели отражают ценность для бизнеса и заказчиков: ◦ раннее подтверждение того, что услуга сможет предоставлять предсказанную ценность; ◦ уменьшение негативного влияния ошибок и инцидентов в промышленной эксплуатации; ◦ более эффективное использование ресурсов; ◦ уменьшение задержек в тестировании, которые влияют негативно на бизнес; ◦ улучшение понимания новой или измененной услуги; ◦ четкое понимание ролей и ответственностей, относящихся к новой или измененной услуге; ◦ затраты и ресурсы, необходимые от пользователей и заказчиков. 2. второстепенные показатели - внутренние по отношению к поставщику услуг. Эти показатели отражают эффективность и результативность тестирования: ◦ объем работ и стоимость настройки среды тестирования; ◦ объем работ для нахождения дефектов; ◦ уменьшение повторяющихся ошибок - достигается за счет обратной связи тестирования с проектированием и внедрением. Благодаря анализу результатов тестирования ошибки исключаются из будущих релизов; ◦ уменьшение количества ошибок/дефектов на поздних стадиях тестирования и в процессе производства; ◦ повторное использование данных тестирований; ◦ количество ошибок на каждой стадии жизненного цикла; ◦ количество и процентное соотношение ошибок, которые были обнаружены в ходе тестирования; ◦ инциденты, найденные в ходе тестирования, как процент от общего количества инцидентов, произошедших в ходе эксплуатации; ◦ количество известных ошибок, задокументированных на ранних стадиях тестирования. 10.2. Оценка Оценка (Evaluation) - процесс, ответственный за проведение оценки новой или изменяемой услуги для обеспечения управления рисками и помощи в принятии решения о продолжении проведения изменения. Фактическая производительность услуги оценивается через сравнение с ожидаемой производительностью. Процесс также находит причины расхождения этих значений и управляет ими. Оценка фактической производительности любого изменения в услугах является важной частью сервис-менеджмента. Поставщик услуг может оценить, насколько реалистичны были его прогнозы в отношении услуг, и выявить причины несоответствия фактических значений ожиданиям. На рис. 10.2 изображен процесс Оценки, его входы и выходы. Рис. 10.2.  Процесс Оценки Приведем основные термины в контексте Оценки: Оценка должна рассматривать как запланированные, так и незапланированные эффекты изменения. При этом для простоты считается, что запланированные эффекты всегда приносят выгоду. Незапланированные эффекты гораздо труднее предсказать, и обычно они проявляются уже в процессе эксплуатации. Незапланированные эффекты, в отличие от запланированных, не всегда приносят пользу. Запланированные эффекты должны попадать под критерии приемки. Запланированные эффекты описываются в документации к изменению вместе с метриками, которые позволят измерить эффективность изменения. Приведем основные аспекты для оценки эффективности изменения: • Способность поставщика услуг - способность поставщика услуг или сервисной единицы осуществлять свою деятельность в соответствии с требованиями; • Переносимость - способность или мощность услуги принять изменение или релиз; • Организационное регулирование - способность организации принять предлагаемое изменение. Например, обновлены ли все имеющиеся услуги для того, чтобы гладко провести процесс внедрения новой услуги? Или: у группы внедрения есть все необходимые доступы? • Ресурсы - квалифицированный персонал, финансовые средства, инфраструктура, приложения и другие ресурсы, необходимые для внедрения услуги; • Моделирование и измерение - мера совпадения предсказанного поведения услуги (в процессе моделирования) с фактическим; • Люди - люди в рамках системы и влияние изменения на них; • Использование - подходит ли услуга для использования? Будет ли она доступной, надежной, безопасной и т.п.? • Цель - подходит ли услуга для осуществления поставленной перед ней цели? Сможет ли она предоставить требуемую производительность? Поможет ли она удалить ограничения? В управлении рисками выделяется два аспекта - оценка рисков и уменьшение рисков. Оценка рисков анализирует угрозы и уязвимости, которые появились (или появятся) в результате внедрения изменения. Основным значением при оценке рисков является вероятность угроз и ущерб, который они принесут. Риск=Вероятность*Ущерб Если посчитанный риск больше установленной нормы, необходимо принять меры по уменьшению рисков. Например, предпринять какие-то шаги для более быстрого восстановления в случае сбоев или просто устранить слабое место. После этого необходимо провести повторную оценку рисков, чтобы убедиться, что они снизились до приемлемого уровня. Результатом проведения Оценки становится отчет, состоящий из следующих секций: • перечень рисков - риски, которые остались после применения контрмер и действий по их уменьшению; • отчет по расхождениям - разница между предсказанной и фактической производительностью; • заключение об утверждении и проверки на соответствии техническим требованиям (если требуется); • рекомендации процессу Управления изменениями о том, стоит принять или отклонить изменение. Входами процесса Оценки являются пакет услуг, проектная документация, критерии приемки услуг, результаты тестов. Выходом - отчет об оценке для Управления изменениями. Ключевые показатели производительности для процесса Оценки: • со стороны заказчиков/бизнеса: ◦ уменьшение отличий между фактической производительностью и той, которая нужна заказчикам; ◦ уменьшение количества инцидентов, связанных с услугой. • внутренние показатели: ◦ количество "провалившихся" проектов (должно стремиться к нулю); ◦ уменьшение времени на проведение оценки. 10.3 Управление знаниями Управление знаниями (Knowledge Management) - процесс, отвечающий за сбор, анализ, сохранение и предоставление знаний и информации в Организации. Первичная цель Управления знаниями - увеличение эффективности путем снижения необходимости в повторном поиске знаний. Знания в контексте Внедрения включают в себя: • информация обо всех заинтересованных лицах; • приемлемые уровни рисков и ожидания относительно производительности; • доступные ресурсы и временные рамки. Процесс отвечает за то, чтобы нужная информация поступала к компетентному лицу своевременно для поддержки в принятии решений. Задачи процесса: • повышение результативности поставщика услуг, качества услуг и удовлетворенности заказчиков, а также снижение затрат; • обеспечение понимания персоналом ценности предоставляемых заказчикам услуг; • обеспечение своевременного доступа персонала к следующей информации: ◦ кто в настоящее время использует услуги; ◦ текущие уровни потребления; ◦ ограничения для предоставления услуги; ◦ трудности, с которыми сталкиваются заказчики. Знания рассматриваются в рамках модели Данные-Информация-Знания-Мудрость. Данные-Информация-Знания-Мудрость (Data-to-Information-to-Knowledge-to-Wisdom или DIKW) - способ представления взаимосвязей между данными, информацией, знанием и мудростью. Концепция DIKW показывает, каким образом каждое из перечисленных понятий базируется на остальных. Рассмотрим термины в составе DIKW: Данные - набор дискретных фактов о событиях. В рамках Управления знаниями над ними выполняются следующие действия: 1. сбор точных данных; 2. анализ, систематизация и преобразование в информацию; 3. определение наиболее значимых данных и концентрация ресурсов на их сборе. Информация - структурированные данные. Информация, как правило, хранится в слабоструктурированных формах - документах, e-mail, файлах. Управление знаниями предназначено для того, чтобы информацию можно было легко запросить, найти и использовать. Это необходимо для исключения ошибок, облегчения поиска и предотвращения избыточных работ. Знания - комплект накопленных взглядов, опыта, идей, ценностей и суждений. Люди получают знания, опираясь на свой собственный опыт и на опыт других людей, а также путем анализа информации, поступающей из различных источников. Знания предоставляют и структурируют информацию таким образом, чтобы ее можно было легко использовать для принятия решений. В контексте Внедрения это означает использование опыта предыдущих внедрений. Мудрость - предоставляет ультимативный процесс понимания материального и способность принимать решения, основываясь на логических рассуждениях. Взаимосвязь рассмотренных понятий показана на рис. 10.3 Рис. 10.3.  Преобразование данных в мудрость Знания процессов Управления услугами хранятся в Системе управления знаниями и услугами. Система управления знаниями и услугами (Service Knowledge Management System или SKMS) - набор инструментов и баз данных, которые используются для управления знаниями и информацией. SKMS включает Систему управления конфигурациями, также как и другой инструментарий и базы данных. SKMS сохраняет, управляет, обновляет, и представляет всю информацию, которая необходима поставщику услуг для управления полным жизненным циклом ИТ-услуг. SKMS представляет собой большую базу знаний, которая содержит в частности: • опыт персонала; • записи об окружающей обстановке - погода, количество и поведение пользователей, фигуры производительности организации и т.п. • возможности, требования и ожидания поставщиков и партнеров: • уровень квалифицированности персонала. На рис. 10.4 показана упрощенная схема взаимодействия трех уровней обращения информации - данные собираются в CMDB, поступают в CMS и только затем в SKMS для поддержки принятия решений. Рис. 10.4.  Связь CMDB, CMS и SKMS Рассмотрим основные действия и принципы в рамках Управления знаниями. 1. Формирование стратегии. Для организации Управления знаниями, как и для всех предыдущих процессов, необходимо разработать стратегию. Стратегия должна рассматривать следующие вопросы: ◦ модель управления; ◦ планируемые и уже проводимые организационные изменения и соответствующие им изменения ролей и ответственностей; ◦ определение ролей и ответственностей, непрерывное субсидирование; ◦ политики, процедуры, методы и процессы для Управления знаниями; ◦ технологические и другие требования; ◦ метрики измерения производительности процесса Управления знаниями. Особенно внимание в стратегии должно быть уделено сбору значимых для организации знаний, данных и информации. В частности: ◦ помощь организации в определении знаний, которые будут полезны; ◦ проектирование структурированного процесса для организации, отбора, хранения и предоставления информации. Это позволит людям улучшить понимание значимых для организации областей; ◦ сбор информации от разных процессов; ◦ формирование новых знаний; ◦ получение необходимой информации из сторонних источников; ◦ сбор знаний из внешних источников (например, Интернета, партнеров, публикаций и т.п.) и их адаптация под нужны организации. 2. Передача знаний. Для Управления знаниями крайне важно наладить обмен информацией в рамках организации. На практике часто именно в этом заключается основная сложность. Традиционными средствами передачи знаний в рамках организации являются тренинги и документация. При построении программы тренинга необходимо учитывать множество факторов - личностные особенности, культурные и языковые отличия, возраст, специфику области и т.п. ITIL рекомендует максимально визуализировать знания с помощью компьютерных и других технологий, так как это упростит процесс обучения. При этом важно научить людей применять полученные знания на практике в зависимости от обстоятельств. 3. Управление данными и информацией. Для эффективного управления данными и информацией Управлению знаниями важно ответить на следующие вопросы: ◦ какие знания нужны для принятия решений? ◦ какие условия необходимо контролировать? (от погодных условий до требований законодательства); ◦ какие данные доступны? ◦ сколько стоит сбор и управление информацией (данными)? ◦ применяемые политики, стандарты, требования законодательства и т.п. ◦ интеллектуальные и авторские права. После нахождения ответов на представленные вопросы необходимо определить требования к собираемой информации. Очень часто организации накапливают большое количество данных и информации без понимания того, как они будут использованы в дальнейшем. Когда требования определены, можно построить "архитектуру информации". В ITIL под этим подразумевается выполнение следующих действий: ◦ формирование и регулярное обновление модели управления информацией, которая позволит гибко, экономно и своевременно создавать, использовать информацию и управлять ею; ◦ определение системы, которые позволят оптимизировать использование информации путем эффективного управления данными и информацией; ◦ формирование системы классификации информации в рамках организации. На следующем шаге определяются процедуры управления данными и информацией. Они должны включать в себя механизмы, позволяющие: ◦ определить данные и информацию, которые будут собираться в рамках жизненного цикла услуг; ◦ определить процедуры управления данными и информацией и сделать их доступными для тех, кому они нужны; ◦ хранить и восстанавливать; ◦ устанавливать роли и ответственности для отдельных единиц информации; ◦ определять и публиковать права, обязанности и условия, необходимые для осуществления доступа к информации и данным; ◦ делать резервные копии информации и данных; ◦ определить требования для пересмотра хранимых информации и данных, например, внедрение новых технологий; ◦ собирать и хранить запросы к информации. В рамках Управления данными и информацией необходимо также разработать планы по улучшению процедур и процесса в целом. 4. Использование SKMS для поддержки принятия решений в рамках организации. Важно, чтобы люди и организации, участвующие в процессе, четко понимали метрики его успешности и эффективности. Для оценки эффективности Управления знаниями можно использовать множество критериев. В общем случае критериями процесса Управления знаниями могут быть: • успешное внедрение и эксплуатация услуг с небольшим количеством ошибок; • улучшение ответов на запросы бизнеса; • улучшение доступности стандартов и политик и управления ими; • распространение знаний; • уменьшение времени и "сил", необходимых для поддержки и управления услугами; • уменьшение времени на поиск информации, необходимой для диагностирования и решения проблем и ошибок; • уменьшение зависимости знаний от персонала. Критерии для бизнеса/заказчиков: • уменьшение пользовательских ошибок в результате эффективной передачи знаний; • уменьшение времени на решение проблем в результате того, что персонал лучше обучен и может воспользоваться SKMS; • улучшения для пользователей: • быстрое разрешение запросов; • способность решения проблем без помощи извне; • проблемы и вопросы решаются на том уровне, на котором появились, и не передаются выше. • уменьшение времени внедрения и поддержки на ранних стадиях эксплуатации услуги. Критерии для поставщика услуг: • использование знаний, измеренное в: • количество запросов к SKMS; • среднее время на поиск необходимой информации. • ошибки, выявленные в ходе проверок или о которых сообщил персонал; • участие персонала в форумах для предоставления поддержки посредством сбора и обмена знаниями; • степень повторного использования процедур, проектов тестирования, сценариев и т.п, описанных в документации; • удовлетворенность персонала организацией обмена знаниями. Эксплуатация услуг как этап жизненного цикла услуг Основной целью Эксплуатации услуг является координирование процессов и деятельностей, необходимых для предоставления услуг заказчикам на согласованных уровнях. Эксплуатация также ответственна за непрерывное управление технологиями, поддерживающими услуги. Даже хорошо спроектированные и внедренные процессы не принесут большой ценности в ежедневную эксплуатацию услуг, если не будут должным образом объединяться и управляться. Как часть процесса Управления услугами, Эксплуатация отвечает за эффективное использование процессов и уменьшение издержек. Как часть функционирования организации, Эксплуатация отвечает за то, чтобы бизнес смог достичь своих целей. Как часть мира технологий, Эксплуатация отвечает за эффективное использование технологий, поддерживающих услуги. Охват Эксплуатации включает в себя: • сами услуги. Любая деятельность, являющаяся частью услуги, будет предметом рассмотрения Эксплуатации. • процессы Управления услугами. В рамках Эксплуатации производится непрерывное управление многими процессами Управления услуг. Даже если они формально принадлежат другим этапам жизненного цикла услуг, например, Проектированию или Внедрению, они будут также использоваться в рамках Эксплуатации услуг. • технологии. Все услуги требуют каких-то технологий для своего предоставления. Управление этими технологиями входит в охват этапа Эксплуатации. • люди. Вне зависимости от того, какие услуги, процессы и технологии используются, всё в конечном итоге зависит от людей. Услуги предназначены для людей и управляются людьми. Непонимание важности этого аспекта может привести к провалу всего сервис-менеджмента. Эксплуатация услуг оптимизируется двумя способами: 1. долгосрочное последовательное улучшение - постоянное улучшение процессов, функций и результатов Эксплуатации. На основе анализа отчетов принимаются решения о том, где возможны улучшения, и как их лучше осуществить. Сюда относится, например, проектирование новых инструментов или процессов с помощью этапа Проектирования. 2. краткосрочное улучшение - применяемые в рамках рабочего процесса улучшения процессов, технологий и функций. Сюда относятся мелкие улучшения, не влияющие на фундаментальную основу процесса, например, обновления, тренинги и т.п. В публикации "ITILv3. Service Operation" вводятся новые термины, касающиеся эксплуатации услуг. Контроль операционного управления (IT Operations Control) - функция, отвечающая за мониторинг и контроль услуг и IT-инфраструктуры. Операционное управление IT (IT Operations) - деятельности, выполняемые функцией Контроля операционного управления ИТ, в том числе консольное управление, планирование задач, резервное копирование, восстановление, печать и управление выводом. Процессы в рамках Эксплуатации: • мониторинг событий - отслеживает все события, связанные с Эксплуатацией; • управление проблемами и инцидентами - концентрируется на восстановлении нормальной работы услуг при возникновении сбоев; • выполнение запросов - разрешение запросов пользователей, которые чаще всего поступают через сервис-деск; • управление доступом - предоставление легитимным пользователям прав на доступ к услугам и предотвращение доступа неавторизированных пользователей. Более подробно процессы в рамках Эксплуатации будут рассмотрены в следующих лекциях. В публикации "ITILv3. Service Operation" вводится несколько терминов для отображения того, как люди объединяются для выполнения процессов и различных деятельностей. Функция - логическая концепция, относящаяся к людям и автоматизированным системам, которые выполняют определенный процесс, деятельность или комбинацию процессов и деятельностей. В больших организациях функция может быть разбита на части и выполняться в рамках нескольких отделов, групп или команд. Функция также может предоставляться одной организационной единицей, например, сервис-деском. В маленьких организациях, наоборот, один отдел может выполнять несколько функций. Группа - объединение людей, имеющих что-то общее. В публикации ITIL это люди, осуществляющие схожие деятельности. При этом они могут использовать разные технологии, относится к разным организационным единицам и даже разным организациям. Команда - объединение людей, которые работают вместе для достижения общей цели, но при этом они не обязательно принадлежат одной организационной структуре. Отдел - форма организационной структуры, которая существует для выполнения определенного набора деятельностей. Управление - форма организационной структуры, в которой объединены отделы. Роль - набор ответственностей, деятельностей и полномочий, присвоенных сотруднику или команде. Роль определяется в процессе. Один сотрудник или команда может иметь (выполнять) много Ролей. Например, Роли Менеджера Конфигураций и Менеджера Изменений могут выполняться одним сотрудником. Эксплуатация услуг это не просто повтор разработанных процессов и процедур. Самой сложной задачей этого этапа является обеспечение стабильной работы услуг наряду с адаптацией к изменяющимся условиям окружения IT и бизнеса. Вообще, Эксплуатация услуг часто должна искать компромиссы между взаимоисключающими друг друга вещами. В этой лекции мы рассмотрим основные из них. Интересно, что в публикации "ITILv3.Service Operation" выделено 2 взгляда на IT - внешний взгляд и внутренний взгляд. Внешний взгляд рассматривает IT как набор услуг. Это подход заказчиков и бизнеса, которым не важны технологические особенности предоставления услуг и управления ими. Им важно чтобы услуги функционировали на согласованных уровнях и приносили бизнесу заявленную ценность. Внутренний взгляд рассматривает IT как набор технологий. Он рассматривает, какие технологии и системы используются для предоставления услуг и управлениями ими. Это взгляд поставщика услуг, поэтому он и называется внутренний. При предоставлении услуг важно рассматривать две точки зрения и соблюдать баланс между ними (рис. 11.1). Рис. 11.1.  Баланс между внутренним и внешним взглядом Если организация будет фокусироваться только на внешнем взгляде, то есть рассматривать только требования бизнеса, она может неправильно оценить свои возможности и дать бизнесу обещания, которые не сможет в итоге исполнить. Напротив, организация, которая будет фокусироваться на внутреннем взгляде, может создать дорогие по себестоимости услуги, не приносящие бизнесу значимых результатов. В табл. 11.1 приведены примеры крайностей в обеих позициях. Таблица 11.1. Чрезмерный уклон на внутренний взгляд Чрезмерный уклон на внешний взгляд Позиция Контроль производительности и управление устройствами, системами, инфраструктурой и персоналом IT с маленькой заботой о конечном результате Достижение высоких уровней производительности услуг без понимания того, как они достигаются Метрики • концентрация на технической производительности без отслеживания того, как она в итоге влияет на услуги; • сообщение бизнесу значений метрик, которые не относятся к производительности услуг в целом (например, время обновления сети) • концентрация на внешних метриках, без показа внутреннему персоналу как их достичь и как улучшить процессы; • ожидание того, что внутренний персонал разработает собственные метрики для измерения внутренней производительности Стратегия эксплуатации • стандартные механизмы на протяжении всего времени эксплуатации • все новые услуги должны вписываться в существующие архитектуры и процедуры • множество команд и технологий • новые технологии требуют новых подходов к эксплуатации и создание новых команд операционного управления Стратегия затрат • снижение затрат достигается преимущественно за счет объединения или усиления технологий • оптимизация операционных процедур и ресурсов • влияние сокращения расходов на бизнес оценивается только после его осуществления • подсчет ROI(Возврата инвестиций) концентрируется на сокращении издержек и периодах окупаемости • бюджет строится вокруг того, что в первую очередь нужно бизнес-единицам • бизнес-единицы, которые не смогли четко заявить о своих нуждах или неправильно их обосновали, будут использовать худшие услуги из-за недостаточности финансирования Методики и руководства Сфокусированы вокруг непосредственного управления технологиями без привязки к тому, как их производительность влияет на услуги в целом Сфокусированы в основном вокруг того, что и когда нужно сделать, без четких указаний как этого достичь Перегиб в ту или иную сторону является недопустимым. Эксплуатация услуг должна предоставлять пользователям и заказчикам ценность. Это невозможно сделать без понимания того, как что работает. Достижение баланса между внутренним и внешним взглядом требует четкого подхода, отражающего все этапы жизненного цикла услуг: • понимание того, какие услуги использует бизнес и почему; • понимание того, как услуги влияют на бизнес; • понимание того, как используются технологии для предоставления и поддержки услуг; • вовлечение команд Операционного управления в этап Непрерывного улучшения услуг для обнаружения способов предоставления большей ценности/качества и уменьшения затрат; • формирование методик и руководств для команд Операционного управления, которые будут рассматривать вопросы управления технологиями и предоставления услуг; • Операционное управление должно четко понимать, как производительность отдельных технологий влияет на услуги в целом и, соответственно, на бизнес и его цели; • набор стандартных услуг предоставляется постоянно всем бизнес-единицам, кастомизированные услуги предоставляются отдельным бизнес-единицам; • стратегия затрат должна балансировать между требованиями различных бизнес-единиц; уменьшение затрат достигается за счет новых технологий или оптимизации использования имеющихся; • ROI должен быть основан на предоставлении ценности, а не сокращении затрат; • вовлечение Операционного управления в этапы Проектирования и Внедрения услуг; • обратная связь с этапом Непрерывного улучшения услуг для выявления возможностей и необходимости улучшений; • четкий план коммуникаций и тренингов для бизнеса. Как бы хорошо ни была спроектирована услуга, она будет функционировать хуже, если ее компоненты будут работать неустойчиво или вовсе будут недоступны. Эксплуатация услуг должна обеспечить стабильность и доступность IT-инфраструктуры в соответствии с проектной документацией. В то же время она должна распознавать изменения требований бизнеса и IT и оперативно реагировать на них. Многие изменения носят эволюционный характер. Например, функциональность, производительность и архитектура базовой системы могут измениться за несколько лет работы. Каждое такое изменение дает возможность для предоставления большей ценности бизнесу. Ответную реакцию на эволюционные изменения легче планировать. Некоторые изменения происходят очень быстро. Например, бизнес-единица выиграла тендер и ей нужны новые услуги, больше возможностей и более быстрое время реагирования. Для Эксплуатации услуг наибольшей сложностью является приспособление к таким изменениям без значительного влияния на услуги, которые уже используются. Эксплуатации услуг необходимо соблюдать баланс между обеспечением стабильности функционирования услуг и быстрым реагированием на изменения (рис. 11.2). Рис. 11.2.  Баланс между стабильностью и реагированием на изменения В табл. 11.2 приведены примеры крайностей двух позиций. Таблица 11.2. Чрезмерная концентрация на стабильности Чрезмерная концентрация на реагировании Позиция • ориентированность на технологии • развитие и улучшение стандартных процессов и техник Управления услугами • ориентированность на бизнес • одобрение изменений без предварительного определения того, что нужно сделать для их осуществления Типичные проблемы IT может демонстрировать соответствие с SOP и OLA, даже если есть явные расхождения с требованиями бизнеса Персонал IT не может выполнять стандартные процедуры и рутинные работы, так как сконцентрирован на проектной деятельности Стратегия развития • стратегия развития основана на анализе спроса на существующие системы • сопротивление внедрению новых услуг, которое приводит к тому, что бизнес-единицы стремятся управлять своими системами для того, чтобы получить доступ к новым услугам • развитие новой технологии для каждого нового требования бизнеса • использование разных технологий для удовлетворения требований бизнеса, которые незначительно отличаются друг от друга Технология предоставления услуг Использование существующей или стандартной технологии предоставления услуг; услуги корректируются для работы в рамках существующих параметров Избыточное обеспечение. Нет попыток приспособить новую услугу для работы в существующей инфраструктуре. Управление мощностями • прогнозы делаются на основе текущих рабочих нагрузок • производительность систем поддерживается на постоянном уровне путем обновлений и управления спросом • прогнозы строятся на основе будущих потребностей бизнеса отдельно для каждой услуги; не принимается в расчет деятельность IT и другие услуги • текущие рабочие нагрузки не учитываются Достижение баланса между стабильностью и быстрым реагированием на изменения требует выполнения следующего: • финансирование гибких технологий, таких как виртуальные среды; • построение сильного процесса Управления уровнем услуг(SLM), который будет функционировать на всем жизненном цикле услуг; • интеграция SLM с другими процессами проектирования для обеспечения корректного отображения требований бизнеса на этап Эксплуатации и компоненты IT-инфраструктуры; • инициирование изменений на ранних стадиях жизненного цикла услуг с целью совместного управления требованиями бизнеса и IT; • обеспечить участие IT в изменениях бизнеса на ранних стадиях их осуществления, чтобы IT услуги максимально соответствовали этим изменениям; • команды Операционного управления должны предоставлять информацию на вход проектирования и улучшения архитектур и услуг. Эксплуатация услуг также должна находить баланс между качеством услуг и их стоимостью. На рис. 11.3 изображена зависимость инвестиций в услуги и их качества. Рис. 11.3.  Зависимость качества услуг от их стоимости Из рисунка видно, что в большинстве случаев увеличение качества услуги приводит к ее удорожанию. Тем не менее, эта связь не всегда прямо пропорциональна. Например, на ранних стадиях жизненного цикла можно значительно увеличить качество услуг путем минимальных вложений. Чем позже делаются изменения в рамках жизненного цикла, тем они дороже. На более поздних этапах жизненного цикла услуг даже малейшее увеличение качества услуги может стоить больших денег. Достижение баланса между затратами и качеством является ключевой задачей сервис-менеджмента (рис. 11.4). Универсальных решений нет, так как каждая услуга имеет разный потенциал оптимизации, зависящий от природы самой услуги и бизнес-цели, которую она поддерживает. Например, бизнес может быть готов тратить много денег на увеличение доступности критичных услуг, но его устраивает низкий уровень доступности для административных средств. К сожалению, существует множество примеров, когда организации вкладывают большие финансовые средства в увеличение качества услуг, но не получают никаких доказательств того, что оно в конечном итоге увеличивается. Рис. 11.4.  Баланс качества услуг и их стоимости В последние годы IT-организации стремятся сократить свои расходы чаще всего под давлением извне. Это приводит не только к уменьшению стоимости услуг, но и их качества. При этом нет простого способа расчета баланса качества и затрат. SLR (Требования уровня услуг) вместе с четким пониманием бизнес-цели и потенциальных рисков помогут определить, что услуги предоставляются с оптимальными затратами. Они также могут помочь определить услуги с "большим размером", которые возникают из-за доступности средств, и услуги "с маленьким размером", которые возникают из-за того, что бизнес не понимает необходимости финансирования тех или иных аспектов. В табл. 11.3 примеры крайностей в двух позициях. Таблица 11.3. Чрезмерный фокус на качестве Чрезмерный фокус на стоимости Позиция Предоставление качества, которое необходимо бизнесу, чего бы это ни стоило Максимальное сокращение затрат и предотвращение выхода за рамки выделенного бюджета Типичные проблемы • расширение бюджета • IT-услуги предоставляют больше, чем требуется бизнесу для успеха • увеличение спроса на услуги с высоким качеством • IT лимитирует качество услуг исходя из доступного бюджета • бизнес стремится получить больше услуг от IT Управление финансами IT не имеет метода для связи качества услуг и их стоимости. Для оценки используется чаще всего "затраты на одного пользователя" Нет метода для связи деятельностей в рамках IT и непосредственного предоставления услуг. Финансирование обычно выполняется в рамках расходов, заранее предусмотренных в бюджете. Достижение баланса качества услуг и их стоимости требует следующего: • процессы и инструменты Управления финансами могут рассчитать стоимость предоставления услуг и выбрать оптимальную по стоимости модель предоставления среди имеющихся альтернатив. Например, сравнить стоимость предоставления услуги с 98% доступностью и 99,5 %, или стоимость предоставления услуг с дополнительным функционалом и без него; • обеспечение того, что решения относительно баланса качества и затрат, будут принимать люди с соответствующей квалификацией на этапах Построения стратегии и Проектирования. Менеджеры Операционного управления должны принимать решения относительно выделения финансовых средств на увеличение операционной эффективности. Следующей проблемой является баланс проактивности и реактивности. К реактивным организациям относятся те, которые не предпринимают никаких действий, пока не будет толчка в виде какого-нибудь внешнего драйвера - нового требования бизнеса, разработанного приложения или увеличения жалоб пользователей и заказчиков. К сожалению, многие организации придерживаются реактивных методов управления, наивно полагая, что это единственный путь для достижения стабильности в предоставлении услуг. Они сознательно ограничивают любые проявления проактивных действий со стороны персонала Операционного управления. Ирония состоит в том, что отсутствие одобрения проактивных действий сервис-менеджмента может привести к тому, что в итоге увеличится стоимость реактивных действий и соответствующие риски. Например, проактивным действием является формирование резервных копий серверов на случай сбоев. Это стоит не так дорого, как реактивные действия по восстановлению, если сбой все-таки случится. Проактивная организации всегда ищет пути для улучшения текущей ситуации. Проактивный подход всегда работает на перспективу и увеличивает конкурентное преимущество организации. Тем не менее, излишний уклон "в проактивность" может стоить слишком дорого. Поэтому важно соблюдать баланс двух подходов (рис. 11.5). Рис. 11.5.  Баланс реактивного и проактивного подходов В табл. 11.3 представлены крайности этих подходов. Таблица 11.3. Чрезмерная реактивность Чрезмерная проактивность Позиция Ответ на потребности бизнеса и инциденты только после того, как о них сообщили/они случились Предугадывание потребностей бизнеса, прежде чем о них сообщат, и проблем, прежде чем они появятся Типичные проблемы • подготовка к предоставлению новых услуг занимает много времени, так как каждый проект рассматривается как первый • похожие инциденты возникают вновь и вновь • у персонала плохой моральный настрой и, как следствие, высокая "текучка" • деньги тратятся прежде, чем устанавливаются требования. При этом многое из того, на что были потрачены деньги, никогда не будет использовано. • персонал IT работает в организации долго и допускает со временем, что знает требования бизнеса лучше, чем сам бизнес Планирование мощностей Ждать пока не возникнут проблемы с мощностями. При их возникновении предоставлять дополнительные мощности до появления следующей проблемы. Предугадывать проблемы с мощностями и тратить деньги на то, чтобы они не появились - даже если это скорее всего не случится Планирование непрерывности услуг • никаких планов не формируется, пока не случилась катастрофа или другое значительное неблагоприятное событие • планы по восстановлению сфокусированы на ключевых системах IT, а не на процессах Чрезмерное планирование(и траты) на опции восстановления IT. Предоставление незамедлительного восстановления большинства услуг, вне зависимости от их влияния на бизнес Управление изменениями • изменения обычно не фиксируются или фиксируются в последний момент как Срочные изменения • недостаточно времени на оценку влияния и затрат • изменения плохо тестируются и контролируются, как результат - большое количество последующих инцидентов изменения запрашиваются и осуществляются даже при отсутствии необходимости в них - много работы проделывается на корректировку работы элементов, которые нормально функционируют. Проактивное управление в общем случае имеет преимущества, но иногда требуется и реактивные действия. Для соблюдения баланса необходимо следующее: • строгие процессы Управления проблемами и инцидентами; • готовность категорировать технические сбои также хорошо, как спрос на услуги со стороны бизнеса. • доступность данных от Управления конфигурациями и Управления активами для экономии времени на реализацию проектов и принятия адекватных решений; • непрерывное вовлечение SLM в эксплуатацию услуг. Очень важно иметь обратную связь Эксплуатации с другими этапами жизненного цикла услуг. Персонал операционного управления должен принимать участие в Проектировании и Внедрении услуг, а также в Построении стратегии там, где это допустимо. Меру участия персонала необходимо определить в должностных инструкциях, ролях и т.п. Это обеспечит то, что услуги, спроектированные на этапе Проектирования, смогут быть использованы в конечном итоге. Интересным является то, что в ITIL мониторинг и контроль эксплуатации услуг сравнивается с мониторингом и контролем здоровья. IT-инфраструктура выступает в роли организма. Каждая инфраструктура имеет жизненно важные показатели, которые необходимо отслеживать, чтобы понять, работает ли инфраструктура нормально, то есть "здорова" ли она. Это значит, что для контроля не обязательно отслеживать абсолютно все компоненты, а только "жизненно важные". Это может быть использование пропускной способности сети или использование памяти на критичных серверах. Если значения этих показателей в пределах нормы, значит, система здорова. Выделение таких показателей позволит сократить расходы на мониторинг и контроль. Но, как и с другими организмами, иногда необходимо проводить комплексные проверки, которые выявят проблемы, не влияющие сразу на "жизненно важные" показатели. Какие показатели и когда необходимо контролировать в "здоровье" инфраструктуры должно быть определено на этапе Проектирования, протестировано на этапе Внедрения и оптимизировано в рамках Непрерывного улучшения услуг. Управление событиями и инцидентами в рамках Эксплуатации услуг 12.1. Управление событиями Управление событиями (Event Management) - процесс, ответственный за управление событиями в течение жизненного цикла. Управление событиями одна из главных деятельностей операционного управления ИТ. Событие (Event) - изменение состояния, которое имеет значение для управления конфигурационной единицей или услугой. Для того чтобы быть эффективным, операционное управление должно знать состояние инфраструктуры и ее компонентов, а также отслеживать любые отклонения от нормальной работы. Управление событиями реализовывается с помощью систем мониторинга и контроля, которые основаны на двух типах инструментов: • инструменты активного мониторинга - опрашивают ключевые конфигурационные единицы с целью выяснения их статуса и доступности. Любое отклонение вызовет алерт (предупреждение), который перенаправляется необходимой команде или инструменту для принятия необходимых действий. Приведем определение из глоссария ITIL: Активный мониторинг (Active Monitoring) - мониторинг конфигурационных единиц или услуг, использующий автоматизированные регулярные проверки для отслеживания текущего статуса объекта мониторинга. • инструменты пассивного мониторинга - обнаруживают и собирают алерты, без принятия каких-либо ответных действий. Пассивный мониторинг (Passive Monitoring) - мониторинг конфигурационной единицы, услуги или процесса, который основывается на предупреждениях или уведомлениях о текущем состоянии объекта мониторинга. Из определений, данных в глоссарии, не совсем очевидна разница двух видов мониторинга. Основным отличием является принятие ответных действий в случае алерта при активном мониторинге и их полное отсутствие при пассивном. Необходимо сразу отметить разницу между мониторингом и Управлением событиями. Эти процессы очень похожи, но, тем не менее, имеют отличия. Управление событиями сфокусировано на обнаружении значимых событий, касающихся статусов услуг и инфраструктуры. Мониторинг же следит за всеми событиями, и, по сути, имеет более широкий охват. Например, мониторинг может отслеживать состояние устройства, чтобы удостовериться, что оно функционирует в установленных рамках, даже если устройство не генерирует никаких событий. Таким образом, Управление событиями является частью системы мониторинга. Фактически, Управление событиями может контролировать любой аспект сервис-менеджмента. Объектами Управления событиями могут быть: • конфигурационные единицы; • условия среды (пожар или обнаружение дыма); • мониторинг использования лицензий на программное обеспечение; • безопасность; • нормальная активность (например, использование приложений или производительность сервера). Ценность Управления событиями для бизнеса косвенная. Тем не менее, можно выделить следующие преимущества, которые дает Управление событиями бизнесу: • Предоставляет механизмы для раннего обнаружения инцидентов. Во многих случаях Управление событиям позволяет обнаружить инцидент и принять соответствующие действия до того, как он значительно повлияет на услугу в целом. • При интеграции с другими процессами сервис-менеджмента может повысить их эффективность. Он может сообщить об изменениях или отклонениях статусов, что позволит соответствующей команде своевременно предпринять необходимые действия. • Раннее оповещение о необходимости обновления процедур или ресурсов; • Управление событиями основано на автоматизированных операциях, что увеличивает эффективность и позволяет задействовать персонал на более "креативные" работы, в частности, проектирование новых услуг и поиск путей по улучшению существующих. Управление событиями работает со следующими типами событий: • события, сигнализирующие о регулярной операции, например: ▪ уведомления о том, что работы в соответствии с графиком выполнены; ▪ аутентификация пользователя для использования приложения; ▪ e-mail достиг получателя; • события, отмеченные как отклонения, например: ▪ попытка входа в приложение с использованием некорректного пароля; ▪ нестандартная ситуация в работе бизнес-процесса, которая может потребовать дальнейших действий; ▪ использование CPU выше установленной нормы; ▪ установка неизвестных приложений. • события, отмеченные как нестандартные, но при этом не являющиеся отклонениями. При обнаружении подобных событий необходим более детальный мониторинг. На рис. 12.1 представлена схема процесса Управления событиями. Рис. 12.1.  процесс Управления событиями Разного рода события возникают постоянно, но при этом не все события нужно регистрировать и обнаруживать. Важно, чтобы люди, участвующие в проектировании, разработке, развертывании и поддержке услуг, четко понимали, какие именно события необходимо отслеживать. Конфигурационные единицы в большинстве случаев выдают предупреждения в случае выполнения определенных условий. Возможность формировать эти предупреждения должна быть спроектирована и встроена в конфигурационные единицы. Многие конфигурационные единицы генерируют предупреждения с использованием открытого стандарта SNMP. В идеальном случае на этапе Проектирования формируется стандартный набор событий, которые необходимо отслеживать в отношении конкретных конфигурационных единиц. В рамках этапа Внедрения этот набор тестируется и настраивается. После того, как предупреждение сформировано, специальный агент в системе обнаруживает его, "читает" и анализирует значимость события. Следующий шаг - фильтрация событий. На этом этапе выносится решение о том, будет ли данное событие проигнорировано или его необходимо передать менеджменту для осуществления необходимых ответных действий. Если событие игнорируется, оно просто записывается в журнал событий (лог). Никаких других действий не выполняется. Фильтрация является первым шагом к классификации событий. Этап фильтрации, по сути, является необязательным. Каждая организация имеет свои критерии для оценки значимости события, но ITIL рекомендует использовать как минимум три категории событий: • информационное событие - относится к событию, которое не требует никаких действий и не является отклонением. Такие события просто записываются в логи и используются для слежения за работой системы и ее компонентов, или контроля выполнения каких-то операций. Они также могут использоваться для сбора статистики и дальнейших исследований. Примерами информационных событий могут быть вход пользователя в систему или успешное завершение транзакции. • предупреждение - этот тип события формируется тогда, когда услуга или устройство приближается к пороговым значениям. Предупреждения предназначены для того, чтобы соответствующий сотрудник, процесс или инструмент проверили ситуацию более детально и приняли необходимые меры для предотвращения отклонения. Примерами предупреждений могут быть использование памяти сервера более 75% или увеличение количества коллизий в сети. • отклонение - этот тип событий сигнализирует о том, что услуга или устройство функционируют неправильно (за пределами нормы). Это значит, что нарушаются SLA и OLA, что, как следствие, приводит к негативному влиянию на бизнес в целом. Примерами отклонений могут послужить: ◦ выход из строя сервера; ◦ больше, чем n пользователей подключились одновременно к приложению N; ◦ сегмент сети не отвечает на запросы. Если событие отмечено как значительное, необходимо определить точно его значимость и необходимые ответные действия - это этап корреляции. Корреляция обычно выполняется частью средства управления под названием "Correlation Engine", которая применяет к событию набор правил и критериев в определенном порядке. Основная идея в том, что событие может повлиять на бизнес, а правила помогут определить степень и тип этого влияния. В механизме корреляции событий прописывается способ реагирования на событие, например: что делаем при первом, втором и последующих проявлениях данного предупреждающего события, при сочетании или последовательности ряда событий - отклонений, одиночном, но имеющем очень серьезные для заказчика последствия, отклонении. Примеры того, что может использовать Correlation Engine для оценки: • количество похожих событий (например, большое количество попыток неправильного ввода пароля может свидетельствовать о попытке взлома устройства); • количество конфигурационных единиц, генерирующих похожие события; • сопровождают ли событие какие-либо специфичные действия с данными или кодом; • является ли событие отклонением; • категория события; • назначение приоритета событию и т.п. Механизм, который инициирует ответные действия, называется триггером. Существует множество типов триггеров, каждый из которых спроектирован для инициализации конкретных действий. Например: • Триггеры инцидентов, которые формируют запись в Системе управления инцидентами и, соответственно, запускают процесс Управления инцидентами; • Триггеры изменений, которые формируют RFC и инициируют процесс Управления изменениями; • Скрипты, которые выполняют определенные действия, например, перезагрузку устройства; • Триггеры баз данных, которые ограничивают доступ пользователей к определенным областям базы или удаляют/создают записи в ней. Следующий этап - выбор ответных действий. Существует множество вариантов ответных действий, которые при этом могут комбинироваться. Ниже приведены примеры вариантов ответных действий: • запись события в лог. Вне зависимости от того, какое ответное действие будет выбрано, хорошей практикой является формирование записи о событии в логе. Должна быть стандартная процедура для операционного персонала, предусматривающая периодический анализ логов, а также четкие инструкции о том, как использовать конкретный лог. Также необходимо помнить о том, что информация в логах может не иметь значения до возникновения инцидента. В рамках Управления событиями нужно определить период хранения логов перед тем, как они будут заархивированы или удалены. • автоматические ответные действия. Для регулярных и "понятных" событий можно разработать автоматические ответные действия. Триггер запустит их и затем проверит результат выполнения. Если что-то пошло не так, будет сформирована запись о проблеме или инциденте. Примерами автоматических ответных действий могут быть: 1. перезагрузка устройства; 2. повторный запуск услуги; 3. изменение параметра устройства; 4. блокировка приложения для предотвращения несанкционированного доступа и т.п. • Алерт (предупреждение) и вмешательство людей. Алерт служит для уведомления о событии людей, которые имеют необходимые навыки и знания для его разрешения. При этом алерт должен содержать как можно более полную информацию о событии, на основании которой человек сможет принять правильное решение. • Создание Запроса на изменение (RFC). В Управлении событиями есть две точки, где могут быть созданы RFC: ◦ при возникновении отклонения. Например, проверка компьютера показала, что на нем установлено три неавторизованных приложения. В этом случае необходимо сформировать RFC, который поможет процессу Управления изменениями устранить отклонение. ◦ на этапе корреляции была определена необходимость изменения. В данном случае на этапе корреляции определяется, что наиболее подходящим ответным действием будет изменение чего-то. • Создание записи об инциденте. Если Correlation Engine определяет то, что определенный набор событий является инцидентом, создается запись об инциденте. Запись об инциденте должна быть максимально полной и отражать связи со всеми событиями, относящимися к инциденту. • Создание записи о Проблеме или формирование связи с уже имеющейся записью. Инциденты обычно связаны с определенными записями о проблемах. При возникновении инцидента важно связать его с соответствующей записью о проблеме, а если такой нет - создать ее. • Особые типы инцидентов. В некоторых случаях событие может являться отклонением, но при этом не влиять непосредственно на услуги. Такие инциденты не включаются в расчет времени простоя и относятся скорее с проблемам операционного характера. Информация о них должна быть записана в соответствующий лог и передана персоналу, который разбирается с инцидентами этого типа. Каждый день может происходить десятки и сотни событий и зачастую невозможно детально рассматривать каждое событие. Обзорные действия предназначены для проверки того, как были отработаны инциденты, не пропущены ли какие-то события, сбора статистических данных и т.п. При этом обзорные действия не должны повторять то, что было сделано до этого. Метрики, которые можно использовать для измерения эффективности Управления событиями: • количество событий по категориям; • количество событий по значимости; • количество событий, которые потребовали участия персонала; • количество инцидентов, вызванных известными ошибками и проблемами; • количество одинаковых инцидентов (или повторяющихся); • количество инцидентов, связанных с проблемами производительности; • количество инцидентов, свидетельствующих о наличии потенциальных проблем с доступностью и т.п. Основными сложностями и рисками для Управления событиями являются недостаточное финансирование, выбор оптимального уровня фильтрации событий и упущение момента для своевременного развертывания агентов в рамках инфраструктуры. Для того чтобы Управление событиями было эффективным, его механизмы должны быть разработаны на этапе Проектирования услуг в рамках процессов Управления доступностью и Управления мощностями. Но при этом Управление событиями не является статичным - в ходе эксплуатации услуг могут появляться новые требования и события, которые необходимо отслеживать. Проектирование Управления событиями должно включать следующее: 1. Инструментарий - что может быть отслежено в отношении конфигурационных единиц и как можно воздействовать на них. Другими словами это точное определение и проектирование того, как контролировать и мониторить инфраструктуру и услуги. В рамках определения инструментария необходимо ответить на следующие вопросы: ◦ что необходимо мониторить? ◦ какой тип мониторинга необходим? ◦ когда необходимо формировать событие? ◦ какая информация должна содержаться в событии? ◦ для кого предназначены сообщения о событиях? 2. Сообщения об ошибках должны отображать критичные ошибки, свидетельствующие о сбое или вероятности его возникновения. 3. Механизмы обнаружения событий и формирования алертов. Проектирование этих механизмов требует: ◦ знания взаимосвязей всех бизнес-процессов, которые контролируются с помощью Управления событиями; ◦ знания SLA для каждой услуги, поддерживаемой конфигурационной единицей; ◦ знания того, кто поддерживает конфигурационную единицу; ◦ знания того, какие значения параметров конфигурационной единицы являются нормальными, а какие нет; ◦ понимание того, что именно нужно знать для эффективного управления конфигурационной единицей; ◦ знания информации, которая может помочь эффективной поддержке конфигурационной единицы; ◦ осознания важности совокупности одинаковых или похожих событий; ◦ понимание взаимосвязей конфигурационных единиц; ◦ доступности информации об известных ошибках, полученной от вендоров или из предыдущего опыта. 4. определение пороговых значений для каждой конфигурационной единицы. При этом значения могут изменяться в зависимости от многих обстоятельств. Например, максимальное количество пользователей, получающих доступ к серверу, зависит от того, какие именно работы они на нем выполняют. 12.2. Управление инцидентами Управление инцидентами (Incident Management) - процесс, отвечающий за управление жизненным циклом всех инцидентов. Основная цель Управления инцидентами - скорейшее восстановление услуги для пользователей. Инцидент (Incident) - незапланированное прерывание услуги или снижение качества услуги. Сбой конфигурационной единицы, который еще не повлиял на услугу, также является инцидентом. Например, сбой одного диска из массива зеркалирования. Как видно из определения процесса, Управление инцидентами предназначено для максимально быстрого восстановления нормальной эксплуатации услуги и минимизации неблагоприятного влияния на бизнес в случае возникновения инцидента. Под "нормальной эксплуатацией услуги" здесь понимается эксплуатация в соответствии с SLA. Процесс рассматривает все события, которые нарушают или могут нарушить нормальную эксплуатацию услуги. Информация о таких событиях может поступать из разных источников, основными из которых являются звонки пользователей и технического персонала в сервис-деск и процесс Управления событиями. Ценность Управления инцидентами для бизнеса более очевидна, чем у других процессов этапа Внедрения. Часто именно этот процесс является основой для формирования обоснования бизнесу о необходимости остальных процессов этапа Внедрения. В частности, Управление инцидентами помогает бизнесу тем, что: • быстро находит и разрешает инциденты, в результате чего снижается время простоя услуг, что в целом увеличивает показатели доступности услуг; • выравнивает деятельности IT в соответствии с приоритетами бизнеса; • увеличивает способность выявления возможностей для улучшения услуг в результате расследования инцидентов; • сервис-деск, разрешая инциденты, определяет дополнительные требования IT и бизнеса к услугам и обучению. Время разрешения инцидента обычно формализовано в рамках SLA, OLA и других базовых соглашений. Команды поддержки должны быть готовы к соблюдению временных ограничений. ITIL вводит также понятие Модель инцидентов, которая включает в себя: • шаги, которые необходимо предпринять для того, чтобы разрешить инцидент; • хронологический порядок шагов; • распределение ответственностей - кто и что делает; • временные рамки и пороговые величины для завершения каждого действия; • вопросы того, с кем необходимо связать и на каком этапе; Таким образом, Модель инцидентов описывает последовательность действий при возникновении определенного типа инцидентов. Использование моделей инцидентов позволяет стандартизовать процесс Управления инцидентами и ускорить его. Этот подход применим в отношении часто возникающих "стандартных" инцидентов. "Нестандартные" случаи обрабатываются отдельно, например, инциденты, связанные с информационной безопасностью. В отдельную категорию выделяются "значительные инциденты", которые должны разрешаться максимально быстро. Значительный инцидент (Major Incident) наивысшая категория влияния для инцидента. Значительный инцидент означает значительные потери для бизнеса. То, какие инциденты будут считаться значительными, каждая организация решает индивидуально. На рис. 12.2 схематически отображены основные деятельности в рамках Управления инцидентами. Рис. 12.2.  Процесс Управления инцидентами Рассмотрим основные этапы, изображенные на рис. 12.2. Для того чтобы разрешить инцидент, его необходимо сначала обнаружить, то есть идентифицировать. С точки зрения непрерывности бизнеса неприемлемо ждать обращений пользователей или технического персонала в сервис-деск. Все ключевые компоненты должны контролироваться, чтобы своевременно обнаруживать сбои или возможности их возникновения. После того, как инцидент обнаружен, информацию о нем необходимо занести в лог. В логе должно быть отображено время обнаружения инцидента, вне зависимости от того, как он был обнаружен - по звонку в сервис-деск или в результате работы автоматических агентов. В логе также необходимо записать всю связанную с инцидентом информацию. Запись об инциденте должна послужить базой для его разрешения соответствующей командой поддержки. Запись об инциденте должна включать: • уникальный идентификатор инцидента; • категорию инцидента; • срочность инцидента. Срочность (Urgency) - мера того, насколько быстро с момента своего появления инцидент, проблема или изменение приобретет существенное влияние на бизнес. Например, инцидент с высоким уровнем влияния может иметь низкую срочность до тех пор, пока это влияние не затрагивает бизнес в период закрытия финансового года. Влияние и срочность используются для назначения приоритета. • влияние инцидента; • приоритет инцидента; • дата и время записи; • Имя/ID человека или группы, сделавшей запись об инциденте; • метод уведомления; • имя/отдел/номер/расположение пользователя; • метод обратной связи; • описание симптомов; • статус инцидента; • связанные конфигурационные единицы; • группа поддержки/сотрудник, к кому переадресован инцидент; • связанная с инцидентом проблема/известная ошибка; • деятельности, осуществленные для разрешения инцидента; • время и дата разрешения инцидента; • категория закрытия; • время и дата закрытия. Следующий этап разрешения инцидента - категорирование. Оно необходимо для дальнейших работ, в частности, поиска известных ошибок и проблем, которые могли послужить причиной для возникновения инцидента. Обычно используется три-четыре уровня категорирования (рис. 12.3). Рис. 12.3.  Варианты категорирования инцидентов Нет стандартных методов для категорирования инцидентов, каждая организация сама определяет, какие категории будет использовать. Приоритет инцидента определяется исходя из двух понятий - срочности и влияния. Влияние в отношении инцидентов чаще всего определяется на основе количества пользователей, которые он затронул. Тем не менее, этот показатель не всегда является объективным. В некоторых случаях влияние инцидента даже на одного единственного пользователя может оказать значительное негативное влияние на бизнес в целом. Другие факторы, которые можно использовать для оценки влияния: • риск для жизни или сегмента; • количество услуг, которые затрагивает инцидент; • уровень финансовых потерь; • влияние на бизнес-репутацию; • возникновение нарушений законодательства и требований регуляторов. В таблицах 12.1 и 12.2 приведен пример матриц для определения приоритета инцидента и времени, в течение которого его необходимо разрешить. Таблица 12.1. Влияние Высокое Среднее Низкое Срочность Высокая 1 2 3 Средняя 2 3 4 Низкая 3 4 5 Таблица 12.2. Приоритет Характеристика Время разрешения 1 Критичный 1 час 2 Высокий 8 часов 3 Средний 24 часа 4 Низкий 48 часов 5 Планируемый Запланировать Для персонала поддержки необходимо разработать четкие инструкции определения приоритета инцидента на основе срочности и влияния на бизнес. Необходимо отметить, что приоритет инцидента может меняться в зависимости от изменения окружающих условий и требований бизнеса. Далее следует этап начальной диагностики. В первую очередь он относится к инцидентам, поступившим в сервис-деск. Специалист службы сервис-деск должен попытаться найти причину, вызвавшую инцидент, понять, что именно работает некорректно и выявить максимальное количество характеристик инцидента во время связи с пользователем, например, по телефону. Другими словами, специалист должен попытаться решить инцидент и закрыть его. Если это невозможно, он сообщает пользователю идентификационный номер инцидента. Если сервис-деск не может разрешить инцидент или сроки первой ступени разрешения инцидентов истекли, инцидент должен быть немедленно передан дальше. Эскалация (Escalation) - деятельность, направленная на получение дополнительных ресурсов, когда это необходимо для достижения Целевых показателей уровня услуги или ожиданий заказчиков. Эскалация может потребоваться в рамках любого процесса Управления услугами, но наиболее часто ассоциируется с Управлением инцидентами, Управлением проблемами и управлением жалобами заказчика. Существует два типа эскалации: функциональная эскалация и иерархическая эскалация. • функциональная эскалация. Функциональная эскалация подразумевает передачу инцидента в группу поддержки с более высокой квалификацией и компетенцией. При этом если очевидно, что второй уровень поддержки не сможет разрешить инцидент, его можно сразу передать на третий уровень поддержки. Третий уровень поддержки может включать в себя не только сотрудников организации, но и поставщиков, вендоров и т.п. При этом ответственность за уведомление пользователя о ходе разрешения инцидента остается на сервис-деске, вне зависимости от того, где инцидент рассматривается на данный момент. • иерархическая эскалация. Иерархическая эскалация подразумевает вовлечение или просто информирование руководителей более высокого уровня о возникновении инцидента. Она способствует своевременному принятию решений относительно выделения дополнительных ресурсов и вовлечения внешних организаций в процесс разрешения инцидента. Следующий этап разрешения инцидентов называется исследование и диагностика. В случаях, когда пользователи обращаются только для поиска информации, сервис-деск должен предоставить ее в минимальные сроки. Но если сообщается о наличии сбоя, это требует определенных действий по исследованию и диагностике инцидента. При этом все предпринятые действия должны быть отображены в записи об инциденте. Действия чаще всего включают в себя: • установление того, что именно не работает или что именно ищет пользователь; • определение хронологии событий; • оценка влияния инцидента, в том числе количества пользователей, которых он затронул; • поиск в базе знаний аналогичных случаев в прошлом. Когда потенциальное разрешение инцидента определено, необходимо провести тестирование того, что действия по восстановлению завершены, и услуга полностью восстановлена для пользователей. Группа, разрешившая инцидент, должна передать его на закрытие сервис-деску. Сервис-деск, в свою очередь проверяет, что все действия, необходимые для разрешения инцидента, выполнены, пользователи удовлетворены и согласны закрыть инцидент. Это включает в себя следующее: • закрытие категорирования - производится проверка корректности изначально установленной категории инцидента. Если она оказалось неправильной, ее исправление и занесение изменений в запись об инциденте; • опрос удовлетворенности пользователей - осуществляется по звонку или электронной почте для статистики и отображения эффективности работы сервис-деска; • проверка полноты записи об инциденте; • определение того, какая проблема вызвала инцидент, является она постоянной или периодически повторяющейся. Сюда относится также определение проактивных действий по предотвращению инцидентов этого типа в дальнейшем и формирование записи о проблеме, если она новая; • формальное закрытие инцидента - формальное закрытие записи об инциденте. В некоторых случаях инцидент может быть повторно открыт даже после формального закрытия. Правильным будет заранее определить правила о том, как, когда и при каких условиях инцидент может быть повторно открыт. Это используется, в частности, когда в один и тот же день возникают одинаковые инциденты. Для нового инцидента, тем не менее, необходимо сформировать новую запись со ссылкой на предыдущий инцидент. Запись о предыдущем инциденте может быть использована для разрешения нового. Метриками эффективности процесса Управления инцидентами могут быть: • общее количество инцидентов; • количество инцидентов, находящихся на разных стадиях - закрыт, в работе, передан и т.п. • размер текущего лога об инцидентах; • количество значительных инцидентов; • среднее время разрешения инцидентов; • процент инцидентов, разрешенных в согласованное время разрешения инцидентов; • средние затраты на инцидент; • количество повторно открытых инцидентов и их процентное соотношение к общему количеству инцидентов; • количество инцидентов, неправильно назначенных в команды поддержки; • количество инцидентов, для которых были неправильно определены категории; • количество удаленно разрешенных инцидентов (без персонального присутствия); • количество инцидентов, разрешенных с использованием каждой Модели инцидентов; • количество инцидентов в разрезе определенных интервалов дня. Для эффективного Управления инцидентами необходимо обеспечить следующее: • способность обнаруживать инциденты как можно раньше. Это включает в себя обучение пользователей немедленно сообщать об инцидентах и конфигурирование инструментов Управления событиями; • убедить персонал в том, что все инциденты должны быть занесены в журнал; • доступность информации об известных проблемах и ошибках. Это позволит персоналу использовать опыт предыдущих инцидентов; • взаимодействие с CMS для определения взаимосвязей конфигурационных единиц и обращения к их истории для поддержки первого уровня; • взаимодействие с SLM для корректной оценки инцидентов, расстановки приоритетов и выполнения процедур Эскалации. SLM в свою очередь может использовать информацию от Управления инцидентами для определения того, что целевые уровни производительности реалистичны и могут быть достигнуты. Основные риски для процесса Управления инцидентами: • большое количество инцидентов, которые не могут быть разрешены в установленные сроки в связи с недостатком ресурсов или их недостаточной подготовкой; • приостановка разрешения инцидентов из-за некорректной работы поддерживающих инструментов; • недостаточность или несвоевременность информации из-за некорректной работы поддерживающих инструментов или плохой взаимосвязи с другими процессами; • несоответствия с основными контрактами и соглашениями, которые возникают вследствие их плохой проработки и нереалистичности согласованных целевых показателей.