3 ms·

> What is the actual calculation? Not answering this directly, but the paper Meaningful Availability [0] released recently really changed my opinion on how to

> What is the actual calculation? Not answering this directly, but the paper Meaningful Availability [0] released recently really changed my opinion on how to calculate and visualize availability. There's a discussion on HN as well [1]. [0]: https://www.usenix.org/system/files/nsdi20spring_hauer_prepub.pdf https://www.usenix.org/system/files/nsdi20spring_hauer_prepu... [1]: https://news.ycombinator.com/item?id=22424173 https://news.ycombinator.com/item?id=22424173

thanatropism 7y ago
That was insightful to some point. But, of course, the relevant metric is "expected availability" -- before I decide to go on the service; therefore, not the same as "customers served". If I have to think about downtime then my experience is degraded; moreso if I have to delay and batch planned interactions (all of which will later count as successful!) [Edit: To the point: a high rate of randomly-timed failures is a kind of degraded experience, but not as critical as blocky patches of downtime. A 1% rate of randomly-timed failures is much much much preferred than having the service go out three straight days every February.] Also: uptime is not the same as "customer delight". It's all about time.
- allanbreyes 7y ago
  > a high rate of randomly-timed failures is a kind of degraded experience, but not as critical as blocky patches of downtime Do you think that's an accurate generalization for all software and business contexts? I think a novel insight about the paper is that windowed user uptime is able to visualize the differences. (See Figure 20 from the paper.)
  - johannes1234321 7y ago
    It certainly is not - a trade might not care about 99% of the time, but the exact moment they want to do a trade the system must work. Whereas of some GitHub request fails and I retry it's a minor annoyance, but in most cases I won't even know whether that was GitHub's flaw, my local system or some networking in between.

thanatropism 7y ago

That was insightful to some point. But, of course, the relevant metric is "expected availability" -- before I decide to go on the service; therefore, not the same as "customers served". If I have to think about downtime then my experience is degraded; moreso if I have to delay and batch planned interactions (all of which will later count as successful!) [Edit: To the point: a high rate of randomly-timed failures is a kind of degraded experience, but not as critical as blocky patches of downtime. A 1% rate of randomly-timed failures is much much much preferred than having the service go out three straight days every February.] Also: uptime is not the same as "customer delight". It's all about time.

allanbreyes 7y ago
> a high rate of randomly-timed failures is a kind of degraded experience, but not as critical as blocky patches of downtime Do you think that's an accurate generalization for all software and business contexts? I think a novel insight about the paper is that windowed user uptime is able to visualize the differences. (See Figure 20 from the paper.)
- johannes1234321 7y ago
  It certainly is not - a trade might not care about 99% of the time, but the exact moment they want to do a trade the system must work. Whereas of some GitHub request fails and I retry it's a minor annoyance, but in most cases I won't even know whether that was GitHub's flaw, my local system or some networking in between.