Инцидент как составить

Усиление конкуренции на рынке услуг заставляет бизнес бороться за клиентов, улучшая качество продуктов и услуг, обеспечивая большую прозрачность работы сервисов. Бизнес-процессы фирм все сильнее зависят от IT среды. Для нормального функционирования компаний приоритетной задачей становится быстрое реагирование на возникающие инциденты.

Что такое инциденты?

Сегодня утром в офисе у бухгалтера, готовящего отчет для начальства неисправен принтер. Замятие бумаги или закончились чернила – это можно назвать инцидентом.

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

Можно выделить следующие типы инцидентов:

1. Технические — любое происшествие, которое мешает правильному функционированию оборудования и программного обеспечения (нехватка рабочего места на диске, отказ компьютерных систем или ПО, обрыв проводов, замыкания, снижение уровня сигнала и т.д.).
2. Информационные — несанкционированный доступ к конфиденциальным данным, их раскрытие или изменение. Нанесение урона компьютерным программам вследствие заражения вирусом и внешних атак.
3. Нарушение нормативных актов, политики или законов ИТ-инфраструктуры.
4. Выявленные отклонения и недостатки программного обеспечения, сказывающиеся на скорости обработки обращения.

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

Что такое проблемы и чем они отличаются от инцидентов?

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

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

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

Предприятие, предоставляющие определенный комплекс услуг или информационный продукт, осуществляет свою деятельность на основе SLA — соглашения об уровне обслуживания пользователя. Инциденты, возникающие в ходе работы, могут повлиять на соблюдения условий договора. Для обеспечения качества предоставляемого продукта, был разработан специальный подход к управлению инцидентами—ITSM (IT Service Management). Его основными составляющими является:

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

ITSM базируется на определенном своде правил и практик, которые описаны в ITIL (библиотеке инфраструктуры информационных технологий). С внедрением системы управления инцидентами качественно улучшается функционирование всей системы, конкурентоспособность предприятия, лояльность клиентов и экономическая прибыль. На ее основе создаются службы, помогающие бизнесу организовать работу в ИТ среде: HelpDesk, ServiceDesk или более продвинутая версия MySmartService. Подобная система управления увеличивает скорость обработки происшествий, их устранение и увеличение удовлетворенности пользователей поставляемыми услугами. Также службы берут на себя полную ответственность за соблюдение SLA соглашения перед клиентом, их работа основана на принципах ITIL.

Процесс управления инцидентами можно разделить следующим образом:

Шаг 1. Фиксация инцидента.

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

Шаг 2: Категоризация инцидента.

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

Шаг 3: Приоритезация инцидента.

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

• Критический
• Высокий
• Средний
• Низкий

Шаг 4: Назначение ответственного.

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

Шаг 5: Создавайте задачи и управляйте ими.

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

Шаг 6: Управление и продвижение SLA.

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

Шаг 7: Разрешение инцидента.

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

Шаг 8: Закрытие инцидента.

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

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

Организовать работающую систему управления инцидентами на предприятие собственными силами достаточно сложно. Это происходит в связи со следующими причинами:

1. Необходим не только учет инцидентов, но и их приоритетная расстановка, от которой зависит правильное распределение времени на решение задачи.
2. Нужно координировать работы сразу нескольких служб одновременно.
3. Распределять нагрузку на разные отделы равномерно.
4. Учитывать связь между системами филиалов.
5. Брать личную ответственность за локальные решения сотрудников.
6. Учитывать компетенцию специалистов, стоимость их работы.
7. Организовать несколько линий поддержки, укомплектовать их нужными специалистами.
8. Создать систему числовых метрик с точным указанием времени на решение определенных типов инцидентов.
9. Расширять количество персонала в зависимости от роста компании, проводить модернизацию рабочих инструментов и переподготовку сотрудников.

Кроме всего этого, нужно тщательно фиксировать выявленные инциденты, процесс работы по их устранению, удовлетворенность пользователей. Подобный анализ позволит повысить уровень обслуживания, снизит риск возникновения будущих проблем. Для организации всего процесса, нужно привлекать дополнительные рабочие ресурсы, либо воспользоваться специализированными поставщиками решений Service Desk / ITSM.

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

