4 ms·

Someone is always on call, so it’s just a case of whoa on the hook.

Juliate 6y ago
Yes, and in the long term, it's always better/more scalable/efficient to be disciplined enough to be able to have someone on call who has not designed/written the thing running.
- edoceo 6y ago
  +1! And the feedback loop on this method is awesome too. Even in short term should have different parties for Dev and Ops
- ownagefool 6y ago
  Why is that? The whole "you build it you run it" movement is an attempt to fix dev teams just not giving a fuck about quality of code they put out, especially from a reliability point of view. Why is the opposite better?
  - Juliate 6y ago
    It's a complement not an opposite. It's exactly like properly/cleverly documenting your code/project: not only for others now or in a few year, but also for yourself later on. It's having common rules across teams to get more reliability out of the whole company. You build it, you run it. Fine. Until the point when you can't anymore (because... reasons - it just happens). In any activity you want to sustain, you always have to have backups (in people and in processes), instead on relying on your-(self/team) alone.
  - pantulis 6y ago
    I guess because that enforces the documentation to be good enough so that someone without the faintest idea of what the software does can operate it. Probably this approach is more scalable specially in big companies where you can have operation teams on-call for a myriad of project. I personally believe that this does not guarantee a better service.
  - hyko 6y ago
    If your teams don’t give a fuck about the quality of their code, why would they give a fuck about the quality of their production support?
    - ownagefool 6y ago
      Because they'll be rang at 4am...
      - Juliate 6y ago
        And what happens when they (or the most competent elements of them) leave? You will need to do in a rush what could have been prepared before. A whole business takes that into account as importantly as their disaster recovery processes (which is not necessarily something you focus early on, but you eventually do).
user5994461 6y ago
Factually wrong. All developers could turn off their phone/pagers and then there's no on call anymore! The worst that can happen is that the company is down a few hours overnight. Issues can be investigated and fixed during office hours. I'd wager that most companies don't have global customers and don't need 24/7 coverage.
- sethammons 6y ago
  > the worst that can happen is the company is down for a few hours overnight I think this is a great example of why disagreements arise on HN: different world experiences and base assumptions. For many companies, being unavailable for that window of time would be catastrophic. We had one client that suffered about an hour of downtime (turned out to be their issue). They accounted that hour for 5 million dollars lost.
  - Too 6y ago
    $5M/hour can pay for a lot of engineers. So as you say - with such assumptions - you can and should pay for both up-front design, QA and people on-call, otherwise you only have your self to blame for the loss.
  - deleted 6y ago
    [deleted]

Yes, and in the long term, it's always better/more scalable/efficient to be disciplined enough to be able to have someone on call who has not designed/written the thing running.

edoceo 6y ago
+1! And the feedback loop on this method is awesome too. Even in short term should have different parties for Dev and Ops
ownagefool 6y ago
Why is that? The whole "you build it you run it" movement is an attempt to fix dev teams just not giving a fuck about quality of code they put out, especially from a reliability point of view. Why is the opposite better?
- Juliate 6y ago
  It's a complement not an opposite. It's exactly like properly/cleverly documenting your code/project: not only for others now or in a few year, but also for yourself later on. It's having common rules across teams to get more reliability out of the whole company. You build it, you run it. Fine. Until the point when you can't anymore (because... reasons - it just happens). In any activity you want to sustain, you always have to have backups (in people and in processes), instead on relying on your-(self/team) alone.
- pantulis 6y ago
  I guess because that enforces the documentation to be good enough so that someone without the faintest idea of what the software does can operate it. Probably this approach is more scalable specially in big companies where you can have operation teams on-call for a myriad of project. I personally believe that this does not guarantee a better service.
- hyko 6y ago
  If your teams don’t give a fuck about the quality of their code, why would they give a fuck about the quality of their production support?
  - ownagefool 6y ago
    Because they'll be rang at 4am...
    - Juliate 6y ago
      And what happens when they (or the most competent elements of them) leave? You will need to do in a rush what could have been prepared before. A whole business takes that into account as importantly as their disaster recovery processes (which is not necessarily something you focus early on, but you eventually do).

user5994461 6y ago

Factually wrong. All developers could turn off their phone/pagers and then there's no on call anymore! The worst that can happen is that the company is down a few hours overnight. Issues can be investigated and fixed during office hours. I'd wager that most companies don't have global customers and don't need 24/7 coverage.

sethammons 6y ago
> the worst that can happen is the company is down for a few hours overnight I think this is a great example of why disagreements arise on HN: different world experiences and base assumptions. For many companies, being unavailable for that window of time would be catastrophic. We had one client that suffered about an hour of downtime (turned out to be their issue). They accounted that hour for 5 million dollars lost.
- Too 6y ago
  $5M/hour can pay for a lot of engineers. So as you say - with such assumptions - you can and should pay for both up-front design, QA and people on-call, otherwise you only have your self to blame for the loss.
- deleted 6y ago
  [deleted]