"Und wenn dann im Betrieb mal was nicht funktioniert?" Die Frage kommt meistens kurz vor dem Start, und sie ist berechtigt. Die ehrliche Antwort darauf gefällt vielen nicht: Es wird irgendwann etwas nicht funktionieren. Jede Software, die wirklich benutzt wird, hat Fehler. Die Frage ist nicht, ob, sondern wie schnell du es merkst und wie schnell jemand dran ist.
Niemand verspricht gern, dass etwas kaputtgehen kann. Es klingt nach schlechter Arbeit, und du bezahlst ja genau dafür, dass es läuft. Trotzdem ist "fehlerfrei" kein Zustand, den es gibt, sondern ein Versprechen, das man nur brechen kann. Wer dir Software ohne Fehler zusichert, hat entweder noch keine echte im Betrieb gehabt oder sagt dir nicht die Wahrheit. Reden wir lieber darüber, was tatsächlich zählt.
Fehlerfrei gibt es nicht
Software läuft nicht im luftleeren Raum. Sie hängt an einem Server, an einer Datenbank, an Diensten von Dritten, an einem Browser, den gestern noch jemand aktualisiert hat. Dazu kommen Nutzer, die Dinge eingeben, mit denen niemand gerechnet hat. Je mehr davon zusammenspielt, desto mehr Stellen gibt es, an denen mal etwas hakt.
Das heisst nicht, dass man schludrig baut. Wir testen, bevor etwas live geht, und zwar gründlich. Warum diese Tests einen grossen Teil der Fehler abfangen, bevor du sie je siehst, steht in Woher weisst du, dass es funktioniert?. Aber Tests prüfen, woran man gedacht hat. Der Betrieb ist der Ort, an dem das auftaucht, woran niemand gedacht hat. Beides gehört zusammen, und keins ersetzt das andere.
"Fehlerfrei" ist kein Qualitätsmerkmal, sondern ein Marketingversprechen. Die Qualität zeigt sich nicht daran, dass nie etwas passiert, sondern daran, was passiert, wenn doch.
Die eigentliche Frage ist nicht ob, sondern wie schnell
Wenn Fehler zum Betrieb dazugehören, dann entscheidet nicht ihre blosse Existenz über die Qualität deiner Software, sondern zwei Zeiten. Wie lange dauert es, bis jemand merkt, dass etwas nicht stimmt. Und wie lange dauert es dann, bis es behoben ist.
Diese zwei Zeiten machen den ganzen Unterschied. Ein Fehler, der um 2 Uhr nachts auftritt, um 2:01 Uhr gemeldet wird und bis 8 Uhr morgens behoben ist, bevor der erste Kunde ihn überhaupt bemerkt, ist ein Nicht-Ereignis. Derselbe Fehler, der drei Tage lang still Bestellungen verschluckt, bis sich jemand wundert, warum der Umsatz eingebrochen ist, ist eine Katastrophe. Technisch ist es derselbe Fehler. Was ihn teuer oder harmlos macht, ist allein, wie früh er sichtbar wird.
Merkst du es, oder ruft der Kunde an?
Hier trennt sich ein durchdachter Betrieb von einem, der auf gut Glück läuft. Die Frage ist einfach: Woher erfährst du, dass etwas kaputt ist? Wenn die Antwort "ein Kunde schreibt eine verärgerte Mail" lautet, hast du kein Frühwarnsystem, sondern den spätestmöglichen und teuersten Weg. Bis der Kunde schreibt, haben zehn andere es schon erlebt und nichts gesagt. Sie sind einfach gegangen.
Du starrst nicht den ganzen Tag auf den Fluss. Der Pegel tut es für dich
Niemand kann rund um die Uhr auf eine Software schauen. Deshalb bauen wir ihr etwas ein, das genau das tut. Die Software meldet selbst, wenn etwas aus dem normalen Bereich läuft, wenn Fehler sich häufen, wenn etwas langsamer wird oder ganz stehenbleibt. Wie ein Pegel an der Aare, der nicht wartet, bis jemand im Wasser steht, sondern anschlägt, wenn der Stand steigt. Das Ziel ist, dass wir es wissen, bevor du den Anruf bekommst.
Das nennt sich Monitoring, und es ist kein Luxus für Konzerne. Es ist der Unterschied zwischen "wir sind schon dran" und "oh, davon höre ich zum ersten Mal". Für ein KMU muss das nicht aufwendig sein. Ein paar richtig gesetzte Alarme auf die Dinge, die wirklich wehtun, decken den Grossteil ab.
Was dann passiert
Ein Alarm allein hilft noch niemandem, wenn danach nichts Geordnetes folgt. Wenn bei uns etwas anschlägt, läuft kein Feuerwehreinsatz mit Panik, sondern ein ruhiger Ablauf. Erst schauen wir, wie schlimm es ist: Steht alles still, oder ist es eine Ecke, die kaum jemand nutzt? Danach richtet sich, ob wir sofort ran müssen oder ob es bis morgen Zeit hat. Dann stabilisieren wir, oft erst mit einem schnellen Pflaster, das die Blutung stoppt, und danach mit der sauberen Lösung.
Und zum Schluss kommt der Teil, den die meisten überspringen: Wir schauen, warum der Fehler durchgerutscht ist, und sorgen dafür, dass genau dieser nicht ein zweites Mal passiert. Ein Fehler, aus dem man lernt, macht die Software ein Stück robuster. Ein Fehler, den man nur wegklickt, kommt wieder. Dass diese laufende Arbeit kein Extra ist, sondern zum Betrieb gehört, haben wir in Software ist nie fertig beschrieben.
Was das für dich heisst
Du musst das alles nicht selbst verstehen oder bedienen. Aber du solltest wissen, dass es existiert, denn genau hier entscheidet sich, ob dich ein Fehler eine ruhige Stunde kostet oder einen schlechten Tag mit wütenden Kunden. Es lohnt sich, vor dem Start eine einzige Frage zu stellen und auf eine konkrete Antwort zu bestehen.
Die Frage, die du stellen solltest
Nicht "kann garantiert nichts passieren", die Antwort darauf ist immer ein ehrliches Nein. Sondern: "Woher erfahrt ihr, dass etwas kaputt ist, und wie schnell seid ihr dann dran?" Wer darauf eine klare Antwort hat, Monitoring, eine Erreichbarkeit, einen geübten Ablauf, der denkt an den Tag nach dem Launch, nicht nur an den Launch.
Das ist dieselbe Haltung wie bei der Sicherheit: Nicht die Jagd nach dem unmöglichen Nullrisiko, sondern schnell wieder auf den Beinen sein, wenn etwas passiert. Wir haben das in Ist das sicher? ausführlicher aufgeschrieben. Software, die läuft, ist nicht die, bei der nie etwas schiefgeht. Es ist die, bei der jemand merkt und reagiert, bevor du es überhaupt mitbekommst.
Du willst wissen, wie dein Projekt im Betrieb aufgestellt wäre, nicht nur am Launch-Tag? Erzähl uns davon, wir schauen ehrlich hin.
Marco
Co-Founder & Lead Engineer · FlowCode Bern. Schreibt über das, was beim Bauen wirklich passiert.
