gifts2017

Почему инциденты – это полезно, и как их правильно готовить

Опубликовал Илья Козлов (Dem1urg) в раздел Управление - Управление проектом

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

Что такое инцидент? Как взаимосвязаны изменения и инциденты?

Для начала давайте разберемся в том, что же такое инцидент.

  • Если переводить с латыни буквально, слово incidens – это «падающий». Это вполне актуально для IT– периодически «падает» софт, «падают» сервера.
  • Если обратиться к толковому словарю Ушакова, то инцидент – это недоразумение, неприятное происшествие.
  • А мы для себя сформулировали такое определение:
    «Инцидент – это любой сбой в нормальном течении процесса» - вообще любой сбой.
  • И одновременно с этим инцидент – это немаловажный источник знаний о несовершенстве процесса, то, что позволяет нам понять, что что-то пошло не так, увидеть проблему (узнать о ее существовании) и попытаться ее решить.

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

Что такое изменения?

  • Это любые действия, направленные на преобразование технологии, конструкции, инфраструктуры или порядка выполнения любых видов работ.
  • Изменения в любом случае необходимы. Если ничего не менять – это прямой путь «в никуда», к завершению, к закрытию бизнеса – нельзя оставаться на одном месте. Мир вокруг нас меняется, конкуренты не спят, нужно всегда двигаться вперед, нужно постоянно меняться.
  • Но одновременно с этим любое изменение – это источник инцидентов, потому что что-то начинает делаться не так, как раньше.

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

Процесс управления инцидентами

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

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

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

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

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

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

Почему мы выбрали именно такую реализацию для процесса? На самом деле – это частности, потому что не так важно, каким образом процесс работает: он может вестись на бумаге, в Excel, на корпоративном портале, в 1С, на любой другой системе – главное, чтобы процесс работал. Просто когда все данные находятся в автоматизированной системе – это удобно.

Регистрация и купирование инцидентов

По поводу регистрации инцидентов.

Первое (и самое сложное), с чего нужно начать,  – это начать регистрировать инциденты.

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

Следовательно, нужно прививать культуру регистрации инцидентов: у сотрудников должен быть рефлекс " инцидент произошел -> его нужно зарегистрировать".

С чем мы столкнулись? Оказалось, что инциденты, произошедшие в смежных подразделениях, люди регистрировали достаточно охотно, потому что «это не я виноват, это они накосячили», а инциденты, произошедшие в зоне своей ответственности, регистрировать не хотели, потому что для этого нужно было признать что есть проблема. Вместо этого сотрудники пытались как-то спрятать инцидент, "не выносить сор из избы" и пр.

Каким образом мы с этим боролись?

  • Здесь важный момент – для того, чтобы процесс работал хорошо, качественно – инциденты должны регистрироваться на всех уровнях – не только на уровне высшего руководства (генерального, функционального директоров, линейных руководителей). Процесс заработает по-настоящему хорошо только тогда, когда инциденты будут регистрировать все, вплоть до рядовых сотрудников.
  • Во-вторых, должны быть созданы списки значимых инцидентов для каждой должности подразделения – это те инциденты, которые подлежат обязательной регистрации – хочешь ты или не хочешь, их нужно регистрировать.
    Что это может быть?
    Инцидент может иметь общий характер. Например, промышленная компания выпускает какой-то серийный продукт, и по результатам его приемо-сдаточных испытаний в произведенной серии продукции выявляется массовый брак. Это всегда инцидент. Причем, в зависимости от масштаба проблемы один и тот же инцидент может быть транслирован на разные уровни:
    •  Например, выявление массового брака в серийно производимой продукции свыше 3% – это инцидент уровня генерального директора, который требует полной остановки конвейера, полноценного расследования и выяснения причин.
    • А тот же самый инцидент, но с процентом брака более 1%, но менее 3 %– уже относится к уровню директора по качеству или начальника ОТК (то есть, генеральный здесь еще не подключается). Инцидент такого уровня в целом будет возникать чаще, чем на уровне генерального.
    • А инцидент уровня конкретного контролера ОТК – это, например, выявление более 10 приборов в партии или более 3 приборов подряд.

