Home Verdummt die IT, oder machen wir es uns zu einfach?
Post
Cancel

Verdummt die IT, oder machen wir es uns zu einfach?

Sorry, ich theorisiere mal wieder, vielleicht bin ich aber auch gerade etwas zu sehr angefressen …

Ich habe keine Informatik studiert.
Ich bringe mir Dinge selber bei, bin Praktiker, ein Autodidakt. Ich lerne durch tun, durch anfassen und durch Fehler machen.

Okay, ich bin jetzt auch eine Spur älter als viele, die mich in meinem Arbeitsumfeld umgeben und ein ähnliches Aufgabenspektrum bedienen.
Ich weiß wie CPU, RAM, und HDD zusammenarbeiten, habe meine ersten Rechner auch noch selber zusammengebaut, kann mit Begriffen wie TCP/IP, Protokollen und I/O umgehen.
Hab gelernt, wie man Services manuell kompiliert, installiert und konfiguriert.
Ich würde sagen, ich kann deren Wichtigkeit in einer normalen IT Umgebung bewerten.

Damit einhergehend rollen sich mir die Fußnägel vor Schmerzen auf, wenn ich mir die aktuelle Situation in der IT anschaue.
Beginnend in der Schule vom Mitbewohner … Informatik heißt dort .. Word Dokumente schreiben!

Warum fragt man denn nicht mal bei den Firmen nach, die Händeringend um Fachpersonal betteln?
Warum machen diese Firmen eigentlich nicht mehr Druck bei der Politik, damit so etwas eingedämmt wird?
Warum wird in einem “Informatik” Unterricht eigentlich nur Software eines Monopolisten beworben und eingesetzt?

MTA vs. Fedora

Ich durfte - vor sehr vielen Jahren (so um das Jahr 2007 herum) - einmal bei der Auswahl eines potentiellen Nachfolgers dabei sein.

F: “Schon mal einen MTA installiert und konfiguriert?”
A: (Stolz geschwellte Brust) “Japp.”
F: “Welchen denn?”
A: “Fedora.”
F: …
A: …
F: “Du weißt schon, was ein MTA ist?” A: (druckst herum)
F: …
A: (Kleinlaut) “Nein.”

Es nicht zu wissen ist das eine, denn daran kann man arbeiten.
Es nicht lernen zu wollen viel schlimmer. Denn damit haben wir alle verloren.

Mein letzter Counterpart, der noch weiß wie man einen DNS konfiguriert, geht.
Viele andere möchten Services nur noch benutzen. Oder einen Container starten, der einem den Service zur Verfügung stellt.
Die Konfiguration kommt dann magisch.
Getreu dem Motto, ‘der Strom kommt doch aus der Steckdose’ …

Container

Und mittlerweile werden ja Container für alles missbraucht.

Und das meine ich ernst, denn wenn jemand ein Standard Debian als Basis für einen Container benutzt um dort nur curl reinzuwerfen, damit man das so benutzen kann … dieser Mensch muss allen Ernstes den Verstand verloren haben!

Es ist ja nicht nur so, dass man plötzlich ein komplettes OS in einem Container benutzt, welches potentiell immer veraltet ist … Man baut sich ein 200MiB großes Monster um ein 203kib großes binary benutzen zu können …

Die wenigsten Entwickler beschäftigen sich mit dem “Innenleben” eines Containers, oder aber wer den Container gebaut hat. Oder wie alt der ist.
Man erschrickt nur, wenn man mal einen Security Scanner dagegen laufen lässt und denen die CVEs vor die Füße wirft …

Wir sind bei “hoffen und beten” angekommen

Heutzutage startet man einen Container und hofft, das er funktioniert.
Services wirklich konfigurieren kann man nicht mehr.
Oder will es auch nicht.
Oder aber man vertraut auf die Standardeinstellungen.
Dabei wird die Komplexität nicht geringer.
Eher das Gegenteil, sie steigt sogar von Update zu Update!

Diejenigen, die heutzutage kritische Systeme betreiben sollen, können nur noch yaml Dateien schreiben. Fehlermeldungen werden weitestgehend versteckt, oder sind kaum erreichbar, oder kryptisch und schwer lesbar.
Wichtige Systemupdates werden ignoriert (Wieso? Läuft doch.) oder aber weggeschoben (Was, schon wieder ein Update?)

Bin ich besser?

Sicherlich nicht!
Ich habe ein ähnliches Problem. Denn bei mir kommt mittlwerweile viel aus einer Automatisierung.
Installieren, Basis Konfiguration, läuft.
Dachte ich zumindest.

Bestes Beispiel für mich war Loki.
Ich habe dafür eine Ansible Rolle geschrieben, da wir Loki in einem meiner Projekte ausprobieren und benutzen wollten. Ich beließ es bei eine kleinen Standardkonfiguration. Der Service startete, man konnte ihn benutzen, alles war fein. Mitnichten, denn ein paar Monate später stellte man dann fest, das man die Historie so nicht benutzen konnte. Verbidungsabbrüche, Fehlermeldungen .. alles dabei.
Und wenig Zeit.

Ich habe mir dann 2 Tage Zeit genommen, habe die Dokumenation gelesen, mich mit den Fehlermeldungen beschäftigt, Lösungen gesucht. Im Endergebniss habe ich die Rolle so weit erweitert, dass der Service fast komplett konfigurierbar ist. Ich habe Tests geschrieben. Und ich habe Loki in dem Projekt soweit konfiguriert, dass wir jetzt die Logfiles der letzten 30 Tage anschauen können.

Entweder, wir nehmen uns keine Zeit mehr und uns mit komplexer Software und deren Konfiguration zu beschäftigen, oder wir bekommen diese Zeit nicht (mehr).

Beides ist auf lange Sicht nicht hilfreich.

Automatisierung

Ich bin ein großer Fan von Automatisierung.
Sie hilft mir bei meiner täglichen Arbeit.
Schafft für mich reproduzierbare Ergebnisse.
Wenn sie gut gemacht ist, kann sie mich in einem Desaster Fall unterstützen.
Das dadurch meine Kollegen meine Projekte ebenfalls betreuen könnten .. ist das nicht nur ein schöner Nebeneffekt sondern entlastet mich und ermöglicht es mir auch mich um andere Aufgaben zu kümmern, oder zu lernen.

Aber durch diese Automatisierung verlerne ich eben auch viel!

Meine Ansible Rolle für einen nginx liefert mir meine gewünschten VHosts in einer gleichbleibend (ggf. hohen) Qualität.
Aber diese VHost Dateien per Hand zu schreiben verlerne ich. Tritt irgendwo ein Fehler auf, muss ich zusehen woher der kommt und wie ich ihn beseitigen kann. Da hilft mir meine Automatisierung überhaupt nicht weiter.

Da hilft mir nur mein Wissen und meine Vergangenheit … ich kann eine Fehleranalyse durchführen und damit den Fehler auch beseitigen. (Manchmal ist es auch hilfreich zu wissen wo und wie man sucht. ;) )

Zusammengefasst

Wir haben aktuell eine hohe Fluktuation in der IT.
Es geht mehr Wissen, statt das es kommt.
Diejenigen, die einmal die Infrastruktur aufgebaut haben und Dinge wussten sind schon lange weg.

Wir etablieren bzw. verfestigen eine “Nach mir die Sinnflut” Mentalität.

Wir haben Berater die Buzzwords herunter beten. Die Hypes hinterherlaufen.

Wir haben Admine die mit einem Clusterupdate einen Totalverlust aller Services & Daten in Kauf nehmen.

  • “Ist halt Komplex.”
  • “Haben wir nicht testen können.”
  • “Oh, da gab es ein Breaking-Change?”
  • “Wer liest sich denn alle Changelogs durch?”
  • “Welcher Entwickler hat denn den Service X deployed, der wird seit 2 Releases nicht mehr unterstützt!?”

Admins, denen wir unsere Daten anvertrauen können nur noch yaml Dateien schreiben, denen aber das Wissen aber die Basics wie DNS, TCP/IP oder Netzwerke fehlen, die keine Ahnung von Latenzen haben, die nicht wissen was I/O ist.

Probleme werden mit noch mehr Services, sprich Komplexität, erschlagen. (Werft mal einen Blick auf die CNCF Landkarte!)

Das ist Fachkräftemangel auf einer ganz anderen Ebene.

Fazit

Docker, Container oder Kubernetes sind für mich nicht die Ursache von Problemen, sie stehen symptomatisch für sie.
Wer jetzt hier einen Rant gegen Container und Kubernetes herauslesen möchte … bitte sehr!
Aber derjenige hat den eigentlichen Grund meines Rants nicht verstanden .. der sollte noch einmal von vorn beginnen.

Und ich empfehle den Heise Kommentar Unterirdische Kubernetes-Qualität – Containerland ist abgebrannt. Der trifft eigentlich so ziemlich jeden Nagel.
Klassische Kubernetes Rants findes man eigentlich auch immer bei Fefe.
Der begründet sie - IMHO - dafür aber auch fachlich fundiert.

Alle von uns benötigten Services müssen noch immer installiert, konfiguriert und betrieben werden. Von Menschen, die sich damit auskennen. Die es aber immer weniger gibt.
Ich wünsche mir, dass dieser Typ Admin nicht ständig belächelt und in die Ecke gestellt wird, nur weil er über seinen Tellerrand hinaus blickt und vor den möglichen Folgen warnt.

Ich wünschte mir ein wenig mehr … Realitätsbezug.

This post is licensed under CC BY 4.0 by the author.