Entwickler müssen sich organisieren, agiles Vorgehen ist dabei gerade en vogue. Da fragen sich Sysadmins, ob sich Iterationen, das Arbeiten in Paaren und kurze Meetings nicht übertragen lassen.

Immer mehr Unternehmen stellen vom klassischen Wasserfall auf iterative Software-Entwicklung wie Scrum [1] oder Extreme Programming (XP, [2]) um. In der Systemadministration hingegen hat sich der agile Gedanke bisher nicht durchgesetzt – und das, obwohl es sich hierbei genauso um einen iterativen Prozess handelt wie beim Programmieren. Denn nur durch ständige kleine Anpassungen bleibt das Gesamtsystem dauerhaft stabil. Grund genug, einmal über den Tellerrand zu schauen und zu überlegen, wie eine agile Systemadministration aussähe.

XP legt 13 Grundpraktiken fest, die Software-Entwickler ohne Ausnahme befolgen [3]. Wer sie auf die Arbeit eines Admin übertragen will, muss einige von ihnen anpassen. Damit entsteht agile Systemadministration (ASA).

Agile Praktiken

So könnte ein Grundsatz der ASA-Arbeitsweise zum Beispiel lauten, keinen Webserver zu betreiben, solange ihn kein Monitoring überwacht. Das Verfahren nennt die Fachwelt Continous Testing.

Um die Qualität auf einem hohen Niveau zu halten, sollten Entwickler Software testgetrieben entwickeln. Durch Test Driven Development (TDD) erreichen sie, möglichst viele Fehlerursachen bereits im Vorfeld auszuschließen. So lassen sich Systeme besser warten und erweitern. Einige Programmierer verlieben sich regelrecht in die Tests, wenn der grüne Balken des Werkzeugs anzeigt, dass der eigene Code Hunderte automatische Unit-Tests erfolgreich absolviert hat und somit noch funktioniert.

Das Vorgehen bietet dem Entwickler Gewissheit, seine Software im Griff zu haben, wenn er nach Hause geht. Auch Admins dürfen sich so fühlen, wenn sie Server oder ganze Netzwerke mit automatisierten Tests abdecken (siehe Praktik 1 in der Tabelle 1). Es ist für Admins ein schöner Anblick, wenn alle Anzeigen der Netzwerküberwachung von Nagios (siehe Abbildung 1) auf Grün stehen [4].

Abbildung 1: Sind alle Statusbalken grün, darf sich der Admin beruhigt zurücklegen. Das funktioniert besonders dann, wenn für jeden Dienst und jede Maschine mindestens ein zugehöriger Test den Betrieb überwacht.

So haben die Systemverwalter das Ergebnis ihrer Arbeit direkt vor Augen: Sie wissen auf einen Blick, wie viel freien Speicher der Server noch hat und wie schnell ihre Dienste gerade antworten. Webtests überprüfen zusätzlich dauerhaft und automatisiert, ob alle Applikationen noch verfügbar sind.

Diese Rückversicherung durch die Tests ermöglicht es, auch komplexere Umbauten an der Infrastruktur durchzuführen, ohne Gefahr zu laufen, Relevantes zu übersehen. Führt der Admin die bestehenden Tests auf neuen Servern aus, erhält er so automatisch eine Liste von Änderungen, die er noch vornehmen muss. Somit vereinfacht sich seine Arbeit.

XP-Entwickler programmieren paarweise. Abwechselnd sitzt einer von beiden an der Tastatur (Driver) und der andere daneben (Co-Driver). Auf diese Weise schulen sie sich gegenseitig. Sie befolgen Teamregeln wie Codingstyles und analysieren den Quelltext des jeweils anderen. Zudem darf jedes Paar die Quellen anderer Paare bearbeiten. Das erhöht die Qualität des Code und es entstehen keine Wissensmonopole bei Einzelnen.

Paare lernen schnell voneinander

Admins schreiben meist keinen Quellcode. Stattdessen pflegen sie eine gemeinsame Konfiguration der Server oder des Netzwerks. Zusätzlich vereinheitlichen sie die Wege, wie sie Systeme konfigurieren. Wenn Administratoren neu zu einem Projekt hinzukommen und einen Server aufsetzen, ist es sinnvoll, dies gemeinsam mit einem erfahrenen Kollegen am Bildschirm zu machen (siehe Praktik 2 in Tabelle 1). Auf diesem Weg lernen sie die Arbeitsweisen des Teams schnell kennen. Besonders bietet sich das Administrieren im Paar bei zeitkritischen Problemen an, etwa wenn es darum geht, Downtimes zu vermeiden oder Ausfälle zu beheben.

Dokumentieren ist mühsam, aber notwendig. Ändert sich die Technik, sollten Admins ihre Aufzeichnungen anpassen, sonst bleiben die Dokumente nutzlos oder werden gar gefährlich. Um Kosten zu sparen, verzichtet das agile Paradigma möglichst auf statische Dokumente (siehe Praktik 3 in Tabelle 1). Als Ersatz dienen Unit-Tests. Der Code selbst sollte dann allerdings für sich selbst sprechen.

Planung schont Nerven

Agile Entwickler schützen sich vor dem Burnout. Mehr als 40 Stunden in der Woche sind über einen kurzen Zeitraum hinnehmbar, deuten aber langfristig auf Fehler in der Planung oder auf wackelige Technik hin. Wenn das Team solche Probleme gezielt angeht, bedeuten Bereitschaftsdienste nicht automatisch regelmäßige Wochenend- und Nachteinsätze. Lassen sich Probleme nicht direkt beheben, etwa weil die Technik eine akzeptable Lösung nicht erlaubt, sollte dies für alle transparent sein.

Fällt ein System aus, liegt damit die Schuld nicht automatisch beim Admin, denn jeder wusste um technische Risiken. Ohnehin sind Schuldfragen nicht zielführend. Hilfreicher sind Nachbesprechungen mit Lerneffekt, so genannte Retrospektiven (siehe Praktik 4 in Tabelle 1). Bei ihnen bewerten die Mitarbeiter das Gelernte und suchen nach Verbesserungen. Die Risiken nehmen die Beteiligten in der nächsten Iteration als Anforderung mit auf, priorisieren und lösen sie, bevor sie andere Erweiterungen in Angriff nehmen (siehe Praktik 5 in Tabelle 1).

Damit das Team technische Schwachstellen beseitigen und langfristig die Verfügbarkeit garantieren kann, sollte es nicht allein über die eingesetzte Technik entscheiden. Es priorisiert zusätzlich gemeinsam mit seinem Auftraggeber Um- und Ausbauten (siehe Praktik 6 in Tabelle 1). Schließlich ist das Team verantwortlich für den reibungslosen Betrieb der Infrastruktur. Das erfordert abzuwägen, ob die neueste, altbekannte oder die politisch vorgeschriebene Technik zum Einsatz kommt. Sobald das Team Einigung erzielt, legt es diese als Teamregel fest. So könnte es etwa entscheiden, nur noch Apache Tomcat als Applikationsserver einzusetzen oder in einer bestimmten DMZ keinen Webserver aufzustellen. Solche Regeln muss jedes Teammitglied unterschreiben und einhalten.

Selbstbestimmte Teams

Bei Scrum und XP beschreiben User-Storys die Anforderungen an die Software [5]. Sie beantworten Fragen nach einem festen Muster: Wer möchte etwas? Worin besteht die Änderung, wie sieht sie aus? Wieso ist sie nötig? Das formulieren die Anwender dann beispielsweise so: “Als Mitarbeiter der Personalabteiling möchte ich auf unserer Etage einen eigenen Drucker haben, damit ich nicht mehr bis zum Kopierraum laufen muss.”

Agile Teams arbeiten in Zeiträumen fester Länge, in so genannten Iterationen. Sie vereinbaren das Ziel, am Ende einer Iteration wieder einen stabilen Zustand zu erreichen, und legen sich währenddessen auf eine realisierbare Anzahl von Storys fest (siehe Praktik 7 in Tabelle 1). Während dieser Iteration, auch gelegentlich Sprint genannt, steuert sich das Team selbst und stimmt sich täglich bei kurzen Treffen im Stehen ab (siehe Abbildung 2). Scrum nennt sie auch Standup-Meetings oder Daily Scrums [6].

Abbildung 2: Scrum (Gedränge) ist eine iterative Vorgehensweise, die sich nicht nur auf die Software-Entwicklung, sondern mit Anpassungen auch auf die Systemadministration anwenden lässt.

Systemadministratoren verantworten den dauerhaften Betrieb und planen täglich wiederkehrende Aufgaben. Hier passt die Metapher einer Story nicht ganz. Wiederkehrende Aufgaben lassen sich zwar immer wieder auf die Aufgabenliste (Blacklog in der Scrum-Terminologie) setzen, aber es erschwert dem Team, solche Aufgaben zu planen und durchzuführen.

Deshalb erledigt diese Aufgaben reihum ein anderer Mitarbeiter (siehe Praktik 8 in Tabelle 1). Wer mit dem Patchen der Server an diesem Morgen befasst ist, hat das Patch-Token. Das Path-Token entspricht dem Stab beim Staffellauf, sein jeweiliger Inhaber reicht es jeden Tag weiter. Neben einer wöchentlichen Planung in Sprints haben sich auch Zeitmanagements wie beispielsweise Getting Things Done (GTD) bewährt [7], die es auch als Screencast gibt [8].

Zusammenarbeit

Wenn Admins in der Nähe ihrer Anwender arbeiten, beschleunigt sich die Kommunikation zwischen allen Beteiligten. Die Fachleute reden hier von osmotischer Kommunikation [9]. Können Anwender zum Beispiel nicht mehr auf den Dateiserver zugreifen, wenden sie sich normalerweise an ihre Admins (siehe Praktik 9 in Tabelle 1). Beginnen diese aber zur gleichen Zeit hektisch zu tippen, zu telefonieren oder zwischen ihren Servern und den Konsolen hin und her zu laufen, erübrigt sich die Frage nach möglichen Störungen offenkundig.

Informations-Radiatoren unterstützen diese nonverbale Kommunikation. Das sind große aufgehängte Bildschirme, die den aktuellen Zustand der Infrastruktur anzeigen. Sie strahlen Information ab wie eine Heizung Wärme. Sitzen die Admins durch eine Zugangsschleuse von ihren Kollegen getrennt, hilft es, den Bildschirm mit der Serverüberwachung vor die Schleuse zu hängen. Alternativ lassen sich die Sicherheitsbereiche auch mit durchsichtigen Glaswänden realisieren (siehe Praktik 10 in Tabelle 1).

Agile Werte

Verantwortung im Team zu übernehmen, technische Entscheidungen gemeinsam zu treffen und sich gegenseitig bei der Pair Administration zu schulen ist für manchen Admin ungewohnt. Das geht Entwicklern, die agil arbeiten, manchmal ebenso. Daher sind gemeinsame Werte wichtig. Extreme Programming nennt hier Mut, Respekt, Kommunikation, Einfachheit und Feedback. Scrum benennt dazu Engagement und Fokussierung auf ein Ziel zu seinen Tugenden [10].

Der amerikanische Berufsverband der Systemadministratoren der Usenix, SAGE, hat sich 2003 einen Code of Ethics gegeben. Er besteht aus zehn Regeln, denen die agilen Werte zugrunde liegen: Professionalism, Personal Integrity, Privacy, Laws and Policies, Communication, System Integrity, Education, Responsibility to Computing Community, Social Responsibility, Ethical Responsibility [11]. Um die Arbeit des Sysadmin effektiver zu gestalten, empfehlen sich daraus abgeleitet vier Grundsätze.

Admins verhalten sich professionell und verletzen keine persönlichen Gefühle. Als unprofessionell gilt auch, wegen persönlicher Ansichten unfair zu handeln. Diesen Respekt fordert auch das Extreme Programming. Jedes Teammitglied behält Verfügbarkeit, Datensicherheit und Funktionsfähigkeit seiner betreuten Systeme im Auge. Es fühlt sich für diese Ziele persönlich verantwortlich und engagiert sich fokussiert darum, sie umzusetzen. Nur so entsteht ein Teamgeist, aus dem die Admins schöpfen können.

Ein Systemverwalter sitzt an der Schnittstelle zwischen Anwendern und Management. Bei Systemfragen bindet er alle Beteiligten kommunikativ ein, hört zu, vollzieht Bedürfnisse seiner Gegenüber mit ein und liefert ihnen eine konstruktive Rückmeldung.

Ein weiterer Grundsatz lautet, nur auf private Informationen in Computern zuzugreifen, wenn es nötig ist und im Rahmen von technischen Pflichten stattfindet. Admins bewahren und schützen die Vertraulichkeit aller Informationen, zu denen sie Zugriff haben, unabhängig vom Weg, wie sie daran gekommen sind. Dieser Wert ist eine Besonderheit der agilen Systemadministration.

Die vorgestellten agilen Methoden sind auf die Systemadministration übertragbar, erfordern aber nicht die kompromisslose Umsetzung des Extreme Programming. Auch andere Denkmodelle wie GTD oder die Meta-Methode Crystal, die Teamgrößen und Projektrisiken modelliert, sollten Systemverwalter bei ihrer Arbeit in Betracht ziehen. Eine ASA-Community nach den Vorbildern der Software-Entwicklungsmodelle muss sich erst noch bilden, gegenwärtig entstehen erste Diskussionsplattformen [12].

Die ASA formuliert Vorschläge, wie Systemverwalter ihre Arbeit effektiver erledigen. Jeder von diesen Vorschlägen muss seinen Nutzen in der Praxis erst noch beweisen.

Neue Wege für Admins

Je nach Fachgebiet und Teamgröße unterscheiden sich Aufgaben und Risiken. Darauf passen Admins die Vorschläge an. Wer aber nach ihnen lebt, darf sich über mehr Qualität, gesteigertes Vertrauen in die Technik und schließlich über mehr Spaß bei der Arbeit freuen. (mg)