Здесь суть не в конкретных цифрах, а в самом подходе – инцидент может быть одного плана, но в зависимости от тяжести его последствий его нужно рассматривать на разных уровнях. И если на самом нижнем уровне (уровне простого персонала) он может быть просто купирован, то на верхнем уровне он обязательно должен быть расследован, потому что если инцидент дошел до такого уровня, значит проблема есть и она носит системный характер. И если не найти её причину инцидент будет повторяться вновь и вновь.
Списки инцидентов должны быть у всех руководителей – от уровня генерального директора до линейных руководителей и начальников отделов.

  • У каждой зоны ответственности должны быть свои списки инцидентов:
    • Для IT туда может входить, например, сбой в работе серверного оборудования или недоступность информационной системы.
    • Для уровня директора по IT – недоступность информационной системы более одного часа в рабочее время.
    • Для начальника отдела сисадминов это может быть вообще любой сбой в работе оборудования, даже если этот сбой не привел ни к каким проблемам для бизнеса (даже если, например, просто не отработал регламент резервного копирования в ночное время). Выяснять причины нестабильности работы оборудования необходимо в любых случаях, поэтому инцидентом этой зоны ответственности должно быть любое отклонение.
  • В первую очередь в эти списки нужно вносить те инциденты, которые имеют наиболее серьезные последствия для бизнеса – с этогонужно начать. Конечно, пока люди сами к этому еще не готовы, им необходимо дать толчок, каким-то образом их заставить – ввести специальный регламент для регистрации инцидентов. А когда процесс пойдет, это давление можно ослабить.
  • Значимые инциденты регистрируются абсолютно всегда. Лучше, если система учета инцидентов автоматизирована и связана с системами оперативного управленческого учета, потому что тогда можно будет настроить какие-то триггеры, какие-то события, по которым регистрация будет происходить полностью автоматически.
  • Следующий момент – купирование инцидента. После того, как инцидент зарегистрирован, его нужно купировать. Здесь все просто: если произошел пожар – его нужно потушить. Если остановился конвейер – его нужно запустить. Все остальное нужно отложить «на потом».
    Поэтому первое, что мы должны сделать, – это устранить сам инцидент и его непосредственную причину, затем необходимо восстановить нормальное течение процесса, а сразу после того, как течение процесса восстановлено, нужно приступить к расследованию инцидента.

У нас в системе форма регистрации инцидента выглядит так, как показано выше.

Расследование инцидентов

Теперь о том, что касается расследования инцидента.

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

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

Так нельзя, это не будет работать – нужно обязательно создать рабочую группу, в которую будут входить сотрудники из разных подразделений:

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

Количество людей в такой группе должно быть 5-6 человек – больше не нужно, иначе эффективность начнет падать.

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

Инструменты для расследования инцидентов

Какие есть инструменты для выявления причин инцидентов?

Инструментов, в принципе, достаточно много. Но я вам расскажу про те, которые показали эффективность по нашему опыту внедрения. Это:

  • Инструмент «Пять почему»
  • Диаграмма Исикавы
  • И принцип Парето

Про каждый из них - чуть подробнее.

5 «почему»

Что такое «5 почему»?

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

Диаграмма Исикавы

Диаграмма Исикавы – это, по сути, те же самые «5 почему», только усложненный вариант.

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

Как ее использовать? Рисуем квадратик, в котором коротко сообщаем суть инцидента, и от него начинаем рисовать вот такую диаграмму (она еще называется «рыбья кость»), на каждой линии которой мы будем размещать вот эти «5 почему», группируя их причины по зонам.

Принцип Парето

А принцип Парето, я думаю, и так уже многим известен: 80% результата можно получить, приложив 20% усилий, а оставшиеся 80% усилий дадут только 20% результата.

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

Классификация причин инцидентов.
Корневые причины и корректирующие мероприятия – взаимосвязь с регламентом

Сами причины инцидента делятся на три группы – корневые, сопутствующие и непосредственные. Что здесь важно?

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

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

Что здесь поможет?

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

  • Ситуация может быть такая – есть регламент, в котором написано, как делать. Люди обучены и действовали в соответствии с регламентом. Но инцидент возник. Значит, регламент неправильный.
  • Если регламента нет вообще – люди как-то делают, но это их внутреннее тайное знание. Значит, причина – это отсутствие регламента (люди не знают, как делать правильно).
  • И третий вариант – это когда и регламент есть, и люди обучены, и регламент правильный, но инцидент все равно произошел. Значит, эти люди регламент нарушили.

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

Акт расследования

Как произвести расследование и правильно составить акт?

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

