Migration älterer Kernsysteme ohne Geschäftsunterbrechung

Kernmigrationen schlagen bei der Umstellung fehl. Nicht im Design, nicht im Build, nicht im Test: Am Wochenende wird das alte System abgeschaltet, das neue eingeschaltet und am Montag das Geschäft eröffnet, um herauszufinden, was niemand wusste. Das Muster ist häufig genug, um einen Namen zu haben, den Urknall, und häufig genug, dass die meisten Führungskräfte, die einen Kernaustausch in Auftrag geben, einen erlebt haben.

Der Standpunkt hier ist, dass der Urknall eine Wahl ist, und zwar eine schlechte. Die Alternative ist im Ingenieurwesen wohlbekannt und wird von den Vertragsunterzeichnern selten gefordert. Dem alten System ist eine Kompatibilitätsschicht vorgelagert. Die Verbraucher wechseln einzeln dorthin. Der neue Kern übernimmt Domäne für Domäne dahinter. Die Daten werden als Stream übertragen und täglich abgeglichen, nicht als Last einer einzelnen Nacht. Für jeden Schritt gibt es ein Rollback, das ausgeführt, zeitlich festgelegt und verwaltet wurde. Das Programm zeigt langsamer ein dramatisches Ergebnis und ist weitaus wahrscheinlicher, dass es zu Ende geht.

Warum der Urknall scheitert

Drei Dinge gehen schief, und zwar gemeinsam.

Das Einfrieren. Um einen Termin zu verkürzen, muss das Unternehmen Wochen oder Monate im Voraus aufhören, das alte System zu ändern, damit das neue ein festgelegtes Ziel erreichen kann. Produkteinführungen warten. Regulatorische Änderungen werden von Hand eingespielt. Der Rückstand wächst, das Datum verschiebt sich, der Stillstand verlängert sich und die Organisation lernt, um ihren eigenen Kern herum zu arbeiten. Zum Zeitpunkt der Umstellung ersetzt das neue System eine Version des alten, die nicht mehr existiert.

Der ungeübte Rollback. Der Rollback-Plan ist ein Dokument. Darin wird beschrieben, wie bei einem Ausfall des neuen Systems am Montag das alte wiederhergestellt wird. Es wurde noch nie ausgeführt, da die Ausführung bedeuten würde, dass das alte System in der Produktion heruntergefahren werden müsste. Als der Montag kommt und das neue System auf eine Weise ausfällt, die niemand vorhergesehen hat, stellt das Team fest, dass das Rollback länger dauert, als das Unternehmen warten kann, dass die seit der Umstellung geschriebenen Daten nicht zurückverschoben werden können und dass die Entscheidung zum Rollback keinen Eigentümer hat. Also drängen sie vorwärts, in ein System, das nicht funktioniert, denn zurück ist schlimmer.

Die unbekannten Verbraucher. In jedem Kernsystem, das seit einem Jahrzehnt läuft, sind die Verbraucher nicht aufgeführt. Eine Tabellenkalkulation im Finanzwesen, die eine Tabelle direkt liest. Ein Batch-Job, den ein ausgeschiedener Auftragnehmer geschrieben hat. Eine Partnerintegration, die sich mit gemeinsamen Anmeldeinformationen authentifiziert. Ein Bericht, den die Regulierungsbehörde monatlich erhält. Die Abhängigkeitskarte wurde aus Dokumentation und Interviews erstellt, und die Dokumentation war falsch und die Befragten wussten es nicht. Der Urknall entdeckt diese Verbraucher in dem Moment, in dem sie kaputtgehen.

Der Rollback-Plan wurde nie ausgeführt, da seine Ausführung bedeuten würde, das alte System herunterzufahren. Am Montag erfährt das Team, was das bedeutet.

Das alternative Muster

Das Muster besteht aus einer Handvoll Komponenten und jede entfernt einen der oben genannten Fehlermodi.

Eine Kompatibilitätsschicht, manchmal auch Fassade genannt, wird vor dem Altbaukern platziert. Es spricht die bestehenden Verträge des Altsystems, die gleichen Schnittstellen, die gleichen Dateiformate, die gleichen Nachrichtenformen, sodass kein Verbraucher wechseln muss, um mit ihm zu sprechen. Am ersten Tag werden lediglich Anrufe weitergeleitet. Es ist die Naht, entlang derer alles andere geschieht.

Ersatz im Strangler-Stil. Hinter der Schicht wird der neue Kern domänenweise aufgebaut. Wenn eine Domäne bereit ist, leitet die Ebene den Datenverkehr dieser Domäne an die neue Implementierung weiter und leitet alles andere weiterhin an die alte weiter. Das Altsystem wird nicht abgeschaltet; es wird Domäne für Domäne ausgehungert, bis nichts mehr von ihm abhängt. Dann geht es in den Ruhestand, an einem Tag, der niemandem etwas bedeutet.

