Neulich war es dann so weit, der erste KSK-Rollover stand an:

Nachdem mein Provider die in Rekordzeit weitergegeben hatte konnten die DNSSEC-Tools wie in der Doku beschrieben dazu gebracht werden, den Rollover abzuschließen:

Es kommt viel zu selten vor, daß mal was auf Anhieb funktioniert, wie es sollte - das hier war eine angenehme Ausnahme.

Im Gegensatz zu dem, was man im Netz so findet, ist es nicht korrekt, "set password/m5 null" zu nutzen. Richtig sieht es so aus:

Also "clear" statt "set ... null". Und man sollte mehr als einen Test-Durchlauf machen um zu sehen, ob die Konfiguration funktioniert, gerade "ins" und die Reihenfolge von "clear" und "set" können durchaus beim ersten Mal funktionieren, aber Mist bauen, wenn die Datei bereits angepasst wurde.

Guten Rutsch!

Für diejenigen, die Debian/stable aka squeeze benutzen und seit Kurzem ein Galaxy Nexus ihr eigen nennen: Keines der Musikprogramme (weder Banshee, noch Amarok, noch Rhythmbox) wird in der Lage sein, Eure Musik mit dem Device via MTP zu synchronisieren. Glaubt mir, ich habe so ziemlich alles versucht, was mir eingefallen ist:

1. Anlegen einer eigenen udev-Regel, damit das Ding für mich als User (und Mitglied der "audio"-Gruppe) beschreibbar ist, aka:
   CODE:
   echo 'SUBSYSTEMS=="usb", ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="685c", SYMLINK+="libmtp-%k", MODE="660", GROUP="audio"' >> /etc/udev/rules.d/51-android-rules udevadm trigger

   Danach funktioniert dann zwar "mtp-detect", aber die Player können immer noch nix damit anfangen.

2. Patchen der "libmtp8", damit sie das Device erkennt, aka:
   CODE:
   - apt-get source libmtp8 - apt-get build-dep libmtp8 - Einfügen der Zeile       { "Samsung", 0x04e8, "Samsung Galaxy Nexus", 0x685c, DEVICE_FLAG_BROKEN_MTPGETOBJPROPLIST_ALL },   an geeigneter Stelle in src/music-players.h - dpkg-buildpackage -rfakeroot

   Danach sagt "mtp-detect" zwar nicht mehr "Unknown Device" und Banshee hat auch tatsächlich einmal Dateien übertragen, aber keine Playlists - und es ging auch wirklich nur ein einziges Mal.

3. Aktualisieren der "libmtp8" (die "8" steht ja bekanntlich für den SONAME, also "libmtp.so.8" als Symlink auf "libmtp.8.0.3"), also zuerst auf die 1.0.6, da bleibt der SONAME der gleiche, dann auf die 1.1.1 aus Debian/unstable, da änder sich der SONAME, also auch Banshee nochmal neu gebaut -> erkennt trotzdem nix.
4. Banshee (und die halbe Distribution) auf die Version aus Debian/experimental aktualisiert, bringt nix.

Ich hab aufgegeben. Mit "mtpfs" kann man das Device mounten und per Hand Musik übertragen, aber keine Playlists. Mir wurde das dann zu doof und ich habe mich via offenem US-Proxy bei Google Music angemeldet (und danach mein Google-Paßwort geändert und die Session invalidiert!). Das Hochladen aller meiner Musik in die Cloud hat knapp eine halbe Stunde gedauert, danach war auf dem Handy noch einmal "Clear Data/Daten löschen" via App-Verwaltung für die "Musik"-Applikation angesagt, gefolgt von einem Verknüpfen des Google-Accounts via Musik -> Einstellungen, dann hatte ich Zugriff auf die Musik. Die Playlisten musste ich dann zwar einmalig neu machen, aber dafür habe ich sie jetzt auch überall zur Verfügung. Und da man Musik via WLAN auch gut offline verfügbar machen kann...

Ich hoffe, MTP bekommt jetzt mal etwas mehr Aufmerksamkeit, denn eigentlich ist das ein cooles Protokoll und auch die Tatsache, daß man den Speicher der Smartphones damit nicht mehr partitionieren muß ist ziemlich cool. Und kleiner Rant am Rande: Unter Windows 7 hat mit MTP auf Anhieb alles geklappt... mit Bordmitteln