Процесс внедрения корректирующих изменений

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

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

Как правильно внедрять те корректирующие мероприятия, которые были запланированы?

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

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

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

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

Какие здесь могут быть причины?

  • Собственно, с чего все началось? С того, что на складе были обнаружены приборы, которые отгружать нельзя.
  • Что произошло дальше (точнее, чего не произошло)? Эти приборы не были физически изолированы, не были как-то промаркированы – их нужно было забрать, увезти, наклеить на них красные ярлычки – этого сделано не было.
  • Что дальше? В учетной системе не была произведена процедура блокировки – ни физически на складе, ни в учетной системе не заблокировали.
    • Вопрос – почему не заблокировали в учетной системе? А потому, что нет в учетной системе режима блокировки, потому что приборы данного типа нужно было заблокировать не все (там их несколько типов было – это не конкретный артикул номенклатуры был, а это была целая серия артикулов, причем только произведенные после определенной даты) – такого режима не было.
    • Дальше вопрос – почему не была проведена блокировка запланированной отгрузки? – потому что конструкторы не могут останавливать ни отгрузку, ни производство: нет у них такого режима, когда конструктор при выявлении ошибки может дать команду на остановку конвейера.
    • Почему не была проведена физическая изоляция приборов? Потому что не было выполнено указание конструкторов, содержащее команду на эту изоляцию.
    • А почему оно не было выполнено? Потому что оно пришло по электронной почте, да еще и оказалось, что в нем содержались не окончательные указания, а всего лишь их проект, и поэтому исполнитель приборы все-таки заблокировал, но не те.

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

Заключение

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

Как с этим бороться и наш опыт того, как мы с этим боролись, я уже рассказал.

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2015 CONNECTION 15-17 октября 2015 года.

Приглашаем вас на новую конференцию INFOSTART EVENT 2016 DEVELOPER.

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Евгений Биккулов (ihtiking) 03.08.16 11:18
Автору большое спасибо за труд публикации статьи, но как то уж надоели эти "ГрафикиДиаграммыРасчётыАнализРегистрацияДетализация и прочее". Всё равно всё сводится к простой формуле: Есть проблема, пиши код и решай её.

Аналитика по типовым причинам, приводящие к инцидентам, может дать только количественную оценку. Например, косяк программиста - 100 случаев, косяк бухгалтерии - 200 случаев. Только вот НА БУДУЩЕЕ предупреждать данные инциденты эта информация не поможет. Программисты приходят\уходят в\из компании. Всю историю не изучишь....
2. Виталий Попов (Сурикат) 03.08.16 18:40
Монументально!
Основная проблема такого подхода очень большая инерционность в принятии корректирующих мер. И их накопление в гигантские кипы инструкций, которые никто не соблюдает.
3. Илья Козлов (Dem1urg) 03.08.16 19:21
(1) ihtiking, Суть доклада была в том, чтобы рассказать о том, как одна компания попыталась применить системный подход к решению инцидентов. И что из этого получилось.
4. Яков Коган (Yashazz) 04.08.16 15:06
Пхе. Немножко пересказа ISO и немножко собственного опыта. Честно говоря, утомляют эти жж-образные биографические реминесценции. Ибо бесполезны, хоть будь сто раз красиво оформлены. Что в одной компании пошло "на ура", то в другой забуксует, и нет, на самом деле, никаких выводов и никаких best practice, кроме собственно желания участников процесса двигать оный процесс. А посему - скушно, братцы.

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

Я вот могу рассказать, как одна немаленькая компания не без моей помощи СКК внедряла, и-таки внедрила... Ровно для того, чтобы немецкие аудиторы, строгие ребята из TUV SUD, нужные бумажечки нам выдали. Надо ли говорить, на каком уровне при этом было и осталось истинное качество, или сами догадаетесь?
5. Sergey Andreev (starik-2005) 04.08.16 17:43
(4) Yashazz, ну это ИТИЛ - английская методология систем, работающих на базе инцидентов и создающих библиотеку знаний, позволяющую на часто встречающиеся инциденты реагировать быстрее с каждым разом. Ну и цепочка постоянного улучшения. Да, ничего нового, но лучше это прочитать, чем не прочитать - такое вот мое ИМХО.

