Nutze diese Checkliste zur Übergabe einer produktionsreifen App: Verpacke Umgebungen, Secrets, Monitoring, Backups und Runbooks so, dass der Betrieb die App deployen und betreiben kann.
Eine produktionsbereite Übergabe bedeutet, dass Ops die App ohne Rateversuche betreiben kann. Sie können eine bekannte Version deployen, bestätigen, dass sie gesund ist, auf Alerts reagieren und von einem schlechten Release oder Ausfall wiederherstellen. Wenn irgendetwas davon vom Gedächtnis eines einzelnen Entwicklers abhängt, ist die Übergabe nicht abgeschlossen.
Betrachte die Übergabe als ein Paket, das eine Frage beantwortet: Wenn die ursprünglichen Erbauer eine Woche verschwinden, kann Ops das System trotzdem sicher und verfügbar halten?
Ein solides Paket beschreibt in der Regel, was die App macht, wie „gesund" aussieht, wie Releases funktionieren (deploy, verifizieren, rollback), wo Konfiguration liegt, wie Secrets gehandhabt werden und wie Monitoring, Backups und Incident‑Antworten laufen.
Genauso wichtig ist, was es nicht abdeckt. Eine Übergabe ist kein Versprechen, Features hinzuzufügen, umzustrukturieren, Bildschirme neu zu gestalten oder „später aufzuräumen“. Das sind eigene Projekte mit eigenem Umfang.
Bevor ihr sie als abgeschlossen erklärt, einigt euch auf Ownership und Reaktionszeiten. Zum Beispiel: Ops ist für die Uptime verantwortlich und deployed; das Produktteam ist für Roadmap‑Änderungen zuständig; das Entwicklerteam stellt ein definiertes Zeitfenster für Nachbetreuung zur Verfügung, um Fehler zu beheben und Fragen zu beantworten.
Ops kann nur das übernehmen, was sie sehen. Ein einfaches einseitiges Inventar verhindert Rätselraten bei Deploys, Vorfällen und Audits. Halte es in klarem Deutsch und konkret.
Liste jede laufende Komponente und ihren Ort: Backend‑API, Webapp, Background‑Worker, geplante Jobs und wie mobile Apps sich verbinden. Selbst wenn iOS/Android über Stores verteilt werden, sind sie weiterhin auf dasselbe Backend angewiesen.
Führe externe Dienste auf, ohne die die App nicht laufen kann. Wenn ihr PostgreSQL, eine Queue, Objektspeicher oder Drittanbieter‑APIs nutzt (Zahlungen wie Stripe, Messaging, E‑Mail/SMS, Telegram), schreibe den genauen Servicenamen und den Verwendungszweck auf.
Erfasse Netzwerkanforderungen, damit Hosting nicht zum Trial‑and‑Error wird: benötigte Domains (App, API, Admin), Ports und Protokolle, wer TLS‑Zertifikate erneuert, wo DNS verwaltet wird und irgendwelche Inbound/Outbound‑Allowlists.
Schreibe schließlich erwartete Last in realen Zahlen auf: Peak‑Requests pro Minute, aktive Nutzer, typische Payload‑Größen, aktuelle Datenbankgröße und erwartetes Wachstum. Auch grobe Bereiche helfen Ops, Limits und Alerts zu setzen.
Wenn ihr mit AppMaster gebaut habt, dokumentiert das generierte Backend, die Webapp und Integrationen, damit Ops weiß, was zusammen deployed werden muss.
Produktiv‑Setups scheitern meist an der langweiligen Stelle: Konfiguration, die nur im Kopf einer Person existiert. Behandle Konfiguration als lieferbares Artefakt. Ops sollte sehen können, welche Einstellungen existieren, was sich zwischen Umgebungen unterscheidet und wie man sie sicher ändert.
Beginne damit, jede heute existierende Umgebung zu benennen, auch wenn sie temporär erscheint. Die meisten Teams haben dev, staging und production sowie Kopien wie „production‑eu“ oder „staging‑us“. Notiere, welche Umgebung für Release‑Tests, Datenbankmigrationen und Incident‑Übungen genutzt wird.
Stelle eine einzelne Konfigurationsreferenz bereit, die Variablennamen und sichere Beispielwerte aufführt (niemals echte Zugangsdaten). Mach Platzhalter deutlich sichtbar.
Dein Übergabepaket sollte enthalten:
Füge einen einfachen Änderungsprozess hinzu. Zum Beispiel: Anforderung per Ticket, Review durch den Service‑Owner, zuerst in Staging anwenden, dann in einem geplanten Fenster nach Production promoten mit einem Rollback‑Plan für steigende Fehlerquoten.
Wenn du eine AppMaster‑App exportierst und selbst hostest, gilt dieselbe Regel: liefere ein sauberes, dokumentiertes Set an Konfig‑Keys zusammen mit dem generierten Quellcode, damit Ops es konsistent über Umgebungen betreiben kann.
Secrets sind der schnellste Weg, wie aus einer sauberen Übergabe ein Sicherheitsvorfall wird. Das Ziel ist einfach: Ops soll jedes Secret kennen, wo es liegt, wer es lesen kann und wie man es ändert, ohne Ausfallzeiten zu verursachen.
Beginne mit einer kurzen Secret‑Liste, die Ops in einer Minute überfliegen kann. Notiere für jeden Eintrag, was es entsperrt (Datenbank, SMTP, Stripe, JWT‑Signing‑Key), wo es liegt (Vault, Cloud Secret Store, Kubernetes Secret, verschlüsselte Datei) und wer für die Rotation verantwortlich ist.
Schreibe Rotationsschritte wie ein Rezept, nicht als Policy. Nenne die genaue Reihenfolge, wie lange das alte Secret gültig bleiben muss und den einen Check, der beweist, dass es funktioniert hat.
Verwende dieses Muster für jedes Secret:
Sei explizit bei Verschlüsselungserwartungen. Secrets sollten im Secret‑Store verschlüsselt sein und die Übertragung (TLS) zwischen App und Abhängigkeiten geschützt sein. Niemals Secrets in Source‑Control, Build‑Artefakte oder geteilte Docs legen.
Definiere Break‑Glass‑Zugriffe. Falls ein Ausfall normalen Zugriff blockiert, nenne, wer Notfallzugriff genehmigen darf, wie lange dieser gilt und was danach geprüft und auditiert werden muss.
Ops kann nur übernehmen, was sie reproduzieren können. Ein gutes Deployment‑Paket beantwortet drei Fragen einfach: Was genau läuft, wie deployen wir es nochmal, und wie kommen wir schnell zurück, wenn etwas schiefgeht?
Füge eine klare „Stückliste" für den Build bei. Nenne den Artefakt‑Typ und wie man ihn verifiziert, nicht nur wo er liegt:
Füge ein kleines, konkretes Beispiel hinzu. Zum Beispiel: „Deploy v1.8.2 durch Aktualisieren des Image‑Tags, Migrationen ausführen, dann Web‑Worker neu starten. Wenn Healthchecks innerhalb von 10 Minuten fehlschlagen, auf v1.8.1 zurückrollen und den Migrationsjob stoppen.“
Ein Rollback‑Plan sollte sich wie eine Anleitung lesen, der man um 2 Uhr morgens folgen kann. Er sollte festlegen:
Wenn die App mit AppMaster gebaut und als Quellcode für Self‑Hosting exportiert wurde, füge die generierte Code‑Version, Build‑Anweisungen und Laufzeit‑Erwartungen bei, damit Ops dasselbe Release später neu bauen kann.
Eine Übergabe ist nicht abgeschlossen, bis Ops sieht, was die App tut und rechtzeitig gewarnt wird, bevor Nutzer sich beschweren.
Einigt euch darauf, welche Logs existieren müssen und wo sie landen (Datei, Syslog, Log‑Plattform). Stelle sicher, dass Logs zeitlich synchronisiert sind und eine Request‑ oder Korrelations‑ID enthalten, damit Vorfälle nachvollziehbar sind.
Du willst typischerweise Anwendungslogs (wichtige Events und Fehler), Error‑Logs (Stacktraces, fehlgeschlagene Jobs), Access‑Logs (Requests und Statuscodes), Audit‑Logs (Admin‑Aktionen und Exporte) und Infrastruktur‑Logs (Restarts, Node‑Pressure, Festplattenprobleme).
Definiere als Nächstes eine kleine Menge Metriken, die Nutzerwirkung und Systemgesundheit widerspiegeln. Wenn du nur fünf wählst: Latenz (p95/p99), Fehlerquote, Auslastung (CPU/RAM/Disk), Queue‑Tiefe und Verfügbarkeitschecks von außerhalb deines Netzwerks.
Alert‑Regeln sollten eindeutig sein: Was löst aus, Schweregrad (Page vs Ticket), wer ist on‑call und wann eskalieren. Füge einen „bekannt guten" Dashboard‑Snapshot und eine kurze Notiz hinzu, was normal aussieht (typische Latenz, erwartete Fehlerquote, übliche Queue‑Tiefe). Dieser Kontext verhindert laute Alerts und hilft neuen Responders schnell zu handeln.
Backups sind nichts, was man „hat“. Sie müssen wiederherstellbar sein, auf Abruf.
Schreibe den genauen Umfang auf: Datenbank, Dateispeicher (Uploads, Reports, Rechnungen) und Dinge, die oft vergessen werden, wie Konfiguration, die nicht im Code liegt, und die Verschlüsselungsschlüssel zum Lesen geschützter Daten.
Halte Ziele in klaren Begriffen. RPO ist, wie viel Datenverlust akzeptabel ist (z. B. 15 Minuten). RTO ist, wie lange ein Ausfall dauern darf (z. B. 1 Stunde). Wähle Zahlen, die das Geschäft akzeptiert, denn sie bestimmen Kosten und Aufwand.
Füge hinzu:
Wenn du eine AppMaster‑App exportierst und selbst hostest, füge PostgreSQL‑Restore‑Schritte sowie externe Storage‑Buckets und die Schlüssel für verschlüsselte Felder bei.
Plane einen Restore‑Drill. Dokumentiere Zeit, was schiefging und was ihr geändert habt, damit der nächste Restore schneller und weniger stressig wird.
Eine Übergabe ist erst echt, wenn jemand um 2 Uhr nachts gepaged werden kann und das Problem ohne Raten behebt. Runbooks verwandeln Tribal Knowledge in Schritte, denen ein On‑Call folgen kann.
Beginne mit den Vorfällen, die am wahrscheinlichsten sind: Totalausfall, langsame Requests und ein Deploy, das etwas kaputt macht. Halte jedes Runbook kurz. Platziere die schnellsten Checks oben, damit Responders in Minuten Signal bekommen.
Halte die Struktur konsistent, damit es unter Druck schnell zu scannen ist:
Wenn die App aus AppMaster exportiert oder fürs Self‑Hosting bereitgestellt wurde, nenne, wo die generierten Services laufen, wie man sie sicher neu startet und welche Konfig‑Werte pro Umgebung erwartet werden.
Führe eine kurze Post‑Incident‑Checkliste: Timeline, letzte Änderungen, genaue Fehlermeldungen, betroffene Nutzer und was das Problem gelöst hat. Aktualisiere dann das Runbook, solange Details noch frisch sind.
Ops kann ein System nur übernehmen, wenn klar ist, wer was darf und wie Zugriff nachverfolgt wird.
Schreibe die tatsächlich genutzten Rollen auf. Für viele Teams reichen diese:
Dokumentiere die „Tür‑Policy" in klaren Schritten: Wer gewährt Zugriff, wo wird er vergeben (SSO, Cloud‑IAM, DB‑User, CI/CD, Admin‑Panels), wer kann ihn entziehen und wie bestätigt man das bei Offboarding.
Vergiss nicht nicht‑menschliche Zugänge. Liste jeden Service‑Account und Token auf, die von Jobs, Integrationen und Monitoring genutzt werden, mit einer Least‑Privilege‑Notiz (z. B. „darf nur von Bucket X lesen"). Wenn du AppMaster‑Quellcode exportierst, nenne, welche Env‑Vars oder Config‑Dateien diese Identitäten definieren, aber füge niemals geheime Werte in die Übergabedokumentation ein.
Setze auch Audit‑Log‑Erwartungen: was geloggt werden muss (Login, Deploy, Konfig‑Änderung, DB‑Admin‑Aktionen), wer Logs lesen darf, Aufbewahrung, wo Logs gespeichert sind und wie man Logs für einen Vorfall oder Review anfordert.
Sicherheitsnotizen sollten für Nicht‑Spezialisten lesbar sein, aber konkret genug, damit Ops handeln kann. Füge eine einseitige Zusammenfassung bei, die beantwortet: Welche Daten speichern wir, wo liegen sie und wer hat Zugriff?
Beginne mit Datentypen: Kundenprofile, Support‑Tickets, Zahlungs‑Metadaten, Dateien. Hebe sensible Kategorien wie PII (Namen, E‑Mails, Telefonnummern), Zugangsdaten und regulierte Daten hervor. Wenn du Quellcode zum Self‑Hosting exportiert hast (auch aus AppMaster), notiere, wo diese Daten in der Datenbank landen und welche Dienste sie lesen können.
Schreibe Aufbewahrungs‑ und Löschregeln in praktischen Begriffen: Was wird wie lange aufgehoben und wie funktioniert Löschung (Soft Delete vs Hard Delete, verzögerte Löschung, Backups). Wenn es rechtliche Holds oder Audit‑Bedarfe gibt, nenne, wer Ausnahmen genehmigt.
Logs leaken oft mehr als Datenbanken. Sei klar, wo PII erscheinen kann (Access‑Logs, Error‑Logs, Analytics‑Events) und wie du es reduzierst oder maskierst. Wenn ein Feld nie geloggt werden darf, nenne diese Regel explizit.
Halte Genehmigungen eindeutig:
Wenn du nur eine zusätzliche Sache hinzufügen kannst, füge eine Evidenz‑Notiz hinzu: Wo Audit‑Logs liegen und wie man sie exportiert, wenn jemand Nachweise verlangt.
Ops übernimmt ein Kundenportal, das von einem kleinen Produktteam gebaut wurde, und migriert es auf neue Self‑Hosting‑Infrastruktur. Ziel ist nicht nur „es läuft“, sondern „Ops kann es betreiben, ohne die Erbauer anzurufen".
Tag 1: Ops macht einen sauberen Erstdeploy in einer neuen Umgebung nur mit dem Übergabepaket. Die App startet, aber Login schlägt fehl, weil eine Env‑Var für den E‑Mail‑Provider fehlt. Diese wird zum Env‑Template hinzugefügt und der Deploy wird wiederholt, bis alles von Grund auf funktioniert.
Tag 2: Der erste Alert wird absichtlich ausgelöst. Ops verursacht einen kontrollierten Ausfall (einen Service stoppen oder ausgehende E‑Mails blockieren) und bestätigt: Metriken zeigen das Problem, Alerts erreichen den richtigen Kanal und die Nachricht sagt, was als Nächstes zu tun ist.
Tag 3: Ein Token läuft in der Payment‑Sandbox ab. Da der Speicherort und die Rotationsschritte dokumentiert sind, ersetzt Ops es ohne Raten oder Geheimnisverbreitung.
Tag 4: DNS‑Cutover. Ein fehlerhafter Eintrag zeigt auf die alte IP, und das Portal ist für einige Nutzer nicht erreichbar. Ops nutzt das Runbook, um DNS, TLS und Healthchecks in der richtigen Reihenfolge zu prüfen.
Tag 5: Erster Backup‑Restore‑Test. Ops stellt in eine frische Datenbank wieder her und beweist, dass das Portal echte Daten laden kann.
Die App lief 7 Tage ohne mysteriöse Fixes, es gab eine erfolgreiche Wiederherstellung, klare Alerts und einen wiederholbaren Deploy, den Ops alleine durchführen kann.
Der schnellste Weg, eine ruhige Übergabe in einen 2‑Uhr‑Brand zu verwandeln, ist anzunehmen, „wir haben Ops alles gesagt" heißt dasselbe wie „Ops kann es ohne uns betreiben".
Häufige Fehler nach einer Self‑Hosting‑Übergabe sind: Secrets in Tabellen oder Chat geteilt, Rollbacks, die einen Entwickler brauchen, Backups existieren, aber Restores wurden nie getestet, Alerts, die den ganzen Tag feuern weil Thresholds nicht angepasst wurden, und Umgebungsdetails, die nur im Kopf einer Person existieren (Ports, DNS‑Namen, Cron‑Pläne, Cloud‑Permissions).
Beispiel: Du exportierst Quellcode aus AppMaster zum Self‑Hosting und der erste Deploy klappt. Zwei Wochen später bricht eine Konfigänderung Logins. Wenn Secrets per Chat geteilt wurden und das Rollback den ursprünglichen Entwickler braucht, verliert Ops Stunden, nur um wieder zu dem Stand „es hat gestern funktioniert" zurückzukommen.
Bevor du das Ticket schließt, mache ein kurzes Fresh‑Start‑Drill. Gib das Übergabepaket einem Ops‑Engineer und eine saubere Umgebung (neue VM, neuer Kubernetes‑Namespace oder ein neues Cloud‑Projekt). Wenn die Person die App innerhalb einer festgelegten Zeit (z. B. 2 Stunden) deployen, beobachten und wiederherstellen kann, seid ihr nahe dran.
Nutze diese Checks:
Wenn du generierten Quellcode für Self‑Hosting exportierst, bestätige außerdem, dass Ops weiß, wo Build‑Inputs, Versionen und Release‑Tags aufgezeichnet sind, damit künftige Releases reproduzierbar bleiben.
Führe eine finale Durchlaufprobe mit den Personen durch, die den Pager tragen. Betrachte es als Generalprobe. Beweise, dass Deploy, Rollback, Restore und Alerting mit genau dem Paket funktionieren, das du übergibst.
Eine finale Durchlaufprobe umfasst gewöhnlich: Deploy in eine Testumgebung und dann Production mit denselben Schritten, Rollback auf die vorherige Version und Verifikation, Restore aus Backup in eine saubere Umgebung und Validierung einer einfachen Prüfung (Login, Datensatz anlegen, Nachricht senden), eine sichere Test‑Alarmierung und Bestätigung, wo während eines Vorfalls Logs und Dashboards zu finden sind.
Mache Ownership explizit. Benenne einen Owner für jedes Runbook (Deploy, Incident, Restore) und für jede Alert‑Route (primärer On‑Call, Backup, Verhalten außerhalb der Geschäftszeiten). Wenn niemand einen Alert besitzt, wird er entweder ignoriert oder weckt die falsche Person.
Schreibe einen kurzen Day‑2‑Plan, damit Ops weiß, was nach der ersten Woche zu verbessern ist: Thresholds anpassen, Kosten prüfen, alte Artefakte bereinigen und Zugriff überprüfen. Halte es klein und zeitlich begrenzt.
Wenn du mit AppMaster (appmaster.io) gebaut hast, füge den exportierten Quellcode oder die genauen Deployment‑Zieldetails bei (Cloud, Regionen, Build‑Einstellungen, benötigte Services), damit Ops die App reproduzieren kann, ohne auf das ursprüngliche Projekt‑Workspace angewiesen zu sein. Setze einen einfachen Rhythmus, um das Paket bei geänderten Anforderungen zu aktualisieren, damit Runbooks nicht aus der Realität driften.
Was bedeutet „produktionsbereite Übergabe“ konkret?Eine produktionsbereite Übergabe bedeutet, dass Ops eine bekannte Version deployen, ihren Zustand prüfen, auf Alerts reagieren und aus Ausfällen wiederherstellen kann, ohne sich auf das Wissen eines einzelnen Entwicklers zu verlassen. Wenn eine Woche ohne die ursprünglichen Entwickler die Verfügbarkeit gefährdet, ist die Übergabe nicht abgeschlossen.
Was sollte in einer grundlegenden Systemübersicht enthalten sein?Beginne mit einer einseitigen Systemübersicht, die jede laufende Komponente und ihren Standort listet: API, Webapp, Worker, geplante Jobs, Datenbank, Speicher und benötigte Drittanbieterdienste. Füge Domains, Ports, DNS/TLS‑Verantwortliche und grobe erwartete Last hinzu, damit Ops ohne Rätselraten arbeiten kann.
Wie übergibt man Umgebungs‑Konfiguration ohne Geheimnisse zu leaken?Stelle eine einzelne Konfigurationsreferenz bereit, die jeden Konfig‑Schlüssel, seinen Typ und ein sicheres Beispielwert zeigt, sowie die Unterschiede zwischen Dev/Staging/Prod. Lass echte Zugangsdaten weg und dokumentiere, wo Konfiguration gespeichert ist und wie sie beim Deploy angewendet wird, damit Änderungen reproduzierbar sind.
Was ist das Minimum, das wir für Secrets und deren Rotation dokumentieren sollten?Erstelle eine kurze Geheimnisliste, die erklärt, wofür jedes Secret dient, wo es gespeichert ist, wer es lesen kann und wer die Rotation verantwortet. Schreibe Rotationsschritte als Checkliste mit einem klaren Verifikationsschritt und füge einen Break‑Glass‑Prozess für Notfälle mit Audit‑Erwartungen hinzu.
Was macht ein Deployment‑Paket für Ops „reproduzierbar"?Ops muss genau wissen, was läuft und wie man es reproduziert: Artefaktname/Tag, Version, Build‑Datum, Checksumme und die Quellenreferenz. Füge das empfohlene Ziel (VM, Container, Kubernetes), die Deploy‑Reihenfolge, erwartete Dauer und wie Datenbankmigrationen ausgeführt und verifiziert werden, hinzu.
Was sollte ein Rollback‑Plan enthalten, damit er um 2 Uhr morgens nutzbar ist?Definiere die Auslöse‑Signale (z. B. fehlgeschlagene Healthchecks oder erhöhte Fehlerquote), die zuletzt funktionierende Version und die exakten Schritte zum schnellen Zurückrollen. Beschreibe, ob Datenbankänderungen umkehrbar sind und welche sichere Alternative gilt, falls nicht, damit Rollbacks keine Improvisation werden.
Welche Monitoring‑Signale sollten wir bei der Übergabe priorisieren?Wähle eine kleine Menge Metriken, die Nutzererfahrung und Systemgesundheit widerspiegeln: Latenz (p95/p99), Fehlerquote, Auslastung (CPU/RAM/Disk), Queue‑Tiefe und externe Verfügbarkeitschecks. Mache Alerts eindeutig: Auslöser, Schweregrad, wer paged wird, und was „normal“ bedeutet. Sorge dafür, dass Logs zeit‑synchronisiert sind und Korrelation‑IDs enthalten.
Wie machen wir Backups und Restores wirklich zuverlässig?Dokumentiere, was gesichert wird, wo die Backups liegen, deren Aufbewahrung und wer Wiederherstellungen durchführen darf. Lege eine Schritt‑für‑Schritt‑Wiederherstellungsprozedur mit Verifikation fest und plane regelmäßige Restore‑Drills; Backups zählen nur, wenn eine Wiederherstellung auf Abruf in einer sauberen Umgebung funktioniert.
Wie sollte ein On‑Call‑Runbook für typische Vorfälle aussehen?Halte Runbooks kurz und einheitlich: Symptome, erste Checks, nächste Checks, Entscheidungspunkte und Eskalation. Konzentriere dich auf wahrscheinliche Vorfälle (Ausfall, Verlangsamung, fehlerhaftes Deploy) und aktualisiere das Runbook direkt nach einem Vorfall, solange Details noch frisch sind.
Wie dokumentieren wir Zugriffskontrolle und Berechtigungen für Ops‑Ownership?Schreibe die tatsächlich verwendeten Rollen auf (Deployer, DB‑Admin, Read‑Only, Incident Commander), wie Zugriff gewährt und entzogen wird, und welche Aktionen auditiert werden müssen. Vergiss nicht nicht‑menschliche Zugänge: liste Service‑Accounts und Tokens auf, ihre eingeschränkten Rechte und wo ihre Identität konfiguriert ist, ohne geheime Werte einzufügen.
10. März 2026
11 Min
08. März 202611 Min
07. März 20267 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
