Als ich 1994 mit ersten HTML Seiten experimentierte war es schon recht toll überhaupt einen Webserver, oder eine Webseite zu haben. HTML, Frames, Tabellen und Gifs oder JPGs waren die Mittel der Wahl und ein Wysiwyg-Editor war schon ein gewisser Luxus.

So ab 2000 waren dynamische Seiten in, oft weniger weil sie besser waren, sondern weil sie halt auf asp oder php basierten und irgendwie cooler waren. Parallel dazu entwickelten sich Content Management Systeme, die dem Webautor das mühselige setzen der Seiten erleichtern sollten.

2004 stieß ich auf die Software Mambo CMS (und auf diverse andere geniale Systeme, von denen ich aber die meisten wieder vergessen habe) und kurz darauf auf dessen Nachfolger (ForkFork ein Fork ist in der OpenSource Welt eine Abspaltung, bei dem zu einem Zeitpunkt der Code der Software übernommen und als eigenes Projekt weitergeführt wird) Joomla und auch auf WordPress.

Mit Joomla realisierte ich viele Projekte, während mich zwar das damals kleine, schlanke und schnelle WordPress faszinierte, ich aber keine passenden Einsatzzweck dafür hatte.

Wieder etwas später, WordPress war mittlerweile keine kleine schlanke Blogsoftware mehr sondern ein ausgewachsenes CMS, begann ich meine Webseite damit zu betreiben. Aktuell ist das immer noch die Basis dieser Webseite.

Joomla und WordPress (auch verschiedenen anderen Tools wie Drupal, HumHub, uvm., welche ich getestet oder eingesetzt habe, die mir aber den Aufwand einer Migration meiner Webseite nicht wert waren) haben einige Dinge gemeinsam. Da wäre der recht aufgeblähte Unterbau inklusive Benutzerverwaltung, Pluginverwaltung und zahllosen Features, von denen ich nur sehr wenige benötige. Auch die serverseitige Scriptsprache PHP ist ihnen gemein, mit denen das Backend, die Datenbank und die eigentliche Webseite betrieben bzw. ausgegeben werden. Und natürlich eine Datenbank, in der nicht nur der Inhalt der Webseiten, sondern wirklich, wirklich viele Dinge in Tabellen abgelegt werden.

Das mag bei umfangreichen und hochfrequentierten Webseiten Vorteile haben, bei meinen kleinen Webprojekten hat es in der Regel einen großen Nachteil: Es macht die Webseite träge – ja vergleichsweise langsam. Also wird mit Präprozessoren und In Memory-Caching versucht die dynamische Webseite zu überlisten und eine Mischung aus vorausschauend aufbereitendem Content als statische Variante aus dem Cache geliefert. So wird der einige 100 MB große Apparat gar nicht erst in Betrieb genommen um meine paar KB an Webinhalt zu präsentieren. Dynamisch ist bei mir sowieso eher wenig – und wenn, dann eher weil WordPress es kann, denn das ich es wirklich brauche.

Ich stand also wieder vor einem kleinen, eher experimentellen Projekt und wollte wie gewohnt WordPress, MariaDB, Apache2 und PHP installieren. Moment! Der „HostHost Als Host bezeichnet man einen PC / Server, welcher das für eine Virtualisierung benötigte Betriebssystem (KVM, VMWare®) für Gastrechner bereitstellt. Oft auch scherzhaft "Blech" genannt, da hier meist die "reale" Hardware gemeint ist.“ ist ein Armv6 Rechner mit 500MB Ram, besser bekannt als Raspberry Pi 1B. „Da war doch vor kurzem ein Artikel über alternative CMS-Systeme“, den kramte ich aus meiner Linkliste.

Zwei grundlegende Ansätze drängten sich mir auf, FlatFileCMS (z.B. GravCMS, Typemill, …) und Static Site Generatoren (z.B. Hugo, Jekyll, …).

FlatFile CMS bedeutet, dass die Webinhalte in Markdown Dateien in einer Ordnerstruktur, die der Webseitenstruktur entspricht, im Dateisystem des Webservers abgelegt werden. Der Zugriff ist so insbesondere bei kleinen Webseiten, bei denen die Markdown Datei via PHP mit dem Template verknüpft und vom Webserver bereitgestellt und ausgeliefert wird, erheblich schneller als bei einer angeflanschten Datenbank. Das mag bei umfangreichen Webseiten oder bei sehr vielen Webzugriffen anders sein, aber das habe ich nicht getestet.

Bei einem Static Site Generator wird typischerweise aus Markdown Dateien und einem Template eine pure HTML-Datei mit CSS und evtl. ein wenig Javascript generiert. Die dadurch entstehende Ordnerstruktur wird auf dem Webserver abgelegt und als reines HTML ausgeliefert. Das gibt noch einmal einen richtigen Performance-Kick oder anders herum gesehen schont es die Ressourcen. Die wohl größten Nachteile sind das separat zu behandelnde GUI, bzw. die recht steile Lernkurve bei der Grundeinrichtung aller Elemente. Das mit dem GUI hat natürlich auch Vorteile, ich kann es unabhängig vom Static File Generator auswählen.

Es galt verschiedene Kriterien zu erfüllen und verschiedene Bedürfnisse abzuwägen, hauptsächlich waren das neben ressourcensparendem Fußabdruck ein komfortables Erstellen und Verwalten von Artikeln für die Webseite und ein einfacher Einsatz bzw. ein schnelles Einarbeiten.

Nach verschiedenen Versuchen setzte sich das FlatFile CMS Grav durch. Eine einfache Installation, dazu sollten PHP und Nginx zum Betrieb ausreichen. Die angebotenen Templates waren schlicht, aufgeräumt und richtig schnell. Auch das Backend (Grav-Admin) war in kurzer Zeit zu erlernen und mit der Markdown Syntax für die Webseiten hatte ich mich auch schon angefreundet.