Но вообще все сводится к хелпдеску...
Прикрепленные файлы:
6. Илья Козлов (Dem1urg) 05.08.16 10:12
(4) Yashazz, Рад, что у вас столь богатый профессиональный опыт, что вам такое уже неинтересно. Без подколов, на самом деле рад.
Но. Целью доклада и данной статьи не являлось развеять чью-либо скуку.
Цель - показать ситуацию под определенным углом зрения, в надежде, что это поможет кому-то посмотреть на привычные вещи по новому. И придумать, как он может улучшить работу свою или своей компании.
Accident; +1 Ответить
7. Илья Козлов (Dem1urg) 05.08.16 10:16
(5) starik-2005, Не нужно сужать рамки до ITIL и HelpDesk. Понятия инцидента намного шире. И инструментов для управления процессом изменений больше.
Я специально в докладе не делал акцента именно на ИТ. Да, зачастую, защитой от многих "мелких" инцидентов является автоматизированная информационная система, работа с которой построена таким образом, чтобы пользователь не мог сделать что-то неправильно (контроль заполненности реквизитов, контроль остатков при проведении документа и т.п.). Но не нужно ограничиваться этим.
8. Sergey Andreev (starik-2005) 05.08.16 12:11
(7) Dem1urg, Вы просто не читали шесть томов ITIL, походу. Я не сузил - я расширил.
9. Александр Анисков (vandalsvq) 05.08.16 19:17
Форма регистрации сообщения (инцидента) это конечно жуть, слишком как то наворочено.
По идее сначала регистрация и подтверждение сообщения, при чем назначение ответственных за разбор дальнейший не всегда реален и целесообразен.
Далее решают уже аналитики, ну или главарь технической банды (если вообще не сделать двойной вариант: персональное назначение + рынок свободных задач).
Собственно по результату реализации можно уже делать задачу по разработке механизма предотвращения.
Ну это просто, поток мыслей.

Пы.сы. если на картинке схемы бизнес-процесса реальный программный процесс - это просто беда, паника, истерика. Процессы должны быть простыми и понятными, желательно без множеств ветвлений и возвратов. С другой стороны хозяин барин и если надо наладить бюрократию, то начало неплохое ))))))
10. Илья Козлов (Dem1urg) 05.08.16 23:52
(9) vandalsvq, Процесс абсолютно реальный и он работает. В базе уже несколько тысяч инцидентов. Чтобы схема (карта маршрута) поместилась на слайде, её пришлось нарисовать "змеей". Если развернуть процесс в "линию" он будет выглядеть значительно проще. Ветвлений не много, а все возвраты возникают только если исполнитель предыдущего этапа сделал свою работу некачественно.
11. Евгений Савицкий (saveug) 07.08.16 11:34
Вот интересно, точка входа в управление инцидентами только одна - пользователь, но ведь бывают инциденты, генерируемые автоматически (средства мониторинга и т.п.). С другой стороны, если в процессе работы приложения произошел сбой, то зачем надеяться, что пользователь обратится за решением проблемы? Ведь можно подключить автоматические средства уведомления об инциденте.
12. Sergey Andreev (starik-2005) 08.08.16 11:34
(11) saveug, так и делают. Просто в качестве заказчика тут выступает ИТ, как создатель алгоритма проверки функционала. Робот от имени ИТ и создает данный инцидент, являющийся следствием работы алгоритма проверки на ошибочную ситуацию. В остальных случаях, когда робот не может распознать ошибку, заказчиком инициатором является пользователь. Регулярные ошибки уже могут облекаться в алгоритм, контролирующий те или иные параметры работы системы. И это не только ИТ проблем касается, но и проблем учета. Например, при превышении суммы отгрузки клиенту возникает инцидент, адресованный уполномоченному по данным вопросам сотруднику (или их группе). Если превышение оплаты по заявке на расходование ДС не выше определенного, то инцидент может быть создан финансовому контроллеру, если выше - просто отклонен. Ну и так далее...
13. Александр Дейнеко (Accident) 08.08.16 12:46
(2) Сурикат, добавлю - не только не соблюдают, но и не читают вовсе..
14. Александр Дейнеко (Accident) 08.08.16 12:52
(5) starik-2005, Полностью согласен.
Ps Статья читабельная. Для ознакомления самое то..
Саму методологию ИТила можно несколько лет постигать, ну это если кому интересно..
15. Юрий Муллабакиев (mulla1979) 08.08.16 18:08
16. Alexander Speshilov (speshuric) 09.09.16 21:35
Моё личное мнение:

