“Read-only Friday” - не просто мем, а выстраданная мудрость поколений DevOps-инженеров. Сегодня расскажу реальные истории о том, почему деплоить в пятницу - это игра с огнём, и поделюсь правилами выживания.
Классика жанра: “Это же маленький фикс!”
История №1: CSS-правка
Пятница, 17:30
- Менеджер: “Нужно просто поменять цвет кнопки”
- Разработчик: “Это одна строчка CSS”
- DevOps: “Ладно, деплоим”
Пятница, 18:15
- CSS файл не минифицировался
- CDN закэшировал старую версию
- Половина пользователей видит сломанную вёрстку
Суббота, 02:00
- Откатываемся
- Чистим кэш CDN
- Объясняем жене, почему мы с ноутбуком в кровати
Урок
Не бывает “маленьких” изменений в пятницу. Бывают большие проблемы в выходные.
История №2: “У нас же есть тесты!”
Пятница, 16:00
# CI/CD pipeline
✓ Unit tests passed
✓ Integration tests passed
✓ Deploy to production
Пятница, 19:00
- Тесты проходят
- Мониторинг молчит
- Пользователи жалуются
Что случилось? База данных в проде была на 0.0.1 версию новее, чем в тестах. Миграция применилась криво. Данные частично потерялись.
Урок
Тесты - это хорошо. Но production всегда найдёт способ удивить.
История №3: “Откатимся за 5 минут”
Пятница, 17:00
- Деплоим новую версию
- Что-то пошло не так
- “Не волнуйтесь, у нас же есть откат!”
Пятница, 17:30
- Откат не работает (миграции БД необратимы)
- Бэкап делается раз в сутки в 03:00
- Последний бэкап - вчерашний
Понедельник
- Восстановили данные вручную
- Потеряли данные за пятницу
- Ищем новую работу
Урок
Plan B должен быть протестирован ДО того, как понадобится.
Правила выживания
1. Read-only Friday
# .gitlab-ci.yml
deploy:
script:
- |
if [ $(date +%u) -eq 5 ] && [ $(date +%H) -ge 12 ]; then
echo "🚫 Деплой в пятницу после 12:00 запрещён!"
exit 1
fi
- ./deploy.sh
2. Freeze periods
# deployment-config.yaml
freeze_periods:
- name: "Friday afternoon"
start: "Fri 14:00"
end: "Mon 09:00"
- name: "Holidays"
dates:
- "2025-12-31"
- "2025-01-01"
3. Канареечный деплой
Если уж деплоить в пятницу:
# 1% трафика на новую версию
kubectl set image deployment/app app=app:v2 --record
kubectl patch deployment app -p '{"spec":{"strategy":{"rollingUpdate":{"maxSurge":"1%"}}}}'
# Мониторим 30 минут
# Если всё ОК - раскатываем дальше
Исключения из правил
Когда МОЖНО деплоить в пятницу:
- Критический security fix - но только с одобрения всей команды
- Прод уже лежит - хуже не будет
- Feature flag - можно быстро выключить
- Только инфраструктура - без изменения кода
Когда НЕЛЬЗЯ:
- “Клиент просит” - клиент подождёт до понедельника
- “Это же быстро” - знаменитые последние слова
- “Я проверял локально” - локально != production
- Перед отпуском - вообще табу
Чек-лист для смельчаков
Если всё-таки решили деплоить:
- Вся команда в курсе и готова
- Есть план отката (проверенный!)
- Мониторинг настроен и работает
- Есть контакты всех ответственных
- Жена/муж предупреждены
- Пиво в холодильнике (понадобится)
Реальная статистика
Из моего опыта за 5 лет:
- Пятничных деплоев: 47
- Проблемных: 31 (66%)
- Потраченных выходных: 19
- Седых волос: +100500
Альтернативы
1. Feature flags
if feature_flag('new_feature'):
return new_logic()
else:
return old_logic()
Деплоим в среду, включаем в понедельник.
2. Blue-Green deployment
- Деплоим на blue в пятницу
- Тестируем в выходные
- Переключаем трафик в понедельник
3. Просто подождать
# crontab
0 9 * * MON /scripts/deploy_all_friday_changes.sh
Мудрость от старших
“Если что-то может пойти не так в пятницу - оно пойдёт не так в пятницу вечером”
- Закон Мерфи для DevOps
“Нет такой задачи, которая не может подождать до понедельника”
- Опытный тимлид
“Деплой в пятницу - это неуважение к своим выходным”
- Выгоревший DevOps
Итоги
Деплой в пятницу - это как русская рулетка. Можете выиграть, но зачем рисковать?
Помните:
- Код никуда не убежит до понедельника
- Выходные - это святое
- Репутация восстанавливается дольше, чем прод
И главное правило: Read-only Friday - это не признак слабости, а признак мудрости.
P.S. Если ваш менеджер настаивает на пятничном деплое, покажите ему эту статью. Если не поможет - обновляйте резюме (но не в пятницу!).