Постмортем инцидента для публикации

Постмортем: ошибки при создании счетов и задержка вебхуков 15 сентября 2026 года

Опубликовано: [дата публикации]

Кратко

15 сентября с 09:02 до 09:40 МСК около 14 000 из 22 000 активных аккаунтов Ledgerly (примерно 64%) не могли создавать счета и генерировать PDF: API возвращал ошибки 502 и 504. Доставка вебхуков в интеграции с 1С и Контур.Диадоком задержалась, и очередь полностью разобралась только к 12:40.

Данные не потеряны. Из-за автоматических повторных запросов у 180 пользователей появились дубли счетов. Мы нашли и удалили их вручную, каждому из этих пользователей написали отдельно.

Причина: в 08:58 мы выкатили релиз 2.14.0. Он изменил конфигурацию PgBouncer, прокси между нашим приложением и базой данных PostgreSQL. В новом шаблоне конфигурации лимит клиентских соединений (max_client_conn) был равен 50 вместо прежних 500. Через две минуты начался ежедневный утренний пик нагрузки, лимита не хватило, и PgBouncer перестал принимать новые соединения.

Мы приносим извинения всем, у кого утро 15 сентября началось с ошибок, и особенно тем, кому пришлось разбираться с дублями.

Что увидели клиенты

Хронология

Всё время указано по Москве (UTC+3), 15 сентября 2026 года.

Ключевые интервалы

• От изменения до обнаружения: 6 минут (08:58 → 09:04). От первых ошибок у клиентов до алерта прошло 2 минуты (09:02 → 09:04). Мы узнали о проблеме по симптому, то есть по ошибкам. Сигнала о её причине, заполнении пула соединений, у нас не было.
• От обнаружения до устранения: 32 минуты (09:04 → 09:36). Основное время ушло на три этапа: 10 минут до решения об откате (09:04 → 09:14), 5 минут до его запуска (09:14 → 09:19) и 12 минут на сам откат, включая ручное исправление конфига (09:19 → 09:31).
• Полное устранение последствий: вебхуки к 12:40, дубли счетов к [время].

Обнаружение в этом инциденте сработало быстро. Слабым местом оказались сроки реакции: путь от алерта к действию и продолжительность отката.

Почему это произошло

Симптом. API-гейтвей отдавал 502 и 504 на создание счетов, генерацию PDF и обработку вебхуков.

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

Почему? Лимит клиентских соединений PgBouncer был 50. В обычный утренний пик нам нужно значительно больше, поэтому до этого релиза лимит составлял 500.

Почему лимит стал 50? Релиз 2.14.0 заменил конфигурацию PgBouncer, сгенерированную из шаблона. В шаблоне для max_client_conn стояло значение 50, а не 500. [Уточнить механизм: параметр пропал из шаблона и подставилось значение по умолчанию, в шаблоне была устаревшая версия или переменная не прокинулась в окружение.]

Почему ошибка дошла до продакшена?

1. В пайплайне не было проверки, которая сравнивает параметры инфраструктурной конфигурации с согласованными значениями. Изменение, которое уменьшило лимит в 10 раз, прошло без предупреждения.
2. Конфигурация PgBouncer применилась сразу на весь продакшен. Постепенной раскатки, на которой проблема проявилась бы на части трафика, не было.
3. Релиз вышел в 08:58, за две минуты до ежедневного пика нагрузки. У нас не было правила, запрещающего выкатывать изменения инфраструктуры перед пиком.

Почему последствия оказались тяжелее простого простоя? 4. Эндпоинт создания счёта не защищён от повторов: он не принимает ключ идемпотентности и не распознаёт повторный запрос. Клиентские SDK после таймаута автоматически отправляли запрос ещё раз. Часть исходных запросов при этом успела выполниться на сервере, хотя клиент получил таймаут. Так появились дубли. [Проверить, что механизм именно такой.] 5. Откат релиза через CI/CD не вернул прежнюю конфигурацию PgBouncer, и её пришлось исправлять вручную. [Проверить.] Это удлинило восстановление.

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

Что мы изменили и изменим

Уже сделано (к 18 сентября)

• Проверка конфигурации в CI. Пайплайн сравнивает конфигурацию PgBouncer с согласованными значениями и блокирует деплой, если они расходятся.
• Алерт на заполнение пула. Мы получим сигнал, когда доля свободных соединений упадёт ниже 15%, то есть до того, как клиенты начнут видеть ошибки.

В работе

• Инструкция для дежурных по инцидентам с пулом соединений. В ней будут признаки, порядок диагностики и критерии выбора между откатом и исправлением на месте. Срок: 1 октября 2026 года.

Запланировано

• Запас по размеру пула. Поднимем лимит соединений с двукратным запасом относительно пиковой нагрузки. Срок: 30 сентября 2026 года.
• Постепенная раскатка инфраструктурных конфигураций. PgBouncer и Redis будем обновлять сначала на части трафика, с автоматическим откатом при росте ошибок. Срок: 15 октября 2026 года.

Если вас это затронуло

