In unserem Unternehmen läuft der Onboarding-Prozess für das SRE-Team. Ich bin von der Entwicklungsseite in diese Geschichte eingestiegen. Während dieses Prozesses sind mir Gedanken und Insights gekommen, die ich mit anderen Entwicklern teilen möchte. In diesem Artikel reflektiere ich darüber, was passiert, wie es passiert, und wie wir alle künftig damit umgehen können.
Fortsetzung der Artikelreihe, die inspiriert wurde von Vorträgen auf unserer internen Veranstaltung :
2. Infrastructure as Code. (Sie sind hier)
3. Generierung von Typescript-Verträgen basierend auf C#-Modellen. (In Arbeit…)
4. Einführung in den Raft-Konsensalgorithmus. (In Arbeit…)
…
Wir haben beschlossen, ein SRE-Team zu bilden, um die Ideen von zu verwirklichen. Wir haben Programmierer aus unseren eigenen Entwicklern rekrutiert und sie für mehrere Monate zur Weiterbildung entsendet.
Die folgenden Lernziele standen vor dem Team:
- Unsere Infrastruktur, die größtenteils in Microsoft Azure angesiedelt ist, in Form von Code (Terraform und alles, was dazu gehört) zu beschreiben.
- Die Entwickler im Umgang mit der Infrastruktur zu schulen.
- Die Entwickler auf den Bereitschaftsdienst vorzubereiten.
Wir führen das Konzept von Infrastructure as Code ein.
In einem traditionellen Weltmodell (klassisches Management) befinden sich Infrastrukturwissen an zwei Stellen:
- Entweder in Form von Wissen im Kopf von Experten.
- Oder diese Informationen sind auf gewissen Maschinen gespeichert, von denen einige Experten kennen. Es ist jedoch nicht sicher, dass eine externe Person (für den Fall, dass unser gesamtes Team plötzlich ausfällt) verstehen kann, wie alles funktioniert. Auf dieser Maschine können viele Informationen vorhanden sein: Zugriffsrechte, Cron-Jobs, gemountete (siehe ) Festplatte und einfach eine endlose Liste von dem, was geschehen kann. Es ist schwierig zu erkennen, was wirklich vor sich geht.
In beiden Fällen befinden wir uns in einer Falle und werden abhängig:
- entweder von einer Person, die sterblich ist, anfällig für Krankheiten, verliebt, Stimmungsschwankungen unterliegt und einfach gekündigt werden kann;
- oder von einer physisch operierenden Maschine, die ebenfalls ausfallen kann, gestohlen werden kann und unerwartete Herausforderungen und Unannehmlichkeiten mit sich bringt.
Es liegt nahe, dass die ideale Lösung darin besteht, alles in einen menschenlesbaren, wartbaren und qualitativ hochwertigen Code zu übertragen.
So ist Infrastructure as Code (IaC) eine Beschreibung der gesamten vorhandenen Infrastruktur in Form von Code sowie begleitende Werkzeuge zur Bearbeitung und Umsetzung dieser Infrastruktur.
Warum alles in Code übersetzen?Menschen sind keine Maschinen. Sie können sich nicht alles merken. Die Reaktion von Menschen und Maschinen ist unterschiedlich. Alles Automatisierte funktioniert potenziell schneller als das, was Menschen tun. Das Wichtigste ist eine einzige Wahrheitsquelle (single source of truth).
Woher kommen die neuen SRE-Ingenieure?Also, wir haben uns entschieden, neue SRE-Ingenieure einzustellen, aber woher bekommen wir sie? Das Buch mit den richtigen Antworten () sagt uns: von Entwicklern. Schließlich arbeiten sie mit Code, und Sie erreichen den idealen Zustand.
Wir haben lange und intensiv auf dem Arbeitsmarkt außerhalb unseres Unternehmens nach ihnen gesucht. Wir müssen jedoch eingestehen, dass wir keinen einzigen gefunden haben, der unseren Anforderungen entspricht. Wir mussten unter unseren eigenen Mitarbeitern suchen.
Probleme mit Infrastructure as Code
Lasst uns nun Beispiele dafür betrachten, wie Infrastruktur in Code eingebettet werden kann. Der Code ist gut geschrieben, von hoher Qualität, mit Kommentaren und Einrückungen.
Beispielcode aus Terraform.
Beispielcode aus Ansible.
Meine Herren, wenn alles so einfach wäre! Wir leben schließlich in einer realen Welt, die immer bereit ist, uns zu verblüffen und Überraschungen sowie Probleme zu präsentieren. Auch hier kommen wir nicht ohne sie aus.
1. Das erste Problem besteht darin, dass IaC in den meisten Fällen irgendeine Art von DSL ist.
Und ein DSL ist wiederum eine Strukturbeschreibung. Genauer gesagt, was Sie haben sollten: Json, Yaml, Modifikationen von großen Unternehmen, die ihre eigenen DSLs entwickelt haben (in Terraform wird HCL verwendet).
Das Problem ist, dass darin leicht fehlende, uns vertraute Dinge wie:
- Variablen;
- Bedingungen;
- irgendwo fehlende Kommentare, zum Beispiel gibt es in Json standardmäßig keine;
- Funktionen;
- und ich spreche noch nicht einmal von so hochrangigen Dingen wie Klassen, Vererbung und all dem.
2. Das zweite Problem bei solchem Code ist, dass es häufig eine heterogene Umgebung darstellt.Normalerweise arbeiten Sie mit C#, also einer Sprache, einem Stack, einem Ökosystem. Doch hier haben Sie eine riesige Vielfalt an Technologien.
Eine durchaus reale Situation ist, wenn ein Bash-Skript mit Python einen Prozess startet, in den JSON eingefügt wird. Sie analysieren es, und dann erzeugt ein weiterer Generator noch 30 Dateien. Für all dies kommen Eingabevariablen aus dem Azure Key Vault, die über ein Plugin zu drone.io abgerufen werden, das in Go geschrieben ist, und diese Variablen durchlaufen eine YAML-Datei, die aus einem Template-Generator namens Jsonnet erstellt wurde. Es ist ziemlich schwierig, einen klar strukturierten Code zu haben, wenn man eine so vielfältige Umgebung hat.
In der traditionellen Entwicklung arbeiten wir in der Regel mit einer Sprache an einer einzigen Aufgabe. Hier hingegen arbeiten wir mit einer Vielzahl von Sprachen.
3. Das dritte Problem ist das Tooling.. Wir sind es gewohnt, leistungsstarke Editoren (Ms Visual Studio, Jetbrains Rider) zu nutzen, die vieles für uns erledigen. Selbst wenn wir einen Fehler machen, weisen sie uns darauf hin. Das scheint normal und natürlich zu sein.
Aber irgendwo in der Nähe gibt es VSCode, das einige Plugins hat, die installiert werden, gewartet oder eben nicht gewartet werden. Neue Versionen sind erschienen, aber wurden nicht unterstützt. Ein einfacher Übergang zur Implementierung einer Funktion (sofern sie überhaupt vorhanden ist) wird zu einem komplexen und nicht triviale Problem. Eine einfache Umbenennung einer Variable bedeutet ein Ersetzen in dem Projekt über Dutzende von Dateien. Außerdem besteht die Chance, dass das, was man ersetzen möchte, nicht in Ordnung ist. Natürlich gibt es hier und da Syntaxhighlighting, Autovervollständigung und manchmal auch Formatierung (obwohl es bei mir in Terraform unter Windows nicht funktioniert).
Zum Zeitpunkt des Verfassens des Artikels wurde noch nicht veröffentlicht, um Version 0.12 zu unterstützen, obwohl sie bereits seit 3 Monaten veröffentlicht ist.
Es ist Zeit, sich von…
- Debugging.
- Refactoring-Tool.
- Autocomplete.
- Fehlererkennung beim Kompilieren.
Es ist lustig, aber das erhöht die Entwicklungszeit und die Anzahl der unvermeidlichen Fehler.
Das Schlimmste ist, dass wir nicht darüber nachdenken sollten, wie wir die Dateien strukturiert ablegen, sie umsetzen, wartbar und lesbar machen und so weiter, sondern eher darüber, wie ich diesen Befehl korrekt formulieren kann, denn ich habe ihn irgendwie falsch eingegeben.
Als Neuling versuchen Sie, Terraform zu verstehen, und die IDE hilft Ihnen dabei überhaupt nicht. Wenn es Dokumentation gibt – haben Sie sie aufgerufen und angesehen. Aber wenn Sie in eine neue Programmiersprache einsteigen, würde die IDE Ihnen sagen, dass es diesen Typ gibt und jenen nicht. Zumindest auf der Ebene von int oder string. Das kann oft hilfreich sein.
Und wie sieht es mit Tests aus?
Sie fragen sich: „Wie steht es um die Tests, liebe Programmierer?“ Ernsthafte Leute testen alles in der Produktion, und das ist hart. Hier ist ein Beispiel für einen Unit-Test für ein Terraform-Modul von der Website. .
Die haben eine gute Dokumentation. Microsoft hat mir immer wegen ihres Ansatzes zur Dokumentation und Schulung gefallen. Aber man muss kein Onkel Bob sein, um zu erkennen, dass der Code hier nicht perfekt ist. Achten Sie auf die Validierung, die nach rechts verschoben wurde.
Das Problem beim Unit-Test ist, dass wir überprüfen können, ob das Json am Ausgang korrekt ist. Ich habe 5 Parameter übergeben, und ich erhielt einen Json-Output mit 2000 Zeilen. Ich kann analysieren, was hier passiert, das Testergebnis validieren…
Es ist schwierig, JSON in Go zu analysieren. Aber man sollte in Go schreiben, da Terraform in Go eine gute Praxis ist, um in der Programmiersprache, in der man schreibt, auch zu testen. Die Organisation des Codes ist insgesamt sehr schwach. Dennoch ist es die beste Bibliothek für Tests.
Selbst Microsoft schreibt seine Module und testet sie auf diese Weise. Natürlich ist das Open Source. Alles, worüber ich spreche, kann von Ihnen verbessert werden. Ich könnte mich hinsetzen und innerhalb einer Woche alles reparieren, die VS Code-Plugins open sourcen, Terraform anpassen, ein Plugin für Rider erstellen. Vielleicht ein paar Analyzer schreiben, Linter einbinden und zur Testbibliothek beitragen. Ich kann das alles tun. Aber das sollte nicht meine Hauptbeschäftigung sein.
Best Practices für Infrastructure as Code
Lassen Sie uns weitermachen. Wenn es in IaC keine Tests gibt, die IDE schlecht ist und die Werkzeugauswahl unzureichend ist, dann sollten wenigstens die besten Praktiken beachtet werden. Ich habe einfach Google Analytics verwendet und zwei Suchanfragen verglichen: Terraform Best Practices und C# Best Practices.
Was sehen wir? Eine unerbittliche Statistik, die nicht zu unseren Gunsten spricht. In der C#-Entwicklung sind wir einfach überwältigt von Materialien: Wir haben hervorragende Praktiken, es gibt Bücher von Experten und auch Werke, die von anderen Experten verfasst wurden und diese kritisieren. Ein Meer an offizieller Dokumentation, Artikeln, Schulungskursen und jetzt auch noch Open-Source-Entwicklung.
Was die Anfrage zu IaC betrifft: Hier versuchen Sie mühsam, Informationen aus Vorträgen von Highload-Events oder HashiConf, aus der offiziellen Dokumentation und zahlreichen Issues auf GitHub zusammenzutragen. Wie verteilt man diese Module überhaupt, was macht man damit? Es scheint, dass dies ein echtes Problem ist... Es gibt eine Community, meine Damen und Herren, die auf jede Frage mit 10 Kommentaren auf GitHub antwortet. Aber das ist nicht sicher.
Leider fangen die Experten gerade erst an, sichtbar zu werden. Im Moment sind sie noch zu rar. Und die Community selbst befindet sich noch in den Kinderschuhen.
Wohin bewegt sich das alles und was ist zu tun?
Man kann alles hinschmeißen und zurück zu C# gehen, in die Welt des Riders. Aber warum? Warum würden Sie das überhaupt tun, wenn es nicht darum geht, eine Lösung zu finden? Hier sind meine subjektiven Schlussfolgerungen. Sie können gerne in den Kommentaren mit mir diskutieren, das wäre interessant.
Ich setze persönlich auf mehrere Dinge:
- Die Entwicklung in diesem Bereich geschieht sehr schnell. Ich möchte eine Grafik der Anfragen im Bereich DevOps anführen.
Möglicherweise ist das Thema sehr trendy, aber die Tatsache, dass das Feld wächst, gibt einen gewissen Hoffnungsschimmer.Wenn etwas so schnell wächst, werden sich zwangsläufig kluge Köpfe finden, die sagen, wie es richtig gemacht wird und wie nicht. Die zunehmende Popularität führt dazu, dass vielleicht endlich jemand die Zeit findet, ein Plug-in für jsonnet für vscode zu schreiben, das einen direkten Zugang zur Implementierung von Funktionen ermöglicht, anstatt sie über ctrl+shift+f suchen zu müssen. Wenn sich alles weiterentwickelt, entstehen auch mehr Materialien. Ein weiteres Beispiel ist das kürzlich erschienene Buch von Google über SRE.
- Es gibt entwickelte Methoden und Praktiken in der regulären Softwareentwicklung, die wir hier erfolgreich anwenden können. Ja, es gibt Nuancen beim Testen und in heterogenen Umgebungen, sowie unzureichende Tools, aber es gibt eine enorme Anzahl von Praktiken, die nützlich sein und helfen können.
Ein einfaches Beispiel: die Zusammenarbeit durch Pair Programming. Das hilft enorm, die Dinge zu verstehen. Wenn man einen Kollegen neben sich hat, der ebenfalls versucht, etwas zu begreifen, wird man es gemeinsam besser verstehen.
Das Verständnis dafür, wie Refactoring durchgeführt wird, hilft auch in solchen Situationen, es effektiv umzusetzen. Man muss nicht alles auf einmal ändern, man kann zunächst die Benennungen anpassen, dann die Anordnung ändern und schließlich vielleicht einen Teil herausstellen. Oh, hier fehlen Kommentare.
Fazit
Obwohl meine Überlegungen pessimistisch erscheinen mögen, blicke ich hoffnungsvoll in die Zukunft und hoffe aufrichtig, dass wir (und Sie) es schaffen werden.
In Kürze folgt der zweite Teil des Artikels. Darin werde ich berichten, wie wir versucht haben, agile Praktiken anzuwenden, um unseren Lernprozess und die Arbeit mit der Infrastruktur zu verbessern.
Quelle: habr.com