So begeistert ich anfangs von GravCMS war, kamen aber auch einige Rückschläge. Für mein kleines Projekt benötigte ich keine Plugins außer dem Admin-Modul. Das Core-System von Grav lief mit PHP 8.2 wie geschmiert und das simple Template, das ich mir ausgesucht hatte, schien auch alle meine Wünsche zu erfüllen.

Kurz darauf sollte ein weiterer, etwas anspruchsvollerer Blog entstehen. Begeistert wie ich nun mal war, wollte ich GravCMS gleich bei diesem weiteren, erheblich umfangreicheren Projekt einsetzen und gegenüber dem von mir standardmäßig eingesetzten WordPress den Vortritt lassen. Leider folgten hier einige Hiobsbotschaften. Neben den Fonts von Google bzw. über Fontawesome, was im Endeffekt auf das selbe hinaus läuft – einen Verstoß gegen die DSGVO bzw. das Riskieren einer Abmahnung – stellte sich viele der schon in die Jahre gekommenen Plugins als nicht oder nur bedingt einsatzfähig heraus. Woran das lag, finde ich möglicherweise irgendwann heraus, ich vermute es waren Probleme mit PHP8.2 / 8.3. Am unangenehmsten viel mir der sorglose Umgang der Community mit Anbietern wie Google, Awesomefont oder Disqus auf. Es war schon eine gewisse Pfriemelei die Templates möglichst vollständig davon zu befreien.

Beim Thema Kommentarfunktion stieg ich dann nach drei Tagen vergeblichen Recherchierens und Experimentierens endgültig aus. Die Vorhandenen Module wollten partout nicht mit meinem System zusammenarbeiten. Schweren Herzens trennte ich mich also wieder von GravCMS und suchte weiter.

Natürlich hätte ich wieder zu WordPress greifen können, aber wenn ich schon einmal den Entschluss gefasst hatte, wollte ich es ohne durchziehen.

Ich sah mir Jekyll und Hugo, zwei OpenSource Static HTML Generatoren an. Das klang vielversprechend – dachte ich… Zuerst einmal musste ich feststellen, dass es sich hier nicht um ein CMS im herkömmlichen Sinne handelte. Viel mehr arbeitet man mit Jekyll oder Hugo auf einem Entwicklungssystem, dem eigenen PC zum Beispiel. Änderungen kann man so Live im Browser betrachten und ausgiebig testen. Wenn man zufrieden ist, schiebt man nur des Ergebnis auf den Webserver.

Schließlich entschied ich mich für Jekyll, mehr aus Sympathie, denn aus harten Fakten.

Auch bei Jekyll stieß ich auf das Problem eingebundener Fonts, hatte aber schon Übung diese aus dem von mir erwählten Template zu entfernen. Jetzt kam der Knüller! Jekyll generiert HTML Dateien – Punkt. Mir war schon lange nicht mehr bewusst, wie viele Funktionen man mit HTML und CSS nicht hat. Ein simples Kontaktformular stellt hier schon eine gewisse Herausforderung dar.

Ich las mich durch viele Forenbeiträge. Die Nutzer von Jekyll schienen eine Abneigung gegen PHP zu haben, standen Betreibern wie Github (Microsoft) oder Disqus (teils werbefinanziert) aber offen gegenüber – eine für mich etwas merkwürdige und schwer nachvollziehbare Sichtweise. Für mich ist der Verbleib meiner Daten auf meinem Server aber ein sehr wichtiges Element, darum erstellte ich mir mein Kontaktformular mit PHP erst mal selbst, was Jekyll erstaunlich gut ab kann.

Was ich noch erwähnen sollte, die Lernkurve bzgl. Jekyll ist steil. Richtig steil. Wenn man sich aber eingearbeitet hat, bekommt man ein Gefühl zurück, das ich schon seit langem nicht mehr kannte: „Kontrolle über meine Webseite!“

Also betreibe ich im Jahr 2024 eine HTML-basierte Webseite, mit wenigen zusätzlichen Codeschnipseln. Old fashioned? Vintage? Schnell, bunt und stabil!

Nachtrag: ich verwende als Kommentar-System „Isso“ ein kleiner in Python geschriebener Service, der die Verwaltung der Kommentare übernimmt, lokal und Ressourcensparend.

Haben Sie auch schon mal über einen ClusterCluster In der IT ist ein Cluster ein Verbund von mehrerern Komponenten wie Speichern oder Rechnern, die zum Zweck der Ausfallsicherheit oder Leistungserhöhung den selben Service ausliefern. nachgedacht, um Ihre Rechenleistung zu skalieren oder bei einem Hardware- oder Standortausfall Ihren Service einfach weiter zu betreiben?

Klar – aber die Kosten, die komplexe Konfiguration und der Leerlauf im Regelbetrieb schrecken Sie ab. Hier kommt Kubernetes oder wie in diesem Fall K3s ins Spiel. Sie haben bestimmt schon von Docker-ContainernDocker-Container Als Docker-Container bezeichnet man eine Technologie, bei der ein Service und alle Komponenten die zu seiner Erbringung notwendig sind in einem Paket, dem so genannten Container zusammengefasst werden. Die Schnittstellen werden abstrahiert und an den Container-Dienst, z.B. Dockerd übermittelt. gehört. Das ist zwar nicht die Einzige mögliche Lösung für K3s, der Einfachheit halber möchte ich mich aber hier darauf beschränken.

Mit Docker-Containern kann man – falls man die Konfiguration einmal passend erstellt hat – recht schnell einen Service bereitstellen. Alle Abhängigkeiten sollte der Container dabei mitbringen. Einen Schritt weiter gedacht, könnte man in Ausnahmesituationen einfach schnell ein paar weitere Container starten und – ein geeigneter und vorbereiteter Service vorausgesetzt – die Leistung ganz fix skalieren, oder einen ausgefallenen HostHost Als Host bezeichnet man einen PC / Server, welcher das für eine Virtualisierung benötigte Betriebssystem (KVM, VMWare®) für Gastrechner bereitstellt. Oft auch scherzhaft "Blech" genannt, da hier meist die "reale" Hardware gemeint ist. woanders wieder zum Leben erwecken.

