Blog

Die Perspektive eines Entwicklers

von Eric Sigler 11. April 2017 | 4 Minuten Lesezeit

„Zum Operationsraum zu gehen – ich habe nicht mehr das Gefühl, dass ich das jemals wieder tun muss.“

Im Vorfeld unserer neueste Version mit neuen Funktionen für Entwickler Ich setzte mich hin mit David Yang , ein leitender Ingenieur hier bei PagerDuty , der die Entwicklung unserer internen Architektur von einer einzigen monolithischen Codebasis zu Dutzenden von Mikrodienste Er ist der technische Leiter unseres Incident-Management-Teams (People), das die Dienste verantwortet, die Benachrichtigungen an alle über 8.000 PagerDuty Kunden ausliefern. Wir haben uns zusammengesetzt und über das Leben nach dem Wechsel zu PagerDuty gesprochen. Teams, die für den Betrieb ihrer Dienste verantwortlich sind. Hier sind Einige Beobachtungen zu den Vor- und Nachteilen, die wir festgestellt haben:

Zum Leben jetzt, wo Teams ihre Dienste selbst besitzen:

Seit der Umstellung auf ein Modell, bei dem Entwickler ihre Dienste selbst verwalten, genießen sie deutlich mehr Unabhängigkeit. Ein positiver Nebeneffekt ist, dass wir die Schwierigkeiten bei der Bereitstellung und Verwaltung der Infrastruktur minimiert haben. Das Team möchte nun die Anzahl der Hindernisse und Blockaden so gering wie möglich halten. Die unterstützenden Infrastrukturteams arbeiten daran, bessere Self-Service-Tools bereitzustellen, um den Bedarf an menschlichen Eingriffen zu reduzieren.

Der Übergang zu Die Entwickler besitzen ihren Code. verkürzt die Zykluszeit von dem Moment an, in dem jemand sagt: „Das ist ein Problem“, bis zu dem Zeitpunkt, an dem er das Problem tatsächlich beheben kann, was sich als unschätzbar wertvoll erwiesen hat.

Zum Thema Kulturwandel:

Indem man den Mitarbeitern mehr Verantwortung für den Code und generell mehr Verantwortung für die von ihnen betriebenen Systeme überträgt, fördert man eine Kultur, die darauf ausgerichtet ist, Hindernisse frühzeitig zu beseitigen. Jedes Team optimiert sich darauf, zukünftige Blockaden zu vermeiden. Blockaden werden viel deutlicher sichtbar. Früher musste ich jedes Mal die IT-Abteilung fragen, wenn wir Hosts bereitstellen wollten, und habe das einfach hingenommen. Jetzt erkennt mein Team seine eigenen Hindernisse besser, weil sie nicht mehr von den Problemen anderer Teams verdeckt werden.

Wir haben Teams, die sich viel stärker darauf konzentrieren, den gesamten Prozess der Wertschöpfung für den Kunden von Anfang bis Ende selbst in die Hand zu nehmen, was von unschätzbarem Wert ist.

Wie dies dabei helfen kann Reaktionsprozess auf Vorfälle :

Die Zuständigkeiten für die Services sind klarer definiert. Es ist einfacher festzustellen, welche Teams bei Betriebsstörungen betroffen sind. Und die Tatsache, dass ich die genaue Vorgehensweise kenne – eine Art objektive Checkliste – ist großartig. So kann ich mich voll und ganz auf die Problemlösung konzentrieren und muss mich nicht mit den Details herumschlagen. Kommunikation rund um den Vorfall.

Was nicht so gut funktioniert hat:

Das soll nicht heißen, dass der Betrieb eines Dienstes nicht auch seine eigenen Probleme mit sich bringt. Er erfordert dedizierte Zeit für die operative Wartung unserer Dienste. Dies beansprucht letztendlich mehr Zeit des Teams, was insbesondere bei älteren Diensten problematisch ist, da hier Wissenslücken bestehen können. Anfangs haben wir nicht genügend Schutzmechanismen implementiert, um die Betriebsbereitschaftsarbeiten in unseren Sprints abzusichern. Dies wird nun durch die Nutzung von … verbessert. KPIs [wie beispielsweise spezifische Skalierungsziele und operative Auslastungsgrade], um uns objektive Entscheidungen zu ermöglichen.

Mit Blick auf die Zukunft:

[Bezüglich der Balance zwischen betriebsbezogener Arbeit und Feature-Entwicklungsarbeit] fragen sich die Teams: „Wie kann ich all das im Alltag optimal nutzen? Wie kann ich noch objektivere Entscheidungen treffen?“ – und steuern diese objektiven Entscheidungen mithilfe von Kennzahlen zu.

In unserer Produktentwicklung wird alles anhand von Kriterien wie „Kundennutzen“ und „Erfolgskriterien“ definiert. Ich denke, der Versuch, die operative Arbeit im gleichen Sinne zu beschreiben, erleichtert die effektive Priorisierung. Wir sitzen alle im selben Boot und verfolgen das gleiche Ziel: unseren Kunden Mehrwert zu bieten. Und irgendwann müssen wir die unterschiedlichen Prioritäten abwägen.

Der Versuch, Veränderungen im operativen Bereich einer Organisation umzusetzen, erfordert viel Zusammenarbeit. Dazu gehört auch, die richtigen Kennzahlen zu ermitteln und diese zu diskutieren.

 

 


Bild: ' Lupe „ ist urheberrechtlich geschützt (c) 2013 Todd Chandler“