Be pragmatic, not dogmatic!

Be pragmatic, not dogmatic! "Sitzen wir nicht alle im selben (Software)-Boot?"

Joachim Arrasz

Im letzten Teil der Kolumne „Be pragmatic, not dogmatic!“ wurde diskutiert, inwiefern sich die Meinungen von Sponsor und Entwicklungsteam zum Thema Test, Stage oder Production-Deployments unterscheiden. Dieses Mal wollen wir die Differenzen zwischen Entwicklungsteam und betreuendem Maintenance-Team beleuchten. Es geht um die Einhaltung von Prozessen und Zuständigkeitsgrenzen bei kritischen Produktionszuständen.

Noch ein wichtiger Punkt, der unbedingt angemerkt werden muss: Alles was ich hier schreibe ist meine persönliche Meinung und spiegelt auch nur diese wieder 🙂 Diskussionen sind herzlich willkommen! Falls sich der eine oder andere Kollege angesprochen fühlt, natürlich ist alles frei erfunden und Ähnlichkeiten sind rein zufällig… 🙂

„Sitzen wir nicht alle im selben (Software)-Boot?“

Steigen wir also in den vierten Teil der Kolumne ein, in dem ein Thema besprochen wird, welches meiner Meinung nach in nahezu jeder Produktion oder Fertigung, die Software-gesteuert arbeitet, vorkommt: Wo beginnen die Kompetenzgrenzen des Entwicklungsteams, wo enden die Kompetenzen des Maintenance-Teams?

Begonnen hat alles damit, dass das Entwicklungsteam, wie geplant, ein Release deployed hat. Das Deployment lief auch rund, die ersten zwei Monate lief die Anwendung wie erwartet. Nach und nach traten kleine Performance-Probleme zu Tage, da das System nun mehr und mehr Produktionsdaten halten musste. Der Betrieb des Systems wurde von einer anderen Abteilung realisiert. Das Entwicklungsteam hatte dazu einen Deployment-Plan erstellt und diesen, wie auch das Systemarchitekturdiagramm, an die Abteilung, welche den Betrieb realisiert und zu verantworten hat, übergeben.

Es wurden kleinere Bugs gemeldet. Die meisten davon waren fehlerhafte fachliche Daten, da noch die eine oder andere Validierung fehlte – nichts weiter Tragisches. Wir waren in der Lage, innerhalb von wenigen Stunden Bugfixes einzuspielen.

Die Meldungen über mangelnde Performance wurden jedoch nach und nach häufiger und wurden auch mit höherer Priorität eingestellt. Wir haben daraufhin den Anwendungscode auf Fehler geprüft, die SQL-Statements intensiv profiled, mittels FindBugs, PMD und Co. Versucht, Hotspots zu finden und weiter einzugrenzen. Fehler konnten wir keine entdecken, bis wir die Laufzeit der SQL-Statements manuell mittels eines DB-Tools geprüft hatten. Und siehe da: wie so oft ein Treffer!

So, nun kommen wir also zum erkannten Problem und dem Umgang damit. Wie man sich vorstellen kann, trafen hier nun komplett differente Meinungen aufeinander. Die betreibenden Kollegen verwiesen darauf, das die entwickelnden Kollegen nicht angegeben hätten, wann Indexe, Statistiken und dergleichen innerhalb des Schemas aktualisiert werden müssen. Die entwickelnden Kollegen jedoch gaben mit an, dass dies nur mit entsprechenden Rechten und nur auf Basis der bereits bekannten Produktionsstatistiken realisiert werden kann. Diese Rechte haben die entwickelnden Kollegen nicht, was zuerst einmal auch gut ist.

Schlimm wurde es für den Verantwortlichen, da er sich in einer „Deadlock-Situation“ zwischen den Teams befand und selbst gar nicht in der Lage war, diese aufzulösen. Die komplette Trennung zwischen Entwicklung und Betrieb hat sicherlich ganz klare Vorteile, wenn es darum geht, sauber und entkoppelt zu arbeiten und zu dokumentieren. Es gibt sicherlich noch eine ganze Handvoll weiterer Vorteile. Allerdings, und das sieht man an dem oberen Beispiel sehr gut, kann es eben auch sehr kritisch werden. Letztlich wurde das Problem derart gelöst, dass die Entwicklungsmannschaft die Rechte bekamen, die jeweiligen Indexe und Statistiken anzupassen und zu aktualisieren.