Ja klar, macht der brave Administrator alles, auch am Sonntag nachmittag… Besser wäre vielleicht ein System, welches sich automatisch darum kümmert. Hier kommen Kubernetes (K8s) und K3s ins Spiel, die können das ganz gut. Zu den Hauptunterschieden von K8s und K3s gehört wohl der Umfang der Basis-Installation. So möchte K8s gleich mal 3 Master ServerMaster / Slave Als Master oder Slave bezeichnet man in der IT historisch viele hierarchische Abhängigkeiten. Eine mögliche Bezeichnung wäre Haupt- und Nebengerät. K3s stellt aber keine aufgewokte Bezeichnung bereit., die nichts anderes tun als die Worker-Nodes zu verwalten. Das ist zwar aus Sicht eines Ausfalles toll, aber schon sehr ressourcenintensiv. K3s kommt erst mal mit einem Master, der auch noch Worker-Node ist viel spartanischer daher, für reine Testumgebungen sollte das auch durchaus reichen. Mit einem Einzeiler auf der Kommandozeile lassen sich recht flott Worker-Nodes hinzufügen, oder auf Wunsch auch ein weiterer Master.

Jetzt kommt der Trick 17

Wir geben K3s ein Ziel vor, zum Beispiel fordern wir vom K3s-Master einfach 3 Apache-Webserver an, das definieren wir in einem so genannten Pod. Diesen Pod und die darin angeforderten Webserver-Container kann K3s jetzt auf den Nodes verteilen wie er möchte, oder wie es der interne Service Load Balancer vorsieht. Tritt eine Situation ein, bei der das Ziel nicht mehr erfüllt ist, weil vielleicht ein Host mit einer Worker-Node nicht erreichbar ist, wird K3s versuchen (einen) weitere(n) Container auf einem verfügbaren Node zu starten. Das macht K3s so lange bis das Ziel erreicht ist, oder keine weitern (freigegebenen) Ressourcen mehr zur Verfügung stehen. Dann bleibt der Service im Status degraded, oder im schlechtesten Fall steht er nicht zur Verfügung.

Das hört sich bisher alles ganz nach der Erfüllung vieler Adminwünsche auf einmal an, jedoch ist die Konfiguration teilweise sehr anspruchsvoll. Wir wollen schließlich nicht nur einen Webserver, sondern auch die passende Webseite, CMS, Datenbank usw. bereitstellen. Der erste Service mit einem „Hallo Welt“ ist in wenigen Minuten online, die gesamte Firmenwebseite, die auch bei einem Ausfall, oder bei blitzartigem Besucheransturm weiter läuft stellt ein ganz anderes Kaliber dar.

Nützliche Helfer

Damit die ganze Sache ein wenig übersichtlicher wird, bietet sich Open-Lens als grafische Benutzeroberfläche an. Hier gibt es diverse Möglichkeiten den Cluster, die Nodes und die darauf laufenden Pods zu verwalten.

Helm soll beim Verwalten und Verteilen der Pods behilflich sein. Das geschieht über sogenannte Charts und eine recht umfangreiche Biosphäre an bereitgestellten Templates und Containern, was bei mir bisher ganz gut funktioniert hat.

Fazit

K3s geht sparsam mit ihren Ressourcen um. Einmal sauber eingerichtet kümmert sich der Clustermanager um die Verteilung Ihrer Services auf die vorgesehenen Plattformen. Mit ein paar kleinen Änderungen an den Pod-Konfigurationen lassen sich schnell eine Menge Container verteilen oder wieder stilllegen.

Vielleicht gar keine so schlechte Idee ein eigener Cluster.

Kein Backup, kein Mitleid! Kennen Sie den Spruch? Bareos für ein zeitgemäßes, zuverlässiges Backup!

Die Software Bacula und dessen ForkFork ein Fork ist in der OpenSource Welt eine Abspaltung, bei dem zu einem Zeitpunkt der Code der Software übernommen und als eigenes Projekt weitergeführt wird Bareos begleiten mich schon seit vielen Jahren und sichern zuverlässig meine und die Server einiger meiner Kunden.

Bareos lässt sich sehr granular konfigurieren und bietet enorm viele Features, um Backups genau auf die eigenen Wünsche und Bedürfnisse einzustellen. Aber warum gerade jetzt darüber berichten? Ganz einfach – ich habe letztes Wochenende damit verbracht, meine Backup-Strategie zu überdenken und neu einzurichten.

