Wer kennt die meist problematische Beziehung zwischen Entwicklung und Betrieb nicht?
Die Entwicklung entwickelt, der Betrieb betreibt. Dabei geht einiges schief und schnell ist die Stimmung im Keller und es kommt zu gegenseitige Anschuldigungen:
- “Die Entwicklung liefert immer nur Mist!” sagt der genervte Admin, der durch einen Alarm letzte Nacht aus dem Bett geworfen wurde. “Die sind einfach zu fault & doof richtig zu testen!”.
- “Ich kann ja gar nicht richtig testen, es fallen immer wieder drei beliebige Bits im Loadbalancer um. Natürlich nur in Produktion! Und die Logfiles bekomme ich auch nur nach ewigen Diskussionen. Wie soll ich da testen?” erwiedert der empörte Entwickler.
- “Das kann doch nicht sein! Ich dreh langsam durch – muss das immer in meinen Projekten passieren?” jammert der Projektleiter (= ich).
Das sich diese traurige Szene nicht immer wiederholen muss zeigt das Beispiel Flickr: Mit oft mehr als 10 Neuinstallationen auf den Serverfarmen im laufenden Betrieb scheint Flickr einen Modus Operandi gefunden zu haben, in dem produktiv gearbeitet werden kann.
Credo:
Ops who think like devs. Devs who think like ops. Mit dem Hinweis, dass es nicht der Job des Betriebs ist, die Applikationen stabil und sicher zu betreiben – sondern den Geschäftsbetrieb zu ermöglichen bzw. das Geschäft zu ermöglichen. Ist übrigens auch Aufgabe der Entwicklung!
Mehr dazu in einer schönen Präsentation:
Zu den vorgestellten Ansätzen/Werkzeugen gehören:
- Automatisierte Infrastruktur
- Versionskontrolle (shared)
- Einstufiger Build-Prozess
- Einstufiger Build- und Deploy-Prozess
- Feature Flags – es gibt nur den Trunk!
- Gemeinsame Metriken
- IRC und IM Robots (“Dev, Ops & robots having a conversation”)
Hervorgehoben wird jedoch die Rolle der Kultur, der Umgangsformen:
- Respekt
- Vertrauen
- Gesunde Einstellung hinsichtlich Fehlschlägen (Fehler passieren)
- Keine Schuldzuweisungen
Viel Spass beim anschauen!