Es ist schon lustig: In der Firma bin ich einmal im Monat in einem Meeting, bei dem es darum geht, nicht-sicherheitskritische Linux-Updates freizugeben, zu entscheiden, welche unserer selbstgebauten RPM-Pakete wir aktualisieren etc. (wir haben uns selbstironisch die "Linux Updates Group" getauft *g*). Verfügbare Sicherheitsupdates lösen in der Firma Reports via Mail aus, und der freie Satellite-Server "spacewalk" zeigt dicke, knallrote Ausrufezeichen für unsere CentOS-Systeme an, ebenso natürlich das echte RHN für die RHEL-Maschinen. Jedes Stück Software, bis hin zu Perl-Modulen aus CPAN oder Webanwendungen, ist in einer Liste vermerkt, wir vergessen da gar nichts. Und falls wir doch mal was vergessen stehen wir auf den Announce-Listen von mehreren Dutzend Projekten. Unter den Tisch fallen kann da kaum etwas.

Und privat? Distributionsupdates kriege ich natürlich mit, aber mir ist z.B. total entgangen, daß es für meine Webmail-Oberfläche oder auch dieses Blog hier Updates gibt. Na ja - jetzt ist alles aktualisiert, und ich stehe auch privat auf einem halben Dutzend announce-Listen. Noch mehr Mails, juhuu

Ich hatte diese Woche die Gelegenheit, mich mit einigen anderen IT'lern über Dinge auszutauschen, die wir so im Operations-Alltag erlebt haben. Besonders gerne höre ich natürlich immer Geschichten von Banken und Versicherungen, und ich bin da diese Woche nicht zu kurz gekommen. Deswegen, ohne weitere Einleitung:

1. Bei Bank Eins werden die Kosten, die Privatkunden für ihre Aktiendepots entstehen, einmal im Monat abgerechnet - die Daten werden dann dazu benutzt, die Gebühren via Bankeinzug (logisch!) einzusammeln. Für das Erstellen der Abrechnung wird allerdings nicht einfach auf das normale Reporting zugegriffen (die Daten über Aktienbewegungen etc. sind ja alle schon vorhanden, man muß sie nur auswerten) sondern eine speziell für diesen Zweck erstellte Software genutzt (die auch nichts anderes macht als die entsprechenden DB-Queries zu stellen). Diese Software ist auf einem einzelnen, nicht virtualisierten, Server installiert. Und wie sich herausgestellt hat gibt es zwar durchaus Backups von der Konfiguration des Servers und der Software, nur leider waren im K-Fall die Installationsmedien der Software nicht auffindbar oder die Software via Download beziehbar. Das Zusenden der Medien hat vier Tage gedauert.
2. Bank Zwei betreibt seit dem Jahr 2006 ein internes Controlling-System (irgendwas mit Kreditvergabe) auf einem Active-Passive-Cluster. Anfang des Jahres ist der aktive Knoten gestorben und der Umzug der Dienste auf den Standby-Server hat überhaupt nicht geklappt. Eine interne Untersuchungskommision hat herausgefunden, daß ein Umzug auf den Standby-Knoten noch nie - also nichtmal nach der Erstinstallation/Inbetriebnahme - getestet wurde.
3. Versicherung Eins hat über fünf Millionen Euro dafür ausgegeben um sich von einem Team externer Berater das Backup auf die IBM-Software Tivoli TSM umstellen zu lassen. Bestandteil des Vertrags war auch ein automatisiertes Monitoring und Alerting, damit man auch merkt, wenn das Backup einzelner Server fehlschlägt etc. Nach einer größeren SAN-Panne hat man bemerkt, daß viele der Backups, für die das Monitoring in der Vergangenheit "Backup OK" geliefert hatte, noch niemals ohne Fehler gelaufen waren. Es hat sich herausgestellt, daß das Skript, welches vom Monitoring aufgerufen wurde, um den Status eines Backup-Jobs zu ermitteln, von den externen Beratern anscheinend in einen Debugging-Modus versetzt wurde, in dem es stets "OK" zurückgeliefert hat.
4. Versicherung Zwei hat ein - nach ihren Maßstäben - kleineres SAN-System auf Hardware eines Herstellers, über den ich hier auch schon gebloggt habe, umgezogen. Nach neun Tagen ist das hochverfügbare System einfach aus gegangen. Nach Analyse kam man zu dem Schluß, daß ein Wackelkontakt in der SPS zu diesem Ausfall geführt hat. Der Ausfall wäre jedoch vermeidbar gewesen, hätte man auch wirklich alle Stromstecker des Systems mit den Steckerleisten im Rack verbunden und nicht nur die linke Seite.

