111–120 of 149 posts
Earlier quoted context omitted.
changes = downtime. Has been since the advent of computing
Not if you have a competent devops team and a deployment pipeline.
But well, no QA effort is complete enough to really assure the quality of a large system. Thus, the GP holds true.
Taking the numbers at their face value this is a good exercise in some text book statistical test of hypothesis. Incidents: Before 89. After 126. What is the chance of this happening if the 'rate' of occurrence has not changed ? Assuming an unknown but constant Poisson rate, we get the probability of observing what has been observed to be 0.00225. A fortuitous thing about this test is that one does not need to know w…
Maybe Github has grown significantly since then. More complexity, more down time.
Taking the numbers at their face value this is a good exercise in some text book statistical test of hypothesis. Incidents: Before 89. After 126. What is the chance of this happening if the 'rate' of occurrence has not changed ? Assuming an unknown but constant Poisson rate, we get the probability of observing what has been observed to be 0.00225. A fortuitous thing about this test is that one does not need to know w…
Maybe Github has grown significantly since then. More complexity, more down time.
Earlier quoted context omitted.
> Assuming a Poisson rate That feels like a mighty big assumption. Probably big enough that trying to calculate the probability is more misleading than enlightening.
As I mentioned, my comment is meant as an exercise. If we were to take the numbers more seriously, due diligence is necessary. That said, if we assume that one incident does not affect the other, then the Poisson nature falls out as a natural consequence of that independence and the assumption of a constant rate (our Null hypothesis). As long as the incidents are spaced out enough, that the possibility of one inciden…
Earlier quoted context omitted.
Man, I really want to say we don't because of the implications of too centralised an internet, but there's no way it isn't a transitive dependency.
What the hell are you building that there has to be Cloudflare in the dependency tree at some point?
We'd have to basically quadruple our expenses without CF. Not to mention their available protections.
Earlier quoted context omitted.
changes = downtime. Has been since the advent of computing
Not if you have a competent devops team and a deployment pipeline.
Testing something 100% has diminishing returns.
Therefore -> you will never be able to prevent all issues. As you are not aware how many changes are happening, you don't have a value which could indicate the healthiness of it.
I personally think that when i'm getting older and better in my job, i still make errors, the amount and severity is going down though.