Внедрить систему управления инцидентами можно двумя путями: организовав специальный отдел с наемными сотрудниками; воспользоваться компьютеризированными решениями поставщиков Service Desk / ITSM. Второй вариант решения обладает большим количеством преимуществ:

1. Постоянный доступ к информации об инциденте для всего персонала техподдержки.
2. Сокращение времени обслуживания.
3. Точная процедура отслеживания, эскалации и отработки инцидента.
4. Доступность и актуальность управленческой информации.
5. Устранение ее потерь, ошибок и дублирования.
6. Оптимальное использование квалификации персонала на всех линиях.
7. Налаживание связи структурных подразделений компании.
8. Составление отчетов и чек-листов.

Компьютеризированные системы Service Desk полностью интегрированы с важными компонентами управления ИТ-ресурсами. Они позволяют экономить средства на привлечение дополнительного персонала или переподготовки действующего. Компьютерные программы точно передают информацию без искажений и ошибок, могут предоставлять дополнительные сведения управляющему составу компании.

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

Поставщики решений Service Desk / ITSM предлагают широкий набор инструментов и функций управления жизненным циклом инцидентов. Они позволяют быстро обнаружить причину проблемы и смягчить ее последствия. MySmartService представляет собой облачное программное решение, которое объединяет традиционные и современные инструменты управления инцидентами. К особенностям сервиса относится:

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

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

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

Резюме

Сфера ИТ-услуг усложняется с каждым годом, растут требования к организации процесса и функционирования IT-инфраструктуры. Эффективность сопровождения рабочих программ и оборудования имеют большое значение для достижения бизнес целей. Service Desk — единая точка контакта для пользователя, ИТ-персонала, возможных поставщиков вспомогательных услуг компании. Она помогает:

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

Service Desk выполняет ряд экономически выгодных для компании функций: снижает стоимость владения ИТ-инфраструктурой с помощью повышения эффективности ее работы; оптимизирует инвестиции и управляет функциями поддержки бизнеса; выявляет возможные пути развития с последующим получением прибыли; увеличивает лояльность клиентов и их повторное обращение в конкретную фирму; участвует в формирование прибавочной стоимости.

Пока вы маленький старпап, команда легко справляется со всеми ошибками и сбоями сама. Если вы развиваетесь, и делаете это быстро, неизбежно приходит время, когда разработчиков становится больше, компания — крупнее, а проблемы перестают быть локальными и требуют участия смежных команд для их решения. Так и Skyeng прошел путь от маленького стартапа до известной онлайн-школы. Сейчас на платформе десятки тысяч учеников, 40 распределенных команд разработки и сотни сервисов, взаимодействующих друг с другом. 

Конечно, в какой-то момент инциденты вышли за пределы наших команд, и мы задумались о едином подходе работы с ними. Ответственным за процесс организации оказался я — Дима Кузнецов, один из юнит-лидов в Skyeng. Так в декабре 2019 года мы создали MVP этого проекта, и к TechLead Conf 2020 получили первые результаты, о чем я и рассказал на конференции. Сегодня я опишу, каким был процесс и что мы получили в результате.

План был очень простым

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

Сам MVP-процесс описали вот так: 

• Заводим канал #dev-disaster в Slack для быстрого реагирования на критические инфраструктурные сбои. Например, если сервис недоступен на проде, его разработчик пишет об этом — и дежурный сотрудник инфраструктуры подключается, чтобы помочь исправить проблему. Slack — наш основной инструмент коммуникации, поэтому выделенный канал для таких проблем должен стать отличной точкой старта. Плюс мы будем видеть, сколько обращений было на входе. 

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

• Когда инцидент устранен (и QA убедится в этом), пишем  обязательный Postmortem (так как все рассматриваемые сбои у нас критичные). Постмортем пишет тот, у кого больше контекста: это может быть как разработчик, так и сотрудник инфраструктуры.

• Инциденты за неделю разбирает рабочая группа: два руководителя разработки, руководитель эксплуатации инфраструктуры, руководители DevOps и QA. В первую очередь обращаем внимание на наличие системных проблем — тех, что могут возникать не только у одной команды. В процессе контролируем выполнение action-плана по устранению инцидента. А когда все задачи в составе инцидента выполнены, считаем инцидент проработанным и закрываем его.

Схема процесса получилась такой:

Я оформил этот регламент в Confluence, анонсировал в паре публичных каналов в Slack, и мы стали наблюдать, как все работает на практике. 

Картина через месяц

Уже на первом еженедельном разборе мы увидели, что сам еженедельный разбор работает отлично, но фиксируется лишь часть инцидентов. Конверсия зафиксированных сбоев — количество постов из #dev-disaster, для которых были заведены задачи в  Jira — была меньше 20%. 

Когда я начал разбираться, вскрылось много интересного. У кого-то из команд не были настроены мониторинги и алертинги — из-за чего мы знать не знали про некоторые сбои. Кто-то пропустил анонс из-за информационного шума в мессенджере. У некоторых команд еще не было QA — и они решили, что к ним процесс не относится. Другие почему-то посчитали, что их будут наказывать за сбои, хотя никаких наказаний не подразумевалось. А кто-то не хотел писать постмортем — «заполнять бумажки ваши, ну такое…». 

Но чаще всего ребята банально забывали, что нужно сделать. Разработчик забывал тегнуть QA. А тот — завести задачу и правильно ее оформить. Или не понимал, кому нужно передать написание постмортема. Назначенные SLA (3 дня) на написание постмортема не соблюдались, так как ответственные могли забыть про сроки или о том, чтобы перевести задачу в нужный статус.

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

Упрощаем

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

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

Определяем маршруты инцидентов

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

Вот, например, схема наших регулярных end-to-end тестов. Они отправляют отчеты о сбоях в отдельные Slack-каналы, где автоматизаторы анализируют отчет и находят места поломок. Если поломка критичная, то уведомление обязательно отправляется командам:

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

• Если проблема инфраструктурная — писать в канал #dev-disaster и исправлять ее вместе с инфраструктурой;

• Или, если это критичная бага на production, выполнить откат и решить проблему вместе с командой. 

Определяем, что такое инцидент

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

Поэтому мы выделили два типа сбоев:

1. Блокирующий инцидент — полная недоступность сервиса;

2. Критический инцидент — влияние на основной бизнес-процесс конкретного сервиса с учетом массовости его использования. Например, когда много пользователей не видят кнопки входа на урок в личном кабинете. Сюда же вошли сбои, которые хоть и не видны клиентам, но нарушают бизнес-процесс сервиса: например, если отвалились консьюмеры или не сработал cron.

В результате мы пришли к следующей схеме:

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

Упрощаем заведение инцидента

Можно было бы автоматически фиксировать любое сообщение в #dev-disaster как инцидент, но мне показалось, что если так сделать, то коллеги забудут через некоторое время о том, что мы просим фиксировать все виды инцидентов. Поэтому я сделал автоматизацию, которая при публикации поста в #dev-disaster спрашивала, является ли это инцидентом:

Одновременно это решило проблему того, что не все ребята помнили, где и как заводить задачу. Бот показывал модальное окно, в котором оставалось только дать название инциденту и выбрать его приоритет. Это же модальное окно можно было вызвать абсолютно из любого диалога в любом канале Slack, чтобы создать инцидент из треда:

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

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

В результате мы могли смотреть статистику и по задачам, созданным от эпиков, и по тем задачам, которые слинкованы с таким типом.

Упрощаем воркфлоу в Jira 

Чтобы коллегам легче работалось с инцидентами в Jira, я стал прямо в задачу дописывать краткие инструкции того, что нужно сделать дальше. А наполнение задачи обязательными данными реализовал с помощью перехода и диалогового окна. Это оказалось супер-удобно. Мне теперь не нужно было исправлять регламенты, чтобы изменить процесс. А ребята понимали, что от них ожидается на каждом этапе. Я просто добавлял новое обязательное поле в модельное окно и писал подсказку:

Убираем лишнюю бюрократию: делаем постмортем необязательным

Когда я проанализировал все инциденты, которые были зафиксированы за время работы MVP, то пришел к выводу, что Postmortem был нужен максимум в 30% случаев. Если до этого мы писали Postmortem после того, как инцидент был устранен, теперь, в результате работы бота, задача наполнялась минимально необходимой информацией в процессе создания. 

