Infrastruktur als Code: So überwinden Sie Probleme mit XP

Hallo Habr! Zuvor habe ich mich über das Leben in der Infrastruktur als Code-Paradigma beschwert und nichts angeboten, um diese Situation zu lösen. Heute bin ich zurückgekommen, um Ihnen zu sagen, welche Ansätze und Praktiken dazu beitragen werden, aus dem Abgrund der Verzweiflung auszubrechen und die Situation in Ordnung zu bringen.



Im vorherigen Artikel „Infrastruktur als Code: erste Bekanntschaft“ habe ich meinen Eindruck von diesem Bereich geteilt, versucht, über die aktuelle Situation in diesem Bereich nachzudenken, und sogar vorgeschlagen, dass Standardpraktiken, die allen Entwicklern bekannt sind, helfen können. Es mag scheinen, dass es viele Beschwerden über das Leben gab, aber es gab keine Vorschläge, um aus dieser Situation herauszukommen.

Wer wir sind, wo wir sind und welche Probleme wir haben

Wir sind jetzt im Sre Onboarding Team, das aus sechs Programmierern und drei Infrastrukturingenieuren besteht. Wir alle versuchen, Infrastructure as Code (IaC) zu schreiben. Wir tun dies, weil wir im Prinzip Code schreiben können und in der Geschichte Entwickler des Levels „überdurchschnittlich“ sind.

• Wir haben eine Reihe von Vorteilen: einen bestimmten Hintergrund, Kenntnisse der Praktiken, die Fähigkeit, Code zu schreiben, den Wunsch, neue Dinge zu lernen.
• Und es gibt einen durchhängenden Teil, es ist auch ein Minus: ein Mangel an Wissen über Infrastrukturmaterial.

Die Schlussfolgerung aus meinem letzten Artikel lautete: Ich habe versucht, Optimismus (vor allem in mir selbst) zu wecken. Ich wollte sagen, dass wir die uns bekannten Ansätze und Praktiken ausprobieren werden, um mit den Schwierigkeiten und Schwierigkeiten in diesem Bereich umzugehen.

Wir haben jetzt mit diesen IaC-Problemen zu kämpfen:

• Unvollkommenheit von Werkzeugen, Tools zur Codeentwicklung.
• Langsame Bereitstellung. Die Infrastruktur ist Teil der realen Welt und kann langsam sein.
• Mangel an Ansätzen und Praktiken.
• Wir sind neu und wissen nicht viel.

Extreme Programming (XP) zur Rettung

Alle Entwickler sind mit extremer Programmierung (XP) und den dahinter stehenden Praktiken vertraut. Viele von uns haben an diesem Ansatz gearbeitet, und er war erfolgreich. Warum also nicht die dort festgelegten Grundsätze und Praktiken nutzen, um die Schwierigkeiten der Infrastruktur zu überwinden? Wir haben uns entschlossen, diesen Ansatz anzuwenden und zu sehen, was passiert.


Schauen wir uns einige Vorgehensweisen von XP an und wie sie sich auf die Geschwindigkeit und Qualität des Feedbacks auswirken.

XP-Rückkopplungsschleifenprinzip

Nach meinem Verständnis ist Feedback die Antwort auf die Frage, mache ich es richtig, gehen wir dorthin? In XP gibt es diesbezüglich ein göttliches kleines Schema: eine Zeitrückkopplungsschleife. Das Interessante ist, dass je niedriger wir sind, desto schneller wir ein Betriebssystem bekommen können, um die notwendigen Fragen zu beantworten.



Dies ist ein ziemlich interessantes Diskussionsthema, bei dem es in unserer IT-Branche möglich ist, schnell ein Betriebssystem zu erhalten. Stellen Sie sich vor, wie schmerzhaft es ist, ein Projekt ein halbes Jahr lang durchzuführen, und stellen Sie erst dann fest, dass am Anfang ein Fehler gemacht wurde. Dies geschieht beim Entwurf und bei jeder Konstruktion komplexer Systeme.

