Was die Wartung eines Magento-Shops umfasst
Magento 2 ist Software, die du laufend aktualisieren musst. Sie betreibt deine Kasse, deinen Produktkatalog und oft Hunderte Erweiterungen (Module) von verschiedenen Herstellern. Jeder Teil bekommt eigene Updates, und alle müssen weiter zusammenarbeiten.
- Sicherheitspatches: kleine Updates von Magento, die bekannte Lücken schließen. Ohne sie steht dein Shop offen für Angriffe, die öffentlich längst beschrieben sind.
- Upgrades: der Schritt auf eine neuere Version von Magento oder von PHP, der Sprache, in der Magento läuft.
- Überwachung: Ladezeiten, Fehlermeldungen und geplante Aufgaben im Blick behalten, damit du von einem Problem hörst, bevor ein Kunde es meldet.
- Backups: eine Kopie deines Shops, die du auch wirklich zurückspielen kannst.
- Angriffe abwehren: Scraper und Bots, die deinen Shop stark belasten oder einzudringen versuchen.
- Ausrollen: Änderungen live schalten, ohne dass der Shop kurz stillsteht.
Ich mache diese Arbeit selbst, an einem Magento-2.4.7-Shop mit 328 aktiven Modulen. Was ich hier schreibe, stammt aus dieser Arbeit und nicht aus einer Broschüre.
Sicherheitspatches und Upgrades
Ein Patch kann mit einem Modul kollidieren, das dieselben Teile von Magento verändert. Dann funktioniert der Checkout nicht mehr, oder im Admin-Bereich fehlt etwas. Deshalb installiert man Patches nicht blind.
- Zuerst lese ich, welche Teile der Patch berührt und welche Module ebenfalls daran hängen.
- Ich spiele den Patch auf einer Testumgebung ein und gehe die wichtigsten Pfade durch: Suche, Warenkorb, Kasse und Admin-Bereich.
- Konflikte zwischen Modulen löse ich im Code, damit das Update durchläuft.
- Erst danach geht dieselbe Änderung in die Produktion.
So habe ich Patch-Upgrades an einem Produktionsshop durchgeführt, von einer Patchversion zur nächsten, einschließlich der Lösung von Konflikten zwischen Modulen. Ein größerer Versionssprung läuft genauso, mit mehr Testarbeit. Mehr dazu findest du auf der Seite zu Magento-2-Upgrades.
Ausrollen, ohne dass dein Shop stillsteht
Nach einer Änderung baut Magento vieles neu auf, und eine falsche Handlung zum falschen Zeitpunkt legt den Shop lahm. Bei einem Shop mit Traffic geht dann Umsatz verloren.
Deshalb aktualisiere ich den Cache (den Zwischenspeicher, der Seiten schnell macht) in der Produktion gezielt und nie komplett auf einmal. Ein vollständiger Flush setzt alle Seiten gleichzeitig zurück auf kalt. Der Server muss sie dann alle neu aufbauen, während Besucher im Shop sind.
Eine Änderung bereite ich zuerst auf einer Testumgebung vor, prüfe sie und schalte sie dann in einer Reihenfolge live, bei der der Shop weiterläuft. Ich weiß vorher, welchen Schritt ich zurückdrehe, falls etwas schiefgeht.
Überwachung und Backups
Ich behalte drei Dinge im Auge: Ladezeiten, Fehlermeldungen und geplante Aufgaben (Cron-Jobs, die Aufgaben, die Magento selbst zu festen Zeiten ausführt, etwa Indizieren und E-Mails versenden). Weicht eines der drei ab, bekomme ich eine Meldung.
- Ladezeiten: Ein Shop, der langsamer wird, zeigt oft früher als eine Fehlermeldung, dass etwas nicht stimmt.
- Fehlermeldungen: Ein Fehler im Log, der sich wiederholt, ist meistens ein Modul, das nicht richtig arbeitet.
- Geplante Aufgaben: Wenn sie stehen bleiben, geraten Bestand, Suchindex und E-Mails in Rückstand, ohne dass es jemand sieht.
Ein Admin-Bereich, der Fehler anzeigte, lag an einer abgelaufenen Lizenz eines externen Moduls. Ich habe das aufgespürt und behoben. So etwas findest du nur, wenn du der Fehlermeldung bis in den Code folgst.
Ein Backup ist erst etwas wert, wenn du es zurückspielen kannst. Ich prüfe, dass sie laufen und dass sich dein Shop daraus wiederherstellen lässt.
Angriffe abwehren
Ein Shop bekommt auch Traffic, der kein Kunde ist. Manche Bots lesen deinen ganzen Katalog aus, andere suchen nach einer Lücke.
Die Suche ist ein bekanntes Ziel, denn jede Suchanfrage macht dem Server Arbeit und kommt oft nicht aus dem Cache. Ich habe diese Funktion abgeschirmt und den Traffic gefiltert, damit echte Besucher weiter suchen und bestellen konnten.
Einen späteren Versuch, über eine Lücke Code auf dem Server auszuführen, habe ich gestoppt und anschließend untersucht, damit ich wusste, wie der Versuch aufgebaut war.
Aus der Praxis
Ein Magento-2.4.7-Shop mit 3.400 Produkten, täglich in meiner Betreuung
Ich arbeite täglich an einem Magento-2-Produktionsshop (Version 2.4.7) mit über 3.400 Produkten, etwa 13.600 Produktseiten in vier Sprachversionen und 328 aktiven Modulen. Patch-Upgrades, Überwachung, Angriffsabwehr und Ausrollen gehören alle dazu.
Ein Scraper schickte 2,3 Millionen Suchanfragen von 600.000 IP-Adressen an die Suchfunktion. Der Shop blieb stabil, weil ich die Suchfunktion abgeschirmt und den Traffic gefiltert habe.
Derselbe Shop erreicht mobil bei echten Besuchern einen LCP (die Zeit, bis das größte Element im Bild ist) von 2,14 Sekunden, vorher waren es 14 bis 16 Sekunden. Alle Core Web Vitals stehen auf Grün. Auch eigene Module gehören zur Betreuung: Sicherheits-Header (Regeln, die dem Browser sagen, welche Skripte laufen dürfen, CSP mit SRI-Hashes), ein Canonical-Fix für CMS-Seiten (der Suchmaschinen sagt, welche Version einer Seite zählt), verzögertes Laden von Skripten von Drittanbietern und ein Lagermodul in Entwicklung.
So arbeite ich, und mit wem du sprichst
Zuerst lese ich, wie der bestehende Code aufgebaut ist. Dann ändere ich auf einer Testumgebung und erst danach in der Produktion. So bleibt ein Shop heil.
Du hast einen Ansprechpartner: die Person, die den Code schreibt. Du sprichst also mit dem, der die Änderung auch macht. Was die Wartung kostet, hängt von deinem Shop ab. Das besprechen wir nach einem Kennenlernen.