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

0. Илья Козлов (Dem1urg) 47 06.07.16 15:32 Сейчас в теме
В статье речь пойдет про инциденты в несколько более широком смысле, чем это описано в ITIL – там все-таки в основном рассматриваются те инциденты, которые возникают при работе службы IT, а я расскажу про инциденты в целом, возникающие в процессе деятельности любой организации.
Инцидент – это по определению не очень хорошее слово. Если произошел инцидент, значит, произошло что-то плохое, что-то пошло не так, произошел какой-то сбой. Но это – только одна сторона вопроса, а я хочу вам предложить взглянуть на инциденты под другим углом, чтобы понять, чем они могут быть полезны.

Перейти к публикации

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

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

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

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

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

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