13.1. DS 9. Управление конфигурацией
Обеспечение целостности аппаратного и программного обеспечения требует создания и поддержки точного и полного хранилища конфигурационных данных. Данный процесс включает в себя сбор первоначальных данных о конфигурации, создание прототипа, проверку и аудит данных о конфигурации, а также обновление хранилища конфигурационных данных по мере необходимости. Объект конфигурации или конфигурационная единица (Configuration Item, CI) – компонент инфраструктуры или объект, требующий настроек, связанных с инфраструктурой, которая находится под контролем (или должна находиться под контролем) должностных лиц, ответственных за конфигурацию. Объекты конфигурации могут весьма разниться по сложности, размерам и типам – от целой системы (включающей аппаратную часть, программное обеспечение и документацию) до отдельного модуля или небольшого аппаратного компонента. Управление конфигурацией (Configuration Management) – управление настройками объектов конфигурации на протяжении их жизненного цикла [1]. Информация о каждом объекте конфигурации регистрируется в форме записи в хранилище конфигурационных данных и поддерживается актуальной в течение всего жизненного цикла процессом Управление конфигурациями.
Для идентификации конфигураций важно:
определить, как будут категорироваться объекты конфигурации;
определить подход к идентификации и наименованию всех объектов конфигурации;
определить роли и ответственности для владельцев объектов конфигурации отдельных типов в рамах этапов жизненного цикла.
Деятельность в рамках идентификации конфигураций включает в себя:
определение и документирование критериев выбора объектов конфигурации и составляющих их компонентов;
выбор объектов конфигурации и их компонентов на основе установленных критериев;
назначение уникальных идентификаторов для выбранных объектов конфигурации;
определение атрибутов для каждого объекта конфигурации;
определение для каждого объекта конфигурации момента, когда он поступает в Управление конфигурациями;
определение владельца, ответственного за каждый объект конфигурации.
Модель конфигураций должна включать в себя связи и позицию каждого объекта конфигурации. Важной частью Управления конфигурацией является определение уровня контроля для каждого объекта конфигурации. Для этого применяется иерархический подход, так как каждый CI может являться частью другого CI или группы CI. Например, база данных может использоваться многими приложениями. Объекты конфигураций нижних уровней не подвержены детальному контролю и аудиту. Например, клавиатуры, используемые в организации, могут послужить примером CI нижнего уровня. Важно отметить, что в зависимости от конкретной организации, критерии выбора CI нижнего уровня отличаются. Например, в здании ООН работает множество людей, говорящих на разных языках. Для их удобства используются разные клавиатуры - с английской, русской, итальянской и другими раскладками. Следовательно, для ООН информация о клавиатурах является относительно критичной и клавиатура как CI не находится на нижнем уровне иерархии.
Всем объектам конфигурации необходимо назначить имена, состоящие из идентификатора и версии. Имена должны быть уникальными. Помимо этого все физическое оборудование должно иметь бирки, по которым их можно будет легко идентифицировать.
В хранилище конфигурационных данных содержаться атрибуты каждого объекта конфигурации. Выделяют следующие стандартные атрибуты:
уникальный идентификатор;
тип CI;
имя/описание;
версия;
расположение;
дата поставки;
детали лицензии ( в частности, дата ее истечения);
владелец/куратор;
статус;
поставщик/источник;
документация;
данные истории, например, аудиторские отчеты;
тип связей;
соответствующий SLA.
Чаще всего характеристики CI содержатся в документации к нему. Связи объектов конфигурации отражают то, как они взаимодействуют друг с другом в процессе предоставления услуг. Информация о связях объектов между собой должна храниться в хранилище конфигурационных данных.
Основные связи между CI:
CI является частью другого CI. Например, сервер является частью инфраструктуры сайта. Это отношение "родитель-ребенок";
CI соединен с другим CI. Например, персональный компьютер соединен с локальной сетью;
CI использует другой CI. Например, программа использует модуль другой программы;
CI установлен на другой CI, например, Windows Excel на персональный компьютер.
CI может иметь множество связей. Например, быть частью другого CI и одновременно использоваться другими CI .
Каждый CI имеет ряд дискретных статусов в рамках своего жизненного цикла. Значимость каждого статуса определяется использованием CI в его рамках.
Учет статусов обеспечивает корректность и актуальность записей об объектах конфигурации, активах и их состояниях. Стандартные деятельности в рамках Учета состояний:
управление записями о конфигурациях в процессе жизненного цикла;
управление записью, восстановлением и объединением статусов с целью обеспечения корректности, безопасности, своевременности и целостности;
обеспечение доступности информации о статусах в рамках Управления конфигурациями;
запись всех изменений в CI.
Запись о конфигурации создается в процессе идентификации и контроля CI. Она обеспечивает прозрачность и трассируемость CI для всех процессов [5].
Эффективное управление конфигурацией обеспечивает большую доступность систем, минимизирует проблемы, связанные с промышленной эксплуатацией систем и ведет к более быстрому решению проблем.
(рис 13.1) Процесс "Управление конфигурацией"
Управление процессом
Управление конфигурацией.
удовлетворяет следующим бизнес требованиям к ИТ
оптимизация ИТ-инфраструктуры, ресурсов и возможностей, учет ИТ-активов. сосредоточено на
создании и поддержке точного и полного хранилища конфигурационных атрибутов ИТ -активов и прототипов, а также на сравнении их с текущей конфигурацией.
достигается с помощью
Создания централизованного хранилища всех объектов конфигурации.
Выявления объектов конфигурации и их поддержке.
Проверки целостности данных о конфигурации.
результаты оцениваются с помощью следующих показателей
Число проблем, связанных с соответствием требованиям бизнеса, вызванных неправильной конфигурацией активов.
Число отклонений, выявленных между конфигурационными данными в хранилище и текущей конфигурацией активов.
Доля приобретенных, но не учтенных в хранилище лицензий.
В таблице 13.1 представлена информация, необходимая для процесса и ее источники.
| Источник | Входящая информация |
|---|
| AI 4 | Пользовательские, операционные, поддерживающие, технические и руководства администраторов |
| AI 7 | Распространяемые объекты конфигурации |
| DS 4 | Критичность объектов ИТ-конфигурации |
В таблице 13.2 приведены результаты процесса и то, куда они должны поступить.
| Результаты | В процессы |
|---|
| ИТ-конфигурация/детализации по ИТ-активам | DS 8 | DS 10 | DS 13 |
| Запросы на изменения (где и как производить исправления) | AI 6 | | |
| Отчеты об эффективности процессов | ME 1 | | |
Таблица 13.3 содержит таблицу ОУКИ для процесса, а таблица 13.4 – цели и показатели.
| Действия\Функции | Президент | Финансовый директор | Высшее руководство | Директор по ИТ | Владелец бизнес-процесса | Руководитель эксплуатации системы | Главный архитектор ИТ-системы | Руководитель разработок | Руководитель администрации ИТ | Руководитель проектного офиса | Аудит, риски, безопасность |
|---|
| Разработать процедуры планирования управления конфигурацией | | | | К | У | У | И | К | | К | О |
| Вести сбор первичных данных о конфигурации и разрабатывать прототипы | | | | | К | У | К | | | И | У/О |
| Осуществлять проверку и аудит данных о конфигурации, в том числе выявление неавторизованного программного обеспечения | | И | | | У | | | И | | И | У/О |
| Обновлять хранилище конфигурационных данных | | | | | О | О | О | | | И | У/О |
| Цели | Показатели |
|---|
ИТ:
Оптимизировать ИТ-инфраструктуру, ресурсы и возможности
Осуществлять учет и защиту всех активов |
число проблем, связанных с соответствием требованиям бизнеса, вызванных неправильной конфигурацией активов |
Процесса:
создать хранилища в отношении всех активов, атрибутов конфигурации и прототипов
поддерживать целостность хранилища конфигурационных данных
изучать текущую конфигурацию активов на предмет соответствия прототипам в хранилище конфигурационных данных |
число отклонений, выявленных между конфигурационными данными в хранилище и текущей конфигурацией активов
доля приобретенных, но не учтенных в хранилище лицензий |
Действия:
создание централизованного хранилища всех объектов конфигурации
выявление объектов конфигурации и их поддержка
проверка целостности данных о конфигурации |
средняя временная задержка между выявлением несоответствия и его исправлением
число несоответствий, относящихся к неполноте или отсутствию данных о конфигурации
доля объектов конфигурации, соответствующих уровням обслуживания по эффективности, безопасности, доступности |
Цели контроля
DS 9.1. Хранилище конфигурационных данных и прототип
Создать средства поддержки и централизованное хранилище, в которое должна помещаться все информация, имеющая отношение к объектам конфигурации. Следует вести мониторинг и учет всех активов и изменений в них. Поддерживать прототипы для объектов конфигурации всех систем и услуг в качестве контрольной точки, к которой можно вернуться после совершения изменений.
DS 9.2. Идентификация и обслуживание объектов конфигурации
Разработать процедуры конфигурации для поддержки управления и документирования всех изменений в хранилище конфигурационных данных. Интегрировать данные процедуры с процессами управления конфигурацией, управления инцидентами и управления проблемами.
DS 9.3. Проверка целостности конфигурации
Периодически проверять конфигурационные данные и подтверждать целостность конфигурации в настоящем и прошлом. Периодически проверять установленное программное обеспечение на предмет соответствия политике использования ПО, либо использования нелицензионного ПО, либо иных случаев использования ПО не в соответствии с условиями контрактов. Следует вести отчетность и предпринимать действия по исправлению ошибок и отклонений.
Рассмотрим диаграмму, на которой изображены компоненты электронной почты (рис.13.2).
(рис 13.2) Компоненты электронной почты
Такое представление может быть полезно:
показать новым администраторам, какие сервера с чем работают (ориентация);
при планировании добавления жесткого диска к серверу 1 узнать, что на нем работает (VM1) и какие услуги будут затронуты (электронная почта). Эта информация полезна для процесса Управление внесением изменений;
если пользователи сообщают, что электронная почта недоступна, служба поддержки знает, что стоит проверить работу приложения на VM1. Эта информация полезна для Управления инцидентами;
если решается вопрос о переносе VM1 с сервера 1 на сервер 2, нужно обсудить изменения в указанной диаграмме в рамках процесса Управление изменениями;
если сервер 1 ломается, нужно связаться с производителем. Контактная информация может быть отображена в диаграмме (Управление инцидентами).
и т.п.
Конечно, на практике хранить такое детальное описание компонентов в виде диаграмм невозможно. В любом случае информацию подобного рода нужно хранить и систематизировать. Это и называется в COBIT хранилищем конфигурационных данных (Configuration Management Database, CMDB). Каждый элемент в хранилище называется Объектом конфигурации. В данном примере сервер 1, VM 1 и электронная почта являются объектами конфигурации.
Каждая организация определяет индивидуально, какую именно информацию хранить в CMDB. Например:
Нужно ли определять, на каком сервере располагается VM1? Представьте себе, что с виртуальной машиной возникли проблемы и нужно проверить каждый сервер организации, чтобы найти ее. Именно поэтому связи объектов конфигурации должны быть обязательно указаны в CMDB.
Нужно ли указывать параметры сервера 1 (частоту процессора, количество памяти и т.п.)? В принципе достаточно легко узнать такую информацию на самом сервере. Хранить ее или нет – решать Вам.
Нужно ли указывать информацию о конфигурации Exchange? Вы можете легко ее узнать, зайдя на VM1. Подобного рода информация может заноситься в CMDB только в ручном режиме, а это сильно усложняет процесс.
Помимо заполнения хранилища важно следить за его актуальностью. Например, в сервис-деск поступила информация о недоступности электронной почты. Специалисты поддержки обратились к CMDB и увидели, что приложение запущено на VM1. Обратились к VM1 , а его там нет. Вот почему крайне важно обновлять информацию в CMDB. Это можно сделать следующими путями:
включить процедуру обновления хранилища в процедуру внесения изменений;
создать процедуру регулярного обзора хранилища на предмет актуальности представленной в нем информации.
Важной задачей в рамках процесса Управления конфигурацией является управление лицензиями. В CMDB важно отобразить не только количество лицензий, но и то, где они установлены. Это поможет выявить излишки или недостаток лицензий, а также нелегальное использование программного обеспечения.
Эффективность деятельности любой организации зависит от того, насколько хорошо она управляет своими активами. Именно работа с активами приносит организации прибыль. Управление конфигурацией ответственно за управление активами с целью поддержки других процессов управления услугами.
DS 10. Управление проблемами
Эффективное управление проблемами требует выявления и классификации всех проблем, анализа их первопричин и последующего их решения. Проблема (Problem) – в ИТ неизвестная причина, лежащая в основе одного или многих инцидентов[1].Процесс управления проблемами также включает в себя формулирование рекомендаций по совершенствованию, поддержке учета проблем и изучение статуса корректирующих действий. Эффективный процесс управления проблемами максимизирует доступность систем, ведёт к повышению уровней обслуживания, сокращению затрат и повышению комфорта и удовлетворенности пользователей. Процесс Управления проблемами тесно связан с процессом Управления инцидентами, так как возникновение инцидентов происходит вследствие наличия проблем. Эти процессы часто используют одни инструменты, системы категорирования и расстановки приоритетов и т.п. Также как и процессы Управления инцидентами и Управления изменениями, Управление проблемами предоставляет ценность для бизнеса тем, что повышает доступность и качество услуг. Если проблема, порождающая инцидент, решена, бизнес выиграет от уменьшения времени простоя услуг и уменьшения негативного влияния на бизнес-системы. Управление проблемами также уменьшает издержки бизнеса на разрешение инцидентов, так как непосредственно уменьшает их количество[5].
(рис 13.3) Процесс "Управление проблемами"
Управление проблемами.
удовлетворяет следующим бизнес требованиям к ИТ
обеспечение удовлетворенности конечных пользователей предложением услуг и уровнями обслуживания, сокращение дефектов и переделок в предлагаемых услугах.
сосредоточено на
Учёте, отслеживании и разрешении проблем в среде промышленной эксплуатации; анализе первопричин всех существенных проблем и определении путей решения выявленных эксплуатационных проблем.
достигается с помощью
Проведения анализа первопричин выявленных проблем.
Анализа тенденций.
Назначения владельцев проблем и интенсификации их решения.
результаты оцениваются с помощью следующих показателей
Число повторяющихся проблем, имеющих последствия для бизнеса.
Доля проблем, решенных в течение определенного периода времени.
Регулярность отчетов или обновлений, касающихся текущих проблем, ранжированных по их серьезности.
Процесс Управления проблемами схематически изображен на рис.13.4. Порядок действий взят из публикаций ITIL, которые также рассматривают этот процесс.
(рис 13.4) Управление проблемами
Первый этап - обнаружение проблемы. Существует множество путей обнаружения проблем, в частности:
обнаружение или "подозрение" причины возникновения одного или более инцидентов от сервис-деска. Сервис-деск может разрешить инцидент, но не выявить его первопричину, что увеличивает вероятность возникновения аналогичных инцидентов в дальнейшем. В этом случае формируется запись о проблеме для поиска основной причины инцидента;
анализ инцидента технической группой поддержки, в результате которого будет выявлено существование проблемы или вероятность ее существования;
автоматическое обнаружение сбоев приложений или компонентов инфраструктуры, которое выявит необходимость создания записи о проблеме;
уведомление о существовании проблемы от поставщика или подрядчика;
анализ инцидентов как часть проактивного управления инцидентами.
После обнаружения проблемы, информацию о ней необходимо занести в лог, то есть сформировать запись о проблеме. Запись о проблеме должна отражать детальное описание проблемы и весь ее жизненный цикл, в частности:
информация о пользователе;
информация об услуге;
информация об оборудовании;
время и дата начала формирования записи;
описание инцидента, который стал результатом существования проблемы;
детальное описание всех деятельностей в рамках решения проблемы.
Для определения приоритета проблемы необходимо также оценить ее "тяжесть" или то, насколько она серьезна для инфраструктуры:
систему можно восстановить или она должна быть заменена?
сколько это будет стоить?
сколько людей и какой квалификации необходимо для решения проблемы?
сколько времени займет решение проблемы?
насколько велик охват проблемы? ( например, сколько конфигурационных единиц она затрагивает)
На следующем этапе проводятся исследование и диагностика проблемы. Целью исследования является поиск первопричины проблемы. Для оценки точки сбоя и определения уровня негативного влияния может использоваться CMDB. База известных ошибок может быть использована для поиска случаев возникновения проблемы в прошлом, и, возможно, ее решения.
Иногда полезным может быть попытка воссоздания сбоя в тестовой среде для выяснения его причины и поиска наиболее эффективного пути ее устранения. Существует множество стандартных техник для анализа, диагностики и решения проблем. Приведем техники, рассматриваемые в публикации ITIL:
хронологический анализ. Когда возникает сложная проблема, могут появиться противоречивые отчеты и сообщения относительно того, что действительно случилось. Для восстановления картины документально фиксируют хронологию всех событий, связанных с проблемой. Это помогает также выяснить зависимости и устранить из цепочки события, которые не относятся к рассматриваемой проблеме.
Анализ потерь (Pain Value Analysis) - методика, используемая для идентификации влияния на бизнес одной или нескольких проблем. Формула расчета потерь основана на количестве затронутых пользователей, продолжительности простоя, влияния на каждого пользователя, и стоимости для бизнеса (если известно).
Анализ Кепнера и Трего - системный подход к разрешению проблем. Проблема анализируется в терминах Что, Где, Когда и Сколько. Определяются возможные причины. Наиболее вероятная причина подвергается проверке. Таким образом определяется истинная причина.
"Мозговой штурм" - методика, которая помогает команде генерировать идеи. При этом идеи не должны критиковаться и анализироваться во время проведения самого Мозгового штурма, это происходит после.
Диаграмма Ишикавы - методика, помогающая команде определить все возможные причины проблемы. Первоначально была разработана Каору Ишикавой (Kaoru Ishikawa), результатом работы этой методики является диаграмма[5]. Основная проблема изображается в виде ствола диаграммы, главные факторы - как ветки, вторичные факторы - как соплодие и т.д. Создание диаграммы стимулирует обсуждение проблемы и более глубокое понимание ее сложности.
анализ Парето - методика отделения значимых причин возникновения проблемы от незначимых. Должны быть предприняты следующие действия:
сформировать таблицу, содержащую причины проблемы и их частоту в процентном соотношении от общего количества случаев возникновения проблемы;
упорядочить строки таблицы в порядке увеличения важности причин;
добавить столбец совокупного процента.
Более понятным анализ Парето будет на примере из публикации ITIL. В таблице 13.5 приведены 10 причин отказа сетевых взаимодействий, то есть "падения сети".
| "Падение сети" |
|---|
| Причины | Процент от общего количества (%) | Расчет | Совокупный процент (%) |
| Сетевой контроллер | 35 | 0+35 | 35 |
| Порча файлов | 26 | 35+26 | 61 |
| Конфликт адресации | 19 | 61+19 | 80 |
| ОС Сервера | 6 | 80+6 | 86 |
| Ошибки скриптов | 5 | 86+5 | 91 |
| Непротестированное изменение | 3 | 91+3 | 94 |
| Ошибки оператора | 2 | 94+2 | 96 |
| Сбой резервного копирования | 2 | 96+2 | 98 |
| Попытки вторжения | 1 | 98+1 | 99 |
| Сбой дисков | 1 | 99+1 | 100 |
Далее необходимо сделать следующие шаги:
создать столбиковую диаграмму причин, расположенных в соответствии с их Процентом от общего количества ( 2 столбец);
наложить линию суммарного процента (4 столбец).
нарисовать линию от 80 % совокупного процента к оси y, параллельно оси x. В точке пересечения с линией суммарного процента "уронить" ее на ось x. Точка оси x, на которую "упадет" линия отделит значимые причины от незначимых.
Диаграмма рассматриваемого примера изображена на рис.13.5.
(рис 13.5) Анализ Парето
Следующий этап - поиск обходного решения. Обходное решение (Workaround) - уменьшение или устранение влияния инцидента или проблемы, для которых в текущий момент недоступно полное разрешение. Например, перезапуск отказавшей конфигурационной единицы или ручное добавление поврежденного файла из резервной копии. Обходные решения являются временными решениями для поддержания работоспособности системы на время поиска решения проблемы. Обходные решения документируются в Базе известных ошибок. База известных ошибок (Known Error Database или KEDB) - база данных, содержащая все записи об известных ошибках. Эта база данных создается в процессе Управления проблемами и используется процессами Управления инцидентами и проблемами.
Как только найдено решение проблемы, его необходимо как можно быстрее реализовать. Тем не менее, важно помнить, что внесение изменений может затронуть другие услуги или конфигурационные единицы. Если необходимо какое-то функциональное изменение, прежде чем его осуществить, надо сформировать Запрос на изменение, который будет обработан в рамках процесса Управления внесением изменений. После того, как все необходимые действия предприняты, проблема устранена, происходит закрытие записи о проблеме, а также всех связанных с ней записей об инцидентах. Перед закрытием необходимо провести проверку (пересмотр) полноты записи о проблеме - она должна содержать детальное описание всех осуществленных процедур и действий. Для значительных проблем, которые считаются таковыми в соответствии с системой приоритетов конкретной организации, проверка должна быть более детальной, в частности рассматривать такие вопросы как:
что сделано правильно в отношении проблемы;
что сделано неправильно в отношении проблемы;
что может быть сделано лучше в будущем;
как предотвратить повторение проблемы;
были ли задействованы третьи стороны.
На практике редко встречаются приложения, системы и релизы программного обеспечения, не имеющие ошибок. В идеальном случае все они обнаруживаются на этапе тестирования. Тем не менее, ошибки могут не проявится или быть незамеченными и , таким образом, "просочиться" на этап эксплуатации.
В таблице 13.6 представлена информация, необходимая для процесса и ее источники.
| Источник | Входящая информация |
|---|
| AI 6 | Авторизация изменений |
| DS 8 | Отчеты об инцидентах |
| DS 9 | Детальная ИТ-конфигурация, ИТ-активы |
| DS 13 | Протоколы ошибок |
В таблице 13.7 приведены результаты процесса и то, куда они должны поступить.
| Результаты | В процессы |
|---|
| Запросы на изменения (где и как осуществлять исправления) | AI 6 |
| Протоколы проблем | AI 6 |
| Отчеты об эффективности процессов | ME 1 |
| Выявленные проблемы, ошибки и временные способы их решения | DS 8 |
Таблица 13.8 содержит таблицу ОУКИ для процесса, а таблица 13.9 – цели и показатели.
| Действия\Функции | Президент | Финансовый директор | Высшее руководство | Директор по ИТ | Владелец бизнес-процесса | Руководитель эксплуатации системы | Главный архитектор ИТ-системы | Руководитель разработок | Руководитель администрации ИТ | Руководитель проектного офиса | Аудит, риски, безопасность |
|---|
| Выявлять и классифицировать проблемы | | И | И | К | У | К | К | | | И | О |
| Провести анализ первопричин | | | | | К | | К | | | | У/О |
| Разрешить проблемы | | | | К | У | О | О | | О | К | К |
| Отслеживать статусы проблем | | И | И | К | У/О | К | К | | К | К | О |
| Предложить рекомендации по улучшению и создать запросы на изменения | | | | И | У | И | И | | И | | О |
| Поддерживать протоколы проблем | | | | И | И | | И | | | И | У/О |
| Цели | Показатели |
|---|
ИТ:
обеспечить удовлетворенность конечных пользователей предложением услуг и уровнем обслуживания
сократить дефекты и переделки в решениях и предлагаемых услугах
обеспечить достижение целей ИТ |
число повторяющихся проблем, имеющих последствия для бизнеса
число прерываний бизнеса, вызванных эксплуатационными проблемами |
Процесса:
вести учет и отслеживать эксплуатационные проблемы до их решения
анализировать первопричины всех существенных проблем |
доля зафиксированных и отслеженных проблем
доля повторяющихся проблем (в течение периода времени) по их серьезности
доля проблем, решенных в течение требуемого периода времени
число открытых/новых/закрытых проблем по их серьезности
среднее и стандартное отклонение от временной зарежки между выявлением проблемы и ее решением
среднее и стандартное отклонение от временной задержки между решением и закрытием проблемы |
Действия:
наделение менеджера по решению проблем достаточными полномочиями
проведение анализа первопричин выявленных проблем
анализ тенденций
назначение владельцев проблем и интенсификации их решения |
средняя продолжительность времени между фиксацией проблемы и выявлением ее первопричин
доля проблем, по которым первопричины не выявлены
регулярность отчетов или обновлений, касающихся текущих проблем, ранжированных по серьезности |
Цели контроля
DS 10.1. Выявление и классификация проблем
Реализовать на практике отчетность и классификацию проблем, которые были выявлены в ходе процесса управления инцидентами. Этапы этой работы аналогичны классификации инцидентов; то есть проблемам нужно присвоить категории, определить последствия, срочность и приоритетность. Категорировать проблемы по группам или разделам (например, проблемы в аппаратном обеспечении, программах, поддержке программ). Эти группы должны соответствовать организационным обязанностям пользователей и являться основой для постановки задач перед персоналом службы поддержки.
DS 10.2. Отслеживание и разрешение проблем
Следует убедиться в том, что система управления проблемами обеспечена необходимыми средствами по отслеживанию, анализу и определению первопричин всех выявленных проблем, включая:
Все связанные объекты конфигурации.
Неразрешенные проблемы и инциденты.
Известные и предполагаемые ошибки.
Отслеживание тенденций в проблемах.
Выявить и предложить поддерживающие решения в отношении первопричин проблем, вызывающие запросы на изменения в процессе управления изменениями. Через процесс решения, управление проблемами должно получать регулярные отчеты от управления изменениями по разрешению проблем и ошибок. Управление проблемами предполагает ведение мониторинга постоянного воздействия проблем и выявленных ошибок на сервисы для пользователей. В случае достижения неприемлемого уровня данного воздействия, управление проблемами должно осуществить эскалацию проблемы, возможно повысив ее приоритет или предпринять экстренные изменения. Отслеживать продвижение в решении проблем в рамках соглашений об уровне обслуживания.
DS 10.3. Закрытие проблем
Предусмотреть процедуру окончательного решения проблемы либо после подтверждения о ее успешном устранении либо после соглашения с бизнес пользователями о методах ее альтернативного (обходного) решения.
DS 10.4. Интеграция управления конфигурацией, управления инцидентами и проблемами
Осуществить интеграцию процессов управления конфигурацией, управления инцидентами и проблемами для обеспечения эффективного управления проблемами и совершенствования.
Вспомним пример с обращением насчет неработающего принтера в сервис-деск. Допустим, такая проблема появляется у разных пользователей. Обнаружено, что принтер возобновляет работу после перезапуска. В данном случае перезапуск – обходное решение, но не решение проблемы. Поэтому Вам надо найти истинную причину и устранить ее.
Как и в Управлении инцидентами, Управление проблем имеет ряд задач, которые необходимо выполнить. Ответственные за решение проблем сотрудники (так называемые менеджеры проблем) должны их приоритезировать проблемы по срочности и негативному влиянию на бизнес. Менеджеры проблем назначают сотрудников - владельцев проблем, которые обладают достаточной компетенцией для их решения. Например, для проблем с операционными системами это будет кто-то из администраторов, для проблем с принтерами – кто-то из отдела обслуживания рабочих мест и т.п.
На следующем этапе ИТ-специалист диагностирует проблему и пытается определить первопричину ее возникновения. Например, в случае с принтером это могут быть старые барабаны, недостаток памяти или сломанный порт. После нахождения первопричины ее необходимо устранить – поменять барабан, обновить память и т.п. Многие изменения при этом проходят через процесс Управление внесением изменений. Только после того, как владелец проблемы убедиться, что она действительно устранена и не вызывает больше инцидентов, он может закрыть проблему. Вот так в упрощенном виде выглядит процесс Управления проблемами.
Ключевые термины:
Объект конфигурации или конфигурационная единица (Configuration Item, CI) – компонент инфраструктуры или объект, требующий настроек, связанных с инфраструктурой, которая находится под контролем (или должна находиться под контролем) должностных лиц, ответственных за конфигурацию. Объекты конфигурации могут весьма разниться по сложности, размерам и типам – от целой системы (включающей аппаратную часть, программное обеспечение и документацию) до отдельного модуля или небольшого аппаратного компонента.
Управление конфигурацией (Configuration Management) – управление настройками объектов конфигурации на протяжении их жизненного цикла.
Проблема (Problem) – в ИТ неизвестная причина, лежащая в основе одного или многих инцидентов.
Обходное решение (Workaround) - уменьшение или устранение влияния инцидента или проблемы, для которых в текущий момент недоступно полное разрешение.
База известных ошибок (Known Error Database или KEDB) - база данных, содержащая все записи об известных ошибках.
13.1. DS 9. Управление конфигурацией
Обеспечение целостности аппаратного и программного обеспечения требует создания и поддержки точного и полного хранилища конфигурационных данных. Данный процесс включает в себя сбор первоначальных данных о конфигурации, создание прототипа, проверку и аудит данных о конфигурации, а также обновление хранилища конфигурационных данных по мере необходимости. Объект конфигурации или конфигурационная единица (Configuration Item, CI) – компонент инфраструктуры или объект, требующий настроек, связанных с инфраструктурой, которая находится под контролем (или должна находиться под контролем) должностных лиц, ответственных за конфигурацию. Объекты конфигурации могут весьма разниться по сложности, размерам и типам – от целой системы (включающей аппаратную часть, программное обеспечение и документацию) до отдельного модуля или небольшого аппаратного компонента. Управление конфигурацией (Configuration Management) – управление настройками объектов конфигурации на протяжении их жизненного цикла [1]. Информация о каждом объекте конфигурации регистрируется в форме записи в хранилище конфигурационных данных и поддерживается актуальной в течение всего жизненного цикла процессом Управление конфигурациями.
Для идентификации конфигураций важно:
определить, как будут категорироваться объекты конфигурации;
определить подход к идентификации и наименованию всех объектов конфигурации;
определить роли и ответственности для владельцев объектов конфигурации отдельных типов в рамах этапов жизненного цикла.
Деятельность в рамках идентификации конфигураций включает в себя:
определение и документирование критериев выбора объектов конфигурации и составляющих их компонентов;
выбор объектов конфигурации и их компонентов на основе установленных критериев;
назначение уникальных идентификаторов для выбранных объектов конфигурации;
определение атрибутов для каждого объекта конфигурации;
определение для каждого объекта конфигурации момента, когда он поступает в Управление конфигурациями;
определение владельца, ответственного за каждый объект конфигурации.
Модель конфигураций должна включать в себя связи и позицию каждого объекта конфигурации. Важной частью Управления конфигурацией является определение уровня контроля для каждого объекта конфигурации. Для этого применяется иерархический подход, так как каждый CI может являться частью другого CI или группы CI. Например, база данных может использоваться многими приложениями. Объекты конфигураций нижних уровней не подвержены детальному контролю и аудиту. Например, клавиатуры, используемые в организации, могут послужить примером CI нижнего уровня. Важно отметить, что в зависимости от конкретной организации, критерии выбора CI нижнего уровня отличаются. Например, в здании ООН работает множество людей, говорящих на разных языках. Для их удобства используются разные клавиатуры - с английской, русской, итальянской и другими раскладками. Следовательно, для ООН информация о клавиатурах является относительно критичной и клавиатура как CI не находится на нижнем уровне иерархии.
Всем объектам конфигурации необходимо назначить имена, состоящие из идентификатора и версии. Имена должны быть уникальными. Помимо этого все физическое оборудование должно иметь бирки, по которым их можно будет легко идентифицировать.
В хранилище конфигурационных данных содержаться атрибуты каждого объекта конфигурации. Выделяют следующие стандартные атрибуты:
уникальный идентификатор;
тип CI;
имя/описание;
версия;
расположение;
дата поставки;
детали лицензии ( в частности, дата ее истечения);
владелец/куратор;
статус;
поставщик/источник;
документация;
данные истории, например, аудиторские отчеты;
тип связей;
соответствующий SLA.
Чаще всего характеристики CI содержатся в документации к нему. Связи объектов конфигурации отражают то, как они взаимодействуют друг с другом в процессе предоставления услуг. Информация о связях объектов между собой должна храниться в хранилище конфигурационных данных.
Основные связи между CI:
CI является частью другого CI. Например, сервер является частью инфраструктуры сайта. Это отношение "родитель-ребенок";
CI соединен с другим CI. Например, персональный компьютер соединен с локальной сетью;
CI использует другой CI. Например, программа использует модуль другой программы;
CI установлен на другой CI, например, Windows Excel на персональный компьютер.
CI может иметь множество связей. Например, быть частью другого CI и одновременно использоваться другими CI .
Каждый CI имеет ряд дискретных статусов в рамках своего жизненного цикла. Значимость каждого статуса определяется использованием CI в его рамках.
Учет статусов обеспечивает корректность и актуальность записей об объектах конфигурации, активах и их состояниях. Стандартные деятельности в рамках Учета состояний:
управление записями о конфигурациях в процессе жизненного цикла;
управление записью, восстановлением и объединением статусов с целью обеспечения корректности, безопасности, своевременности и целостности;
обеспечение доступности информации о статусах в рамках Управления конфигурациями;
запись всех изменений в CI.
Запись о конфигурации создается в процессе идентификации и контроля CI. Она обеспечивает прозрачность и трассируемость CI для всех процессов [5].
Эффективное управление конфигурацией обеспечивает большую доступность систем, минимизирует проблемы, связанные с промышленной эксплуатацией систем и ведет к более быстрому решению проблем.
(рис 13.1) Процесс "Управление конфигурацией"
Управление процессом
Управление конфигурацией.
удовлетворяет следующим бизнес требованиям к ИТ
оптимизация ИТ-инфраструктуры, ресурсов и возможностей, учет ИТ-активов. сосредоточено на
создании и поддержке точного и полного хранилища конфигурационных атрибутов ИТ -активов и прототипов, а также на сравнении их с текущей конфигурацией.
достигается с помощью
Создания централизованного хранилища всех объектов конфигурации.
Выявления объектов конфигурации и их поддержке.
Проверки целостности данных о конфигурации.
результаты оцениваются с помощью следующих показателей
Число проблем, связанных с соответствием требованиям бизнеса, вызванных неправильной конфигурацией активов.
Число отклонений, выявленных между конфигурационными данными в хранилище и текущей конфигурацией активов.
Доля приобретенных, но не учтенных в хранилище лицензий.
В таблице 13.1 представлена информация, необходимая для процесса и ее источники.
| Источник | Входящая информация |
|---|
| AI 4 | Пользовательские, операционные, поддерживающие, технические и руководства администраторов |
| AI 7 | Распространяемые объекты конфигурации |
| DS 4 | Критичность объектов ИТ-конфигурации |
В таблице 13.2 приведены результаты процесса и то, куда они должны поступить.
| Результаты | В процессы |
|---|
| ИТ-конфигурация/детализации по ИТ-активам | DS 8 | DS 10 | DS 13 |
| Запросы на изменения (где и как производить исправления) | AI 6 | | |
| Отчеты об эффективности процессов | ME 1 | | |
Таблица 13.3 содержит таблицу ОУКИ для процесса, а таблица 13.4 – цели и показатели.
| Действия\Функции | Президент | Финансовый директор | Высшее руководство | Директор по ИТ | Владелец бизнес-процесса | Руководитель эксплуатации системы | Главный архитектор ИТ-системы | Руководитель разработок | Руководитель администрации ИТ | Руководитель проектного офиса | Аудит, риски, безопасность |
|---|
| Разработать процедуры планирования управления конфигурацией | | | | К | У | У | И | К | | К | О |
| Вести сбор первичных данных о конфигурации и разрабатывать прототипы | | | | | К | У | К | | | И | У/О |
| Осуществлять проверку и аудит данных о конфигурации, в том числе выявление неавторизованного программного обеспечения | | И | | | У | | | И | | И | У/О |
| Обновлять хранилище конфигурационных данных | | | | | О | О | О | | | И | У/О |
| Цели | Показатели |
|---|
ИТ:
Оптимизировать ИТ-инфраструктуру, ресурсы и возможности
Осуществлять учет и защиту всех активов |
число проблем, связанных с соответствием требованиям бизнеса, вызванных неправильной конфигурацией активов |
Процесса:
создать хранилища в отношении всех активов, атрибутов конфигурации и прототипов
поддерживать целостность хранилища конфигурационных данных
изучать текущую конфигурацию активов на предмет соответствия прототипам в хранилище конфигурационных данных |
число отклонений, выявленных между конфигурационными данными в хранилище и текущей конфигурацией активов
доля приобретенных, но не учтенных в хранилище лицензий |
Действия:
создание централизованного хранилища всех объектов конфигурации
выявление объектов конфигурации и их поддержка
проверка целостности данных о конфигурации |
средняя временная задержка между выявлением несоответствия и его исправлением
число несоответствий, относящихся к неполноте или отсутствию данных о конфигурации
доля объектов конфигурации, соответствующих уровням обслуживания по эффективности, безопасности, доступности |
Цели контроля
DS 9.1. Хранилище конфигурационных данных и прототип
Создать средства поддержки и централизованное хранилище, в которое должна помещаться все информация, имеющая отношение к объектам конфигурации. Следует вести мониторинг и учет всех активов и изменений в них. Поддерживать прототипы для объектов конфигурации всех систем и услуг в качестве контрольной точки, к которой можно вернуться после совершения изменений.
DS 9.2. Идентификация и обслуживание объектов конфигурации
Разработать процедуры конфигурации для поддержки управления и документирования всех изменений в хранилище конфигурационных данных. Интегрировать данные процедуры с процессами управления конфигурацией, управления инцидентами и управления проблемами.
DS 9.3. Проверка целостности конфигурации
Периодически проверять конфигурационные данные и подтверждать целостность конфигурации в настоящем и прошлом. Периодически проверять установленное программное обеспечение на предмет соответствия политике использования ПО, либо использования нелицензионного ПО, либо иных случаев использования ПО не в соответствии с условиями контрактов. Следует вести отчетность и предпринимать действия по исправлению ошибок и отклонений.
Рассмотрим диаграмму, на которой изображены компоненты электронной почты (рис.13.2).
(рис 13.2) Компоненты электронной почты
Такое представление может быть полезно:
показать новым администраторам, какие сервера с чем работают (ориентация);
при планировании добавления жесткого диска к серверу 1 узнать, что на нем работает (VM1) и какие услуги будут затронуты (электронная почта). Эта информация полезна для процесса Управление внесением изменений;
если пользователи сообщают, что электронная почта недоступна, служба поддержки знает, что стоит проверить работу приложения на VM1. Эта информация полезна для Управления инцидентами;
если решается вопрос о переносе VM1 с сервера 1 на сервер 2, нужно обсудить изменения в указанной диаграмме в рамках процесса Управление изменениями;
если сервер 1 ломается, нужно связаться с производителем. Контактная информация может быть отображена в диаграмме (Управление инцидентами).
и т.п.
Конечно, на практике хранить такое детальное описание компонентов в виде диаграмм невозможно. В любом случае информацию подобного рода нужно хранить и систематизировать. Это и называется в COBIT хранилищем конфигурационных данных (Configuration Management Database, CMDB). Каждый элемент в хранилище называется Объектом конфигурации. В данном примере сервер 1, VM 1 и электронная почта являются объектами конфигурации.
Каждая организация определяет индивидуально, какую именно информацию хранить в CMDB. Например:
Нужно ли определять, на каком сервере располагается VM1? Представьте себе, что с виртуальной машиной возникли проблемы и нужно проверить каждый сервер организации, чтобы найти ее. Именно поэтому связи объектов конфигурации должны быть обязательно указаны в CMDB.
Нужно ли указывать параметры сервера 1 (частоту процессора, количество памяти и т.п.)? В принципе достаточно легко узнать такую информацию на самом сервере. Хранить ее или нет – решать Вам.
Нужно ли указывать информацию о конфигурации Exchange? Вы можете легко ее узнать, зайдя на VM1. Подобного рода информация может заноситься в CMDB только в ручном режиме, а это сильно усложняет процесс.
Помимо заполнения хранилища важно следить за его актуальностью. Например, в сервис-деск поступила информация о недоступности электронной почты. Специалисты поддержки обратились к CMDB и увидели, что приложение запущено на VM1. Обратились к VM1 , а его там нет. Вот почему крайне важно обновлять информацию в CMDB. Это можно сделать следующими путями:
включить процедуру обновления хранилища в процедуру внесения изменений;
создать процедуру регулярного обзора хранилища на предмет актуальности представленной в нем информации.
Важной задачей в рамках процесса Управления конфигурацией является управление лицензиями. В CMDB важно отобразить не только количество лицензий, но и то, где они установлены. Это поможет выявить излишки или недостаток лицензий, а также нелегальное использование программного обеспечения.
Эффективность деятельности любой организации зависит от того, насколько хорошо она управляет своими активами. Именно работа с активами приносит организации прибыль. Управление конфигурацией ответственно за управление активами с целью поддержки других процессов управления услугами.
DS 10. Управление проблемами
Эффективное управление проблемами требует выявления и классификации всех проблем, анализа их первопричин и последующего их решения. Проблема (Problem) – в ИТ неизвестная причина, лежащая в основе одного или многих инцидентов[1].Процесс управления проблемами также включает в себя формулирование рекомендаций по совершенствованию, поддержке учета проблем и изучение статуса корректирующих действий. Эффективный процесс управления проблемами максимизирует доступность систем, ведёт к повышению уровней обслуживания, сокращению затрат и повышению комфорта и удовлетворенности пользователей. Процесс Управления проблемами тесно связан с процессом Управления инцидентами, так как возникновение инцидентов происходит вследствие наличия проблем. Эти процессы часто используют одни инструменты, системы категорирования и расстановки приоритетов и т.п. Также как и процессы Управления инцидентами и Управления изменениями, Управление проблемами предоставляет ценность для бизнеса тем, что повышает доступность и качество услуг. Если проблема, порождающая инцидент, решена, бизнес выиграет от уменьшения времени простоя услуг и уменьшения негативного влияния на бизнес-системы. Управление проблемами также уменьшает издержки бизнеса на разрешение инцидентов, так как непосредственно уменьшает их количество[5].
(рис 13.3) Процесс "Управление проблемами"
Управление проблемами.
удовлетворяет следующим бизнес требованиям к ИТ
обеспечение удовлетворенности конечных пользователей предложением услуг и уровнями обслуживания, сокращение дефектов и переделок в предлагаемых услугах.
сосредоточено на
Учёте, отслеживании и разрешении проблем в среде промышленной эксплуатации; анализе первопричин всех существенных проблем и определении путей решения выявленных эксплуатационных проблем.
достигается с помощью
Проведения анализа первопричин выявленных проблем.
Анализа тенденций.
Назначения владельцев проблем и интенсификации их решения.
результаты оцениваются с помощью следующих показателей
Число повторяющихся проблем, имеющих последствия для бизнеса.
Доля проблем, решенных в течение определенного периода времени.
Регулярность отчетов или обновлений, касающихся текущих проблем, ранжированных по их серьезности.
Процесс Управления проблемами схематически изображен на рис.13.4. Порядок действий взят из публикаций ITIL, которые также рассматривают этот процесс.
(рис 13.4) Управление проблемами
Первый этап - обнаружение проблемы. Существует множество путей обнаружения проблем, в частности:
обнаружение или "подозрение" причины возникновения одного или более инцидентов от сервис-деска. Сервис-деск может разрешить инцидент, но не выявить его первопричину, что увеличивает вероятность возникновения аналогичных инцидентов в дальнейшем. В этом случае формируется запись о проблеме для поиска основной причины инцидента;
анализ инцидента технической группой поддержки, в результате которого будет выявлено существование проблемы или вероятность ее существования;
автоматическое обнаружение сбоев приложений или компонентов инфраструктуры, которое выявит необходимость создания записи о проблеме;
уведомление о существовании проблемы от поставщика или подрядчика;
анализ инцидентов как часть проактивного управления инцидентами.
После обнаружения проблемы, информацию о ней необходимо занести в лог, то есть сформировать запись о проблеме. Запись о проблеме должна отражать детальное описание проблемы и весь ее жизненный цикл, в частности:
информация о пользователе;
информация об услуге;
информация об оборудовании;
время и дата начала формирования записи;
описание инцидента, который стал результатом существования проблемы;
детальное описание всех деятельностей в рамках решения проблемы.
Для определения приоритета проблемы необходимо также оценить ее "тяжесть" или то, насколько она серьезна для инфраструктуры:
систему можно восстановить или она должна быть заменена?
сколько это будет стоить?
сколько людей и какой квалификации необходимо для решения проблемы?
сколько времени займет решение проблемы?
насколько велик охват проблемы? ( например, сколько конфигурационных единиц она затрагивает)
На следующем этапе проводятся исследование и диагностика проблемы. Целью исследования является поиск первопричины проблемы. Для оценки точки сбоя и определения уровня негативного влияния может использоваться CMDB. База известных ошибок может быть использована для поиска случаев возникновения проблемы в прошлом, и, возможно, ее решения.
Иногда полезным может быть попытка воссоздания сбоя в тестовой среде для выяснения его причины и поиска наиболее эффективного пути ее устранения. Существует множество стандартных техник для анализа, диагностики и решения проблем. Приведем техники, рассматриваемые в публикации ITIL:
хронологический анализ. Когда возникает сложная проблема, могут появиться противоречивые отчеты и сообщения относительно того, что действительно случилось. Для восстановления картины документально фиксируют хронологию всех событий, связанных с проблемой. Это помогает также выяснить зависимости и устранить из цепочки события, которые не относятся к рассматриваемой проблеме.
Анализ потерь (Pain Value Analysis) - методика, используемая для идентификации влияния на бизнес одной или нескольких проблем. Формула расчета потерь основана на количестве затронутых пользователей, продолжительности простоя, влияния на каждого пользователя, и стоимости для бизнеса (если известно).
Анализ Кепнера и Трего - системный подход к разрешению проблем. Проблема анализируется в терминах Что, Где, Когда и Сколько. Определяются возможные причины. Наиболее вероятная причина подвергается проверке. Таким образом определяется истинная причина.
"Мозговой штурм" - методика, которая помогает команде генерировать идеи. При этом идеи не должны критиковаться и анализироваться во время проведения самого Мозгового штурма, это происходит после.
Диаграмма Ишикавы - методика, помогающая команде определить все возможные причины проблемы. Первоначально была разработана Каору Ишикавой (Kaoru Ishikawa), результатом работы этой методики является диаграмма[5]. Основная проблема изображается в виде ствола диаграммы, главные факторы - как ветки, вторичные факторы - как соплодие и т.д. Создание диаграммы стимулирует обсуждение проблемы и более глубокое понимание ее сложности.
анализ Парето - методика отделения значимых причин возникновения проблемы от незначимых. Должны быть предприняты следующие действия:
сформировать таблицу, содержащую причины проблемы и их частоту в процентном соотношении от общего количества случаев возникновения проблемы;
упорядочить строки таблицы в порядке увеличения важности причин;
добавить столбец совокупного процента.
Более понятным анализ Парето будет на примере из публикации ITIL. В таблице 13.5 приведены 10 причин отказа сетевых взаимодействий, то есть "падения сети".
| "Падение сети" |
|---|
| Причины | Процент от общего количества (%) | Расчет | Совокупный процент (%) |
| Сетевой контроллер | 35 | 0+35 | 35 |
| Порча файлов | 26 | 35+26 | 61 |
| Конфликт адресации | 19 | 61+19 | 80 |
| ОС Сервера | 6 | 80+6 | 86 |
| Ошибки скриптов | 5 | 86+5 | 91 |
| Непротестированное изменение | 3 | 91+3 | 94 |
| Ошибки оператора | 2 | 94+2 | 96 |
| Сбой резервного копирования | 2 | 96+2 | 98 |
| Попытки вторжения | 1 | 98+1 | 99 |
| Сбой дисков | 1 | 99+1 | 100 |
Далее необходимо сделать следующие шаги:
создать столбиковую диаграмму причин, расположенных в соответствии с их Процентом от общего количества ( 2 столбец);
наложить линию суммарного процента (4 столбец).
нарисовать линию от 80 % совокупного процента к оси y, параллельно оси x. В точке пересечения с линией суммарного процента "уронить" ее на ось x. Точка оси x, на которую "упадет" линия отделит значимые причины от незначимых.
Диаграмма рассматриваемого примера изображена на рис.13.5.
(рис 13.5) Анализ Парето
Следующий этап - поиск обходного решения. Обходное решение (Workaround) - уменьшение или устранение влияния инцидента или проблемы, для которых в текущий момент недоступно полное разрешение. Например, перезапуск отказавшей конфигурационной единицы или ручное добавление поврежденного файла из резервной копии. Обходные решения являются временными решениями для поддержания работоспособности системы на время поиска решения проблемы. Обходные решения документируются в Базе известных ошибок. База известных ошибок (Known Error Database или KEDB) - база данных, содержащая все записи об известных ошибках. Эта база данных создается в процессе Управления проблемами и используется процессами Управления инцидентами и проблемами.
Как только найдено решение проблемы, его необходимо как можно быстрее реализовать. Тем не менее, важно помнить, что внесение изменений может затронуть другие услуги или конфигурационные единицы. Если необходимо какое-то функциональное изменение, прежде чем его осуществить, надо сформировать Запрос на изменение, который будет обработан в рамках процесса Управления внесением изменений. После того, как все необходимые действия предприняты, проблема устранена, происходит закрытие записи о проблеме, а также всех связанных с ней записей об инцидентах. Перед закрытием необходимо провести проверку (пересмотр) полноты записи о проблеме - она должна содержать детальное описание всех осуществленных процедур и действий. Для значительных проблем, которые считаются таковыми в соответствии с системой приоритетов конкретной организации, проверка должна быть более детальной, в частности рассматривать такие вопросы как:
что сделано правильно в отношении проблемы;
что сделано неправильно в отношении проблемы;
что может быть сделано лучше в будущем;
как предотвратить повторение проблемы;
были ли задействованы третьи стороны.
На практике редко встречаются приложения, системы и релизы программного обеспечения, не имеющие ошибок. В идеальном случае все они обнаруживаются на этапе тестирования. Тем не менее, ошибки могут не проявится или быть незамеченными и , таким образом, "просочиться" на этап эксплуатации.
В таблице 13.6 представлена информация, необходимая для процесса и ее источники.
| Источник | Входящая информация |
|---|
| AI 6 | Авторизация изменений |
| DS 8 | Отчеты об инцидентах |
| DS 9 | Детальная ИТ-конфигурация, ИТ-активы |
| DS 13 | Протоколы ошибок |
В таблице 13.7 приведены результаты процесса и то, куда они должны поступить.
| Результаты | В процессы |
|---|
| Запросы на изменения (где и как осуществлять исправления) | AI 6 |
| Протоколы проблем | AI 6 |
| Отчеты об эффективности процессов | ME 1 |
| Выявленные проблемы, ошибки и временные способы их решения | DS 8 |
Таблица 13.8 содержит таблицу ОУКИ для процесса, а таблица 13.9 – цели и показатели.
| Действия\Функции | Президент | Финансовый директор | Высшее руководство | Директор по ИТ | Владелец бизнес-процесса | Руководитель эксплуатации системы | Главный архитектор ИТ-системы | Руководитель разработок | Руководитель администрации ИТ | Руководитель проектного офиса | Аудит, риски, безопасность |
|---|
| Выявлять и классифицировать проблемы | | И | И | К | У | К | К | | | И | О |
| Провести анализ первопричин | | | | | К | | К | | | | У/О |
| Разрешить проблемы | | | | К | У | О | О | | О | К | К |
| Отслеживать статусы проблем | | И | И | К | У/О | К | К | | К | К | О |
| Предложить рекомендации по улучшению и создать запросы на изменения | | | | И | У | И | И | | И | | О |
| Поддерживать протоколы проблем | | | | И | И | | И | | | И | У/О |
| Цели | Показатели |
|---|
ИТ:
обеспечить удовлетворенность конечных пользователей предложением услуг и уровнем обслуживания
сократить дефекты и переделки в решениях и предлагаемых услугах
обеспечить достижение целей ИТ |
число повторяющихся проблем, имеющих последствия для бизнеса
число прерываний бизнеса, вызванных эксплуатационными проблемами |
Процесса:
вести учет и отслеживать эксплуатационные проблемы до их решения
анализировать первопричины всех существенных проблем |
доля зафиксированных и отслеженных проблем
доля повторяющихся проблем (в течение периода времени) по их серьезности
доля проблем, решенных в течение требуемого периода времени
число открытых/новых/закрытых проблем по их серьезности
среднее и стандартное отклонение от временной зарежки между выявлением проблемы и ее решением
среднее и стандартное отклонение от временной задержки между решением и закрытием проблемы |
Действия:
наделение менеджера по решению проблем достаточными полномочиями
проведение анализа первопричин выявленных проблем
анализ тенденций
назначение владельцев проблем и интенсификации их решения |
средняя продолжительность времени между фиксацией проблемы и выявлением ее первопричин
доля проблем, по которым первопричины не выявлены
регулярность отчетов или обновлений, касающихся текущих проблем, ранжированных по серьезности |
Цели контроля
DS 10.1. Выявление и классификация проблем
Реализовать на практике отчетность и классификацию проблем, которые были выявлены в ходе процесса управления инцидентами. Этапы этой работы аналогичны классификации инцидентов; то есть проблемам нужно присвоить категории, определить последствия, срочность и приоритетность. Категорировать проблемы по группам или разделам (например, проблемы в аппаратном обеспечении, программах, поддержке программ). Эти группы должны соответствовать организационным обязанностям пользователей и являться основой для постановки задач перед персоналом службы поддержки.
DS 10.2. Отслеживание и разрешение проблем
Следует убедиться в том, что система управления проблемами обеспечена необходимыми средствами по отслеживанию, анализу и определению первопричин всех выявленных проблем, включая:
Все связанные объекты конфигурации.
Неразрешенные проблемы и инциденты.
Известные и предполагаемые ошибки.
Отслеживание тенденций в проблемах.
Выявить и предложить поддерживающие решения в отношении первопричин проблем, вызывающие запросы на изменения в процессе управления изменениями. Через процесс решения, управление проблемами должно получать регулярные отчеты от управления изменениями по разрешению проблем и ошибок. Управление проблемами предполагает ведение мониторинга постоянного воздействия проблем и выявленных ошибок на сервисы для пользователей. В случае достижения неприемлемого уровня данного воздействия, управление проблемами должно осуществить эскалацию проблемы, возможно повысив ее приоритет или предпринять экстренные изменения. Отслеживать продвижение в решении проблем в рамках соглашений об уровне обслуживания.
DS 10.3. Закрытие проблем
Предусмотреть процедуру окончательного решения проблемы либо после подтверждения о ее успешном устранении либо после соглашения с бизнес пользователями о методах ее альтернативного (обходного) решения.
DS 10.4. Интеграция управления конфигурацией, управления инцидентами и проблемами
Осуществить интеграцию процессов управления конфигурацией, управления инцидентами и проблемами для обеспечения эффективного управления проблемами и совершенствования.
Вспомним пример с обращением насчет неработающего принтера в сервис-деск. Допустим, такая проблема появляется у разных пользователей. Обнаружено, что принтер возобновляет работу после перезапуска. В данном случае перезапуск – обходное решение, но не решение проблемы. Поэтому Вам надо найти истинную причину и устранить ее.
Как и в Управлении инцидентами, Управление проблем имеет ряд задач, которые необходимо выполнить. Ответственные за решение проблем сотрудники (так называемые менеджеры проблем) должны их приоритезировать проблемы по срочности и негативному влиянию на бизнес. Менеджеры проблем назначают сотрудников - владельцев проблем, которые обладают достаточной компетенцией для их решения. Например, для проблем с операционными системами это будет кто-то из администраторов, для проблем с принтерами – кто-то из отдела обслуживания рабочих мест и т.п.
На следующем этапе ИТ-специалист диагностирует проблему и пытается определить первопричину ее возникновения. Например, в случае с принтером это могут быть старые барабаны, недостаток памяти или сломанный порт. После нахождения первопричины ее необходимо устранить – поменять барабан, обновить память и т.п. Многие изменения при этом проходят через процесс Управление внесением изменений. Только после того, как владелец проблемы убедиться, что она действительно устранена и не вызывает больше инцидентов, он может закрыть проблему. Вот так в упрощенном виде выглядит процесс Управления проблемами.
Ключевые термины:
Объект конфигурации или конфигурационная единица (Configuration Item, CI) – компонент инфраструктуры или объект, требующий настроек, связанных с инфраструктурой, которая находится под контролем (или должна находиться под контролем) должностных лиц, ответственных за конфигурацию. Объекты конфигурации могут весьма разниться по сложности, размерам и типам – от целой системы (включающей аппаратную часть, программное обеспечение и документацию) до отдельного модуля или небольшого аппаратного компонента.
Управление конфигурацией (Configuration Management) – управление настройками объектов конфигурации на протяжении их жизненного цикла.
Проблема (Problem) – в ИТ неизвестная причина, лежащая в основе одного или многих инцидентов.
Обходное решение (Workaround) - уменьшение или устранение влияния инцидента или проблемы, для которых в текущий момент недоступно полное разрешение.
База известных ошибок (Known Error Database или KEDB) - база данных, содержащая все записи об известных ошибках.
