Dirks Logbuch

Ja, solche Jobs gibt es wirklich.

Vor 100 Jahren bekam ich mal Anrufe von wildfremden Menschen, die gehört haben, dass ich "mit Computern umgehen könnte". Ich helfe ja gerne, aber als ich gemerkt habe, dass das einen Umfang von zwei bis drei Stunden pro Tag angenommen hatte, habe ich Geld gefordert.

Von Heute auf Morgen hörten die Anrufe auf, als ob die sich abgesprochen hätten.



Vielen Dank an CommitStrip.

Ich alleine kenne schon fünf Definitionen für den Begriff DevOps, aber diese hier, die ich in dem Artikel Coworker der GarageBilk Teil 35 – Das Team von Uberspace.de (Vorgriff auf den kommenden Linkdump) gefällt mir am Besten und beschreibt auch das, was ich unter DevOps verstehe:

Das bedeutet für uns DevOps: Wir entwickeln unsere Infrastruktur mit den Methoden weiter, die in der Software-Entwicklung erdacht wurden.

Hier im Blog war das schon öfter Thema, es gibt eine Reihe an anderen Beschreibungen.

Aus aktuellem Anlass muss ich noch einmal auf Bandbreite und Latenz herumreiten und vielleicht noch hinzufügen, dass auch die Anzahl der Anfragen durchaus eine Rolle bei Performance-Betrachtungen spielt.

Wir hatten hier auf einem System massive Performance-Probleme und ich habe relativ schnell herausgefunden, dass ein bestimmter User und von diesem ein bestimmter Prozess für einen grossen Teil der Festplattenlast verantwortlich ist.

Der Applikationsbetreuer war der Meinung, dass das nicht sein könne, da der Teil der Applikation kaum bzw. nur sehr wenig schreibt. Das stimmt, er hat wirklich nicht viel geschrieben, aber dafür wenige Bytes und diese sehr häufig. Das hat die IO-Queue gefüllt und weitere Zugriffe blockiert.

Einige Zeit später hat der Betreuer einfach mal den Prozess beendet und siehe da, die Performance der übrigen Komponenten war sehr hoch.

Lehre, die man daraus ziehen sollte: Glaubt keinem Applikationsbetreuer!

Nein, im Ernst: Es ist wichtig, dass man genau weiss, was eine Applikation tut und noch wichtiger ist es, Performance nicht alleine am Durchsatz fest zu machen. Latenz und Anzahl der Requests spielen ebenfalls eine Rolle.

Ein Arbeitskollege wies mich heute auf den Artikel Die unheimlichen Götter im Tagesanzeiger hin. Der Artikel thematisiert etwas, was schon lange bekannt ist und nie bestritten wurde. Allerdings muss darüber im Umfeld der verschiedenen Affären rund um Bespitzelung noch einmal gesprochen werden. Menschen, die Vollzugriff auf Systeme haben, können ihre Rechte auch missbrauchen.

Einige Firmen haben das bereits erkannt und verlangen aus diesem Grund ein (polizeiliches) Führungszeugnis bzw. Führungszeugnis (Schweiz) oder Strafregisterbescheinigung (Österreich). Das ist zwar nicht ausreichend, aber schon einmal ein Statement. Wenn man wegen Computerkriminalität vorbestraft ist - zählen eigentlich illegale Kopien dazu? - dann wird es schwierig, einen Job in solchen Firmen einen Job zu finden.

Ich halte den Systemadministrators' Code of Ethics für wichtig und ich erwarte, dass jeder, der professionell IT betreibt auch dahinter steht. Den Verhaltenskodex habe ich für unser Buch übersetzt und als Richtlinie auch bei My own IT eingesetzt.

(Vielleicht lohnt es sich auch, hier im Blog mal nach "ethics" zu suchen).

Nachdem ich via Michael Kofler von der Nachricht hörte, dass Pearson die IT-Fachbuchsparte (und damit auch Addison-Wesley Fachbücher) einstellt, habe ich mir noch schnell eine Kopie DES Standardwerkes der Systemadministration auf totem Baum gesichert.

Das Buch deckt alle Bereiche der Systemadministration ab, ohne dabei Betriebssystemspezifisch zu sein. Es geht vielmehr um praxisorientierte Tipps, wie man sich nicht selber ins Bein schiesst.

