Dirks Logbuch (Artikel mit Tag sysadmin)

Call your Sysadmin ...

nospam@example.com (Dirk Deimeke) — Wed, 07 Oct 2015 05:25:00 +0200

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.

Definition DevOps ...

nospam@example.com (Dirk Deimeke) — Tue, 12 May 2015 10:25:38 +0200

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.

Performanceuntersuchungen ...

nospam@example.com (Dirk Deimeke) — Thu, 23 Apr 2015 05:41:00 +0200

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.

Sicherheitslücke Systemadministrator ...

nospam@example.com (Dirk Deimeke) — Thu, 20 Feb 2014 08:21:00 +0100

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).

The Practice of System and Network Administration ...

nospam@example.com (Dirk Deimeke) — Fri, 15 Mar 2013 06:09:00 +0100

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.

Junior? Senior?

nospam@example.com (Dirk Deimeke) — Tue, 30 Oct 2012 07:13:00 +0100

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.

Administratoren haben ein Wahrnehmungsproblem ...

nospam@example.com (Dirk Deimeke) — Thu, 29 Mar 2012 08:31:16 +0200

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."

Grundwahrheit für Entwickler ...

nospam@example.com (Dirk Deimeke) — Wed, 07 Mar 2012 08:04:29 +0100

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.

Bereitschaft ...

nospam@example.com (Dirk Deimeke) — Mon, 30 Jan 2012 11:17:44 +0100

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.

Monitor the monitor ...

nospam@example.com (Dirk Deimeke) — Sat, 26 Nov 2011 08:03:39 +0100

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..

Zeitmanagment für Systemadministratoren ...

nospam@example.com (Dirk Deimeke) — Sat, 19 Nov 2011 17:13:09 +0100

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.

Load average ...

nospam@example.com (Dirk Deimeke) — Thu, 06 Oct 2011 13:56:40 +0200

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.

Minderheitenschutz für Administratoren ...

nospam@example.com (Dirk Deimeke) — Thu, 05 May 2011 13:36:46 +0200

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

Kenne Deine Werkzeuge ...

nospam@example.com (Dirk Deimeke) — Wed, 15 Dec 2010 06:12:00 +0100

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.

Schwimmen und Rad fahren ...

nospam@example.com (Dirk Deimeke) — Wed, 24 Nov 2010 07:28:46 +0100

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 ...

Wir haben die Macht ...

nospam@example.com (Dirk Deimeke) — Fri, 10 Sep 2010 14:41:52 +0200

Manager? CEOs? Vorstände? Von wegen - der Mann, der uns alle in der Hand hat, ist der Systemadministrator.

Artikel in SüddeutscheZeitungMagazin, Betr.: Die dunkle Seite der Macht

Disk-Monitoring ...

nospam@example.com (Dirk Deimeke) — Fri, 02 Jul 2010 18:40:26 +0200

Gibt es eigentlich intelligentes Diskmonitoring (auf dem Mond)?

Die meisten Monitoring-Lösungen, die ich kenne, überwachen Dateisysteme auf einen bestimmten Füllgrad und warnen, wenn eine bestimmte Grenze überschritten wurde bzw. alarmieren, wenn eine andere Grenze überschritten wurde. Man kann diese Grenzen global, per Gruppe von Maschinen oder pro einzelne Maschine festlegen.

Leider haben Dateisysteme im Laufe ihres Lebens die Angewohnheit zu wachsen. Und so muss man immer an einer Schraube nachjustieren, dass das Monitoring bzw. Warnungen und Alarmierungen wieder passen. Tut man das nicht können merkwürdige Alarme kommen.

Im Normalfall wird bei Erreichen der 90% Marke gewarnt und bei Überschreiten der 95% Marke alarmiert.

Das ist für kleine Dateisysteme auch sinnvoll, wenn aber im Laufe des Lebens ein Dateisystem 1 TB Platz hat reden wir von Alarmierungen, wenn "nur noch" 50 GB frei sind.

Was ich mir vorstelle, ist so eine Art selbstlernendes System, dass sich an die Nutzung der Dateisysteme anpasst. Oft ist es so, dass zu Stosszeiten ein grosses Wachstum zu verzeichnen ist, in ruhigeren Zeiten bleibt der Stand erhalten oder der Füllgrad geht sogar zurück.