Die Entwicklungsmannschaft fragte danach allerdings, meiner Meinung nach zurecht, was denn dann noch das Maintenance-Team mache. Diese sollten aus Entwicklersicht deutlich proaktiver arbeiten und auch dafür Sorge tragen, dass das DB-System in einem guten Zustand ist. Dazu gehört auch, das QueryLog der DB im Auge zu behalten, genauso wie die Long Running Queries zu analysieren. Gelöst wurde das gesamte Problem letztlich dadurch, dass die Entwicklungsmannschaft, hier ganz pragmatisch, die Probleme auf althergebrachte Weise lösen konnte, nämlich durch Debugging von der Anwendung in die Infrastruktur.

[ header = Seite 2: Meine Meinung zu dieser Kontroverse ]

Meine Meinung zu dieser Kontroverse:

Bei klassischen Betriebssetups ist die Trennung einfach falsch. Alle, die an solch einem Projekt beteiligt sind, sollten gemeinsam in einem Team arbeiten und auch entsprechende Meetings abhalten. Die Vorteile, die eine Team- bzw. Abteilungstrennung bringt, sind leicht mit den Nachteilen aufzuwiegen. Ich persönlich bin der Meinung, dass die Nachteile deutlich stärker zu gewichten sind. Man verspielt Transparenz sowie einfache Kommunikationswege durch diese Trennung. Informationen gehen verloren. Die eine Abteilung denkt, die andere wird es schon richten, und umgekehrt. Hinzu kommen natürlich Abstimmungsprobleme, Probleme mit Zugriffsrechten auf den Systemen und dergleichen.

Der dogmatische Ansatz, die Trennung zwischen Betrieb und Entwicklung aufrecht zu erhalten, hat sicherlich auch Vorteile (beispielsweise klare Zuständigkeiten und Prozesse, Fokussierung der Entwickler auf die Entwicklung, usw.). Allerdings bin ich der Meinung, dass hier der pragmatische Ansatz, dringend auftretende Probleme schnell und gemeinsam zu lösen, absolut der richtige Weg ist. Entwickler sollten mehr und mehr Verantwortung für den Betrieb übernehmen, Administratoren den Entwicklern mehr auf die Sprünge helfen. Gemeinsam sollten Szenarien wie Continuous Deployment oder gar Continuous Delivery angegangen werden.

Natürlich verschwimmen Zuständigkeitsgrenzen und Kompetenzen, natürlich sind die Werkzeuge und Methoden, mit denen die Abteilungen solche Probleme heutzutage lösen, unterschiedlich. Wenn man aber die Möglichkeit betrachtet, dass diese beiden Welten mehr und mehr verschmelzen, so wird auch der Wissensaustausch schnell die unterschiedlich effizienten Herangehensweisen aufheben, und beide Welten werden danach mehr sein, als sie vorab alleine waren!

Sind wir doch einmal ehrlich zu uns selbst: Wenn man die derzeitige Situation der Softwareentwicklung und der Systeminfrastrukturen beobachtet, sieht man, dass auch in unserer Welt eben diese Grenzen immer mehr verschwimmen.

Warum habe ich dieses Thema nun also gewählt? Weil ich glaube, dass die Trennung des Betriebs und der Entwicklung, wie sie in vielen Projekten realisiert ist, ein Fehler ist. Meiner Meinung nach gehört den entwickelnden Admins bzw. den administrierenden Entwicklern die Zukunft. Buzzwords wie die Continuous Delivery, DevOps und so weiter zeigen uns hier die Richtung!

Würde mir heute jemand die Möglichkeit geben, eine ideale Softwareentwicklungswelt aufzubauen, legte ich sicherlich mein Hauptaugenmerk darauf, Teams interdisziplinär aufzustellen. Es braucht ein ausgewogenes Verhältnis zwischen Betrieb, Entwicklung und Wartung. Wo also bleibt die Ausbildung zum DevOp an den Hochschulen oder in den Ausbildungsbetrieben? Natürlich darf hier auch der DBA niemals vergessen werden!

Ich würde mich sehr über eine anregende Diskussion freuen und hoffe auf reichhaltiges Feedback über die Kommentarfunktion. Denn ich sehe hier sehr, sehr viel Kommunikationsbedarf zwischen diesen „immer weiter verschmelzenden“ Abteilungen!

Leute, wollt ihr mich nun hier alleine mit dem Produktionsrisiko sitzen lassen? Das kann doch nicht euer Ernst sein!

Geschrieben von
Joachim Arrasz
Joachim Arrasz
Joachim Arrasz ist als Software- und Systemarchitekt in Karlsruhe bei der synyx GmbH & Co. KG als Leiter der CodeClinic tätig. Darüber hinaus twittert (@arrasz) und bloggt er gerne (http://blog.synyx.de/)
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.