Инициация управления проблемами

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

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

 

Известные ошибки

 

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

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

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

Известная ошибка не может быть закрыта раньше ее успешного решения.

Примечание:

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

 

Решение проблемы

 

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

 

Обмен информацией

 

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

 

Отслеживание и эскалация

 

Ход решения всех проблем должен отслеживаться.

Все спорные вопросы следует эскалировать соответствующим сторонам.

В процесс следует включить:

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

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

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

г) определение точек эскалации;

д) регистрацию сведений об используемых ресурсах и о любых принятых действиях.

 

Закрытие инцидента и проблемы

 

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

а) точно зафиксированы сведения о способе разрешения;

б) сделана категоризация причины - для облегчения последующего анализа;

в) при необходимости, потребитель услуги и персонал, обеспечивающий её предоставление, осведомлены о разрешении;

г) потребитель согласен с разрешением;

д) если разрешение невозможно или оно не может быть выполнено, то потребитель информирован об этом.

 

Анализ проблем

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

Как правило, анализ проблем включает:

а) анализ влияния состояния решения инцидента и статуса проблемы на согласованные уровни услуг;

б) совещания руководства для определения тех проблем, которые требуют безотлагательных действий по их решению;

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

 

Задачи анализа проблем

 

Анализ проблем должен включать:

а) определение тенденций, например, повторений проблем и инцидентов, известных ошибок;

б) выявление повторений проблем с конкретным компонентом услуги или инфраструктуры, или обладающим конкретным месторасположением;

в) выявление нехватки активов, недостаточной подготовки персонала или плохой документации;

г) выявление нарушений (фактов несоблюдения требований и правил) стандартов, политик и законов;

д) выявление известных ошибок в запланированных релизах;

е) определение готовности сотрудников поставщика услуг к работе по устранению инцидентов и решению проблем;

ж) выявление повторений ранее устранённых инцидентов и решённых проблем.

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

Необходимая информация должна быть добавлена в базу знаний процесса управления проблемами.

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

 

Предупреждение проблем

Проактивное управление проблемами должно вести к сокращению количества инцидентов и проблем. Оно также должно включать ссылки на информацию, способствующую проведению анализа, такую как:

а) информацию об активах и конфигурациях;

б) информацию процесса управления изменениями;

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

г) информацию об аналогичных проблемах, существовавших раньше.

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

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

 

 

Процессы контроля

 

Управление конфигурациями

 

Цель: Определять и контролировать компоненты услуг и инфраструктуры, а также осуществлять сбор, хранение конфигурационной информации и поддержание ее в актуальном состоянии.

 

Планирование и реализация управления конфигурациями

 

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

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

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

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

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

а) область применения, цели, политики, стандарты, роли и ответственности по управлению конфигурациями;

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

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

г) порядок контроля конфигураций (порядок контроля доступа к конфигурациям, обеспечения сохранности, контроля версий, сборок и релизов);

д) процесс контроля взаимодействия, необходимый для определения, регистрации и управления конфигурационными элементами и информацией о них, которые являются общими для двух и более организаций-потребителей, например, системные интерфейсы, релизы программных средств;

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

ж) управление подрядчиками и субподрядчиками, участвующими в работе процесса управления конфигурациями.

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

 

Идентификация конфигураций

 

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

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

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

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

б) конфигурационные базисы или описание конфигураций пакетов аппаратных и программных средств, типовые конфигурации оборудования и конфигурации релизов;

в) документальные копии и электронные библиотеки, например, библиотеки эталонного программного обеспечения;

г) инструментарий или программное средство, используемые для автоматизации управления конфигурациями;

д) лицензии;

е) компоненты, предназначенные для обеспечения информационной безопасности, например, брандмауэры (сетевые экраны);

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

з) документацию, связанную с управлением услугами, например, Соглашения об уровне услуг, описания процедур;

и) вспомогательные средства и системы для поддержки предоставления услуг, например, средства электроснабжения;

к) сведения о взаимоотношениях и взаимозависимостях между конфигурационными элементами.

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

а) другую документацию;

б) другие активы;

в) различные объекты инфраструктуры, например, здание;

г) структурные подразделения;

д) персонал.

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

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

 

Контроль конфигураций

 

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

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

Чтобы сохранить целостность систем, услуг и инфраструктуры, информация о конфигурационном элементе, должна соответствующим образом храниться в безопасной среде, которая:

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

б) предоставляет средства для восстановления информации после сбоев;

в) позволяет провести контролируемое восстановление, например, с мастер-копии программного обеспечения.