Сайт или сервис упал: какой разбор инцидента должен прислать разработчик и как понять, что сбой не повторится

Короткий ответ: после того как сайт или сервис снова работает, разработчик должен прислать письменный разбор инцидента — постмортем. Главное в нём: что сломалось и сколько длилось, кого задело, точная хронология, причина и список мер с ответственными и сроками. Если вместо мер написано «будем внимательнее», сбой, скорее всего, повторится.

Ниже — шаблон такого отчёта, вопросы, которые стоит задать после сбоя, признаки отговорок, порядок действий при утечке персональных данных и журнал инцидентов, который полезно вести на своей стороне. Как вовремя узнавать о падении, разобрано в статье про мониторинг сайта после запуска, а что проверить самому, если сайт не открывается, — в отдельной статье; здесь речь о том, что происходит после восстановления.

Что такое постмортем и зачем он заказчику?

Постмортем — это письменный разбор сбоя, составленный после восстановления работы. Он отвечает на три вопроса владельца: что именно я потерял, почему это случилось и что изменится, чтобы не случилось снова. Без него заказчик знает только, что «всё починили».

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

• Понять ущерб. Сколько заявок, заказов или оплат не прошло, нужно ли кому-то перезвонить.
• Проверить обещания. Меры из отчёта можно поставить задачами и через две недели спросить, что сделано.
• Видеть повторения. Три одинаковые причины за полгода — повод менять хостинг, архитектуру или подрядчика, а не чинить в четвёртый раз.

В инженерной практике такие отчёты пишут без поиска виноватых. Так, в книге Google о надёжности сервисов глава о культуре постмортемов прямо говорит: разбор исходит из того, что все действовали добросовестно с той информацией, что у них была, а исправлять нужно систему и процесс.

Когда нужен полный разбор, а когда хватит короткого сообщения?

Полный разбор нужен, если сбой видели клиенты, пропали данные, работу восстанавливали вручную (например, откатывали выкладку) или о сбое узнали не от мониторинга, а от клиента. Короткий одиночный сбой без последствий достаточно записать в журнал.

Критерии стоит договорить заранее, ещё при заключении договора поддержки, — тогда спорить «а нужен ли отчёт» не придётся. Рабочий набор для небольшого бизнеса:

• сайт, магазин или сервис был недоступен для клиентов дольше 15–30 минут в рабочее время;
• не работали заказ, оплата, форма заявки, вход в личный кабинет — даже если остальное открывалось;
• потеряны или испорчены данные: заказы, заявки, файлы, записи в базе;
• сбой первым заметили вы или ваш клиент, а не оповещение;
• такой же сбой уже был за последние три месяца;
• есть признаки, что к данным получил доступ посторонний.

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

Что должно быть в разборе инцидента?

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

Ниже шаблон, который можно переслать разработчику как образец. Третья колонка — признаки, по которым видно, что раздел заполнен формально.

Раздел	Что написано	Признак слабого отчёта
Кратко	Что сломалось, когда, сколько длилось, восстановлено ли полностью	Только «был сбой, всё починили»
Масштаб	Какие функции не работали, сколько заказов, заявок или пользователей задето, потеряны ли данные	«Затронуло немногих» без цифр
Хронология	События по минутам: начало, обнаружение, кто заметил, реакция, восстановление	Нет времени обнаружения или его заметил клиент
Причина	Цепочка: что произошло технически и почему это стало возможным	Одна фраза про «хостинг» или «нагрузку»
Что сделано	Как восстановили работу, что вернули, какие данные проверили	Не сказано, проверяли ли целостность данных
Меры	Список изменений с ответственным, сроком и способом проверки	«Будем внимательнее»
Что нужно от вас	Решения и действия на стороне заказчика: оплата, доступы, уведомления	Раздел отсутствует, хотя без вас мер не сделать

Как читать хронологию сбоя?

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

Хорошая хронология выглядит как журнал с точным временем и источником каждого события:

• 09:12 — выложено обновление каталога;
• 09:14 — форма заказа начала возвращать ошибку (по журналу сервера);
• 11:40 — менеджер сообщил, что с утра нет заказов;
• 11:52 — разработчик подтвердил сбой, начал откат;
• 12:05 — откат завершён, форма работает, проверен тестовый заказ.

