Проблем-менеджмент отвечает за поиск, идентификацию, оценку

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

Обычно, к управлению неуввязками перебегают после внедрения функции Service Desk и процесса управления инцидентами [DM №5], таковой подход является традиционным и обычным. Оба процесса по требованиям эталона ISO/IEC 20000 объединены в группу процессов решения, в связи с этим проясним понятия и определим отличия управления инцидентами от управления неуввязками.
Управление неуввязками отличается от управления инцидентами в собственной основной цели – определение коренных обстоятельств инцидентов и их следующее разрешение и предотвращение. В почти всех ситуациях цель управления неуввязками может быть в прямом конфликте с целью управления инцидентами, т.к. целью управления инцидентами является более резвое восстановление услуг, предоставляемых заказчику, нередко по средствам нахождения обходных решений, а не определения неизменного разрешения.
Исходя из вышесказанного, скорость, с которой неувязка будет разрешена, находится на втором месте по значимости.
Расследование корневой трудности может востребовать некое время и может задерживать восстановление услуги, приведя к простоям, но предотвращая повторение инцидентов.

В среде эксплуатации возникновение определенного количества инцидентов безизбежно.
В компьютерном оборудовании и телекоммуникационных каналах временами появляются сбои. Например, разглядим некоторый сервис, у которого есть два состояния – обычная работа и отклонение от нормы.
Обозначим эти периоды как uptime и downtime соответственно, разглядим эти обозначения очень обширно (соответствует норме – не соответствует).

Рис.1 – Жизнь сервиса во времениКак видно из представленного рисунка, поставщик сервиса стремится уменьшить время downtime и обеспечить наивысшую продолжительность uptime.
Многие хостинговые компании в рекламных целях указывают 100% uptime, что не совершенно правильно, так как кроме вероятных сбоев, в дата-центрах производятся плановые работы, которые способны ограничить доступ к сервису. Основая задачка – это очень уменьшить время downtime, чтоб юзеры не ощутили заморочек с сервисами.
Поглядим на задачку обеспечения надежности чуток обширнее и увидим, что для того, чтоб сервисное решение подольше работало «правильно», нужно, чтоб это решение было подходящим образом спланировано и спроектировано, выстроено на базе надежных компонент, корректно протестировано, описано и передано в эксплуатацию, а там корректно сопровождалось, поддерживалось и потреблялось. Если перечисленные задачки выполнены отлично и согласовано – возможность наличия в инфраструктуре ошибок и, как следует, появления инцидентов, будет относительно низкой.
На практике все смотрится далековато не наилучшим образом, разработчики, проектировщики и внедренцы поработали так, как смогли осознать друг дружку, поначалу при передаче сервиса в эксплуатацию перебежало некое количество ошибок, потом в среде эксплуатации наплодили некое количество ошибок, которые временами появляются в форме инцидентов.
Чем ужаснее связь меж компонентами разработки и эксплуатации, тем нужнее проблем-менеджмент. С другой стороны, чем лучше связь меж ними, тем больше шансов, что в этом процессе мы сможем что-то делать.
Проблем-менеджмент отвечает за поиск, идентификацию, оценку, контроль и попытку исправления этих ошибок.
За uptime отвечает достаточное количество людей, задачка которых безошибочно выполнить работу на собственных шагах и не допустить переход ошибок от 1-го уровня к другому, т.к. за downtime отвечает только проблем-менеджер,  у которого не настолько не мало времени, чтоб убрать ошибки в среде эксплуатации. Для управления неуввязками, обычно, употребляется подход основанный на принципах ITIL, которые предполагают внедрение проактивного и реактивного управления неуввязками.

Обычный реактивный подход

Данный подход применяется в большинстве компаний.
Он основывается на ситуациях, когда проблема уже произошла, и она довольно суровая, потому юзер обращается в IT. В таком случае данные об инциденте обычно являются личными, так как они основаны на личном восприятии ситуации юзером и сотрудником поддержки.
Если появляется несколько подобных инцидентов, которые верно зафиксированы, IT может начать расследование трудности, сначало основываясь на собранных личных данных.
Очередной недочет использования только реактивного подхода – не всегда юзеры докладывают о дилеммах. Появляются ситуации, когда юзеры испытывают некие трудности с работой системы, действующие на их продуктивность, но не докладывают об этом.
В итоге это выливается в формирование негативного представления об IT посреди служащих, хотя IT ничего не понимало об этих дилеммах, так как фокус ориентирован на инциденты, о которых сообщается. Процесс контроля заморочек в данном случае состоит из 3-х шагов:идентификация и запись трудности;систематизация трудности – исходя из убеждений воздействия на бизнес;расследование и диагностика трудности.

Рис.2 – Контроль заморочекПроактивный (превентивный) подход

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

Рис. 3 - Процесс проактивного проблем-менеджмента.Разглядим более детально процесс управления неувязкой.Сбор. Идет работа по сбору для следующего анализа всей доступной инфы, относящейся к данной дилемме.
Эти данные могут размещаться на тыщах ПК, потому для этого требуются разные инструменты. Вся собранная информация собирается в единую базу данных.Анализ. Дальше идет анализ собранных данных с целью выявить причину появления трудности.

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

Применяемый подход позволил понизить число инцидентов на 35% за отчетный год.

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

ISO/IEC 20000-1:2005 Информационные технологии – управление услугами.
Общие положения и словарь.ISO/IEC 20000-2:2005 Информационные технологии – управление услугами. Практическое управление.

Бибилиотека ITIL. Service Support.IT Expert. Управление неуввязками – еще проактивнее. http://www.itexpert.ru/

IT@Intel White Paper.
  Improving Client Stability with Proactive Problem Management