Das Buch "The Praxis of System and Network Administration" ist auch als TPOSANA bekannt und geschrieben von Tom Limoncelli.

Bei meinem vorherigen Arbeitgeber hatte ich via Safari Books Zugriff auf die digitale Version.

Im Rahmen unserer Suche nach einem neuen Kollegen bin ich das eine oder andere Mal gefragt worden, was einen Senior zum Senior macht. Das das Kürzel vor der Berufsbezeichnung nicht mit Rente zu tun hat, war allen klar.

Die Core Job Descriptions auf der Seite der SAGE geben schon einmal eine Idee, wie eine mögliche Definition für Administratoren aussehen kann. Mir fällt gerade ein, dass ich auf der Ubucon 2009 einen Session zu Praktischer Administration gehalten habe, Video ist dort auch verlinkt.

Die Titel "Novice", "Junior", "Intermediate" ("Advanced") und "Senior" finden sich so oder ähnlich für verschiedene Berufe in der IT-Branche. Bei manchen kommen noch "Principal" oder "Leading" (und ein paar andere mehr) dazu, dafür ist mir in "freier Wildbahn" noch nie ein "Intermediate" bzw. "Advanced" Typ in den Weg gelaufen. Halbwegs standardisiert ist meines Wissens nach nur der Titel "Senior".

Abgesehen von den dort beschriebenen technischen Fertigkeiten gibt es nicht fachliche Anforderungen, die meiner Erfahrung nach fachbereichsübergreifend gefordert sind bzw. Gebiete, die für alle Stufen definiert sind.

Zum einen spielt die Grösse der Umgebung und die Komplexität eine Rolle, mit steigendem "Level" steigt auch die Komplexität der betreuten oder entwickelten Umgebung und ebenfalls die Grösse, unabhängig davon ob der Beruf der eines Administrators, Engineers oder Architects ist.

Weiterhin steigt auch die Berufserfahrung je weiter es in Richtung Senior geht. Achtung: Das ist bezogen auf das Fachgebiet. Jemand der Senior Systems Administrator ist, kann sich nach einen Wechsel des Arbeitsfeldes als Junior Projektmanager wiederfinden.

Was auf den ersten Blick überraschen mag, ist, dass Kommunikation unglaublich wichtig ist. Wissensarbeiter in der IT müssen viel kommunizieren und das in Wort und Schrift, in unseren Breiten meist zweisprachig in Deutsch und Englisch. Untere Level sollen sich klar und verständlich ausdrücken können, von höheren Leveln wird erwartet, dass sie auch komplexe Sachverhalte darstellen können und eventuell Fachpublikationen (Artikel in Zeitschriften, Büchern, ...) und eventuell Vorträge auf Veranstaltungen bereits vorzuweisen haben.

Lastly not leastly steigt die erwartete Selbständigkeit der Mitarbeiter. Während es zu Beginn noch in Ordnung ist, wenn durch Anleitung und Nachfragen gearbeitet wird, steigen die Anforderungen später deutlich an. Dazu gehört, dass vielleicht nur Arbeitsaufträge gegeben werden und dass der Beauftragte eigenständig mit einer selbständig erarbeiteten Lösung des Auftrags zurückkommt. Gerade dieser Punkt zeigt auch, wo die Arbeitgeber eher bereit sind, Homeoffice zu gewähren.

Wie weiter oben beschrieben, sind das Erfahrungswerte, die fachbereichsunabhängig sind. "Your mileage may vary" - Ihr könnt andere Erfahrungen gemacht haben und ich freue mich über Eure Erfahrungen in den Kommentaren zu lesen.

Schon öfter habe ich auf Veranstaltungen erwähnt, dass Administratoren ein Wahrnehmungsproblem haben, weil sie erst dann bemerkt werden, wenn etwas nicht läuft.

Der Artikel The problems of operations and sysadmin heroism fasst das sehr gut zusammen:

If you (sysadmin) are rewarded for cleaning up after floods but not recognized for building flood prevention instead, pretty soon you start losing enthusiasm for trying to argue your bosses into funding that flood prevention. And in a real way this is a lot like the devops blame problem; when you (boss) reward some things and penalize others, you have told operations what your priorities are whether you like it or not.