Bei klassischen Bandsicherungen war eines der Hauptprobleme, ein defektes oder verlorenes Band, sowie der Aufwand einzelne Bänder einzulesen. Deswegen waren die Voll- und DifferentialsicherungVoll, Diff, Inc Vollsicherung: Alle Dateien werden gesichert (langsam, hoher Platzbedarf) Differentialsicherung: Alle geänderten Dateien seit der letzten Vollsicherung werden gesichert. Inkrementalsicherung: Nur die geänderten Dateien seit der letzten Sicherung werden gesichert. (in Kombination) die beliebtesten Sicherungsstrategien. Inkrementelle SicherungenVoll, Diff, Inc Vollsicherung: Alle Dateien werden gesichert (langsam, hoher Platzbedarf) Differentialsicherung: Alle geänderten Dateien seit der letzten Vollsicherung werden gesichert. Inkrementalsicherung: Nur die geänderten Dateien seit der letzten Sicherung werden gesichert. waren mit Vorsicht anzuwenden, da bei einer vollständigen Wiederherstellung die entsprechende VollsicherungVoll, Diff, Inc Vollsicherung: Alle Dateien werden gesichert (langsam, hoher Platzbedarf) Differentialsicherung: Alle geänderten Dateien seit der letzten Vollsicherung werden gesichert. Inkrementalsicherung: Nur die geänderten Dateien seit der letzten Sicherung werden gesichert. und alle darauf folgenden inkrementellen Sicherungen einwandfrei sein mussten. Diese Problematik führte meist zu einer GFSGFS Grandfather, Father, Son ist eine Sicherungsstrategie, die einen möglichst vollständigen Datenbestand beim Einsatz möglichst weniger Bänder gewährleisten soll. Beispiel: Der Son ist die tägliche (differentielle) Sicherung. Der Father ist die wöchentliche Vollsicherung, damit erden alle Tagessicherungen hinfällig und können überschrieben werden. Alle 4 Wochen wird jetzt ein Father zur Monatssicherung und damit zum Grandfather, damit sind die übrigen Father Sicherungen überschreibbar. Jährlich kann dann noch ein Grandfather zum Langzeit Archiv erklärt werden. Damit sind dann alle Monatssicherungen überschreibbar. Diese Strategie führt zu wenigen, meist verschmerzbaren Sicherungsanomalien und kommt mit ca. 20 Bändern aus. Sicherungsstrategie mit Voll- und Differentialsicherungen. Dies forderte hohen Platzbedarf sowie Zeitaufwand und ermöglichte SicherungsanomalienSicherungsanomalien Als Sicherungsanomalien bezeichnet man kalkulierte Verluste von Dateien, die trotz intakter Sicherung auftreten können. Beispiel: In einer GFS-Rotation wird innerhalb einer Arbeitswoche (zwischen zwei Vollsicherungen) eine Datei erstellt und wieder gelöscht. Drei Wochen später fällt das Fehlen der Datei auf. Aufgrund des Rotationsschemas wird die Datei nicht mehr auf den Sicherungsbändern zu finden sein..

Heute wird oft auf Cloud- oder NAS-Laufwerke gesichert, die je nach System mehr oder weniger redundant und ausfallsicher angelegt sind. Das Hauptproblem verlagert sich dadurch auf den (kostenintensiven) Speicherplatz, (Internet-)Bandbreite oder auf den möglichen Ausfall des ganzen Sicherungssystems. Das Mittel der Wahl stellen also inkrementelle Sicherungen dar. Angeführt von einer Vollsicherung, wird immer weiter inkrementell gesichert. Damit das nicht zu einem riesigen Bestand kleiner inkrementeller Sicherungen anwächst, wirkt man mit dem KonsolidierenKonsolidieren Konsolidieren meint in diesem Zusammenhang, die inkrementellen Änderungen werden auf die vollständige Sicherung angewendet. Auf Wunsch kann nur das Hinzufügen von neuen und geänderten Dateien, aber auch das löschen von Dateien angewendet werden. der Daten entgegen, was auch zu Sicherungsanomalien führen kann.

Wie lösen Sie das mit Bareos?

Bareos kennt die Funktion Allways Incremental (AI), welche das entsprechende Schema gut abbildet. Kombiniert mit dem Einsatz verschiedener Storage-Pools, welche auf verschiedene Speicherorte zeigen können, ergibt das eine Vollsicherung und viele inkrementelle Sicherungen, die wunschgemäß in die Vollsicherung konsolidiert werden. Dazu gesellt sich ein Copy-Job, der regelmäßig den Stand der Vollsicherung in ein Langzeitarchiv kopiert.

Je nach Aufwand, den Sie betreiben möchten, können Sie so eine georedundante Datensicherung aufbauen, die mit möglichst wenig Speicherplatz auskommt.

Ganz besonders klasse sind die Plugins für PostgreSQL und MariaDB / MySQL, mit denen Sie auch umfangreiche Datenbanken online und inkrementell sichern können.

Der Vor- ist auch gleichzeitig ein Nachteil

Die vielen tollen Konfigurationsmöglichkeiten, die Bareos bietet, das client- / serverbasierte Sicherungsmodell, verschiedene Medienpools, Band- / NAS- und Cloudspeicher wollen konfiguriert und ausgetestet werden. Läuft die Sache aber einmal rund, braucht sie sich hinter keiner anderen Backup Software mehr zu verstecken.

Solides Backup, Mitleid überflüssig!

In vielen Fällen merkt man höchstens, dass ITSM nicht oder mangelhaft funktioniert. Ein Buch im Internet bestellen sollte im Jahr 2023 keine allzu große Herausforderung sein.

So einfach wie ein Buch bestellen – Fehlanzeige!

Wenn ich bei einem der Branchenriesen ein Buch bestelle, egal ob neu oder gebraucht, kommt dieses mit wenigen Klicks nach kurzer Zeit bei mir im Postfach oder der Packstation an. Ich muss zugeben, dass ich dort bereits als Kunde registriert bin und mich den Bedingungen (Kreditkarte, Lastschrift o.ä.) unterworfen habe. Die Auswahl war aber meist groß und ich konnte meinen Vorlieben nachgehen.

Neulich wollte ich jedoch ein Buch bei einem Autor kaufen, der seine Bücher auch selbst anbietet. Ein Abenteuer – nun ein kleines natürlich.

Die Kiste der Pandora

Eigentlich war es nur der Shop des Autors. Was war passiert? Das Objekt meines Interesses, wurde auf der Seite zwar angezeigt, kaufen erwies sich aber als weniger einfach als erwartet. Dazu muss ich anmerken, dass ich für verschiedene Zwecke unterschiedliche Browser bzw. deren Ableger verwende. Im Fall einer störrischen Webseite greife ich dann auch mal auf Firefox oder Chrome in der Basisversion zurück. Hier waren aber selbst die gängigsten Browser hart gefordert. Nach einigen Versuchen hatte ich die Artikel endlich in meinem Warenkorb – jetzt nur noch bezahlen und fertig … dachte ich mir.

