RKemper added a comment.
With respect to the SLO itself, our goal is an SLO that captures the promise we make about service availability: namely, that WDQS is available on a **best-effort** basis. In practice, this means that if an issue arises out of "business hours", it's acceptable to wait until "business hours" to resolve it. For example, in the most extreme case, if the service were to have an outage on a Friday night, we wouldn't be paging anyone to work the night nor the weekend, but come Monday we'd be focusing our efforts on restoring availability as soon as possible. This specific scenario - a multi-day full outage - would of course be quite rare (on the order of a few times a year at most, but generally much less). Thus our uptime % goal should reflect the above reality. I think a good starting point would be 95% uptime. This means that the service could be down for 18.25 days out of a year. With that number we could have basically one full weekend outage a quarter and be within our threshold. Note that any % chosen is to some extent arbitrary. For example if WDQS were down during business hours and we weren't doing anything to try to fix it, but were still above 95% uptime, we'd be within our SLO but not actually meeting our best-effort claim. Conversely, if we were experiencing frequent weekend outages but were always getting things operational by the time the normal workweek has commenced, we could fall below our SLO's threshold while still actually meeting our own expectations for the service. But this 95% number seems like a reasonable initial target to convey our intent with this service. To be clear, in practice, at least based off current performance, I'd expect our uptime to be well over that 95% minimum bar, but the point is that the 95% threshold lets us be explicit about what kind of error budget we're allowing for. TASK DETAIL https://phabricator.wikimedia.org/T313751 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: RKemper Cc: MPhamWMF, Aklapper, Astuthiodit_1, AWesterinen, karapayneWMDE, Invadibot, maantietaja, CBogen, ItamarWMDE, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331
_______________________________________________ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