In unserem Fall hilft uns IaC beim Feedback. Sofort nehme ich eine kleine Anpassung an das obige Diagramm vor: Wir haben keinen monatlichen Release-Plan, sondern kommen mehrmals am Tag vor. Einige Praktiken sind an diesen Betriebssystemzyklus gebunden, den wir genauer untersuchen werden.

Wichtig: Feedback kann die Lösung für alle oben genannten Probleme sein. Zusammen mit XP-Praktiken kann es Verzweiflung aus dem Abgrund ziehen.

Wie Sie aus dem Abgrund der Verzweiflung herauskommen: drei Übungen

Tests

Tests werden in der XP-Rückkopplungsschleife zweimal erwähnt. Es ist nicht nur das. Sie sind äußerst wichtig für alle extremen Programmiertechniken.

Es wird davon ausgegangen, dass Sie Einheiten- und Abnahmetests haben. Einige geben Ihnen in wenigen Minuten Feedback, andere in wenigen Tagen, da sie länger geschrieben sind und weniger häufig ausgeführt werden.

Es gibt eine klassische Testpyramide, die zeigt, dass es mehr Tests geben sollte.



Wie trifft dieses Schema auf uns in einem IaC-Projekt zu? Eigentlich ... nichts.

• Unit-Tests können trotz der Tatsache, dass es viele davon geben sollte, nicht sehr viele sein. Oder sie testen sehr indirekt etwas. In der Tat können wir sagen, dass wir sie überhaupt nicht schreiben. Aber hier sind einige Anwendungen für solche Tests, die wir noch geschafft haben:
  
  
  1. Code auf jsonnet testen. Dies ist zum Beispiel unsere Pipeline-Montage in Drohnen, was ziemlich kompliziert ist. Der jsonnet-Code wird durch Tests gut abgedeckt.
     Wir verwenden dieses Unit-Test-Framework für Jsonnet .
  2. Testet auf Skripte, die beim Start der Ressource ausgeführt werden. Skripte in Python und daher Tests für sie können geschrieben werden.
• Eine Überprüfung der Konfiguration in Tests ist möglicherweise möglich, wir jedoch nicht. Es ist auch möglich, die Überprüfung der Ressourcenkonfigurationsregeln über tflint zu konfigurieren. Nur für Terraform gibt es zu grundlegende Überprüfungen, aber viele Testskripte sind für AWS geschrieben. Und wir sind auf Azure, daher ist dies wieder nicht geeignet.
• Komponentenintegrationstests: Dies hängt davon ab, wie Sie sie klassifizieren und wo Sie sie ablegen. Aber sie funktionieren im Grunde.
  
  So sehen Integrationstests aus.
  
  
  
  Dies ist ein Beispiel für das Zusammenstellen von Bildern in Drone CI. Um sie zu erreichen, müssen Sie 30 Minuten warten, bis das Packer-Image erfasst wurde, und dann weitere 15 Minuten warten, bis sie verstrichen sind. Aber sie sind es!
  
  
  Bildvalidierungsalgorithmus

  1. Zunächst muss Packer das Bild vollständig vorbereiten.
  2. Neben dem Test befindet sich eine Terraform mit einem lokalen Status, mit der wir dieses Image bereitstellen.
  3. Bei der Bereitstellung wird ein kleines Modul verwendet, das daneben liegt, damit Sie leichter mit dem Image arbeiten können.
  4. Wenn die VM über das Image bereitgestellt wird, können Sie mit der Überprüfung beginnen. Die Kontrollen werden meist mit dem Auto durchgeführt. Es wird überprüft, wie Skripte beim Start funktionieren und wie Dämonen funktionieren. Dazu gehen wir über ssh oder winrm zu dem Computer, der gerade ausgelöst wurde, und überprüfen den Status der Konfiguration oder ob die Dienste gestiegen sind.

  
  
