Der letze Beitrag zur agilen Systemadministration enthielt einen Vorschlag wie man die agilen Methoden auf das Tagesgeschäft eines Administrators übertragen kann.

Nun versuche ich einen Überblick zu geben wie Systemadministratoren in agilen Projekten involviert werden können. Dabei sind offensichtlich drei Aspekte relevant:

• Zusammenarbeit mit Menschen
• Iteratives Vorgehen
• Beraten und Coachen

Diese Punkte sind in meiner Sysadmin-Zeit immer wieder aufgetreten und haben sich in Projekten erfolgreich bewährt.

Punkt 1: Zusammenarbeit mit Menschen.
In (agilen) Projekten ist es häufig erforderlich, dass die Administratoren mit ihrem Wissen das Projektteam unterstützen.  Leider gibt es Vertreter dieser Zunft, die ständig versuchen das Projektteam zu manipulieren und ihre eigenen Regeln getreu dem Motto: “Ich bin root, ich darf das” durchzusetzen. Dabei bedienen sie sich häufig starrer Regeln und Policies (ITIL sei Dank). Hier zeigt sich der grundsätzliche Konflikt zwischen Projektteam und Serviceteam. Die einen wollen ihr Projekt erfolgreich zu Ende bringen (da stören diese Richtlinien eben). Und die Anderen müssen das operative Tagesgeschäft samt Rechteverwaltung sicherstellen.

Daher stammt vermutlich auch das alte Klischeedenken, dass der Administrator der natürliche Feind des Entwicklers ist. Vielmehr muss hier auch dem Admin daran gelegen sein, das Projekt erfolgreich zu beenden und nicht zu behindern.

Punkt 2: Iteratives vorgehen.
So wie das Projektteam arbeitet, muss auch der Administrator iterativ arbeiten.  Das bedeutet, dass die Systeme zuerst grundsätzlich installiert werden und in Folgeschritten die User angelegt und berechtigt werden. Eine komplette Berechtigungsliste kann man hier noch nicht erwarten. Auch kann es sein, dass Systeme während einer langen Projektlaufzeit aktualisiert werden müssen, weil das Projektteam die neuen Funktionalitäten dringend benötigt, oder das Netzwerk aktualisiert werden muss, da die Bandbreite nicht ausreicht.

Punkt 3: Beraten und Coachen.
Hier geht es darum den Entwicklern die Richtlinien und Policies zu erläutern, die für den operativen Betrieb gelten; sie von der Einhaltung der Richtlinien zu überzeugen.  Der Kampf ist bereits verloren, wenn der Administrator versucht die Regeln einfach durchzusetzen. Insgesamt gilt es aber auch die bestehenden Richtlinien selbst immer wieder zu hinterfragen und zu prüfen, ob sie tatsächlich dienlich oder hinderlich sind.

Ebenso müssen dem Projektteam die Zusammenhänge der IT-Infrastruktur erläutert werden. Dies ist insbesondere dann interessant, wenn die IT-Architektur ausschließlich von dem Team festgelegt wird.

Fazit:
Gerade wenn in Projekten agil gearbeitet wird, ist es erforderlich die agilen Werte für die Zusammenarbeit auch zu leben. Das gilt insbesondere für den Urkonflikt zwischen Systemadministratoren und Programmierern.  Allerdings sollte nicht nur der schnelle Projekterfolg im Auge gehalten werden, sondern auch die Gesamtheit der Maßnahmen, durch die ein stabiler und störungsfreier IT-Betrieb möglich wird.

Im aktuellen Linux Magazin habe ich einen interessanten Artikel zum Thema agile Methoden in der Systemadministration gefunden. In der Softwareentwicklung ist der agile Gedanke zunehmend verbreitet. In dem Tagesgeschäft eines IT-Administrators wird agilen Ansätzen derzeit wenig Beachtung geschenkt.

Marcel Wegermann beschreibt in dem Artikel wie sich die agilen Praktiken auf die Arbeit eines Administrators übertragen lassen. Durch Anpassen der Regeln lässt sich so eine ASA (Agile Systemadministration) auf die Beine stellen.  So werden in diesem Artikel Zehn agile Regeln für die Systemadministration aufgestellt, die sich an XP Grundpraktiken orientieren:

