DevOps on HightLoad ++ Siberia: Mythen entlarven und Tools diskutieren

Interview mit Alexander Titov, einem der Mitglieder des Programmkomitees unserer HighLoad ++ - Konferenz im Juni, dessen separater Abschnitt DevOps gewidmet sein wird.
Unter dem Schnitt, in welche Richtung der DevOps "Wind" weht und welche genauen Aspekte dieses Konzepts im Forum diskutiert werden.



Alexander ist unserer Community sehr vertraut, er ist der Organisator von DevOps Moscow und der DevOpsDays Moscow-Konferenz, er spricht seit mehreren Jahren auf unseren Veranstaltungen und hilft bei der Gestaltung ihrer Programme. Derzeit ist er Managing Partner bei Express 42, das DevOps in Technologieunternehmen ausbaut. Zuvor hatte Alexander von 2010 bis 2012 mit Qik einen faszinierenden Übernahmepfad durchlaufen, vom Betrieb eines schnell wachsenden Startups bis zum Betrieb bei einem großen internationalen Unternehmen Microsoft. Zuvor war er von 2009 bis 2010 technischer Direktor des ersten Cloud-Hostings in Russland, Skalaxi.

- Fangen wir von weitem an: Entwickelt sich die DevOps-Kultur? Welche Veränderungen wurden in diesem Bereich in den letzten Jahren beobachtet? Und wie sieht DevOps in Russland aus?

Natürlich ändert sich in einer Welt, in der sich die Technologie alle drei Jahre gegenseitig ändert, ständig und sehr stark. Das Grundproblem war zunächst die Produktion und der Betrieb von Software selbst im digitalen Zeitalter. Um dieses Problem herum hat sich die DevOps-Bewegung versammelt. Jetzt wurde das Grundproblem in viele Unterkategorien unterteilt - Infrastrukturmanagement, Überwachung, kontinuierliche Integration, kontinuierliche Bereitstellung, Arbeit mit Menschen (insbesondere das Problem des Burnout von Menschen, die sowohl Ausbeutung als auch Entwicklung betreiben), einige technologische Dinge (zum Beispiel das Auftreten von Kubernetes, wie z ein solcher De-facto-Standard für die gesamte Infrastrukturplattform in Unternehmen). Das heißt, in vielerlei Hinsicht tauchten Besonderheiten auf: Wir haben die Phase des Verstehens durchlaufen, was nach wie vor anders zu tun ist, viele neue Ansätze ausprobiert und einige standardisierte Prozesse zur Lösung gemeinsamer (typischer) Probleme entwickelt. Gleichzeitig sind die Tools und Prozesse in vielen Unternehmen auf der ganzen Welt immer noch von schlechter Qualität oder sehr schlecht formalisiert.

Im russischen Kontext besteht ein weiteres Problem darin, dass wir nicht verstehen, warum dies alles notwendig ist. Dies verwirrt viele. Wir entwickeln, testen und arbeiten separat, und dann lösen einige Kubernetes einige Probleme, aber sie versuchen, sie umzusetzen, ohne die Prozesse, Ansätze und Kompetenzen der Menschen zu ändern. Alles bricht zusammen. Und warum diese neuen Technologien nicht klar sind.

- Und was ist der Grund für solch eine radikale Transformation?

Wie bereits erwähnt, haben wir begonnen, ein anderes Problem zu lösen. Die klassische IT löste zunächst das Problem der Automatisierung von Geschäftsprozessen innerhalb eines Unternehmens. Die gesamte Infrastruktur wurde darauf abgestimmt - Datenbanken, Busse usw. Seit dem Jahr 2000, nach der Dotcom-Krise, hat die IT auf die Entwicklung digitaler Produkte umgestellt, die massiv maßgeschneiderte Services bereitstellen und einen gewissen Wert liefern können. Wenn das Unternehmen zuvor ein bestimmtes Automodell hergestellt hat, hat es jetzt auf die Anpassung für jeden Kunden umgestellt. Dies ist eine Lösung für ein anderes Problem, für das grundlegend andere Ansätze und Technologien erforderlich sind - ein anderer Softwareproduktionsprozess. Hier ist es nicht mehr möglich, Entwicklung, Test und Betrieb nacheinander durchzuführen. Jetzt beginnen diese Prozesse gleichzeitig.

Trotzdem gibt es ein Missverständnis, dass es bei DevOps um den Betrieb geht. Klassische Systemadministratoren, die operative Arbeiten ausführen, werden einfach in DevOps-Ingenieure umbenannt, was den Begriff im Prinzip diskreditiert. In der Tat ist das Konzept viel breiter. Dies ist eine separate Reihe von Praktiken, ein separater Rahmen, mit dem Sie bestimmte Probleme unter bestimmten Bedingungen und mit Personen einer bestimmten Kompetenz lösen können - nicht mehr und nicht weniger. Nur wenige Menschen verstehen, warum dies notwendig ist. Und dies ist eines der Probleme, die wir durch Konferenzen lösen wollen.

- Welche Berichte sollen sich auf Abschnitte innerhalb der Siberian HighLoad konzentrieren?