• Eine ähnliche Situation bei Integrationstests und in Modulen für Terraform. Hier ist eine kurze Tabelle, in der die Merkmale solcher Tests erläutert werden.
  
  
  
  Pipeline-Feedback im Bereich von 40 Minuten. Alles dauert sehr lange. Es kann für die Regression verwendet werden, aber für eine neue Entwicklung ist es im Allgemeinen unrealistisch. Wenn Sie sich wirklich darauf vorbereiten und laufende Skripte vorbereiten, können Sie diese auf 10 Minuten reduzieren. Dies sind jedoch immer noch keine Unit-Tests, bei denen es sich um 100 Teile in 5 Sekunden handelt.

Das Fehlen von Unit-Tests während der Zusammenstellung von Bildern oder Modulen der Terraform ermutigt dazu, die Arbeit auf separate Dienste zu verlagern, die einfach von REST abgerufen werden können, oder auf Python-Skripte.

Zum Beispiel mussten wir es so gestalten, dass sich die virtuelle Maschine beim Start im ScaleFT- Dienst registriert und sich selbst löscht , wenn sie zerstört wird.

Da ScaleFT ein Service ist, müssen wir über die API damit arbeiten. Es wurde ein Wrapper geschrieben, den Sie ziehen und sagen können: "Kommen Sie herein und löschen Sie dies, das." Es speichert alle notwendigen Einstellungen und Zugriffe.

Wir können bereits normale Tests dafür schreiben, da es sich in keiner Weise von gewöhnlicher Software unterscheidet: Einige Apiha werden nass, Sie ziehen und schauen, was passiert.

Testergebnisse: Unit-Tests, die das Betriebssystem in einer Minute erhalten sollten, geben es nicht. Und höhere Arten von Tests in der Pyramide bewirken einen Effekt, aber nur ein Teil der Probleme wird abgedeckt.

Paarprogrammierung

Tests sind natürlich gut. Sie können viele von ihnen schreiben, sie können von verschiedenen Arten sein. Sie werden auf ihrem Niveau arbeiten und uns Feedback geben. Das Problem mit schlechten Unit-Tests, die das schnellste Betriebssystem ergeben, bleibt jedoch bestehen. Gleichzeitig wünscht er sich weiterhin ein schnelles Betriebssystem, es ist einfach und angenehm, damit zu arbeiten. Ganz zu schweigen von der Qualität der Lösung. Glücklicherweise gibt es Techniken, die noch schnelleres Feedback geben als Unit-Tests. Dies ist Paarprogrammierung.

Beim Schreiben von Code möchte ich so schnell wie möglich Feedback zu seiner Qualität erhalten. Ja, Sie können alles in den Feature-Zweig schreiben (um niemandem etwas zu verderben), eine Pull-Anfrage im Github stellen, sie jemandem zuweisen, dessen Meinung Gewicht hat, und auf eine Antwort warten.

Aber du kannst lange warten. Die Leute sind alle beschäftigt, und die Antwort, auch wenn sie es ist, ist möglicherweise nicht von höchster Qualität. Angenommen, die Antwort kam sofort, der Rezensent hat die ganze Idee sofort verstanden, aber die Antwort kommt nachträglich immer noch verspätet. Aber ich möchte etwas früher. Hier ist die Paarprogrammierung und zielt darauf ab - also sofort zum Zeitpunkt des Schreibens.

Im Folgenden sind die Programmierstile für Paare und ihre Anwendbarkeit bei der Arbeit an IaC aufgeführt:

1. Klassischer, erfahrener + erfahrener Timerwechsel. Zwei Rollen - Fahrer und Navigator. Zwei Leute. Sie arbeiten an einem Code und wechseln nach einer bestimmten vorgegebenen Zeit die Rollen.

Betrachten Sie die Kompatibilität unserer Probleme mit dem Stil:

• Problem: Unvollkommenheit von Werkzeugen, Werkzeuge für die Codeentwicklung.
  Negative Auswirkung: Um sich länger zu entwickeln, verlangsamen wir uns, das Tempo / der Rhythmus der Arbeit verirrt sich.
  Wie man kämpft: Wir verwenden eine andere Abstimmung, eine gemeinsame IDE und lernen immer noch Verknüpfungen.
• Problem: Langsame Bereitstellung.
  Negative Auswirkung: Erhöht die Zeit zum Erstellen eines funktionierenden Codeteils. Wir vermissen beim Warten, Hände werden gezogen, um etwas anderes zu tun, während Sie warten.
  Wie zu kämpfen: nicht überwunden.
• Problem: Mangel an Ansätzen und Praktiken.
  Negativer Effekt: Es gibt kein Wissen darüber, wie man Gutes tut, aber wie schlecht. Erweitert das Feedback.
  Wie man kämpft: Der Austausch von Meinungen und Praktiken bei der Paarung löst das Problem fast.

Das Hauptproblem bei der ungleichmäßigen Anwendung dieses Stils auf IaC. In der traditionellen Softwareentwicklung haben Sie eine sehr gleichmäßige Bewegung. Sie können fünf Minuten verbringen und N schreiben. Verbringen Sie 10 Minuten und schreiben Sie 2N, 15 Minuten - 3N. Hier können Sie fünf Minuten verbringen und N schreiben, und dann weitere 30 Minuten und ein Zehntel von N schreiben. Hier wissen Sie nichts, Sie haben einen Knebel, einen Dummkopf. Der Versuch braucht Zeit und lenkt von der Programmierung selbst ab.

Fazit: In seiner reinen Form passt es nicht zu uns.

2. Tischtennis. Bei diesem Ansatz wird davon ausgegangen, dass ein Teilnehmer einen Test schreibt und der andere eine Implementierung für ihn durchführt. Da bei Unit-Tests alles kompliziert ist und Sie einen langen Integrationstest schreiben müssen, verschwindet die ganze Ping-Pong-Leichtigkeit.

Ich kann sagen, dass wir versucht haben, die Verantwortlichkeiten für das Entwerfen eines Testskripts und das Implementieren von Code dafür zu trennen. Ein Teilnehmer kam auf ein Drehbuch, in diesem Teil der Arbeit, für die er verantwortlich war, hatte er das letzte Wort. Und der andere war für die Umsetzung verantwortlich. Es hat gut geklappt. Die Qualität des Szenarios mit diesem Ansatz steigt.

Schlussfolgerung: Leider erlaubt das Arbeitstempo nicht die Verwendung von Ping-Pong als Praxis der Paarprogrammierung in IaC.

3. Starker Stil. Schwieriges Üben . Die Idee ist, dass ein Teilnehmer ein Verzeichnisnavigator wird und der zweite die Rolle eines ausführenden Treibers übernimmt. In diesem Fall das Recht, Entscheidungen ausschließlich mit dem Navigator zu treffen. Der Treiber druckt nur und kann mit einem Wort beeinflussen, was passiert. Die Rollen ändern sich lange nicht.

Gut geeignet für das Training, erfordert aber starke Soft Skills. Darauf sind wir ins Stocken geraten. Die Technik war schwierig. Und hier geht es nicht einmal um Infrastruktur.

Fazit: Möglicherweise kann es angewendet werden, wir geben Versuche nicht auf.

4. Mobbing, Schwärmen und alle bekannten, aber hier nicht aufgeführten Stile werden nicht berücksichtigt, weil habe nicht versucht und darüber im Rahmen unserer Arbeit zu sagen, wird nicht funktionieren.

Allgemeine Ergebnisse zur Verwendung der Paarprogrammierung:

• Wir haben ein ungleichmäßiges Arbeitstempo, das niederschlägt.
• Wir sind auf unzureichend gute Soft Skills gestoßen. Und der Themenbereich trägt nicht dazu bei, diese Mängel zu überwinden.
• Lange Tests und Probleme mit Werkzeugen machen die Paarentwicklung viskos.

