Im Juni hatten wir das Vergnügen, unseren ersten virtuellen PagerDuty Summit EMEA auszurichten! Zu unseren Rednern gehörten Llywelyn Griffith-Swain, SRE-Manager, und David Jambor, Leiter Systems Engineering bei Vodafone. Sie skizzierten Vodafones Ansatz zur Erreichung unveränderlicher Telemetrie.

David eröffnete die Sitzung mit der Definition der strategischen Ziele von Vodafone. „Unsere Vision ist es, eine technikorientierte Kultur zu schaffen“, erklärte er. „Wir möchten Entwicklungsteams befähigen, eigenständig zu sein. Deshalb stellen wir sie in den Mittelpunkt all unserer Aktivitäten, aber wir wollen sie auch herausfordern – ihr Code muss innerhalb von vier Stunden in die Produktion gehen.“

Zu diesem Zweck entwickelt Vodafone Self-Service-Funktionen, bei denen die Entwicklungsteams selbst bestimmen können, welche Tools und Funktionen sie benötigen und wie sie diese nutzen möchten. Das Endziel besteht darin, Beobachtungs- und Warnfunktionen bereitzustellen, die den Entwicklungsteams mitteilen, was mit dem Code passiert und wie er sich verhält, wenn er in die Produktion übergeht.

„Wir entwickeln eine Menge Tools dafür“, erzählt David. „Wir entwickeln echte kontinuierliche CI/CD mit einem Schwerpunkt auf kontinuierlicher Bereitstellung, die es uns ermöglicht, Code aus einer Sandbox in die Produktionsumgebung zu verschieben. Dies lässt sich jedoch nicht ohne eine unveränderliche Infrastruktur erreichen, die es uns ermöglicht, unveränderliche Beobachtungsmöglichkeiten und Warnmeldungen für Entwicklungsteams bereitzustellen.“

Warum ist unveränderliche Telemetrie wichtig?

Um zu erklären, wie unveränderliche Beobachtbarkeit definiert werden kann, lieferte David uns anhand der Formel 1 eine tolle Analogie.

Stellen Sie sich vor, Sie führen das Rennen an und Ihr Reifen hat eine Reifenpanne, sodass Sie einen Boxenstopp einlegen müssen. Was erwarten Sie von Ihren Ingenieuren – den Reifen reparieren oder ersetzen? Natürlich möchten Sie, dass sie ihn ersetzen, denn Sie möchten so schnell wie möglich wieder ins Rennen einsteigen. Bei Unveränderlichkeit geht es darum, das Kaputte wegzuwerfen und schnell zu ersetzen, anstatt Zeit mit Reparaturversuchen zu verschwenden.

„Unveränderliche Infrastruktur in der IT bedeutet eigentlich, dass Sie nichts ändern sollten, wenn etwas kaputt ist. Es geht viel schneller, es durch etwas Neues zu ersetzen“, erklärt David. „Unveränderliche Observabilität nutzt diesen Ansatz, um eine On-Demand-Funktion bereitzustellen, mit der Sie alles von Anfang bis Ende auf unveränderliche Weise überwachen und alarmieren können.“

Wie Vodafone unveränderliche Telemetrie ermöglicht

Der unveränderliche Ansatz zur Telemetrie würde dazu führen, dass Site Reliability Engineering (SRE)-Teams bei Bedarf neue Überwachungsansätze entwickeln. Llewelyn gab uns ein Beispiel, bei dem drei Entwicklungsteams alle einen Schwellenwert-Fehlerratenmonitor verwenden.

Aber was passiert, wenn ein Team beschließt, einen Fehlerratenmonitor für die Anomalieerkennung zu haben? Anstatt den vorhandenen Monitor zu ersetzen und die anderen Teams zu verärgern, würde das SRE-Team den neuen Monitor entwickeln. Sobald dieser fertig ist, würde das Entwicklungsteam, das ihn angefordert hat, den neuen Monitor verwenden, während die anderen weiterhin den vorhandenen Monitor verwenden.

Llewelyn sprach auch über die Herausforderungen, denen Vodafone bei der Implementierung unveränderlicher Telemetrie gegenüberstand. „Wir haben über 150 Entwickler und verfolgen den DevOps-Ansatz, bei dem Entwickler den Code besitzen müssen, egal ob er sich in der Produktion oder in niedrigeren Umgebungen befindet, einschließlich anschließender Überwachung und Warnmeldungen“, teilte er mit. „Wir müssen auch allen Beteiligten einen sofortigen Überblick über unseren Produktionsstatus geben, um eine digitale Sichtbarkeit zu ermöglichen.“

Er erklärte auch, dass die von ihnen entwickelte Lösung den SRE-Prinzipien der Arbeitsreduzierung entsprechen muss. Da die Lösung aber auch für die Entwickler gedacht ist, müssen sie alle Module und Monitore als Code verfügbar machen und über eine CI-Pipeline implementieren, damit die Entwickler sie bei Bedarf schnell hinzufügen können und Vodafone sich im Falle eines Vorfalls erholen kann.

Das SRE-Team träumte davon, dass ein Entwickler die Release-Pipeline nie verlassen muss, um Überwachung und Alarmierung einzurichten; stattdessen kann er einfach Module aufrufen, die vom Team selbst erstellt wurden. In der Praxis bei Vodafone bedeutet dies, dass das SRE-Team Konfigurationen für Datadog-Monitore und PagerDuty Callouts entwickelt, die in Terraform aufgerufen werden können, um Überwachung und Alarmierung einzurichten. Sollten Entwickler in Zukunft neue Monitore benötigen, würden diese beim SRE-Team angefordert, das sie entwickeln und zur Verfügung stellen würde, und die Entwickler könnten sie dann über Terraform aufrufen.

David beendete die Sitzung mit einer Erklärung, wie PagerDuty in die SRE-Strategie passt. „Das Ziel von SRE ist es, mühsame Arbeit zu eliminieren, damit Zeit für wertvollere Aufgaben wie die Entwicklung von Lösungen bleibt, die die Zukunft zu einem besseren Ort machen. Die Automatisierung von Aufgaben ist hier von entscheidender Bedeutung, und PagerDuty ist das beste Tool für diese Aufgabe, da es Entwicklungsteams näher an ihren Code heranführt und ihnen die Verantwortung überträgt.“

Möchten Sie die gesamte Sitzung verfolgen? Registrieren Sie sich noch heute für Schauen Sie es sich auf Anfrage an (kostenlos!), sowie weitere Kundensitzungen, inklusive Incident Management bei Form3 und wie Sie mit Auto Trader UK und Gousto die Betriebseffizienz steigern.