Es ist schön zu sehen, daß wir, obwohl wir so klein sind, trotzdem ein soviel höheres Niveau halten können als Firmen, deren Monatsbudget für IT größer ist als das, was wir in einem ganzen Jahr ausgeben

Die Firma, für die ich derzeit arbeite, hat Niederlassungen in diversen deutschen Städten. Dort steht vor Ort zwar nicht wirklich viel Hardware, aber natürlich ist es gerade bei den Netzwerkgeräten notwendig, auf diese auch zugreifen zu können, wenn die Standleitungsverbindungen unterbrochen sein sollten. Um dies zu gewährleisten evaluiert ein Kollege derzeit Konsolenserver mit integrierten Modem. Und natürlich testet man in so einem Fall auch, ob selbige Einwahl via Modem auch zuverlässig funktioniert.

Nachdem der Kollege das also getestet hat und dabei eine Fehlerrate von über einem Drittel aufgetreten ist, hat er folgende sehr schöne Aussage getroffen:

Ich glaube, diesen Spruch werde ich mir auch aneignen

Ich war heute in Nürnberg auf der DOAG-Konferenz. Ziemlich viele gute Vorträge (da ich ja kein echter DBA bin sitze ich nicht so viel in den DB-, sondern eher in den Infrastruktur-Vorträgen), aber einer war eine echte Niete. Ein Conslutant hat vorgestellt, wie er und seine Kollegen einem bekannten deutschen Unternehmen, das wir im folgenden mal die Firma GmbH nennen wollen, dabei geholfen haben, ein Migrationsprojekt abzuschließen, das selbige Firma nicht alleine auf die Reihe gekriegt hat. Und irgendwie ist mir trotz Diskussion mit dem Vortragenden im Anschluß an dessen Präsentation immer noch nicht klar, was eigentlich der Verdienst besagter Beratungsfirma war.

Die beschriebene Situation war folgende: Migration von einem 3-Node RAC-Cluster mit 10.1.x.y auf einen 4-Node RAC-Cluster mit 11.2.x.y. Migration von alter auf neue Storage. Bisserl Kleinkram hintendran (geänderte ETL-Prozesse für das Data Warehouse etc.), aber nix weltbewegendes dabei. Was war passiert? Die Firma GmbH wollte hochverfügbare Storage, die schnell ist. Also redundanter Betrieb, aber die Verfügbarkeit sollte nicht durch ASM-Mirroring erreicht werden, sondern eben von der Storage kommen. Dummerweise waren die Leute, die die Storage gekauft haben, anscheinend nicht auf der Höhe ihres Jobs und haben eine Storage gekauft, die weder hochverfügbar noch schnell, dafür aber teuer war. Ferner hatte monatelang keine in der Firma GmbH den Arsch in der Hose, den Fehler einzugestehen und die Geschäftsführung um Geld für eine neue Storage zu bitten - und diesmal mit dem Hersteller zu vereinbaren, das man das Ding erst abnimmt, wenn man nachgemessen hat, das es schnell ist.

Fremdwahrnehmung: Die Consulting-Bude kam an, hat die Projektleitung abgesägt, viel Geld für eine neue, schnelle Storage ausgegeben, die vorhandene Storage für teueres Geld erweitert und die fehlenden HA-Features via teurem SAN-Virtualisierer nachgerüstet, womit das Ding dann schneller wurde, als man es jemals benötigt hat. Die IT'ler haben paar Nachtschichten geschoben (so what?). Und am Ende haben sie nach Stundensatz abgerechnet.

Eigenwahrnehmung: Die Consulting-Bude kam an und hat die bestehende Projektleitung bei der Ausarbeitung eines Notfallplans unterstützt. Im ersten Schritt wurde ein neuer Storage-Partner an Bord geholt, von dem man schnelle Storage sehen wollte - unter der Bedingung, daß man die alte Storage weiterverwenden kann. Ferner hat sie mit modersten Methoden des Projektmanagements die noch zu erledigenden Arbeiten parallelisiert (z.B. wurde der RAC-Cluster parallel zur Anschaffung der neuen Storage eingerichtet). Man hat klar kommuniziert und die bestehende Projektleitung hat die Führung des Projekts an die Conslutants abgegeben. Der Storage-Partner hat selbstlos zwei extrem schnelle Storages zur Verfügung gestellt, um die Migration zu beschleunigen, weil die Firma GmbH ihm auf Anraten der Consluting-Firma den SAN-Virtualisierer abgekauft hat. Selbiger Virtualisierer hat ermöglicht, daß man die bestehende Storage mitbenutzen kann (das waren ursprünglich zwei getrennte Systeme, die man dann zu einem zusammengefasst hat, um die Performance hinzubekommen - na ja, fast hinzubekommen, man musste da nochmal nachkaufen). Die Migration konnte durchgeführt werden, woraufhin die Geschäftsleitung der Firma GmbH, die toll mit den Conslutants zusammengearbeitet hat, sich dazu entschlossen hat, dem Storage-Partner noch eine der schnellen Storages abzukaufen (was für letzteren bestimmt total überraschend war!). Das ganze war nur durch die langjährige Erfahrung der Berater möglich - und durch den selbstlosen Einsatz der Mitarbeiter. Die Firma GmbH ist heute Referenzkunde bei besagtem Beratungsdienstleister.

