 Hallo. Willkommen zur Wikipak-OK. Hallo. Ich höre... ja, ja. Wir heißen die drei Jungs hier. Willkommen, die über die Infrastruktur von Wikipedia reden werden. Lukas, Amir und Daniel sprechen. Genau. Hoffentlich habt ihr Spaß. Hallo. Mein Name ist Amir. Ich bin ein Software-Engineer bei Wikimedia Deutschland. Lukas ist auch Software-Engineer bei Wikimedia Deutschland. Und Daniel ist Software-Architekt in Berlin, Leipzig und Berlin. Heute reden wir darüber, wie Wikipedia betrieben wird mit wenig Geld und keine Werbung und ohne Datenkollektion. Wir reden zuerst über die Application Layer und die äußeren Layers und dann gehen wir in die tieferen Ebenen von Wikipedia. Es geht darum, wie Anfragen verarbeitet werden von außen. Grundsätzlich Informationen über Wikimedia und Wikipedia. Also, die Wikipedia-Infrastruktur ist für den Wikimedia-Foundation non-profit betrieben. Es sind circa 370 Personen. Es sind ungefähr 500 Personen. Wenn man alles zusammenzählt, der ganze Content ist, der ganze Inhalt wird von Freiwilligen verarbeitet, Menschen, die Sachen, also was beifügen. Es werden 304 Sprachen gehostet und es ist ein paar Jahre, also 18 Jahre alt. Und es gibt sehr viele, viele Artikel, zum Beispiel. Was ist der verrückteste Artikel, den ihr habt, über das Schrägste, was man bekommen hat, was ihr kennt, sind Menschen, die auf Toiletten gestorben sind. Wer von euch kennt die verrückte Artikel, was ist das verrückteste für euch? Wir haben Mikrofonprobleme. Menschen, die von ihrer eigenen Erfindung getötet wurden. Es gibt eine Liste von Gefängnisausbrüchen mit Helikoptern. Es gibt eine Liste von Listen von Listen, also die drei. Und alle drei Monate wird diese Liste von Listen von Listen verlinkt mit Russells Paradox. Manche, also sie können in Turkey, das gibt Artikel, die nicht in manchen Ländern gelesen werden können. Hier seht ihr eine Liste von den Wikimedia Projekten, manche von denen sind nicht so berühmt wie Wikipedia. Wikipedia ist das berühmteste. Es gibt dann auch noch Wikidata. Und der Hauptnutzen von diesem Projekt ist, die Daten zu verwalten, die Wikipedia benutzt. Also unsere Infrastruktur, also unsere Infrastruktur ist alles Open Source. Wir könnten ganz viele unterschiedliche Dinge benutzen, manche werden uns sogar gratis angeboten, aber wir entscheiden uns dagegen, sie zu benutzen. Wir haben zwei Hauptdatacenter, um Ausfälle zu vermeiden. Wir haben drei Caching Points of Presence. Wir benutzen nicht Cloudflare, um die Privatsphäre der Benutzer zu schützen. Zum Beispiel, wenn sie aus Ländern kommen, wo es gefährlich für sie ist, in der Wikipedia-Content zu editieren. Wir haben 17 Milliarden Anfragen an Seiten per Monat. Wir haben 100.000 bis 2.000 Anfragen in der Sekunde, was unterschiedlich ist zu den Pageviews. Wir haben 300.000 neue Zitronen per Monat und 1.300 echter Hardware-Server. Daniel wird uns über die Anwendungsschicht erzählen. Die Anwendungsschicht ist die Software, die das macht, was die Wikimacht. Das sind unsere Page-Clicks und unsere Updates. Die Herausforderung für Wikipedia ist es, all diese Seiten an die Benutzer zu verteilen. Es ist eine klassische Lamp-Applikation. Es läuft auf einem Apache Server, hat MySQL als Datenbank backend. Wir hatten HHVM als PHP-Engine, aber wir haben zurück zum mainstream PHP gewechselt und benutzen PHP 7.2, weil Facebook entschieden hat, dass das nicht mehr dem Standard entspricht und sie selbst weiterentwickeln. Wir haben mehrere Cluster von Servern, um Pageviews, aber auch Edits zu handeln. Wir haben einen Teil von den Servern, um Assinkrone zu arbeiten, Sachen im Background und im Hintergrund, beispielsweise Videoscaling zu kümmern, was zu langsam ist, um es unter Flight zu machen. MediaFiki ist ein ziemlich beeindruckendes Ding, weil ihr es einfach bei euch installieren könnt und das funktioniert dann bei euch. Aber ihr könnt das dann auch benutzen, um die halbe Welt zu bedienen, was sehr kraftvoll ist. Natürlich ist auch diese breite Anwendung, kann auch Probleme generieren. Darüber reden wir morgen, aber heute gehen wir über die Lustigen Dinge. Wenn ihr viele Pageviews bedienen wollt, dann müsst ihr ganz viel Caching machen. Also wir haben ein ganzes Menge an unterschiedlichem Caching-System. Das Wichtigste ist vermutlich der Browsercache. Wie ihr bestimmt wisst, werden die Seiten in der Markup-Sprache Wikitext genugiert. Und das Resultat von diesem Parsing wird dann gecached. Und dieser Cache ist semi-persistent, es fällt eigentlich nie etwas dabei raus. Und es ist ein gigantisches Ding und lebt in einem eigens dafür dedizierten System. Wir haben einen Cache für alles, für unterschiedliche Dinge. Wir haben auch eine Weile Redis benutzt. Redis ist ein bisschen besser, um Dinge zwischen unterschiedlichen Systemen zu zirkulieren. Wir benutzen das immer noch als Session Storage. Aber wir sind gerade da weit davon, uns weg zu bewegen hin zu Cassandra für Session Storage. Wir haben eine Reihe von zusätzlichen Surfaces, die laufen für sehr spezialisierte Anwendungen. Zum Beispiel für Skalien von Bildern, das Rendering von mathematischen Formeln. OAS ist sehr interessant, OAS ist ein System, um Vandalismus zu detektieren. Das ist ein Maschinenlearning-basiertes System, um Edits herauszufinden, die nicht wirklich großartig sind und mehr Aufmerksamkeit erfordern. Wir haben noch andere Surfaces, die unseren Content auf mobilen Geräten verwalten und noch viele andere. Im Hintergrund müssen wir auch Events managen. Wir benutzen Kafka für Message Queuing. Wir benutzen das, um unterschiedliche Teile des Systemes darüber zu informieren. Zum Beispiel für die... Aber wir benutzen es aber auch zum Beispiel für Einträge, die geupdatet werden müssen im CDN. Der nächste Teil wird über die Datenbanken gehen. Ganz kurz, wir haben nachher viel Zeit für Fragen. Gibt es im Moment irgendwelche Fragen? Ist alles sehr verständlich. Eine Frage im Hintergrund? Können wir vielleicht das Mikrolauter stellen? Danke. Ich denke, das ist dein Teil. Ich will über mein Lieblings-Thema reden. Das Dungeon von allen Produktionssystemen, die Daten banken. Wir benutzen MariaDB. Wir sind von MySQL zu MariaDB gewechselt. Wir sind sehr open source. Ihr könnt euch nur den Datenbankenbaum aussuchen. Ihr könnt euch auch live die Datenbank anziehen. Hier ist der Link. Vor ein paar Monaten habe ich eine Anfrage gekriegt. Wir haben einen Security-Problem gefunden. Das haben wir dann behoben. Wenn ihr sehen wollt, wie die Datenbankencluster aussehen, sind jetzt aufgeteilt in Sections. Ganz große Wikis haben jetzt ihre eigene Sektion. Beispielsweise die englische Wikipedia ist eine Sektion. Die deutsche Wikipedia ist zusammen mit anderen. Alle Sections haben ein Master und mehrere Repliken. Diese Repliken sind selber wie der Master in anderen, um Datenausfalt zu verhindern. Wir haben unterschiedliche Datenbanken für den Wikitext. Wikipedia speichert jede Edition. Also müssen wir das alles auch abspeichern. Für Metadata ist das etwas komplizierter. Metadata wird benutzt, um die Seite anzuzeigen. Um das zu machen, ist das hier eine sehr einfache Version von dem, was passiert. Das ist S1. Der Master ist diese Zahl und das repliziert dann auf diese Sachen, die ihr sehen könnt. Das ist dann in einem anderen Datencenter und ist selber wie der Master von etwas anderem. Er hat seine eigene Repliken. Wir haben diese Repliken und der Master hier ist in Virginia. Das zweite Datencenter ist in Dallas. Die brauchen dann eine Quasi-Segreplikation und TLS, um zu verändern, dass andere Leute da hinein hören. Wir haben Snapshots und dann haben wir noch Dumps von Wikipedia, die ihr auch auf der Seite dort downloaden könnt. Außer die, die wir aus Privatsparengründen löschen müssen. Und wir haben viele und viele Backups. Und im Wahlkampf zusammenfassend haben wir 570 Terabyte an Daten, 150 Datenbank-Server, 350.000 Quarries in der Sekunde und 20 Terabyte an Raum. Wir haben auch den LSD Search. Du kannst dir, ihr könnt euch vorstellen, dass es um Suche geht. Und auch ganz oben rechts gibt es da dieses Feld, wo man das Ding, auch beim Mobile Ding und je nach dem von Sprache ist das auch. Da gibt es ein eigenes Team, das von der Suchplattform ist. Die Leute, die hier sind, sind nicht von dieser Suchplattform. Aber die anderen könnten das besser erklären. Wir haben auch einen Medienspeicher. Und wir haben eine, eine, eine Kategorie in Comments. Wir haben eine, wir haben eine Kategorie, wo Katzen nach links schauen und Katzen nach rechts schauen. Also es gibt sehr, sehr viele Kategorien. Und es gibt unglaublich viele Medien und sehr, sehr viele Objekte, eine Billion Objekte. It's an OpenStack object, sorry. Es gibt verschiedene Caches, Frontend, Backend. Und wir wollen auch über Traffic reden, Website Traffic. Das Bild ist Schweden in 1970. Autos, die von der linken auf die rechte Seite fahren. Es gibt fünf Caching-Ebenen. Eine in Singapur. Es gibt eben verschiedene Noten. Es gibt eine in Points of Presence in Chicago und in Amsterdam. Wir haben unser eigenes Inhalts-Netzwerk. Der Traffic wird von GODNS gemanagt. Von den Traffic-Leuten wird das geschrieben. Und man kann das Pool, also zusammenfassen und auseinandernehmen. Es gibt LVS, ist die Transport Layer. Die Layer 3 und 3 und 4 von Linux. Es geht um konsistentes Hashing. Wir brauchen sogar etwas, das den Load-Balance Manage, weil das Ganze so groß geworden ist. Es gibt einige Firmen, die mit uns kooperieren. So funktioniert das Caching an TLS. 2.0 wird verwendet. Die erste Ebene ist Engine X minus. Weißt jemand, was das ist? Wir haben Engine X, ist die Free Version. Engine X plus ist die kommerzielle Version. In Engine X, wir verwenden Engine X minus. Wir haben das weggenommen, was wir nicht brauchen und wenn wir das minus. Die Warnisch ist eine Frontend Caching Layer. Das ist eine Memory. Die Warnisch ist beckend. Das ist langsamer. Warnisch Caching verwendet 90% des Cachings. Die Application Layer hat eine TTL von 24 Stunden. Wenn das geändert wird, wird das auch invalid. Wenn das Frontend das nicht findet, geschickt es an das Backend. Wir haben zwei Caching-Klasse. Der eine ist Text, der andere ist Upload. Das ist überhaupt nicht verwirrend. Wir haben zwei Caching-Klasse. Der andere ist Text, der andere ist Upload. Das ist überhaupt nicht verwirrend. Das ist eine Caching-Klasse. Das ist eine Caching-Klasse. Das ist überhaupt nicht verwirrend. Wenn ihr rausfindet, ihr könnt einfach nur leeres. Aber wenn ihr auf Upload geht, dann kommt ihr auf den Upload Cluster. Es gibt viele Probleme, weil ein Warnisch ist Open Core. Die Version, die wir benutzen, ist Open Source und nicht die Commerciale. Aber die Open Core Version unterstützt kein TLS. So, Verzeihung. Warnisch hat viele Probleme. Es ist Open Core. Es unterstützt kein TLS-Termination. Deswegen haben wir das Engine X Minus System, nur um das TLS-Termination zu machen. Das führt dann dazu, dass wir einen Grundjob haben, der alle Warnisch-Notes zweimal in der Woche neu starten muss, was sehr peinlich ist. Auf der anderen Seite, in der Anwendungsschicht haben wir im Backend-Warnisch auch kein TLS. Was heißt, dass wir IPsec benutzen, was auch ein bisschen peinlich ist. Aber wir ändern das gerade. Wir benutzen ETS. ETS macht das TLS. Und im Moment haben wir noch ein Warnisch-Frontend, was noch existiert. Aber auch das Backend wird sich ändern zu ETS. Also, wir nennen das das ETS Sandwich. Die gute Sache ist, die TLS-Termination mit ETS kann TLS 1.3 benutzen, was moderner, sicherer und schneller ist. Und damit wird Zeit von allen Anfragen gespart und damit von unseren Nutzern. Hoffentlich wird das bald live gehen. Also, das ist die neue Version. Wie ich gesagt habe, das TLS, das können wir dann benutzen und das sicherere Nehmen statt IPsec. Ja. Und jetzt ist es an der Zeit, was passiert, wenn ihr Wikipedia.org eintippt. Also, was ihr seht, dieses Bild hat überhaupt nichts damit zu tun, was passiert, wenn ihr Wikipedia.org eintippt. Das ist ein offline Wikipedia-Leser. So, wenn ihr wie im meisten Fällen ein Get macht und eure Anfrage ist gecached, dann fragt euer Computer nach der IP-Adresse und dann sagt es euch, weil wir hier auf dem Kongo sind, das nächste Datacenter ist in Amsterdam. Das erreicht dann Edge und dann geht es durch die TLS-Termination von nginx-minus. Dann erreicht es den Warnisch-Cache-Server entweder im Frontend oder im Backend. Da bekommt ihr dann die Antwort heraus und das propagiert also überhaupt nicht dann irgendein anderes Datacenter weiter und das ist ganz nett. Das ist der Großteil der Anfragen, die wir kriegen. Wenn ihr Pech habt und eure Anfrage ist nicht im Warnisch-Cache vom Amsterdam-Zentrum, dann wird es weiter geschickt und das erste Datacenter wird da auch den Cache erreichen und dann kriegt ihr darüber die Antwort und wir müssen immer noch keine Anwendungssachen machen. Wenn auch dann nichts davon kommt, dann kommt es auf mediaviki.org und dann wird mediaviki ganz viel Arbeit machen, um mit der Datenbank zu reden. In dem Fall mit dem ersten Chart von der englischen Wikipedia die Seite raus. Nein, ich habe etwas vergessen. Erst wird es noch gucken, ob die HTML-Seite im Browser-Cache verfügbar ist. Wenn das entweder Mem-Cache oder Database-Cache, Datenbank-Cache ist und nur in dem Fall, wo es das nicht ist, dann wird es alles raussuchen, was nötig ist und den Text und die Seite rendern. Und wenn ja ein Edit oder ein Upload macht, dann ist es noch viel schlimmer, weil dann muss es immer über mediaviki gehen. Dann muss es diese neuen Edit-Speichern entweder im Media-Backend oder in den Datenbanken. Aber dann muss es auch noch andere Dinge machen. Zuerst muss es die Caches alle lernen. Es muss allen Sachen, dass neue Seiten eine neue Version von dieser Seite gibt. Es muss auch eine ganze Menge updaten. Wenn es zum Beispiel eine Template ist, die editiert, dann ist die in ganz vielen Seiten verwendet worden. Dann müssen alle diese Seiten neu gerendert werden, um die neue Version von der Template zu benutzen. Also muss es die Caches für all diese Seiten invalidieren. Wenn es eine Datei ist, muss es vielleicht Fumpnails generieren und muss neue Mediafalls generieren. Vielleicht weil ihr ein Webm-Herf hochgeladen habt und muss dann andere Dinge generieren. Und dann muss es durch diese ganzen Sachen durch. Jetzt erklären wir, wie wir das alles verwalten. Um 1300 Bermetel-Cluster zu managen, ist es nicht einfach. Was wir benutzen, ist Puppet um die Konfiguration zu managen. Wir haben 50.000 Zeilen von Puppetcode. Damit kriegt ihr ein Gefühl dafür, wie viel das ist. 100.000 Zeilen von Ruby. Wir speichern nicht so auf GitHub oder GitLab. Wir haben unser eigenes System. Und für das haben wir ein Jenkins-System. Das macht alle möglichen Dinge. Wir haben noch ein Kubernetes-Cluster für manche von unseren Service. Wenn wir also eine Änderung in Gerrit macht, dann generiert das Stacker-Felds und die werden dann in die Produktion gepusht. Wir haben Cummin. Das haben wir gebaut, unser Automatisierungstool. Das haben wir gebaut für uns. Das managen automatisch alle Noten, von denen ich vorhin geredet habe. Ich werde jetzt ein bisschen über die Wikimedia Cloud Service gehen. Die sind ein bisschen anders, weil es ist nicht wirklich unser Produktionszeug, sondern das ist, wo ihr Leute, also alle freiwilligen Sachen machen könnt. Da habt ihr dann ein Pool von Sachen, die dann Gruppen von Nutzer und zugeordnet werden können. Und dann könnt ihr da euer Zeug machen. Und da könnt ihr dann auch laufen lassen, was auch immer ihr wollt, um die virtuellen Maschinen zu starten, laufen zu lassen und zu stoppen, benutzen. Intern managen wir unsere virtuellen Maschinen mit Puppets, aber viele Leute machen es auch per Hand. Und dann gibt es größere Projekte, wie zum Beispiel Toolforge, für eure eigenen Web-Base-Tools laufen lassen könnt. Dann gibt es Beta, die alle mehr oder weniger die gleiche Konfiguration benutzen, aber die aktuelle Masterversion von der Software benutzen. Und anstelle von dem, was wir einmal in der Woche deployen, sodass wir hoffentlich Bugs frühzeitig sehen. Und wir müssen auch irgendwo auf diesen Slides-Kybernitis haben, damit könnt ihr, das könnt ihr benutzen, um Arbeit zu verteilen auf den unterschiedlichen Sachen. Die aktuelle Fog, die wir benutzen, ist Sun Grid Engine. Und ich weiß nicht, wie die vorher hieß. Also zusammengefasst, sind das unsere Systeme. Wir haben 1.300 Surfaces mit vielen, vielen Layer-Schichten von Caching. Wir können die nicht alle als eine gecached Version behalten. Alles, das ist Open Source. Ihr könnt euch da gerne beteiligen. Und das ist die Art, wie ich eingestellt wurde. Ich habe angefangen, mich an den Projekten zu beteiligen, und mir wurde dann angeboten, dass ich für sie arbeiten kann. Das ist eigentlich genauso, wie wir alle angestellt wurden. Also das ist alles, was in Wikimedia passiert. Wenn ihr uns helfen wollt, für heueren Leute an, ihr könnt euch auf jobs.wikimedia.org gucken. Wenn ihr für die deutsche Seite arbeiten wollt, könnt ihr auf die Wikimedia.de Seite gehen. Wenn ihr uns helfen wollt, wir haben so viele Arten, wie ihr das machen könnt. Wir haben so viele Bugs, die euch anschauen könnt. Ihr könnt euch das einfach nur da ansehen. Und Fabrikate ist unser Backträger. Ihr könnt euch da einen Back ansehen und den dann fixen. Wir haben ein Repo, das ist privat. Aber das hält halt die Zertifikate für TLS und alles, die sind halt privat. Aber die Dokumentation, die Dokumentation ist auch online. Und die Dokumentation für MediaFiki ist auf mediafiki.org. Und wir haben auch einen Link auf die Donate-Seite gemacht. Wenn ihr irgendwelche Fragen habt, bitte. Wir haben ein paar Zeit für Fragen. Eine Frage. Haben Sie Probleme mit Hackerattacken? Das ist nicht in der Präsentation. Die erste Regel von Sicherheitsproblemen ist, wir reden nicht über Sicherheitsprobleme. Aber ja, lasst uns sagen, wir haben sehr viele Angriffe, die passieren. Wir hatten einmal vor ein paar Monaten einen erfolgreichen Angriff. Aber wir haben eine Infrastruktur dafür, wir haben ein Sicherheitsteam, das sich um sowas kümmert. Wir haben eine LDAP-Gruppe. Und wir haben die LDAP für die webbasierten Systeme. Wir haben strikte Protokolle. Man kriegt einen Private Key. Und dann sichern Leute ihre Private Keys als Ubic Keys. Es gibt einen Server als Datacenter, wo man über SSR draufkommt. Und dann muss man darüber gehen, um auf die anderen Inhalte zuzugreifen. Wenn ihr im Inneren der Produktion seid, dann könnt ihr nicht mehr mit der äußeren Welt drehen. Es kann nur noch Dinge von innerhalb der Produktion, auf Dinge von innerhalb der Produktion zugreifen. Gibt es zu Aufrufe ohne HTTPS? Ja. Wir haben angefangen, schon länger nicht mehr HTTPS Protokolle zu behandeln. Und auch keine SSL mehr. Und TLS 1.0 auch. Und bitte benutzt diese tolle neue Technologien, die etwa vor zehn Jahren herausgekommen sind. Und die Deadline davon ist dann im Februar und danach nur noch 1.2. Gibt Reed-only Zugang von Usern bis zu dem Browser-Cache durch? Ja, wir umgehen all diese Sachen. Ja, das tut es. Ja, und das ist ein sehr großes Problem und etwas, um das für uns zu kümmern wollen. Aber es benötigt sehr viel Umstrukturierung der Architektur. Wenn ihr daran interessiert seid, einen Grund, warum wir, was wir planen, ist aktiv-active. Also, dass die Leser an Fragen, an direkt durchgehen, an das zweite Datensinn. Ich habe eine Frage. Verwendet ihr Gannetti als Visualization-Plattform? Könnt ihr mir darüber sagen, welche Teile sind gehostet auf der Plattform? Ich bin mir da jetzt nicht sehr sicher, soweit ich das weiß, sind das sehr kleine virtuelle Maschinen in Produktion, die wir auf sehr kleine Mikroseiten benutzen, die wir dann benutzen und servieren. Denkt über Open Hardware nach? Nein, nicht für Server. Ich denke für das Offline-Reader-Projekt, aber das ist nicht etwas, was das Wikimedia-Projekt das macht. Aber Open Hardware in der Praxis heißt, dass wenn man bis runter zum Chip-Design geht, dann ist das sehr hart und nicht praktizierbar, leider. Eine Sache dazu, manche von unseren Maschinen sind sehr, sehr kräftig und die geben wir unseren Vorschon für Analyse. Und wir brauchen GPUs für das, aber dafür gibt es keine Open Source Treiber. Und da sind wir dann migriert und haben dann AMD benutzt. Und das war dann ein Problem mit den Wechs. Ich bin beeindruckt, dass 90 Prozent aus der Cache kommen. Ich bin beeindruckt. Rufen die alle die gleichen Seiten auf oder geht es darum, dass einfach so viel gecached ist? Wie viel Anteil von der Datenbank ist in der Cache? Ich habe keine exakten Zahlen, aber ein großer Prozentsersatz von der ganzen Datenbank ist im Cache. Und der neue ist alle und sehr obskurre Sachen sind auch da. Und es ist eine Power Law-Distribution. Viele Seiten werden sehr häufig angerufen und sehr, sehr viele Seiten werden gar nicht aufgerufen in der Woche, außer zum Beispiel durch ein Qualer. Ich weiß keine Zahlen, aber ich würde sagen, weniger als 50 Prozent sind tatsächlich gecached. Aber ich sollte mir das ansehen, das sind eigentlich wirklich interessante Zahlen. Weißt du, ob das 90 Prozent von den Pages oder von den Get-Requests sind? Ich würde davon ausgehen, dass für nicht-Page-Füße es sogar noch viel höher ist, weil ich kann dann JavaScript-Anfragen für CSS-Stellen dieser Channis ändern. Ja, da wird es um über 90 Prozent sein. Arbeiten eure Datenzentren mit grüner Energie? Gute Frage, die das Amsterdam-Daten-Center ist vollgrün. Aber die anderen sind zum Teil coole und zum Teil Gas. So weit ich das weiß, es gibt es Pläne, um die davon zu entfernen. Aber der Hauptteil ist, das Wichtigste ist, wir emigrieren gar nicht so furchtbar viel Kohlen-Dioxide und unsere Kohlenstoffausstoß ist der gleiche wie 240 Haushalte, also sehr klein. Das ist vergleichbar mit dem Traffic von Facebook. Aber wir machen weniger, weil Facebook macht halt viele Sachen wie die Daten sammeln, Algorithmen darauf machen und das machen wir halt nicht. Hier gibt es noch eine Frage. Wie viele Entwickler braucht ihr, um die Infrastruktur zu betreiben und wie viele Entwicklerstunden braucht es, um die aufzubauen? Was sehr interessant ist, ist, dass es Non-Profit ist. Wie viel Aufwände und wie viel Geld ist da reingefliessen oder wäre reingefliessen? Wenn es nur darum geht, das alles zu laufen, am Laufen zu halten, dann sind es weniger als 20 Leute. Also wenn ihr das auf Request in der Sekunde auf Leute aufteilt, dann sind es sowas wie 8.000 Anfragen pro Sekunde pro Ingenieur. Was sehr beeindruckend ist, ich würde wirklich gerne wissen, ob es irgendeine Organisation gibt, die das schlägt. Ich weiß aber tatsächlich nicht, was das Operationsbudget ist, aber ich würde sagen, 2-stellige Millionen jedes Jahr. Aber über die letzten 18 Jahre, ich habe keine Ahnung. Aber für die ersten 5 Jahre waren die Leute tatsächlich alle freiwillige. Wir haben bis 10, 8 Jahren her, aber niemand hat dazu Buch geführt. Vor ein paar Jahren habe ich ein paar Interessanten von Saltstack-Verwendungen. Was ist damit passiert? Ich glaube, wir haben Saltstack nicht benutzt, aber wir benutzen es nicht mehr. Verwendet ihr Backjobs und Jobrunners für Services? Die Jobrunners, wenn du fragst, ob die Jobrunner dedicated sind, das sind sie. Haben wir irgendwelche freie Sachen für sowas? Nein, wir haben eigentlich nicht viel Hardware, wir haben alles in Benutz. Manchmal lassen wir 5 Dinge gleichzeitig laufen. Es sind 20 Pro-Datencenter für Jobrunner und sie lassen 700 Jobs per Sekunde laufen, aber das beinhaltet nicht die Videoscaler. Können Sie uns sagen, wie funktionieren Architekturentscheidungen? Entscheidungsfindungen zur Architektur. Fikimedia hat einen Komitee, um hochstufige technische Entscheidungen zu treffen, TECCO, und wir haben einen RSC-Prozess. Also jede Entscheidung, die sehr schwer rückgängig zu machen ist, durchläuft diesen Prozess. Man macht einen Ticket auf, und damit fängt man dann diesen Prozess an, der auf der Mailingliste angekündigt wird. Und irgendwann ist es dann hoffentlich gut genug, zum implementieren. Manchmal funktioniert das gut, manchmal kriegt man nicht viel Feedback, aber es stellt sicher, dass Leute diese Bescheid wissen über diese Entscheidungen. Und wenn ihr euch beschweren wollt, Daniel ist der Vorsitzender. Wie ist das mit CI und CD entlang der Pipeline? Mit so viel Traffic? Wollt ihr alles konsistent haben? Gibt es irgendein Testing oder ein Testmanagement, das ihr aufgesetzt habt? Unitests, gibt es Integration-Tests, integrierte End-to-end-Tests. Wir haben Beta-Cluster, und wir deployen auch einmal in der Woche. Alle Änderungen werden dann gemirrt. Der Branch wird dann jeden Dienstag übernommen. Und die Hebräische und die katalonische Wikipedia haben sich freiwillig gemeldet, um die Versuchs-Wikipedia zu sein für alle anderen. Und wenn es Probleme gibt, wird das dann gefixt, und dann geht es live für alle anderen Wikis. Unsere Testcoverage ist nicht so groß wie sie sollte. Wir brauchen unsere Benutzer für das. Wir arbeiten selbstverständlich daran, das zu verbessern und eine Sache, die wir erst kurz hinzugefügt haben, ist ein Programm, das End-to-end-Tests macht. Und wir hoffen, dass wir damit den Großteil der Anwendungslogik abdecken können und damit das User, ohne das User-Interface mit einzuziehen. Das User-Interface ist natürlich auch wichtig, aber sehr anfällig. Aber wir wollen jetzt erstmal die Anwendungslogik testen und wir arbeiten gerade daran. Und das ist gerade ein Poof of Concept und wir arbeiten gerade daran, das in unseren CI zu integrieren. Und wir machen das, wenn alle jetzt aus ihrem Urlaub zurück sind. Und dann müssen wir so um die 1000 Tests schreiben. Ich denke, es gibt auch einen Plan, nach jedem Kommitt zu deployen und dann ein Url-Back zu machen, wenn es Probleme gibt. Aber das ist mehr so ein lang, längerfristiges Ding. Im Moment, wenn es ein Problem gibt, dann machen wir ein Url-Back auf die Version von der letzten Woche. Gibt es noch weitere Fragen? Ich glaube nicht. Vielen Dank. Vielen Dank für diesen schönen Talk. Danke für die tollen Fragen, für den tollen Vortrag. Schön, dass Sie da waren. Vielen Dank. Applaus.