Здесь работу восстановили за 25 минут после сигнала, и это неплохо. Но сбой шёл почти два с половиной часа, и узнали о нём от менеджера. Значит, главная мера — не «чинить быстрее», а проверка формы заказа после каждой выкладки и оповещение об ошибках. Если в отчёте нет времени обнаружения или его нельзя подтвердить журналом, попросите добавить.

Как отличить настоящую причину от поверхностной?

Настоящая причина отвечает не только «что сломалось», но и «почему это стало возможным». «Закончилось место на диске» — это событие. Причина — журналы никто не очищал и не было оповещения о заполнении диска.

Простой приём — несколько раз спросить «почему»:

1. Почему не принимались заказы? — Сервер не мог записать данные.
2. Почему не мог? — Диск заполнен на 100 %.
3. Почему заполнен? — За восемь месяцев накопились журналы ошибок, их никто не удалял.
4. Почему никто не заметил? — Нет оповещения о заполнении диска, а ежемесячной проверки сервера нет в поддержке.

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

Звучит как	Почему это не мера	Как выглядит настоящая мера
«Будем внимательнее при выкладке»	Зависит от памяти человека, проверить нельзя	Перед выкладкой автоматически прогоняются тесты формы заказа; без них выкладка не запускается
«Это хостинг, мы ни при чём»	Объясняет, но ничего не меняет	Резервный способ отправки заявок и проверка доступности раз в минуту
«Такое бывает редко»	Частота не уменьшает ущерб от следующего раза	Оповещение, которое сработает раньше, чем позвонит клиент
«Перезапустили сервер, всё работает»	Это восстановление, а не устранение причины	Найдено, что заполнило диск, настроена очистка журналов и порог оповещения
«Проведём полный аудит»	Без срока и результата это обещание	Аудит модулей оплаты до конкретной даты, итог — список задач на доске

Какие вопросы задать разработчику после сбоя?

Задайте семь вопросов: что сломалось, сколько длилось, что потеряно, как узнали, почему это стало возможно, что изменят и к какому сроку, что нужно от вас. Если на какой-то вопрос нет ответа, это и есть следующая задача.

1. Что именно не работало и с какого по какое время? Ответ с точностью до минут, по журналу, а не по памяти.
2. Что потеряно? Заказы, заявки, оплаты, файлы. Можно ли восстановить, есть ли список клиентов, которым нужно позвонить.
3. Проверена ли целостность данных? Особенно после восстановления из резервной копии: что было между копией и сбоем.
4. Как узнали о сбое? Если от вас или клиента — почему не сработал мониторинг.
5. Почему это стало возможным? Цепочка «почему», а не одно событие.
6. Какие меры, кто и до какого числа их сделает? Каждая мера — отдельная задача со сроком.
7. Что нужно от нас? Оплатить тариф хостинга, дать доступ, принять решение, предупредить клиентов.

Ниже — как различить меру и отговорку, если ответ на шестой вопрос вызывает сомнения.

Как понять, что меры действительно снизят риск?

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

Меры обычно делятся на три вида — полезно, когда в отчёте есть каждый:

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

Через две-три недели после отчёта сверьте меры с фактом. Удобно, когда они стоят задачами на доске проекта: в поддержке Roboweb.team у каждого заказчика есть доска в личном кабинете с колонками от «Пожеланий» до «Готово», и меры после сбоя видны там же, где остальные задачи.

Что делать, если при сбое могли пострадать персональные данные?

Если есть признаки, что данные клиентов попали к посторонним, у владельца сайта как оператора персональных данных появляются обязанности по закону. Обычный технический разбор здесь не заменяет уведомление Роскомнадзора.

По ч. 3.1 ст. 21 закона 152-ФЗ «О персональных данных» оператор с момента выявления такого инцидента уведомляет Роскомнадзор: в течение 24 часов — о самом инциденте, предполагаемых причинах и вреде, принятых мерах и об ответственном за взаимодействие лице; в течение 72 часов — о результатах внутреннего расследования и о лицах, чьи действия стали причиной, если такие есть.

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

Как вести журнал инцидентов у себя?

Журнал инцидентов — простая таблица на стороне заказчика: одна строка на сбой, восемь колонок. Он нужен, чтобы видеть повторения и не зависеть от памяти подрядчика, особенно если подрядчик меняется.

Колонки, которых достаточно:

1. дата и время начала и восстановления;
2. что не работало (заказ, оплата, весь сайт, обмен с 1С);
3. как узнали: оповещение, сотрудник, клиент;
4. ущерб в ваших единицах: заказов, заявок, звонков;
5. причина в одной строке из разбора;
6. меры и их срок;
7. выполнены ли меры (дата проверки);
8. ссылка на полный разбор.

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

Кто платит за разбор и исправление причины?

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

В типовом договоре Roboweb.team гарантия — 30 календарных дней с даты подписания акта: ошибки, возникшие по вине исполнителя, устраняются безвозмездно. Гарантия не распространяется на изменения, внесённые заказчиком или третьими лицами, и на сбои сторонних сервисов — хостинга, платёжного шлюза, CRM. Отдельно от гарантии после запуска есть бесплатный период мелких правок: 7 дней для лендинга и бота, 14 дней для магазина и веб-приложения, 1 месяц для корпоративного сайта.

Дальше — абонентская поддержка от 7 900 ₽ в месяц или разовые задачи; работаем в рабочее время. Что обязательно записать в договор поддержки — время реакции, резервные копии, кто отвечает за хостинг, — разобрано в статье договор на поддержку сайта и SLA. Туда же стоит добавить одну строку: «после инцидента по согласованным критериям исполнитель направляет письменный разбор в течение N рабочих дней».

Как выглядит разбор на условном примере?

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

Кратко. 14 ноября с 10:05 до 15:30 заявки с формы на сайте не доходили в CRM. Сайт открывался, форма показывала «Спасибо». Восстановлено полностью.

Масштаб. 11 заявок не попали в CRM. Все найдены в журнале сервера, список с телефонами передан менеджеру в 15:45.

Причина. CRM в этот день сменила адрес приёма данных и отключила старый. Сайт получал ошибку, но не сообщал о ней и не сохранял заявку для повторной отправки. Объявление об изменении CRM рассылала заранее, письмо пришло на почту, которую никто не читает.

Меры. Заявки сохраняются на сайте и повторно отправляются при ошибке — до 20 ноября. При ошибке передачи — оповещение в Telegram менеджеру и разработчику — до 20 ноября. Почту для уведомлений CRM переключить на рабочую — заказчик, до 17 ноября.

Заметьте: сбой случился на стороне стороннего сервиса, и формально это не гарантийный случай. Но отчёт всё равно показывает слабое место сайта — он молча терял заявки — и закрывает его.

Когда подробный разбор не нужен и какие ошибки встречаются?

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

Частые ошибки заказчиков и подрядчиков:

• Принять «всё работает» как отчёт. Восстановление и устранение причины — разные вещи.
• Искать виноватого. Разработчик, которого ругают за каждый сбой, начнёт о них молчать.
• Требовать разбор через час. Сначала — восстановление и короткое сообщение, разбор — после, иначе отвлекаете от починки.
• Не проверить меры. Обещания без срока и проверки забываются за месяц.
• Не посчитать ущерб. Без цифр нельзя решить, стоит ли мера своих денег.
• Требовать стопроцентной доступности. Сбои случаются у любой системы; цель — узнавать раньше и восстанавливаться быстрее.

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

Короткие ответы на частые вопросы

Что такое постмортем в IT простыми словами?

Это письменный разбор сбоя после того, как работу восстановили: что произошло, кого и как задело, почему так вышло и что изменят, чтобы это не повторилось. Цель — исправить систему и процесс, а не найти виноватого.

Через сколько после сбоя разработчик должен прислать разбор?

Короткое сообщение о восстановлении — сразу, как сайт заработал. Полный разбор для небольшого проекта разумно ждать в течение одного-трёх рабочих дней; срок стоит записать в договоре поддержки.

Обязан ли разработчик бесплатно исправить причину сбоя?

Если причина — ошибка в сданной работе и сбой случился в гарантийный срок, исправление входит в гарантию. В договорах Roboweb.team это 30 календарных дней с даты акта; на изменения третьих лиц и сбои сторонних сервисов гарантия не распространяется.

Кто сообщает в Роскомнадзор, если при сбое утекли персональные данные?

Оператор персональных данных, то есть обычно владелец сайта — заказчик. Разработчик даёт ему факты для уведомления: что произошло, какие данные могли пострадать, какие меры приняты.

Нужен ли разбор, если сайт лежал пять минут ночью?

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

Услуги и кейсы по теме: поддержка сайта от 7 900 ₽/мес · заказная разработка · цены и сроки