Wenn eine Agentur nur ein oder zwei Kundenwebsites betreut, ist die Geschwindigkeit, mit der du auf einen Vorfall reagierst, der wichtigste Maßstab. Wenn du die Umgebung kennst, ist die Lösung meist in greifbarer Nähe. Ein gut bewältigtes Problem kann die Kundenbeziehung stärken – daher ist eine schnelle Reaktion eine Fähigkeit, die du dir aneignest, und ein Grund zum Stolz, auf den du aufbauen kannst.
Allerdings wächst das Volumen der Vorfälle in einem Portfolio parallel zum Portfolio selbst. Mit dem falschen Fokus kannst du zwar schneller bei der Behebung von Problemen werden, ohne jedoch deren Häufigkeit zu verringern. Der Unterschied zwischen Reaktionsgeschwindigkeit und Vorfallhäufigkeit ist genau der Punkt, an dem die wahren Kosten einer reaktiven Agentur liegen.
Warum eine schnelle Reaktion auf Vorfälle die falsche Erfolgskennzahl ist
Single-Site-Setupskönnen eine Kultur der schnellen Fehlerbehebung aufrechterhalten, da Vorfälle selten und vereinzelt auftreten. Wenn man die Umgebung genau kennt und einen vertrauten Weg zur Lösung hat, ist die Reaktionsgeschwindigkeit eine aussagekräftige Leistungskennzahl. Dies wird als „Mean Time to Recovery or Repair“ (MTTR) bezeichnet: die durchschnittliche Zeit, die benötigt wird, um einen Ausfall zu beheben, sobald er auftritt.
Mit zunehmendem Wachstum wird jedoch die „Mean Time Between Failures“ (MTBF) zu einem besseren Indikator für den Betriebszustand. Während die MTTR die Wiederherstellungsgeschwindigkeit misst, misst die MTBF, wie lange ein System läuft, bevor der nächste Ausfall auftritt. Eine hohe MTBF bedeutet, dass Ausfälle selten sind, eine niedrige MTBF hingegen, dass dein Team fast ständig mit der Wiederherstellung beschäftigt ist – unabhängig davon, wie schnell die einzelnen Wiederherstellungen ablaufen.
Kurz gesagt: Wenn du nur auf MTTR optimierst, konzentrierst du dich auf die Werkstatt, während das Fahrzeug immer wieder kaputtgeht. Stattdessen brauchst du MTTR, um die Effizienz der Wiederherstellung zu beurteilen, und MTBF, um festzustellen, ob die Umgebung überhaupt Vorfälle verursacht.
Was eine niedrige MTBF in einem wachsenden Portfolio kostet
In einem großen Portfolio führt eine niedrige MTBF pro Website zu einer Support-Warteschlange, die sich nicht allein durch schnelle Reaktionszeiten bewältigen lässt. Häufige Vorfallstypen betreffen regelmäßig mehrere Website gleichzeitig:
- Konflikte bei Plugin-Updates betreffen mehrere Installationen gleichzeitig, wenn ein Update für ein gemeinsam genutztes Plugin, das im gesamten Portfolio zum Einsatz kommt, ausgerollt wird.
- Bot-bedingte Leistungseinbußen können mehrere Websites gleichzeitig betreffen, wenn automatisierter Traffic das Caching umgeht und PHP-Threads unbegrenzt beansprucht.
- Bereitstellungsfehler führen zu Konfigurationsfehlern in Live-Umgebungen, wenn Staging-Workflows nicht konsequent befolgt werden.
- Störungen in der gemeinsam genutzten Infrastruktur auf Plattformen, die Websites nicht voneinander isolieren, können sich von einer Website auf andere auf demselben Server ausbreiten.
Viele davon führen zu Vorfällen, die dein Team nicht verursacht hat und innerhalb der Umgebung nicht verhindern kann. Daher ist es nicht dasselbe, all diese Probleme schneller zu beheben, als dafür zu sorgen, dass weniger davon auftreten.
Hall ist ein Kinsta-Kunde mit jahrzehntelanger Erfahrung als Webagentur. Bei ihrem früheren Hoster wirkten sich wiederkehrende Website-Ausfälle während Traffic-Spitzen direkt auf den Umsatz eines WooCommerce-Kunden aus und beanspruchten Teamkapazitäten, die eigentlich für die Kundenarbeit vorgesehen waren:
Kinsta arbeitet so, wie wir arbeiten. Wir brauchen hervorragende Leistung, damit es keine Überraschungen gibt, und großartigen Support, falls doch mal etwas passiert. Mit Kinsta können wir Ablenkungen durch Supportanfragen reduzieren und unsere Produktivität steigern.
Die Kosten, die nicht in den Support-Tickets auftauchen
Die meisten Agenturen erfassen die direkten Kosten eines Vorfalls, typischerweise die Stunden, die ein Entwickler oder Account-Manager mit der Diagnose und Behebung des Problems verbringt. Diese Zahl ist zwar real, aber unvollständig, da einige versteckte Kosten nicht berücksichtigt werden:
- Durch den Kontextwechsel wird ein Entwickler von einem Build-Projekt abgezogen, um einen Vorfall auf einer Live-Seite zu bearbeiten, doch der Build läuft weiter. Untersuchungen zeigen, dass es 15–25 Minuten dauert, bis man nach einer Unterbrechung wieder voll konzentriert arbeiten kann – das bedeutet, dass ein einziger Vorfall am Vormittag still und leise den größten Teil eines konzentrierten Arbeitsblocks zunichte machen kann. Diese Kosten tauchen nie im Support-Ticket auf, summieren sich aber über alle Websites im Portfolio hinweg.
- Das Vertrauen des Kunden ist groß, wenn du einen einzelnen Vorfall transparent bearbeitest und löst. Im Gegensatz dazu weckt ein Muster wiederkehrender Vorfälle Zweifel daran, ob die Umgebung stabil ist. Allein die Häufigkeit bestimmt im Laufe der Zeit das Vertrauen des Kunden.
- Eine Agentur, die auf reaktiven Maßnahmen basiert, macht erfahrene Entwickler zu einer permanenten ersten Verteidigungslinie. Als Standardbetriebsmodus für ein wachsendes Portfolio führt dies zu Fluktuation und Kapazitätsengpässen und lässt die negative Situation weiter eskalieren.
Die ständigen Bemühungen eines Teams, sich zwischen ein Portfolio und wiederkehrende Ausfälle zu stellen, sind eher ein Problem der Plattform als eine Frage der Personalausstattung. Die Lösung ist eine Infrastruktur, die keine ständigen Eingriffe benötigt, um stabil zu bleiben. Die preisgekrönte Digitalmarketing-Agentur Paramark beschreibt ein ähnliches Modell aus der Zeit vor Kinsta:
Es erforderte einen übermäßigen Verwaltungsaufwand, um Website-Ausfälle zu verhindern. Zu den ständigen Problemen gehörten unter anderem die Verwaltung der Serverressourcen und das Bereinigen von Log-Dateien. Wurde dies versäumt, wurden die Websites instabil.
Die Lösung (die Erfassung von Vorfällen pro Website und Monat statt der Zeit bis zur Behebung) zeigt dir, ob sich die Umgebung tatsächlich verbessert oder ob dein Team einfach nur besser darin wird, ein andauerndes Problem zu bewältigen.
So sieht die Vorbeugung von Vorfällen aus
Die Infrastruktur und die gesamte Plattform von Kinsta basieren auf dieser Philosophie: Es geht darum, die Wahrscheinlichkeit von Vorfällen zu verringern, statt nur deren Behebungszeit zu verkürzen.
Erstens läuft jede Website in einem eigenen, isolierten Linux-Container mit einem dedizierten Software-Stack. Ressourcen können die Containergrenzen nicht überschreiten – das gilt sogar zwischen Websites, die zum selben Unternehmenskonto gehören.
Bei einem Agenturportfolio haben einzelne Vorfälle in einer Umgebung keinerlei Auswirkungen auf die Leistung oder Verfügbarkeit anderer von dir verwalteter Websites. Im Gegensatz dazu führt auf Shared-Hosting-Plattformen ein Ressourcenanstieg auf einer Website zu Leistungseinbußen bei anderen Websites auf demselben Server.
Automatische Backups und Wiederherstellung mit einem Klick
Kinsta erstellt täglich vollständige Backups jeder Website und bewahrt diese mindestens 14 Tage lang auf. Du kannst über den Backupsbildschirm in MyKinsta auf Backups zugreifen und diese wiederherstellen. Dort findest du außerdem zwei weitere relevante Backup-Arten:
- Systemgenerierte Backups werden automatisch vor wichtigen Vorgängen ausgelöst, wie zum Beispiel der Wiederherstellung aus einem bestehenden Backup. Vor der Ausführung eines Vorgangs gibt es immer einen Wiederherstellungspunkt.
- Mit manuellen Backups kannst du jederzeit bis zu fünf zusätzliche Snapshots erstellen, die du zur besseren Identifizierung auch benennen kannst.
Über die Schaltfläche Wiederherstellen nach für jedes Backup kannst du mit nur wenigen Klicks zu einem bekannten Zustand zurückkehren. Für Agenturen, die Kinsta Automatic Updates für ihr gesamtes Portfolio nutzen, läuft jedes geplante Update mit einem bereits vorhandenen, vom System generierten Wiederherstellungspunkt. Der Prozess lautet nun „Wiederherstellen und untersuchen“ und ist unabhängig von der betroffenen Website vorhersehbar.
Staging-Umgebungen und selektiver Push
Die Staging-Umgebungen von Kinsta bieten eine separate Kopie der Live-Site, um Änderungen zu testen, bevor sie bei den Kunden ankommen. Jeder Kinsta-Tarif beinhaltet eine kostenlose Standard-Staging-Umgebung pro Website. Wenn eine Änderung bereit zur Bereitstellung ist, gibt dir der selektive Push die Kontrolle darüber, was genau in die Produktion übernommen wird.
Um den selektiven Push zu nutzen, wähle deine Staging-Umgebung in MyKinsta aus, klicke auf Umgebung pushen und wähle einen Bereitstellungsumfang (Dateien oder Datenbank). Jeder Umfang verfügt außerdem über ein Dropdown-Menü, mit dem du genau festlegen kannst, was gepusht wird:
Kinsta erstellt vor jedem Push ein automatisches Backup der Zielumgebung. Bereitstellungs-Fehler, die auf Live-Sites gelangen, sind häufige Ursachen für Störungen. Daher ist eine Multi-Umgebungs-Konfiguration mit selektivem Push und automatischen Backups vor dem Push eine Möglichkeit, dringende Eingriffe auf der Live-Site zu vermeiden.
Bot-Schutz als Schutz vor Leistungsausfällen
Der Bot-Schutz von Kinsta filtert den Datenverkehr, bevor WordPress eine Anfrage verarbeitet, um automatisierte Belastungen auf Infrastrukturebene zu reduzieren, bevor sie die Serverleistung beeinträchtigen. Standardmäßig blockiert Kinsta plattformweit Datentraffic, der als bösartig eingestuft wird.
Um den Schutz für eine Seite zu konfigurieren, gehst du in MyKinsta zum Bildschirm Bot-Schutz und klickst im Bereich Schutzstufe auf Ändern:
Es stehen vier Stufen zur Auswahl, wobei Bösartigen Datentraffic blockieren die Standardeinstellung für alle Websites ist. Dadurch werden DDoS-Versuche und Anfragen von IP-Adressen blockiert, die mit bekannten Angriffsquellen in Verbindung stehen. Du kannst dies jedoch auch erweitern, um bestätigten automatisierten Datentraffic zu blockieren, Anfragen von mutmaßlichen Bots und nicht klassifizierten Anfragen zu überprüfen und sogar den gesamten nicht verifizierten Datentraffic – einschließlich mutmaßlich menschlicher Besucher – zu überprüfen.
Wenn du in MyKinsta mehrere Websites auswählst und auf Aktionen > Bot-Schutz ändern klickst, kannst du eine Schutzstufe auch gleich auf mehrere Websites gleichzeitig anwenden. Durch Bots verursachte Last kann das Caching komplett umgehen und bei jeder Anfrage PHP-Threads beanspruchen, besonders bei der Verwaltung von WooCommerce- oder Mitglieder-Websites. Diese Funktion zur Hand zu haben, wird mit der Zeit immer wichtiger.
Analytik als Frühwarnsystem
Die Analytics-Suite von MyKinsta verschafft dir Einblick in Zustände, bevor sie zu Problemen für deine Kunden werden. Auf dem Analytics-Bildschirm verfolgt die Registerkarte Performance die PHP-Antwortzeiten und die PHP-Thread-Auslastung im Zeitverlauf. Ein Muster steigender Antwortzeiten ohne entsprechenden Anstieg des menschlichen Datentraffics ist oft ein frühes Anzeichen für Bot-Last oder eine ineffiziente Datenbankabfrage:
Das gemeinsame Durchsehen der Analytics-Diagramme dauert pro Website nur wenige Minuten und deckt Muster auf, die bei der reaktiven Überwachung übersehen werden. Wenn du dir beispielsweise das Diagramm Besuche unter Plan-Nutzung ansiehst, erhältst du Einblicke in Aspekte wie den abrechnungsrelevanten menschlichen Traffic. Wenn du dies mit dem Bericht Top-Anfragen nach Aufrufen vergleichst (der den gesamten Traffic einschließlich automatisierter Anfragen abdeckt), erhältst du einen Einblick, wo botgetriebene Last die Serverleistung beeinträchtigt, während die Besucherzahlen normal erscheinen.
Das Betriebsmodell deiner Agentur auf Prävention ausrichten
Der Weg zu weniger Vorfällen wird eher durch die Wahl der Plattform und der Funktionen unterstützt als durch andere Arbeitsabläufe.
Beginne zum Beispiel damit, bei einem Vorfall neben den Lösungsschritten auch die einzelnen Faktoren der betroffenen Website zu protokollieren. Das Ziel ist nicht die Dokumentation um ihrer selbst willen, sondern zu erkennen, ob sich Vorfälle aus denselben zugrunde liegenden Gründen wiederholen. Die Protokolle in MyKinsta können dabei helfen:
Ein Log, das drei Vorfälle auf derselben Website anzeigt, die durch Konflikte bei Plugin-Updates verursacht wurden, deutet auf eine Lücke im Staging-Workflow hin. Ohne diese Aufzeichnung bleibt das Muster unsichtbar und die Vorfälle treten weiterhin auf.
Eine Checkliste vor der Bereitstellung ist der beste Weg, um die Entscheidungen, die du bereits getroffen hast, in einen wiederholbaren Prozess zu integrieren. Die folgenden Punkte verhindern die häufigsten Arten vermeidbarer Vorfälle:
- Teste jede Änderung in einer Kinsta-Staging-Umgebung anhand eines produktionsrelevanten Zustands, bevor du sie überträgst.
- Nutze den selektiven Push, um den Deployment-Umfang an die Änderung anzupassen.
- Überprüfe den Bot-Schutz nach jeder Bereitstellung, das öffentlich zugängliche dynamische Funktionen hinzufügt, insbesondere Formulare, Checkout-Abläufe oder Login-Endpunkte.
- Überprüfe nach dem Deployment das Leistungsdiagramm unter Analytics, um sicherzustellen, dass die Antwortzeiten im zulässigen Bereich bleiben.
Sobald du Vorfälle pro Website regelmäßig verfolgst, kannst du proaktiv über Zuverlässigkeitstrends berichten, anstatt Probleme erst im Nachhinein zu erklären. Ein Kunde, der eine vierteljährliche Zusammenfassung erhält, aus der eine sinkende Vorfallhäufigkeit und eine konstante Verfügbarkeit hervorgeht, hat eine andere Wahrnehmung des Dienstes als einer, der nach jedem Vorfall einen Anruf erhält.
Eine auf Prävention ausgerichtete Infrastruktur macht die Skalierung einer Agentur nachhaltig
Eine schnelle Reaktion auf Vorfälle ist eine grundlegende Fähigkeit für jede Agentur. Eine Infrastruktur, die Vorfälle selten macht, entscheidet darüber, ob diese Fähigkeit ständig genutzt wird oder nur selten benötigt wird. Auf Agentur-Ebene entscheidet die Kluft zwischen diesen beiden Faktoren über Rentabilität und Teamstabilität.
Kinstas Toolset und Infrastruktur (wie z. B. die Container-Isolierung, das automatische Backup-System und der Bot-Schutz) decken genau die Vorfallkategorien ab, auf deren Behebung du die meiste Zeit verwendest. Auf dieser Grundlage sorgt der von dir implementierte Prozess – etwa ein Vorfallprotokoll oder eine Checkliste vor der Bereitstellung – dafür, dass die Reduzierung der Vorfälle auf allen von dir verwalteten Websites konsistent ist.
Für Agenturen, die Kunden-Websites auf Kinsta verwalten, bietet das Agentur-Partnerprogramm dedizierten Support, Ressourcen für den gemeinsamen Vertrieb und Tools, die speziell auf die Verwaltung von WordPress in großem Maßstab zugeschnitten sind.
Joel ist Frontend-Entwickler und arbeitet bei Kinsta als Technical Editor. Er ist ein leidenschaftlicher Lehrer mit einer Vorliebe für Open Source und hat über 200 technische Artikel geschrieben, die sich hauptsächlich um JavaScript und seine Frameworks drehen.
