
Black Friday: Wie ein riskantes Experiment den Tag gerettet hat
Am vergangenen Freitag hat bei Digitec Galaxus AG schweizweit der Ausnahmezustand geherrscht. Die grösste Sorge: Halten die Server dem Ansturm stand. An vorderster Front dabei ist Software Engineer Enes Poyraz. Er erzählt von einem Tag, an dem die Engineers alles auf eine Karte gesetzt haben.
17 Sekunden. So lange dauert es, bis digitec.ch am vergangenen Freitag, international als Black Friday bekannt, zum ersten Mal offline geht. Der Grund: Zu viele User Requests. Die Server unseres Unternehmens sind nach 17 Sekunden unter der Last von dir und anderen Kunden zusammengebrochen. Denn zu viele wollten die Sonderangebote am internationalen Ausverkaufstag abstauben.
«Wir dachten eigentlich, dass die Server länger stehen bleiben würden», sagt Junior Software Engineer Enes Poyraz.
Der Engineer berichtet von einem Tag, an dem er und sein Team eine Firma zur Unproduktivität gezwungen hat und an dem die Engineers deinen Deal mit einer Verzweiflungstat gerettet haben.

Enes ist in der Sekunde anwesend, als die Server zum ersten Mal in die Knie gehen. Denn eine Truppe Engineers – alle Teams sind nach James-Bond-Filmen benannt – sind jedes Jahr zum Black Friday auf Stand-By. In den neuen Offices an der Förrlibuckstrasse, zu Hause im Home Office oder irgendwo da draussen an Laptops mit mobilem Internet. Sie warten darauf, dass die Server nachgeben und mitigieren, wenn sie können.
Doch zur Mitternachtslast sind sie an ihren Grenzen. Die sonst so stolzen Engineers müssen einen harten Schlag hinnehmen. Den Männern und Frauen, denen schon eine Downtime von wenigen Sekunden zu lange ist, gelingt es erst nach gut zwei Stunden, die Server wieder online zu bringen. Doch stabil lief der Shop nicht. Immer wieder ging die Site offline, aber nur ganz kurz. Einzig ein Livestream aus dem Digital Marketing ist aktiv.
«Das ist zwar für Kunden etwas mühsam, aber engineering-seitig erwartetes Verhalten», sagt Enes. Er zuckt mit den Schultern. Klar, es sei unangenehm und die Engineers versuchen, diese Zeiten zu minimieren. Aber wenn eine Nation eine Website hämmert, dann könne das vorkommen.
Die zweite Welle
Es wird ruhig. Nach 2 Uhr nachts schlafen die Bewohnerinnen und Bewohner der Schweiz, haben ihre guten Deals abgestaubt. Später im Tage wird mir aus dem Zürcher Shop zugetragen, dass eine Person dediziert dazu eingesetzt worden ist, Smartphone-Abos abzuschliessen. Denn am vergangenen Freitag gab es 50% Rabatt auf jedes Smartphone beim Abschluss eines Abos. Die Abos können auch online erworben werden.
Doch davon bekommt Enes nichts mit. Er geht kurz vor 3 Uhr morgens nach Hause, schläft ein paar unruhige Stunden. Neben ihm das Handy auf «laut», da er jederzeit den Anruf erhalten könne, dass er sofort wieder ins Büro kommen soll. Die Server seien down, er werde gebraucht. Doch der Anruf kommt nicht. Enes schläft. Gleich tun es ihm andere Engineers, darunter auch Teamleader Software Engineering Raphael Renaud, der tatsächlich Pikett hat. Raphaels Telefon hat morgens um 5 Uhr geklingelt. Anruf aus Wohlen mit der Frage, warum so wenige Bestellungen im System sind. Denn auch das Zentrallager in Wohlen hat Ausnahmezustand am Black Friday und läuft mit vollem Personalbestand und auf Hochtouren.
Gegen 9 Uhr ist er wieder an seinem Arbeitsplatz, beschreibt sich selbst als «ausgeschlafen». Die Server halten. Knapp.
«Die Last ist im Laufe des Morgens kontinuierlich gestiegen», sagt Enes, «und uns wurde klar, dass wenn das so weitergeht, dann halten wir den Tag nicht durch.»
Das käme gar nicht in Frage. Da jetzt mehr Engineers in den Büros sind als das Pikett-Détachement der vergangenen Nacht, können sie sich aufteilen. Ein Team widmet sich den internen Systemen. Alles, was abgeschaltet werden kann, wird abgeschaltet. Ein Mail von Chief Information Officer Oliver Herren informiert die digitec-Mitarbeiter um 9:36 Uhr, dass interne Tools wie die Zeiterfassung für Mitarbeiter oder einige Funktionen im Shop-Backend abgeschaltet werden, um Server-Ressourcen zu schonen. Alles, das wir lokal hosten und abschalten können, wird abgeschaltet.
In den Büros am Zürcher Hauptsitz schlucken Mitarbeiter leer. Wir sind ein Online Shop. Unsere Website ist unser Kapital, der Ort, der unsere Rechnungen zahlt und dir deine neuesten Geräte bringt. Wir machen uns Sorgen. Vor allem auch darum, weil die Redaktion den Betrieb mehr oder weniger einstellen kann. Das gesamte Magazin wird von der Frontseite verbannt. Die Bilder, auf die du klickst, fressen zu viele Ressourcen.