Mittlerweile war wohl mein Jagdinstinkt erwacht, der mich vom simplen verlassen der Seite abhielt. Schließlich gab es da Buch auch bei einem Branchenriesen und es musste noch nicht mal unbedingt dieses sein. Ich versuchte also weiter mein Glück. Verwirrt landete ich auf einem Kalender.

Wenn der Service gar nicht vorhanden ist, lässt er sich dann „Managen“

Ich fragte via Kontaktformular beim Verkäufer nach und erfuhr, das dies schon so richtig sei, da jener nicht zeitnah sondern seinem Terminkalender nach versenden wollte. Ich könne mir einen der angezeigten Versandtermine in unterschiedlich weit entfernter Zukunft aussuchen. Meine zur Mail gebrachte Ansicht, ich wollte das Buch baldmöglichst und obendrein auch so einfach wie möglich erhalten, stieß auf Unverständnis, anbei hatte ich meine Probleme mit der Webseite geschildert.

„Man sei eigentlich Dienstleister und habe andere Prioritäten, deswegen fände Versand nur nach Terminvereinbarung statt.“ war die Antwort auf meine Fragen. Das der Webshop  nicht funktioniere, läge vermutlich an mir oder meinem Browser, bei ihm laufe es einwandfrei und er wolle der Webagentur deswegen auch nicht Bescheid geben.

Selbst der hartgesottenste Kunde gibt irgendwann auf.

Jetzt wollte ich nur nicht mehr auf den Kauf verzichten, um zu beweisen, dass mir einfach nicht möglich war hier einzukaufen. Nach weiteren Versuchen gelang es mir meine Adresse einzugeben und den Versand in etwa 2 Wochen zu terminieren. Ein paar Tage später fragte ich erneut an, ich wollte das Buch schließlich nicht nur bestellen, sondern auch bezahlen. Da kam doch glatt der Hinweis, meine Adressdaten wären falsch.

Ich quälte mich also erneut mehrmals durch den Bestellprozess – denn einfach so per Mail war die Bestellung unmöglich aufzunehmen – und gab meine durchaus gültigen Adressdaten erneut ein, wählte erneut einen Termin in noch fernerer Zukunft und harrte der Dinge, die da kommen sollten. Die Antwortmail des Verkäufers, an meine Adresse (DHL-Packstation) wolle er nicht versenden, setzte dem ganzen dann final die Krone auf.

Ich fühlte mich an Zeiten erinnert, in denen am Ende von Webseiten stand: „Optimiert für Internet Explorer 5 (5.5, 6, 7 usw.) mit einer Auflösung von 1280×1024“, oder so ähnlich. Wenn jemand einen so einfachen Service schon nicht anbieten kann, sich aber gleichzeitig als Dienstleister bezeichnet, möchte ich auf die Qualität dessen Dienstleistung lieber auch gleich verzichten. Ich will mir nicht vorschreiben lassen, welchen Browser oder Betriebssystem ich zu verwenden habe, noch an welche Adresse ich meine Ware geliefert haben möchte, Packstation, Postfach oder Hausadresse – meine Entscheidung!

Hilft mir IT Service Management dabei?

Da ich viele Prozesse in meinem IT Service Management (ITSM) System in der Planungsphase schon durchdacht habe, Standard Abläufe in Vorgangsbeschreibungen oder Arbeitsanweisungen stehen und die Konfiguration meiner Geräte detailliert in meiner CMDB zu finden sind, muss ich viel weniger Zeit in einen einzelnen Vorfall stecken als früher.

An die regelmäßige Planung und Dokumentation musste ich mich erst einmal gewöhnen. Zu Anfang tendierte ich immer noch zu „losstürmen und Fehler beseitigen“. Mittlerweile habe ich gelernt, dass ein geplanter Change viel weniger unerwünschte Nebeneffekte mit sich bringt. Zudem sind die Änderungen am System gleich dokumentiert, was besonders in stressreichen Situationen gerne mal unter den Tisch fällt.

Ist die umfangreiche Dokumentation nicht zu aufwändig?

Zu Anfang ist die Dokumentation der Prozesse und aller einzelnen Vorgänge natürlich ein Mehraufwand. Je mehr sich FitSM jedoch in meinem Arbeitsleben breit macht, desto mehr unterstützt es mich. Die Dokumentation eines einzelnen Falles besteht meist aus der Planung im Vorfeld, wodurch schon ein großer Teil der Dokumentation angelegt wird. Die tatsächliche Durchführung des Changes und die anschließende Dokumentation sind oft mit „Wie geplant gelaufen, CMDB update Ok, PIR (Post Implementation Review) positiv.“ schnell erledigt. Der Ablauf des PIR – ein check ob alles nach dem Change wie gewünscht läuft – sollte bereits Teil der Dokumentation sein und in der Change Planung nur referenziert werden. PIRs können bei komplexen Systemen recht umfangreich sein

In der Helden IT wird die Planung gerne weggekürzt, der IT Held hat ja viel Erfahrung und kann entsprechend auf verschiedene unvorhergesehene Ereignisse reagieren. Die Zeitersparnis ist schnell aufgebraucht, wenn der erste unvorhergesehene Seiteneffekt auftritt. Die Dokumentation im Anschluss wird übrigens wegen der ungeplant langen Dauer des Vorgans auch gerne mal weggekürzt. Wir haben ja einen IT Helden, der das im Ernstfall wieder hinbiegt 😉

Mach Du mal…

Ein ganz wesentlicher Teil der Produktivität besteht darin, die einfachen wiederkehrenden Dinge zu delegieren. Dazu ist die umfangreiche Dokumentation bei ITSM wie geschaffen. Je detaillierter die Anweisungen zu einem Vorgang festgehalten sind, umso einfacher ist der Auftrag zu vergeben. Es ermöglicht mir schließlich viel produktiver zu sein, wenn ich den Change nur noch genehmigen muss, anstatt ihn selbst zu planen und durchzuführen. Auch wenn es sich anfangs komisch anfühlt, Verantwortung für die Ausführung der Tätigkeit abzugeben – was für ein schönes Gefühl, delegieren zu können.

