Чем время реакции отличается от времени исправления

Какие события скрываются за словом «исправить»

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

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

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

Согласуйте словарь времени

Уточните начало и конец отсчёта для каждого показателя. От сообщения в личном мессенджере или от регистрации в системе поддержки? До первого ответа или до подтверждения восстановления? Если правила размыты, обе стороны могут добросовестно получить разные цифры.

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

Приоритет определяется последствиями

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

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

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

Рабочее окно меняет смысл срока

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

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

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

Отличайте SLA, SLO и цели восстановления

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

RTO относится к целевому времени восстановления, а RPO — к допустимой потере данных во времени относительно точки восстановления. Определения целей восстановления также приведены в руководстве AWS. Они не равны частоте ответов поддержки. Даже быстрый ответ не доказывает, что база может быть восстановлена до требуемого состояния.

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

Условный пример инцидента

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

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

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

Карточка обращения, которая ускоряет разбор

• Затронутая страница или функция и время первого наблюдения с часовым поясом.
• Действия, после которых возникает ошибка, без передачи секретов.
• Ожидаемый и фактический результат.
• Охват: все пользователи, отдельная роль, устройство или запись.
• Безопасный идентификатор операции, если он доступен.
• Последние известные изменения и возможность обходного пути.
• Контакт ответственного, который может проверить восстановление.

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

Что проверить в предложении поддержки

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

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

Как посчитать сроки по журналу инцидента

Ниже вымышленный инцидент в пределах одного дня. Все отметки приведены в одном часовом поясе UTC+3. Договор примера считает реакцию от регистрации обращения, а восстановление — от начала недоступности. Это условия упражнения, а не сроки обслуживания Webexlab.

Реакция заняла 7 минут, недоступность — 80 минут. Между восстановлением и окончательным исправлением прошло ещё 5 часов 10 минут. Это три разных интервала. Быстрый ответ специалиста не превращает 80 минут простоя в семь, а восстановление функции не означает, что расследование закончено.

Если в упражнении задана цель восстановления 60 минут, фактические 80 минут её превышают на 20. В отчёте нужно сохранить отклонение и его причину. Нельзя переносить начало отсчёта на момент, когда инженер получил доступ, только чтобы уложиться в показатель. Определение RTO и зависимые операции согласуют заранее.

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