„Der Gang zum Operationssaal – ich habe nicht das Gefühl, dass ich das jemals wieder tun muss.“

Im Vorfeld unserer neueste Version von Funktionen für Entwickler setzte ich mich 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 – ​​People-Teams, das für die Dienste verantwortlich ist, die Warnmeldungen an alle über 8.000 PagerDuty Kunden senden. Wir setzten uns zusammen und sprachen über das Leben nach dem Wechsel zu Teams, die für den Betrieb ihrer Dienste verantwortlich sind. Hier sind einige Beobachtungen zu den Vorteilen und Nachteilen, die wir gesehen haben:

Zum Leben jetzt, da die Teams ihre eigenen Dienste besitzen:

Seit wir zu einem Modell übergegangen sind, bei dem Entwickler ihre Dienste besitzen, gibt es viel mehr Unabhängigkeit von Entwicklern. Ein Nebeneffekt ist, dass wir die Schwierigkeiten bei der Bereitstellung und Verwaltung der Infrastruktur minimiert haben. Jetzt möchte das Team die Zahl der Hindernisse und Blockaden so gering wie möglich halten. Unterstützende Infrastrukturteams sind darauf ausgerichtet, bessere Self-Service-Tools bereitzustellen, um den Bedarf an menschlichem Eingreifen zu minimieren.

Der Wechsel zu Entwickler besitzen ihren Code verkürzt die Zykluszeit von dem Zeitpunkt an, an dem jemand sagt „das ist ein Problem“, bis zu dem Zeitpunkt, an dem das Problem tatsächlich behoben werden kann, was von unschätzbarem Wert ist.

Zum Thema Kulturwandel:

Indem man den Leuten mehr Eigentum am Code gibt und ihnen im Allgemeinen mehr Verantwortung für die Systeme gibt, die sie betreiben, fördert man im Wesentlichen eine Kultur, die stärker darauf ausgerichtet ist, Hindernisse aus dem Weg zu räumen – so als ob jedes Team stärker darauf ausgerichtet wäre, sich zu fragen: „Wie kann ich sicherstellen, dass ich nie wieder blockiert werde?“ oder „Wie kann ich in Zukunft nicht blockiert werden?“ Es ist viel offensichtlicher, wenn wir blockiert werden. Früher musste ich jedes Mal die Betriebsabteilung fragen, wenn wir Hosts bereitstellen wollten, und ich habe es einfach akzeptiert. Jetzt kann mein Team seine Hindernisse besser erkennen, weil sie nicht durch die Hindernisse anderer Teams verdeckt werden.

Wir haben Teams, die sich viel stärker darauf konzentrieren, den gesamten Prozess der Bereitstellung von Kundennutzen von Anfang bis Ende zu beherrschen, was von unschätzbarem Wert ist.

Wie dies helfen kann bei der Vorfallreaktionsprozess :

Es gibt klarere Grenzen für die Serviceverantwortung. Es ist einfacher herauszufinden, welche spezifischen Teams betroffen sind, wenn es ein Betriebsproblem gibt. Und die Tatsache, dass ich das genaue Verfahren kenne, das ich befolgen muss – und es ist eher ein objektives Verfahren nach dem Motto „das ist die Checkliste“ –, ist großartig. Es ermöglicht mir, mich zu 100 % auf die Lösung des Problems zu konzentrieren und nicht auf die Kommunikation rund um den Vorfall.

Zu den Dingen, die nicht so gut funktioniert haben:

Damit will ich nicht sagen, dass der Besitz eines Dienstes nicht auch seine eigenen Probleme mit sich bringt. Es erfordert Zeit, sich um die operative Wartung unserer Dienste zu kümmern. Dies nimmt letztendlich mehr Zeit des Teams in Anspruch, was insbesondere bei Legacy-Diensten ein Problem ist, bei denen Wissenslücken bestehen können. Am Anfang haben wir nicht genügend Schutzmaßnahmen ergriffen, um die Arbeit an der Betriebsfähigkeit in unseren Sprints zu schützen. Dies wird durch die Nutzung von verbessert KPIs [wie etwa spezifische Skalierungsziele und Betriebslastniveaus], um uns objektive Entscheidungen zu ermöglichen.

In der Zukunft:

[Beim Abwägen zwischen betriebsbezogener Arbeit und Funktionsentwicklungsarbeit] fragen sich die Teams: „Wie nutze ich das alles im Alltag? Wie treffe ich noch objektivere Entscheidungen?“ – und sie steuern diese objektiven Entscheidungen mithilfe von Kennzahlen.

Bei unserer Produktentwicklung wird alles unter den Begriffen „Kundennutzen“, „Erfolgskriterium“ usw. definiert. Ich denke, der Versuch, die operative Arbeit im gleichen Sinne zu vermitteln, erleichtert die effektive Priorisierung. Wir sind alle im selben Team und verfolgen dasselbe Ziel, unseren Kunden einen Mehrwert zu bieten. Irgendwann muss man die konkurrierenden Prioritäten auflösen.

Der Versuch, innerhalb einer Organisation Veränderungen im operativen Geschäft herbeizuführen, erfordert viel Zusammenarbeit. Außerdem muss man herausfinden, welche Kennzahlen die richtigen sind, und eine Diskussion über diese Kennzahlen führen.

^{Bild: ' Lupe ” ist Copyright (c) 2013 Todd Chandler}