5. Trotzdem gab es Erfolge. Wir haben unsere eigene Konvergenzmethode entwickelt - Divergenz. Ich werde kurz beschreiben, wie es funktioniert.

Wir haben regelmäßige Partner für mehrere Tage (weniger als eine Woche). Wir machen eine Aufgabe zusammen. Für eine Weile sitzen wir zusammen: Einer schreibt, der zweite sitzt und sieht als Support-Team zu. Dann sind wir uns eine Weile nicht einig, jeder macht einige unabhängige Dinge, dann konvergieren wir wieder, synchronisieren sehr schnell, machen etwas zusammen und gehen wieder auseinander.

Planung und Kommunikation

Der letzte Block von Praktiken, durch den Betriebssystemprobleme gelöst werden, ist die Organisation der Arbeit mit den Aufgaben selbst. Dies schließt auch den Erfahrungsaustausch ein, der außerhalb der Paararbeit liegt. Betrachten Sie drei Praktiken:

1. Aufgaben durch den Zielbaum. Wir haben die allgemeine Verwaltung des Projekts durch einen Baum organisiert, der endlos in die Zukunft geht. Technisch ist die Führung bei Miro erledigt. Es gibt eine Aufgabe - es ist ein Zwischenziel. Daraus ergeben sich entweder kleinere Ziele oder Aufgabengruppen. Von ihnen sind die Aufgaben selbst. Alle Aufgaben werden auf diesem Board erstellt und ausgeführt.



Dieses Schema gibt auch Feedback, das einmal am Tag auftritt, wenn wir bei Rallyes synchronisieren. Die Präsenz eines gemeinsamen Plans vor allen ist strukturiert und völlig offen und ermöglicht es jedem, auf dem Laufenden zu bleiben, was passiert und wie weit wir fortgeschritten sind.

Vorteile der visuellen Sicht auf Aufgaben:

• Kausalität. Jede Aufgabe führt zu einem globalen Ziel. Aufgaben werden in kleinere Ziele gruppiert. Die Infrastrukturdomäne selbst ist ziemlich technisch. Es ist nicht immer sofort klar, welche spezifischen Auswirkungen auf das Unternehmen ausgeübt werden, indem beispielsweise ein Rankbook zur Migration auf einen anderen Nginx geschrieben wird. Das Vorhandensein einer nahe gelegenen Zielkarte macht dies deutlicher.
  
  Ursache ist eine wichtige Eigenschaft von Aufgaben. Es beantwortet direkt die Frage: "Mache ich das?"
• Parallelität. Wir sind neun und es ist unmöglich, jeden mit einer Aufgabe einfach physisch anzugreifen. Aufgaben aus einem Bereich sind möglicherweise auch nicht immer ausreichend. Wir sind gezwungen, parallel zwischen kleinen Arbeitsgruppen zu arbeiten. Gleichzeitig sitzen die Gruppen einige Zeit auf ihrer Aufgabe, sie können von jemand anderem gestärkt werden. Menschen fallen manchmal von dieser Arbeitsgruppe ab. Jemand macht Urlaub, jemand macht einen Bericht für die DevOps-Konferenz, jemand schreibt einen Artikel über Habr. Es ist sehr wichtig zu wissen, welche Ziele und Vorgaben parallel erreicht werden können.

2. Veränderbare Moderatoren von Morgenrallyes. Bei Stand-Ups haben wir ein solches Problem - die Leute erledigen viele Aufgaben parallel. Manchmal sind Aufgaben lose miteinander verbunden und es gibt kein Verständnis dafür, wer was tut. Und die Meinung eines anderen Teammitglieds ist sehr wichtig. Dies sind zusätzliche Informationen, die den Verlauf der Problemlösung ändern können. Natürlich ist normalerweise jemand mit Ihnen zusammen, aber Beratung und Tipps sind immer nicht überflüssig.