Ein Verbraucher nach dem anderen. Die Verbraucher werden einzeln in einer nach Risiko gewählten Reihenfolge auf die Kompatibilitätsschicht verschoben: die am wenigsten kritischen zuerst, diejenigen mit dem bekanntesten Verhalten, diejenigen, deren Eigentümer sich im Gebäude befinden. Jede Bewegung ist klein genug, um verstanden und rückgängig gemacht zu werden. Die unbekannten Verbraucher tauchen auf, während sich die bekannten bewegen, da der Verkehr, der das Altsystem immer noch direkt erreicht, per Definition von einem Verbraucher stammt, der noch nicht auf der Karte ist. Die Karte vervollständigt sich in der Produktion sicher.

Doppellauf und Versöhnung. Für jede Domain läuft der neue Kern für einen vereinbarten Zeitraum neben dem alten. Beide erhalten die gleichen Eingaben. Ihre Ergebnisse werden jeden Tag Datensatz für Datensatz verglichen. Der Versöhnungsbericht ist der Beweis dafür, dass das neue System das tut, was das alte getan hat, einschließlich des Verhaltens, das niemand dokumentiert hat. Wo sich die beiden unterscheiden, wird der Unterschied untersucht, und oft stellt sich heraus, dass das alte System falsch war.

Feature-Flags. Die Routing-Entscheidungen in der Kompatibilitätsschicht werden durch die Konfiguration und nicht durch die Bereitstellung gesteuert. Ein Flag verschiebt einen Verbraucher oder eine Domäne auf den neuen Kern; die gleiche Flagge verschiebt es zurück. Eine Veröffentlichung und eine Umstellung sind getrennt: Der Code wird kontinuierlich ausgeliefert und das Verhalten ändert sich, wenn jemand dies beschließt.

Datenmigration als Stream. Die Daten werden nicht in einer Nacht verschoben. Ein Change-Data-Capture-Feed oder ein gleichwertiger Mechanismus kopiert Datensätze kontinuierlich vom alten zum neuen, sodass der neue Kern immer nahezu auf dem neuesten Stand ist. Die endgültige Synchronisierung für jede Domäne erfolgt in Minuten Delta, nicht in Stunden Last. Wenn die Domäne zurückgesetzt wird, kehrt sich der Stream um oder das alte System wurde überhaupt nicht mit dem Schreiben gestoppt.

Einstudierter Rollback mit definierten Triggern

Ein Rollback ist ein Vorgang, kein Plan. Der Unterschied besteht darin, dass eine Prozedur ausgeführt wurde.

Jeder Umstellungsschritt, sei es das Verschieben eines Konsumenten, das Routing einer Domäne oder das Ausmustern einer Komponente, hat ein Rollback, das in einer Produktionsumgebung ausgeführt, zeitlich festgelegt und mit der tatsächlichen Dauer dokumentiert wurde. Die Person, die es in der Produktion ausführen wird, hat es in der Probe aufgeführt. Der Schritt erfolgt erst nach Ablauf der Probe.

Die Trigger werden vor dem Schritt definiert. Ein Rollback-Auslöser ist eine im Voraus vereinbarte messbare Bedingung: eine Fehlerrate über einem Schwellenwert für eine angegebene Dauer, eine Abstimmungsdifferenz über einer vereinbarten Anzahl, ein benannter Geschäftsprozess, der fehlschlägt, ein behördlicher Bericht, der nicht erstellt werden kann. Wenn ein Trigger ausgelöst wird, wird das Rollback ausgeführt. Es gibt kein Treffen. Das Treffen fand statt, als der Auslöser vereinbart wurde, und es umfasste die Menschen, die sonst geweckt werden müssten, um eine Entscheidung zu treffen.

Die Entscheidung hat einen namentlich genannten Eigentümer. Eine Person ist befugt, jede Stufe rückgängig zu machen, ist anwesend, wenn die Stufe ausgeführt wird, und es handelt sich nicht um die Person, die das umgeschnittene Ding gebaut hat.

Beobachtbarkeit und Versöhnung als Akzeptanz

Das Akzeptanzkriterium für einen migrierten Verbraucher oder eine migrierte Domäne ist kein Freigabegespräch. Dabei handelt es sich um einen Abgleichsbericht, der für den vereinbarten Zeitraum keinen Unterschied zwischen Alt und Neu aufzeigt, und um eine Beobachtbarkeitsansicht, die zeigt, dass sich das neue System unter realer Belastung innerhalb seiner erwarteten Grenzen verhält.

