Ivan.Miller
New member
Пятница, 19:40, я уже мысленно открывал холодильник, когда в телефон прилетел алерт от мониторинга: время ответа базы выросло до небес, а через две минуты в общий чат посыпались скриншоты от поддержки — оплата не проходит, корзина висит на белом экране. Это был один из тех вечеров, когда от того, насколько ты собран в первые двадцать минут, зависит, закончится день спокойным ужином или объяснением с руководством в субботу утром.
Хочу честно сказать главную вещь, которую я вынес из той истории: самый дорогой рефлекс в такой момент — перезапустить кластер и посмотреть, что будет. Мы именно так и хотели поступить, но за минуту до этого я заглянул в логи и увидел ошибку про переполненный диск на основном узле. Перезапуск не помог бы, он бы просто добавил нам ещё десять минут простоя и залил логи поверх важных улик. Поэтому первое правило нашей команды теперь звучит так: сначала фиксируем факты, потом трогаем сервис. Открываем графики, смотрим, упал ли узел совсем, стал ли он только для чтения, растёт ли репликация, дошли ли до нас алерты о лагах реплик, есть ли свежий архив WAL и когда последний раз успешно проходил полный бэкап. Всё это — две-три минуты работы, а не полчаса паники.
Дальше идёт собственно чек-лист, по которому мы теперь работаем и который реально уложился в час. Объявляем инцидент в чате и назначаем одного человека, который говорит с бизнесом — он не лезет в терминал, чтобы не потерять нить. Проверяем, что видно приложению: это полный отказ подключений, ошибки только на запись или всё деградировало постепенно. Смотрим активные сессии, ждущие блокировки и самые долгие транзакции — иногда виноват один забытый скрипт аналитика, который держит блокировку и не даёт базе дышать. Проверяем свободное место, состояние архивации, лаг репликации и очередь подключений на пулере. И только после этого принимаем решение: поднимаем реплику вместо основного узла или восстанавливаемся из бэкапа на точку во времени. Это развилка, и её нельзя проходить на автопилоте, потому что за ней стоят разные цифры потери данных.
Тут нужно быть предельно честным с собой и с бизнесом. Переключение на реплику даёт вам минимальную потерю данных, но только если лаг был близок к нулю и реплика действительно здорова — об этом надо знать заранее, а не выяснять в момент аварии. Восстановление из бэкапа с прогоном архива WAL даёт гарантированную точку и предсказуемый результат, но занимает больше времени и требует свободной машины, места и проверенного скрипта. В тот вечер у нас была пятисекундная задержка репликации и целый диск бэкапов, поэтому выбрали быстрое переключение, а уже потом, ночью, спокойно искали настоящую причину. Именно поэтому мой главный совет читателям: заранее посчитайте и напишите на бумаге, что для вашего продукта хуже — потеря двадцати минут данных или потеря сорока минут доступности. Ответ будет разным для интернет-магазина, биллинга и внутренней аналитики, и в аварии думать об этом некогда.
Само восстановление, когда решение принято, — это уже техника, но тоже с подводными камнями. Мы подняли реплику, переключили её в основной режим, вернули права и последовательности, поправили конфигурацию ролей, перевели приложение на новый адрес через пул соединений и перезапустили пулер, чтобы он не держал мёртвые коннекты. Отдельно пришлось сбросить кэш на стороне бэкенда, иначе часть страниц продолжала отдавать старые данные и выглядела как вторая авария. С нуля до работающей оплаты прошло примерно пятьдесят две минуты, и примерно двадцать из них мы потратили на проверки после включения трафика: свежие записи, целостность последних заказов, отсутствие ошибок в приложении, корректные счётчики. Это время кажется потерянным, но именно оно спасло нас от повторного падения через полчаса уже на пике вечернего трафика.
Что реально помогло и что я советую наладить каждому, у кого продакшн на Postgres. Первое — регулярная проверка восстановления из бэкапа, не отчёт о том, что бэкап создался, а настоящее развёртывание на тестовой машине хотя бы раз в месяц. Второе — понятный runbook с точными шагами и именами узлов, потому что в три часа ночи никто не помнит, где лежит архив WAL. Третье — алерты не только на падение базы, но и на рост диска, на лаг репликации, на долгие транзакции и на протухшую архивацию, то есть на предвестников, а не на сам факт пожара. Четвёртое — один канал связи, один дежурный и один человек для общения с бизнесом. И пятое — разбор без поиска виноватых, на котором пишутся конкретные задачи с исполнителями и сроками, иначе через полгода вы повторите тот же вечер в том же составе.
После того вечера мы поменяли не так много, но важное: вынесли архивацию WAL на отдельный том, поставили жёсткие лимиты на пулере, добавили автопроверку бэкапов и раз в квартал устраиваем учебную тревогу с переключением на реплику на стейдже. Смешно, но команда стала спокойнее не потому, что база перестала падать, а потому что у нас появился понятный путь действий. Авария превратилась из катастрофы в скучную процедуру, и это, пожалуй, лучший комплимент инфраструктуре, который я могу придумать.
А теперь к вам, коллеги: расскажите, что в вашем чек-листе спасло вас в самый неудачный вечер — автопереключение, репетиция восстановления, наглый скрипт-спасатель или просто хладнокровный дежурный с кофе? И какой узел в вашей системе вы считаете самым хрупким перед выходными? Делитесь опытом, вместе мы точно переживём больше пятниц, чем по отдельности.
Хочу честно сказать главную вещь, которую я вынес из той истории: самый дорогой рефлекс в такой момент — перезапустить кластер и посмотреть, что будет. Мы именно так и хотели поступить, но за минуту до этого я заглянул в логи и увидел ошибку про переполненный диск на основном узле. Перезапуск не помог бы, он бы просто добавил нам ещё десять минут простоя и залил логи поверх важных улик. Поэтому первое правило нашей команды теперь звучит так: сначала фиксируем факты, потом трогаем сервис. Открываем графики, смотрим, упал ли узел совсем, стал ли он только для чтения, растёт ли репликация, дошли ли до нас алерты о лагах реплик, есть ли свежий архив WAL и когда последний раз успешно проходил полный бэкап. Всё это — две-три минуты работы, а не полчаса паники.
Дальше идёт собственно чек-лист, по которому мы теперь работаем и который реально уложился в час. Объявляем инцидент в чате и назначаем одного человека, который говорит с бизнесом — он не лезет в терминал, чтобы не потерять нить. Проверяем, что видно приложению: это полный отказ подключений, ошибки только на запись или всё деградировало постепенно. Смотрим активные сессии, ждущие блокировки и самые долгие транзакции — иногда виноват один забытый скрипт аналитика, который держит блокировку и не даёт базе дышать. Проверяем свободное место, состояние архивации, лаг репликации и очередь подключений на пулере. И только после этого принимаем решение: поднимаем реплику вместо основного узла или восстанавливаемся из бэкапа на точку во времени. Это развилка, и её нельзя проходить на автопилоте, потому что за ней стоят разные цифры потери данных.
Тут нужно быть предельно честным с собой и с бизнесом. Переключение на реплику даёт вам минимальную потерю данных, но только если лаг был близок к нулю и реплика действительно здорова — об этом надо знать заранее, а не выяснять в момент аварии. Восстановление из бэкапа с прогоном архива WAL даёт гарантированную точку и предсказуемый результат, но занимает больше времени и требует свободной машины, места и проверенного скрипта. В тот вечер у нас была пятисекундная задержка репликации и целый диск бэкапов, поэтому выбрали быстрое переключение, а уже потом, ночью, спокойно искали настоящую причину. Именно поэтому мой главный совет читателям: заранее посчитайте и напишите на бумаге, что для вашего продукта хуже — потеря двадцати минут данных или потеря сорока минут доступности. Ответ будет разным для интернет-магазина, биллинга и внутренней аналитики, и в аварии думать об этом некогда.
Само восстановление, когда решение принято, — это уже техника, но тоже с подводными камнями. Мы подняли реплику, переключили её в основной режим, вернули права и последовательности, поправили конфигурацию ролей, перевели приложение на новый адрес через пул соединений и перезапустили пулер, чтобы он не держал мёртвые коннекты. Отдельно пришлось сбросить кэш на стороне бэкенда, иначе часть страниц продолжала отдавать старые данные и выглядела как вторая авария. С нуля до работающей оплаты прошло примерно пятьдесят две минуты, и примерно двадцать из них мы потратили на проверки после включения трафика: свежие записи, целостность последних заказов, отсутствие ошибок в приложении, корректные счётчики. Это время кажется потерянным, но именно оно спасло нас от повторного падения через полчаса уже на пике вечернего трафика.
Что реально помогло и что я советую наладить каждому, у кого продакшн на Postgres. Первое — регулярная проверка восстановления из бэкапа, не отчёт о том, что бэкап создался, а настоящее развёртывание на тестовой машине хотя бы раз в месяц. Второе — понятный runbook с точными шагами и именами узлов, потому что в три часа ночи никто не помнит, где лежит архив WAL. Третье — алерты не только на падение базы, но и на рост диска, на лаг репликации, на долгие транзакции и на протухшую архивацию, то есть на предвестников, а не на сам факт пожара. Четвёртое — один канал связи, один дежурный и один человек для общения с бизнесом. И пятое — разбор без поиска виноватых, на котором пишутся конкретные задачи с исполнителями и сроками, иначе через полгода вы повторите тот же вечер в том же составе.
После того вечера мы поменяли не так много, но важное: вынесли архивацию WAL на отдельный том, поставили жёсткие лимиты на пулере, добавили автопроверку бэкапов и раз в квартал устраиваем учебную тревогу с переключением на реплику на стейдже. Смешно, но команда стала спокойнее не потому, что база перестала падать, а потому что у нас появился понятный путь действий. Авария превратилась из катастрофы в скучную процедуру, и это, пожалуй, лучший комплимент инфраструктуре, который я могу придумать.
А теперь к вам, коллеги: расскажите, что в вашем чек-листе спасло вас в самый неудачный вечер — автопереключение, репетиция восстановления, наглый скрипт-спасатель или просто хладнокровный дежурный с кофе? И какой узел в вашей системе вы считаете самым хрупким перед выходными? Делитесь опытом, вместе мы точно переживём больше пятниц, чем по отдельности.