Wenn es früher hauptsächlich Betriebsberichte gab, möchten wir in diesem Jahr weitere Informationen über den Zusammenhang mit der Entwicklung hinzufügen, z. B. über Prozesse der kontinuierlichen Lieferung, der kontinuierlichen Integration und des Testens. Ein cooles Beispiel ist ein Bericht von Maxim Lapshin über RIT ++ (als Teil der RootConf 2018 im Frühjahr) über die Verwendung von DevOps in der Box-Entwicklung. Ein solches Unternehmen hat im Grunde keine Ausbeutung - es stellt eine Box her, die es an einen Kunden verkauft. Gleichzeitig hat sie DevOps im Inneren. Dieser Ansatz bricht das Muster, hilft aber gleichzeitig, den erwähnten Mythos zu entlarven, dass es bei DevOps nur um den Betrieb geht. Dies ist unser erster grundlegender Fokus.

Der zweite Schwerpunkt sind neue Technologien. Jetzt ist es in Mode, über Kubernetes, Prometheus und andere zu sprechen. Und wir suchen Menschen, die diese Technologien in der Praxis spüren konnten. Das heißt, sie werden nicht nur konfiguriert und funktionsfähig gemacht, sondern auch in ihren Entwicklungsprozess einbezogen. Im Allgemeinen versuchen wir, alle Technologien unter dem Motto zu betrachten, wie sie in den Softwareproduktionsprozess einbezogen werden - welches Problem sie lösen, welche Ziele sie setzen usw. Wenn Sie nicht darüber sprechen, beginnen die Leute mit Technologie als Frachtkult zu arbeiten: "Setzen wir Kubernetes auf und wir können Google machen." So wird es nicht funktionieren.

- Das Konzept der kontinuierlichen Integration wird vom Markt bereits gut angenommen. Gibt es neben bestimmten Tools noch etwas zu besprechen?

Natürlich. Das grundlegende, man kann sogar sagen, entscheidende Konzept ist, dass Produkte im Kontext von DevOps im Rahmen des kontinuierlichen Integrationsprozesses nicht auf Qualität getestet werden. Das heißt, es spielt keine Rolle, wie funktional das Produkt ausgereift ist. Es ist wichtig zu überprüfen, wie gut es startet und ob es zur Integration in andere Komponenten bereit ist.

Dies ist eine wesentliche Änderung, da eine kontinuierliche Integration in die konsequente Entwicklung, den Betrieb und das Testen erfolgt. Auf dieser Ebene wird jedoch die Qualität des Produkts gemäß den Anforderungen des Benutzers überprüft, und im Rahmen von DevOps werden die funktionalen Eigenschaften überprüft. In dieser Phase können einzelne Dienste im Rahmen der Microservice-Infrastruktur schnellstmöglich integriert werden (und DevOps als Ganzes existiert ohne Microservice-Architektur nicht).

- Welche Tools stehen dieses Jahr im Fokus?

Zunächst die bereits erwähnten Kubernetes. Es erschien vor einiger Zeit, erreichte aber erst vor kurzem das Stadium, in dem es verwendet werden kann. Jetzt kann es von jedem Unternehmen verwendet werden, das einen aktualisierten digitalen Dienst entwickelt, z. B. Dienste über Websites oder mobile Anwendungen.

Oft als Prometheus - ein Überwachungssystem, GitLab - als kontinuierliches Integrationssystem bezeichnet. Und auch der gesamte HashiCorp-Stack - Vault, Terraform (beide von HashiCorp entwickelt). Natürlich Docker - als Lieferformat.

- Gibt es in jüngster Zeit Verschiebungen im Rahmen des Konzepts „Alles als Code“?

Die Praxis von „alles als Code“ selbst ist offensichtlich nützlich. Dies ist eines der Grundprinzipien, auf denen der DevOps-Prozess basiert. Kubernetes setzt diese Ideologie einfach fort.

In DevOps lautet die Hauptgeschichte „Infrastruktur als Code“. Und dies ist nicht nur ein Konzept, sondern auch ein Prozess, bei dem alle Komponenten in Form von Code dargestellt werden, der es einzelnen "Teilen" der Infrastruktur ermöglicht, miteinander zu interagieren. Hier gibt es keine drastischen Änderungen, aber in der Praxis entwickelt es sich jetzt in Kubernetes. Beispielsweise werden Tools für das Abhängigkeitsmanagement wie Helm entwickelt, Tools zum Erstellen separater Module, Infrastrukturbeschreibungen, z. B. Operatoren (und es erscheinen Frameworks zum Schreiben von Anweisungen in Kubernetes) usw. Mit anderen Worten, es gibt eine gesunde Entwicklung des Instruments und die Durchdringung der Praxis darin.

- Lohnt es sich, über die Praxis von „alles als Code“ getrennt vom Instrument zu sprechen?

Wir haben noch kein Programm vollständig erstellt, daher kann ich nicht sagen, ob wir solche Themen speziell für HighLoad ++ ansprechen werden. Aber das an sich ist möglich.

