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