Поэтому мы ввели статус ревью для задачи, где была указана причина сбоя, дата начала и устранения, а также источник. А дальше рабочая группа по инциденту принимала решение — нужно ли здесь писать постмортем (то есть, нужны ли нам подробности). Или по этой задаче и так все понятно — и ее можно переводить в ожидание выполнения action-плана. В результате команды стали делать меньше «бумажной» работы.

Запрашиваем постмортем только когда он нужен

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

• перетаскивал задачу в соответствующий статус, 

• выбирал, кто будет писать постмортем, 

• и указывал дату, к которой  хотел бы получить результат:

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

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

Еженедельный дайджест инцидентов

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

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

Составляем наглядную документацию

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

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

Взаимодействие с техподдержкой

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

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

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

• сотрудники инфраструктуры получили понятное место, где можно делать анонсы о плановой недоступности.

Результаты

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

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

Эти результаты я описывал на TechLead Conf 2020. Но на этом наш процесс не остановился и за год работы видоизменился еще несколько раз. Сейчас у нас появилась команда SRE, тимлид которой курирует весь этот процесс. А наша база основных проблем и сбоев разрослась и структурировалась. 

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

Если вы задумались над внедрением подобного в своей компании:

• Определитесь сразу, для чего это вам. Чтобы собирать метрики? Чтобы улучшать вашу систему? Для каких-то других целей?

• Выберите ответственного за процесс и будьте готовы к тому, что он потратит на это много времени. Первое время, особенно пока работал MVP-процесс, я тратил 100% своего времени на его поддержку. С внедрением автоматизации стало проще, но инциденты нужно анализировать и разбирать, поэтому сократить свое участие до нуля можно только выйдя из проекта;

• Определите метрики: какие хотите снимать и на какие хотите влиять. Это может быть количество инцидентов, время простоя или сумма потерь. Метрики помогут быстро понять, работает процесс или нет;

• Очень важно, чтобы у ответственного за процесс было достаточно административного ресурса для изменений. У меня он был. Не уверен, что процесс заработал бы, отвечай за него разработчик, QA или кто-то из тимлидов — у нас очень много команд; 

• Определите путь инцидентов — как вы о них узнаете, из каких источников. Это поможет собрать общую картину и вы обязательно увидите какие-то точки пересечения;

• Упрощайте процесс. Сложный процесс не будет работать. Команды будут его избегать, а вы будете тратить много сил и ресурсов на его поддержание.

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

• Держите процесс под контролем. Я выстроил несколько уровней подстраховки, что помогает нам теперь фиксировать 90% инцидентов. Напоминания, контроль со стороны рабочей группы, помощь техподдержки — без этого фиксаций было бы намного меньше.

TechLead Conf 2021 пройдет с 30 июня по 1 июля 2021 в московском отеле Radisson Slavyanskaya. Расписание можно посмотреть здесь. А билеты — здесь.

До встречи на конференции, полностью посвященной инженерным процессам и практикам

Инцидент
— Случай, столкновение, неожиданное
происшествие, как правило, неприятное,
связанное с конфликтом.

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

Инцидент

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

Например,
Сараевское убийство – убийство наследника
австро венгерского престола Франца
Фердинанда и его жены, осуществленное
28 июня 1914 г. (по новому стилю) в городе
Сараево, было использовано Австро
Венгрией как повод для развязывания
Первой мировой войны. Уже 15 июля 1914 г.
Австро Венгрия под прямым давлением
Германии объявила войну Сербии. А прямое
вторжение Германии 1 сентября 1939 г. в
Польшу – это уже не повод, а инцидент,
свидетельствующий о начале Второй
мировой войны.

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

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

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

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

Если
после инцидента найти компромисс и
предотвратить дальнейшее развитие
конфликта не удалось, то за первым
инцидентом следуют второй, третий и т.
д. Конфликт вступает в следующий этап
– происходит его эскалация (нарастание).
Так, после первого инцидента во Второй
мировой войне – вторжения Германии в
Польшу – последовали другие, не менее
опасные. Уже в апреле – мае 1940 г. немецкие
войска оккупировали Данию и Норвегию,
в мае – вторглись в Бельгию, Нидерланды
и Люксембург, а затем и во Францию. В
апреле 1941 г. Германия захватила территорию
Греции и Югославии, а 22 июня 1941 г. напала
на Советский Союз.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #