Goal-2022-Jan-Jun

Miraheze's Goals for the first half of 2022 (January 1st ~ June 30th).

Tasks added to this project must be at least one of the following:

a long-term project that can realistically be finished before June 30th,
a development project that will have a positive impact on Miraheze communities,
an objective for Site Reliability Engineers (infrastructure, introducing a new service, major work etc.).
MediaWiki and development tasks can be added freely by anyone assuming someone has in the past hinted at the possibility they would be willing to work on it or have a noticeable impact on communities.

Site Reliability Engineering tasks should only be added by members of the Site Reliability Engineering team as they have full control over their priorities and workflow, not subject to community benefit.

< Goal-2021-Jul-Dec | Goal-2022-Jul-Dec >

Since we've got SQL backups as well, I'd say every 3 months for XML would be reasonable

Backup schedules defined:

Private - weekly
SSL Keys - weekly
SQL - fortnightly
mediawiki-xml - MediaWiki (SRE) - can someone propose a time frame for XML dumps please? - 3 monthly?
Phabricator Static - fortnightly

root@puppet141:~/private# /usr/local/bin/miraheze-backup backup private
Starting backup of 'private' for date 2022-12-27...
Completed! This took 8.501368522644043s
root@puppet141:~/private# /usr/local/bin/miraheze-backup backup sslkeys
Starting backup of 'sslkeys' for date 2022-12-27...
Completed! This took 7.49277400970459s

Availability for the swift proxy, ac and object servers should be 99.5% I think.

@Paladox can we draft some Swift SLOs please so that we can start to monitor them before the end of this year?

Given recent events, a work around solution will be worked on and released this weekend hopefully.

In T8802#197599, @John wrote:

How is the abandoned jobs measurement to work as it’s not clear what percentage of jobs have failed?

The SLO for MediaWiki latency also looks extremely high based on the small data set available at 5s - is there a reason for this?

How is the abandoned jobs measurement to work as it’s not clear what percentage of jobs have failed?

@Reception123 @MacFan4000 All the monitoring for this task should be done now, but we need to make sure that the selected numbers here are agreed upon. Any other suggestions for it?

We could store and average the backend response times variable that we post in web requests - this would be a form of inexpensive latency monitoring

I recommend we remove latency from MediaWiki also. We don't really have a way to monitor it anymore, as I removed blackbox monitoring from MediaWiki as it seemed to make hundreds of thousands of semi-expensive, otherwise unnecessary daily requests, that seemed to actually provide ortherwise unnecessary frontend load and degradation. Backend monitoring was not worth frontend performance degradation in my opinion. I don't see any other way to really monitor latency in this case.

I got the prometheus-es-exporter working again today, for this. So we can add exceptions, etc... again, so I can do more work on this a bit later now.

DNS
- SLO: Latency for DNS lookups to be below 5ms at least 99.5%

Mail
- SLO: Availability of Mail servers to be at least 99.5%.
- SLO: Errors for sending mail is below 1%.
- SLO: Latency of message delivery is below 30 seconds.
MariaDB
- SLO: Availability of MariaDB is at least 99.5%.
- SLO: Error rates for access are below 5%.
LDAP
- SLO: Availability of LDAP to be at least 99.5%.

Proposal for some below are:

Goal-2022-Jan-JunGoal
ArchivedPublic
Watch Project

Members

Watchers

Details

Recent Activity
View All

Dec 30 2022

Dec 28 2022

Dec 27 2022

Dec 26 2022

Dec 21 2022

Dec 11 2022

Nov 25 2022

Sep 26 2022

Sep 24 2022

Sep 23 2022

Sep 20 2022

Sep 17 2022

Sep 11 2022

Sep 10 2022

Sep 9 2022

Sep 8 2022

Sep 7 2022

Sep 1 2022

Aug 21 2022

Aug 2 2022

Jul 2 2022

Goal-2022-Jan-JunGoalArchivedPublicWatch Project