1. Jede neue Funktion (z.B. Server, Service, Standleitung oder das Hosting) muss durch automatisierte Tests abgedeckt sein.
2. Teammitglieder administrieren zu zweit an der Konsole, wenn sinnvoll
3. Dokumentation auf Papier ist tot. Automatisierte Tests und die Konfiguration selbst sind Dokumentation genug. Kommentare ergänzen die Monitoring-Tests.
4. Das Team bespricht jeden Notfalleinsatz in der Retrospektive. So findet es die Ursachen für Wochenend- oder Notfalleinsätze und stellt sie zügig ab.
5. Risiken müssen aufgedeckt und schnell beseitigt werden (Transparenz schaffen)
6. Technische Entscheidungen liegen beim Team. Alle Mitglieder tragen sie gemeinsam. Das Team allein hat die Verantwortung für den Betrieb. (Team Commitments).
7. Die Administratoren führen Projekte iterativ und inkrementell durch.
8. Regelmäßig wiederkehrende Aufgaben erledigen alle Teammitglieder reihum.
9. Die Administration arbeitet möglichst zusammen an einem Ort in der Nähe des Kunden. (First- und Second-Level-Support, Entwickler oder Endanwender).
10. Ein großer Bildschirm zeigt nach Art einer Ampel den aktuellen Status der Server und Auslastung für alle gut sichtbar an. Das fördert die osmotische Kommunikation.

Mein Fazit:

Für mich der erste Beitrag zum Thema ASA. Als großer Anhänger der agilen Methoden sind für mich die Punkte eins bis acht lohnend und sicherlich in den meisten Rechenzentren anwendbar. Eine Nagios-Installation leistet bereits  in vielen Unternehmen seine Dienste und kann für die gesamte Testautomatisierung herangezogen werden. Allerdings ist es dann umso wichtiger qualifizierte Kommentare in der Konfiguration zu finden.

Punkt zwei und acht sehe ich als besonders effektiv an. Denn hier steht nicht nur der agile Gedanke im Vordergrund, sondern das Vorhandene Wissen wird auf mehrere Köpfe verteilt. Damit kann dem Problem mangelnder Vertretungen entgegen gewirkt und die Abhängigkeit von Einzelpersonen aufgelöst werden.

Aber nicht alle Ansätze lassen sich so einfach umsetzen. Insbesondere den Punkt neun sehe ich als kritisch an, denn in Zeiten von Outsourcing und Service-Rechenzentren ist die örtliche Nähe zum Kunden nicht immer möglich.

Der Einsatz von Whiteboards, Pinnwänden oder Flipcharts im Administrationsbereich kann zur Sprintplanung genutzt werden oder die Teambesprechungen unterstützen. Wie Teamräume aussehen können ist hier zu sehen. Ein Ticket-Trouble-System wie OTRS kann die auftretenden Störungen kanalisieren und ist zudem revisionssicher. Darüberhinaus ist für die Projekte ein Wiki das Tool der Wahl und zur Kommunikation mit der „Außenwelt“ kann ein Blog sehr hilfreich sein. So könnten dort aktuelle Störungen oder Planungen von Downtimes kommuniziert werden.

Insgesamt haben die agilen Methoden potenzial auch in der Systemadministration einzuziehen. Die bisherigen strikten Zuständigkeiten für Systeme oder Anwendungen können so effektiv aufgebrochen und eine höhere Dienstleistungsqualität erreichet werden.

Es ist mal wieder soweit.  Heute ist der System Administrator Appreciation Day. An diesem Tag wird den Systemadministratoren für ihre Arbeit hinter den Kulissen gedankt. Ich selbst weiß wie es ist, Sysadmin zu sein. Wenn die Benutzer merken, dass man da ist, handelt es sich vermutlich um einen Serverausfall, oder eine sonstige Störung. Wenn wir unsere Arbeit nieder legen, um zu streiken, merkt es keiner, wenn wir sie vorher gut erledigt haben. Ebenso wird grundsätzlich nur gemeckert, wenn die Benutzer Spam-Mails empfangen – von den zigtausend, die täglich abgewehrt werden. Tja, als Sysadmin hat man es eben nicht leicht..

