4 ms·

Such incidents remind me of 2 things 1. No matter what 99.99999999% availability a service provides, its utterly useless if the time to get back up is unaccept

Such incidents remind me of 2 things 1. No matter what 99.99999999% availability a service provides, its utterly useless if the time to get back up is unacceptable. 2. Do not have remote services, which you cannot fully control to be a part of your run time deployments.

acchow 9y ago
Uptime % includes time to recovery. Since you're not up if you're still recovering...
- hkmurakami 9y ago
  Yes. And recovery time should be tracked separately from uptime is the takeaway imo.
- ram_rar 9y ago
  But that still does not provide much inside into recovery time. Its good to know, the median recovery time.
  - solatic 9y ago
    The only time that uptime would not give insight* into recovery time is if the service is not being regularly updated (remember, zero-downtime deployments should never affect your uptime numbers), then, the uptime numbers improve over time to something really impressive but go in the toilet once the shit hits the fan. I hardly think it's reasonable to consider services like GitHub or infrastructure like AWS as being irregularly updated...
- OJFord 9y ago
  I think GP's point is that you should assume the 0.{however many 0s}1% it's down is going to be a bad time for you, and then ask yourself how long you want to wait to be back up. A long down time might be worse for you than a shorter down time more frequently.
  - paulddraper 9y ago
    I fail to see how. 99.99999999% uptime is 3 milliseconds of downtime a year. That's not even a TCP retransmission.
    - OJFord 9y ago
      Well for a start, ten nines is a lot, isn't it? If this service is up for five years, then it can go down for 15ms and still claim all ten over that period. Which is almost nothing still, but if you needed ten to begin with then maybe it's quite a lot for you. All I'm saying is - and I think this is what the commenter originally twice above me meant - is that the rate doesn't give you all the information, you at least need a period as well.
hasenj 9y ago
I can't understand why people include GitHub as a deploy time dependency. Deploying should be about pushing an already built package to the destination server(s). The idea that you push the source code then build it on the server makes no sense to me. If I was github I would forbid (and punish) this kind of behavior.

acchow 9y ago

Uptime % includes time to recovery. Since you're not up if you're still recovering...

hkmurakami 9y ago
Yes. And recovery time should be tracked separately from uptime is the takeaway imo.
ram_rar 9y ago
But that still does not provide much inside into recovery time. Its good to know, the median recovery time.
- solatic 9y ago
  The only time that uptime would not give insight* into recovery time is if the service is not being regularly updated (remember, zero-downtime deployments should never affect your uptime numbers), then, the uptime numbers improve over time to something really impressive but go in the toilet once the shit hits the fan. I hardly think it's reasonable to consider services like GitHub or infrastructure like AWS as being irregularly updated...
OJFord 9y ago
I think GP's point is that you should assume the 0.{however many 0s}1% it's down is going to be a bad time for you, and then ask yourself how long you want to wait to be back up. A long down time might be worse for you than a shorter down time more frequently.
- paulddraper 9y ago
  I fail to see how. 99.99999999% uptime is 3 milliseconds of downtime a year. That's not even a TCP retransmission.
  - OJFord 9y ago
    Well for a start, ten nines is a lot, isn't it? If this service is up for five years, then it can go down for 15ms and still claim all ten over that period. Which is almost nothing still, but if you needed ten to begin with then maybe it's quite a lot for you. All I'm saying is - and I think this is what the commenter originally twice above me meant - is that the rate doesn't give you all the information, you at least need a period as well.

hasenj 9y ago

I can't understand why people include GitHub as a deploy time dependency. Deploying should be about pushing an already built package to the destination server(s). The idea that you push the source code then build it on the server makes no sense to me. If I was github I would forbid (and punish) this kind of behavior.