Начну с признания: я много лет искренне верил, что падения прода в пятницу вечером — это злая шутка вселенной. Ну не может же быть совпадением, что именно в тот момент, когда я уже мысленно еду домой, а в сумке лежит бутылка чего-нибудь холодного, телефон начинает вибрировать. Прошло несколько лет, три команды и примерно два десятка инцидентов — и теперь я точно знаю: совпадений тут нет. Пятничный вечерний инцидент почти всегда не случайность, а отложенный результат решений, принятых в течение недели. Расскажу про пять причин, которые я видел своими глазами, и про то, как мы их в итоге выкорчёвывали.
Причина первая — релизы в пятницу. Классика жанра: всю неделю спорили, согласовывали, ждали финальный фикс, и деплой приезжает в прод ровно в последний рабочий день. Дальше работает закон Мёрфи: новая версия спокойно живёт под низкой дневной нагрузкой, а к вечеру, когда люди массово приходят после работы, вылезает всё, что не поймали на стейдже. Мы ввели простую вещь: заморозка релизов по пятницам после обеда. Сначала команда ныла, что мы теряем скорость. Потом посчитали, сколько времени съедали ночные разборы, и нытьё прекратилось само собой.
Причина вторая — деплой руками и по памяти. Это самая обидная история, потому что она вообще не про код. Один человек знает, что нужно зайти на сервер, поправить конфиг, перезапустить сервис именно в этом порядке и не забыть про кэш. Пока он в отпуске или просто уставший вечером — порядок ломается, и вот у нас рассинхрон конфигов. Лечится скучно и надёжно: деплой только из CI, конфиги в репозитории, никаких правок на боевой машине. Если шаг нельзя автоматизировать, его как минимум надо записать в чек-лист.
Причина третья — отложенные задачи, которые срабатывают в конце недели. У нас так падала база от ночного бэкапа, который совпал с еженедельным отчётом по расписанию. Два тяжёлых процесса, разнесённых по времени в теории, встретились в пятницу в реальности, и диск ушёл в полку. С тех пор у нас есть правило: все cron-задачи, бэкапы и ротации живут в одном реестре с указанием времени запуска и потребляемых ресурсов. И да, бэкап, который никто ни разу не восстанавливал, я бэкапом не считаю — мы раз в месяц реально поднимаем из него окружение.
Причина четвёртая — вечерний пик плюс отсутствие предохранителей. Днём трафик ровный и добрый, вечером приходит волна, а у сервиса нет нормальных таймаутов, лимитов и деградации. Один медленный внешний API — и пул соединений забит, а следом падает всё подряд, хотя формально ничего не менялось. Здесь очень помогает простой мысленный эксперимент: что будет, если этот вызов начнёт отвечать не за сто миллисекунд, а за тридцать секунд? Если ответ звучит как всё умрёт — у вас есть что починить, и лучше починить это в среду, а не в пятницу.
Причина пятая — человеческий фактор и усталость. Самая вредная правка за всю мою практику была сделана по принципу «это на минутку, потом нормально переделаем». Фиче-флаг, который включили руками перед выходными. Пароль, который обновили в двух местах из трёх. И самое главное — отсутствие дежурного, которому есть куда позвонить и у которого есть понятный порядок действий. Когда инцидент начинается, а в чате все спрашивают друг у друга, что происходит, — вы теряете не пять минут, а час.
Что в итоге помогло мне лично. Короткий список: заморозка релизов перед выходными, деплой только через автоматику, канареечная выкатка на часть трафика, фича-флаги вместо срочных правок, алерты на бизнес-метрики, а не только на железо, живое дежурство с порядком действий и разбор инцидента без поиска виноватых. Отдельный пункт — разрешить себе останавливаться. Я несколько раз отменял пятничный релиз в последний момент, и ни разу об этом не пожалел.
Итог простой: пятничный вечер перестаёт быть минным полем ровно тогда, когда ты убираешь не сам инцидент, а условия, при которых он стал возможен. Прод не мстительный, он просто честно показывает всё, что вы отложили на потом. А теперь вопрос к вам, форумчане: какая причина падений в конце недели была вашей самой болезненной — и что в вашей команде реально спасло положение? Делитесь историями, вместе мы точно найдём ещё пару рецептов.
Причина первая — релизы в пятницу. Классика жанра: всю неделю спорили, согласовывали, ждали финальный фикс, и деплой приезжает в прод ровно в последний рабочий день. Дальше работает закон Мёрфи: новая версия спокойно живёт под низкой дневной нагрузкой, а к вечеру, когда люди массово приходят после работы, вылезает всё, что не поймали на стейдже. Мы ввели простую вещь: заморозка релизов по пятницам после обеда. Сначала команда ныла, что мы теряем скорость. Потом посчитали, сколько времени съедали ночные разборы, и нытьё прекратилось само собой.
Причина вторая — деплой руками и по памяти. Это самая обидная история, потому что она вообще не про код. Один человек знает, что нужно зайти на сервер, поправить конфиг, перезапустить сервис именно в этом порядке и не забыть про кэш. Пока он в отпуске или просто уставший вечером — порядок ломается, и вот у нас рассинхрон конфигов. Лечится скучно и надёжно: деплой только из CI, конфиги в репозитории, никаких правок на боевой машине. Если шаг нельзя автоматизировать, его как минимум надо записать в чек-лист.
Причина третья — отложенные задачи, которые срабатывают в конце недели. У нас так падала база от ночного бэкапа, который совпал с еженедельным отчётом по расписанию. Два тяжёлых процесса, разнесённых по времени в теории, встретились в пятницу в реальности, и диск ушёл в полку. С тех пор у нас есть правило: все cron-задачи, бэкапы и ротации живут в одном реестре с указанием времени запуска и потребляемых ресурсов. И да, бэкап, который никто ни разу не восстанавливал, я бэкапом не считаю — мы раз в месяц реально поднимаем из него окружение.
Причина четвёртая — вечерний пик плюс отсутствие предохранителей. Днём трафик ровный и добрый, вечером приходит волна, а у сервиса нет нормальных таймаутов, лимитов и деградации. Один медленный внешний API — и пул соединений забит, а следом падает всё подряд, хотя формально ничего не менялось. Здесь очень помогает простой мысленный эксперимент: что будет, если этот вызов начнёт отвечать не за сто миллисекунд, а за тридцать секунд? Если ответ звучит как всё умрёт — у вас есть что починить, и лучше починить это в среду, а не в пятницу.
Причина пятая — человеческий фактор и усталость. Самая вредная правка за всю мою практику была сделана по принципу «это на минутку, потом нормально переделаем». Фиче-флаг, который включили руками перед выходными. Пароль, который обновили в двух местах из трёх. И самое главное — отсутствие дежурного, которому есть куда позвонить и у которого есть понятный порядок действий. Когда инцидент начинается, а в чате все спрашивают друг у друга, что происходит, — вы теряете не пять минут, а час.
Что в итоге помогло мне лично. Короткий список: заморозка релизов перед выходными, деплой только через автоматику, канареечная выкатка на часть трафика, фича-флаги вместо срочных правок, алерты на бизнес-метрики, а не только на железо, живое дежурство с порядком действий и разбор инцидента без поиска виноватых. Отдельный пункт — разрешить себе останавливаться. Я несколько раз отменял пятничный релиз в последний момент, и ни разу об этом не пожалел.
Итог простой: пятничный вечер перестаёт быть минным полем ровно тогда, когда ты убираешь не сам инцидент, а условия, при которых он стал возможен. Прод не мстительный, он просто честно показывает всё, что вы отложили на потом. А теперь вопрос к вам, форумчане: какая причина падений в конце недели была вашей самой болезненной — и что в вашей команде реально спасло положение? Делитесь историями, вместе мы точно найдём ещё пару рецептов.