Untersuchungen in der IT-Branche haben wiederholt gezeigt, dass DevOps-orientierte Teams, die Software schnell und effektiv ausliefern können, ihre langsameren Kollegen in Bezug auf Unternehmensrentabilität, Marktanteil und praktisch jede andere wichtige Wettbewerbskennzahl regelmäßig übertreffen. Diese Art von Erfolg ist auf die Umstrukturierung von Teams zurückzuführen, die es ihnen ermöglichen, schneller zu agieren und näher an ihren Kunden zu sein. Eine der größten Herausforderungen für bestehende Teams besteht jedoch darin, genau zu verstehen, wie sie von ihrem heutigen Stand in diese wettbewerbsfähigeren Strukturen übergehen können.

Der Folge Mitte Februar des Page It bis zum Limit Der Podcast hilft Ihnen dabei.

Vollständiger Service

Bei PagerDuty nennen wir diese Art von Betriebsmodell „ Vollständiger Service .“ Das ist eine elegante Art zu sagen, dass Service Ownership einen umfassenden Ansatz (auch „Full-Service“ genannt) erfordert. Um flexibel zu sein, müssen Softwarebereitstellungs- und -betriebsteams die vollständige Kontrolle über jeden Aspekt der von ihnen unterstützten Services haben: von Design und Entwicklung über den Produktionsbetrieb bis hin zur endgültigen Einstellung ihrer Software.

Schnell zu sein bedeutet in der Regel, klein zu sein. Oder vielmehr bedeutet es, dass die Tiefe, die erforderlich ist, um die Software- und Liefervorgänge vollständig zu besitzen, so groß ist, dass der notwendige Kompromiss darin besteht, die Oberfläche der Verantwortung dieses Teams zu reduzieren (siehe: die Popularität von Mikrodienste ).

Das Problem für die meisten Organisationen, die schon ein paar Jahre alt sind, ist, dass dies einfach nicht die Art ist, wie sie arbeiten. In den späten 2000er und frühen 2010er Jahren verleiteten die Skaleneffekte viele Unternehmen dazu, ihre IT-Abläufe in größeren und konsolidierteren Monolithen zu zentralisieren. Die größere Größe sparte zwar Kosten, verlangsamte jedoch die Leistung erheblich, was kleineren, flexibleren Unternehmen den Weg ebnete, etablierte Branchengrößen zu verdrängen.

Viele dieser etablierten Unternehmen haben nun Schwierigkeiten herauszufinden, wie sie ihre monolithischen Organisationen in kleinere, agilere Komponenten umgestalten können. Wir werden vielleicht besser darin, monolithische Webanwendungen in Microservices umzugestalten, aber wie können wir zentralisierte IT-Teams mit seit langem etablierten Silos und Aufgabentrennungen in funktionsübergreifende Full-Service-Eigentümer umgestalten?

PagerDuty Ops-Anleitungen

Das PagerDuty Community-Team schreibt eine Reihe von Ops-Anleitungen : Handbücher, die komplexe und groß angelegte Verfahrensaufgaben in mundgerechte Konzepte zerlegen und konkrete Methoden enthalten, mit denen Sie üben können, wie es gemacht wird. Diese Anleitungen sind produktunabhängige Rahmenwerke, die sich darauf konzentrieren, sowohl grundlegende Theorie als auch pragmatische Praxis zu vermitteln. Normalerweise tun sie das, indem sie Ihnen zeigen, wie sowohl PagerDuty als auch unsere Kunden gängige betriebliche Herausforderungen bewältigt haben.

Unsere neue Version des Leitfaden für den Full-Service-Betrieb von Ownership Ops bietet einen detaillierten Einblick in die Konzepte hinter dem Aufbau funktionsübergreifender Teams, die die den gesamten Software-Lebenszyklus eines Dienstes. Es bietet Ihnen auch konkrete, umsetzbare Schritte, die Sie unternehmen können, um Teamstrukturen neu zu definieren und diese neuen Teams vorzubereiten, um häufige Fehler zu vermeiden.

Die Neugestaltung von Teamstrukturen ist in der Regel Teil der meisten Initiativen zur digitalen Transformation. Während solcher Vorhaben beginnen die Teams, darüber nachzudenken, wie sie die Full-Service-Ownership-Strategie genau angehen. Der neue Ops Guide zeigt zunächst, wie man einen messbaren Business Case zur Unterstützung von Full-Service-Ownership-Teams erstellt.

