Der Entwickler ist krank und die Produktion steht: Notfall-Unterstützung für kleine Unternehmen

Ihr einziger Entwickler liegt mit Grippe im Bett, und die App, die Ihre Kunden jeden Tag nutzen, hat gerade aufgehört zu funktionieren. In diesem Moment merken viele kleine Unternehmen, wie abhängig sie von einer einzigen Person sind. Notfall-Entwicklerunterstützung existiert genau für diese Situation: Ein Live-System ist kaputt, niemand im verbleibenden Team kann den Code gefahrlos anfassen, und jede Stunde Ausfall kostet Kunden, Umsatz oder beides.

Das ist kein seltener Fall. Die meisten Unternehmen mit weniger als fünfzig Mitarbeitenden betreiben ihr gesamtes Produkt mit einem oder zwei Entwicklern, manchmal einem Gründer, der früher selbst programmiert hat und seit Jahren nicht mehr im Code war. Ist diese Person nicht verfügbar, sei es durch Krankheit, eine plötzliche Kündigung oder einfach einen Flug ohne Empfang, gibt es oft keinen Plan B. Der Server läuft weiter. Niemand weiß, wie man sich dort einloggt.

Was in den ersten Stunden wirklich zum Problem wird

Das erste Problem ist selten der Fehler selbst. Es ist, dass niemand weiß, wo er anfangen soll. Ein kleines Unternehmen mit einem Entwickler hat meist kein Runbook, keinen dokumentierten Deployment-Prozess und keine zweite Person mit Produktionszugriff. Die Person, die das normalerweise in zwanzig Minuten lösen könnte, ist dieselbe Person, die nicht erreichbar ist.

Kunden merken es schnell, wenn das Produkt kundenseitig genutzt wird, etwa ein SaaS-Tool, ein Onlineshop oder ein Buchungssystem. Support-Tickets stapeln sich. Jemand im Team nimmt verärgerte Anrufe entgegen, ohne eine Ahnung zu haben, was wirklich nicht funktioniert, weil er die Codebasis nie gesehen hat und keine Zugangsdaten für den Hosting-Anbieter, die Datenbank oder das Fehler-Tracking-Tool besitzt.

Gleichzeitig verschlimmern gut gemeinte Eingriffe die Lage manchmal noch. Ein nicht-technisches Teammitglied startet einen Server neu, weil es naheliegend schien, was einen Cache im Arbeitsspeicher löscht und einen zweiten, bisher unbemerkten Fehler sichtbar macht. Jemand versucht, ein Deployment über ein Dashboard zurückzurollen, das er nicht versteht, und sperrt dabei den Account. Niemand trägt daran Schuld. Es passiert einfach, wenn ein Team keinen Incident-Prozess hat, weil es nie damit gerechnet hat, einen zu brauchen.

Wer realistisch jetzt helfen kann

Wenn Sie nach Notfall-Entwicklerunterstützung suchen, finden Sie drei grundsätzliche Optionen, und sie sind nicht austauschbar.

Ein Freelance-Entwickler, der Ihren Stack schon kennt, ist der schnellste Weg, falls einer existiert, aber die meisten kleinen Unternehmen haben keinen Freelancer in Reserve, und einen völlig Fremden mitten in einem akuten Ausfall zu finden, ist langsam und riskant. Sie prüfen die Fähigkeiten einer Person unter Druck, und genau dann sind Sie am schlechtesten in der Lage, sie richtig einzuschätzen.

Eine Entwicklungsagentur oder Beratung, die Notfall- oder Bereitschaftsarbeit anbietet, kann meist schneller reagieren als ein Solo-Freelancer, den Sie zum ersten Mal treffen, weil mehrere Entwickler zur Verfügung stehen und der Vorfall an jemanden mit passender Erfahrung gehen kann, egal ob Symfony, Next.js, Laravel oder was auch immer Ihr Stack ist. Der Nachteil: Das kostet pro Stunde mehr, und die Qualität schwankt zwischen Anbietern immer noch stark.

Das Support-Team Ihres Hosting-Anbieters lohnt einen ersten Blick, wenn das Problem eher Infrastruktur als Code sein könnte. Ein erreichtes Datenbank-Verbindungslimit, eine falsch konfigurierte Umgebungsvariable oder ein ausgelasteter Server können von außen genauso aussehen wie ein Anwendungsfehler, und der Hosting-Support kann das manchmal lösen, ohne dass jemand Ihren Code überhaupt anfasst.

Ehrlich gesagt brauchen Sie jemanden, der innerhalb einer Stunde produktiv ist, nicht jemanden, der Ihre Codebasis von null lernt, während Ihre Kunden warten. Das ist das eigentliche Auswahlkriterium, wichtiger als Preis oder Unternehmensgröße.

Welchen Zugriff jemand braucht, bevor er überhaupt etwas tun kann

Genau hier geraten die meisten Notfälle ins Stocken. Ein fähiger Entwickler kann innerhalb von fünfzehn Minuten am Telefon sein und trotzdem eine Stunde verlieren, weil er auf Zugangsdaten wartet.

Wer auch immer hilft, braucht mindestens Zugriff auf die Hosting-Umgebung oder den Server, das Code-Repository, das Fehler-Tracking- oder Logging-Tool, falls vorhanden, und die Datenbank, zu Beginn mindestens Lesezugriff. Wenn Ihre Produktionsumgebung Secrets oder API-Schlüssel außerhalb des Codes speichert, etwa Zahlungsanbieter-Schlüssel oder Tokens für Drittanbieterdienste, braucht die Person auch diese, sonst debuggt sie im Blindflug.

Wenn Sie nicht wissen, wer aktuell Admin-Rechte für diese Systeme hat, lohnt es sich, das noch heute zu klären, ob gerade ein Vorfall läuft oder nicht. Überraschend viele kleine Unternehmen stellen erst während eines Ausfalls fest, dass der einzige Account mit vollem Zugriff jemandem gehörte, der das Unternehmen vor acht Monaten verlassen hat.

Unsere Arbeit zur Legacy-Code-Optimierung beginnt oft genau hier, bei einem Unternehmen, das einen Notfall überstanden hat und sicherstellen will, dass der nächste nicht sechs Stunden statt einer dauert.

Den Vorfall überstehen, ohne ihn schlimmer zu machen

Sobald jemand Fähiges sich das Problem ansieht, halten ein paar Gewohnheiten einen schlechten Tag davon ab, noch schlechter zu werden.

Schreiben Sie mit, was passiert, während es passiert. Ein einfaches gemeinsames Dokument mit Zeitstempeln, was versucht wurde und was sich geändert hat, reicht aus. Das verhindert, dass zwei Personen sich gegenseitig die Korrekturen zunichtemachen, und gibt jedem, der später dazukommt, das vollständige Bild statt einer mündlichen Zusammenfassung, die schon die Hälfte der Details verloren hat.

Widerstehen Sie dem Drang, eine schnelle Korrektur direkt in die Produktion zu bringen, ohne eine Möglichkeit, sie rückgängig zu machen. Fragen Sie auch unter Druck, ob sich die Änderung in dreißig Sekunden zurücknehmen lässt, falls sie nicht funktioniert. Eine Korrektur, die sich nicht zurückrollen lässt, ist ein zweiter Ausfall, der nur auf seinen Moment wartet.

Kommunizieren Sie ehrlich und früh mit Ihren Kunden, statt bis zur Lösung zu schweigen. Ein kurzes Status-Update, auch nur „wir wissen davon und arbeiten daran", senkt das Support-Aufkommen stärker, als man erwarten würde, weil der meiste Ärger aus Unsicherheit entsteht, nicht aus dem Ausfall selbst.

Halten Sie die erkrankte Person außen vor, außer es ist wirklich unvermeidbar. Der ganze Sinn von Notfall-Unterstützung ist, dass Ihr Team nicht zwischen der Gesundheit einer Person und dem Online-Bleiben des Geschäfts wählen muss.

Danach: Wie Sie denselben Notfall nicht zweimal erleben

Sobald das System wieder läuft, ist die Versuchung groß, den Laptop zuzuklappen und weiterzumachen. Genau das sollten Sie nicht tun, denn die Bedingungen, die zu diesem Ausfall geführt haben, bestehen weiterhin.

Beginnen Sie beim Zugriff. Stellen Sie sicher, dass mindestens zwei Personen, idealerweise auch jemand außerhalb der täglichen Entwicklung, in Hosting, Repository und kritische Drittanbieter-Accounts gelangen, ohne auf das Telefon einer einzelnen Person zu warten. Ein Passwort-Manager mit gemeinsamen Tresoren erledigt das meiste davon an einem Nachmittag.

Schauen Sie sich dann an, was wirklich kaputtgegangen ist. War es ein Fehler, der durch eine jüngste Änderung eingeführt wurde, ist das oft ein Zeichen für dünne Testabdeckung oder eine fehlende Staging-Umgebung, die Probleme abfangen würde, bevor sie Kunden erreichen. Hatte es gar nichts mit Code zu tun, etwa ein Server, dem der Speicherplatz ausging, ist das eine Monitoring-Lücke, und Alarme, die das einen Tag früher erkannt hätten, sind meist günstig einzurichten.

Eine kurze Code-Quality-Beratung nach einem solchen Vorfall rechnet sich meist schnell. Es ist deutlich leichter, ein paar Stunden Review direkt nach einem Schreckmoment zu rechtfertigen, als jemanden davon zu überzeugen, das an einem normalen Dienstag zu priorisieren.

Entscheiden Sie schließlich schon jetzt, wen Sie anrufen würden, falls das wieder passiert, statt es ein zweites Mal unter Druck herauszufinden. Selbst eine informelle Vereinbarung oder ein bekannter Ansprechpartner verkürzt Ihre Reaktionszeit von Stunden auf Minuten.

Wenn Sie eine zweite Meinung zu Ihrem aktuellen Setup möchten, oder Sie etwas Ähnliches kürzlich erlebt haben und sicherstellen wollen, dass es sich nicht wiederholt, schreiben Sie an hello@wolf-tech.io oder besuchen Sie wolf-tech.io. Wir arbeiten mit kleinen Teams genau an dieser Art von Lücke, von Notfall-Korrekturen bis dahin, dass es kein nächstes Mal gibt.