WTF?

Es hätte alles so schön sein können: 4 Terabyte von einem Linux-Fileserver waren auf eine EMC Celerra zu migrieren. Wie gut, daß die Celerra für so einen Fall einen Mechanismus mitbringt, der das Problem in wenigen Minuten lösbar macht: Die Rede ist von „CDMS”, dem „Celerra Data Migration Service”. Dabei handelt es sich um eine Kombination aus einem speziellen Filesystem - dem „MGFS”, aka „Migration Filesystem”, welches „offline inodes” unterstützt - und im Hintergrund laufenden Prozessen. Das Zusammenspiel klingt dabei denkbar cool: Das neu angelegte MGFS wird von einem CDMS-Thread mit dem zu migrierenden Fileserver verbunden (letzerer darf die Daten dazu natürlich nur noch an die Celerra exportieren). Danach greifen alle Clients nur noch auf die Celerra zu. Im Hintergrund werden dabei auf dem MGFS transparent die Verzeichnis-Strukturen und alle Nutzdaten, die von Clients angefragt werden, angelegt. Wurde eine Datei zwar mal aufgelistet (z.B. durch ein ls auf das Verzeichnis), aber noch nie aufgerufen, so ist der Status des Inodes offline. Sobald die Datei gelesen wird, ist der Status online, weil sie ja wie erwähnt im Hintergrund vom Source-Server übertragen wurde. Die Celerra tritt hierbei also als NFS- oder CIFS-Proxy gegenüber den Clients auf - eine Migration ist somit in wenigen Momenten erledigt. Um das übertragen der Nutzdaten zu beschleunigen, kann CDMS im Hintergrund auch aktiv Daten mirgieren. Eigentlich, so sollte man meinen, eine sehr elegant Lösung.

Der Teufel steckt wie immer im Detail: Im Gegensatz zum Standard-Dateisystem UxFS hat der Code des MGFS leider ein paar Optimierungen für große Dateisysteme verpasst. Die Folge davon ist, daß eine im Speicher des DataMover vorgehaltene Cache-Struktur bei großen Dateisystemen vollkommen versagt, wenn es darum geht, freie Blöcke für Schreibrequests zu finden. Im Log sieht man dann die Nachricht:

Wenn diese Situation auftritt, so ist die Celerra erstmal mehrere Minuten lang (je nach Größe des Filesystems und dessen Füllstand) damit beschäftigt, die gesamte Platte zu durchsuchen, um freie Blöcke zu finden, wo sie Daten hinschreiben kann. In dieser Zeit blockieren so ziemlich alle anderen Threads, die auf dem Dateisystem was tun wollen. Bei uns wurde das ganze kritisch, sobald 2,7TB auf dem 6TB Filesystem alloziert wurden. Das fiese ist, daß diese Situation bei jedem Schreibrequests passieren kann, also nicht nur bei einem im Hintergrund laufenden CDMS-Thread.

Ein Workaround, um wenigstens die Migration noch zu Ende zu bringen, ist es, permanent Sparse Files zu erzeugen (512 Byte aus /dev/zero, dann 16MByte sparse, wieder 512 Byte etc.) - Skript dazu gibt es auf Anfrage. Nach Abschluß der Migration steht ja die Konvertierung von MGFS nach UxFS an, und auch hier kann man in besagte Situation fallen, so daß ein Vorgang, der sonst knappe 30 Sekunden dauert (aktuellen NAS-Code vorausgesetzt) auch gerne mal eine Stunde Zeit erfordern könnte - und evt. das Filesystem offline bringt. Nach der Konvertierung in ein UxFS wird ein paar Minuten lang der sog. „Cylinder Group bitmap cache” initialisiert, danach sollten die Probleme der Vergangenheit angehören.