Der Abgleich vergleicht die Ergebnisse auf der Ebene, die für das Unternehmen von Bedeutung ist: Salden, Termine, Richtlinien, Rechnungen, was auch immer der Kern des Aufzeichnungssystems ist. Es läuft täglich, wird von jemandem überprüft, der sich auf dem Gebiet auskennt, und jeder Unterschied wird entweder erklärt und akzeptiert oder behoben. Der Bericht wird aufbewahrt, da der Prüfer ihn anfordern wird.

Die Beobachtbarkeit wird mit den Bedienern entwickelt, die sie lesen. Strukturierte Protokolle, Metriken und Traces beantworten die Fragen, die sie tatsächlich stellen, wenn etwas nicht stimmt: Was hat sich geändert, wer ist seit wann betroffen und ob es schlimmer wird. Warnungen werden bei Bedingungen ausgelöst, die Maßnahmen erfordern, andernfalls bleiben sie stumm. Eine Warnung, auf die niemand reagiert, ist Lärm, und Lärm verbirgt die Warnung, auf die es ankommt.

Zusammengenommen ersetzen diese das Vertrauen, das ein Urknall dem Vorstand abverlangt, durch Vertrauen. Einem Direktor kann der Abgleich und die Dashboards angezeigt werden und er kann anhand von Beweisen statt Zusicherungen entscheiden, ob der nächste Schritt sicher ist.

Die Organisation rund um die Migration

Das technische Muster schlägt fehl, wenn sich die Organisation um es herum immer noch so verhält, als ob ein großer Knall bevorstehe.

Eine Wechseltafel. Eine ständige Gruppe mit Vertretern aus den Bereichen Technik, Betrieb, betroffenen Geschäftseinheiten und Compliance trifft sich in einem festen Rhythmus und genehmigt jeden Cutover-Schritt anhand der Beweise: dem Probenprotokoll, dem Abgleichsbericht, den Triggerdefinitionen und dem benannten Rollback-Eigentümer. Es ist klein und es entscheidet. Es handelt sich nicht um ein Statusmeeting.

Einfrierfenster wurden ausgehandelt, nicht verhängt. Manche Schritte brauchen noch eine Ruhephase: eine kurze, für einen bestimmten Bereich, zu einem vom Unternehmen gewählten Zeitpunkt. Die Geschäftseinheit benennt das Fenster und die Migration passt hinein, anstatt dass die Migration ein Einfrieren erklärt und das Unternehmen darum herumarbeitet. Ein ausgehandeltes Fenster wird eingehalten. Eine auferlegte Regelung wird umgangen.

Training als Schritt, nicht als nachträglicher Einfall. Die Menschen, die den Kern bedienen, am Schalter, auf der Station, am Handelsschalter, bewegen sich mit dem Verbraucher, den sie nutzen. Sie werden vor dem Umzug ihres Kunden in das neue Verhalten geschult, wobei das alte System weiterhin verfügbar ist und das von ihnen verwendete Runbook von jemandem getestet wurde, der nicht am Projekt beteiligt war.

Geregelte Kontexte

In einem Krankenhausnetzwerk oder einer Bank handelt es sich bei der Migration um eine regulierte Änderung, und nach dem oben genannten Muster werden auch die Verpflichtungen erfüllt.

Gemäß HIPAA verarbeitet ein Krankenhausnetzwerk in den Vereinigten Staaten geschützte Gesundheitsinformationen, und die Sicherheitsregel erfordert dafür administrative, physische und technische Schutzmaßnahmen, einschließlich Zugriffskontrollen, Prüfungskontrollen und Integritätskontrollen. Eine Migration berührt alle drei. Dual-Running bedeutet, dass geschützte Gesundheitsinformationen für einen bestimmten Zeitraum in zwei Systemen vorhanden sind und beide die Sicherheitsvorkehrungen erfüllen müssen. Der Abgleichsbericht ist eine Integritätskontrolle. Zugriffsprotokolle auf der Kompatibilitätsebene sind eine Prüfkontrolle. Die Geschäftspartnerverträge mit den beteiligten Anbietern müssen den Migrationszeitraum explizit abdecken.

In der Schweiz stellt die FINMA unter anderem Anforderungen an beaufsichtigte Institute zum Outsourcing, zur betrieblichen Belastbarkeit und zum Management von Risiken im Bereich der Informations- und Kommunikationstechnologie. Generell wird von einer beaufsichtigten Bank erwartet, dass sie die Kontrolle über wesentliche ausgelagerte Funktionen behält, ihre kritischen Funktionen und die Toleranzen für deren Störung identifiziert und der Aufsichtsbehörde nachweisen kann, dass eine wesentliche Änderung an einem Kernsystem geregelt, getestet und umkehrbar war. Eine Migration, die jeweils einen Verbraucher mit einstudiertem Rollback und täglichem Abgleich umzieht, erzeugt diese Beweise als Nebenprodukt. Ein Urknall bringt ein Versprechen hervor.

