5. УПРАВЛЕНИЕ т>овле.МАМИ

Идентификация и регистрация проблемы

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

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

Деятельность по «иде1гти(})икации проблем» часто выполняют Координаторы проблем. Однако бывает так, что персонал, изначально не повлеченный в эту работу, например, специалисты по Управлению Мощиостялш, тоже можеч- выявлять проблемы. Такие «находки» также следует регистрировать как проблемы.

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

•Анализ 1гнфраструктуры позволил определить ее слабые места, где могут произойти повысинци-ДС1ГГЫ (возможно, это проводилось средствами Процессов Управления Доступностью и Унравле-1ГИЯ ]У1ои(ностями).

•Произошел серьезный иштдеит, требующий структурного решения для предотвраи1ения его повторения в будущем.

•CyuiecTByeT угроза срыва Уровня Услуг, согласоваггиого с заказчиком (по показателям производительности, мопиюсти ИТ-средств, затрат и т. д.)

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

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

Анализ тенденций позволяет обнаружить области, которым требуется особое внимание. Необходн-мг>1е для этого дополнительные ресурсы нужно обосновать с позиции издержек и выгод для организации. Паприме]), определить области, которым требуется более действенная поддержка, и понять, насколько они важны для предоставляемых услуг

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

•издержки, которые несет бизнес из-за инцидешов;

•ко;тчсство инцидентов;

•количество пользователей и бизнес-процессов, затронутых инцидентами;

•время и затраты на разрептение иншгдентов.

Классификация и назначение

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

Ютассификацня проблемы включает в себя следующее:

•Категория: определение области, например, программное или аппаратное обеспечение;

•Степень воздействия па бизнес-процесс;

•Срочность: допустимая задержка в решешт проблемы;

ми и оиснки внесенных нзмене1ии"1 с помощью Анализа результатов внедрения (PIR). В рамках Контроля оишбок осуществляется деятельность по мо1П1Торингу всех известных онп1бок с момента их идентификании и до устранения. К работе по Контролю оиитбок привлекаются многие подразделения, как из операционной среды, так и из среды разработки.

Контроль проблем

Идентификация и регистрация известных ошибок

База Данных пробле/.i

Поиск решения

Описание выбранного решения

Запрос на изменение

f Управление Л I Изменениями J

Оценка проблемы/ анализ peiyAbiaToa внедрения

Изменение выполнено?

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

База Данных проблем

Рис. 5.5. Контроль ошибок

(ИСТОЧНИК: OGC)

Идентификация и регистрация ошибок

После определения причины проблемы и связанной с ней Конфигуратцонной Единицы, проблеме присваивается статус «Известной онпгбки» и начинается деятельность по Контролю онгибок. Во многих случаях уже имеется обходное ренгение для проблемы, даже если оишбка найдена самими разработчиками. Но в некоторых случаях обходное решение нужно найти, а затем передать его в Процесс Ун[)авления Инцидентами, если там еще имеются открытые итцданты. Это обходное решение также можно исиользовать во время сопоставления инцидентов.

Поиск [)ен1ения

Персонал, участвуюп1ий в Унравлснии Проблемами, определяет, что необходимо сделать для разре-н1е1П1я известной ошибки. Снециалисты сравнивают различные решения, нртнп1мая во внимаггис Со-глатнсиия об Уровне Услуг (SLA), возможные издержки и выгоды. Они определяют степень влияния и срочность Запросов на Изменения. Все работы 1Ю выработке решения должны быть зафиксированы в системе, у не1х;онала должны быть средства для мониторинга проблем и определения их стат)са.

Срочное исправление

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

Определение окончательного решения

На пре;п>1дущих этапах происходит выбор оптимального регпения. Однако может быть пр1Н1ЯТ0 ре-lueiHie пе исправлять известную ошибтсу, например, по причине экономической нецелесообразности.

г е. во время сопоставления новых инцидентов с известными сшибками. - Прим. ред.

Например, колишипя, у которой есть проблемы с собстг)енными разработками системы KRI, ириос-тапавливаег любые исправления кодов существующей системы, так как принято стратегическое решение о переходе на SAP к концу года. В этом и других аналогичных случаях полученные преимущества не перевенн1вают затраты на нсправле]1ия. Или же в другом случае степень воздействия онтбки может оказаться приемлемой, шипщеит может оказаться легким для исправления или же вероятность его повторения невысока. В некоторых случаях исправление известно!! ошибки вообще невозможно без приложения усилий, песоразмергплх проблеме. Но какое бы решение не было принято, оно должно быть отражено в системе, чтобы его мож1го бглло испол1хЗовать в Процессе Управ-лешш Инцидентами.

После оконча1И!я этапа выбора существует достаточно и!1формации для подачи Запроса на Измепе-!i!ie. Далее исправление известной ош1!бки будет произведено в рамках Процесса Управления Изменениями.

Анализ рез5льтатов внедрения (PIR)

Изменение, предназначенное для устранения известной ошибки, должно быть рассмотрено при анализе результатов внедрения до закр1лтия проблемы. Если изменение дало ожидаемый результат, проблема может быть закрыта, и в базе дап1И>гх о проблемах ее статзс будет изменен на статус «решена». Управление Инцидентами будет проинформировано об этом и нтгциденты, ошзаниые с этой проблемой, тоже мо!7т быть загсрыты.

Примтапие: Во многих организациях процесс реализован таким образом, что проблема закрывается то.1ько после того, как будут закрыты связанные с ней инциденты (и закрытие проверено заказчиком), иначе если инщшенттл не удается закрыть, то проблему бздет необходимо открьпшть снова.

Отслеживание и мониторинг

Данная задача предполагает выполнение мониторинга хода работ но разрешеГшю проблем и известных ошибок на всех этапах Контроля проблем и Контроля ошибок. Цели состоят в следу!0!цем:

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

•Вести мониторинг процесса выработки и реа;п1заци1г решения и 1«л1тролировать правильность исполнения Запроса на Изменение. По этой причине Управление Изменениями ре17ляр!10 передает итгформацию о состоятги Запросов на Изменение в Контроль ошибок.

Предоставление информации

В течение всего процесса информация об обходных решениях и быстрых исправлениях передается в Управление И1Щ11де1гтами. Пользователи также могут и1!формироваться об .этом. Хотя данные предоставляет Процесс Управления Проблемами, их распростране)и-1ем занимается Служба Service Desk. Управлетгие Проблемами использует Кон()нгурацпонпую Базу Данных, а также Соглашения об Уров1ге Услуг, для уточнения, какую информацию и кому следует предоставлять.

5.4.3. Проактивное Управление Проблемами

Проактив1!ое Унравление Проблемами (т. е. предупреждающее появление проблемы) имеет дело с вопросами !сачества инфраструктуры. Оно сосредоточено па анализе тендешщй и выявлении нотен-ттальных угроз ишшдентов до того, как они 1!роизо11дут. Это достигается путем изуче!1ия слабых и перегрзжешплх компонентов инфраструктуры. Еат таких областей несколько, тогда делается !!о-пытка предотвращеггия появления в них ошибок, которые наблюдались в других местах. Слабые места и!!фраструктуры должны быть выявлешл и изучены.

Post Implementation Review - PIR