Инцидент менеджмент руководство

Инцидент-менеджмент для самых маленьких: как мы учили поддержку и разработку работать сообща

Привет, хабр! Меня зовут Полина. Я несколько лет занималась настройкой и развитием инцидент-менеджмента для eLama.

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

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

Приоритет – всему голова

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

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

На этом этапе не были учтены, как мне кажется, наиболее важные аспекты работы с приоритетами. Во-первых, определение приоритета не должно выполняться «на глаз». Во-вторых, в приоритетах должны мыслить все участвующие стороны, как минимум, разработка и поддержка.

О критериях

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

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

У вас B2C-сервис, которым пользуется множество небольших клиентов. В этом случае показательным может быть количество заафекченных пользователей.

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

С течением времени и список приоритетов, и их критерии могут меняться. Например, в первой итерации процесса у нас было 5 приоритетов – highest, high, medium, low и lowest. Последний отпал в ходе эволюции, потому что для него не нашлось применения на практике.

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

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

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

О синхронности

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

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

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

Программистский для начинающих

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

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

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

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

О поиске общего языка

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

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

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

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

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

Безусловно, это не избавило нас от bus-фактора. Процесс работы с инцидентами по-прежнему координируется и, если честно, я не могу с уверенность сказать, может ли быть иначе. Но процент времени, которое затрачивает инцидент-менеджер непосредственно на переписывание тикетов, значительно сократился.

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

Тестировщик в беде не бросит

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

О скрытых ресурсах

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

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

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

Во-вторых, находясь на периферии обращений о некорректной работе продукта, тестировщики могут быстрее узнавать об ошибках на бою.

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

О форматах взаимодействия

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

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

Безусловно, работа с инцидентами не является основным фокусом команды QA, да и не всем подошел такой формат. Но даже то участие, которое по мере своих возможностей принимают в процессе заинтересованные тестировщики, в нашем случае обеспечивает достаточную поддержку процесса и ослабляет bus-фактор.

С чего начинается инцидент-менеджмент

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

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

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

Во-первых, занесение проблемы в табличку означало, что оно не потеряется, в отличие от личного сообщения.

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

При этом, на тот момент мы воспользовались теми ресурсами, которые уже были в команде, то есть не потратили никаких дополнительных средств.

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

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

Заключение

Вот, пожалуй, и все.

Ретроспективно оценивая свой опыт работы над incident management process, я сформулировала для себя, на каких трех слонах и черепахе он базируется. Для меня это:

• приоритизация проблем; 

• общий язык для обмена информацией между командами; 

• люди, готовые поддерживать процесс;

• регистрация инцидентов в любом виде.

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

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

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

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

Спасибо за внимание!

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

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

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

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

Три принципа управления инцидентами в командах DevOps

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

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

В нашем Справочнике по управлению инцидентами мы описываем подход к управлению инцидентами, подходящий именно командам DevOps.

Have you ever experienced an interruption while working on a project and run into disorganization as a result? Most of us have been there, unfortunately. But thankfully, there’s a way to resolve these issues in real time without sacrificing team productivity. 

Incident management is the process of analyzing and correcting project interruptions as quickly as possible. That means more time spent on delivering impact—not to mention completing the project at hand. 

We’ll go over the process of incident management and best practices to implement a strategy of your own so that you’re ready if and when the next project incident occurs. 

What is incident management?

Incident management is the process of detecting, investigating, and responding to incidents in as little time as possible. While it doesn’t always lead to a permanent solution, incident management is important in order to finish projects on time, or as close to the set deadline as possible. 

Incident management can be implemented within any team, though IT teams commonly use it alongside release management and sometimes refer to it as IT infrastructure library, or ITIL, incident management.

Project managers use incident management during projects to prevent hazards from derailing tasks. This is done with the help of a five-step process that ensures incidents get solved efficiently and correctly. 

An incident is any disruption to a service or workflow. A few types of incidents that may be solved with incident management include: 

• Wi-Fi connectivity issues

• A virus or malware bug

• Email malfunction

• Website lags or navigation errors

• Security incidents 

Essentially, an incident is anything that will make life harder for customers or employees. 