IT Helden haben es da viel schwerer. Ihre persönliche Expertise ist nicht einfach zu übertragen und große Teile der Dokumentation befinden sich in ihrem Kopf. Fällt der IT Held aus, muss die Vertretung von einem weiteren IT Helden übernommen werden – gar nicht so einfach.

Jetzt kommt das beste:

Durch mein gut dokumentiertes System, das es mir erlaubt mehr produktiv und weniger beschäftigt zu sein, bekomme ich noch einen Bonus.

Ich bin ersetzbar!

Ich kann also ganz entspannt in den Urlaub fahren. Auf eine einsame Insel, ohne Internet oder Mobilfunkempfang – falls ich das möchte. Denn mein System wird auch ohne mich weiterlaufen. Wenn es zu einem Incident kommt ist alles gut dokumentiert und kann von allen meinen Kollegen wieder zum Laufen gebracht werden.

In der Markenwerkstatt

Ich rufe hauptsächlich wegen 3 Fällen in meiner Werkstatt an:

• Häufig: Ich möchte einen Kundendienst- oder Reifenwechsel- Termin. In diesem Fall werde ich nach einem Wunschtermin gefragt, und ob mir etwas besonderes aufgefallen ist. Der Rest läuft fast ohne mein zutun ab. Ich gebe mein Auto zum vereinbarten Termin ab, bekomme eine Tasse Kaffee angeboten oder auch ein Ersatzauto für den Tag.
• Manchmal: Ab und Zu tritt eine Störung am Auto auf, was sich auf verschiedene Art äußern kann. Ich werde in der Regel mit dem Meister oder zumindest einem Mechaniker verbunden und bekomme nach einer (möglichst präzisen) Fehlerbeschreibung eine Auskunft um was es sich handeln könnte und ob ich weiterfahren oder den Pannendienst holen soll.
  Bringe ich mein Auto dann wieder in die Werkstatt, wiederholt sich der gleiche freundliche Vorgang. Auto abgeben, Kaffee trinken, Ersatzauto mitnehmen.
• Selten – Ich möchte ein neues Auto kaufen. Dann werde ich wie ein Superstar empfangen, aber das lassen wir aus unserem Beispiel besser weg.

Als Fazit kann ich sagen, egal ob gerade viel oder wenig los ist, der Umgang ist freundlich, man versucht meine Wartezeit angenehm zu gestalten (was auch mal für Produktwerbung genutzt wird) oder ich bekomme ein Ersatzgerät. Das bietet nicht unbedingt die selbe Leistung und den gleichen Komfort wie mein eigenes Auto, reicht aber so gut wie immer aus. Ach ja – ob ich das Problem selbst verursacht habe, spielt nicht die geringste Rolle.

Mein Beitrag dazu, der vielleicht auch eine Rolle spielt: Ich bemühe mich einen erkannten Fehler umgehend zu kommunizieren und präzise zu beschreiben, ein „Die Karre geht schon wieder nicht“ wäre vermutlich wenig hilfreich für beide Seiten. Und ich erwarte nicht sofort einen Termin in der Werkstatt, ich begnüge mich mit der Auskunft am Telefon. Ich bin auf der untersten Stufe für Kfz-Bediener qualifiziert und zertifiziert (Führerschein der passenden Klasse).

Beim IT Service

Beim IT Service sieht das in der Regel ein wenig anders aus. Ein Kundendienst ist nicht vorgesehen, bestenfalls werden Updates geplant und ausgerollt. Eine Tasse Kaffee bekomme ich auch nicht und ein bequemer Wartebereich ist Mangelware. Das kann natürlich am Budget und am Platzangebot der IT Abteilung oder des Service-Shops liegen, oder daran dass es überhaupt nicht vorgesehen ist dem Klienten eine angenehme Wartezeit zu bieten.

Innerhalb einer Firma kann ein Ersatzlaptop durchaus üblich sein, aber bekomme ich dieses auch so, dass ich mich hinsetzen und loslegen kann? Bei Privatkunden im Serviceshop sieht das sicher anders aus und selbst wenn ein Ersatz möglich ist, kann ich damit umgehen?

Bei der präzisen Fehlerbeschreibung wirds jetzt ganz eng. Ein geändertes Verhalten des PCs wird vom Benutzer eher selten an die IT Abteilung gemeldet und wenn, bekommt er noch seltener eine hilfreiche Auskunft.

Bei Fehlermeldungen hat bisher auch noch keines der mir bekannten Systeme eine einfache, mit aussagekräftigen Symbolen versehene Warnanzeige etabliert.

Mein Fazit: Die Kommunikation ist eher tagesformabhängig und selten wirklich freundlich. Der gesamte Vorgang ist nicht auf eine angenehme Erfahrung ausgerichtet. Selbst bei vorhandenen Ersatzgeräten ist nahtloses Weiterarbeiten selten möglich.

Der Beitrag des Anwenders: Fehler kommuniziere ich nicht im Ansatz, viel öfter erst, wenn eine Weiterverwendung / Reparatur nur noch schwer möglich ist. Fehlerbeschreibungen versuche ich gar nicht erst präzise zu formulieren, auch eine Meldung wie „Ihr Druckauftrag wurde ausgeführt“ sind nur kryptische Meldungen, mit denen Benutzer sowieso nichts anfangen können. Hilfe erwarte ich immer sofort, mein Problem ist für mich schließlich das Größte. Eine entsprechende Grundqualifikation habe ich natürlich nicht.

Managed IT Service

Warum funktioniert das jetzt bei meinem Auto so gut und bei meinem Laptop so schlecht?

