iiuniversitet.ruЦентр обучения нейросетямОткрыть каталог

Разбор сбоя и постмортем

Ведёт сбой в работе сервиса от оценки серьёзности и обновлений статуса до разбора без поиска виноватых.

СкиллAnthropicClaudeApache-2.0Загрузить архив в ClaudeПроверка не требуется
Что делает
Ведёт сбой в работе сервиса от оценки серьёзности и обновлений статуса до разбора без поиска виноватых.
Когда брать
Когда сервис лёг или пришла тревога: нужно оценить серьёзность, оповестить людей, потом написать разбор.
Пример запроса
У нас упал сайт оплаты, помоги оценить серьёзность и написать обновление статуса для команды.

Входит в плагин engineering. В Cowork и Claude Code можно поставить плагин целиком.

Как включить

  1. Нажмите «Скачать на русском» и сохраните архив.
  2. В Claude откройте Настройки → Capabilities → Skills → Upload skill и выберите архив.
  3. Включите скилл переключателем.
Для терминала

Распакуйте архив и положите папку incident-response в ~/.claude/skills/. Файл SKILL.md должен лежать внутри этой папки.

Текст

---
name: incident-response
description: Рабочий процесс реагирования на инцидент — оценка и разбор ситуации, коммуникация и написание постмортема. Запускай по фразам «у нас инцидент», «прод лежит», при тревоге, для которой нужно определить серьёзность, для обновления статуса посреди инцидента, а также для написания постмортема без поиска виноватых после устранения проблемы.
argument-hint: "<incident description or alert>"
---

/incident-response

Если встретишь незнакомые подстановки или нужно узнать, какие инструменты подключены, смотри [CONNECTORS.md](../../CONNECTORS.md).

Веди инцидент от обнаружения до постмортема.

Использование

/incident-response $ARGUMENTS

Режимы

/incident-response new [description]     # Start a new incident
/incident-response update [status]       # Post a status update
/incident-response postmortem            # Generate postmortem from incident data

Если режим не указан, спроси, на каком этапе инцидент.

Как это работает

┌─────────────────────────────────────────────────────────────────┐
│                    РЕАГИРОВАНИЕ НА ИНЦИДЕНТ                     │
├─────────────────────────────────────────────────────────────────┤
│  Этап 1: ОЦЕНКА                                                 │
│  ✓ Определить серьёзность (SEV1-4)                              │
│  ✓ Выяснить, какие системы и пользователи затронуты             │
│  ✓ Назначить роли (IC — руководитель, связь, исполнители)       │
│                                                                 │
│  Этап 2: КОММУНИКАЦИЯ                                           │
│  ✓ Подготовить внутреннее обновление статуса                    │
│  ✓ Подготовить сообщение для клиентов (если нужно)              │
│  ✓ Завести штаб (war room), согласовать частоту обновлений      │
│                                                                 │
│  Этап 3: СНИЖЕНИЕ УЩЕРБА                                        │
│  ✓ Записать предпринятые меры                                   │
│  ✓ Вести хронологию событий                                     │
│  ✓ Подтвердить устранение                                       │
│                                                                 │
│  Этап 4: ПОСТМОРТЕМ                                             │
│  ✓ Постмортем без поиска виноватых                              │
│  ✓ Восстановление хронологии                                    │
│  ✓ Анализ первопричины (5 «почему»)                             │
│  ✓ Задачи с ответственными                                      │
└─────────────────────────────────────────────────────────────────┘

Классификация серьёзности

УровеньКритерииВремя реакции
SEV1Сервис не работает, затронуты все пользователиНемедленно, подключаются все
SEV2Серьёзно ухудшена важная функция, затронуты многие пользователиВ течение 15 минут
SEV3Проблема во второстепенной функции, затронуты некоторые пользователиВ течение 1 часа
SEV4Косметическая проблема или с малым влияниемВ следующий рабочий день

Рекомендации по коммуникации

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

Результат — обновление статуса

## Обновление по инциденту: [Название]
**Серьёзность:** SEV[1-4] | **Статус:** Расследуем | Причина найдена | Наблюдаем | Решено
**Влияние:** [Кто или что затронуто]
**Последнее обновление:** [Время]

### Текущее состояние
[Что нам известно сейчас]

### Предпринятые действия
- [Действие 1]
- [Действие 2]

### Дальнейшие шаги
- [Что происходит дальше и ожидаемый срок]

### Хронология
| Время | Событие |
|-------|---------|
| [ЧЧ:ММ] | [Событие] |

Результат — постмортем

## Постмортем: [Название инцидента]
**Дата:** [Дата] | **Длительность:** [X часов] | **Серьёзность:** SEV[X]
**Авторы:** [Имена] | **Статус:** Черновик

### Краткое содержание
[Резюме простым языком в 2–3 предложениях]

### Влияние
- [Какие пользователи затронуты]
- [Как долго длилось влияние]
- [Влияние на бизнес, если его можно измерить]

### Хронология
| Время (UTC) | Событие |
|-------------|---------|
| [ЧЧ:ММ] | [Событие] |

### Первопричина
[Подробное объяснение, что вызвало инцидент]

### 5 «почему»
1. Почему произошло [симптом]? → [Потому что...]
2. Почему произошло [причина 1]? → [Потому что...]
3. Почему произошло [причина 2]? → [Потому что...]
4. Почему произошло [причина 3]? → [Потому что...]
5. Почему произошло [причина 4]? → [Первопричина]

### Что получилось хорошо
- [Что сработало]

### Что получилось плохо
- [Что не сработало]

