Nutzen Sie diese Enterprise-Readiness-Checkliste, um Ihr Produkt für größere Kunden zu skalieren — mit praktischen Zuverlässigkeitslektionen inspiriert von Diane Greene und VMware.
Der Verkauf an kleine Teams dreht sich meist um Funktionen und Tempo. Beim Verkauf an Unternehmen ändert sich die Definition von „gut“. Ein Ausfall, ein verwirrender Berechtigungsfehler oder ein fehlender Audit-Trail können Monate Vertrauen zunichtemachen.
Zuverlässigkeit bedeutet schlicht drei Dinge: die App bleibt erreichbar, Daten bleiben sicher und das Verhalten bleibt vorhersehbar. Dieser letzte Punkt ist wichtiger, als es klingt. Enterprise-Nutzer planen Arbeit um Ihr System herum. Sie erwarten dasselbe Ergebnis heute, nächste Woche und nach dem nächsten Update.
Was normalerweise zuerst scheitert, ist kein einzelner Server. Es ist die Lücke zwischen dem, was Sie für eine Handvoll Nutzer gebaut haben, und dem, was große Kunden als selbstverständlich voraussetzen. Sie bringen mehr Traffic, mehr Rollen, mehr Integrationen und mehr Prüfung durch Security und Compliance mit.
Die frühen Stresspunkte sind vorhersehbar. Die Erwartungen an die Verfügbarkeit steigen von „meist in Ordnung“ zu „muss langweilig stabil sein“, mit klarer Vorfallsbearbeitung. Datensicherheit wird zu einem Thema auf Vorstandsebene: Backups, Wiederherstellung, Zugriffsprotokolle und Datenverantwortung. Berechtigungen werden schnell kompliziert: Abteilungen, Auftragnehmer und Prinzipien der geringsten Rechte. Änderungen werden riskant: Releases brauchen Rollbacks und Wege, Überraschungsverhalten zu verhindern. Support wird nicht länger nur „hilfreich“, sondern Teil des Produkts mit Reaktionszeiten und Eskalationspfaden.
Ein Startup-Kunde mag einen zweistündigen Ausfall und eine schnelle Entschuldigung akzeptieren. Ein Enterprise-Kunde will vielleicht eine Root-Cause-Zusammenfassung, den Nachweis, dass es nicht wieder vorkommt, und einen Plan zur Vermeidung ähnlicher Fehler.
Eine Enterprise-Readiness-Checkliste geht nicht um „perfekte Software“. Es geht darum, zu skalieren, ohne Vertrauen zu zerstören, indem Produktdesign, Teamgewohnheiten und tägliche Abläufe zusammen verbessert werden.
Diane Greene gründete VMware in einer Zeit, in der die Enterprise-IT vor einem schmerzhaften Trade-off stand: schnell vorankommen und Ausfälle riskieren oder stabil bleiben und langsame Änderungen akzeptieren. VMware war wichtig, weil es Server wie verlässliche Bausteine behandeln ließ. Das ermöglichte Konsolidierung, sicherere Upgrades und schnellere Wiederherstellung, ohne dass jedes App-Team alles neu schreiben musste.
Das zentrale Enterprise-Versprechen ist einfach: Stabilität zuerst, Funktionen danach. Unternehmen wollen zwar neue Fähigkeiten, aber auf einem System, das weiterläuft während Patches, Skalierung und normale Fehler. Wenn ein Produkt geschäftskritisch wird, wird aus „wir beheben das nächste Woche“ verlorener Umsatz, verpasste Deadlines und Compliance-Probleme.
Virtualisierung war ein praktisches Zuverlässigkeitswerkzeug, nicht nur ein Kostenhebel. Sie schuf Isolationsgrenzen. Eine Workload konnte abstürzen, ohne die ganze Maschine mitzunehmen. Sie machte Infrastruktur außerdem wiederholbarer: Wenn Sie snapshottet, klonen und Workloads verschieben können, können Sie Änderungen testen und bei Problemen schneller wiederherstellen.
Diese Denkweise gilt weiterhin: Entwerfen Sie für Änderungen ohne Downtime. Gehen Sie davon aus, dass Komponenten ausfallen, Anforderungen sich verschieben und Upgrades unter realer Last passieren. Bauen Sie dann Gewohnheiten, die Änderungen sicher machen.
Kurz gesagt: Fehler isolieren, damit ein Problem sich nicht ausbreitet; Upgrades routinemäßig behandeln; Rollbacks schnell machen; vorhersehbares Verhalten cleveren Tricks vorziehen. Vertrauen entsteht durch langweilige Zuverlässigkeit, Tag für Tag.
Wenn Sie auf modernen Plattformen bauen (oder Apps mit Tools wie Koder.ai generieren), gilt die Lektion: Stellen Sie Funktionen nur auf Wegen bereit, die Sie deployen, überwachen und rückgängig machen können, ohne den Kundenbetrieb zu unterbrechen.
VMware wuchs in einer Paketsoftware-Welt, in der „ein Release“ ein großes Ereignis war. Cloud-Plattformen haben den Rhythmus verändert: Kleinere Änderungen werden öfter geliefert. Das kann sicherer sein, aber nur, wenn Sie den Wandel kontrollieren.
Ob Sie einen gebündelten Installer ausliefern oder in die Cloud pushen, die meisten Ausfälle beginnen gleich: Eine Änderung landet, eine versteckte Annahme bricht, und die Blast-Radius ist größer als erwartet. Schnellere Releases beseitigen das Risiko nicht — sie vervielfachen es, wenn Ihnen Schutzmechanismen fehlen.
Teams, die verlässlich skalieren, gehen davon aus, dass jedes Release fehlschlagen könnte, und bauen das System so, dass es sicher versagt.
Ein einfaches Beispiel: Eine „harmlos“ erscheinende Änderung an einem Datenbank-Index sieht in Staging gut aus, erhöht in Produktion aber die Schreiblatenz, staut Anfragen und lässt Timeouts wie zufällige Netzwerkfehler aussehen. Häufige Releases geben Ihnen mehr Gelegenheiten, diese Art Überraschung einzuführen.
Cloud-Ära-Apps bedienen oft viele Kunden auf geteilten Systemen. Multi-Tenant-Setups bringen neue Probleme, die sich immer noch auf dasselbe Prinzip zurückführen lassen: Fehler isolieren.
Noisy-Neighbor-Probleme (der Anstieg eines Kunden verlangsamt andere) und geteilte Ausfälle (ein schlechtes Deploy trifft alle) sind die moderne Version von „ein Bug nimmt den Cluster mit“. Die Kontrollen sind vertraut, nur kontinuierlich angewendet: gestufte Rollouts, per-Tenant-Kontrollen, Ressourcenbegrenzungen (Quoten, Rate-Limits, Timeouts) und Designs, die partielle Ausfälle handhaben.
Observability ist die andere Konstante. Sie können Zuverlässigkeit nicht schützen, wenn Sie nicht sehen können, was passiert. Gute Logs, Metriken und Traces helfen, Regressionen schnell zu erkennen, besonders während Rollouts.
Rollback ist außerdem keine seltene Notfallmaßnahme mehr. Es ist ein normales Werkzeug. Viele Teams koppeln Rollbacks mit Snapshots und sicheren Deploy-Schritten. Plattformen wie Koder.ai bieten Snapshots und Rollback, die Teams helfen können, riskante Änderungen schnell rückgängig zu machen, aber der größere Punkt ist kulturell: Rollback sollte geübt werden, nicht improvisiert.
Wenn Sie die Zuverlässigkeit erst definieren, wenn ein Enterprise-Deal auf dem Tisch liegt, argumentieren Sie mit Gefühlen: „Es scheint in Ordnung zu sein.“ Größere Kunden wollen klare Versprechen, die sie intern wiederholen können, wie „die App bleibt erreichbar“ und „Seiten laden während Spitzen ausreichend schnell“.
Beginnen Sie mit einer kleinen Anzahl einfacher Ziele. Zwei, auf die sich die meisten Teams schnell einigen können, sind Verfügbarkeit (wie oft der Service nutzbar ist) und Antwortzeit (wie schnell sich zentrale Aktionen anfühlen). Halten Sie Ziele an dem, was Benutzer tun, nicht an einem einzelnen Server-Metrik.
Ein Error Budget macht diese Ziele im Alltag brauchbar. Es ist die Menge an Ausfall, die Sie in einem Zeitraum „ausgeben“ können, während Sie Ihr Versprechen weiterhin einhalten. Wenn Sie im Budget bleiben, können Sie mehr Liefer-Risiko eingehen. Wenn Sie es verbrauchen, hat Zuverlässigkeitsarbeit Vorrang vor neuen Features.
Um Ziele ehrlich zu halten, verfolgen Sie einige Signale, die auf reale Auswirkungen abbilden: Latenz bei Hauptaktionen, Fehler (fehlschlagende Anfragen, Crashes, gebrochene Flows), Sättigung (CPU, Speicher, DB-Verbindungen, Queues) und Verfügbarkeit entlang des kritischen End-to-End-Pfads.
Sobald Ziele gesetzt sind, sollten sie Entscheidungen beeinflussen. Wenn ein Release die Fehlerquote steigen lässt, diskutieren Sie nicht lange. Pausieren, beheben oder zurückrollen.
Wenn Sie eine schnelle Entwicklungsplattform wie Koder.ai nutzen, sind Ziele noch wichtiger. Geschwindigkeit hilft nur, wenn sie durch Zuverlässigkeitsversprechen begrenzt ist, die Sie halten können.
Der Sprung von „funktioniert für unser Team“ zu „funktioniert für einen Fortune-500-Kunden“ ist meist Architektur. Die entscheidende Denkweise ist einfach: Gehen Sie davon aus, dass Teile Ihres Systems an einem normalen Tag ausfallen, nicht nur während eines größeren Ausfalls.
Entwerfen Sie für Ausfälle, indem Sie Abhängigkeiten optional machen, wenn möglich. Wenn Ihr Billing-Provider, E-Mail-Service oder Analytics-Pipeline langsam ist, sollte Ihre Kern-App dennoch laden, Anmelden erlauben und Nutzern die Hauptaufgaben ermöglichen.
Isolationsgrenzen sind Ihre besten Freunde. Trennen Sie den kritischen Pfad (Login, Kern-Workflows, Writes zur Hauptdatenbank) von Nice-to-have-Funktionen (Empfehlungen, Aktivitätsfeeds, Exporte). Wenn optionale Teile ausfallen, sollten sie „geschlossen“ fehlschlagen, ohne den Kern mitzuziehen.
Einige Gewohnheiten verhindern in der Praxis Kaskadeneffekte:
Datensicherheit ist der Punkt, an dem „wir reparieren das später“ in Downtime umschlägt. Planen Sie Backups, Schema-Änderungen und Wiederherstellung so, als würden Sie sie wirklich brauchen — denn das werden Sie.
Beispiel: Ein Team liefert eine React-App mit einer Go-API und PostgreSQL aus. Ein neuer Enterprise-Kunde importiert 5 Millionen Datensätze. Ohne Grenzen konkurriert der Import mit dem normalen Traffic und alles verlangsamt sich. Mit den richtigen Guardrails läuft der Import über eine Queue, schreibt in Batches, nutzt Timeouts und sichere Retries und kann pausiert werden, ohne den Alltag der Nutzer zu beeinträchtigen. Wenn Sie auf einer Plattform wie Koder.ai bauen, behandeln Sie generierten Code genauso: Fügen Sie diese Schutzmaßnahmen hinzu, bevor echte Kunden davon abhängig werden.
Incidents sind kein Beweis für Scheitern. Sie sind normale Kosten beim Betrieb echter Software für echte Kunden, besonders wenn Nutzung wächst und Deployments häufiger werden. Der Unterschied ist, ob Ihr Team ruhig reagiert und die Ursache behebt oder hektisch agiert und denselben Ausfall nächsten Monat wiederholt.
Früh verlassen sich viele Produkte auf ein paar Leute, die „einfach wissen“, was zu tun ist. Unternehmen akzeptieren das nicht. Sie wollen vorhersehbare Reaktion, klare Kommunikation und Beweise, dass Sie aus Fehlern lernen.
On-Call geht weniger um Heldentaten als darum, Ratespiele um 2 Uhr morgens zu vermeiden. Eine einfache Einrichtung deckt das meiste ab, worauf große Kunden Wert legen:
Wenn Alerts den ganzen Tag feuern, stummschalten Leute sie, und der echte Vorfall wird übersehen. Verknüpfen Sie Alerts mit Nutzerwirkung: Anmeldung schlägt fehl, Fehlerraten steigen, Latenz überschreitet eine klare Schwelle oder Hintergrundjobs stauen sich.
Nach einem Vorfall führen Sie eine Review durch, die auf Fixes, nicht auf Schuldzuweisung fokussiert. Erfassen Sie, was passiert ist, welche Signale gefehlt haben und welche Guardrails das Ausmaß reduziert hätten. Setzen Sie das in ein oder zwei konkrete Änderungen um, weisen Sie einen Verantwortlichen zu und setzen Sie ein Fälligkeitsdatum.
Diese operativen Basics trennen eine „funktionierende App“ von einem Service, dem Kunden vertrauen können.
Große Kunden verlangen selten zuerst neue Funktionen. Sie fragen: „Können wir dem in Produktion täglich vertrauen?“ Die schnellste Antwort liefern Sie mit einem Härtungsplan und Nachweisen, nicht mit Versprechungen.
Listen Sie auf, was Sie bereits erfüllen vs. was fehlt. Notieren Sie die Enterprise-Erwartungen, die Sie heute ehrlich unterstützen können (Uptime-Ziele, Zugriffskontrolle, Audit-Logs, Datenaufbewahrung, Datenresidenz, SSO, Support-Zeiten). Markieren Sie jeden Punkt als bereit, teilweise oder noch nicht. Das macht vagen Druck zu einem kurzen Backlog.
Fügen Sie Release-Sicherheit hinzu, bevor Sie mehr ausliefern. Unternehmen interessiert weniger, wie oft Sie deployen, als ob Sie ohne Vorfälle deployen können. Nutzen Sie eine Staging-Umgebung, die Produktion spiegelt. Verwenden Sie Feature Flags für riskante Änderungen, Canary-Releases für stufenweise Rollouts und einen Rollback-Plan, den Sie schnell ausführen können. Wenn Ihre Plattform Snapshots und Rollback unterstützt (Koder.ai tut das), üben Sie das Wiederherstellen einer früheren Version, bis es Muskelgedächtnis ist.
Belegen Sie Datenschutz, und prüfen Sie ihn erneut. Backups sind kein Häkchen. Planen Sie automatisierte Backups, definieren Sie Aufbewahrung und führen Sie Wiederherstellungstests im Kalender durch. Fügen Sie Audit-Trails für zentrale Aktionen hinzu (Admin-Änderungen, Datenexporte, Berechtigungsänderungen), damit Kunden Vorfälle untersuchen und Compliance-Anforderungen erfüllen können.
Dokumentieren Sie Support und Incident-Response in einfacher Sprache. Schreiben Sie ein einseitiges Versprechen: Wie man einen Vorfall meldet, erwartete Reaktionszeiten, wer Updates kommuniziert und wie Post-Incident-Reports erstellt werden.
Führen Sie eine Readiness-Review mit einem realistischen Lasttestplan durch. Wählen Sie ein enterprise-ähnliches Szenario und testen Sie es Ende-zu-Ende: Spitzen-Last, langsame Datenbank, ausgefallener Knoten und ein Rollback. Beispiel: Ein neuer Kunde importiert am Montagmorgen 5 Millionen Datensätze, während 2.000 Benutzer einloggen und Reports ausführen. Messen Sie, was bricht, beheben Sie den größten Flaschenhals und wiederholen Sie den Test.
Erledigen Sie diese fünf Schritte und Verkaufsgespräche werden leichter, weil Sie Ihre Arbeit zeigen können.
Eine SaaS-App für den Mittelstand hat einige hundert Kunden und ein kleines Team. Dann unterschreibt sie den ersten regulierten Kunden: eine regionale Bank. Der Vertrag enthält strenge Uptime-Erwartungen, enge Zugriffskontrollen und die Zusage, Sicherheitsfragen schnell zu beantworten. An den Hauptfunktionen des Produkts ändert sich nichts, aber die Regeln fürs Betreiben tun es.
In den ersten 30 Tagen nimmt das Team „unsichtbare“ Verbesserungen vor, die Kunden trotzdem spüren. Monitoring verschiebt sich von „sind wir erreichbar?“ zu „was ist kaputt, wo und für wen?“ Sie fügen Dashboards pro Service und Alerts mit Nutzerimpact statt CPU-Rauschen hinzu. Zugriffskontrollen werden formell: stärkere Authentifizierung für Admin-Aktionen, überprüfte Rollen und protokollierter, zeitlich limitierter Produktionszugriff. Auditfähigkeit wird zur Produktanforderung mit konsistenten Logs für Login-Fehler, Berechtigungsänderungen, Datenexporte und Konfig-Edits.
Zwei Wochen später geht ein Release schief. Eine Datenbankmigration läuft länger als erwartet und beginnt, für einen Teil der Nutzer Requests zu timeouten. Was verhindert, dass daraus ein mehrtägiger Vorfall wird, ist grundsätzliche Disziplin: ein klarer Rollback-Plan, eine einzelne Incident-Lead-Person und ein Kommunikationsskript.
Sie pausieren den Rollout, leiten Traffic weg vom langsamen Pfad und rollen auf die letzte funktionierende Version zurück. Wenn Ihre Plattform Snapshots und Rollback unterstützt (Koder.ai tut das), geht das schneller, aber Sie brauchen trotzdem ein geübtes Verfahren. Während der Wiederherstellung schicken sie alle 30 Minuten kurze Updates: Was betroffen ist, was getan wird und wann das nächste Check-in stattfindet.
Einen Monat später sieht „Erfolg“ auf die beste Art langweilig aus. Alerts sind seltener, aber aussagekräftiger. Die Wiederherstellung ist schneller, weil die Zuständigkeiten klar sind: eine Person on call, eine koordiniert, eine kommuniziert. Die Bank fragt nicht mehr „habt ihr das unter Kontrolle?“ sondern „wann können wir die Nutzung ausweiten?"
Wachstum ändert die Regeln. Mehr Nutzer, mehr Daten und größere Kunden bedeuten, dass kleine Lücken zu Ausfällen, lärmenden Incidents oder langen Support-Fällen werden. Viele dieser Probleme wirken „in Ordnung“, bis die Woche kommt, in der Sie Ihren ersten großen Vertrag unterschreiben.
Die Fallen, die am häufigsten auftauchen:
Ein einfaches Beispiel: Ein Team fügt für einen großen Kunden eine Custom-Integration als Hotfix am späten Freitag ein. Es gibt kein schnelles Rollback, Alerts sind bereits laut, und die On-Call-Person rät nur. Der Bug ist klein, aber die Wiederherstellung zieht sich stundenlang, weil der Restore-Pfad nie getestet wurde.
Wenn Ihre Enterprise-Readiness-Checkliste nur technische Punkte enthält, erweitern Sie sie. Nehmen Sie Rollback-, Restore-Drills und einen Kommunikationsplan auf, den der Support ohne Entwickler im Raum ausführen kann.
Wenn größere Kunden fragen „Seid ihr bereit für Enterprise?“, meinen sie meist: Können wir dem in Produktion vertrauen? Nutzen Sie das als kurzen Selbst-Check vor einer Demo oder einem Versprechen im Verkaufsgespräch.
Bevor Sie eine Demo zeigen, sammeln Sie Nachweise, auf die Sie ohne Herumreden verweisen können: Monitoring-Screenshots, die Fehlerquote und Latenz zeigen; ein anonymisiertes Audit-Log-Beispiel („wer tat was, wann“); eine kurze Restore-Drill-Notiz (was Sie wiederhergestellt haben und wie lange es dauerte) und ein einseitiges Release- und Rollback-Protokoll.
Wenn Sie Apps auf einer Plattform wie Koder.ai bauen, behandeln Sie diese Checks genauso. Ziele, Belege und wiederholbare Gewohnheiten sind wichtiger als die Tools, mit denen Sie gebaut haben.
Enterprise-Readiness ist kein einmaliger Sprint vor einem großen Deal. Behandeln Sie sie wie eine Routine, die Ihr Produkt ruhig unter Druck hält, während Teams, Traffic und Kundenerwartungen wachsen.
Machen Sie Ihre Checkliste zu einem kurzen Aktionsplan. Wählen Sie die drei größten Lücken, die das meiste Risiko erzeugen, machen Sie sie sichtbar und weisen Sie Verantwortliche mit realistischen Terminen zu. Definieren Sie „Done“ in einfachen Worten (z. B. „Alert löst innerhalb von 5 Minuten aus“ oder „Restore end-to-end getestet“). Halten Sie einen kleinen Lane im Backlog für Enterprise-Blocker, damit dringende Arbeit nicht vergräbt. Wenn Sie eine Lücke schließen, dokumentieren Sie die Änderung, damit neue Teammitglieder sie wiederholen können.
Erstellen Sie ein internes Readiness-Dokument, das Sie für jeden großen Interessenten wiederverwenden. Halten Sie es kurz und aktualisieren Sie es nach jedem ernsten Kundenkontakt. Ein einfaches Format funktioniert gut: Zuverlässigkeitsziele, Sicherheits-Basics, Datenhandhabung, Deployment und Rollback sowie wer on call ist.
Führen Sie monatliche Zuverlässigkeits-Reviews als Routine ein, die sich an echten Ereignissen orientiert, nicht an Meinungen. Nutzen Sie Vorfälle und Beinahe-Pannen als Agenda: Was ist ausgefallen, wie haben Sie es entdeckt, wie haben Sie wiederhergestellt und was verhindert eine Wiederholung?
Wenn Sie mit Koder.ai bauen, integrieren Sie Readiness in Ihren Entwicklungsablauf. Nutzen Sie Planning Mode früh, um Enterprise-Anforderungen zu kartieren, bevor Sie Builds starten, und verlassen Sie sich auf Snapshots und Rollback während Releases, damit Fixes stressfrei bleiben, während Ihr Prozess reift. Wenn Sie einen Ort wollen, um diesen Workflow zu zentralisieren, ist koder.ai dafür ausgelegt, im Chat zu bauen und zu iterieren, dabei praktische Kontrollen wie Source-Export, Deployment und Rollback anzubieten.
Beginnen Sie vor der Vertragsunterzeichnung. Wählen Sie 2–3 messbare Ziele (Verfügbarkeit, Latenz für zentrale Aktionen und akzeptable Fehlerrate) und bauen Sie dann die Grundlagen, die diese Ziele halten: Monitoring, das an Nutzerwirkungen gebunden ist, ein schnell ausführbarer Rollback-Pfad und getestete Wiederherstellungen.
Wenn Sie warten, bis die Beschaffung fragt, landen Sie bei vagen Versprechungen, die Sie nicht belegen können.
Weil Unternehmen auf vorhersehbare Abläufe optimieren, nicht nur auf Funktionen. Ein kleines Team toleriert vielleicht einen kurzen Ausfall und eine schnelle Reparatur; ein Unternehmen braucht oft:
Vertrauen geht verloren, wenn Verhalten überraschend ist – auch bei kleinen Bugs.
Nutzen Sie eine kurze Liste benutzerorientierter Versprechen:
Erstellen Sie dann ein für ein Zeitfenster. Wenn es aufgebraucht ist, pausieren Sie riskante Releases und priorisieren Zuverlässigkeit.
Behandeln Sie Änderungen als das Haupt-Risiko:
Wenn Ihre Plattform Snapshots und Rollback unterstützt (z. B. Koder.ai), nutzen Sie sie – aber proben Sie trotzdem die menschlichen Schritte.
Backups beweisen nur, dass Daten irgendwo kopiert wurden. Unternehmen fragen, ob Sie gezielt wiederherstellen können und wie lange das dauert.
Minimale praktische Schritte:
Ein Backup, von dem Sie noch nie wiederhergestellt haben, ist eine Annahme, keine Fähigkeit.
Beginnen Sie einfach und strikt:
Erwarten Sie Komplexität: Abteilungen, Auftragnehmer, temporärer Zugriff und die Frage „Wer darf Daten exportieren?“ tauchen schnell auf.
Loggen Sie Ereignisse, die die Fragen „Wer hat was, wann und von wo getan?“ beantworten für sensible Aktionen:
Machen Sie Logs manipulationssicher und mit einer Aufbewahrung, die den Erwartungen der Kunden entspricht.
Zielen Sie auf weniger Alerts mit höherer Aussagekraft:
Rauschende Alerts trainieren Teams, die einzige wichtige Seite zu ignorieren.
Isolation und Lastkontrollen:
Ziel ist, das Problem eines Kunden daran zu hindern, einen Ausfall für alle zu verursachen.
Führen Sie ein realistische End-to-End-Szenario durch:
Messen Sie, was bricht (Latenz, Timeouts, Queue-Tiefe), beheben Sie den größten Flaschenhals und wiederholen Sie den Test. Ein häufiger Test ist ein großer Import, der läuft, während normaler Traffic weiterläuft und der Import durch Batch-Verarbeitung und Queues isoliert ist.