Meine Erklärung gilt jetzt natürlich nicht für alle Fälle, sondern schöpft aus meiner persönlichen Erfahrung.

Zum Einen ist es ganz klar die Standardisierung. Autos sind, auch wenn sie sehr individuell erscheinen, hochgradig standardisiert. Im Prinzip kann ich mich als Führerschein Inhaber in ein fremdes Auto setzten und losfahren. Bis auf ein paar Kleinigkeiten unterscheidet sich die grundlegende Bedienung von verschiedenen Autos nicht.

Bei Laptops – sollte man meinen – könnte das doch ähnlich sein? Selbst wenn das gleiche Betriebssystem, die gleichen (wesentlichen) Anwendungen und evtl. der selbe Hersteller zur Verfügung stehen, scheinen die Anwender hier wesentlich mehr Probleme beim Umstieg zu haben.

Ansatz Nr. 1 – PC-Führerschein

Möglicherweise liegt es an der (oft fehlenden) Grundqualifikation und an den damit einhergehenden selbst erlernten Angewohnheiten („Klickstrecken“). Der Benutzer kennt die „Standards“ überhaupt nicht und ist in einer nicht personalisierten Umgebung erst einmal recht unsicher.

Dagegen könnten natürlich Schulungen helfen, ein Führerschein zur PC-Bedienung. Der Benutzer könnte sich an das Ersatzgerät setzen und los arbeiten, da er die zu Grunde liegende Technik verstanden hat und nicht auf die gewohnte Ansicht von Hersteller XY angewiesen ist.

Ansatz Nr. 2 – Erweiterte Serviceleistungen

Die IT-Abteilungen oder Reparaturshops sind selten auf solche Szenarien eingerichtet.

Die Reparaturannahme für Laptops könnte zu einem ähnlich angenehmen Erlebnis wie beim Auto werden. Sitzplätze, Zeitschriften und kostenlose Getränke während der Benutzer auf die Eingangsprüfung wartet. Bei Reparaturzeiten die eine Stunde übersteigen gibt es ein Ersatzgerät und eine Benachrichtigung zum Abholen des reparierten Kundengeräts.

Ansatz Nr. 3 – Ersatz statt Reparatur

Das geht Reparaturshop nicht ganz so einfach, in kontrollierten Umgebungen ist es aber möglich. Alle benutzerdefinierbaren Einstellungen werden gesichert und bei Bedarf auf das Ersatzgerät übertragen. Damit kann das Ersatzgerät auch gleichzeitig weiterverwendet werden.

Alles schön und gut

Und was hat da jetzt mit ITSM zu tun? Viel – sogar sehr viel!

Services, Prozesse und auch Geräte wollen standardisiert werden. Dazu verwenden wir die Dokumentation aus unserem IT Service Management. Benutzer werden geschult, Einstellungen werden dokumentiert – damit kann die IT-Abteilung (und mit ein wenig Vorarbeit auch der Reparaturshop) einen ähnlich tollen Service wie das Autohaus anbieten. FitSM machts möglich.

Wo liegt dann das Problem?

Zum einen ganz bestimmt im Budget. Da der Vorteil eines solchen Vorgehens ohne gutes ITSM-Reporting nicht greifbar ist, fällt es schwer für solche Luxusprobleme eine Finanzierung hin zu bekommen. Erst wenn der Mehrwert durch kürzere Ausfallzeiten belegt werden kann, lässt sich auch ein ROI aufzeigen.

Ein freundlicher Umgang ist auch schwer messbar und damit einhergehende positive finanzielle Auswirkungen noch schwerer. Ein Beispiel könnten Benutzerfehler sein, die schneller und vollständiger gemeldet werden. So wird möglicherweise weiterer Schaden frühzeitig vermieden und der Reparaturaufwand verringert.

Wollen Benutzer und Servicemitarbeiter geschult werden? Manchmal. Natürlich kosten Benutzerschulungen erst mal Geld. Kompetentere Benutzer, die weniger Fehler machen und schneller arbeiten und dank ihrer neuen Kenntnisse zufriedener mit ihrem Arbeitsgerät sind sparen diese Kosten sicher schnell wieder ein.

Lange Jahre konnte ich mich nicht vom Design meiner alten Webseite trennen. Hatte ich doch viel Arbeit darin investiert, die Technik und das ein wenig düstere Aussehen lieb gewonnen.

Aber jetzt ist es endlich so weit! Ab jetzt erstrahlt alles im neuen Design!

Alle wesentlichen Inhalte haben es natürlich hierher geschafft. Viel Spaß! 🙂

IT Helden sind die Stütze einer reaktiven IT. Wenn es in der Unternehmens-IT klemmt, sind wir froh wenn ein IT Held in die Bresche springt und in mehr oder weniger kurzer Zeit alles wieder läuft – so ähnlich wie zuvor, vielleicht sogar besser als je zuvor, zumindest aber wieder irgendwie.

Verstehen Sie mich nicht falsch. Ich war selbst Jahrelang ein IT Held. Gut ausgebildet mit viel Erfahrung und Begeisterung für meinen Job, nur war ich – wie viele meiner Kollegen – (zu) oft im Einsatz um Brände zu löschen, die nicht nötig gewesen wären, um Kollegen Vorgänge zu erklären oder um die Scherben zu beseitigen die andere hinterlassen hatten. Das wirkte sich oft schlecht auf die Planung und Konzeptionierung der IT aus, führte zu hohem persönlichen Stress und verminderte obendrein noch die Qualität der Ergebnisse.

Wäre das alles mit einem IT Service Management System (ITSM) wie FitSM nicht passiert? Schwer zu sagen. Sicher hätte der hohe Dokumentationsgrad eines Service Management Systems (SMS) meine IT Kollegen befähigt ähnlich gute Fehleranalysen zu erstellen und ebenso gute oder noch bessere Lösungen zu erarbeiten wie ich sie mir gerne anhefte. Was ich aber in jedem Fall sagen kann: Der strukturierte Ansatz in einem SMS macht die Aufgaben, die Abläufe und die Kosten in einer IT Abteilung transparent und planbar.

