Studien der IT-Branche belegen immer wieder, dass DevOps-orientierte Teams, die Software schnell und effektiv bereitstellen können, ihre langsameren Konkurrenten hinsichtlich Unternehmensrentabilität, Marktanteil und nahezu allen relevanten Wettbewerbskennzahlen regelmäßig übertreffen. Dieser Erfolg basiert auf der Umstrukturierung von Teams, die es ihnen ermöglicht, schneller zu agieren und näher an ihre Kunden heranzurücken. Eine der größten Herausforderungen für bestehende Teams besteht jedoch darin, den Übergang von ihrer aktuellen Situation zu diesen wettbewerbsfähigeren Strukturen zu gestalten.

Der Folge Mitte Februar der Page It to the Limit Der Podcast ist da, um zu helfen.

Vollservice-Eigentum

Bei PagerDuty nennen wir diese Art von Betriebsmodell „ Vollservice-Eigentum Das bedeutet im Klartext, dass die Verantwortung für einen Service einen umfassenden Ansatz erfordert. Um flexibel agieren zu können, müssen Softwareentwicklungs- und Betriebsteams die vollständige Verantwortung für alle Aspekte der von ihnen betreuten Services tragen: von Design und Entwicklung über den Produktionsbetrieb bis hin zur endgültigen Außerbetriebnahme ihrer Software.

Schnelles Handeln bedeutet in der Regel, klein zu bleiben. Oder besser gesagt: Es bedeutet, dass die Tiefe des erforderlichen Fachwissens für die vollständige Kontrolle über Software- und Bereitstellungsprozesse so groß ist, dass der notwendige Kompromiss darin besteht, den Verantwortungsbereich des Teams zu reduzieren (siehe: die Popularität von …). Mikrodienste ).

Das Problem für die meisten Organisationen, die älter als ein paar Jahre sind, ist, dass dies einfach nicht ihrer Arbeitsweise entspricht. Ende der 2000er und Anfang der 2010er Jahre verleiteten Skaleneffekte viele Unternehmen dazu, ihre IT-Abläufe in größeren, stärker konsolidierten Monolithen zu zentralisieren. Die größere Größe mag zwar Kosten gespart haben, verlangsamte aber die Leistung erheblich, was kleineren, agileren Unternehmen den Weg ebnete, etablierte Branchenführer herauszufordern.

Viele dieser etablierten Unternehmen tun sich nun schwer damit, ihre monolithischen Organisationen in kleinere, agilere Einheiten umzustrukturieren. Wir werden zwar immer besser darin, monolithische Webanwendungen in Microservices zu überführen, aber wie gelingt es uns, zentralisierte IT-Teams mit ihren seit Langem bestehenden Silos und der strikten Trennung von Aufgaben in funktionsübergreifende Full-Service-Teams umzuwandeln?

PagerDuty -Einsatzleitfäden

Das PagerDuty Community-Team verfasst eine Reihe von Artikeln. Operationsleitfäden Handbücher, die komplexe und umfangreiche Abläufe in überschaubare Konzepte unterteilen und konkrete Methoden zur praktischen Anwendung bieten. Diese produktunabhängigen Leitfäden vermitteln sowohl theoretische Grundlagen als auch praxisorientierte Vorgehensweisen. Sie zeigen Ihnen, wie PagerDuty und unsere Kunden gängige operative Herausforderungen gemeistert haben.

Unsere neue Version der Leitfaden für den Betrieb eines Full-Service-Unternehmens bietet einen detaillierten Einblick in die Konzepte hinter dem Aufbau funktionsübergreifender Teams, die die Verantwortung für die gesamten Softwarelebenszyklus eines Dienstes. Es bietet Ihnen außerdem konkrete, umsetzbare Schritte, mit denen Sie Teamstrukturen neu definieren und diese neuen Teams darauf vorbereiten können, häufige Fehler zu vermeiden.

Die Neugestaltung von Teamstrukturen ist typischerweise Bestandteil der meisten Initiativen zur digitalen Transformation. Im Rahmen solcher Projekte beginnen Teams zu überlegen, wie sie die vollständige Verantwortung für ihre Services übernehmen können. Der neue Ops Guide zeigt zunächst, wie man einen messbaren Business Case für Teams mit vollständiger Serviceverantwortung erstellt.