Gibt es solche Systeme, die das Wachstum und vor allem auch die Schrumpfung über die Zeit beobachten und Alarm schlagen, wenn sich die Füllgrade beispielsweise um 5% pro zehn Stunden verändern? (Zahlen willkürlich gewählt). Und die dann auch berücksichtigen, was in der Vergangenheit auf dem Dateisystem los war?

Fände ich klasse.

(Gleiches gilt für CPU-Monitoring oder Nutzung des Hauptspeichers).

Gelöscht und nicht freigegeben ...

nospam@example.com (Dirk Deimeke) — Thu, 01 Jul 2010 17:40:00 +0200

Einer der grossen Stolpersteine, die Nutzern im Weg liegen, sind Dateien, die sie gelöscht haben, deren Speicherplatz aber nicht freigegeben wurde.

Um das Problem zu verdeutlichen, erzeuge ich einmal eine 1 GB Datei:

$ dd if=/dev/zero of=/tmp/GB-Datei bs=1024 count=1048576

$ df -h /tmp
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 142G 118G 17G 88% /

In einem zweiten Fenster lese ich jetzt die Datei mit less

less /tmp/GB-Datei

Jetzt lösche ich die Datei im ersten Fenster:

rm /tmp/GB-Datei

df -h /tmp
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 142G 118G 17G 88% /

Der Speicherplatz wurde nicht freigegeben, weil noch ein Prozess die Datei benutzt. Um herauszufinden wer noch offene Dateien hat, hilft der Befehl lsof (list open files, Lektüre der man-page lohnt sich!).

lsof | grep deleted
less 2204 dirk 4r REG 8,1 1073741824 2621637 /tmp/GB-Datei (deleted)

ps -fp 2204
UID PID PPID C STIME TTY TIME CMD
dirk 2204 1807 7 17:26 pts/0 00:00:25 less /tmp/GB-Datei

Wenn jetzt das less-Kommando verlassen wird, ergibt sich:

df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 142G 117G 18G 87% /

Einen Hinweis noch am Ende. Sehr häufig gibt es die Herausforderung, dass das Log eines Serverdienstes zu gross wird und man kein Wartungsfenster bekommt, um die Logdateien wegzuräumen.

Wenn wirklich dringend Platz geschaffen werden muss, kann man mit

cat /dev/null > logdatei

oder

> logdatei

Die Datei auf null Bytes verkleinern. dabei wird das Dateihandle nicht verändert, der Serverdienst logged also weiter in die gleiche Datei.

mintty für Cygwin ...

nospam@example.com (Dirk Deimeke) — Wed, 09 Jun 2010 13:01:00 +0200

Mal eben schnell "wegbloggen".

Nach gefühlten einhundert Jahren Schmerzen mit Cygwin und der Windows-Textkonsole habe ich jetzt mintty gefunden.

Mintty is a terminal emulator for Cygwin that is based on code from PuTTY 0.60 by Simon Tatham and team.

Und prompt brauche ich PuTTY nicht mehr ... (ich werden mintty natürlich noch ausführlich testen, aber bis jetzt sieht es richtig gut aus).

Odysee ...

nospam@example.com (Dirk Deimeke) — Mon, 26 Apr 2010 07:01:03 +0200

Unser root-Server macht leider weiterhin Probleme. Seit letzten Donnerstag verabschiedet er sich sang- und klanglos (ohne irgendeine Meldung im Log). Meiner Meinung nach liegt das an Überhitzung, vermutlich hat sich ein oder haben sich mehrere Lüfter verabschiedet. Ein anderer Hardware-Schaden wäre auch denkbar, aber relativ unwahrscheinlich, weil es dann immer noch Meldungen in die System-Logdateien schaffen.

Vor zwei Monaten hatten wir das gleiche schon einmal, ein achtstündiger Hardwaretest hatte allerdings nichts ergeben. Ich bin gespannt, wie sich der Anbieter jetzt dazu stellt. So kann es in keinem Fall weitergehen.

Kein Produktionssystem ...

nospam@example.com (Dirk Deimeke) — Wed, 21 Apr 2010 17:05:00 +0200

Was mich in meiner beruflichen Laufbahn als Systemadministrator immer am meisten gestört hat, war die Aufteilung der betreuten Systeme in Produktionssysteme nicht Nicht-Produktionssysteme.