Übersetzt in etwa: "Wenn Du (Sysadmin) dafür belohnt wirst, nach einer Flut aufzuräumen und es noch nicht einmal bemerkt wird, wenn Du Vorkehrungen zur Flutvermeidung triffst, [...] wenn Du (Chef) einige Dinge belohnst und andere bestrafst, dann ist klar, welche Prioritäten Du setzt, ob Du es magst oder nicht."

Einmal mehr ein sehr guter Artikel von Kristian Köhntopp, wer ihn nicht im Feedreader hat, trägt selber Schuld. Der Artikel erläutert sehr gut, dass universitäres Wissen oft an der Praxis scheitert:

Junger Informatiker, hoffnungsvolle Uni-Abgängerin! Hier ist, was Dich in Deinem Beruf erwartet: Du wirst mit altem Code zu tun haben, der offensichtliche Schwächen hat. Du wirst mit Werkzeugen und Umgebungen arbeiten müssen, die Deiner Meinung nach nicht Stand der Technik sind. Eine Deiner Hauptaufgaben wird sein, den alten Code zu refaktorieren. Dabei wird die Zeit nicht reichen, diese Aufgabe zu Ende zu führen. Du wirst die Versuchung verspüren, den alten Kram wegzuwerfen und auf der grünen Wiese neu anzufangen.
[...]
Eine der Aufgaben, die eine Firma lösen muß, wenn sie junge Informatikerinnen und Uni-Abgänger einstellt, ist sie zu deprogrammieren. Ihnen die Flausen aus dem Kopf zu pusten, die ihnen das Uni-Studium in den Kopf gesetzt hat. Sie mit den Realitäten der Welt vertraut zu machen. Und sie zu lehren, daß so wenig wie die wenigsten Städteplaner und Landschaftsarchitekten mit einem leeren Plan anfangen können, die wenigsten Softwarearchitekten und Entwickler mit einem leeren Editor starten.

Das gilt analog für Administratoren oder System Ingenieure genauso. Es gibt Gründe warum eine Umgebung so aussieht, wie man sie vorfindet.

Allerdings heisst das nicht, dass man seine Ideen nicht äussern sollte. "Frisches Blut" ist wichtig, um bestehende Strukturen in Frage zu stellen. Manchmal sind Vorbedingen, die zu einer "Architektur-Schleife der besonderen Art" geführt haben, gar nicht mehr gegeben und dann ist es gut aufzuräumen.

Passend dazu gab es in der letzten Woche schickes Bild bei Geek and Poke.

Mann, Mann, Mann ... es kann auch manchmal echt bescheuert laufen. Ich lächelte und ich war froh und es kam schlimmer.

In der letzten Woche hatte ich Bereitschaft (hier in der Schweiz nennt man das Pikett), was "normalerweise" kein Problem ist. In guten IT-Umgebungen sind Bereitschaftsdienste eine Rückversicherung für Fälle, die "eigentlich" nie eintreten. So ist es auch normalerweise. Nur eben in der letzten Woche nicht.

Ich bin zwei Mal nachts um drei Uhr und einmal um viertel vor eins aus dem Bett geholt worden, ärgerlicherweise immer für Fälle für die unser Team nicht verantwortlich ist. Na, ja, man kann nicht immer Glück haben. Bei uns ist es so, dass der Bereitschaftshabende im Normalfall die Änderungen an Produktionssystemen durchführt, was zu einem durchgearbeiteten Samstag geführt hat. Alles für sich genommen, ist das kein Problem, ich kann mich in der Woche eh nicht weit von zu Hause entfernen, da ich eine halbe Stunde Reaktionszeit habe, aber die letzte Woche war zu extrem.

Ins Herz geschlossen habe ich den Kollegen, der mich am letzten Montag direkt nachdem ich das Haus verlassen habe, auf dem Bereitschafts-Mobiltelefon erreicht hat und mich bat einen Produktionsserver neu zu starten. Das machen wir nicht auf Anruf, da muss schon eine bestimmte Prozedur eingehalten werden, sonst könnte ja jeder kommen. Auf diesen Kollegen habe ich über eine Stunde gewartet bis ich genervt nach Hause gegangen bin. Am nächsten Tag habe ich dann erfahren, dass es wohl nicht so wichtig war.

Grrr! Ich muss auch mal quengeln

Selten habe ich das Telefon so gerne weiter gegeben, wie nach der letzten Woche.

Das Thema Bereitschaft könnten wir eigentlich mal in den Adminstories behandeln.