• Если вы создавали счёт между 09:02 и 09:40 и получили ошибку, проверьте, что счёт существует. Если его нет, создайте заново.
• Если в вашем аккаунте были дубли, мы написали вам отдельно, и лишние записи уже удалены.
• Если вы видите расхождения в данных 1С или Диадока за 15 сентября, напишите в поддержку: [контакт].

Замечания редактора

Список замен

Что смягчил и почему

• Слово «ошибка» применительно к шаблону. Я не писал, кто или что её внёс, и перенёс акцент на отсутствие проверок. Это не прячет суть: сам факт ошибки в шаблоне назван прямо.
• SDK. Если это ваши SDK (судя по контексту, да), формулировка «часть клиентских SDK» читается как «виноваты клиенты». Я перенёс ответственность на сервер без идемпотентности. Если SDK сторонние, формулировку нужно поменять, но корневая причина остаётся той же.
• Извинение оставил коротким и без самобичевания. Обороты вроде «к счастью, данные не пострадали» я не использовал: отсутствие потерь указано как факт.

Расхождения в исходных данных (исправить до публикации)

1. «22 минуты от обнаружения до устранения» не сходятся с таймлайном. С 09:04 до 09:36 прошло 32 минуты. Число 22 получается от решения об откате (09:14) до 09:36. В тексте стоит 32. Публичный читатель пересчитает сам.
2. «6 минут от начала проблемы» считаются от деплоя, а клиенты видели ошибки с 09:02, то есть алерт сработал через 2 минуты. Я привёл оба интервала. Здесь цифры в вашу пользу, и их стоит показать.
3. Ошибки нормализовались в 09:36, а влияние на клиентов указано до 09:40. Объясните эти 4 минуты (кэш, повторы, долгие запросы) или выровняйте время.
4. Вебхуки. В исходнике сказано «задержка до 40 минут» и одновременно «очередь догналась к 12:40». Это 3,5 часа. Одно из двух неверно. Возможно, 40 минут составляла задержка для большинства, а хвост разбирался дольше. Тогда так и напишите.
5. Дубли. В одном месте сверка шла «до 13:00», в другом заняла у поддержки «весь день». Нужно одно время окончания, в тексте стоит плейсхолдер.

Где не хватает данных

• Почему в шаблоне оказалось 50. Это самое важное недостающее звено. Сейчас разбор останавливается на «ошибке в шаблоне». Кстати, у самого PgBouncer значение max_client_conn по умолчанию равно 100, а не 50, так что «дефолт 50», скорее всего, ваш собственный. Выясните, откуда он взялся.
• Доля ошибочных запросов. «14 000 аккаунтов получали ошибки» не говорит, падал ли каждый запрос или каждый пятый. Одна цифра («до N% запросов на создание счёта завершались ошибкой») сделает раздел о влиянии заметно сильнее.
• Не отправлены ли дубли контрагентам. Если повторный счёт успел уйти через вебхук в Диадок или 1С, удаления у вас недостаточно: документ уже у контрагента. Проверьте это первым делом. Если такие случаи были, о них нужно написать прямо и в начале.
• Обновлялась ли публичная статус-страница во время инцидента и когда. SEV1 объявили в 09:09 во «внутреннем статус-канале». Клиенты спросят, когда об инциденте узнали они.

Пробелы в мерах, которые заметят

• Нет меры против дублей. Это главная дыра. Вы описали, как дубли появились, но ничего не обещаете, чтобы это не повторилось. Любой технический читатель спросит про ключ идемпотентности на создании счёта и про политику повторов в SDK. Без срока не публикуйте, но решите этот вопрос до выхода текста: пусть в разделе будет хотя бы «ключ идемпотентности для создания счетов, срок такой-то».
• Нет меры про время деплоя. Релиз вышел за 2 минуты до пика. Правило вроде «никаких изменений инфраструктуры с 08:30 до 10:00» стоит почти ничего, а без него раздел «Почему» выглядит незавершённым.
• Откат не вернул конфиг (если это так). Мера про постепенную раскатку это частично закрывает, но стоит отдельно сказать, что откат релиза теперь возвращает и инфраструктурную конфигурацию.
• «Пул с запасом x2». Уточните, какой параметр вы меняете: max_client_conn или default_pool_size. Это разные вещи, и увеличение второго упирается в max_connections PostgreSQL. Сейчас мера сформулирована расплывчато.

Проверка на лишнее

• Имён сотрудников нет, только роли: дежурный инженер, администратор баз данных, поддержка.
• Конкретных клиентов нет. 180 названо числом.
• Финансовых оценок нет.
• Подрядчиков нет, 1С и Контур упомянуты только как направления интеграций, без претензий к ним.
• Внутренних адресов, хостов и идентификаторов нет. Имя параметра max_client_conn оставил: это публичная настройка PgBouncer, а не ваш идентификатор.
• Перед публикацией уберите маркеры [уточнить] и [проверить] и заполните плейсхолдеры: дату публикации, время окончания работы с дублями, контакт поддержки.