Doch es ist alles vergebens: Um ziemlich genau 12 Uhr Mittags gibt der Server erneut auf. Nicht so schlimm, wie in der Nacht zuvor, die Site kommt und geht im Sekundentakt, aber trotzdem zu instabil für ein gutes Kauferlebnis auf der Site.
Die Engineers vergessen die Sache mit dem Mittagessen und machen sich daran, die Site wieder online zu bringen.
Ein Experiment rettet den Tag
Während Oliver und ein Team von Engineers aus allen Abteilungen des Engineerings Services offline genommen haben, war Enes mit zwei anderen Engineers damit beschäftigt, einen Plan auszuhecken. Was tun, wenn es nicht ausreicht, die internen Services offline zu nehmen?
Die drei Engineers wurden beauftragt, eine Lösung zu finden, wenn alle anderen Lösungen scheitern.
«Mehr out-of-the-box geht es nicht», sagt Enes. Er ist schon etwas stolz darauf, zum Team gehört zu haben, das den Tag gerettet hat. Der sonst eher ruhige Mann spricht auf einmal etwas lauter.
Die Lösung heisst Redis, ein Cache-System, das die Engineers im Augenwinkel beobachten. Enes gehört zu denen, die Anwendungen darauf getestet haben. Ein Cache ist nichts anderes als ein Datenspeicher, der oft gemachte Requests abspeichert und so schneller abwickeln kann. Ein Beispiel: Wenn du auf die Black Mobile Site willst und tausende andere das auch wollen, dann muss nicht mehr jedes Mal die Datenbank hinter der Website angefragt werden. Das Cache hat eine Version der Site bereits zwischengespeichert und zeigt dir diese an. So können Ressourcen auf den weiteren Einkaufsprozess verwendet werden.
«Klar, wir haben eine Cache-Lösung, die im normalen Alltag sauber läuft», sagt Enes. Aber jedes mal, wenn ein Server down geht, müssen die Caches neu berechnet werden. Noch schlimmer: Jeder unserer Server berechnet das Cache lokal. Sprich, jedes mal wenn ein Server down geht, muss das Cache lokal auf der Server-Maschine neu berechnet werden. Das frisst Ressourcen, die eigentlich kundenseitig gebraucht werden. An Leser des Magazins denkt firmenweit keiner mehr. Die Marketing-Abteilung hat schon lange die Waffen gestreckt. Das Produktmanagement fragt sich, ob ihre Lagerbestände ausreichen. Die Shop-Mitarbeiter sehen sich mit langen Schlangen konfrontiert. Die Engineers aber sehen sich einer Nation Kaufwütigen gegenüber und denken gar nicht ans aufgeben.
«Gross habe ich Redis noch nicht ausprobiert», sagt er, «aber ich habe zwei Tage damit verbracht, etwas rumgetestet.» Das sei niemals ausreichend, um dem System den grössten Online-Shop der Schweiz anzuvertrauen. Wenn Enes seine zwei Wochen alten Notizen anschaut, dann muss er grinsen.
Es hat sicher einige Anwendungsbereiche bei uns
Die Engineers beschliessen, Redis ohne Testing an einem Demosystem live zu nehmen. Ein riskantes Unterfangen. Bevor ein Unternehmen eine Software in ein Live System eingepflegt wird sie von internen Stellen und oft auch von Externen auf Herz und Nieren getestet. Denn nur weil Software laut dem Marketing-Material des Herstellers genau nach dem klingt, was ein System braucht, heisst das noch lange nicht, dass es den versprochenen Mehrwert bringt. Manchmal wird durch den Einsatz alles nur noch schlimmer.
«Was meinst du, kommt das gut», wird Enes gefragt.
Der Engineer nickt.
Redis übernimmt
Ab da geht alles schnell. Da Redis laut Angaben Enes «verdammt schnell und einfach» ist, steht der Server nach 20 Minuten bereit. Wo das alte Cache System digitecs auf jedem Server lokal läuft, ist Redis zentral auf einem Server und rechnet auch Requests auf anderen Server mit. Sprich: Jeder Server schreibt ins Redis-Cache und so ist die Lösung besser skalierbar und die lesenden Server haben weniger Last.
«Damit wir aber nicht eine komplett waghalsige #yolo-Aktion starten, haben wir noch ein SwitchBit eingerichtet», meint Enes. Dazu hat sich ein kleines Team der IT Operations dazu bereit erklären müssen, die Server stets zu überwachen, damit der Shop nicht komplett abgeschossen wird. Denn IT Ops ist schon den ganzen Tag mit Server-Performance-Überwachung beschäftigt. Sie sind laut Enes diejenigen, die seinem Team den Rücken freigehalten hat für das Experiment mit Redis.
Das Problem kommt mit dem Go-Live, das so unkoordiniert wie nur möglich abläuft. Auf einem Managed Server Microsofts, damit die Last intern nicht zu gross wird, will Enes Redis starten.
«Blöderweise läuft Redis auf Port 6380, der bei uns geschlossen ist», sagt er. Er beantragt notfallmässig die Öffnung des Ports, was aber nicht möglich ist, denn just dieser Port wird von Microsofts Server blockiert. Doch Enes hat eines gelernt: Er hat immer einen zweiten Plan in petto.
«Parallel habe ich versucht, Redis auf Googles Cloud zum Laufen zu bringen», sagt er. Doch auch das wird schwieriger, als angenommen. Mit Hilfe von Senior Software Engineer Michal Nebes schafft er es, einen Redis Cluster hochzufahren.
Um 16 Uhr gilt es ernst. Ein kurzes Code Review. Der Code passt laut Senior Software Engineer Boško Stupar und er misst den Roundtrip der Daten, also die Zeit, die Daten brauchen, um an den Server gesendet zu werden und wieder zum Computer des Users zurückkommen.
- Normal: 50 Millisekunden bis 500 Millisekunden. Zu langsam
- Redis, lokales Testsystem: 8 bis 9 Millisekunden
- Redis, produktiv: 16 bis 19 Millisekunden
Redis geht online. Der Abendverkauf wird in die Hände eines unerprobten Systems mit minimaler Absicherung gelegt.
Bange Sekunden.
Redis liest Requests mit, baut ein Cache auf.
Die Last auf den Servern geht merklich zurück. Der Shop stabilisiert sich.

