2

Der Administrator und das agile Projektteam

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.

0

Happy SysAdminDay

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

3

Warum Perlcode schön sein muss

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ß:

Linux doch als Desktopalternative

Mit der heute veröffentlichten Kernel Version 2.6.18 ist der Kernel mit all seinen Treibern und damit natürlich auch das Betriebssystem selbst wieder ein Stück Richtung Desktopalternative gerückt. Die meisten Änderungen sind für den Desktop sicherlich unerheblich, dennoch wird das freie Betriebssystem häufig nicht, wegen mangelnder oder schlechter Treiber, eingesetzt. Dass der CFQ-I/OScheduler nun zum Standard gemacht wurde bleibt dabei Nebensache.

Infos

[1] Heise Open zum neuen Kernel [http://www.heise.de/open/artikel/77566]
[2] Golem zum neuen Kernel [http://www.golem.de/0609/47705-3.html]