Den Ausstieg prüfen, bevor Sie von einem Dienst abhängen
AbgeschlossenTrennen Sie Quellcode-Eigentum von betrieblicher Portabilität. Testen Sie Exporte, unabhängige Builds, Infrastrukturzugriff und die für einen Übergang nötigen Nachweise.
Veröffentlicht von TaigaWie wir schreiben
Verständnis prüfenIhre Organisation besitzt den Quellcode. Welcher zusätzliche Nachweis stützt die betriebliche Portabilität?Übung bearbeiten
Das lernen Sie
- Die für einen Betrieb ohne Anbieter nötigen Ressourcen und Rechte bestimmen.
- Eine kleine Ausstiegsübung entwerfen, bevor eine kritische Abhängigkeit entsteht.
- Export-, Übergangs- und Löschentscheidungen trennen.
Definieren Sie, was nutzbar bleiben muss
Eigentum am Quellcode ist wertvoll. Es ist nur ein Teil eines Ausstiegsplans.
Betrachten Sie eine fiktive Anwendung, deren Quellcode im Repository des Unternehmens liegt. Der Build lädt ein privates Paket des Anbieters herunter. Die Produktion nutzt ein Cloud-Konto des Anbieters. Niemand hat das Verfahren zur Datenbankwiederherstellung dokumentiert.
Das Unternehmen hat den Code, kann den Dienst aber noch nicht unabhängig betreiben. Sein Ausstiegsplan muss Rechte, Ressourcen, Zugriff und Wissen gemeinsam abdecken.
Erfassen Sie die Abhängigkeiten
| Ressource oder Verantwortung | Ausstiegsfrage |
|---|---|
| Code und Historie | Kann das nächste Team auf das vollständige Repository zugreifen? |
| Pakete und Lizenzen | Kann es jede erforderliche Abhängigkeit beschaffen und nutzen? |
| Daten und Schemas | Kann es nutzbare Datensätze mit intakten Beziehungen wiederherstellen? |
| Infrastruktur und Konfiguration | Kann es die Umgebung und erforderlichen Einstellungen neu erstellen? |
| Identitäten und Secrets | Wer erstellt neue Zugangsdaten und kontrolliert den Zugriff? |
| DNS und Zertifikate | Wer kann den öffentlichen Endpunkt verschieben? |
| Nachweise und Betrieb | Welche Entscheidungen, Runbooks, Tests und Incident-Aufzeichnungen bleiben verfügbar? |
Prüfen Sie Exportformate und Umfang. Ein lesbarer Dokumentexport erhält nicht zwangsläufig jede Beziehung, jeden Anhang oder jede Ausführungsaufzeichnung. Fordern Sie ein Beispiel an und prüfen Sie es mit den Personen, die es nutzen würden.
Führen Sie einen unabhängigen Build durch
Nutzen Sie eine sichere Testumgebung und freigegebene Beispieldaten. Geben Sie einer autorisierten Person aus dem Entwicklungsteam das vorgeschlagene Übergabepaket. Lassen Sie die Anwendung bauen, die Konfiguration anwenden, die Daten wiederherstellen und einen vollständigen Geschäftsvorgang prüfen.
Erfassen Sie jeden fehlenden Bestandteil und seine Beschaffungsdauer. Liefern Sie während der Übung kein undokumentiertes Wissen stillschweigend nach. Die Übung soll zeigen, was dem nächsten Team fehlen würde.
Prüfen Sie anschließend Übergangsbedingungen: überlappende Abonnements, Datenübertragungsdauer, Paketzugriff, Identitätsänderungen und Supportverfügbarkeit. Berücksichtigen Sie diese Kosten im Vergleich von Eigenentwicklung und Einkauf.
Trennen Sie Export und Löschung
Ein Export erstellt eine Kopie. Ein Übergang verändert, wer den Dienst betreibt. Eine Löschung entfernt festgelegte Datensätze gemäß dem vereinbarten Verfahren. Das sind getrennte Entscheidungen mit unterschiedlichen Nachweisen.
Definieren Sie die erforderliche Aufbewahrung und den Löschumfang mit den zuständigen Verantwortlichen. Bestätigen Sie die aktuellen Bedingungen und Verfahren des Anbieters. Löschen Sie nicht die einzige nutzbare Wiederherstellungskopie, bevor das empfangende System geprüft wurde.
Taiga dokumentiert einen administrativen Exportprozess und einen getrennten Löschprozess. Secret-Werte sind vom Export ausgeschlossen. Ihre Übergabe braucht deshalb einen autorisierten Weg, erforderliche Secrets neu anzulegen. Prüfen Sie die aktuellen Exportinhalte anhand Ihres Übergangsbedarfs. Nehmen Sie nicht an, dass der Export eine vollständige Anwendungssicherung ist.
Entscheiden Sie, welche Abhängigkeiten akzeptabel sind
Portabilität erfordert nicht, jeden verwalteten Dienst zu entfernen. Eine Abhängigkeit kann sinnvoll sein, wenn ihr Nutzen, ihre Grenzen und der Übergangsweg verstanden sind.
Erfassen Sie akzeptierte Abhängigkeiten, eine verantwortliche Person und einen Anlass zur erneuten Prüfung. Wiederholen Sie die Ausstiegsübung nach einer wesentlichen Architektur- oder Vertragsänderung. Fahren Sie mit einem Einführungsplan fort, der diese Verantwortlichkeiten von Anfang an enthält.
Übung bearbeiten
Ein fiktiver Anbieter gibt Ihnen ein Git-Repository und einen Datenbankexport. Nennen Sie fünf weitere Dinge, die Sie für einen unabhängigen Betrieb brauchen. Wählen Sie eines aus und beschreiben Sie einen Test, der eine fehlende Abhängigkeit aufdecken würde.
Arbeitsblatt herunterladen (Markdown)Wenn Sie diese Auswahl aufheben, wird der gesamte in diesem Browser gespeicherte Fortschritt gelöscht.
Ihr Fortschritt bleibt in diesem Browser. Ohne Konto und Tracking.
Quellen und weiterführende Lektüre
- NIST: Secure Software Development Framework ↗
- Taiga docs: Data and privacy ↗
- Taiga docs: Integrations and environments ↗