Ein zusätzlicher Gesprächspartner im technischen Alltag
Wir betreuen kleine KMU. Die Aufgaben reichen von einer gestörten Mailzustellung bis zur Frage, wie sich Monitoring, Sicherungen und neue Anwendungen mit begrenzten Mitteln sinnvoll betreiben lassen. In den letzten Tagen habe ich begonnen, diese Arbeit zusammen mit einem KI-Assistenten in Visual Studio Code systematischer anzugehen und zu dokumentieren.
Dabei bringe ich die Umgebung, die Anforderungen und die Beobachtungen aus dem Betrieb ein. Der Assistent hilft, Informationen zu ordnen, Erklärungen zu prüfen und konkrete nächste Schritte vorzubereiten. Daraus entsteht ein Austausch: Ich liefere eine Ausgabe oder einen Screenshot, wir bewerten den Befund und entscheiden, was als Nächstes geprüft oder geändert wird.
Erst verstehen, dann verändern
Ein Ausgangspunkt ist die Frage, was tatsächlich bekannt ist. Welche Systeme sind betroffen? Was wurde bereits verändert? Was steht in unserer Dokumentation? Und welche Vermutung klingt nur plausibel, ohne schon belegt zu sein?
Gerade die bestehende Dokumentation ist dabei wichtig. Ich möchte nicht bei jeder neuen Frage die gesamte Umgebung erneut erklären. Wenn eine vorgeschlagene Lösung nicht zu unserem bisherigen Vorgehen passt, hake ich nach. So haben wir beispielsweise für die Linux-Arbeiten auf die dokumentierten persönlichen Benutzerkonten mit anschliessendem sudo zurückgegriffen.
Auch Vorschläge des Assistenten brauchen diesen Abgleich. Eine Antwort wird nicht allein deshalb richtig, weil sie überzeugend formuliert ist. Meine Rückfragen, Korrekturen und die tatsächlichen Ausgaben gehören zum Arbeitsprozess.
Kleine Schritte machen Ergebnisse überprüfbar
Bei der Graylog-Anbindung hatten beide Linux-Hosts einen erfolgreichen TLS-Vorabtest geliefert. Trotzdem kam zunächst nur von einem Host die Testmeldung an. Statt die Einrichtung als erledigt abzulegen, haben wir den fehlenden Empfang zum nächsten Prüfpunkt gemacht.
Die lokale Diagnose zeigte einen Fehler im verwendeten TLS-Treiber. Nach einem gezielten Wechsel kam die markierte Nachricht auch vom zweiten Host an. Die genaue Ursache innerhalb der ursprünglichen Bibliothekskombination blieb offen. Entscheidend für die Abnahme war die sichtbare Nachricht am Ziel, nicht nur ein laufender Dienst oder eine erfolgreiche Vorprüfung.
Dieses Vorgehen zieht sich durch die Zusammenarbeit: einen überschaubaren Schritt vorbereiten, sein Ergebnis prüfen und erst danach weitergehen. Bei umfangreichen Terminalausgaben speichern wir die Ergebnisse in Dateien, damit die Bewertung nicht am abgeschnittenen Konsolenpuffer scheitert.
Änderungen zunächst als Pilot umsetzen
Bei Checkmk fiel durch die zentralen Logs auf, dass ein Plugin vergeblich einen Agenten innerhalb von Anwendungscontainern starten wollte. Wir haben die betroffene Funktion anhand des abgelegten Codes eingegrenzt und zunächst auf einem Linux-Host gezielt abgeschaltet.
Zum vorbereiteten Skript gehörten eine Sicherung und ein Vorher-/Nachher-Vergleich. Die bisherigen Monitoring-Ziele und Datensektionen mussten erhalten bleiben. Anschliessend habe ich die Journalmeldungen und weiterlaufende Messwerte kontrolliert. Erst nach dieser Stichprobe folgte derselbe Schritt auf dem zweiten Host.
Der Assistent hat dafür Skripte und Prüfschritte vorbereitet; die Serverbefehle habe ich über meine Zugänge ausgeführt und die Ergebnisse zurückgegeben. Das ist eine wichtige Unterscheidung: Ein vorbereitetes Skript ist noch keine ausgeführte Änderung, und eine ausgeführte Änderung ist noch kein abgenommenes Ergebnis.
Auch neue Ideen brauchen einen konkreten Rahmen
Die Zusammenarbeit dreht sich nicht nur um Störungen. Wir besprechen ebenso neue Werkzeuge und Verbesserungen: Welche Aufgabe lösen sie? Was kosten Anschaffung und Betrieb? Können wir sie in unserer Umgebung sinnvoll betreuen? Was lässt sich zunächst klein erproben?
UrBackup ist dafür ein Beispiel. Der Pilot begann mit einem einzelnen Windows-Rechner und einem klar abgegrenzten Sicherungsumfang. Das erste Vollimage gelang. Folge- und Wiederherstellungstests blieben als nächste Nachweise dokumentiert. Eine neue Idee wird so zu einem konkreten Versuch, ohne schon als fertige Lösung für alle Kunden zu gelten.
Auch dieser Blog ist auf diesem Weg entstanden: erst der Wunsch, Erfahrungen zu teilen, dann die lokale Vorschau und schliesslich die geprüfte Veröffentlichung. Ein vorbereiteter Entwurf und eine öffentlich erreichbare Website sind unterschiedliche Projektstände.
Dokumentieren, was wir wirklich erreicht haben
Die neue Dokumentation verbindet die einzelnen Arbeitsschritte. Sie hält fest, welche Änderung vorgenommen wurde, welcher Test erfolgreich war und wo wir bewusst aufgehört haben. Beim Outlook-Vorfall konnten wir den Betrieb wiederherstellen, ohne den ursprünglichen Auslöser eindeutig zu bestimmen. Genau so ist das Ergebnis festgehalten.
Aus den internen Unterlagen bereiten wir nun öffentliche Erfahrungsberichte auf. Hier stehen Ziele, Erkenntnisse und Ergebnisse im Vordergrund; interne Adressen und ausführliche Konfigurationsdetails bleiben in der Betriebsdokumentation.
Für mich liegt der Nutzen der Zusammenarbeit in dieser Verbindung: Ideen schneller konkret machen, Befunde gemeinsam hinterfragen und den nächsten Schritt nachvollziehbar vorbereiten. Die Verantwortung für Entscheidungen im Betrieb bleibt bei mir. Ob eine Lösung passt, zeigen unsere Prüfungen und die anschliessende Erfahrung im Alltag.