Dies ist eine maschinell übersetzte Version eines ursprünglich auf Englisch geschriebenen Artikels – da mein Deutsch eher rudimentär ist, denke ich, dass dies immer noch eine bessere Lösung ist. Wenn Sie einen eklatanten Übersetzungsfehler bemerken, kontaktieren Sie mich bitte und ich werde ihn korrigieren. Ich danke Ihnen.
Warnung: Sie werden feststellen, dass vieles von dem, worüber ich schreibe, in den Bereich Betrieb, Website-Zuverlässigkeit und Devops fällt, und Sie werden vielleicht zu Recht sagen: Alter, ich bin ein Leistungstester, ich teste nur die Software. Gut. Dies ist nicht Ihr Blog. Du brauchst nicht weiterzulesen. Vielen Dank für den Besuch.
Dies ist ein Blog für Leistungstests mit einer extrem eigenverantwortlichen Denkweise. Auch wenn es nicht Ihre Schuld ist, sind Sie für alles verantwortlich. Leistungstests bedeuten hier also, dass Sie sicherstellen müssen, dass die gesamte Lösung funktioniert, egal ob es regnet oder schneit.
Wie können Sie wissen, wie gut Ihr Produkt ist? Oder ob es überhaupt gut ist? Ich meine, Ihre Konkurrenten werden Ihnen nicht einfach ihre vollständigen Leistungstestberichte schicken. Es gibt auch kein “Big Book of Performance Metrics for Your Industry”. Und keiner Ihrer Geschäftsanwender wird wahrscheinlich in der Lage sein, so etwas zu sagen wie: Alter, bei konstant 5 Benutzerregistrierungen pro Sekunde müssen wir das 99. Perzentil innerhalb von 200 ms erreichen. Das ist irgendwie eher unwahrscheinlich.
Wahrscheinlicher ist, dass sich die Leute an Sie wenden und fragen, was gut ist und wie schnell sehr schnell ist. Dies ist also eine kleine persönliche Reise zu dem, was Sie tun können, um Referenzzahlen für sich selbst zu erhalten.
Benchmarking mit sich selbst
Wenn Sie ein bestehendes Produkt mit ein paar Kunden haben, ist Ihre bisherige Leistung ein guter Richtwert. Sie muss vielleicht nicht einmal akzeptabel sein, aber Sie können sie messen und verbessern.
Benchmarks gegen explizite oder implizite Anforderungen
Verträge oder Vertriebsportfolios können explizite Anforderungen oder implizite Versprechen in Bezug auf den Umfang, die Geschwindigkeit und die Dauer enthalten. Erkundigen Sie sich in der Führungsetage, im Vertrieb, in der Produktentwicklung und im operativen Geschäft, ob es jemanden gibt, der schon einmal von jemandem gehört hat, der vielleicht ein paar Zahlen nennen kann.
Benchmarking mit Ihren Wettbewerbern
In Ihrer Branche ist dies vielleicht nicht möglich oder machbar. Wo es jedoch öffentliche Informationsquellen gibt, die alle Vorgänge protokollieren und allen Teilnehmern zur Verfügung stellen, wie z. B. beim öffentlichen Handel verschiedener Art, können Sie nachsehen, wie lange Transaktionen bei jemandem dauerten, der nicht Sie sind.
Benchmarking mit benachbarten Branchen
Möglicherweise gibt es in Ihrer Branche keine öffentlichen Informationen oder Vorschriften in Bezug auf nichtfunktionale Anforderungen, aber in einer ähnlichen oder benachbarten Branche gibt es möglicherweise ausdrücklich festgelegte Anforderungen. Diese können Sie als vorläufige Richtlinien verwenden.
Schauen wir uns die einzelnen Bereiche genauer an.
Verwendung Ihrer vorhandenen Leistungskennzahlen
Der Titel wirft die folgenden Fragen auf:
– Was verstehen wir unter Leistung?
– Mit welchen Messgrößen lässt sich die Leistung unserer Software auf der Grundlage der obigen Definition am besten erfassen?
Was sind Leistungstests in Ihrem Kontext?
Wenn Sie nach Artikeln und Definitionen zum Thema Leistungstests suchen, erhalten Sie immer dieselbe biblische Antwort. Alles machen, alles messen. Sie sprechen mit Ihren Stakeholdern und Ihren Führungskräften, die von einem perfekten, vollautomatischen CICD mit einem Dutzend Performance-Experimenten und einem riesigen grün-roten Dashboard mit Metriken, Prozentsätzen und Regressionsflags träumen werden. Die Leiter Ihrer Entwicklungsteams werden von einem einfach zu implementierenden Performance-Testing-Harness träumen, das Profile ihres gesamten Codes erstellt und sie über alle Engpässe und O(n^2)-Zeitkomplexitätsprobleme informiert, bevor der Code geschrieben wird.
Aber die harten Fakten des Lebens sagen etwas anderes. Was Sie mit diesen Ideen tun sollten, ist, sie in formalisierte Anforderungen umzuwandeln und sie in den Abschnitt “Road Map” Ihrer Leistungsstrategie aufzunehmen – aber dazu später mehr in einem anderen Beitrag.
Fürs Erste sollten Sie die Kapazitäten, die Infrastruktur und die Fähigkeiten, die Sie haben, bewerten und so wenig wie möglich tun, aber gleichzeitig das Beste daraus machen.
Schauen Sie sich Ihre Kunden an, sprechen Sie mit Ihrem Support-Team, lesen Sie die leistungsbezogenen Tickets, wenn Sie B2B sind, schauen Sie sich in den sozialen Medien um, wenn Sie B2C sind. Die Chancen stehen gut, dass einige dieser Leute bereits über Ihre schmerzhaftesten Leistungsprobleme Bescheid wissen. Ihr Problem ist, dass sie Fabeln haben und nicht die Präzision und Wiederholbarkeit wissenschaftlicher Erkenntnisse besitzen. Was sie jedoch haben, ist das, was wirklich schmerzt. Niemand wird sich die Mühe machen, ein Ticket über ein Nicht-Problem zu öffnen. Wenn sie sich die Zeit genommen haben, es aufzuschreiben, bedeutet das, dass sie sich Gedanken machen. Und wenn sie sich kümmern, sollten Sie das auch.
Führen Sie einfach eine Suche nach “Online-Service war extrem langsam” durch. All diese Beschwerden sollten ein Hinweis darauf sein, dass diese Unternehmen dringend angemessene Leistungstests benötigen. Oder schauen Sie in einer der Kategorien von Downdetector nach. Die Rubrik Finanzen ist voll von Banken, die ernsthafte Probleme mit ihrer Online-Verfügbarkeit haben. Interessiert es die Kunden, warum sie sich nicht online anmelden können, nein. Sollten Sie das? Aber ja. Sie wollen jedes Detail wissen: War es der Webserver, das Netzwerk, war es lokal oder global, war es ein Firewall-Problem, ein Problem mit dem Authentifizierungsdienst eines Drittanbieters oder war es nur das DB-Cleanup-Skript, das die Störung verursachte.
Wie sollten meine Metriken aussehen?
Sie können die Frage aus der Sicht Ihres Unternehmens oder Ihrer Interessengruppen betrachten. Wenden Sie sich an sie, stellen Sie eine Liste zusammen und fügen Sie sie Ihrer Roadmap hinzu. Wenden Sie sich dann an den Support, um herauszufinden, was Ihre Kunden am besten interessiert. Wie ticken sie? Sehr oft werden sie die Metrik tatsächlich zur Beschreibung des Phänomens verwenden.
Ihre Beschwerden konzentrieren sich in der Regel auf einige wenige Bereiche.
Schnelligkeit, auch Reaktionsfähigkeit genannt: Die Ergebnisse brauchen ewig. Ich klicke und es ist sehr langsam. Wenn das US-Büro an der Ostküste um 2 Uhr aufwacht, lädt die Datenbank stundenlang.
Robustheit, Zuverlässigkeit, Verfügbarkeit: Die App stürzt ständig ab. Der Dienst war gestern um 4 Uhr nicht verfügbar. Meine Kollegen haben ständig Probleme, sich mit Ihrem Dienst zu verbinden. Sie müssen es mehrmals versuchen, bis sie Erfolg haben.
Volumen bzw. Durchsatz: Ich habe versucht, ein 4K-Bild hochzuladen und bekam eine Fehlermeldung. Wir hatten einen anstrengenden Tag und es dauerte 9 Stunden, um alle unsere Transaktionen zu importieren, und das System war für alle unsere Benutzer einfach sehr langsam. Ich verstehe nicht, warum meine Suchergebnisse eine Viertelstunde zum Laden brauchen.
Ehrenvolle Erwähnung – Fehlertoleranz: Es dauerte 20 Minuten, bis das System einen völlig nutzlosen Fehlercode anzeigte, dass ich einen Fehler in meiner xml-Datei hatte, so dass ich die Fehlersuche nach dem zweiten Versuch aufgab. Die Datei war gut ausgearbeitet, so dass ich keine Möglichkeit hatte, herauszufinden, was ich ändern sollte.
Welche Metriken sind sinnvoll
Geschwindigkeit und Reaktionsfähigkeit
Wir sprechen hier von Antwort- und Roundtrip-Zeiten, Pings, Datenbank-Antwortzeiten, UI- und API-Antwortzeiten. Definieren Sie, was genau Sie meinen, von wo nach wo. Es ist ein Unterschied, wie lange es dauert, vom Erhalt eines Triggers bis zum Abfeuern einer Antwort in Ihrem Labor, oder wie lange Ihr Kunde in Frankfurt braucht, um eine 3 Megabyte große XML-Datei in Ihre App hochzuladen, die in Oregon auf AWS läuft, und wie lange es dauert, auf eine einigermaßen schnelle Antwort mit einem einzigen Euro-Wert zu warten. Das erste ist wesentlich einfacher zu messen und wird irreführend sein. Das zweite ist viel komplexer zu messen und zu lösen, aber am Ende ist das, was Ihre Kunden erleben, das Einzige, was zählt. Das müssen Sie gleich zu Beginn mit den Verantwortlichen klären.
Definieren Sie die Belastung: 100 – 1000 – 10.000 Transaktionen pro Stunde, Minute oder Sekunde. Ist Ihre Maschine zustandslos oder zustandsbehaftet (ein hervorragender kleiner Vortrag von dem Erfinder von Gatling: ). Ist Ihr Produkt B2C oder B2B? Besteht der Datenverkehr hauptsächlich aus “get”-Anfragen, die aus der DB oder dem Inhaltsspeicher gelesen werden, oder gibt es alle möglichen GETs, POSTs, PUTs und DELs, die die DB intensiv nutzen? Fließt der Datenfluss nur in eine Richtung, oder ist er sowohl vor- als auch nachgelagert? Beginnen Sie mit etwas Einfachem, aber Realistischem.
Definieren Sie das Muster: Kommen Ihre Kunden in Scharen zu Ihnen und bilden so eine Art Glockenkurve? Gibt es spezielle Kunden, die innerhalb weniger Minuten 5.000 Transaktionen tätigen und damit Spitzen erzeugen? Versendet Ihr Marketingteam Hunderttausende von E-Mails in Stapeln von 10.000 Stück, wodurch Igel entstehen? Wachen Ihre ersten Kunden um 7 Uhr in der Eurozone auf, dann eine zweite Welle zur Mittagszeit, gefolgt vom Aufstehen an der Ostküste, dann an der Westküste, dann wieder die Mittagszeit? Gestalten Sie das Verkehrsaufkommen für jedes Szenario, schauen Sie sich auch Statistiken aus dem wirklichen Leben an, wenn Sie Zugang dazu haben.
Definieren Sie die Erwartungen für Perzentile: Sagen wir, Sie möchten, dass Ihre API im Norden innerhalb von 150 ms für das 90. Perzentil, 200 ms für das 95. Perzentil, 300 ms für das 99. Perzentil reagiert, wobei die Maximalwerte immer unter 400 ms liegen. Sie können entweder beliebige Zahlen wählen oder eine Reihe von Messungen durchführen und die Ergebnisse als Richtwerte verwenden.
In jedem Fall sollten Sie die Ergebnisse in einem Leistungsbenchmarking-Leitfaden dokumentieren. Dieses Dokument sollte einen Referenzabschnitt enthalten, in dem die Messgrößen definiert werden, die Methodik beschrieben und erläutert wird, warum bestimmte Entscheidungen getroffen wurden, und schließlich brauchen Sie auch einen Referenzabschnitt, in dem die Benchmark-Werte aufgezeichnet werden. Dieses Dokument ist für die Nachwelt bestimmt, so dass die Menschen, einschließlich Ihrer zukünftigen Person, einfachen Zugang zu Referenzdaten für Leistungsvergleiche haben.
Robustheit, Zuverlässigkeit, Verfügbarkeit:
Ein kleiner Umweg über die Verfügbarkeit, insbesondere bei Cloud-Diensten
Früher oder später werden Sie in diese Gespräche hineingezogen werden. Ob aus rechtlicher Sicht, aus der Sicht des Supports oder aus der Sicht des Vertriebs, spielt keine Rolle. Sie werden gefragt werden: Wie hoch ist unsere Betriebszeit? Was sollten wir in unsere SLAs aufnehmen? Zu was können wir uns verpflichten, wenn wir Versprechungen machen? Und weil alle anderen dazu neigen, zu viel zu versprechen und zu wenig zu liefern, und weil Sie sich noch nicht in einem Stadium befinden, in dem Sie über Jahre hinweg verlässliche Metriken haben, um Ihre Aussagen zu untermauern, sollten Sie sehr vorsichtig sein. Messen Sie viel, führen Sie mehrere Szenarien durch, lassen Sie jedes mehrmals in verschiedenen Umgebungen laufen und führen Sie sorgfältig Buch. Geben Sie für die Rechtsabteilung Schätzungen ab, die sich auf die schlimmstmöglichen Szenarien und die pessimistischsten Zahlen stützen, für Dev One mit den wahrscheinlichsten Ausfallprognosen, die alle zusammengerechnet werden, und geben Sie dem Vertrieb eine realistische Schätzung.
Sofern Sie nicht auf die altmodische Art und Weise Feuerstein-Tools herstellen, ist Ihre Verfügbarkeit wahrscheinlich durch die Verfügbarkeit Ihrer Drittanbieter begrenzt. Ihr Hosting-Provider, Ihr Compute-Provider, Ihr Authentifizierungsdienst, Ihr Speicherplatz und alle anderen Dienste, auf die Sie angewiesen sind, haben ihre eigenen SLA, also überlegen Sie sich gut, wie viel Verfügbarkeit Sie in Ihre rechtsverbindlichen Vereinbarungen aufnehmen. Es gibt einen wirklich guten Beitrag von Google über zusammengesetzte Verfügbarkeitsberechnungen in der Cloud, den man unbedingt lesen sollte.
Eine Heuristik zur Verfügbarkeit
Menschen mit den Titeln “Manager” und “Chef” werden wahrscheinlich zu Ihnen kommen und Sie fragen, ob Sie/wir eine Verfügbarkeit von 99,9 % garantieren, versprechen oder liefern können. Die Antwort ist in den meisten Fällen ein klares Nein, aber Sie müssen in der Lage sein zu erklären, dass selbst wenn Ihre Software und die Bereitstellung perfekt sind, selbst 99 % eine große Herausforderung darstellen.
– Wenn Anbieter eins Ihnen eine Verfügbarkeit von 99 % pro Monat bietet, Anbieter zwei 98 % und Anbieter drei 95 %, dann kann Ihre Verfügbarkeit nicht besser als 92 % sein. Nicht 97 %, nicht 92,1 %. Ihre Ausfallzeit als Folge ihrer Ausfallzeiten ist nicht das Produkt, sondern die Gesamtsumme ihrer Ausfallzeiten.
“Aber Sie irren sich, das steht nicht in den dicken, fetten Lehrbüchern!”
Klar. Wenn Sie sich mit dem Buchansatz wohler fühlen, nur zu. Ich bin ein Typ wie Fat Tony. Kaskadierende Ausfälle, die Tatsache, dass das Netzwerk Ihren Zugang zum Speicher beeinträchtigt, sind irrelevant, und die Tatsache, dass zwei dieser Dienste gleichzeitig ausfallen, erhöht definitiv nicht ihre Gesamtbetriebszeit.
Jeder Anbieter wird seine Ausfallzeiten ohne Rücksicht auf andere nutzen. Das alles ist unabhängig von Ihrer Perspektive. Wenn Ihr Speicher für eine halbe Stunde im Monat ausfällt und Ihr Rechner für eine halbe Stunde, ebenso wie Ihr Netzwerk und Ihr Webserver, dann sind Sie für zwei Stunden ausgefallen. So einfach ist das. Wenn also alle Ihre Provider 99,9 % bieten, bedeutet das, dass Sie es nicht sein können.
Wenn Ihre Software nicht perfekt ist, finden Sie hier eine Übersicht darüber, was Sie bei Ihren Berechnungen berücksichtigen sollten.
Was Sie bei Ihren Verfügbarkeitsberechnungen berücksichtigen sollten
Denken Sie daran, dass Sie in diesem Stadium noch keine historischen Daten haben, auf die Sie sich stützen können. Die Daten eines halben oder ganzen Jahres sind eine tolle Referenz, aber mir würden die Hände schwitzen, die Knie weich werden und die Arme schwer, wenn ich auf der Grundlage dieser Zahlen einen verbindlichen Vertrag unterzeichnen würde. Wenn Sie das tun, überprüfen Sie Ihre Diagramme, ob sie eine Tendenz zum Besseren oder Schlechteren zeigen, und verwenden Sie ein möglichst großes Zeitintervall. Die Betriebsdaten von sechs Monaten werden nicht alle potenziellen Ausfallzeiten aufzeigen, die Ihre Rechtsabteilung abdecken muss. Damit die Spaghetti nicht zu groß werden, hier meine Aufzählung der Dinge, die Sie berücksichtigen sollten.
Ich weiß auch, dass kein Unternehmen die Zeit und das Geld aufbringen wird, um alles auf dieser Liste zu testen. Es handelt sich eher um ein Menü, aus dem Sie diejenigen auswählen können, die die größten und katastrophalsten Risiken in Ihrer Welt darstellen.
Startup-Zeiten
Ihre Systeme oder Komponenten sind nicht sofort verfügbar, wenn der Code gestartet wird. Rechnen Sie also Zeit für die Inbetriebnahme ein.
Was ist zu testen und was zu messen?
Testen Sie die Startzeiten vom Einschalten bis zum Abschluss der ersten erfolgreichen Transaktionen. Die Zeitpunkte, an denen Sie bei Bare Metal interessiert sind, reichen vom Einschalten bis zum Bereitstellen des Betriebssystems, der Plattform, des Containers, des Ladens von Datenbanken und Referenzdaten, des Aufbaus von Verbindungen, des Eintreffens der ersten Heartbeats, des Eincheckens der letzten Komponente und des Abschlusses der ersten Transaktion. In virtuellen Umgebungen sollten Sie messen, wie lange es dauert, bis der Hypervisor online ist, wie lange Docker braucht, um hochzufahren, wie lange Ihre Container und Pods brauchen, um hochzufahren, und der Rest der Software-Checkpoints sollte derselbe sein.
Die ersten Transaktionen werden oft ignoriert, aber sie sind das wahre Zeichen dafür, dass Sie nicht nur online sind, sondern auch laufen. Ein solcher Test, den ich bei Produktionssystemen von Kunden eingesetzt habe, war ein Negativtest: Ich habe die API des Kunden mit einem ungültigen Schlüssel angefunkt und ein 401 erwartet, das wir zur Maskierung des serverseitigen Fehlers verwendet haben.
OS-Updates und Upgrades
Es kann sein, dass Sie einige Zeit für Betriebssystem-Updates einplanen müssen (Betriebssystem ist hier definiert als eine Art von Nix-Flavour), die normalerweise keine allzu große Ausfallzeit erfordern, es sei denn, ein Kernel-Update ist notwendig, in diesem Fall müssen Sie das verdammte Ding neu starten. Wenn Sie gezwungen sind, von einer Sunset-Version zu migrieren, ist das eine andere Sache, bei der Sie die Umstellung praktisch ohne Ausfallzeit durchführen können. In jedem Fall müssen Sie die Neustartzeiten für den gesamten Cluster einkalkulieren. Diese kann erheblich von der Startzeit eines einfachen Testaufbaus abweichen.
Was ist zu testen und was ist zu messen?
Im Idealfall arbeiten Sie in einem Blue-Green-Setup, so dass Sie den sekundären Server für diese Experimente verwenden und die Zeiten für alle 30 Server messen können, nicht nur für die drei im Labor. In einer weniger idealen Welt haben Sie dies wahrscheinlich bereits getan, so dass Sie auf Ihre Logs und /var/log/messages zurückgreifen müssen und zuletzt Ihre Freunde mit einer großzügigen Menge an Grepping sind. In jedem Fall sollten Sie von der Ausgabe des Shutdowns bis zum Abschluss aller Startvorgänge alles aufzeichnen.
Wenn Sie ein prod-ähnliches Labor haben, führen Sie immer wieder denselben Neustart-Test mit verschiedenen Ausgangszuständen durch. Starten Sie neu, wenn es keine Last gibt, starten Sie neu, wenn die DB leer ist, starten Sie neu, wenn Sie bereits eine halbe Million Datensätze in Ihrer DB haben, starten Sie neu, wenn Sie mehrere Traffic Runners haben, die das System großzügig auslasten. Sie sind nicht an Durchschnittswerten interessiert. Sie interessieren sich für die schlechtesten Ergebnisse. (Sobald Sie die Benchmark-Zahlen haben, sollten Sie sich diese Ergebnisse noch einmal ansehen und herausfinden, was und warum: Welche Systemressource ist mein Engpass? Welche Komponente brauchte am längsten, um hochzufahren? Warum war sie so langsam? Warum hat die DB nicht geantwortet? … Die Antworten sind für die Ops- und Dev-Teams von entscheidender Bedeutung).
Software-Upgrades
Wenn Sie eine Zero-Downtime-Bereitstellung haben, ist das gut für Sie. Alle anderen sollten die doppelte Zeit einplanen, die normalerweise für Upgrades benötigt wird. Wenn Sie früher fertig werden, wird Ihnen niemand auf die Schulter klopfen, wenn nicht, haben Sie genug Puffer, um Ihre SLAs nicht zu verpassen.
Was ist zu testen und was ist zu messen?
Die Installierbarkeit gehört zu den Leistungstests, die nur in den Lehrbüchern aufgeführt werden, aber ansonsten nie wirklich ein Thema sind. Oh, warten Sie… Ich habe an einem Projekt gearbeitet, bei dem jedes Upgrade ein zermürbender dreitägiger manueller Prozess war und der QA-Projektzyklus ebenfalls drei Tage dauerte.
– Testen Sie die Installation in einer produktionsähnlichen Umgebung.
– Testen Sie Upgrades in produktionsähnlichen Umgebungen.
Setzen Sie einen tatsächlichen Zeitmesser, wie lange es von Anfang bis Ende dauert. Keine Schätzung, sondern eine tatsächliche Zeitangabe.
Heuristiken für rote Fahnen, die darauf hindeuten, dass Ihre Zahlen nicht halten werden
– XZY ist ein besonderer Kunde. Wir haben eine besondere Vereinbarung mit ihnen.
– MNO ist ein solches maßgeschneidertes Projekt. Es enthält eine Menge benutzerdefinierten Code, der nicht in Ihrem Haupt-Repository enthalten ist.
– ABC hat einige benutzerdefinierte Konfigurationen. Das führt in der Regel dazu, dass die Konfiguration ein Chaos ist, so dass Ihr Skript zur Migration der Konfiguration nicht funktionieren wird.
– QWE ist ein On-Premise-Einsatz, bei dem der Kunde auch einige seiner speziellen Skripte installiert hat. Sie haben es mit einer unsauberen Installation/Upgrade zu tun, und Sie haben keine Ahnung, wie viele Ressourcen Ihrer Anwendung tatsächlich zur Verfügung stehen.
All dies bedeutet, dass Ihre Standardmessungen zu Schätzungen führen, die um 100 % bis 1000 % daneben liegen.
Datenbank-Upgrades und -Migrationen, Schemaänderungen
Rechnen Sie bei DB-Migrationen und Schemaänderungen mit dem Vierfachen des Zeitaufwands, den Sie beim Testen hatten. Ich erinnere mich an einen Fall, bei dem es um ein größeres DB-Upgrade ging und die Jungs um ein Zeitfenster von 8 Stunden baten. Sie bekamen 4 Stunden. Letztendlich dauerte es 48. Ich habe 150 Vertriebsmitarbeiter beobachtet, die sich auf dem Boden herumtrieben, weil sie zwei Tage lang keinen einzigen Anruf tätigen konnten. Ich erinnere mich auch daran, dass die DBAs 48 Stunden später etwa 60 Jahre älter aussahen.
Was man testen und was man messen sollte
Versuchen Sie, eine anonymisierte Kopie der Produktivdatenbank zu erhalten. Wenn ja, verwenden Sie diese für alle Ihre DB-Tests. Vergewissern Sie sich, dass alle Schritte automatisiert sind und dass Ihr kompletter automatisierter Regressionstestsatz ohne Fehler läuft.
Wenn Sie ein grünes und blaues System haben, testen Sie auch, wie lange es dauert, ein Rollback durchzuführen, falls das Upgrade fehlschlägt. Wenn Ihre Einrichtung anders ist, testen Sie, wie lange eine Sicherung und Wiederherstellung dauert.
Wenn Sie keine Wiederherstellung durchführen können, buchen Sie 36 Stunden über das Wochenende, bestellen Sie Pizza und Limonade, und vielleicht ist das Glück ja doch noch zu Ihren Gunsten. Und stellen Sie sicher, dass die Rechtsabteilung eine Klausel in die Verträge aufnimmt, die besagt, dass DB-Upgrades nicht in den Geltungsbereich verbindlicher SLAs fallen.
Bei längeren Wartungsfenstern können Sie kreativ sein. Erstens sollte in Ihren Verträgen ausdrücklich festgehalten werden, dass Sie diese von Zeit zu Zeit benötigen. Zweitens passen 8 Stunden vielleicht nicht in Ihre monatlichen SLA-Metriken, aber ein vierteljährliches oder jährliches Fenster dieser Größe sollte machbar sein. Der 8-Stunden-Slot entspricht 0,3 % Ausfallzeit im Quartal und 0,09 % pro Jahr.
Hardware-Ausfälle
Berücksichtigen Sie Hardware-Fehler und Ersatzzeiten. Wir hatten ein großes Upgrade, das auf einem Cluster von 936 Dell 380 Blades durchgeführt werden sollte. Und wir wussten, dass Festplatten-Controller und Festplatten anfällig für Neustarts sind, d. h., dass einige von ihnen möglicherweise nicht mehr hochfahren. Und wenn das während des Upgrades passiert, sind wir verloren. Da diese Knoten bereits seit über zwei Jahren in Betrieb waren, mussten wir sie während des Upgrades aufgrund eines Kernel-Updates neu starten. Als Präventivmaßnahme haben wir vor dem Upgrade alle Knoten stapelweise neu gebootet und mussten schließlich nur einen Festplattencontroller austauschen, und das Upgrade verlief problemlos. Ich denke, meine Hauptbotschaft lautet: Hardware fällt aus, rechnen Sie damit. Ihre Infrastrukturexperten werden wahrscheinlich wissen, wie lange es dauert, bis neue Teile anfangen zu zerbröseln, also geben Sie sich auch dafür Zeit. Sie werden auch wissen, ob ein Hot-Swapping möglich ist. Außerdem sollten Sie Ihre Raid-Konfiguration kennen, damit Sie abschätzen können, wie viel Zeit Sie für einen Austausch benötigen.
Was ist zu testen und was ist zu messen?
Sprechen Sie zuerst mit der Betriebsleitung. Fragen Sie, ob Sie über genügend Redundanz verfügen, damit ein einzelner Hardwareausfall nicht das gesamte System lahm legt. Bei Bare Iron erwarten Sie ein ordentliches, vollständig redundantes N+1-System. Aber auch bei virtualisierten Systemen würden Sie gerne hören, dass alle Komponenten entkoppelt sind, in eigenen, unabhängigen Containern laufen und ein Hot-Hot-Sekundärsystem auf einem separaten physischen Server vorhanden ist.
Aber für diejenigen von uns, die nicht so viel Glück haben… Ich schätze, wir müssen einfach härter an den folgenden Punkten arbeiten:
Disaster Recovery
– Wie lange dauert eine komplette Neueinrichtung?
Denken Sie daran, dass Sie, wenn Sie bis hierher gelesen haben, derjenige sind, der keine Datenbanksicherung und keine vollständig redundante Einrichtung hat. Sprechen Sie also mit der Betriebsleitung, um herauszufinden, wie lange es dauert, bis sie die Hardware gemäß den richtigen Spezifikationen bereitstellt. Dokumentieren Sie die Hardwarespezifikationen als Referenz. Wie lange die Installation und Konfiguration des Betriebssystems und der Plattform dauert. Finden Sie heraus, ob es eine Standardkonfiguration gibt, die sofort einsatzbereit ist, oder ob Sie stundenlang manuell in irgendeiner obskuren Konfigurationsdatei herumfummeln müssen. Fragen Sie speziell nach Firewalls, Loadbalancern und Netzwerken. (Es gibt kaum etwas Lustigeres, als ein System in zwei Subnetzen mit einer Firewall dazwischen einzurichten, während der Kunde gegen das Fenster des Serverraums trommelt und Ihre Chefetage und Ihr PM getrennte halbstündliche schriftliche Berichte verlangen. War nur ein Scherz. Es könnte schlimmer sein.) In diesem Stadium können Sie kaum etwas anderes tun, als zu dokumentieren, wie lange es dauern würde, bis das System einsatzbereit ist, und, oder besser gesagt, UND dies jedem mitzuteilen, den Sie auf dem Flur treffen. Dies ist ein großes Risiko, und Sie wollen, dass die Leute davon wissen. Sie können dies auch einfach in einer Besprechung oder in einer E-Mail ansprechen, die Antworten können ziemlich harsch oder knapp ausfallen, oder beides. YMMV.
Als Trostpflaster haben Sie zumindest auf dem Papier, wie lange eine komplette Einrichtung vom nackten Eisen bis zur ersten erfolgreichen Transaktion dauert – das wird in Ihren Geschäftskontinuitätsplänen für die betriebliche Wiederherstellung im Katastrophenfall sehr nützlich sein.
– Wie lange dauert es, Teile zu ersetzen, die regelmäßig ausfallen?
Sprechen Sie mit Ops über die Festplatten, das Raid in Prod und das Raid im Labor. Fragen Sie sie, wie lange es dauert, eine Festplatte zu ersetzen. Verdoppeln Sie diese Zeit für den Fall, dass die Platte nicht im laufenden Betrieb ausgetauscht werden kann.
– Hardware-Abhängigkeiten für virtualisierte Umgebungen (z. B. Docker)
Ich weiß, dass alle Docker-Leute sagen: “Juhu, zum Glück muss ich mir keine Sorgen um die Hardware machen. Wir hatten diese Python-Anwendung, der der Speicher durch die Nase lief, und die Container wuchsen wie verrückt. Wir hatten einen Testaufbau, der um 2 Gigabyte pro Stunde wuchs. Da die Softwarebehebung eine Plattformbehebung erforderte, was in diesem Jahrhundert nicht mehr möglich sein würde, mussten die Systeme regelmäßig neu gestartet werden.
Um nicht täglich neu starten zu müssen, wurde der verfügbare Festplattenspeicher verdreifacht, damit die Container Platz zum Wachsen hatten. Die bittere Pille kam, als wir feststellten, dass die Container nicht heruntergefahren wurden, als der Hardware-Speicherplatz unter der Virtualisierungsschicht vergrößert wurde, so dass das Mapping zwischen der Hardwareschicht und der virtuellen Schicht durchgeführt wurde. Das Mapping auf dem Live-System brachte die Referenzen durcheinander und die Systeme blieben zwischen den beiden Welten stecken. Wir konnten sie nicht herunterfahren, weil die Referenzen falsch waren, aber sie hatten trotzdem keinen Platz mehr. Es bedurfte einiger dunkler Magie, um diese Instanzen in dieser Welt wiederherzustellen. Alles, was mit einer Größenänderung der Virtualisierung zu tun hat, kann also eine gewisse Ausfallzeit erfordern, wenn Sie nicht genügend physischen Speicherplatz zur Verfügung haben.
Noch schlimmer wird es, wenn Ihre Anwendung so konzipiert ist, dass sie nur in einer einzigen Instanz ausgeführt werden kann, was passiert, wenn ein Ereignis wie Sandy eintritt. Als Sandy, der Hurrikan, NYC traf, hatten wir einen Hosting-Anbieter, dessen Serverraum sich in einem Keller befand… Junge, die Fische schwammen zwischen den Blättern. Unsere Server standen drei Meter hoch im Wasser.
Berücksichtigen Sie, wie lange es dauert, bis Sie sich wieder erholt haben. Dies ist eines der Themen, die man lieber gar nicht erst erwähnt, geschweige denn offen und ehrlich darüber spricht. Die meisten Unternehmen betrachten dieses Thema in geschäftlichen und rechtlichen Gesprächen als Tabu, und selbst die Entwicklungs- und Betriebsabteilungen neigen dazu, es mit einem “Es passiert nicht viel, und es geht ganz schnell” abzuwinken, während sie auf ihre Schuhe starren. Sie müssen also ehrlich und taktvoll sein. Sie müssen das “nicht viel” und das “sehr schnell” quantifizieren. Nehmen Sie mehrere Stichproben, um festzustellen, wie lange Ihr komplettes System zum Hochfahren und zum Neustart braucht.
Nun machen Sie dasselbe in einer ressourcenbeschränkten Umgebung: reduzieren Sie Speicher, Festplatten, Kerne, Kaffee, was auch immer. Und warum? Wenn Ihr System abstürzt, wollen Sie, dass es so schnell wie möglich wieder läuft, damit Sie nicht erst nach Dingen suchen müssen, die Sie reparieren können. Sie wollen, dass es wieder läuft, und dann reparieren Sie es. Sie müssen also wissen, ab welchem Ressourcenverbrauch Ihr System nicht mehr hochgefahren werden kann. Sie müssen wissen, wie viel länger es dauert, bis das System startet, wenn es gerade noch akzeptabel ist.
Nebenbemerkung für Docker-Leute zum Thema Hardware-Pinning und automatisches Failover auf andere Hardware.
In der Cloud und virtualisiert bedeutet nur, dass Sie Ihre Hardwareprobleme an jemand anderen vermietet haben. Fairerweise muss man sagen, dass es sich dabei um eine spezielle Fähigkeit handelt, für die es schwer ist, gute Leute zu finden, daher macht es durchaus Sinn. Aber es bedeutet nicht, dass Ihr System jetzt völlig hardwareunabhängig ist. Wenn jemand das behauptet, muss er ernsthaft umgeschult werden. Schicken Sie ihn zu Ihrem Betriebsteam und stellen Sie sicher, dass er sechs Monate lang für den Betrieb arbeitet.
Infolgedessen würden Sie normalerweise keine Leistungstests durchführen, insbesondere keine Last-, Volumen- und Stresstests in virtualisierten Umgebungen. Das Beste, was Sie tun können, sind Vergleichsexperimente, die jedoch völlig unzuverlässig sein können, da Sie keine Garantien für die Hardwareebene unter Ihrer virtuellen Umgebung haben. Manchmal kann es eine Ausnahme geben. Sie können beantragen, dass bestimmte Hardware an Ihre VMs angeheftet wird. Dann können Sie es versuchen. Sie werden immer noch davon betroffen sein, wie stark andere Systeme auf derselben Hardware ausgelastet sind, worauf Sie einen gewissen Einfluss haben können oder auch nicht.
Wenn Sie Backup-Systeme haben, sollten diese idealerweise auf einer anderen Hardware virtualisiert werden, die weit von der primären Instanz entfernt ist.
Als Nächstes steht der eigentliche Volumentest an. Das Warum, Was und Wie.