Immer dann, wenn ich einen Azubi betreue und ihm in die “Kunst” der Perl-Programmierung einführe, bin ich erschrocken wie planlos die jungen Menschen ihre Programme aufbauen. Leider bleibt es bei vielen Programmierern und IT-Administratoren dabei. Dies führte vor ein paar Tagen zu einer Diskussion, ob Perlcode “schön sein muss”. Ich benutze absichtlich diese Formulierung, um die Brisanz deutlich zu machen. Auch viele meiner Kollegen gehen eher den pragmatischen Weg und schreiben ihre Skripte nicht zum lesen. Dies führt immer wieder dazu, dass jemand der das Skript nicht geschrieben hat und “mal eben” eine Änderung vornehmen muss, bei einem 200 Zeilen Skript einen halben Tag braucht. Leider führt die Freiheit alles kurz und “mal eben” zu schreiben häufig dazu, dass Perlcode, und insbesondere die regulären Ausdrücke, als Leitungsrauschen wahrgenommen wird.

Ich habe mir jedenfalls die Mühe gemacht,  die aus meiner Sicht wichtigen Punkte zusammenzutragen, damit man Perlcode schreiben kann, der auch gerne gelesen wird.
Also viel Spaß:

<!– @page { size: 21cm 29.7cm; margin: 2cm } P { margin-bottom: 0.21cm } –>

Nachdem ich am vergangenen Wochenende meine Fedora Core Installation aktualisiert habe, hier die eine Anleitung wie dieses Upgrade erfolgreich wird.

Bei Fedora aktualisiert yum das Betriebssystem. Damit das problemlos funktioniert, müssen ein paar Schritte beachtet werden. Das System lässt sich mittels “yum –y update” aktualisieren. Dies ist erforderlich um den aktuellen FC4-Stand zu erhalten. Danach muss das System alle inaktiven Kernel entfernen. Die installierten Kernel werden mit “rpm –q kernel” ermitteltund mit “rpm -e kernel-2.6.xy” entfernt.

Anschließend müssen folgende Pakete installiert werden: fedora-release und fedora-release-notes. Doch die Installation gelingt nur, wenn die fedora-release-notes zuerst installiert werden. Zudem muss das Paket die Abhängigkeiten mittels Force (rpm -ihv fedora-release-notes-6-3.noarch.rpm –nodeps) umgehen. Anschließend kann das zweite Paket installiert werden (rpm -ihv fedora-release-6-4.noarch.rpm).

Jetzt ist Yum in der Lage sich selbst mit der neusten Version zu versogen (yum -y update yum). Die neuere Version ist schneller und spart damit Zeit für das zeitraubende Update.

Das System wird von nun an in zwei Schritten aktualisiert:

1. Kernel mit den zugehörigen Abhängigkeiten

2. Das “restliche” System

Yum wird die erforderlichen Abhängigkeiten nicht auflösen können, daher ist hier ein wenig Nachhilfe erforderlich. Alle Pakete könne entfernt werden, bei denen Yum die Abhängigkeiten nicht auflösen kann. Hier ein Beispiel:

Error: Missing Dependency: hotplug is needed by package udev
Error: Missing Dependency: hotplug >= 2001_04_24-13 is needed by package gphoto2
Error: Missing Dependency: libssl.so.5 is needed by package iiimf-libs
Error: Missing Dependency: howl = 0.9.8 is needed by package howl-libs
Error: Missing Dependency: iiimf-libs = 1:12.2-4.fc4.2 is needed by package iiimf-libs-devel
Error: Missing Dependency: xorg-x11-libs = 6.8.2-37.FC4.49.2.1 is needed by package xorg-x11-devel
Error: Missing Dependency: XFree86-libs >= 4.2.99 is needed by package libgnomeui
Error: Missing Dependency: /usr/X11R6/lib/X11/XKeysymDB is needed by package openmotif

Das System könnte nicht mehr arbeiten, wenn das Paket “udev” entfernt werden würde. Zudem sind noch andere Pakete betroffen, durch die die Systemstabilität beeinflusst wird.

Yum bietet Abhilfe mittels “yum provides hotplug”. Dies zeigt die Paketabhängigkeiten, die das Paket hotplug besitzt. Die letzte Spalte zeigt die verfügbare Quelle, oder den Status des Pakets an. Die angezeigten Pakete sollten dann per Hand mittels “rpm -e

” entfernt werden.Anschließend kann man dasd System mit dem Befehl: “yum update” auf die aktuelle Version anheben.