I personally push code every Friday morning, and keep my Friday schedule relatively open so I have time to deal with any surprises.
Many successful companies brag (justifiably) about their continuous deployment systems and speed of deployment. I can't believe they suspend all of that every Friday.
If they were deploying to their entire fleet all at the same time, I would also shiver.
However, most likely that have many stages in their deployment with testing and monitoring that exponentially deploys and if any of those stages don't pass, they auto-rollback.
The End game: minimizing risk with code changes.
1. Deploying more often allows easier root cause analysis to identify the code breaking change.
2. exponential deployment allows developers to monitor their services as it partakes in more variation (more users = greater chance of edge case breaking bug)
3. proper monitoring and test coverage while using auto-rollbacks allows developers to deploy without fear as any unintended effects will be detected at the soonest possible moment while minimizing cost to the users of that breaking change. Then, auto-rollbacks will redeploy code changes that previously worked which should automatically mitigate that code breaking change.
Facebook legitimized the "move fast and break things" attitude by demonstrating that users don't care about reliability, at least nowhere near as much as some of us wish they did.