Um diese Situation zu verbessern, haben wir die Technik des „Änderns des führenden Stand-Ups“ angewendet. Jetzt drehen sie sich auf einer bestimmten Liste, und dies hat Auswirkungen. Wenn es um Sie geht, müssen Sie eintauchen und verstehen, was passiert, um ein Scrum-Meeting gut durchzuführen.



3. Interne Demo. Die Unterstützung bei der Lösung von Problemen durch Paarprogrammierung, Visualisierung im Aufgabenbaum und Hilfe bei Scrum-Rallyes am Morgen ist gut, aber nicht perfekt. Bei einem Paar sind Sie nur durch Ihr Wissen eingeschränkt. Der Aufgabenbaum hilft Ihnen global zu verstehen, wer was tut. Und der Gastgeber und die Kollegen beim Morgentreffen werden nicht tief in Ihre Probleme eintauchen. Sie können sicherlich etwas verpassen.

Die Lösung wurde gefunden, indem die untereinander geleistete Arbeit und ihre anschließende Diskussion demonstriert wurden. Wir treffen uns einmal pro Woche für eine Stunde und zeigen Details zu Lösungen für die Aufgaben, die wir in der letzten Woche erledigt haben.

Während der Demonstration ist es notwendig, die Details der Aufgabe preiszugeben und ihre Arbeit zu demonstrieren.


Nach dem Vollzeit-Teil gibt es immer eine Diskussion im Thread. Hier erscheint das notwendige Feedback zu unseren Aufgaben.


Infolgedessen wird eine Umfrage durchgeführt, um den Nutzen des Geschehens zu ermitteln. Dies ist bereits eine Rückmeldung über das Wesentliche der Rede und die Bedeutung der Aufgabe.

Lange Schlussfolgerungen und was kommt als nächstes?

Es mag scheinen, dass der Ton des Artikels etwas pessimistisch ist. Es ist nicht so. Es funktionieren zwei Basis-Feedback-Ebenen, nämlich Tests und Paarprogrammierung. Nicht so perfekt wie in der traditionellen Entwicklung, aber es gibt einen positiven Effekt daraus.

Tests in ihrer aktuellen Form bieten nur eine teilweise Abdeckung des Codes. Viele Konfigurationsfunktionen werden nicht getestet. Ihr Einfluss auf die direkte Arbeit beim Schreiben von Code ist gering. Integrationstests haben jedoch Auswirkungen, und sie ermöglichen es, Refactorings ohne Angst durchzuführen. Dies ist eine großartige Leistung. Mit der Verlagerung des Fokus auf die Entwicklung in Hochsprachen (wir haben Python, go) verschwindet auch das Problem. Es gibt jedoch viele Überprüfungen des „Klebers“ und es ist keine ausreichend allgemeine Integration erforderlich.

Die Arbeit zu zweit hängt mehr von bestimmten Personen ab. Es gibt einen Aufgabenfaktor und unsere Soft Skills. Es fällt sehr gut mit jemandem aus, schlimmer mit jemandem. Dies hat definitiv einen Vorteil. Es ist klar, dass selbst bei unzureichender Einhaltung der Regeln der Paararbeit die Tatsache der gemeinsamen Ausführung von Aufgaben die Qualität des Ergebnisses positiv beeinflusst. Persönlich ist es für mich einfacher und angenehmer, zusammenzuarbeiten.

Übergeordnete Möglichkeiten zur Beeinflussung des Betriebssystems - Planung und Arbeit mit Aufgaben ergeben genau die Auswirkungen: ein qualitativ hochwertiger Wissensaustausch und eine Verbesserung der Entwicklungsqualität.

Kurze Schlussfolgerungen in einer Zeile

• XP-Praktiken funktionieren im IaC, jedoch mit geringerer Effizienz.
• Stärken Sie, was funktioniert.
• Entwerfen Sie Ihre eigenen Kompensationsmechanismen und -praktiken.