Die Engineers atmen auf.
Auf Facebook schreibt Boško Stupar später:
Black Friday überlebt. Das war der grossartigste Tag meiner Karriere! So stressig, so hart, so lohnend. Für Nerds: Wir haben ein Two-Stage-Caching mit einer zentralisierten Redis-Farm implementiert. Operation am offenen Herzen ohne Schmerzmittel. PS: Ich hasse Black Friday.
Die Engineers treffen sich nach Sonnenuntergang zum Bier im fünften Stock an der Pfingstweidstrasse, ein Auge immer auf den Shop. Ausgelassene Party ist anders, aber sie entspannen sich.
Um 18:55 Uhr gibt Enes entwarnung via WhatsApp:

Die Server laufen normal, unter normaler Last. Derweil stehen die Leute im Shop an, machen Smartphone-Abos und holen Bestellungen ab. Am Shop-Eingang in Zürich steht Store Manager Adrian Maier und gibt Auskunft über Wartezeiten. Zwanzig Minuten, vierzig Minuten. Er ist müde, genau wie die Crew hinter den Kassen.
Die Engineers haben so halb Feierabend, aber die Shop-Mitarbeiter sind die letzten, die durchhalten müssen. Denn um 20 Uhr ist der Tag auch an den Kassen vorbei. Keine Abos mehr, keine Lieferungen, keine Fragen.
Quo vadis, Redis?
Das Redis-System bleibt über das Wochenende bis Montagabend am Netz, damit es Cyber Monday mitmachen kann. Die Engineers sind stolz, der Shop steht am Montag stabil. Doch dann hat Redis erstmal seinen Dienst getan und der Cluster wird wieder vom Netz genommen.
«Denn wenn alles gesagt und getan ist, dann sprechen wir hier immer noch von einem weitgehend unerprobten System», sagt Enes.
Die Engineers haben eine lange Liste von Fragen, die sie beantworten müssen, bevor sie Redis guten Gewissens dauerhaft ans Netz nehmen werden. Darunter viele Fragen, die etwa so klingen: «Warum macht Redis $ding?»
Jetzt, da sich die Lage wieder beruhigt hat, können die Engineers sich diesen Fragen widmen. Denn wenn ihnen Black Friday eines gezeigt hat, dann dass Redis Potential hat. Das nicht zu nutzen wäre schade.
477 Personen gefällt dieser Artikel


Journalist. Autor. Hacker. Ich bin Geschichtenerzähler und suche Grenzen, Geheimnisse und Tabus. Ich dokumentiere die Welt, schwarz auf weiss. Nicht, weil ich kann, sondern weil ich nicht anders kann.