Der nächste Schritt besteht darin, die spezifischen Grenzen eines bestimmten „Dienstes“ zu definieren. Ein Dienst ist eine eigenständige Funktion, die einen Mehrwert bietet und vollständig einem Team gehört. Diese Aussage ist recht umfangreich (für eine ausführlichere Erläuterung siehe den Leitfaden), aber die Quintessenz ist, dass ein wichtiger erster Schritt darin besteht, zu einem gemeinsamen Verständnis der Grenzen eines bestimmten Dienstes zu gelangen und herauszufinden, wer seine wichtigsten Stakeholder sind. Der Leitfaden enthält einige wichtige Überlegungen zur Bestimmung dieser Grenzen in Ihrer Organisation.

Anschließend beschreiben wir alle einzelnen Funktionsrollen, die zur Unterstützung eines Full-Service-Ownership-Modells erforderlich sind. Anstatt diese Rollen nach Berufsbezeichnungen zu benennen (z. B. Softwareentwickler besitzen dieses Teil, Produktmanager besitzen dieses usw.), listet der Leitfaden Funktionen auf, die in der Gesamtstruktur des Teams berücksichtigt werden müssen. Einige Organisationen entscheiden sich dafür, jedem Team Personen mit diesen Fähigkeiten zuzuweisen, während andere eingebettete Rollen erstellen, bei denen Personen in funktionsübergreifenden Teams ihre Zeit auf mehrere Teams aufteilen, um diese Fähigkeiten einzubringen. Wie auch immer Ihre Organisation sich entscheidet, wichtig ist, dass die in diesem Leitfaden beschriebenen Funktionen in jedem Full-Service-Ownership-Team klar angesprochen und verwaltet werden.

Der Abschnitt „Lebenszyklus eines Dienstes“ beschreibt verschiedene Überlegungen, die in jeder Phase der Softwarebereitstellung und des Betriebsprozesses zu berücksichtigen sind: Entwurf, Laufzeit und Ablauf. Der Abschnitt zu Eskalationsrichtlinien beschreibt einen häufigen Problembereich für Softwareentwicklungsteams, die ihre Software noch nie zuvor in der Produktion eingesetzt haben: Wie gestaltet man einen Prozess, um zu reagieren, wenn etwas schief geht? Der Abschnitt zu Bereitschaftsschichten bereitet die Teams dann darauf vor, zum ersten Mal Bereitschaftsdienst zu leisten.

Wie alle unsere Ops Guides ist dies kein verbindliches Flussdiagramm mit genauen Schritten. Stattdessen handelt es sich um eine Einführung in praktische Überlegungen, Listen mit Fragen, die Sie beantworten müssen, um einen detaillierten Plan zum Erstellen Ihres eigenen Prozesses vorzubereiten, und Beispiele dafür, wie Unternehmen wie PagerDuty dieselben Arten von Prozessen erstellt haben. Ops Guides sind Frameworks, die dazu dienen, Ihrem Unternehmen beim Start zu helfen, indem sie die Erfahrungen weitergeben, die wir beim Antreten dieser Wege gemacht haben.

Page It bis zum Limit

Wir hat einen neuen Podcast gestartet , Page It to the Limit, im Dezember (danke fürs Zuhören und die Unterstützung!). Ziel dieses Podcasts ist es, in mundgerechten, leicht zugänglichen Häppchen über die üblichen Herausforderungen zu sprechen, mit denen wir alle konfrontiert sind, wenn wir Software in der Produktion ausführen. Normalerweise tun wir das, indem wir in kurzen 30-minütigen Abschnitten Gäste aus vielen verschiedenen Facetten der IT-Branche interviewen.

Letzte Woche haben wir eine Episode anderer Art veröffentlicht. Scott McAllister und ich haben uns zusammengesetzt, um über Full-Service-Ownership zu sprechen, was es bedeutet, wie man diesen Leitfaden verwendet und was wir im Laufe seiner Entwicklung gelernt haben. Diese Episode ist eine kurze Einführung in einen ausführlicheren Leitfaden. Sehen Sie ihn sich hier an:

Wenn Sie genauer wissen möchten, wie Sie leistungsfähigere, agilere Softwarebereitstellungs- und Betriebsteams aufbauen können, die Ihnen dabei helfen, wettbewerbsfähige Geschäftsergebnisse zu erzielen, lesen Sie den Leitfaden für den Full-Service-Betrieb von Ownership Ops .

Teilen Sie uns Ihre Meinung zum Ops Guide oder zum Podcast auf Twitter mit. @PageIt2theLimit .