Vielleicht kann ein IT Held einen aufgetretenen Engpass mit viel persönlichem Einsatz schneller beheben als eine über ein SMS verwaltete IT Abteilung, aber bei der würde der Engpass wahrscheinlich schon Wochen oder Monate vor einem Ausfall auffallen und es wäre möglich rechtzeitig Gegenmaßnahmen einzuleiten.

Meine Erkenntnis daraus: Helden IT ist nicht unbedingt schlecht, nur oft unkontrolliert und reaktiv. Mit ITSM machen wir einen großen Schritt in Richtung proaktive IT und schaffen uns die Möglichkeit, unsere Service Management Prozesse zu steuern.

Was ist SDTP und wofür ist das gut?

In der FitSM-Theorie wird ein Service nicht einfach installiert und laufen gelassen bis ihn keiner mehr braucht, sondern der Service wird geplant und in Betrieb genommen. Die Planung umfasst viele Aspekte, unter anderem welche Kapazitäten (personell, finanziell und technisch), welche Verfügbarkeiten und welche Wartung ein Service benötigt. Das ist nicht nur in FitSM so, sondern im Service Management allgemein.

Evtl. ist ein Business Case oder Geschäftsszenario vorteilhaft. Dabei werden verschiedene Aspekte des Service beleuchtet und theoretisch in den Geschäftsablauf eingebaut. Der beste und schlechteste Fall und der durchschnittliche Betrieb werden angenommen und die Auswirkungen auf die bereits vorhandenen Services und Geschäftsprozesse besprochen.

Ist das nicht umständlich?

Doch ist es – aber wie viel umständlicher ist es im laufenden Betrieb festzustellen, dass der Service nicht der richtige ist, nicht den erwünschten Vorteil bringt oder vom Kunden so überhaupt nicht benötigt oder akzeptiert wird.

Wenn erst mal Zeit und Geld in einen Service geflossen sind, wird er auch mal weiter genutzt oder angeboten – unabhängig davon ob er passend ist oder genutzt wird.

In der Praxis

Ob ein Kunde den neuen Service braucht oder wieder nur auf den nächsten neuen Zug aufspringen will, lässt sich oft schon mit ein paar wenigen gut platzierten Fragen herausfinden. Manchmal ist es auch besser, einen bereits vorhandenen Service zu verbessern oder mit ein paar Einstellungen und vor allem ein paar Benutzerschulungen das Gewünschte zu erreichen.

Diese kleine Geschichte basiert auf einem persönlichen Erlebnis.

Alles begann damit, dass ich eine Benachrichtigung von DHL erhielt, ich hätte eine Sendung in der Packstation am Ort. Das sollte jetzt IT-Service-Management-technisch kein großer Akt sein – oder doch?

Ich nehme mir also eine kleine Auszeit um Postfach und Packstation einen Besuch abzustatten. Ersteres funktioniert altmodisch – ja beinahe mittelalterlich – aber tadellos mit einem großen gelben Schlüssel.

Letztere hat in den vergangenen Monaten zahlreiche technische Features hinzubekommen. Zuerst fiel die VIEL zu unsichere PIN weg und wurde durch eine Mobil TAN ersetzt. Die alte Karte wurde durch eine viel fortschrittlichere mit Barcode ersetzt, worauf der Barcodereader an der örtlichen Packstation umgehend ausgebaut wurde. Die Mobile TAN wurde kurz darauf durch eine viel bessere und sicherere Email mit QR-Code und TAN ersetzt. Bis zum neuesten Gimmick, der nur noch auf aktuellen Smartphones laufenden DHL-App, die einen zeitlich befristeten QR-Code bei Bedarf generiert und die Postnummer, die PIN, die SMS, die Mail und die TAN ersetzt.

Service Design und Transition haben hier entweder einen auf wenige Wochen fokussierten Livecycle oder mehrmals hintereinander echt Murks produziert.

Bis hier könnte man sagen: „Hat doch gar nicht wirklich etwas mit ITSM zu tun…“. An der Packstation angekommen generiere ich meinen für 2 Minuten gültigen QR-Code und halte diesen vor den entsprechenden Scanner. Das Display spuckt eine Fehlermeldung aus. Ich versuche es mit manueller Eingabe und unternehme weitere Versuche mit neuen QR-Codes. Alles klar, das ist ein Fall für die prominent im Display angezeigte Hotline Nummer.

Am anderen Ende möchte der der eher moderat freundliche Herr eine Sendungsnummer  von mir, diese habe ich nicht, weder meine App, noch die Art der Sendung sehen so etwas vor. Ich schildere meinen recht einfachen Fall trotzdem, keine Chance, ist nicht vorgesehen. Ich werde weiter verbunden und nach erneuter Incident Schilderung wieder weiter verbunden. Nach dem ich insgesamt 18 Mal nach meiner Sendungsnummer gefragt wurde, und ich mehrfach versucht habe den Fall an eine kompetentere Stelle, wie z.B. die Technik zu verlagern, legt die mittlerweile dritte Hotline-Dame einfach auf.

Auf die Frage, wo genau ITSM hier versagt hat, gibt es sicher eine Menge Antworten. Ob jetzt aber der Helpdesk in 3 Fällen unflexibel war, oder einfach keine Möglichkeit bestand die Software ohne Sendungsnummer zu verwenden und damit ein Schulungs- oder Planungsproblem vorliegt, ist schwer zu sagen.

Sicher ist, hier sollte dringend der CSI-Prozess involviert werden!

Nach meinem Telefonat versuchte ich es mit der Hoffnung der Verzweifelten noch einmal – und siehe da, die Technik hat mehr Einsicht als ein schlecht designeter Service Prozess.