In jedem regulierten Kontext sind Prüfpfade nicht optional. Jede Routing-Änderung in der Kompatibilitätsschicht, jedes umgedrehte Flag, jedes Abgleichsergebnis und jedes Rollback wird mit wem, wann und warum protokolliert und das Protokoll wird für den von der Regulierungsbehörde geforderten Zeitraum aufbewahrt. Die Pipeline, die den Code bereitstellt, erzeugt ihre eigene Spur: Was wurde geändert, wer hat es überprüft, welche Tests bestanden. Compliance wird zu einer Eigenschaft des Systems und nicht zu einer Tabelle daneben.

So schließen Sie einen Vertrag ab

Der Vertrag prägt das Verhalten. Ein Vertrag mit einem einzigen Go-Live-Datum und einer damit verbundenen Zahlung erzeugt einen großen Knall, ganz gleich, was in der Methodenanweisung steht, denn der Anbieter wird für dieses Datum bezahlt.

Vertrag durch Verbraucher migriert. Definieren Sie die Verbraucher und Domänen in der Abhängigkeitskarte, vereinbaren Sie eine Reihenfolge und fügen Sie jedem einen Meilenstein hinzu: Der Verbraucher befindet sich auf der Kompatibilitätsebene, der Abgleich hat für den vereinbarten Zeitraum keine Differenz ergeben, das Rollback wurde geprobt und die Betreiber haben das Runbook ausgeführt. Die Zahlung erfolgt nach dem Meilenstein. Das Datum ist eine Prognose, kein Begriff.

Schreiben Sie die Definition von erledigt in den Vertrag: Tests, Beobachtbarkeit, Dokumentation und das Probenprotokoll für jeden Schritt. Schreiben Sie den Austritt von Anfang an in den Vertrag: Quelle in Ihren Repositories ab der ersten Woche und ein Gate, das erfordert, dass Ihr Team vor der endgültigen Zahlung einen Vorfall ohne den Anbieter freigegeben, zurückgesetzt und gelöst hat.

Die Anzeichen dafür, dass es ohnehin zum Urknall wird

Ein gut ausgearbeiteter Vertrag allein stoppt die Entwicklung nicht. Programme, die inkrementell beginnen, bewegen sich unter Termindruck auf den großen Knall zu, und die Anzeichen dafür sind Monate im Voraus sichtbar.

Die Kompatibilitätsschicht wird für „einfache“ Verbraucher übersprungen und die Zahl der Verbraucher, die direkt auf den neuen Kern verschoben werden, wächst. Die Doppellaufzeit wird termingerecht verkürzt. Versöhnungsunterschiede werden ohne Begründung akzeptiert, weil ihre Untersuchung Zeit kostet. Rollback-Proben wurden gestoppt und die letzte protokollierte Probe gilt für einen Schritt vor drei Schritten. Ein Einfrieren wurde eher angekündigt als ausgehandelt. Das Change Board ist zu einer Statusbesprechung geworden, die alles genehmigt. In einem Vorstandspapier ist ein einzelnes Datum mit dem Wort „Go-Live“ daneben aufgetaucht. Jemand hat vorgeschlagen, die verbleibenden Verbraucher zusammenzulegen, um Zeit zu sparen.

Jedes davon ist ein Gespräch. Drei zusammen ist ein großer Knall mit einem anderen Namen, und der Vorstand sollte vor dem nächsten Schritt nach den Probenprotokollen fragen.

Was tun am Montag?

1. Fragen Sie nach der Abhängigkeitskarte und fragen Sie, wie sie erstellt wurde. Wenn es sich ausschließlich um Dokumentationen und Interviews handelt, beauftragen Sie die Verkehrsanalyse, die die Verbraucher findet, die niemand aufgeführt hat.
2. Fordern Sie das Rollback-Probeprotokoll für den letzten Cutover-Schritt an. Wenn keine vorhanden ist, stoppen Sie den nächsten Schritt, bis dies der Fall ist.
3. Fordern Sie den Abgleichsbericht für die zuletzt migrierte Domain und den Namen der Person an, die ihn täglich überprüft.
4. Lesen Sie den Vertrag. Wenn die Zahlung an ein Datum und nicht an migrierte Verbraucher geknüpft ist, verhandeln Sie neu, bevor das Datum zum Plan wird.
5. Rufen Sie den Änderungsausschuss ein, der befugt ist, jeden Schritt gegen Beweise zu genehmigen oder zu stoppen, und entfernen Sie jeden, der nicht teilnehmen kann.
6. Schreiben Sie die Rollback-Auslöser für den nächsten Schritt mit den Zahlen auf und benennen Sie die Person, die die Entscheidung trifft.