Erfahrungen sprechen für sich
Zertifikate zeigen, was man gelernt hat. Erfahrungen zeigen, was man tatsächlich tut. Ein ehrlicher Blick auf das, was mich als Application Manager geformt hat.
Was Zertifikate nicht zeigen
Ich habe Kurse besucht, Dokumentationen gelesen, Konzepte verstanden. Aber die wichtigsten Dinge, die ich im Application Management gelernt habe, kamen nicht aus Schulungen. Sie kamen aus Situationen, die nicht im Lehrbuch standen.
Dieser Post ist kein Lebenslauf. Er ist ein Blick hinter die Kulissen — auf die Momente, die mich wirklich weitergebracht haben.
Der erste echte Incident
Ich erinnere mich an einen Abend, an dem eine produktiv genutzte Applikation still wurde. Kein Alarm hatte ausgelöst — weil das Monitoring nicht korrekt konfiguriert war. Der erste Anruf kam vom Fachbereich.
Was ich dabei gelernt habe: Monitoring ist keine Checkbox. Es muss getestet werden, wie man auch den Code testet. Und: Ein Incident, den du selbst entdeckst, ist besser als einer, den dein Nutzer entdeckt.
Der Change, der zu einem Rollback wurde
Ein Software-Update, gut getestet in der Testumgebung, hat in Produktion ein Verhalten gezeigt, das wir nicht vorhergesehen hatten. Der Go-Live musste rückgängig gemacht werden.
Was ich dabei gelernt habe: Testumgebungen sind nie perfekt. Der Unterschied zwischen Test und Prod liegt oft in Details — Datenmenge, Konfiguration, Netzwerk-Timeouts. Seitdem achte ich darauf, dass jeder Change einen definierten Rollback-Punkt hat — und dass ich ihn auch wirklich ausführen kann, bevor ich go-live gehe.
Das Gespräch, das ich nicht erwartet hatte
Ein Stakeholder rief an und fragte, warum er von einem Vorfall erst durch einen Kollegen erfahren hatte — nicht von mir. Die Applikation lief wieder. Der Schaden war minimiert. Aber das Vertrauen war beschädigt.
Was ich dabei gelernt habe: Technische Exzellenz allein reicht nicht. Kommunikation ist ein Teil des Jobs. Wer einen Incident hat, muss auch kommunizieren — nicht nur lösen. Seitdem ist Transparenz für mich keine Option, sondern Standard.
Die Aufgabe, die eigentlich keine war
Ich bekam einmal einen Auftrag: "Schau dir mal an, warum das System ab und zu langsam wird." Kein Ticket, keine SLA, keine Dringlichkeit.
Was ich fand, war ein Connection-Pool, der unter Last erschöpfte. Ein Problem, das jahrelang als "so ist es halt" akzeptiert worden war.
Was ich dabei gelernt habe: Manchmal ist der wichtigste Beitrag nicht die Lösung eines bekannten Problems — sondern das Sichtbarmachen eines Problems, das niemand als Problem bezeichnet hat.
Warum Erfahrung zählt
Ich bin kein Experte, weil ich viele Kurse gemacht habe. Ich bin ein besserer Application Manager, weil ich Fehler gemacht, gelernt und angepasst habe.
Die Erfahrungen oben klingen klein. Aber sie haben mein Bild von Application Management mehr geprägt als jedes Framework.
Was zählt, ist nicht, dass du nie Fehler machst. Es zählt, was du danach tust.