Ich bin selber kein Planungsweltmeister. Dies ist zumeist auch nicht nötig. Zu meist habe ich mit einem groben Plan gearbeitet und die Details während der Arbeit ausgearbeitet. Es gibt jedoch Momente wo eine gute Planung und Vorbereitung wichtig sind.
80 / 20 Regel
Man kann einen perfekten Plan für eine Infrastruktur machen. Sobald man sich im Aufbau befindet, findet man Fehler im Plan. Daher ist ein grober Plan nützlicher, da man die nicht "verplante" Zeit hat um auf Unvorhergesehenes reagieren zu können. Verbringt man alle Zeit mit dem Planen und hat sich nur die nötigste Zeit für das Umsetzten vorgesehen, ist dies ein Fehler. So hat man keine Zeit um auf Fehler reagieren zu können. Dazu weiter unten ein Beispiel.
Am obligatorischen Nothelferkurs für den Führerschein hat ein Kursleiter eine kurze Geschichte erzählt, welche diesen Punkt klar aufzeigt.
Bei einer früheren Durchführung des Kurses gab es eine Abschlussprüfung. Dies war ein vorbereitetes Szenario, welches die Kursteilnehmer bewältigen mussten. Beim Start stand die Gruppe zusammen und began das beste Vorgehen zu diskutieren. Nach dem der Kursleiter für mehrere Minuten zugesehen hat, ging er zur Gruppe und sagte, sie können aufhöhren. Alle Opfer im Szenario sein unterdessen nicht mehr zu retten.
Dies soll kein Aufruf sein, kopflos und ohne Plan vorzugehen, jedoch auch nicht zu viel Zeit mit der Planung zu verbringen.
Beim planlosen Vorgehen können Dinge vergessen werden oder mehrfach erledigt werden. Dies ist ein extremes Bespiel, zeigt jedoch die Gratwanderung des guten Planen auf.
Bei uns laufen viele Prozesse automatisiert ab. Da ist es wichtig, die Abläufe der Software genau abzusprechen, bevor man mit dem Programieren beginnt. Jedoch muss die Planung nicht Diagramme für jede Codezeile beinhalten. Das hängt jedoch von dem bevorzugten Ablauf des Programieres ab. Ich bevorzuge lieber ein freieres Vorgehe.
Ein Beispiel für keine grosse Plannung war unser System für die Überwachungskameras. Dazu habe ich nach einer passenden Serversoftware gesucht. Anschliessend die Installationsanleitung überflogen auf der suche nach unbekannten Befehlen. Anschliessend die Anleitung in einem Lesezeichen markiert und am Tag der Installation abgearbeitet. Dabei bin ich auf ein Problem gestossen, welches in der Anleitung nicht erwähnt wurde. Im Forum der Software fand ich die Lösung.
Hätte ich mehr recherchiert oder eine Testinstallation gemacht, hätte ich das Problem vor der richtigen Installation gekannt. Dann wäre dies auch ohne Probleme abgelaufen. Hätte jedoch mindestens die doppelte Zeit in Anspruch genommen.
Wann viel Zeit in die Planung investieren
Es gibt Fälle, da habe ich viel Zeit in die Planung investiert. Dazu werde ich unten zwei Beispiele aufführen. Diese sind jedoch von den Anforderungen her spezielle Beispiele und ich möchte sie daher genügend Würdigen.
Umzug Aufbereitung
Als am ersten Standort der Platz knapp wurde, entschieden wir uns einen neuen Standort zu beziehen. Dabei wollten wir keinen Unterbruch unseres Services haben. Da wir die Geräte alle zwei Wochen versendeten, hatte ich ein Zeitfenster von zwei Wochen. Das hiess nicht, das alles in zwei Wochen verschoben werden musste. Nur das die nötigste Infrastruktur so lange wie nötig am alten Standort bleiben musste und dan in zwei Wochen verschoben und neu aufgebaut werden musste.
Das hier eine bessere Planung von Nöten war, ist logisch. So habe ich die neuen Switches am ausgiebig getestet und konfiguriert am alten Standort. Auch habe ich die Serverinfrastruktur am alten Standort so weit wie möglich reduziert. Die frei gewordenen Server habe ich benutzt, um die Infrastruktur am neuen Standort aufbauen zu können. So konnte ich die Funktion des alten Standort aufrecht erhalten, während der neu Standort aufgebaut wurde. Da wir fast alle switches ersetzten, konnte ich das Netzwerk am neuen Standort aufbauen, ohne den alten niederreisen zu müssen
Jedoch musste ich die ganze Zeit die Hardware beachten, welche noch am alten Standort steht und erst später umgezogen wird.
Auch gilt es das Netzwerk und die Netzwerksegmentierung / VLANs zu planen, bevor man die Switches konfiguriert. Ansonsten kann es später zu Problemen mit der Erweiterung des Netzes kommen.
Da hier wichtige Infrastruktur involviert war und ein enges Zeitfenster existierte, war die Planungs und Testphase grösser als bei anderen Projekten.
Ersatz KaaS
Anfang dieses Jahres bekammen wir eine Nachricht von unserem Cloudhosting anbieter, dass sie ihr bestehendes Kubernetes as a Service, KaaS, Angebot einstellen müssen. Der Hintergrund war, dass sie VMWare Tanzu einsetzten und nach der Übernahme durch Broadcom die Kosten dafür explodiert wären. Da sie lange mit Broadcom versucht haben zu verhandeln, war die Frist bis zur Abschaltung ziemlich kurz.
Unser Hostinganbierte, https://www.cyberlink.ch/de, war extrem entgegenkommend und hat uns auch Beraten, wie wir den Wechsel am einfachsten bewerkstelligen können. Da verschiedene unserer wichtigen Apps, die unsere SSO Lösung, auf dem KaaS liefen, musste der Wechsel schnell und möglichst ohne Probleme über die Bühne gehen. Daher nahm ich mir die Zeit, mich in die gewählte Lösung einzulesen und habe eine komplette Spiegelinfrastruktur auf unseren lokalen Server aufgebaut. Dabei habe ich jeden Befehl so notiert, wie ich ihn im Terminal eingegeben habe. Insgesamt habe ich unsere Lösung mindestens 3 mal lokal frisch aufgebaut und eingerichtet.
Dann kam der Tag des Wechsels. Ich habe mir die Liste mit den Befehlen bereitgelegt und mit dem Aufsetzten der Server begonnen. Aber die Grundkonfiguration lieferte schnell einen Fehler. Mehrmaliges googlen und Rubber Ducky Gespräche mit meinem Chef konnten das Problem nicht lösen. Kurz vor Ende des Tages konnte ich das Problem endlich beheben und ein funktionierendes Kubernetes Cluster aufsetzten.
Was lief schief. Ich weis es bis heute nicht hundertprozentig. Meine lokale Infrastruktur läuft auf XCP-ng als Hypervisor. Die Cloud jedoch auf VMWare. Die Lösung war der Kommunikationsweg der Kubernetes Host untereinander. Standartmässig läuft dieser über XVLANs. Nach einem Umstellen auf Wireguard war das Problem verschwunden. Dies ist eigentlich unnötig, da die Servernodes am gleichen Standort laufen und über ein privates Netzwerk miteinander verbunden sind. Es fügt nur einen zusätzlichen Verschlüsselungslayer hinzu.
Das Problem führte dazu, dass ich die Umstellung am nächsten Arbeitstag vornehmen musste und anstatt den erhofften und bei Tests benötigten 3 Stunden eineinhalb Tage benötigt habe.
Als Lehre habe ich mehrere Punkte herausgezogen:
- Ist die Testumgebung nicht 100% identisch mit der realen Umgebung, ist der Test unnötig. Die Tests haben mir in diesem Fall nur geholfen den Fehler zu suchen.
- Kein Plan überlebt den Kontakt mit der Realität. Es gibt immer Umstände, welche man nicht vorher sieht.
Was hilft, wenn man ohne genauen Plan arbeitet
Bei beiden Problemstellungen halfen mir meine Kenntnisse von Netzwerk und Linux Betriebssystemen. Das wichtigste ist das man die Grundlagen kennt und Fehler suchen kann. Kann man nur Befehle aus Anleitungen kopieren, so ist man nutzlos wenn die Anleitung nicht mehr funktioniert. Hat man aber grundlegende Systemkenntnisse kann man bei Fehlern selbständiger vorgehen.
Auch eine Laborumgebung ist Hilfreich. Je öffters man einen Server aufgesetzt und Software darauf installiert hat, des leichter fällt es einem.
Dies soll bei weitem nicht ein Aufruf zu planlosem Arbeiten sein. So hat mir beim KaaS Projekt die Erfahrungen aus den Tests geholfen. Auch konnte ich bei den Tests die Konfiguration soweit anpassen, dass sie meinen Bedürfnissen genügte.
Eine gute Planung kann auch die Dokumentation vereinfachen
Nach dem KaaS Projekt musste ich die Serverkonfiguration nicht mehr Dokumentieren. Ich habe die Befehle von den Tests aus der Dokumentation kopiert. Aufgrund der Probleme musste ich die Befehle anpassen. Dies habe ich jedoch zuerst in der Dokumentation erledigt und die Befehle von da aus auf die Server kopiert und ausgeführt.