Абсолютно правильно сказано, что на начальном этапе главная задача - регистрировать инциденты. А чтобы они регистрировались нужно несколько условий:
1. Одно окно. Или хотя бы "мало понятных окон". Причем "ошибся окном" - проблема окна, а не инициатора.
2. Инцидент создать просто. А лучше он сам создаётся. В том числе по непроизошедшим событиям.
3. НЕ НАКАЗЫВАТЬ ЗА ИНЦИДЕНТЫ. НИКОГДА. Даже если разбор показал что причина - конкретный сотрудник. Соблазн очень велик. Но нет. Если и наказывать, то за нерегистрацию, за задержки на передаче на "простых" этапах, за отсутствие реакции и неактуальность статуса, за неустранение проблем (если они были найдены и выделены ресурсы на устранение). Но никогда не за количество инцидентов. "У отдела А много инцидентов, давайте их лишим премии" - это п... конец вашей системе инцидентов.
4. БД инцидентов должна быть актуальна. Каждый день. По каждому исполнителю.
5. При автоматическом создании инцидентов нельзя спамить (да-да, "Волк! Волк!")

Чтобы поток инцидентов был управляемым:
1. Разделите "управление инцидентами" и "управление проблемами". В этой статье это смешано. На первых порах это нормально, но в итоге лучше разделить.
2. Из предыдущего пункта следует правило: инцидент закрыт НЕ тогда, когда устранена причина, а тогда, когда восстановлен сервис (или согласовано снижение уровня сервиса). На первый взгляд это неправильно, и, действительно, это требует определённой зрелости остальных процессов, но это важно.
3. Как логичное продолжение: Баг - не инцидент. Инцидент это событие потенциального или фактического снижения уровня сервиса, а баг - это неотъемлемое свойство программы. Да, часть багов приводит к инцидентам и является их причиной.
4. Прозрачные и однозначные правила приоритетов инцидентов. Прозрачный и однозначный порядок эскалации (как "вертикальной", так и "горизонтальной"). И в этом месте соглашусь с (5), (8), что лучше было бы имплементировать ITIL-подход. Нет там никакой космической сложности, но некоторые неочевидные грабли уже убраны.
5. Линейный (или почти линейный) и простой жизненный цикл инцидента. Переоткрытие инцидента - это маленькое ЧП. Если инцидент был устранен, но проблема снова возникла, то это новый инцидент (правда уже серийный, с соответствующими последствиями). Проблема у двух пользователей - скорее всего два инцидента, но один будет закрыт как дубликат со ссылкой на первый зарегистрированный.
6. По всем инцидентам, кроме катастроф и полных авралов всё общение в инциденте. В катастрофах и авралах заставлять вести историю самого бесполезного участника (это может быть и начальник какой-нибудь)

Типовые инциденты не надо расследовать. Это не значит, что не надо устранять причину. Причина находится и устраняется в управлении проблемами. Но вот заводить бюрократию вместо типового решения не следует. Абстрактный пример. Инцидент "перегорела лампочка". Каждый раз причина понятна (лампочка перегорела). В рамках предыдущих инцидентов стало понятно, что должен быть запас пампочек, он теперь на складе есть. Договорились в SLA, что нормальный срок устранения такого инцидента N минут. Зачем каждый раз расследовать? Будете заставлять расследовать у вас будут глупые решения: нанять сотрудника, который будет весь день ходить и проверять лампочки, менять лампочки каждую неделю, разработать и внедрить автоматизированную систему отслеживания работоспособности лампочек. Не надо. Просто если есть инцидент - поменяй лампочку. Это не перестаёт быть инцидентом.

Главный вопрос в управлении инцидентов - сбалансированная и аккуратная мотивация (разная для разных участников).
Dem1urg; Артано; +2 Ответить 1
17. Alexander Speshilov (speshuric) 09.09.16 21:47
(16) speshuric,
Уточню: Не наказывайте за инциденты рядовых исполнителей и нижний (линейный) уровень менеджмента. Средний и высший менеджмент за серьёзные инциденты в их зоне ответственности может пострадать (но не всё подразделение).
18. Илья Козлов (Dem1urg) 15.09.16 11:40
(17) speshuric, Это очень важное условие. В докладе я упоминал, что на начальном этапе внедрения процесса было прямое распоряжение высшего руководства содержащее явный запрет любого наказания для всех участников инцидента.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа