© underworld under, 123RF.com

Wohin führt die schnell zunehmende Zahl zu betreuender Systeme bei gleichbleibender Zahl an Betreuern? Zu Überforderung und Chaos? Andernfalls zu Scrum, Kanban und anderen agilen Arbeits- und Organisationsformen? Das Linux-Magazin hat vier Profis zu ihrer Rolle inmitten eines Berufes im Wandel befragt.

Wer auf die Visitenkarten von Mitarbeitern der IT-Abteilungen schaut, erkennt schnell die Differenzierung und den Wandel des Admin-Jobs. Wo früher noch “Administrator” in der Signatur stand, prangen nun Begriffe wie “Systemspezialist” oder “Site Reliability Engineer”. Differenzierter sind nicht nur die Titel, auch die Aufgabenbereiche wandeln und verbreitern sich schleichend.

Arbeiteten einst die Admins als Herren und Frauen über Server und Systeme in der einen Abteilung und die Programmierer und Dokuschreiber in der Entwicklungsabteilung organisatorisch und räumlich getrennt woanders, so sind die Grenzen heute fließend(er).

Dieser Artikel bereist das Innere von IT-Abteilungen, um die Veränderungen der modernen IT-Arbeit mit Hilfe typischer Vertreter ihrer Zunft zu erkunden. Dabei wird schnell klar: Anders als in der reinen Software-Entwicklung, bei der moderne Methoden sowohl gut erforscht als auch vielfach angewendet werden, befinden sich Admins und Operations-Teams in vielen Fällen organisatorisch mitten in einem Umbruch.

Administrierender Coder und codender Administrator

Tobias Paepke (Abbildung 1) ist Senior Frontend Web Developer beim Vergleichsportal Billiger.de in Karlsruhe. “Unser Unternehmensportal nach Maßgaben von Produktmanagern weiterzuentwickeln ist mein Job”, erklärt er. Das bedeutet nicht nur Code schreiben. Zu einem Viertel seiner Zeit, schätzt er, erledigt er klassische Betriebsaufgaben wie externe Schnittstellen anpassen.

So hat Paepke kürzlich die Puppet-Rezepte zur Verteilung der Frontends modifiziert und das Session-Management des Portals erweitert. “Als wichtigen Teil unserer Arbeit optimieren wir die Performance der Systeme und halten sie in einem stabilen Zustand”, umreißt er die klassische Operations-Aufgabe.

Zumindest beim Jobtitel beschreitet der Freiberufler Dirk Gomez (Abbildung 2) genau Paepkes Gegenrichtung. “Im Active Directory lautet mein momentaner Jobtitel ,Systemspezialist'”, verrät Gomez, der an einem zeitlich befristeten Projekt für einen Dienstleister im Gesundheitswesen arbeitet. Dort betreibt er Webanwendungen unter Linux und Solaris, entwickelt sie aber auch weiter. Zuletzt hat er ein etwas aus der Form geratenes Typo-3-System unter seine Fittiche genommen. Es galt, das CMS zu aktualisieren, das zahlreiche geforkte Extensions hat. Zusätzlich stand ein Update auf eine neue LTS-Release an.

Zu je einem Drittel seiner Zeit kümmert er sich ums Administrieren, zu einem Drittel entwickelt er Software – der Rest sind Kommunikation mit Kollegen und Auftraggebern. Diese Mischform des Code-affinen Admin einerseits oder des Entwicklers andererseits, der sich auch mit Betriebsfragen befasst, trägt der engen Verzahnung der Aufgaben in modernen IT-Abteilungen Rechnung.

Abbildung 1: Tobias Paepke will Wissensinseln bei Billiger.de vermeiden: “Das Ausrollen und Testen einer Release übernimmt jedes Mal ein anderer.”

Abbildung 2: Der Freiberufler Dirk Gomez beklagt: “Falsch interpretiert führen agile Methoden dazu, dass Mitarbeiter lediglich Kennzahlen optimieren.”

Betrieb großer Daten

Zum Siegeszug hat das Devops-Konzept aber noch nicht angesetzt. Karolin Wachsmuth (Abbildung 3) ist als System Engineer bei der Inovex GmbH in Köln angestellt und betreut einen Großkunden aus der Medienbranche. Ihr Auftrag: “Für die Big-Data-Umgebung unseres Auftraggebers betreiben wir einen Hadoop-Cluster. Ich sorge dafür, dass der in einem Zustand bleibt, in dem unsere Entwickler gut damit arbeiten können.”

Abbildung 3: Karolin Wachsmuth von Inovex kümmert sich um einen Big-Data-Cluster: “Meine Aufgaben wähle ich selbst anhand von Erfordernissen.”

“Mit Entwicklung habe ich nichts zu tun”, grenzt sie sich von der andernorts populären Mischform ab und erweitert dies auch auf ihre Kollegen: “Die Abteilung ist aufgeteilt in kleinere Teams, die sich in der Hauptsache um bestimmte Systeme kümmern, etwa um die Contentmanagement-Systeme oder Datenbanken.” Das bedeutet aber auch, eng mit den Kollegen aus der Entwicklungsabteilung zusammenzuarbeiten. Von dort bekommt sie auch fachliche Aufträge, bewertet sie und setzt sie selbstständig um.

Agiler Vollzeitadmin

Aufgaben fokussiert verteilen ist auch das Ziel des Telefonie-Anbieters Sipgate in Düsseldorf. Dort arbeitet Rudolph Bott (Abbildung  4) als Systemintegrator Linux und Windows. “Ich gehöre zum Admin- Team, das sich um die gesamte Infrastruktur kümmert, die Sipgate ausmacht”, stellt er seinen Job vor und zählt auf: “Angefangen von der Büro-IT über unsere Netzwerke, Anbindungen an Partner, Rechenzentren, Server, hochverfügbare Cluster bis hin zum Konfigurationsmanagement und noch weiteren Bereichen.” Einzig Entwicklung, Pflege, Konfiguration und Betrieb der hauseigenen Software sowie der Telefoniesysteme gehören nicht dazu.

Es ist aber nicht allein das Aufgabengebiet, sondern vor allem die Arbeitsweise, die die agilen Methoden vom klassischen IT-Betrieb unterscheiden. Zusammenarbeit innerhalb von Teams oder Abteilungen erweist sich als wichtig. Gab klassischerweise der IT-Leiter die Marschrichtung vor, betonen Scrum und Kanban die Selbstorganisation des Teams.

Rudolph Bott erläutert, wie Sipgate das handhabt: “Wir arbeiten nach dem Kanban-Prinzip – das bedeutet, dass wir unsere Aufgaben in kleine so genannte Storys aufteilen. Auf Zettel notiert ziehen wir sie an einem Board durch verschiedene Etappen, beispielsweise Work-in-Progress, QA oder Live-Deploy.” Erst nach einer abgenommenen Qualitätssicherung verlässt eine Story das Board.

Abbildung 4: Rudolph Bott bei Sipgate: “Ohne Kanban wären die Aufgaben als ,Admin of the Week’ gar nicht zu leisten.”

Den Rücken freihalten

Tobias Paepke berichtet von Billiger.de: “Ein Teamleiter unterstützt unser Team, der Basistechnologien entwickelt, aber hauptsächlich den organisatorischen Overhead von uns Entwicklern fernhält.” Ansonsten mischt das Unternehmen die einzelnen Disziplinen: Es gibt immer Sprints, in denen sich einige Teammitglieder aufhalten, der Rest macht Kanban. Paepke betont den Aspekt der Zusammenarbeit: “Wir achten darauf, dass das Sprint-Team auch über mehrere Sprints hinweg eine Gemeinschaft bildet, und darauf, dass jeder innerhalb des Jahres eine gewisse Zeit sprintet.”

In einer Abteilung, deren vorrangige Aufgabe im klassischen Betrieb liegt, haben vorgeplante Sprints mit im Planning festgelegten Zielen mitunter Nachteile, weil sie nicht auf kurzfristige Ereignisse reagieren können. Das betont auch Karolin Wachsmuth: “Neben dem Ticketsystem, in dem unsere Auftraggeber die Langfristaufgaben geordnet nach Dringlichkeit hinterlegen, beobachten wir insbesondere unser Performance-Monitoring. Geht beispielsweise der Platz des HD-FS im Hadoop-Cluster zur Neige, habe ich dort automatisch etwas zu tun.”

Die konkreten Aufgaben sucht sie sich meist selbst, was den eigentlichen Betrieb angeht, und differenziert: “Soll jedoch eines unserer BI-Systeme verändert oder erweitert werden, spreche ich häufig zuvor mit dem zugehörigen Teamleiter.

Wissensinseln vermeiden

Dirk Gomez betont die Rolle der Erfahrung: “Im Zweifel machen die erfahrenen Mitarbeiter alles, die weniger erfahrenen kümmern sich schwerpunktmäßig um ihre Anwendung.” Erst wenn Aufgaben keinen Abnehmer finden, werde der Teamleiter aktiv. Damit spricht er eine weitere Herausforderung in IT-Abteilungen an – die Verteilung des Wissens.

Paepke wie Bott wollen Wissensinseln bannen. “Wir haben im Team einen wöchentlich wechselnden ,Admin of the Week’, der sich um alle Anfragen von außen an das Team kümmert”, beschreibt Bott. Dazu gehören das IT-Equipment im Büro, Berechtigungen oder Mailaccounts. Auf diese Weise will Sipgate zusätzlich verhindern, dass Kollegen aus der Arbeit an Storys geholt werden und unnötig den Fokus verlieren. Bott weiß aber auch um die Grenzen: “Auch wenn das bei wachsender Teamgröße nicht immer einfach ist, versuchen wir an der Alle-alles-Strategie festzuhalten.”

Billiger.de setzt auf verschiedene agile Methoden wie Pair-Programming. Bei dieser Extreme-Programming-Technik sitzen zwei gleichberechtigte Entwickler an einem Rechner – einer als “Pilot”, der Code schreibt, der andere als “Navigator”, der die Korrektheit überwacht und über Verbesserungen am Design nachdenkt. Alle paar Minuten wechseln beide Entwickler die Rollen. Arbeiten mehrere Paare an einem Projekt, tauschen sie sogar paarunabhängig die Plätze.

“Das fördert das Verständnis untereinander und stellt das Wissen breiter auf”, findet Paepke. Wiederkehrende Standardaufgaben verteilt seine Abteilung reihum auf das ganze Team. So rollt beispielsweise jede Woche ein anderes Teammitglied die jeweils neue Release aus.

Jeder macht alles

“Agil heißt, kleine Schritte zu machen”, fasst Wachsmuth den Kern der neuen Denkschule der IT-Abteilungen zusammen. Das führt aber auch zu höherem Bedarf an Austausch und Kommunikation, wofür es aber eine Reihe Werkzeuge gibt. Bezeichnenderweise gaben alle IT-Experten im Gespräch mit dem Linux-Magazin an, mit dem Ticketsystem Jira (Abbildung 5, [1]) zu arbeiten. Das Werkzeug steht unter proprietärer Lizenz, arbeitet aber als Java-Anwendung problemlos in einem Java-Container. Bott differenziert: “Wir nutzen zwei Ticketsysteme: Für Storys setzen wir auf Jira, für den ,Admin of the Week’ auf OTRS.” Anders hält er es nicht für möglich, in dieser Rolle die vielen unterschiedlichen Anfragen zu tracken und zu lösen.

Tickets stehen bisweilen – besonders bei Anwendern – in dem Ruf, die Arbeit der IT-Abteilungen zu bürokratisieren. Bei den befragten Admins hingegen sind sie wohlgelitten: “Ich finde unser Ticketsystem sehr gut”, urteilt Karolin Wachsmuth, und Dirk Gomez teilt ihre Einschätzung, schränkt aber etwas ein: “Ich bin recht zufrieden. Im Normalfall hängt aber viel vom First Level ab, etwa wie viele Details der abfragt und welche Tickets er überhaupt zu uns durchlässt. Das nämlich ist leider ziemlich schwankend.”

Tobias Paepke sieht eine weitere Stärke von Jira in der Information seines Managements: “Es hat hier seine Stärken in den Reports und den Auswertungen. So wie es bei uns implementiert ist, könnte es mehr Unterstützung für den Entwickler bieten – zum Beispiel eine bessere E-Mail-Schnittstelle oder die Verknüpfung zu unseren Softwarerepositories.”

Neben elektronischer setzen IT-Abteilungen auch auf direkte Kommunikation. Wachsmuth zählt auf: “Wir sind permanent im Skype-Chat mit unserem Kunden. Alle zwei Tage veranstaltet unserer Team so genannte Twodailys. Da berichtet jeder, was in den letzten zwei Tagen vorgefallen ist und was wir in den nächsten beiden Tagen vorhaben.” Zusätzlich bespricht sie sich einmal wöchentlich mit anderen Teams, die für ihren Kunden arbeiten, sowie alle zwei Wochen mit ihren Kollegen beim Auftraggeber.

Bei so vielen Meetings kommt es auf Disziplin an. Rudolph Bott verrät einen Trick: “Wir leihen uns einen Scrum-Master bei unseren Entwicklern, der unsere morgendlichen 20-Minuten-Standups begleitet und einmal pro Woche eine einstündige Retrospektive mit uns abhält.”

Abbildung 5: Erfreut sich bei den Befragten überraschend großer Verbreitung – das Ticket- und Reportingsystem Jira.

Theorie trifft Praxis

Den großen Durchbruch in den IT-Abteilungen hat Scrum anders als bei den Software-Entwicklern offenbar noch nicht erzielt. Bott: “Unsere Entwickler organisieren sich in Scrum-Teams und Sprints, die Sysadmins nicht.” Ihm pflichtet Gomez bei: “Nur unsere Entwickler verwenden Scrum.” Bei Billiger.de hat die Systemadministration laut Paepke zwar Schnittstellen zum Kanban, organisiere sich aber über simple Tickets selbst.

Unter Scrum-Verfechtern kursiert bisweilen die Auffassung, dass nur das vollständige Befolgen des komplexen Regelwerks zu guten Ergebnissen führe. Das sehen viele IT-Abteilungen in der Praxis offenbar pragmatischer. Paepke etwa ist der Überzeugung, dass es das Scrum nicht gibt: “Das lässt sich nicht nach Lehrbuch umsetzen. Man ist ja agil. Wir probieren ab und an einen Bruch der Regeln, um zu sehen, wie gut oder wie schlecht die Methoden auf uns passen, und lernen daraus. Das Grundsetup der aktuellen Methoden wie Scrum oder Kanban setzen wir wie gedacht ein.”

Bott formuliert es ähnlich: “Es gibt sicherlich nicht das universelle, perfekte Kanban, sondern immer nur die mehr oder weniger gut auf die eigene Situation angepasste Variante. Wir halten uns zwar recht eng an unsere selbst aufgestellten Regeln, sehen aber alles als iterativen Prozess an. Wenn uns etwas an der effizienten Arbeit behindert, probieren wir Änderungen aus, behalten sie oder gehen wieder zurück zur Ausgangslage.”

Was bringt’s am Ende?

Bleibt die Frage nach messbaren Ergebnissen – meistens dem, wonach sich Management und Controlling sehnen. Rudolph Bott erkennt Kanban eine deutliche Steigerung von Produktivität und Qualität zu. Er zerlegt damit größere anstehende Aufgaben in kleinere Storys: “Wir erreichen dann Stück für Stück ein größeres Ziel, ohne uns von Nebenaufgaben ablenken zu lassen.”

Auch Paepke gibt sich überzeugt, seit der Einführung produktiver geworden zu sein: “Wir arbeiten mehr als Team und haben dadurch mehr Spaß an der Arbeit. Das sind für mich die wichtigsten Punkte, die mich dazu bringen, an das Konzept zu glauben.”

Oft liefert ein sowieso eingesetztes Tool Kennzahlen. Gomez hat beobachtet: “Aus dem Ticket-Tracking-System purzeln Zahlen heraus. Aber wie sich Qualität messen lässt, weiß ich nicht, da ich nicht Teil der Organisation bin. Mein Eindruck ist, dass Mitarbeiter eher auf die Zahlen als auf ihre Tätigkeit optimieren.” Bott wendet ein: “Wir brechen Kennzahlen nicht auf einzelne Personen herunter. Aber anhand der Zahlen können wir Storys als Ausreißer identifizieren. Dann überlegen wir, was im Einzelnen dazu geführt hat und wie wir das beim nächsten Mal verhindern.”

Unvollendete Evolution

Dieser Report zeigt, IT-Abteilungen befinden sich vielerorts im Umbruch. Anders als in der Software-Entwicklung, die ihre Arbeitsweise schon vielerorts auf agile Methoden wie Scrum und Kanban umgestellt hat, feilen die Mitglieder der Operations-Teams und Systemadministratoren noch an der Ausgestaltung ihrer neuen Rollen. Die Form der Umsetzung differiert zudem stark von Unternehmen zu Unternehmen. Gleichwohl: Trotz nicht abgeschlossener Feinabstimmung haben die Methoden in vielen Abteilungen offenbar schon positive Spuren hinterlassen, denn die Effizienz steigt – da sind sich fast alle einig.