Deswegen würde ich mir momentan gut überlegen, ob ich so eine Migration - bis zum Erscheinen eines Fixes im Code, den ich hier bekannt geben würde - derzeit durchführen würde, wenn große Dateisysteme betroffen sind. Ich selbst habe auf jeden Fall eine Woche lang einen total kaputten Schlafrythmus gehabt, weil ich meinem „Severity One”-Service Requests um die ganze Welt nachgereist bin. Am Schluß habe ich die ganzen in Amerika, Kanada und Australien sitzenden L2/L3-Supporter an ihren Telefonnummern erkannt. Und ich bin froh, daß der Wahnsinn zu Ende ist - ich habe das server_cdms server_2 -C filesystemname heute Nacht hinter mich gebracht und das UxFS hält bisher, was es verspricht, keine Hinweise mehr auf hashalloc-Probleme.

Rachmaninov, Klavierkonzert Nummer 3 - genau das richtige zum Abschalten

Ich glaube, hierbei...

15:47 <@name_changed> hua, hier wird gerade Desaster Recovery "geübt"
15:53 <@name_changed> spannend ja 0_0
15:54 <@name_changed> wir haben uns die Oracle 11g zerschrotet
15:56 <@name_changed> eins von frisch angelegten ASM volumes (multipathed) hat durch selfown auf die Flash Recovery Area geschrieben (2-Lun volume via LVM single pathed angebunden)
15:59 <@name_changed> tja, dummer manueller fehler... off-by-one error bei vielen /dev/mapper/mapth?p1 devices, das >xTB FRA Volume war vergessen worden mit auf mpath zu stellen (wegen LVM)
15:59 <@name_changed> es wäre das mpath(n+2)p1 gewesen
16:01 <@name_changed> der kollege dem das passiert ist den haben wir eben nach xxh recovery gegen seinen willen aus'm verkehr gezogen
16:03 <@name_changed> ich wette er schläft immer noch nicht
16:04 <@name_changed> aber wir machen jetzt halt mal nen live test wie lange band- backup zurückholen, restore und recovery wirklich dauert
17:49 <@name_changed> cite: jain, db ist wieder konsistent
17:49 <@name_changed> jetzt gehts ans feintuning, was kann man noch aus den tomcat logs usw. rausholen. die kür halt.
17:53 <@name_changed> band rücksicherung, restore und recover hat bis jetzt ~45h gedauert
18:53 <@name_changed> cite: DB: 2.xT, auf Dxxxxx und IBM Tivoli, aber frag mich nicht welche Tivoli Version
18:55 <@name_changed> cite: DB ist ne Hxx, xxx Core Xeon xxxG RAM
18:58 <@name_changed> hightower: crash war um ~xx:00h am Xxxxxxx
19:58 <@name_changed> cite: und wir sind nach aussen immer noch down
19:58 <@name_changed> $CHEF hat xx Pizzen kommen lassen

...kommt man ganz schön in's Schwitzen

Von eins bis zehn zählen, in ksh97, z.B. unter AIX 4.2.1, Stand Mitte 1997:

Und in bash 3.2.17 (z.B. auch auf dem Mac ab OSX 10.5.2), Stand mehr oder weniger „heute”:

Wie die Zeit vergeht...

Nachdem ich jetzt ja fast drei Wochen in Urlaub war habe ich vorhin gerade mal meine Firmen-Mails synchronisiert. Neben dem üblichen Tagesgeschäft fand sich da auch eine Mail, in der ein Kollege mir eine Anrufnotiz von einem EMC-Techniker hinterlassen hat - offensichtlich gibt es da ein kleineres diagnostisches Problem mit einer unserer Celerras (ich wette, die IPs sind einfach nicht für externes Relaying freigeschaltet, wir hatten die Dinger kurz vor meinem Urlaub in ein anderes Subnet umgezogen). Jetzt wollte ich also gerade mal in Powerlink nachsehen, ob besagter Techniker da einen Service Request eröffnet hat. Ergebnis:

Wo ist eigentlich der Facepalm-Smiley, wenn man ihn braucht? Christian, magst Du den Menschen mal zeigen, wie man einen "Sorry-Server" definiert?

Update: So das Tüpfelchem auf dem "i": Der Mail-Link zu Webmaster zeigt auf "root@localhost"...

(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. erhält 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 4 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 Ascbhluß zu kriegen: Ich kann mir auch gar nichts anderes vorstellen als IT-Operations: There's nothing like beating a server into submission.. Schönes Wochenende Euch allen!

Recht hat er Und Gottseidank isses bei uns ruhiger.

Update: Scheinen viele so zu sehen: