If you deploy little and often, two things happen - first, you get a lot better at it, and second, you get to a point where it's easier to fix a deployment issue and redeploy than to attempt a rollback.

If you work in or around a corporate IT department for any length of time you'll get used to hearing a lot about 'rollback strategies'. In fact "what's your rollback strategy" is pretty much the first line of defence for an old-skool ops team. No one outside the financial, military or medical industries really has a solid answer to this - it's the unicorn in the corner of most large deployment processes.

The horny spiral on unicorn is data migrations - every so often a deployment requires a change to a database schema, or some data migration, and in many cases these migrations don't have a logical rollback, beyond restoring a recent database backup (and when was the last time you actually did one of those on production data?) To all intents and purposes, a rollback in such a situation isn't practical, hence the amount of time taken to ensure that a deployment doesn't break anything.

This problem is greatly exacerbated by the anti-pattern of having deployments done according to an arbitrary schedule, instead of whenever a piece of functionality or a bug fix is ready. (IMO, even if something isn't ready, if it's safe, and it won't adversely affect the business or the user experience, it should be deployed anyway; put it behind a feature flag if you're concerned about it.)

Deploying on an ad hoc basis, when the development team is comfortable with what they have done, is the first step to reducing the stress of a live deployment. The impact of this is fairly obvious - if the development team is the same size, but you are deploying more often, then the size of each deployment is reducing. And as the size of the deployment goes down, so does the impact of any given change. And after a while you'll reach a point where each change is small enough that a.) you have a much higher degree of confidence that you actually know what's in it, and b.) it will have reduced to the point where finding and fixing any bugs is easier than starting again. At which point rollbacks will recede into the background.

If you can deploy to live without any downtime (and if you can't, ask yourself why not - things like database migrations may take the site offline, but deploying code should be zero-downtime), then you should take advantage of that fact.