Heute mal aus der Reihe "Dinge, die wir schon immer wussten, aber nie umgesetzt haben". Wir haben einen Monitoring-vServer, der für verschiedene Domains und Server das Monitoring übernimmt (möchte noch jemand teilnehmen? Ist gratis). Das Monitoring wird gemacht mit Icinga, Munin und Smokeping, manche nutzen nur Icinga, andere auch die anderen beiden Tools.

Der vServer läuft so vor sich hin und stört niemanden. Heute habe ich Icinga aktualisiert und "für Spass" in die Mail-Queue geschaut und gesehen, dass nur rund 1200 Mail aufgelaufen sind. Super!

Nein, ich mache das nicht beruflich ... gerade im Moment könnte ich in den Boden versinken.

Also: Der Monitor-Server muss natürlich auch überwacht werden und zwar so, dass man Fehler auch feststellen kann, ohne dass man ständig draufschauen muss..

Volkmar Kreiss hat alles, was machbar war aus den zum Teil defekten Bändern herausgeholt und meinen Workshop von der Ubucon 2010 zum Thema Zeitmanagement für Systemadministratoren zusammengeschnitten. Der Workshop war zwei Stunden und 47 Minuten sind im Zusammenschnitt zu sehen.

Vielen Dank Volkmar!

Ich bin gerade fasziniert davon, dass ich heute noch das Gleiche sagen, aber einige Dinge anders machen würde.

Damit wäre auch der Rekord geknackt, das habe ich vorher noch nicht gesehen.

root@host:/home/user# w
  1:48pm  up 400 day(s), 23:14,  2 users,  load average: 2873.31, 2827.64, 2756.47
User     tty           login@  idle   JCPU   PCPU  what

Die Maschine, ein Clusternode unter Solaris 10 mit 128 GB RAM und 128 Cores war noch zugreifbar. Was die load average ist, werde ich mal drüben in den Administories erklären.

Der Kojote: Admins wollen als Volksgruppe anerkannt werden

„Die Admins erfüllen alle Voraussetzungen des EU-Abkommens zum Schutz nationaler Minderheiten“, sagt Schlotz (der Sprecher von Server e. V.). „Sie leben in angestammten Siedlungsgebieten, den Serverräumen, sie pflegen eigene Bräuche wie Linux-Distributionen und sprechen eigene Sprachen wie Perl oder PHP.“ Als anerkannte Volksgruppe würden Admins besonderen Schutz des Staates genießen. Dazu gehörten beispielsweise die Befreiung ihrer Parteien von der 5-Prozent-Hürde und zweisprachige Straßenschilder. Eine radikale Minderheit unter den Admins geht gar noch weiter: Sie will eine umfassende Autonomie – und dazu Deutschland in zwei Partitionen aufteilen.

via netzpolitik.org

Der Artikel hier illustriert nahezu perfekt, was mit Kenne Deine Werkzeuge aus dem AdminZen gemeint ist.

Und da hat es mir in dem genannten Zusammenhang vor allem Punkt sieben angetan, "Nutze keine Werkzeuge, die Du nicht handhaben kannst". Vermutlich hätte ich bei besserer Kenntnis Eclipse bzw. TeXlipse so zurecht biegen können, dass es die geforderte Aufgabe, das schnelle Editieren von Text mit Syntax-Highlighting, auch zufriedenstellend gelöst hätte. Da ich mich aber nicht so gut auskannte, hat das nicht funktioniert.

Das beste Werkzeug aus meinem Werkzeugkasten war für diesen Fall vim, was mir - weil ich es zwar nicht perfekt, aber dennoch besser als Eclipse/TeXlipse kannte - einige Arbeit erspart hat.

Manchmal werde ich gefragt, wie man ein (guter) Administrator werden kann. Ich mag solche Fragen, da ich mich auch gerne mit den "Meta-Themen" der Administration beschäftige. Aus diesem Grund halte ich darüber auch Vorträge. Neben der Tatsache, dass man bereit sein muss, eine Menge Zeit zu investieren und Faul zu sein gibt es noch einen wirklich wichtigen Punkt:

Einfach machen!

Es gibt mittlerweile so viele kostengünstige und auch kostenlose Virtualisierungsmöglichkeiten, dass es keine Entschuldigung gibt, nicht auszuprobieren und zu testen. Schwimmen und Rad fahren lernt man auch nicht durch das Lesen von Büchern ...