Nicht jedes Problem braucht das teuerste Werkzeug
Wir betreuen kleine KMU. Dort sind die finanziellen Mittel begrenzt, und die Kosten einer IT-Lösung sind ein entscheidender Faktor. Unser Ziel ist, diesen Unternehmen sichere und verlässlich betreibbare Lösungen zu bieten, die preiswert bleiben. Dazu gehören sowohl die Anschaffung als auch laufende Lizenzkosten, Wartung und Betreuung.
Im IT-Alltag zählt für mich deshalb, ob eine Lösung eine konkrete Aufgabe zuverlässig erfüllt und sich mit vertretbarem Aufwand betreiben lässt. In unserer Umgebung ist daraus ein Mix entstanden: Open-Source-Projekte, selbst betriebene Dienste und kommerzielle Angebote mit einem günstigen oder kostenlosen Einstieg. Daneben bleiben bestehende Microsoft- und andere kommerzielle Produkte Teil der Infrastruktur.
Ich habe neu begonnen, diese Umgebung und die Arbeit daran systematisch zu dokumentieren. Die bisher internen Informationen bereiten wir nun für einen öffentlichen Blog auf. Die Beiträge tragen das Datum dieser Aufbereitung, auch wenn die beschriebenen Arbeiten bereits zuvor stattgefunden haben. Was wollten wir erreichen? Was hat funktioniert? Was ist noch offen? Der Software-Mix ist ein guter Ausgangspunkt, weil die einzelnen Werkzeuge erst im Zusammenspiel ihren Nutzen zeigen.
Open Source übernimmt konkrete Aufgaben
Für Zustände und Messwerte setzen wir Checkmk Community ein. Die Community-Ausgabe ist frei und Open Source. In unserer Umgebung beobachtet sie unter anderem Server und Docker-Container. Die Erfahrung zeigt aber auch, dass selbst ein gut funktionierendes Monitoring Aufmerksamkeit braucht: Prüfintervalle, Last und die tatsächlich benötigten Daten müssen zum Betrieb passen.
Andere Aufgaben haben eigene Werkzeuge. Zammad ist ein Ticketsystem, Paperless-ngx ein Dokumentenarchiv und Apache Guacamole ein browserbasierter Remote-Zugang. Die Projekte sind als Open Source dokumentiert bei Zammad, im Paperless-ngx-Projekt und bei Apache Guacamole. Bei selbst betriebenen Anwendungen gehören Sicherung, Updates und Wiederherstellung zum Gesamtaufwand.
Garage ist ein Beispiel für S3-kompatiblen Speicher. Solche Bausteine lassen sich mit Anwendungen und deren Sicherungsverfahren verbinden. Übertragung, Rücklesen und vollständige Wiederherstellung müssen dabei jeweils gesondert geprüft werden.
Kostenlos und Open Source sind verschiedene Dinge
Graylog ergänzt das Monitoring um zentrale Ereignisprotokolle. Windows- und Linux-Hosts liefern bereits nachweislich Meldungen an den gemeinsamen Eingang. Bei der Einordnung ist die Lizenz wichtig: Graylog Open wird unter der SSPL angeboten. Graylog bezeichnet diese Variante als Source Available; sie ist nicht mit OSI-anerkanntem Open Source gleichzusetzen. Ein öffentlich einsehbarer Quellcode und ein kostenloser Einstieg bedeuten nicht automatisch dasselbe Lizenzmodell wie bei anderen Projekten.
Action1 gehört in eine andere Kategorie: ein kommerzieller Cloud-Dienst für Patchmanagement, Softwareinventar und Schwachstellenübersicht. Wir setzen ihn bereits ein. Laut Herstellerdokumentation, geprüft am 17. Oktober 2026, sind die ersten 200 verwalteten Endpoints kostenlos nutzbar. Das macht den Einstieg wirtschaftlich interessant. Es ist aber weder ein Open-Source-Produkt noch ein Beleg dafür, dass beliebige grössere Umgebungen oder sämtliche Supportleistungen kostenlos wären. Eine konkrete Kostenersparnis gegenüber anderen Anbietern haben wir nicht berechnet.
Der Aufwand verschwindet nicht mit der Lizenzgebühr
Selbst betriebene Software braucht Updates, Sicherungen, Überwachung und Zeit für die Fehlersuche. Ein Cloud-Dienst nimmt andere Arbeiten ab, bringt dafür eigene Abhängigkeiten und Vertragsbedingungen mit. Meine Entscheidung richtet sich deshalb nach der Aufgabe und nach dem Gesamtaufwand, nicht allein nach dem Preisschild.
Der bisherige Betrieb liefert dafür konkrete Erfahrungen: Dienste laufen, Daten werden gesammelt, Sicherungen übertragen und Fehler gezielt korrigiert. Gleichzeitig bleiben offene Punkte sichtbar. Genau diese Mischung ist für mich aussagekräftiger als eine pauschale Empfehlung für das eine oder andere Modell.
Warum ich jetzt dokumentiere
Eine laufende Anwendung erklärt noch nicht, warum wir sie genau so eingerichtet haben. Ohne Notizen gehen Entscheidungen, getestete Wege und die Grenzen eines Ergebnisses schnell verloren. Die neue Dokumentation soll diese Lücke schliessen und bei späteren Änderungen oder Störungen als verlässlicher Ausgangspunkt dienen.
Daraus entsteht auch der Blog: keine vollständige Anleitung unserer internen Umgebung, sondern eine Sammlung nachvollziehbarer Erfahrungen. Die technischen Details bleiben in der Betriebsdokumentation. Öffentlich möchte ich die Ziele, Erkenntnisse und Ergebnisse teilen – einschliesslich der Stellen, an denen die Arbeit noch weitergeht.