Предоставьте специалистам по устранению инцидента одну рабочую запись для воздействия, ответственности, диагностики, обновлений, обходного решения, восстановления, проверки и последующих действий.
Просмотр текущих инцидентов открывается при активном сбое сервиса и риске по времени. Он показывает, что специалисты по устранению инцидента и владельцы сервиса должны решить сейчас, а затем сохраняет доказательства, необходимые для проверки восстановления и извлечения уроков из повторных случаев.
Бесплатно для команды до пяти пользователей. Банковская карта не нужна.
Настраивайте поля, процессы и панели мониторинга без программирования. Посмотреть более 1 000 шаблонов приложений и сценариев
Первый просмотр показывает активные инциденты. Используйте вкладку для мобильных устройств, чтобы сообщить о симптомах, влиянии, доказательствах и контактных данных с телефона.
Запись должна помогать людям быстро восстанавливать сервис, предотвращая исчезновение важного контекста и решений в чате.
Записывайте, что наблюдают пользователи, когда это началось, какая услуга или местоположение затронуто, масштаб воздействия, доступные доказательства и надежный контакт. Не заставляйте заявителя диагностировать первопричину или назначать технический приоритет.
Сделайте одного человека ответственным за инцидент и другую роль — за обновления для заинтересованных сторон по мере необходимости. Показывайте следующее действие, время следующего обновления, состояние эскалации и целевой риск вместо того, чтобы полагаться на личные напоминания.
Записывайте временное решение или действия по восстановлению, техническую проверку, подтверждение от затронутого пользователя и условия для повторного открытия. Статус «Исправлено» не должен стирать неудачную проверку восстановления.
Исполнители, владельцы сервисов, руководители и затронутые пользователи нуждаются в разных видах информации о том же событии.
Сохраняйте наблюдаемые симптомы, недавние изменения, затронутые элементы конфигурации, журналы или вложения, заметки по расследованию, гипотезы, действия и результаты в хронологическом порядке, не раскрывая приватные технические обсуждения в обновлениях для пользователей.
Публикуйте подтверждённое воздействие, доступные обходные решения, текущую деятельность по восстановлению и время следующего обновления. Разделяйте факты и гипотезы, держите аудиторию и состояние доставки видимыми.
Показывайте влияние на бизнес, прошедшее время, критичность сервиса, несоблюдённые обязательства, эскалацию, повторение и необходимость проведения анализа проблем или изменения после восстановления.
Не каждый инцидент требует полного посмертного анализа, но каждое закрытие должно оставлять оправданный операционный результат.
Связывайте повторяющиеся симптомы и связанные инциденты с записью проблемы, чтобы работа по выявлению коренной причины, известные ошибки и обходные решения продолжались после того, как канал реагирования успокоится.
Когда постоянное исправление требует изменения в производственной среде, подключите инцидент к изменению с его собственным риском, проверкой, авторизацией, внедрением и решениями по откату.
Запланируйте короткую проверку эффективности для вновь открытых сервисов, повторяющихся предупреждений, жалоб пользователей или нерешённых корректирующих действий. Уверенность в закрытии выше, когда его можно пересмотреть.
Метка серьёзности должна объяснять модель реагирования, а не заменять суждение.
| Наблюдаемое состояние | Модель реагирования | Доказательства до закрытия |
|---|---|---|
| Критическая служба недоступна для многих пользователей | Координация крупного инцидента и частые обновления | Критерии восстановления выполнены; заинтересованные стороны информированы |
| Существенное ухудшение с обходным решением | Инцидент под контролем и реакция с учётом цели | Обходное решение или восстановление проверено |
| Ограниченное воздействие на пользователей | Стандартная очередь инцидентов | Сообщение от заявителя или владельца службы подтверждает использование |
| Тот же симптом повторяется | Инцидент и связанная с ним проблема | Немедленное восстановление и работа по предотвращению разделены |
Настроить запись инцидента с учётом сигналов, необходимых специалистам по устранению инцидента: затронутая служба, воздействие на пользователей, прошедшее время, ответственный, текущее действие, частота обновлений, обходное решение, восстановление и подтверждение.
Результатом является запись инцидента, которая поддерживает действия во время перебоев и остается полезной после восстановления.Изменяйте вопросы о влиянии и срочности, не прося докладчиков диагностировать причину, а затем направляйте запись в ответственную команду.
Записывайте расследования, решения, обходные пути, обновления для аудитории и следующие согласованные действия по одному и тому же инциденту.
Требуйте технического восстановления, проверки бизнеса, подтверждения пользователя или другой определенной проверки и сохраняйте предыдущую историю при повторном открытии инцидента.
Jodoo может координировать запись инцидента и его передачу между людьми без замены инструментов наблюдения или сигнализации.
Фиксация влияния, приоритет, ответственность, история расследований, коммуникации, проверки восстановления, повторное открытие и связанная работа по проблемам или изменениям.
Ссылки на предупреждения, журналы, треки, события дежурства, записи развертывания, коммуникации о статусе и технические доказательства из их авторитетных систем.
Нативная корреляция событий, автоматическое оповещение, организация чата по инцидентам или реагирование, основанное на наблюдаемости, является основным требованием к покупке.
Инцидент восстанавливает неожиданно прерванную или ухудшенную услугу. Запрос на обслуживание удовлетворяет определенную, ожидаемую потребность, такую как доступ, оборудование или стандартная услуга. Сохраняйте жизненные циклы связанными, но отдельными.
Обычно они должны описывать наблюдаемый эффект и срочность. Служба поддержки может применять модель приоритетов, используя затронутую услугу, масштаб пользователей, критическое временное окно, последствия для безопасности или соответствия требованиям и наличие обходных решений.
Да. Сохраните первоначальное действие по восстановлению и результат проверки, зафиксируйте, почему услуга снова вышла из строя, и продолжайте жизненный цикл вместо удаления или сокрытия предыдущего решения.
Да, через соответствующую интеграцию или автоматизацию. Мониторинг остаётся источником технических сигналов; Jodoo координирует эффект, ответственность, обновления, проверки восстановления и связанную работу.
Авторизованные разработчики могут настраивать поля ввода, правила приоритета, шаги реагирования, уведомления, доказательства восстановления и панели управления без кода по мере развития практики инцидентов.
Откройте заполненные примеры для активного реагирования, коммуникаций, обходных решений, восстановления, повторного открытия и последующего рассмотрения проблемы перед адаптацией рабочего процесса к вашим сервисам.
Изучить работу с инцидентами