If you’re at a startup this is my experience, but working for a stable company, I have not had a fire drill in my two years here.
I write software only though, I’m not doing DevOps. DevOps probably handles the fires.
I write software only though, I’m not doing DevOps. DevOps probably handles the fires.
What you're describing is a legacy, traditional, (and terrible!) 'ops will fix it' mentality that often permeates larger companies where dev teams 'throw stuff over the wall' to another team for production deployments, outage triage, etc
A company with a devops culture deeply involves both developers and operations oriented folks from the start of a project to ensure best practices, reliability, and observability are being baked in from the start, that deployments are automated, and usually developers are more directly responsible for and involved in the operations of their software rather than having dedicated 'ops' teams doing 'firefighting'
Read some of the content put out by Gene Kim or Martin Fowler for a much more in depth look at devops culture and the benefits it can bring a company.
If it’s possible for a minor change to go into production within 24 hours, everything needs to be this fast. http://www.cc.com/video-clips/1myllo/the-miracle-of-flight
If you're in the habit of doing 24 hour turnarounds, then a 24 hour turnaround is no longer an "emergency", it's just normal process. No reason to panic, or to act panicked. Emergencies are only emergencies if they interrupt work-in-progress.
The problem is when you discover something to work on and want it released in 24 hours then you are throwing away any existing schedule as you can’t plan for what you don’t know about.
Call it an emergency or just day to day operations, but the only way to work like that is to give up on the idea of a schedule of any kind.