Creating an incident management template can help your team members know exactly how to solve the problem when an incident does arise. 

Create an incident management plan template

Problem management vs. incident management

While there are a few differentiating factors when it comes to problem management vs. incident management, one key difference stands out: Problem management is the process of correcting the root cause of a project hazard, while incident management involves correcting a project interruption with a quick fix.

Here is a simple breakdown: 

• Incident management: A quick fix to a single, spontaneous event 

• Problem management: A comprehensive fix of a large-scale issue that is halting business operations 

While both systems are needed, they provide different outcomes and happen at different times in the project lifecycle. Incident management happens when an incident occurs, while problem management looks to solve the underlying issue after the fact to ensure it doesn’t happen again.

Benefits of incident management

Incidents can slow projects and waste valuable resources. They can also disrupt your operations, sometimes leading to the loss of crucial data. That’s why incident management is so important.

A few key benefits to incident management include: 

• Increased efficiency and team productivity

• Prevention of future incidents 

• Reduction in downtime

• Improved customer experience

• Visibility and transparency in your organization 

• Smooth business operations

• Quick return to normal service

With a good plan to tackle and eliminate current and future incidents, your organization will be made that much stronger. 

What are the five steps of an incident response plan?

An incident response plan is made of five important steps. Each of these steps makes up the incident management life cycle and helps teams track and address project hazards. 

There are five steps in an incident management plan:

1. Incident identification

2. Incident categorization

3. Incident prioritization

4. Incident response

5. Incident closure

From incident identification to prioritizing and ultimately responding, each of these steps helps incidents flow seamlessly through the process. Without an effective response plan, your projects could be at risk of running into serious issues. This is especially true for IT teams and DevOps due to the technical nature of their work. It’s also one of the reasons incident management is most commonly used within IT service management departments.

This is somewhat similar to a change control process, with the main difference being a project change vs. a major incident. 

Create an incident management plan template

Let’s learn more about the five steps of an effective incident management system, how to spot and resolve issues when they arise, and how resource allocation comes into the mix. 

1. Incident identification

The first step in an incident response plan is identifying the incident. An issue can arise in almost any part of a project, whether that’s internal, vendor-related, or customer-facing. 

To identify an incident, you should include the following:

• Name or ID number

• Description

• Date

• Incident manager

Each of these will be helpful for references later on, especially if you have a problem management plan in place. This way, you can find the root cause of the incident and ensure it doesn’t happen again. 

2. Incident categorization

Incidents need to be accurately categorized in order to be correctly resolved. Categorization allows your team members to:

1. Quickly find a solution if this incident ever arises again. 

2. Correctly prioritize incidents and sort them by urgency. 

Categorizing incidents by urgency can help make sure they’re taken care of in an order that makes sense.  For example, a chatbot lagging and the entire website being down carry different weight. 

Once you’ve categorized an incident, make sure it’s sorted into an appropriate section for future reference and so the right team gets their eyes on it. There isn’t a hard-and-fast rule when it comes to incident management categories, so focus on ways your team can easily identify future issues by the type of incident occurring. 

3. Incident prioritization

Once an incident is identified and categorized, you can move on to incident prioritization. There are a couple of key things to consider when it comes to ranking project incidents by importance: 

• Which other incidents you’re prioritizing against

• What other tasks need to be completed

Since incident management focuses on immediate fixes, you should look to resolve issues that will have immediate impacts. You’ll also need to prioritize incidents against other project tasks that need to be completed.

Once you’ve considered both prioritization factors, you can get started on your high-priority incidents first. 

4. Incident response

Once the incident is correctly labeled and prioritized, you can dig into the meat of the issue. Depending on how it’s labeled, the incident should be sent to the team most equipped to troubleshoot. Usually, the appropriate team will be able to quickly handle the problem. Quick response times are key to incident management. 

In some cases, your response team may not be able to find a solution. When that happens, they’ll escalate the problem to a different team for further investigation and troubleshooting. Keeping track of incidents and the teams assigned to deal with them can be tricky—but made easier with an appropriate work management software.

5. Incident resolution and closure

