апрель    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

показать все 

18.04.2024

Ассоциация разработчиков «Отечественный софт» отметила 15-летие

Читать далее 

17.04.2024

РДТЕХ представил Технологическую карту российского ПО 2023

Читать далее 

16.04.2024

RAMAX Group получила партнерский статус уровня Gold по продукту Tarantool

Читать далее 

12.04.2024

На RIGF 2024 обсудили ключевые вопросы цифрового развития России

Читать далее 

показать все 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

18.04.2024

Цифровая трансформация в энергетике: как запустить проект с максимальным финансовым эффектом?

Читать далее 

05.04.2024

Мотивируй, не то проиграешь!

Читать далее 

22.03.2024

В 2024 году в России и мире вырастут объемы применения AR/VR 

Читать далее 

25.02.2024

Цифровые технологии: надежды и риски

Читать далее 

05.02.2024

Будут ли востребованы услуги технической поддержки софта Oracle в России в ближайшие годы?  

Читать далее 

31.01.2024

Здания с признаками интеллекта. Как Сергей Провалихин автоматизирует дома и производства

Читать далее 

показать все 

Главная / Архив номеров / 2017 / Выпуск №09 (72) / Воткните вилку в розетку. Проактивное управление проблемами

Рубрика: ИТ-процессы

Марина Аншина, президент Фонда ФОСТАС, председатель правления Российского Союза ИТ-директоров

Воткните вилку в розетку
Проактивное управление проблемами

В быту понятия «инцидент» и «проблема» часто взаимозаменяемы и означают – что-то пошло не так. Хотя на интуитивном уровне большинство чувствует: проблема – это что-то более серьезное, чем инцидент

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

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

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

Но вернемся к ITIIL, в соответствии с которым проблема – это корневая причина одного или нескольких инцидентов. Если что-то пошло не так, то первое и естественное побуждение вернуться к нормальному состоянию, т.е., говоря языком ITIL, восстановить работоспособность сервисов ИТ в соответствии с SLA.

Это как если младенец кричит, то надо сделать так, чтобы он кричать перестал и начал улыбаться. В нашем случае в качестве младенцев предстают наши пользователи, радость которых от использования ИТ нам хочется восстановить какможно скорее. А уже потом разбираться в том, «животик» ли у них болел или «зубки» резались. И, конечно, принять меры, чтобы облегчить их страдания от повторного возникновения проблемы, закупив необходимые «лекарства».

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

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

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

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

Рисунок 1. Блок-схема процесса управления проблемами

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

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

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

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

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

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

Кроме того, могут использоваться такие параметры, как:

• Может ли сервис быть восстановлен или требуется замена его компонентов?
• Какие затраты потребуются для уст-ранения проблемы, в том числе на оплату привлечения высококвалифицированного персонала?

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

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

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

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

• Общее описание проблемы.
• Описание проблемы в терминах наименования, местоположения времени и размера, что позволяет отобразить ее системно, с разных сторон.
• Выявление возможных причин.
• Проверка наиболее возможной причины.

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

5. Диаграмма Ишикавы. Каори Ишикава – признанный лидер в области управления качеством, разработал причинно-следственный метод анализа проблем. Принцип метода отображен на рис. 2.

Рисунок 2. Диаграмма Ишикавы

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

6. Метод Парето. Этот метод основан на общеизвестном принципе Парето, который в приложении к проблемам гласит, что 80% проблем порождаются 20% возможных причин. Для использования метода Парето надо создать таблицу 1, пример которой приведен ниже.

Таблица 1. Анализ сетевых ошибок по методу Парето

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

Рисунок 3. Существенные и малосущественные причины возникновения проблемы

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

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

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

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

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

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

• Что было выполнено правильно?
• Что было сделано неверно?
• Что можно сделать лучше в будущем?
• Как предотвратить повторение возникновения проблемы?
• Привлекались ли сторонние исполнители к устранению проблемы и надо ли что-то изменить во взаимоотношениях с ними?

К сожалению, проактивное управление проблемами не получило в ITIL должного внимания. Рискну высказать собственные предположения о причинах такой странной забывчивости. Мой опыт работы в западных компаниях показывает, чтолюбое изменение там требует четкого обоснования. То есть не принято заранее устранять проблемы исходя из предположений о возможности их будущего возникновения. Упор делается на обоснованности затрат.

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

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

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

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи