(Präambel: Falls wir, lieber Leser, derzeit oder in der Vergangenheit in der gleichen Firma arbeiten oder gearbeitet haben: Nichts hiervon ist persönlich gemeint. Nicht hier soll destruktive Kritik sein. Es gibt nur einfach viel, wo man hätte besser sein können oder werden.)

Meine ersten Erfahrungen mit IT in Unternehmen habe ich im April 2000 bei einem Ingenieurbüro in der Nähe von Ingolstadt gemacht. Meine eigentliche Aufgabe zu dem Zeitpunkt war die Gestaltung eines Intranets, aber wie das so ist wenn man jung, gierig und unerfahren ist habe ich natürlich auch in diverse andere Bereiche hereingeschnuppert. Das Unternehmen hat damals hautpstächlich eine CAD-Software namens CATIA auf IBM-Workstations unter AIX eingesetzt, aber auch Tools für die technische Berechnung und das Desgin von Oberflächen (Strak), welche dann unter Systemen wie IRIX oder HP-UX liefen. Daneben gab es natürlich noch die normalen Windows NT-Kisten für die Verwaltung und eine einzige Linux-Maschine (eben meinen Intranet-Server).

Und hier kommen wir gleich zu den ersten zwei Fehlern: Falsche/keine Frameworks und falsche Tools. Fangen wir beim Framework-Thema an: Ich habe damals angefangen, dieses Intranet zu entwerfen und kam dann relativ schnell zu dem Schluß, daß man da eine Authentifizierung für benötigt. Und ich schäme mich zu sagen, wie ich das damals erschlagen habe, aber ich muß es trotzdem erzählen (das ist so ein bißchen wie ein Besuch in einer Geisterbahn): Ich habe im PHP-Code einen smbclient-Prozess erzeugt, welcher sich mit einem Share verbunden hat - wenn das erfolgreich war, dann habe ich für alle weiteren Seiten den Usernamen und das Paßwort in einem versteckten Input-Feld weitergegeben. Im Klartext natürlich. Und während ich jetzt hier wieder aus meinem Loch im Boden hervor krieche können wir uns ja mal kurz überlegen, warum ich damals so einen Mist gebaut habe: Weil ich keine Ahnung hatte, was Session-Management ist. Und warum hatte ich das nicht? Weil ich nicht über den Tellerrand hinaus gesehen habe. Hätte ich mal nach links und rechts gekuckt, hätte ich auch damals schon Frameworks gefunden, die mir Session-Management, Datenbank-Connectivity etc. abnehmen. Und wäre wahrscheinlich um eine Sünde, die mich jetzt noch manchmal des Nachts schweißgebadet aufwachen lässt, ärmer. Auf Eure berechtigte Frage, wieso ich hier meine Jugendsünden nenne, möchte ich gerne mit “Weil der Mist immer noch passiert!” antworten. In den verschiedenen Niederlassungen des Eingangs genannten Ingenieurbüro passiert das genauso wie bei einem großen Automobilhersteller. Und in meiner jetzigen Firma haben wir einen wirklich begabten Programmierer, der hin und wieder erzählt, wie er die Anwendungen, die er gerade entwicklet, intern so abstrahiert. Und manchmal, wenn er mir dann z.B. erzählt daß er jetzt eigene Session-Handling- und Authentifizierungs-Klassen entwickelt hat, oder eine elegante Möglichkeit, mit einer Datenbank zu sprechen, da denke ich mir einfach nur: “Junge, mit jedem beliebigem MVC-Framework hättest Du Dir eine Menge Zeit gespart.” Und wenn ich sehe, wieviel Code und SQL-Abfragen unsere Azubis teilweise schreiben (gut, da sind auch berechtigte Dinge dabei, z.B. Auswertungen oder Reports), schätzie ich mich immer glücklich, wenn ich zu Hause mal in die Verlegenheit komme, eine Web-Applikation zu bauen und mir ein “ruby script/generate model” die schlimmste Arbeit abnimmt (und Rails ist hier nur ein Beispiel für ein Framework, sowas gibt es garantiert auch für PHP oder Java).

Die falschen Tools sind auch so ein Kapitel für sich. In meinem ersten Job habe ich z.B. via Cron-Job regelmäßig abgefragt, wieviel Speicher noch auf bestimmten NFS-Volumes frei ist und diesen Wert dann in eine Datenbank geschrieben. Daraus konnte man sich dann eine schöne Übersichtsseite rauslassen. Das klingt relativ harmlos, aber irgendwann kam dann die Anforderung, doch bitte eine Mail zu generieren, wenn kein Speicher mehr frei war. Und dann musste in den Cron-Job noch eine Möglichkeit rein, sich zu merken, wann die letzte Benachrichtigung erstellt wurde (damit man nicht alle 5 Minuten eine rausschickt). Und spätestens jetzt sollte jedem klar sein, daß ich hier damals das falsche Tool gewählt habe. Wenn ich es heute einfach und schnell erledigen wollte, dann würde ich Nagios oder Icinga nehmen. Für die Benachrichtigungen. Und vielleicht auch für das Erstellen von Graphen, es gibt ja schließlich Plugins wie n2rrd, nagviz etc. Und doch ist ach dieser letzte Schritt evt. schon wieder ein falscher, denn diese ganzen Graphing-Lösungen sind oft nur “drangedübelt” und oft muß man sich einen abbrechen, damit man aus den Checks vernünftige Performance-Daten kriegt. Wer sehen will, wie eklig das werden kann, dem schicke ich gerne mal den n2rrd-Code, mit dem wir zu einem gegebenen Zeitpunkt Filesysteme auf einer großen NAS-Appliance überwacht und gegrapht haben - ich würde einen nüchternen Magen empfehlen. Ziemlich oft fehlt für den Einsatz der richtigen Tools leider auch immer noch ein einheitliches Konzept, über Abteilungen hinweg. Team 1 erschlägt dann seinen Kram mit Nagios-Plugins, Team zwei nimmt MRTG, Team 3 füttert rrdtool per Hand und Team vier wünscht sich Cacti, hat aber niemanden, der einen Cacti-Server bereitstellen könnte (um beim Beispiel Graphing zu bleiben). Ja, machmal ist es toll, wenn ein einzelnes Tool verschiedene Aufgaben übernehmen kann. Aber nach 14 Jahren Linux weiß ich schon warum “one job, one tool” so lange überlebt hat. Die Unfähigkeit, sich auf einen kleinsten gemeinsamen Nenner bei der Toolunterstützung zu einigen ist etwas, was sich in den 11 Jahren, die ich im IT Operations-Betrieb bin, kein Stück geändert hat.

Diese Unfähigkeit hat etwas mit Kommunikation und Planung zu tun - und hallo, hier kommt der nächste Fail. Das klassische Beispiel dafür durfte ich entweder 2002 oder 2003 erleben, als sich eine Firma eine neue, große NAS-Appliance gekauft hatte, weil der Speicherplatz auf dem bisherigen Fileserver zur Neige ging. Aus Kostengründen hat man sich damals dafür entschieden gehabt, ein relativ kleines Modell besagter Appliance zu kaufen (war immer noch teuer genug), dessen Maximalausbau bei exakt dem doppelten Netto-Platz des alten Fileservers lag. Also alles gut? Mitnichten, denn sieben Wochen danach hieß es von seiten der Fachabteilungen, die mit Abstand den meisten Speicherplatz belegt hatten: “Ach übrigens, unser größter Kunde, die Oemcorp, steigt bis Jahresende auf Supersoft 2.0 um - da müssen wir mitgehen, und die größe der einzelnen Dokumente verdoppelt sich da ungefähr.” Übrigens einer der wenigen Momente meiner IT-Laufbahn, in denen mir vor Lachen die Tränen gekommen sind (lustige Momente - für mich - waren übrigens auch: “Auf dem Volume haben wir gar keinen Platz mehr, das hatte ich Dir doch vor sechs Wochen per Mail geschrieben.”, “Ein kompletter Restore dauert über 60 Stunden.” und “Von den Backups der Dateien in dem Pfad kann ich mindestens 23% nicht mehr herstellen.”). Das Thema Projektplanung ist auch so eines, daß ich noch nirgendwo habe vollständig funktionieren sehen. Bei großen Firmen (20000+) hat man zwar meist extrem detaillierte Projektpläne, dutzende Lenkungsausschüsse, ein großes Budget, ist aber auch fast immer auf externes Know-How angewiesen und die ganze Manpower verschwindet meistens irgendwo im Planungs-Overhead. Bei kleinen Firmen

  • na sagen wir mal so, die meisten, die ich kenne, hatten gar kein Projektmanagement (und damit auch keine Planung), das den Namen wert gewesen wäre. Und gerade kleine Firmen leiden extrem oft daran, daß Mitarbeiter oft in bester Einzelkämpfer-Manier ihre Projekte planen, mit Zeithorizonten, die für sie selbst realistisch sind, aber ohne zu berücksichtigen, daß andere Teile der Organisation ihre eigenen Projekte haben und deswegen auch wenig freie Kapzität. Bei ganz kleinen Teams ist das kein Problem, bei größeren Teams wird es hin und wieder unangenehm. Ein gutes Beispiel ist mir selbst erst vor kurzem passiert, als das Netzwerk-Team ein Renumbering vorgeschrieben hat, daß sich direkt mit einem Livegang überschnitten hätte. Ironisch ist das vor allem, weil wir uns eigentlich einmal im Monat zusammensetzen, um uns zwischen den Fachbereichen auszutauschen - was dann schon die Frage aufwirft, wie effektiv diese Meetings einmal im Monat sind.

Worin ironischerweise ausgerechnet IT-Operations-Teams regelmäßig versagen ist übrigens auch die Fähigkeit, mal einen Schritt zurück zu treten und bestehende Strukturen und Abläufe kritisch zu prüfen. Besonders paradox dabei ist die Tatsache, daß die Wahrscheinlichkeit, mit der man ein bestehendes System (oder auch nur eine bestimmte Konfigurationseinstellung) verändert, immer kleiner wird, je länger das System in Betrieb ist - wo eigentlich klar sein müsste, daß es sich genau anders herum verhalten müsste. Ich hatte 2004 mal ein Shellskript geschrieben, das für den Datenaustausch auf einem Multi-Homed-Host vorgesehen war. Das ganze war eine extrem hässliche Krücke (obwohl der Code in Ordnung war, ich meine eher das Konzept) und war für eine Übergangsfrist von vier bis sechs Wochen gedacht. Ihr könnt Euch mein Entsetzen vorstellen, als ich 2006 wieder in dieselbe Firma kam und besagte Krücke - symbolisch gesprochen

  • bei einem 100m-Hürdenlauf beobachten durfte. Jetzt könnte man vermuten, daß das einfach funktioniert hat und es darum jeder vergessen hatte - dem war aber nicht so (was wiederum nicht am Skript, sondern am Datenvolumen und der vorhandenen HW lag). In einer anderen Firma hat man knappe 100 Server via NFS an einen zentralen Fileserver gehängt - und als Mount-Option “soft” gewählt. Weil die Applikationen auf besagten Servern nämlich auch Datenbank-Sessions offen hatten. Hängender NFS-Mount = hängende Datenbank-Session, das schaukelt sich auf. Der Logik kann man im Prinzip folgen - nur hatte sich nie jemand ernsthaft die Mühe gemacht zu untersuchen, wie man “hängende NFS-Mounts” in den Griff kriegt (was nicht weiter schwer ist, besagte Firma hat heute Oracle-Voting-Disks auf NFS). Der Grund war, daß besagter Fileserver ein echter Datenschatz ist und sich einfach nie jemand rangetraut hatte. Ich überlasse es jetzt Eurer Phantasie, wie oft man bei “soft”-Mounts I/O-Fehler hat oder manuell intervenieren muß. Wahrscheinlich hat diese gewisse Trägheit was mit der Art und Weise zu tun, wie die Operations-Teams normalerweise psychologisch funktionieren (Beständigkeit, stabile Umgebungen, Change nur bei klaren Vorteilen etc.).

Der Ehrlichkeit halber muß man sagen, daß es bei vielen der hier erwähnten Firmen eigentlich trotzdem ganz angenehm war - und gerade mein gegenwärtiger Job ist ziemlich gut, von den oben erwähnten Dingen sind wir da deutlich weniger betroffen als anderswo - was nicht heißt, daß wir nicht besser werden könnten (und ich bin überzeugt, daß wir das auch werden!).

Und um den Abschluß zu kriegen: Ich kann mir auch gar nichts anderes vorstellen als IT-Operations: There’s nothing like [beating a server into submission] (http://thedailywtf.com/Articles/Beaten-Into-Submission.aspx"). Schönes Wochenende Euch allen!