Once the problem is solved to everyone’s satisfaction, you’re ready to close the ticket and log the incident as complete. You’ll want to keep any documentation you’ve created in the above steps by storing it in a shared workspace for future reference. This can be anything from a shared drive to a digital project folder. 

During your post-mortem project meeting, you may want to talk through any incidents that occurred during the project. This can be a great transition into the problem management phase of a project where you work to solve the root cause and create a more effective meeting.

Incident management best practices

Now that you know what goes into an incident response plan, it’s time to create an incident log of your own. Getting started can be difficult depending on the type of project and team you’re working with. But with a few best practices and an example incident response log, you’ll be able to document and properly respond to incidents when they arise.

Here’s an example incident log to inspire your own.

View our template gallery or create your own custom log to get started.

Some key incident management best practices include keeping your log organized, properly training and communicating with your team, and automating processes if possible. Let’s dive into seven incident management best practices.

1. Identify early and often

Incidents can be tricky to spot, but the quicker you diagnose them, the easier the outcome will be to handle. 

The best thing to do is set aside time to examine your projects and processes for potential issues as often as possible. This will allow you to know precisely what problems are occurring and which might escalate to full-blown incidents. 

Tip: Once you identify an incident, make sure to document it in your incident log.

2. Keep your work tidy

Organization is key in any part of project management, but especially when documenting problems that could have long-lasting effects. You can do this by cleaning up your drives often and keeping descriptions brief. 

If you feel like more information should be added to your response log but there isn’t enough room, consider linking to an outside space or document where more detailed responses live. 

Tip: Create a baseline character count to keep descriptions short and prevent disorganization. 

3. Educate your team

Train your team about any accidents that may arise and what to do in the event they spot a potential problem. 

While formal training isn’t always needed, it’s a good idea to take them through any programs they’ll be working in and any potential issues. That way, they can help flag incidents before they get out of hand. 

Tip: Set up a meeting to walk your team through your incident log and any other needed tools. 

4. Automate tasks

Business process automation can help make incident management a breeze. While it’s sometimes difficult to set up, it can save you a ton of time in the long run (not to mention the headaches from resolving incidents). 

With the right automation software, also known as ITSM tools, you can program incidents to be flagged automatically. While this won’t be a be-all-and-end-all solution, it can help catch issues that you may have missed otherwise. 

Tip: Don’t forget to check automated tasks often. Setting and forgetting can result in mistakes being missed. 

5. Communicate in one place

Communication can be distributed at times, especially in a virtual work environment. In fact, teams are spending 30% more time on duplicate work. That’s why it’s so important to create an organized method of team communication. This starts with keeping collaboration in a shared space, often with the help of software tools. Not only will this save you and your team time in the future, but it will also help to reference communication when you need it. 

Tip: Set up a meeting to walk your team through your incident log and any other needed tools. 

Читать более 100 цитат для мотивации и вдохновения коллектива на совместную работу

6. Use project management tools

There are numerous tools you can use to create and maintain your incident management plan, project management software being one of them. 

Not only can it help organize work and communication, but it can also help your team build workflows and align goals to the work needed to complete them. This is important when managing incidents, as many teams will likely need to work together to solve issues. The more confusion there is around communication and tasks, the longer it will take to solve incidents in real time. 

Tip: Use a project management calendar to visualize work and deadlines in one place. 

7. Continue improving

Just like any plan you put into place, it’s essential to always work to improve it over time. Your first run at an incident response plan will likely look different from your 100th. Over time you’ll learn ways to become more efficient and it will be easier to spot incidents before they turn into problems. 

While practice makes perfect, there are additional ways you can expand your knowledge base. Some of these include continuing your education and tracking performance metrics. Attending webinars, listening to podcasts, and reading newsletters can all inspire you to bring new ideas back to your team. Plus, project tracking and analyzing KPIs can help you and your team learn from your mistakes.

Tip: Continue your education by learning how to create a resource management plan next.

Managing incidents doesn’t happen incidentally

Now that you’re prepared on how to create an incident management process, handling project incidents will be a breeze. With the seven best practices detailed above, you can ensure your plan is as effective as possible—saving both time and money.