Es gibt viele Ansätze, um die Infrastruktur zu organisieren, Abhängigkeiten innerhalb des Infrastrukturcodes zu verwalten und zu testen. Natürlich werden wir über Konzepte für die Arbeit mit der Praxis sprechen - zum Beispiel, dass Infrastrukturcode in Module unterteilt werden sollte. Es scheint mir, dass solche Themen, isoliert von der Praxis, nicht sehr gut passen. Aber vielleicht werden wir einen Bericht auswählen, in dem alle möglichen Ansätze im Rahmen einer einzigen Systembeschreibung gesammelt werden. Es ist jedoch viel wertvoller, wenn Menschen erzählen und zeigen, wie diese theoretischen Konzepte in der Realität umgesetzt werden. Über die Theorie, die den Praktiken zugrunde liegt, können Sie dann mit denselben Personen am Rande sprechen.



- Es gibt eine Meinung, dass die Popularität der ereignisgesteuerten Architektur im Laufe der Zeit zunimmt. Stimmen Sie dieser Aussage zu?

Eine ereignisgesteuerte Infrastruktur war schon immer Teil des Chatops-Ansatzes. Je nach Ereignis treffen wir im Chat eine Entscheidung darüber, was mit einer Infrastruktur geschehen soll. Diese Geschichte ist für große große Unternehmen sehr notwendig, aber für den Rest des Publikums ist sie noch nicht ganz ausgereift. Um Entscheidungen darüber zu treffen, was passieren soll (was wir tun sollen), ist es notwendig, einen Rahmen für die Regeln innerhalb der Teams zu entwickeln, wie wir diese Entscheidungen treffen, damit jeder es mehr oder weniger gleich macht - von einer Seite schauen. Und damit ist alles kompliziert. Das Format für die Entwicklung eines solchen Frameworks ist das, worüber jetzt alle sprechen: wie es automatisiert, zu einem Tool gebracht werden kann, wie es auf Teambuilding-Ebene durchgeführt werden sollte und wie mit verschiedenen Teams koordiniert werden kann.

- Spiegelt sich das irgendwie in den Konferenzberichten wider?

Nein, bei HighLoad ++ geht es mehr um hoch geladene Systeme und Tools. Daher können wir hier über Tools sprechen, aber nicht über die Entwicklung eines solchen Frameworks. Aber im Herbst werden wir eine separate RootConf-Konferenz haben, die am 1. und 2. Oktober stattfinden wird. Bis 2011 war es betrieblichen Fragen gewidmet (dh nur einer Komponente des gesamten Prozesses „Entwicklungstest-Betrieb“). 2015 haben wir es im Kontext des gesamten DevOps wiedergeboren - also haben wir das Thema schrittweise erweitert. Bei RootConf diskutieren wir, wie das Zusammenspiel von Entwicklern und Wartungsingenieuren sichergestellt werden kann. Wir sprechen über neue Prozesse und Technologien, über Infrastrukturplattformen und Infrastrukturmanagement, das im DevOps-Paradigma nicht nur am Betrieb, sondern auch an der Entwicklung beteiligt ist (sie erledigen nur unterschiedliche Aufgaben).

- Gab es in den letzten Jahren interessante Technologien zur Verbesserung der Ausfallsicherheit von Projekten? Werden sie auf der Konferenz diskutiert?

Heute sind wir auf ein Paradox gestoßen, das damit zusammenhängt, dass „Fehlertoleranz“ nicht „Zuverlässigkeit“ bedeutet. Die Fehlertoleranz wird jetzt durch die Zuverlässigkeit ersetzt.

Fehlertoleranz ist ein Konzept aus dem Paradigma monolithischer Systeme, bei dem das Zuverlässigkeitsproblem durch Duplizierung, Erhöhung der Ressourcen usw. gelöst wurde. Jetzt funktionieren solche Ansätze nicht mehr. Zuverlässigkeit basiert auf grundlegend unterschiedlichen Ansätzen - sie impliziert die "Anti-Fragilität" des Systems. Das heißt, das System wird „weich“: Wenn wir darauf einwirken, ändert es sich und bricht nicht zusammen. Mit anderen Worten, wenn Sie einen neuen Dienst erstellen möchten, sollten Sie solche Varianten seines Verhaltens vorsehen. Wenn der Benutzer oder die Umgebung, in der er arbeitet, versucht, ihn zu zerstören, ändert der Dienst einfach seine Eigenschaften, während der Dienst noch bereitgestellt wird wird ein Ergebnis angegeben.

Ein guter Indikator für diesen Trend ist das Aufkommen des Site Reliability Engineering als Praxis und einzelner Spezialisten - Site Reliability Engineer (SRE) als Ersatz für die bisherige Kompetenz des Systemadministrators. Zur Veranschaulichung dieses Prozesses möchte ich erwähnen, dass Google seine DevOps-Implementierungspraxis in Form eines Buches über Site Reliability Engineering veröffentlicht hat und diese Idee aktiv bei den Massen bekannt macht.

Wir werden auch bei RootConf darüber sprechen. Jetzt ist dieses Thema im Westen auf Hype und wir (von der DevOps Moscow Community) versuchen, es schrittweise zu uns zu bringen.