Migration validieren

Verschieben Sie Traffic erst, nachdem Verhaltens-, Sicherheits-, Performance-, Beobachtbarkeits- und Rollback-Gates übergeben wurden.

Führen Sie vor dem Cutover die folgenden Validierungsschritte aus:

  1. Geben Sie erfasste Ereignisse wieder, und vergleichen Sie erwartete Ausgaben, Fehler, Statuscodes, Header, Bodyschema, Objektmetadaten, Downstream-Schreibvorgänge, Nebeneffekte, Logs und Alarmverhalten.
  2. Führen Sie Last- und Fehlertests aus, die p95/p99-Dauer, maximale Dauer, Speicher-Headroom, kaltem Start-empfindliche Pfade, Peak-Nebenläufigkeit, Backlog- oder Warteschlangenalter, Wiederholungsstürme, Downstream-Ratengrenzwerte und Kapazitätssymptome abdecken.
  3. Testen Sie nicht wohlgeformte Payloads, doppelte Ereignisse, Giftnachrichten, nachgelagerte Nichtverfügbarkeit, Berechtigungsablehnung, geheime Rotation, Netzwerkfehler, Timeoutverhalten, Schleifenverhinderung und Rollback-Bedingungen.

Cutover zu OCI Functions

Verschieben Sie Traffic erst, nachdem Verhaltens-, Sicherheits-, Performance-, Beobachtbarkeits- und Rollback-Gates übergeben wurden.

Führen Sie die folgenden Schritte aus, um den Cutover zu OCI Functions auszuführen:

  1. Vergewissern Sie sich, dass die Gates für Funktions-, Performance-, Sicherheits- und Betriebsvalidierung erfolgreich waren.
  2. Zeichnen Sie den Cutover-Eigentümer, Rollback-Eigentümer, Erfolgskriterien, Rollback-Trigger und die erwartete Recovery-Zeit auf.
  3. Fixieren Sie nicht zugehörige Anwendungsänderungen während des Cutover-Fensters.
  4. Leiten Sie einen begrenzten, beobachtbaren Teil der Workload nach Möglichkeit an OCI Functions weiter.
  5. Überwachen Sie Geschäftsausgaben, Fehler, Timeouts, Latenz, Throttling, Backlog und Downstream-Fehler.
  6. Erhöhen Sie den Verkehr erst nach Ablauf des vereinbarten Beobachtungszeitraums.
  7. Stoppen Sie den Cutover, und führen Sie den Rollback-Plan aus, wenn ein erforderliches Erfolgskriterium nicht erfolgreich ist.
  8. Beginnen Sie die nächste Migrationswelle erst, nachdem die Anwendungs- und Operationsverantwortlichen die Produktionsergebnisse akzeptiert haben.

Wenn das prozentuale Routing nicht verfügbar ist, begrenzen Sie das anfängliche Risiko durch Trigger, Bucket, Queue, Region oder eine andere kontrollierte Workload-Grenze.

Nach Migration validieren

Vergewissern Sie sich, dass die migrierte Workload die Architektur-, Verhaltens-, Performance-, Sicherheits- und Betriebsanforderungen erfüllt.

So validieren Sie nach der Migration:

  1. Workload-Rolle, Quellbestand, Zielarchitektur, Alternativen, Risikobewertung, Servicelimits und Zielaufrufverhalten werden dokumentiert.
  2. Trigger-, Abhängigkeits-, Sicherheits-, Netzwerk- und Betriebsbestände sind vollständig genug, damit ein Prüfer die Zielentscheidung reproduzieren kann.
  3. Erfasste Ereignisse erzeugen erwartete Statuscodes, Header, Bodyschema, Objektmetadaten, Downstream-Schreibvorgänge, Nebeneffekte, Logs und Fehlerverhalten.
  4. Jeder Trigger verfügt über Tests für Payload-Format, Wiederholung, Fehler, Bestellung, Batchverhalten, Idempotenz, doppelte Zustellung, Dead-Letter- oder Fehlerweiterleitung und gegebenenfalls Giftnachrichten.
  5. Dauer von p95/p99, maximale Dauer, Speicher-Headroom, Pfade mit kaltem Start, gleichzeitige Spitzenauslastung, Backlog- oder Warteschlangenalter, Timeoutanzahl, Throttle- oder 429-Verhalten und nachgelagerte Ratenlimits erfüllen die Workload-Anforderungen.
  6. Nebenläufigkeitskontrollen schützen nachgelagerte Systeme und vermeiden Wiederholungsstürme oder ungebundenes Backlogwachstum.
  7. Zulässige Serviceaufrufe sind erfolgreich, und abgelehnte Pfade sind sicher nicht erfolgreich. Secrets sind in Quellcode, Images, Logs, Umgebungsdumps, CI-Ausgabe, Stacktraces oder Fehlermeldungen nicht vorhanden.
  8. Erforderliche private und externe Abhängigkeiten sind über genehmigte Netzwerkpfade erreichbar. Logs, Metriken, Alarme, Dashboards, Traces, Runbooks, Rollback-Trigger, Eigentümer, Schritte, erwartete Recovery-Zeit und endgültige Genehmigungen sind abgeschlossen, bevor der Traffic verschoben wird.

Allgemeine Migrationsprobleme und -begrenzungen

Vermeiden Sie diese häufigen Migrationsdesign-, Integrations- und Betriebsfehler.
  • Alle Lambda-Funktionen gleich erstellen: Klassifizieren Sie jede Funktion nach Rolle, Trigger, Abhängigkeiten, Laufzeitverhalten, Trafficprofil und Betriebsanforderungen, bevor Sie das Ziel auswählen.
  • OCI Functions zu früh auswählen: Validieren Sie Payload, Timeout, Speicher, Abhängigkeit, Aufruf, Nebenläufigkeit, Networking und Integration, bevor Sie Code neu aktivieren.
  • Angenommen, Ereignis-Payloads sind identisch: Erstellen Sie einen OCI-Handler-Adapter, und wiederholen Sie die erfassten Quellereignisse, bevor Sie Produktionstrigger verbinden.
  • Layer und native Abhängigkeiten ignorieren: Packageabhängigkeiten in das OCI-Funktionsimage oder das gemeinsame Basisimage, und testen Sie dann Imagegröße, Start, native Librarys und Abhängigkeitsversionen.
  • IAM-Übersetzung ist zu breit: Ordnen Sie beobachtete Laufzeitaktionen OCI-Policys mit der geringsten Berechtigung zu, und testen Sie abgelehnte Pfade, nicht nur den Happy-Path-Zugriff.
  • Abweichende Queue- oder Stream-Semantik: Entwerfen Sie explizite Idempotenz, Wiederholung, Teilfehler, Fehlerziel, Bestellung und Backpressure-Handling.
  • Objektereignisse verursachen Schleifen: Verwenden Sie separate Eingabe- und Ausgabepräfixe oder -filter, und validieren Sie das Verhalten zum Erstellen, Aktualisieren, Löschen, Wiederholen, Duplizieren und Schleifenprävention.
  • Vorgänge werden verschoben: Aktivieren Sie Logs, Metriken, Alarme, Dashboards, Runbooks, Fehlertests und Rollback-Prüfungen, bevor der Produktionstraffic verschoben wird.