Dabei war es meist so, dass die Produktionssysteme sofort Support bekommen und die anderen Systeme später, wobei später auch heissen konnte "Wenn jemand Lust hat, sich darum zu kümmern.".

Nahezu klassisch ist die Unterteilung in Entwicklungsmaschinen (DEV), Testsysteme (ET, IT), Abnahmesysteme (PT/A, UAT), Backupsysteme (BAK, BCP) und Produktionssysteme (PROD). Und das ist dann gleich auch die Reihenfolge, in der die Systeme betreut werden und - das ist der Grund für diesen Artikel - ich halte diese Reihenfolge für falsch.

Natürlich braucht man eine Unterteilung der Wichtigkeit, um eine Reihenfolge der Bearbeitung festzulegen.

Hier werden meistens Service Level Agreements (SLAs) benutzt, die genau bestimmen, innerhalb welcher Zeit welche Systeme betreut werden müssen oder - mal ganz platt - wer am meisten Geld bezahlt, bekommt den schnellsten Support. Leider werden auch diese SLAs so abgeschlossen, dass die oben angegebene Reihenfolge abgedeckt wird.

Unstrittig ist, dass die Produktions- und die Backupsysteme die höchste Aufmerksamkeit geniessen müssen, da sie meistens für das Kerngeschäft entscheidend sind und häufig auch direkt mit den Kunden zu tun haben, die man durch einen Ausfall vergraulen könnte. Das heisst, hier kann nicht nur finanzieller Schaden entstehen, hier kann auch der Ruf geschädigt werden (was indirekt wieder zu einem finanziellen Schaden führt).

Aber was kommt danach? Für mich persönlich kommen danach tatsächlich die DEV-Maschinen und die Testsysteme. Das sind nämlich Produktionssysteme für Entwickler und für Tester. Es ist relativ leicht auszurechnen, welcher Schaden entsteht, wenn eine komplette Entwicklungsabteilung Däumchen dreht und nur Geld kostet, dafür aber keine produktive Arbeit schafft. Gleiches gilt für Testsysteme und Tester, wobei hier meist in kleineren Umgebungen die Tester aus den Fachabteilungen kommen und auch noch produktive Arbeit zu leisten haben.

Eure Meinung?

Kein Glück ...

nospam@example.com (Dirk Deimeke) — Sat, 17 Apr 2010 07:00:31 +0200

Wir haben kein Glück mit unserem root-Server. Nach dem Ausfall im Januar haben wir momentan nach einer Aufrüstung auf 4 GB (von 2 GB) Probleme mit dem Speicher. Die Kernel-Meldungen lassen keinen anderen Schluss zu.

Aus diesem Grund wird es heute einen intensiven Speicher-Test geben und der Server wird zwischen 10:15 Uhr und voraussichtlich 12:15 Uhr nicht verfügbar sein.

Update: Speicherfehler wurde gefunden und der Speicher wurde komplett ausgetauscht.

Nicht machen ...

nospam@example.com (Dirk Deimeke) — Tue, 13 Apr 2010 12:56:00 +0200

Ich habe neulich den Ausspruch

Benutze nicht awk, wenn Du sed benutzen kannst. Benutze nicht sed, wenn Du grep benutzen kannst. Benutze nicht grep, wenn Du cut benutzen kannst.

gehört und weiss nicht so recht, was ich davon halten soll.

Prinzipiell halte ich es für eine sehr gute Idee, wenn möglichst viele Tools den eigenen Werkzeugkasten füllen. Und meine Meinung ist, dass man das Tool der Aufgabe entsprechend aussuchen sollte. Ich halte auch gar nichts von "Pipe-Schlangen" so wie "grep suchbegriff datei | grep -v 'anderer suchbegriff' | cut -f 1 | sed 's/u/x/", wenn man das alles mit einem einzigen Werkzeug erledigen kann.

BOFH-Smitty

nospam@example.com (Dirk Deimeke) — Fri, 02 Apr 2010 06:13:00 +0200

Bastard Operation Control Centre

Aprilscherze für Techies ...

nospam@example.com (Dirk Deimeke) — Thu, 01 Apr 2010 07:16:00 +0200

Auf rfc-humor.com finden sich die gesammelten RFCs, die als Aprilscherze veröffentlicht wurden.

Weltbekannt und einer der besten RFCs ist RFC 1149, "A Standard for the Transmission of IP Datagrams on Avian Carriers", auch bekannt als "IP über Brieftauben".