5 ms·

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,

by _RPM 8y ago

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.

waz0wski 8y ago
That's ... not remotely devops 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.
- Retric 8y ago
  Devops makes this worse. When the cycle between issue discovery and new code deployment shortens enough everything becomes an emergency. 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 http://www.cc.com/video-clips/1myllo/the-miracle-of-flight
  - beat 8y ago
    Prioritization problems exist independently from release cycle problems. "Everything becomes an emergency" is a symptom of broken priorities, not fast releases. 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.
    - Retric 8y ago
      The problem is not releasing 24 hours after you start working on something. That you can plan for. 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.

by _RPM 8y ago

waz0wski 8y ago

That's ... not remotely devops 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.

Retric 8y ago
Devops makes this worse. When the cycle between issue discovery and new code deployment shortens enough everything becomes an emergency. 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 http://www.cc.com/video-clips/1myllo/the-miracle-of-flight
- beat 8y ago
  Prioritization problems exist independently from release cycle problems. "Everything becomes an emergency" is a symptom of broken priorities, not fast releases. 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.
  - Retric 8y ago
    The problem is not releasing 24 hours after you start working on something. That you can plan for. 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.