Встреча про проблему
Локализуй, найди причину, прими решение — быстро
00:00
0 из 6 шагов выполнено
✓ Инцидент закрыт — время решения: —
Уровень критичности — выбери перед началом
Кто подключён к решению
Разработка
Тестирование
Поддержка
Маркетинг
Аналитика
Финансы
Юристы
CTO / Руководство
Продакт
1
Зафиксировать факт Что случилось?
Что именно не работает, когда началось, кто сообщил
⌄
Вопросы
  • Что именно не работает — опиши симптом?
    Фиксируй симптом, а не предположение о причине. "Кнопка оплаты не реагирует" — симптом. "Сломался платёжный модуль" — уже гипотеза.
  • Когда это началось — точное время?
    Точное время поможет найти что изменилось прямо перед инцидентом — деплой, миграция, внешний сервис.
  • Кто обнаружил и как сообщил?
    Пользователь, мониторинг или коллега — это влияет на оценку масштаба.
  • Сколько пользователей затронуто — все или часть?
    Масштаб определяет приоритет и срочность. Если затронут 1 пользователь — это P3. Если все — P1.
Свой вопрос
    Заметки
    2
    Локализовать проблему Где ломается?
    На каком именно шаге, в какой части системы
    ⌄
    Вопросы
    • На каком шаге пользователь сталкивается с проблемой?
      Чем точнее локализация — тем быстрее найдёт причину разработчик.
    • Это происходит всегда или при определённых условиях?
      Если не всегда — ищи паттерн. Определённый браузер, устройство, регион, сумма заказа.
    • Какое сообщение об ошибке видит пользователь?
      Текст ошибки или код — прямая подсказка для разработчика где смотреть в логах.
    • Проблема воспроизводится стабильно?
      Если воспроизводится стабильно — проще чинить. Если нет — возможно гонка состояний.
    Свой вопрос
      Заметки
      3
      Найти причину Почему сломалось?
      Что изменилось перед инцидентом — деплой, данные, внешний сервис
      ⌄
      Вопросы
      • Что изменялось в системе перед появлением проблемы?
        Деплой, миграция базы, изменение конфига — всё что могло стать триггером за последние 24 часа.
      • Что говорят логи и мониторинг?
        Логи — первый источник правды. Попроси разработчика показать ошибки в период инцидента.
      • Зависит ли проблема от внешнего сервиса?
        Платёжный шлюз, SMS-сервис, карты — внешние сервисы падают независимо от вас.
      • Была ли похожая проблема раньше?
        Если да — возможно это повторяющийся баг или системная проблема которую не починили до конца.
      Свой вопрос
        Заметки
        4
        Оценить влияние Насколько критично?
        Потери, обходной путь, срочность
        ⌄
        Вопросы
        • Какие потери несёт бизнес каждую минуту?
          Деньги, репутация, SLA — конкретные потери помогают правильно расставить приоритет.
        • Есть ли обходной путь для пользователей прямо сейчас?
          Даже временное решение снижает ущерб пока ищется причина.
        • Затронуты ли другие части системы?
          Иногда одна проблема — симптом более широкого сбоя. Проверь смежные функции.
        • Есть ли SLA или обязательства перед клиентами?
          Нарушение SLA может стоить штрафов или потери контракта.
        Свой вопрос
          Заметки
          5
          Принять решение Что делаем?
          Варианты с рисками — и кто принимает финальное решение
          ⌄
          Вопросы
          • Какие варианты решения есть — быстрый и надёжный?
            Всегда есть минимум два варианта: быстрый с риском и медленный но надёжный.
          • Кто имеет полномочия принять решение о действиях?
            BA не принимает решение об откате или деплое — это техлид, CTO или продакт.
          • Сколько времени займёт каждый вариант?
            Время — критичный параметр при инциденте.
          • Нужен ли откат или хватит точечного фикса?
            Откат безопаснее но теряешь новый функционал. Точечный фикс быстрее но риск что что-то упустишь.
          Свой вопрос
            Заметки
            6
            Коммуникация и следующие шаги Кто и что сообщает?
            Пользователи, команда, руководство — все должны знать статус
            ⌄
            Вопросы
            • Кто и как сообщает пользователям о проблеме?
              Молчание злит больше чем признание проблемы. Даже "мы знаем, чиним" снижает поток жалоб.
            • Кто информирует руководство о статусе?
              При P1 руководство должно знать сразу.
            • Как проверим что проблема решена?
              Нужен чёткий критерий — не "разработчик сказал что починил", а "проверили на продакшене".
            • Что делаем чтобы это не повторилось?
              Post-mortem, тест на стейджинге, алерт в мониторинге — зафиксируй что конкретно меняем.
            Свой вопрос
              Заметки
              Итог инцидента
              Заметки по всем шагам
              Заполни заметки в шагах — они появятся здесь
              Скопировано в буфер ✓
              J Подключение к Jira
              Токен создаётся на id.atlassian.com → Security → API tokens. Данные сохраняются только локально в этом браузере. Jira Cloud блокирует прямые запросы из браузера (CORS) — укажи адрес прокси, иначе запрос не пройдёт. Свой бесплатный прокси можно развернуть за 2 минуты: инструкция на GitHub.
              C Подключение к Confluence
              Email и API-токен берутся из того же Atlassian-аккаунта, что и для Jira (создать токен: id.atlassian.com). Space ID (числовой) можно найти через GET /wiki/api/v2/spaces?keys=КЛЮЧ или в URL пространства. Токен хранится только локально в этом браузере (localStorage) и никуда не отправляется, кроме самого Confluence.
              Confluence Cloud блокирует прямые запросы из браузера (CORS), поэтому нужен адрес прокси — без него запрос не пройдёт. Подходит тот же прокси, что и для Jira (он работает с любыми адресами вида *.atlassian.net, включая Confluence). Разверни свой бесплатный прокси за 2 минуты: инструкция на GitHub.