IT業界ではたまに聞く言葉です。
「金曜日にはリリースするな！」
直近ではgithubの公式アカウントが以下のツイートをしたことでさらに知名度が増したような気がします。
|￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣|
— GitHub Projects Community (@GithubProjects) July 19, 2024
| Don't Push To Production On Friday |
|＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿|
\ (•◡•) /
\ /
——
| |
|_ |_
しかしなぜ金曜日にリリースしてはいけないのでしょうか???
なぜ金曜日にリリースしてはいけないのか?
結論 : ✅リスク管理と対応リソースの観点から
金曜日にリリースするということは、次の日は土日になります。
週休二日の企業であれば通常は休みになると思いますが、当然インシデントが発生した時の対応も手薄になります。
そもそも多くの障害は構成変更/デプロイによって引き起こされます。
Googleの SRE（Site Reliability Engineering）書籍
Site Reliability Engineering: How Google Runs Production Systems によると、「多くの障害は、構成変更や新しいコードのデプロイによって引き起こされる」
構成変更（設定・フラグ切り替え・デプロイなど）を「変更（change）」と定義し、障害の主因であると明記。
これを避けるために、リリースは万全な体制で挑まなければならないのです。
1. トラブル時の対応が困難
- 金曜にリリースして問題が発生すると、土日で対応できる人が限られる。
- 担当エンジニアや関係者が休暇を取っていることも多く、即時対応ができない場合がある。
2. テストが不十分になりやすい
- 「金曜日中に終わらせたい」という心理から、テストや確認が甘くなるリスクがある。
- 特に夕方のリリースは、「金曜日の夜に問題が見つかる」→「焦ってリリース?しない?」となることが多い。
3. ユーザー影響が週末に発生する
- BtoCサービスでは、土日にユーザーが多くなることもあり、障害が大きなインパクトにつながる。
- 信頼性の低下やクレーム、ネガティブなSNS拡散など、ブランドへのダメージが発生する可能性も。
4. シンプルにインシデント対応が精神的に辛い
- トラブルが起きると、週末に呼び出される or 対応に追われることに。
- 開発者や運用担当のワークライフバランスを壊す要因になる。
まとめ
だが断る。
それでも俺は金曜日にリリースする -> 今日リリースするプロダクト。燃える様を見よ
それでは皆さん良い週末を🔥🔥🔥