Der nächste Schritt besteht darin, die genauen Grenzen eines jeden „Services“ zu definieren. Ein Service ist eine in sich abgeschlossene Funktionalität, die Mehrwert bietet und vollständig im Besitz eines Teams ist. Diese Aussage ist recht komplex (siehe dazu den Leitfaden für eine detailliertere Erläuterung), aber die Kernaussage ist, dass ein erster wichtiger Schritt darin besteht, ein gemeinsames Verständnis der Grenzen eines Services zu entwickeln und die wichtigsten Stakeholder zu identifizieren. Der Leitfaden enthält einige wichtige Punkte, die Sie bei der Festlegung dieser Grenzen in Ihrem Unternehmen berücksichtigen sollten.

Anschließend beschreiben wir alle einzelnen funktionalen Rollen, die für ein umfassendes Verantwortungsmodell erforderlich sind. Anstatt diese Rollen mit Berufsbezeichnungen zu kennzeichnen (z. B. Softwareentwickler sind für diesen Bereich zuständig, Produktmanager für jenen usw.), listet der Leitfaden Funktionen auf, die in der Gesamtstruktur des Teams berücksichtigt werden müssen. Manche Organisationen stellen jedem Team Mitarbeiter mit diesen Kompetenzen zur Verfügung, während andere integrierte Rollen schaffen, in denen Mitarbeiter funktionsübergreifender Teams ihre Arbeitszeit auf mehrere Teams aufteilen, um diese Kompetenzen einzubringen. Wie auch immer Ihre Organisation vorgeht, wichtig ist, dass die in diesem Leitfaden beschriebenen Funktionen in jedem umfassenden Verantwortungsteam klar definiert und den jeweiligen Verantwortlichkeiten zugeordnet sind.

Der Abschnitt zum Lebenszyklus eines Dienstes beschreibt verschiedene Aspekte, die in jeder Phase der Softwareentwicklung und des Betriebs – Design, Laufzeit und Außerbetriebnahme – zu berücksichtigen sind. Der Abschnitt zu Eskalationsrichtlinien behandelt ein häufiges Problem für Softwareentwicklungsteams, die ihre Software noch nie produktiv eingesetzt haben: die Gestaltung eines Prozesses für den Umgang mit Fehlern. Der Abschnitt zu Bereitschaftsdiensten bereitet Teams anschließend auf ihren ersten Bereitschaftsdienst vor.

Wie alle unsere Leitfäden für operative Prozesse ist auch dieser kein starrer Ablaufplan mit exakten Handlungsanweisungen. Vielmehr bietet er eine Einführung in praktische Überlegungen, eine Liste mit Fragen zur Erstellung eines detaillierten Plans für die Entwicklung Ihrer eigenen Prozesse sowie Beispiele dafür, wie Unternehmen wie PagerDuty ähnliche Prozesse implementiert haben. Unsere Leitfäden sind Rahmenwerke, die Ihrem Unternehmen den Einstieg erleichtern sollen, indem sie unsere Erfahrungen aus ähnlichen Projekten weitergeben.

Page It to the Limit

Wir einen neuen Podcast gestartet Im Dezember startete „Page It to the Limit“ (vielen Dank für eure Unterstützung!). Ziel des Podcasts ist es, die typischen Herausforderungen beim produktiven Softwarebetrieb in leicht verständlichen, kurzen Beiträgen zu behandeln. Dazu interviewen wir in der Regel Gäste aus verschiedenen Bereichen der IT-Branche in 30-minütigen Segmenten.

Letzte Woche haben wir eine etwas andere Folge veröffentlicht. Scott McAllister und ich haben uns über die Übernahme eines Full-Service-Unternehmens unterhalten, was das bedeutet, wie man diesen Leitfaden nutzt und was wir bei seiner Entwicklung gelernt haben. Diese Folge ist eine kurze Einführung in einen ausführlicheren Leitfaden. Hier geht's zum Podcast:

Für einen detaillierteren Einblick, wie Sie leistungsfähigere, agilere Softwareentwicklungs- und Betriebsteams aufbauen, die zu wettbewerbsfähigen Geschäftsergebnissen beitragen, schauen Sie sich Folgendes an: Leitfaden für den Betrieb eines Full-Service-Unternehmens Die

Teilt uns eure Meinung zum Ops Guide oder zum Podcast mit, indem ihr uns auf Twitter kontaktiert. @PageIt2theLimit Die