Leistung · Soforthilfe
Es muss wieder laufen. Jetzt.
Produktion steht, Kunden warten, und der Einzige, der das System kannte, ist nicht mehr erreichbar. Ich kenne diesen Moment und weiss, was er auslöst. Deshalb gilt beim Notfall-Eingriff: zuerst stabilisieren, dann aufräumen, dann dokumentieren.
Typische Fälle
Damit kannst du kommen.
Das Schlimmste am Ausfall ist selten die Technik. Es ist das Gefühl der Ohnmacht: Alle schauen auf dich, und niemand weiss, wo anfangen. Dabei solltest du nicht für den Ausfall eines Dienstleisters oder einer müden Altlast geradestehen müssen.
- Produktion steht nach einem Update oder Deployment.
- Der Shop nimmt keine Bestellungen mehr an oder rechnet falsch.
- Sicherheitsvorfall: verdächtige Zugriffe, Spam-Versand, defacte Seiten.
- Die Agentur oder der Entwickler ist weg, der Code ohne Dokumentation.
- Performance bricht unter Last ein, Kunden springen ab.
- Update-Stau: Nichts lässt sich mehr aktualisieren, ohne dass etwas bricht.
Der Plan
Drei Schritte, bis wieder Ruhe ist.
Über 20 Jahre PHP heisst: Die meisten Fehlerbilder habe ich schon gesehen. Panik ist keine Strategie, ein klarer Ablauf schon.
Notfall melden
Mail mit Betreff «Notfall»: Was ist passiert, seit wann, was wurde versucht. Du bekommst schnellstmöglich eine ehrliche Ersteinschätzung.
Stabilisieren lassen
Zuerst muss es wieder laufen. Hotfix, Rollback oder Workaround: was den Betrieb am schnellsten und sichersten zurückbringt.
Mit Plan weitermachen
Ich behebe die Ursache statt nur das Symptom und du bekommst einen Zustandsbericht: was passiert ist, was getan wurde, was als Nächstes ansteht.
Jede Stunde Stillstand kostet Umsatz und Vertrauen. Warte nicht darauf, dass es sich von selbst löst: Das tut es nicht.
Danach
Vom Notfall zur stabilen Basis.
Der Betrieb läuft wieder, du weisst, was passiert ist, und die kritischen Stellen sind abgesichert. Wenn du willst, geht es danach weiter: Update-Stau abbauen, Monitoring einrichten oder gleich die Migration auf eine neue Basis planen. Ohne Zwang: Der Zustandsbericht gehört dir, auch wenn danach jemand anderes weitermacht.
Ehrlich gesagt
Solo heisst echte Kapazitätsgrenze. Notfälle haben Vorrang, aber ich nehme nur an, was ich seriös stemmen kann. Wenn ich nicht der Richtige bin, sage ich es dir im ersten Austausch, nicht nach der ersten Rechnung.
FAQ
Häufige Fragen zum Notfall-Eingriff.
Wie schnell bekomme ich im Notfall eine Antwort?
In der Regel am selben Arbeitstag. Notfälle werden vor allem anderen priorisiert: Schreib eine Mail mit Betreff «Notfall» und einer kurzen Beschreibung, dann bekommst du schnellstmöglich eine ehrliche Ersteinschätzung.
Was brauchst du von mir für die erste Einschätzung?
Drei Angaben: Was ist passiert, seit wann, was wurde schon versucht. Zugänge zu Server, Code und Datenbank brauche ich erst für den eigentlichen Eingriff, nicht für die Ersteinschätzung.
Der bisherige Entwickler ist weg und nichts ist dokumentiert. Geht das trotzdem?
Ja, das ist der häufigste Fall. Zugriff auf Code und Datenbank reicht: Die Bestandsaufnahme bringt an den Tag, was verbaut wurde. Nach dem Eingriff bekommst du einen Zustandsbericht, der genau das dokumentiert.
Behebst du nur das Symptom oder auch die Ursache?
Beides, in dieser Reihenfolge: Zuerst wird der Betrieb stabilisiert, mit Hotfix, Rollback oder Workaround. Danach wird die Wurzel des Problems behoben und abgesichert, damit es nicht wieder passiert. Den Abschluss bildet der Zustandsbericht mit Prioritäten.
Was kostet ein Notfall-Eingriff?
Nach der kostenlosen Ersteinschätzung bekommst du einen klaren Rahmen für die Stabilisierung als überschaubare erste Etappe. Und wenn ich nicht der Richtige für deinen Fall bin, sage ich es dir im ersten Austausch, nicht nach der ersten Rechnung.
Übernimmst du nach dem Notfall auch die weitere Betreuung?
Wenn du willst, ja: Update-Stau abbauen, Monitoring einrichten oder die Migration auf eine neue Basis planen. Ohne Zwang: Der Zustandsbericht gehört dir, auch wenn danach jemand anderes weitermacht.
Aus der Praxis
Stabilität aus der Praxis.
High-Performance-Optimierung von Multi-Tenant E-Commerce-Plattformen mit Varnish Cache
Multi-Tenant E-Commerce-Plattform mit Varnish Cache beschleunigt: Edge Side Includes, Cache-Tags, Blue-Green-Deployment mit Preheating und Rate Limiting.
PatchPub: Zentrale Verwaltung und Anwendung von Composer-Patches für PHP-Projekte
Laravel-Plattform für zentrale Composer-Patches: Regex- und Diff-Patching, GitHub-PR-Import, git-diff-Vorschau und automatische Prüfung neuer Paket-Versionen.
Datenschnittstelle vom ERP zu Shopify mit Datenkonvertierung, Bereinigung und Fallbacks
Aufbau eines Datenaustauschs zwischen einem ERP-System und Shopify für die automatisierte Synchronisation der Produktdaten.
Verantwortlich: Dimitri König, Gründer der Unique-P GmbH · 20+ Jahre PHP, TYPO3 und Laravel