### Задачи по итогам
| Действие | Ответственный | Приоритет | Срок |
|----------|---------------|-----------|------|
| [Действие] | [Человек] | P0/P1/P2 | [Дата] |

### Извлечённые уроки
[Главные выводы для команды]

Если подключены коннекторы

Если подключён ~~monitoring:

  • Подтяни детали тревоги и метрики
  • Покажи графики затронутых метрик

Если подключён ~~incident management:

  • Создай или обнови инцидент в PagerDuty/Opsgenie
  • Вызови дежурных исполнителей

Если подключён ~~chat:

  • Публикуй обновления статуса в канале инцидента
  • Создай канал для штаба (war room)

Советы

  1. Начинай записывать сразу — не жди полной информации. Обновляй по мере прояснения.
  2. Держи обновления фактическими — что мы знаем, что сделали, что дальше. Без догадок.
  3. Постмортемы пишутся без поиска виноватых — разбирай системы и процессы, а не людей.

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/engineering/skills/incident-response, лицензия Apache-2.0. Изменения: перевод на русский язык.

Оригинал на английском
---
name: incident-response
description: Run an incident response workflow — triage, communicate, and write postmortem. Trigger with "we have an incident", "production is down", an alert that needs severity assessment, a status update mid-incident, or when writing a blameless postmortem after resolution.
argument-hint: "<incident description or alert>"
---

# /incident-response

> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).

Manage an incident from detection through postmortem.

## Usage

```
/incident-response $ARGUMENTS
```

## Modes

```
/incident-response new [description]     # Start a new incident
/incident-response update [status]       # Post a status update
/incident-response postmortem            # Generate postmortem from incident data
```

If no mode is specified, ask what phase the incident is in.

## How It Works

```
┌─────────────────────────────────────────────────────────────────┐
│                    INCIDENT RESPONSE                               │
├─────────────────────────────────────────────────────────────────┤
│  Phase 1: TRIAGE                                                  │
│  ✓ Assess severity (SEV1-4)                                     │
│  ✓ Identify affected systems and users                          │
│  ✓ Assign roles (IC, comms, responders)                         │
│                                                                    │
│  Phase 2: COMMUNICATE                                              │
│  ✓ Draft internal status update                                  │
│  ✓ Draft customer communication (if needed)                     │
│  ✓ Set up war room and cadence                                   │
│                                                                    │
│  Phase 3: MITIGATE                                                 │
│  ✓ Document mitigation steps taken                               │
│  ✓ Track timeline of events                                      │
│  ✓ Confirm resolution                                            │
│                                                                    │
│  Phase 4: POSTMORTEM                                               │
│  ✓ Blameless postmortem document                                 │
│  ✓ Timeline reconstruction                                       │
│  ✓ Root cause analysis (5 whys)                                  │
│  ✓ Action items with owners                                      │
└─────────────────────────────────────────────────────────────────┘
```

## Severity Classification

| Level | Criteria | Response Time |
|-------|----------|---------------|
| SEV1 | Service down, all users affected | Immediate, all-hands |
| SEV2 | Major feature degraded, many users affected | Within 15 min |
| SEV3 | Minor feature issue, some users affected | Within 1 hour |
| SEV4 | Cosmetic or low-impact issue | Next business day |

## Communication Guidance

Provide clear, factual updates at regular cadence. Include: what's happening, who's affected, what we're doing, when the next update is.

## Output — Status Update

```markdown
## Incident Update: [Title]
**Severity:** SEV[1-4] | **Status:** Investigating | Identified | Monitoring | Resolved
**Impact:** [Who/what is affected]
**Last Updated:** [Timestamp]

### Current Status
[What we know now]

### Actions Taken
- [Action 1]
- [Action 2]

### Next Steps
- [What's happening next and ETA]

### Timeline
| Time | Event |
|------|-------|
| [HH:MM] | [Event] |
```

## Output — Postmortem

```markdown
## Postmortem: [Incident Title]
**Date:** [Date] | **Duration:** [X hours] | **Severity:** SEV[X]
**Authors:** [Names] | **Status:** Draft

### Summary
[2-3 sentence plain-language summary]

### Impact
- [Users affected]
- [Duration of impact]
- [Business impact if quantifiable]

### Timeline
| Time (UTC) | Event |
|------------|-------|
| [HH:MM] | [Event] |

### Root Cause
[Detailed explanation of what caused the incident]

### 5 Whys
1. Why did [symptom]? → [Because...]
2. Why did [cause 1]? → [Because...]
3. Why did [cause 2]? → [Because...]
4. Why did [cause 3]? → [Because...]
5. Why did [cause 4]? → [Root cause]

### What Went Well
- [Things that worked]

### What Went Poorly
- [Things that didn't work]

### Action Items
| Action | Owner | Priority | Due Date |
|--------|-------|----------|----------|
| [Action] | [Person] | P0/P1/P2 | [Date] |

### Lessons Learned
[Key takeaways for the team]
```

## If Connectors Available

If **~~monitoring** is connected:
- Pull alert details and metrics
- Show graphs of affected metrics

If **~~incident management** is connected:
- Create or update incident in PagerDuty/Opsgenie
- Page on-call responders

If **~~chat** is connected:
- Post status updates to incident channel
- Create war room channel

## Tips

1. **Start writing immediately** — Don't wait for complete information. Update as you learn more.
2. **Keep updates factual** — What we know, what we've done, what's next. No speculation.
3. **Postmortems are blameless** — Focus on systems and processes, not individuals.

Источник: anthropics/knowledge-work-plugins / engineering / incident-response ↗. Ссылка проверена 2026-10-10.