User Tools

Site Tools


ignaz:blog:it:wie_man_automatisierung_falsch_macht_01.08.2018

Wie man automatisierung falsch macht

Es gibt viele Möglichkeiten was bei der Einführung von Automatisierung schief laufen kann, aber ein Paradebeispiel ist die Verwendung von Automatisierung für Server/Client Management mit generischen Linux Distributionen

  • “Es geht schneller”
  • “Es ist einfacher”
  • “Wir brauchen etwas, dass out-of-the-box läuft”
  • “Wir möchten da nicht viel Zeit mit verschwenden”
  • “Das machen alle so”

Stellen Sie sich vor, Sie sitzen in einem Unternehmen das Linux Desktop Systeme einsetzt. Dann werden Sie wahrscheinlich auf Ubuntu/Debian, SuSE oder Red Hat treffen.

Dann ist Ihnen bestimmt schon aufgefallen, dass der PC bei Ihnen auf der Arbeit nicht selten schlechter funktioniert, als der Linux Desktop zu Hause.

Häufig ist aber auch die Software veraltet, die Software die Sie benötigen gibt es garnicht, das System ist extrem starr und unflexibel was den Desktop angeht u.s.w.

Das Ergebnis sieht dann in vielen Unternehmen gleich aus: Die Mitarbeiter sind weniger produktiv, weniger motiviert und die Admins sind schlecht gelaunt weil man viele Anfragen mit “Nein, geht nicht” abweisen muss und sich beide denken “Natürlich geht das eigentlich, aber halt nicht jetzt, nicht hier, nicht in diesem Netzwerk”.

Der Vergleich mag etwas unfair klingen, denn Ihr System zu hause ist natürlich genau auf Ihre Bedürfnisse optimiert und muss nicht für 20 Unterschiedliche Anwendungsfälle herhalten.

Denn sowas ist ja in Unternehmen nicht möglich, stimmts? Da sind sich alle einig, natürlich stimmt das. Man kann ja nicht jedem Anwender ein System auf seine Bedürfnisse hinstellen, das wäre ja garnicht wartbar.

Nachdem aber genau das 2 Jahre lang mein Job war kann ich sagen, _doch_ es ist Wartbar, Meta-Distributionen wie Gentoo sind viel einfacher, schneller und leichter zu warten als jedes generische System. Der Anwender hat genau das was er will, der Admin kann es ihm mit einem Lied auf den Lippen anbieten, klingt fast wie im Paradies.

Selbstverständlich sind auch Meta-Distributionen Grenzen gesetzt, der PC im Büro ist und bleibt ein Arbeitsgerät und sollte auch von allen Seiten genau als solches angesehen werden.

Aber das kann ja garnicht sein mag sich jetzt der ein oder andere Leser denken, wieso tut es dann nicht jeder?

Und genau das, ist eine sehr komplexe Frage, wieso macht es eigentlich keiner so.

Ein Häufiger Grund ist zum Beispiel: Als die Systeme eingeführt wurden, gab es keine Automatisierung und zwar wirklich gar keine, nichts, niada. Es gibt Admins, die haben noch nie in ihrem Leben von etwas wie ClusterSSH gehört und es gab auch nie genug Rechner, dass das wirklich notwendig war.

Und ganz ohne Automatisierung machen Meta-Distributionen einfach keinen Sinn, das ist wirklich unwartbar.

Und hier kommt auch der größte Fehler den man allgemein bei Automatisierung machen kann und zwar, dass man die Systeme genau so automatisiert wie sie jetzt sind.

Die Automatisierung eröffnet einem eine ganz neue Welt von Möglichkeiten, wie eben der Einsatz von Meta-Distributionen. Plötzlich sind Dinge möglich, die vorher undenkbar waren.

Man hat die Chance, alles auf ein ganz neues Niveau zu heben. Mehr Flexibilität, mehr Funktion, mehr Leistung.

Aber man nutzt es nicht, die meisten Firmen optimieren ihre Prozesse und Abläufe nicht darauf, dass sie sich möglichst gut automatisieren lassen, sondern man Automatisiert genau das, was man jetzt auch hat.

Egal ob Virtualisierung, Storage/Archiv, Backup oder eben Linux Desktops, es bleibt alles genauso wie es ist (egal ob sich das gut automatisieren lässt oder nicht), und legt da dann das Automatisierungstool darüber.

Nach spätestens 2 Jahren stehen die meisten Unternehmen vor dem selben Problem, ein unwartbares Konstrukt.

Ein Update der Automatisierungs Software ist praktisch nicht mehr möglich und ein Update der Serversoftware, die man in Liebevoller Kleinarbeit über Wochen automatisiert hat erst recht nicht, andernfalls ist die ganze Automatisierung im Eimer.

Aber woran liegt das?

Eine Meta-Distribution ist Modular und ausschließlich durch Konfigurationsdateien definiert.

Das heißt automatisiere ich eine Meta-Distribution, baue ich mir Textdateien zusammen und kopiere die auf den Client, ende der Geschichte.

Ganz anders ist es mit einfachen, generischen, out-of-the-box Distributionen, diese sind ein zusammenhängendes Konstrukt an Software und dieses muss in praktisch allen fällen komplett, als Einheit, automatisiert, gewartet und aktualisiert werden.

Man kann nicht einfach ein Postfix Modul bauen, dass eine bestimmte postfix Version installiert, konfiguriert und wartet, denn postfix ist Bestandteil der Distribution und die Distribution bestimmt welchen postfix man hat. Und wenn es ein Distributionsupdate gibt, wird der postfix mit geupdated, ob man will oder nicht.

Und die Distribution updated nicht nur den Postfix, es gibt ein Release und es wird alles geupdated.

Je nach Distribution darf man im Schnitt alle 2 Jahre nochmal alles komplett neu automatisieren, auf einen schlag, am Stück.

Und wehe die Automatisierungssuite hat für ein neues Feature der Distribution kein fertiges Modul (*hust* KDE Neon *hust*), dann geht das manuelle “rumgefrickel” los. Und wenn man das mal über 2-3 Release Updates macht, geht spätestens dann garnichts mehr.

Dann hat man einen unwartbaren Wulst aus Workarounds mit so viel Handarbeit, dass man inzwischen weniger Arbeit gehabt hätte, wenn man von Anfang an alle Systeme einzeln, wie Früher©®™, mit ClusterSSH automatisiert hätte.

Wenn man automatisiert heißt das, dass Automatisierungslösung und System zusammen passen müssen. Mit SCCM kann man nur bedingt Linux Clients verwalten, mit dem Citrix XEN-Center kann man kein VMware Server verwalten u.s.w.

Davon abgesehen, dass sich XEN-Server, VMware ESXi & Co. nur sehr bedingt und unter widrigen Umständen automatisieren, genauso wie eine NetApp.

Das ganze hat auch seinen Grund, der Hersteller hat selbst ein Tool für diesen Zweck entwickelt und Sie sollen es kaufen.

Natürlich geht es auch mit drittlösungen irgendwie, irgendwann, aber ich kann aus Erfahrung sagen, dass sich der Aufwand nicht lohnt. Da reicht ein Update vom Hypervisor und man verschwendet Wochen damit, die Playbooks an den neuen Hypervisor anzupassen damit die Automatisierung wieder läuft.

Wenn das am Leben halten der Automatisierung mehr Aufwand kostet, als die Handarbeit, lohnt es sich einfach nicht mehr.

Und genau das ist das Problem: Häufig fehlt einfach die Struktur. Für die meisten heißt es: Das Einführen von Automatisierung bedeutet die Installation einer neuer Software, das hat ja überhaupt nichts mit der Software zu tun die man bereits einsetzt.

Jetzt gibt es bestimmt den ein oder anderen, der sich fragt wie, dass dann große Unternehmen machen… naja, die kämpfen mit genau diesen Problemen.

Google ging soweit, dass sie ein eigenes System auf Basis von Gentoo entwickelt haben, aber grundsätzlich jedem Mitarbeiter die Freiheit geben sich zu installieren was er möchte. Nicht selten Kämpft man gegen Windmühlen oder Entscheidungen werden schlichtweg politisch getroffen.

Andere Unternehmen leben einfach mit den Einschränkungen und der geringeren Produktivität ihrer Mitarbeiter, das ist jedoch kein Grund den Kopf in den Sand zu stecken und ganz aufzugeben um möglichst wenig Arbeit zu haben.

Aktuell im Trend ist zum Beispiel, dass die Anwender sich mit Hilfe von Docker eigene Systeme bauen und sich so behelfen.

Ich kann mich noch gut an einen Fall erinnern, in dem ein Anwender auf dem Server Python3 haben wollte (was es unter RHEL aktuell offiziell nicht gibt) und die ““Lösung”” war dann, dass er es sich in einem Docker Container einfach selbst eingerichtet hat. Die denkbar schlechteste und vor allem unsicherste Lösung von allen, aber der Anwender muss halt auch irgendwie arbeiten.

Ich könnte noch einige mehr Beispiele nennen (eine Anwendung die eine spezielle Perl Version benötigt hat, eine Legacy Anwendung die eine spezielle glibc Version benötigt hat und und und).

Flexiblität, für alles, egal was kommt, gewappnet zu sein, ist ein unschätzbarer Vorteil den eine Meta-Distribution mit Automatisierung mit sich bringt.

Was genau heißt das jetzt? Alles über Bord werfen und neu machen? Natürlich nicht.

Das heißt nur, dass man nicht krampfhaft alles automatisieren muss was im Netzwerk kreucht und fleucht. Eine Automatisierung ist eine Sache die Monate oder (je nach Netzwerk) bis zu einem Jahr oder mehr in Anspruch nehmen kann.

Automatisierung macht nur Sinn, wenn sie nachhaltig ist.

ignaz/blog/it/wie_man_automatisierung_falsch_macht_01.08.2018.txt · Last modified: 2018/09/17 18:44 by vamp898