Stand von DevOps in Russland 2020

Wie versteht man überhaupt den Zustand von etwas?

Sie können sich auf Ihre Meinung verlassen, die aus verschiedenen Informationsquellen, beispielsweise Veröffentlichungen auf Websites oder Erfahrungen, gebildet wird. Sie können Ihre Kollegen und Freunde fragen. Eine andere Möglichkeit besteht darin, sich mit den Themen der Konferenzen auseinanderzusetzen: Das Programmkomitee besteht aus aktiven Vertretern der Branche, daher vertrauen wir ihnen bei der Auswahl relevanter Themen. Ein eigener Bereich ist Forschung und Berichterstattung. Aber es gibt ein Problem. Weltweit werden jährlich Untersuchungen zum Stand von DevOps durchgeführt, Berichte werden von ausländischen Unternehmen veröffentlicht und es gibt fast keine Informationen über russisches DevOps.

Aber der Tag ist gekommen, an dem eine solche Studie durchgeführt wurde, und heute werden wir Ihnen über die erzielten Ergebnisse berichten. Der Stand von DevOps in Russland wurde gemeinsam von den Unternehmen untersucht.Express 42"Und"Ontiko" Das Unternehmen Express 42 unterstützt Technologieunternehmen bei der Implementierung und Entwicklung von DevOps-Praktiken und -Tools und war eines der ersten Unternehmen, das in Russland über DevOps sprach. Die Autoren der Studie, Igor Kurochkin und Vitaly Khabarov, sind bei Express 42 in der Analyse und Beratung tätig und verfügen über einen technischen Hintergrund aus dem Betrieb und Erfahrung in verschiedenen Unternehmen. Über einen Zeitraum von 8 Jahren haben sich Kollegen Dutzende von Unternehmen und Projekten – vom Startup bis zum Konzern – mit unterschiedlichen Problemen sowie unterschiedlichem kulturellen und technischen Reifegrad angesehen.

In ihrem Bericht erklärten Igor und Vitaly, welche Probleme es während des Forschungsprozesses gab, wie sie diese lösten, wie DevOps-Forschung grundsätzlich durchgeführt wird und warum sich Express 42 dazu entschlossen hat, eine eigene durchzuführen. Sie können ihren Bericht sehen hier.

DevOps-Forschung

Igor Kurochkin begann das Gespräch.

Wir fragen das Publikum regelmäßig auf DevOps-Konferenzen: „Haben Sie den diesjährigen State of DevOps-Bericht gelesen?“ Nur wenige heben die Hand, aber unsere Recherche ergab, dass nur ein Drittel sie studiert. Wenn Sie solche Berichte noch nie gesehen haben, sagen wir gleich, dass sie alle sehr ähnlich sind. Am häufigsten fallen Sätze wie: „Im Vergleich zum letzten Jahr …“

Hier haben wir unser erstes Problem, gefolgt von zwei weiteren:

1. Für das letzte Jahr liegen uns keine Daten vor. Niemand interessiert sich für den Stand von DevOps in Russland;
2. Methodik. Es ist nicht klar, wie man Hypothesen testet, wie man Fragen konstruiert, wie man Analysen durchführt, Ergebnisse vergleicht und Zusammenhänge findet;
3. Terminologie. Alle Berichte sind auf Englisch, eine Übersetzung ist erforderlich, ein gemeinsames Framework für DevOps wurde noch nicht erfunden und jeder entwickelt sein eigenes.

Schauen wir uns an, wie Analysen zum Stand von DevOps in der Welt im Allgemeinen durchgeführt wurden.

Geschichte

DevOps-Forschung wird seit 2011 durchgeführt. Der erste, der sie durchführte, war Puppet, ein Entwickler von Konfigurationsmanagementsystemen. Damals war es eines der wichtigsten Werkzeuge zur Beschreibung von Infrastruktur in Form von Code. Bis 2013 handelte es sich bei diesen Studien lediglich um Umfragen in geschlossenem Format und ohne öffentliche Berichterstattung.

Im Jahr 2013 erschien IT Revolution, Herausgeber aller wichtigen Bücher zum Thema DevOps. Gemeinsam mit Puppet bereiteten sie die erste Veröffentlichung „State of DevOps“ vor, in der 4 Schlüsselmetriken erstmals auftauchten. Im darauffolgenden Jahr engagierte sich das Beratungsunternehmen ThoughtWorks, das für seine regelmäßigen Technologie-Radarberichte zu Branchenpraktiken und -tools bekannt ist. Und im Jahr 2015 wurde ein Abschnitt mit Methodik hinzugefügt, und es wurde deutlich, wie sie die Analyse durchführen.

Im Jahr 2016 veröffentlichten die Autoren der Studie, nachdem sie ihr Unternehmen DORA (DevOps Research and Assessment) gegründet hatten, einen Jahresbericht. Im folgenden Jahr veröffentlichten DORA und Puppet ihren gemeinsamen Abschlussbericht.

Und dann wurde es interessant:

Im Jahr 2018 trennten sich die Unternehmen und es wurden zwei unabhängige Berichte veröffentlicht: einer von Puppet, der zweite von DORA in Zusammenarbeit mit Google. DORA nutzte weiterhin seine Methodik mit Schlüsselkennzahlen, Leistungsprofilen und technischen Praktiken, die sich auf Schlüsselkennzahlen und die Leistung im gesamten Unternehmen auswirken. Und Puppet schlug seinen Ansatz mit einer Beschreibung des Prozesses und der Entwicklung von DevOps vor. Aber die Geschichte setzte sich nicht durch; 2019 gab Puppet diese Methodik auf und veröffentlichte eine neue Version der Berichte, in der die wichtigsten Praktiken und ihre Auswirkungen auf DevOps aus ihrer Sicht aufgeführt wurden. Dann geschah etwas anderes: Google kaufte DORA und gemeinsam veröffentlichten sie einen weiteren Bericht. Vielleicht haben Sie es gesehen.

Dieses Jahr wurde es kompliziert. Es ist bekannt, dass Puppet seine Umfrage gestartet hat. Sie haben es eine Woche früher gemacht als wir, und es war bereits fertig. Wir haben daran teilgenommen und geschaut, welche Themen sie interessierten. Puppet führt derzeit seine Analyse durch und bereitet die Veröffentlichung des Berichts vor.

Es gibt jedoch noch keine Ankündigung von DORA und Google. Im Mai, als die Umfrage normalerweise begann, kam die Information, dass Nicole Forsgren, eine der Gründerinnen von DORA, zu einem anderen Unternehmen gewechselt war. Daher gingen wir davon aus, dass es dieses Jahr keine Recherchen oder Berichte von DORA geben würde.

Wie sieht es in Russland aus?

Wir haben keine Forschung zu DevOps durchgeführt. Wir haben auf Konferenzen gesprochen und die Schlussfolgerungen anderer nacherzählt, und die Raiffeisenbank hat den „Stand von DevOps“ für 2019 übersetzt (ihre Ankündigung finden Sie auf Habré), vielen Dank an sie. Und das ist alles.

Deshalb haben wir unsere eigene Forschung in Russland unter Verwendung der DORA-Methoden und -Ergebnisse durchgeführt. Für unsere Recherche nutzten wir den Bericht von Kollegen der Raiffeisenbank, unter anderem zur Synchronisierung von Terminologie und Übersetzung. Und die für die Branche relevanten Fragen stammen aus DORA-Berichten und dem diesjährigen Puppet-Fragebogen.

Suchprozess

Der Bericht ist nur der letzte Teil. Der gesamte Forschungsprozess besteht aus vier großen Phasen:

Während der Vorbereitungsphase haben wir Branchenexperten befragt und eine Liste mit Hypothesen erstellt. Darauf aufbauend haben wir Fragen zusammengestellt und eine Umfrage für den gesamten Monat August gestartet. Anschließend haben wir den Bericht selbst analysiert und erstellt. Für DORA dauert dieser Prozess 6 Monate. Wir haben es in drei Monaten abgeschlossen und jetzt verstehen wir, dass wir kaum genug Zeit hatten: Erst durch die Analyse verstehen Sie, welche Fragen gestellt werden müssen.

Teilnehmer

Alle Auslandsberichte beginnen mit einem Porträt der Teilnehmer, und die meisten von ihnen stammen nicht aus Russland. Der Anteil der russischen Befragten schwankt von Jahr zu Jahr zwischen 5 und 1 %, was keine Rückschlüsse zulässt.

Karte aus dem Accelerate State of DevOps-Bericht 2019:

In unserer Studie konnten wir 889 Personen befragen – das ist eine ganze Menge (DORA befragt in seinen Berichten jährlich etwa tausend Personen) und hier haben wir unser Ziel erreicht:

Allerdings haben nicht alle unserer Teilnehmer das Ziel erreicht: Die Abschlussquote betrug etwas weniger als die Hälfte. Dies reichte jedoch aus, um eine repräsentative Probe zu erhalten und eine Analyse durchzuführen. Da DORA in seinen Berichten keine Belegungsraten offenlegt, sind hier keine Vergleiche möglich.

Branchen und Positionen

Unsere Befragten repräsentieren ein Dutzend Branchen. Die Hälfte davon arbeitet in der Informationstechnologie. Es folgen Finanzdienstleistungen, Handel, Telekommunikation und andere. Zu den Positionen zählen Spezialisten (Entwickler, Tester, Betriebsingenieur) und Führungskräfte (Leiter von Teams, Gruppen, Bereichen, Direktoren):

Jeder Zweite arbeitet in einem mittelständischen Unternehmen. Jeder Dritte arbeitet in großen Unternehmen. Die meisten arbeiten in Teams von bis zu 9 Personen. Unabhängig davon haben wir nach den Hauptaktivitäten gefragt, und die meisten sind in der einen oder anderen Weise mit dem Betrieb verbunden, und etwa 40 % sind an der Entwicklung beteiligt:

Auf diese Weise haben wir Informationen zum Vergleich und zur Analyse von Vertretern verschiedener Branchen, Unternehmen und Teams gesammelt. Mein Kollege Vitaly Khabarov wird Ihnen von der Analyse erzählen.

Analyse und Vergleich

Vitaly Khabarov: Vielen Dank an alle Teilnehmer, die an unserer Umfrage teilgenommen, Fragebögen ausgefüllt und uns Daten zur weiteren Analyse und Prüfung unserer Hypothesen zur Verfügung gestellt haben. Und dank unserer Klienten und Kunden verfügen wir über einen reichen Erfahrungsschatz, der uns dabei geholfen hat, die für die Branche wichtigen Themen zu identifizieren und die Hypothesen zu formulieren, die wir in unserer Forschung getestet haben.

Leider kann man nicht einfach eine Liste mit Fragen einerseits und Daten andererseits nehmen, sie irgendwie vergleichen, sagen: „Ja, das funktioniert alles so, wir hatten recht“ und getrennte Wege gehen. Nein, wir brauchen Methodik und statistische Methoden, um sicherzustellen, dass wir uns nicht geirrt haben und dass unsere Schlussfolgerungen zuverlässig sind. Dann können wir auf Basis dieser Daten unsere weitere Arbeit aufbauen:

Schlüsselkennzahlen

Als Grundlage dienten uns die DORA-Methodik, die im Buch „Accelerate State of DevOps“ ausführlich beschrieben wurde. Wir haben geprüft, ob die Schlüsselkennzahlen für den russischen Markt geeignet sind und ob sie auf die gleiche Weise verwendet werden können, wie sie DORA zur Beantwortung der Frage verwendet: „Wie entspricht die Industrie in Russland der ausländischen Industrie?“

Wichtige Kennzahlen:

1. Bereitstellungshäufigkeit. Wie oft wird eine neue Version einer Anwendung in der Produktionsumgebung bereitgestellt (geplante Änderungen, ohne Hotfixes und Reaktion auf Vorfälle)?
2. Lieferzeit. Was ist die durchschnittliche Zeit zwischen dem Festschreiben einer Änderung (Schreiben der Funktionalität als Code) und der Bereitstellung der Änderung in der Produktionsumgebung?
3. Wiederherstellungszeit. Wie lange dauert es im Durchschnitt, eine Anwendung in einer Produktionsumgebung nach einem Vorfall, einer Dienstbeeinträchtigung oder der Erkennung eines Fehlers, der Anwendungsbenutzer betrifft, wiederherzustellen?
4. Erfolglose Änderungen. Wie viel Prozent der Bereitstellungen in einer Produktumgebung führen zu einer Verschlechterung der Anwendung oder zu Vorfällen und erfordern die Beseitigung der Folgen (Rollback von Änderungen, Entwicklung eines Hotfixes oder Patches)?

Die Forschung von DORA hat einen Zusammenhang zwischen diesen Kennzahlen und der Unternehmensleistung festgestellt. Wir überprüfen es auch in unserer Studie.

Aber um sicherzustellen, dass die vier Schlüsselkennzahlen etwas beeinflussen können, müssen Sie verstehen: Stehen sie irgendwie miteinander in Zusammenhang? DORA antwortete mit Ja, mit einer Einschränkung: Die Beziehung zwischen der Change Failure Rate und den anderen drei Kennzahlen ist etwas schwächer. Wir haben ungefähr das gleiche Bild erhalten. Wenn Lieferzeit, Bereitstellungshäufigkeit und Wiederherstellungszeit miteinander korrelieren (wir haben diesen Zusammenhang durch die Pearson-Korrelation und durch die Chaddock-Skala festgestellt), dann gibt es keinen so starken Zusammenhang mit erfolglosen Änderungen.

Grundsätzlich tendieren die meisten Befragten dazu, zu antworten, dass es bei ihnen in der Produktion eher zu geringen Vorfällen kommt. Obwohl wir später sehen werden, dass zwischen den Befragtengruppen immer noch ein erheblicher Unterschied in der Rate erfolgloser Änderungen besteht, können wir diese Kennzahl für diese Aufteilung noch nicht verwenden.

Wir führen dies auf die Tatsache zurück, dass (wie sich im Verlauf der Analyse und Kommunikation mit einigen unserer Kunden herausstellte) es einen leichten Unterschied in der Wahrnehmung dessen gibt, was als Vorfall gilt. Wenn es uns gelungen ist, die Funktionalität unseres Dienstes während des technischen Fensters wiederherzustellen, kann dies als Vorfall betrachtet werden? Wahrscheinlich nicht, denn wir haben alles repariert, wir sind großartig. Kann es als Vorfall betrachtet werden, wenn wir unsere Bewerbung zehnmal im normalen, vertrauten Modus wiederholen mussten? Es scheint nicht. Daher bleibt die Frage nach dem Zusammenhang zwischen erfolglosen Änderungen und anderen Kennzahlen offen. Wir werden es weiter klären.

Wichtig hierbei ist, dass wir einen signifikanten Zusammenhang zwischen Lieferzeit, Wiederherstellungszeit und Bereitstellungshäufigkeit festgestellt haben. Daher haben wir diese drei Kennzahlen genutzt, um die Befragten anhand ihrer Produktivität weiter in Gruppen einzuteilen.

Wie viel in Gramm hängen?

Wir haben die hierarchische Clusteranalyse verwendet:

• Wir verteilen die Befragten über den n-dimensionalen Raum, wobei die Koordinaten jedes Befragten seine Antworten auf die Fragen darstellen.
• Wir erklären jeden Befragten zu einem kleinen Cluster.
• Wir fassen die beiden einander am nächsten liegenden Cluster zu einem größeren Cluster zusammen.
• Wir finden das nächste Clusterpaar und kombinieren es zu einem größeren Cluster.

Auf diese Weise gruppieren wir alle unsere Befragten in die Anzahl der Cluster, die wir benötigen. Mithilfe eines Dendrogramms (einem Baum von Verbindungen zwischen Clustern) sehen wir den Abstand zwischen zwei benachbarten Clustern. Es bleibt uns nur noch, den Abstand zwischen diesen Clustern eine gewisse Grenze zu setzen und zu sagen: „Diese beiden Gruppen sind durchaus voneinander zu unterscheiden, weil der Abstand zwischen ihnen riesig ist.“

Hier gibt es jedoch ein verstecktes Problem: Wir haben keine Beschränkungen hinsichtlich der Anzahl der Cluster – wir können 2, 3, 4, 10 Cluster erhalten. Und die erste Idee war: Warum nicht alle unsere Befragten in vier Gruppen einteilen, wie es DORA tut? Wir haben jedoch festgestellt, dass die Unterschiede zwischen diesen Gruppen unbedeutend werden und wir nicht sicher sein können, ob der Befragte wirklich zu seiner Gruppe und nicht zur Nachbargruppe gehört. Wir können den russischen Markt noch nicht in vier Gruppen einteilen. Daher haben wir uns für drei Profile entschieden, zwischen denen ein statistisch signifikanter Unterschied besteht:

Als nächstes haben wir das Profil nach Cluster bestimmt: Wir haben die Mediane für jede Metrik für jede Gruppe ermittelt und eine Tabelle mit Effizienzprofilen zusammengestellt. Tatsächlich wurden die resultierenden Leistungsprofile für den durchschnittlichen Teilnehmer in jeder Gruppe ermittelt. Wir haben drei Effizienzprofile identifiziert: Niedrig, Mittel, Hoch:

Hier haben wir unsere Hypothese bestätigt, dass 4 Schlüsselkennzahlen zur Bestimmung des Leistungsprofils geeignet sind und sowohl auf dem westlichen als auch auf dem russischen Markt funktionieren. Es gibt einen Unterschied zwischen den Gruppen, der statistisch signifikant ist. Ich möchte betonen, dass es einen signifikanten Unterschied im Mittel zwischen den Leistungsprofilen für die Metrik der erfolglosen Änderungen gibt, auch wenn wir die Befragten zunächst nicht nach diesem Parameter geteilt haben.

Dann stellt sich die Frage: Wie nutzt man das alles?

Wie zu verwenden

Wenn wir ein beliebiges Team mit 4 Schlüsselkennzahlen auf die Tabelle anwenden, erhalten wir in 85 % der Fälle keine vollständige Übereinstimmung – dies ist nur der durchschnittliche Teilnehmer und nicht das, was in der Realität der Fall ist. Wir sind alle (und jedes Team) ein bisschen anders.

Wir haben überprüft: Wir haben unsere Befragten und das DORA-Leistungsprofil genommen und untersucht, wie viele Befragte dem einen oder anderen Profil entsprachen. Wir haben festgestellt, dass nur 16 % der Befragten genau einem der Profile zuzuordnen waren. Der Rest liegt irgendwo dazwischen:

Dies bedeutet, dass das Leistungsprofil einen begrenzten Umfang hat. Um eine erste Annäherung daran zu bekommen, wo Sie sich befinden, können Sie diese Tabelle verwenden: „Oh, es sieht so aus, als wären wir näher an Mittel oder Hoch!“ Wenn Sie verstehen, wohin Sie als Nächstes wollen, kann das ausreichen. Wenn Ihr Ziel jedoch eine ständige, kontinuierliche Verbesserung ist und Sie genauer wissen möchten, wo Sie sich weiterentwickeln und was Sie tun müssen, sind zusätzliche Mittel erforderlich. Wir nannten sie Rechner:

• DORA-Rechner
• Rechner Express 42* (in Entwicklung)
• Ihre eigene Entwicklung (Sie können Ihren eigenen internen Rechner erstellen).

Wofür werden sie benötigt? Verstehen:

• Erfüllt das Team unserer Organisation unsere Standards?
• Wenn nicht, können wir ihr helfen – es im Rahmen der Fachkompetenz unseres Unternehmens beschleunigen?
• Wenn ja, können wir es noch besser machen?

Sie können damit auch unternehmensinterne Statistiken sammeln:

• Was für Teams haben wir?
• Teilen Sie Teams in Profile auf;
• Siehe: Oh, diese Teams sind leistungsschwach (etwas langsam), aber diese sind großartig: Sie stellen jeden Tag fehlerfrei bereit und ihre Vorlaufzeit beträgt weniger als eine Stunde.

Und dann können Sie feststellen, dass wir in unserem Unternehmen über das nötige Know-how und die Werkzeuge für die Teams verfügen, denen es noch nicht gelingt.

Oder wenn Sie verstehen, dass Sie sich im Unternehmen wohl fühlen, dass Sie besser sind als viele andere, dann können Sie etwas breiter blicken. Das ist genau die russische Industrie: Können wir uns das notwendige Fachwissen in der russischen Industrie aneignen, um schneller voranzukommen? Hier hilft der Express 42-Rechner (er befindet sich in der Entwicklung). Wenn Sie dem russischen Markt entwachsen sind, dann schauen Sie sich um DORA-Rechner und auf den Weltmarkt.

Bußgeld. Und wenn Sie laut DORA-Rechner zur Elit-Gruppe gehören, was sollten Sie dann tun? Hier gibt es keine gute Lösung. Höchstwahrscheinlich stehen Sie an der Spitze der Branche und durch interne Forschung und Entwicklung sowie den Einsatz umfangreicher Ressourcen sind weitere Beschleunigungs- und Zuverlässigkeitsverbesserungen möglich.

Kommen wir zum süßesten Teil – dem Vergleich.

Vergleich

Wir wollten zunächst die russische Industrie mit der westlichen Industrie vergleichen. Wenn wir direkt vergleichen, sehen wir, dass wir weniger Profile haben und diese etwas stärker miteinander vermischt sind, die Grenzen sind etwas verschwommener:

Unsere Elite-Performer verstecken sich unter den High-Performern, aber sie sind da – das sind die Elite-Einhörner, die bedeutende Höhen erreicht haben. In Russland ist der Unterschied zwischen Elite- und High-Profilen noch nicht groß genug. Wir glauben, dass diese Spaltung in Zukunft aufgrund einer Verbesserung der Ingenieurskultur, der Qualität der Umsetzung von Ingenieurspraktiken und des Fachwissens in Unternehmen erfolgen wird.

Wenn wir zum direkten Vergleich innerhalb der russischen Branche übergehen, sehen wir, dass hochkarätige Teams in jeder Hinsicht besser sind. Wir haben auch unsere Hypothese bestätigt, dass es einen Zusammenhang zwischen diesen Kennzahlen und der organisatorischen Effektivität gibt: Hochkarätige Teams erreichen ihre Ziele mit deutlich größerer Wahrscheinlichkeit nicht nur, sondern übertreffen sie auch.
Lassen Sie uns hochkarätige Teams werden und dabei nicht aufhören:

Aber dieses Jahr ist etwas Besonderes, und wir haben uns entschieden, zu überprüfen, wie Unternehmen in einer Pandemie leben: Hochkarätige Teams kommen deutlich besser zurecht und fühlen sich besser als der Branchendurchschnitt:

• Neue Produkte wurden 1,5–2 Mal häufiger veröffentlicht,
• Erhöhte Zuverlässigkeit und/oder Leistung der Anwendungsinfrastruktur zweimal häufiger.

Das heißt, die Kompetenzen, über die sie bereits verfügten, halfen ihnen, schneller zu entwickeln, neue Produkte einzuführen, bestehende Produkte zu modifizieren und so neue Märkte und neue Benutzer zu erobern:

Was hat unseren Teams sonst noch geholfen?

Ingenieurspraktiken

Ich erzähle Ihnen von den wesentlichen Erkenntnissen für jede Praxis, die wir überprüft haben. Vielleicht hat den Teams noch etwas anderes geholfen, aber die Rede ist von DevOps. Und innerhalb von DevOps sehen wir Unterschiede zwischen Teams mit unterschiedlichen Profilen.

Plattform als Service

Wir haben keinen signifikanten Zusammenhang zwischen dem Alter der Plattform und dem Teamprofil festgestellt: Plattformen erschienen ungefähr zur gleichen Zeit sowohl für Low- als auch für High-Teams. Für Letzteres stellt die Plattform jedoch im Durchschnitt mehr Dienste und mehr Softwareschnittstellen zur Steuerung durch Programmcode bereit. Und Plattformteams helfen ihren Entwicklern und Teams eher bei der Nutzung der Plattform, lösen ihre Probleme und Vorfälle im Zusammenhang mit der Plattform eher und schulen andere Teams.

Infrastruktur als Code

Hier ist alles ziemlich Standard. Wir haben einen Zusammenhang zwischen der Automatisierung des Infrastrukturcodes und der Menge der im Infrastruktur-Repository gespeicherten Informationen festgestellt. Hochkarätige Teams speichern mehr Informationen in Repositories: Dazu gehören Infrastrukturkonfiguration, CI/CD-Pipeline, Umgebungseinstellungen und Build-Parameter. Sie speichern diese Informationen häufiger, arbeiten besser mit Infrastrukturcode und haben mehr Prozesse und Aufgaben für die Arbeit mit Infrastrukturcode automatisiert.

Interessanterweise konnten wir bei den Infrastrukturtests keinen signifikanten Unterschied feststellen. Ich führe dies auf die Tatsache zurück, dass hochkarätige Teams im Allgemeinen über mehr Testautomatisierung verfügen. Vielleicht sollten sie sich nicht separat durch Infrastrukturtests ablenken lassen, sondern die Tests, mit denen sie Anwendungen überprüfen, reichen aus, und dank ihnen können sie sehen, was und wo sie kaputt gegangen sind.

Integration und Bereitstellung

Der langweiligste Abschnitt, denn wir haben bestätigt: Je mehr Automatisierung Sie haben, desto besser arbeiten Sie mit dem Code, desto wahrscheinlicher ist es, dass Sie bessere Ergebnisse erzielen.

Architektur

Wir wollten sehen, wie sich Microservices auf die Leistung auswirken. Ehrlich gesagt ist dies nicht der Fall, da der Einsatz von Microservices nicht mit einer Steigerung der Effizienzindikatoren verbunden ist. Microservices werden sowohl von High- als auch Low-Profile-Teams genutzt.

Was jedoch von Bedeutung ist, ist, dass High-Teams durch den Übergang zu einer Microservice-Architektur ihre Dienste unabhängig entwickeln und einführen können. Wenn die Architektur es Entwicklern ermöglicht, autonom zu agieren, ohne auf jemanden außerhalb des Teams warten zu müssen, dann ist dies eine Schlüsselkompetenz zur Steigerung der Geschwindigkeit. Hier helfen Microservices. Aber einfach ihre Umsetzung spielt keine große Rolle.

Wie haben wir das alles entdeckt?

Wir hatten einen ehrgeizigen Plan, die DORA-Methodik vollständig zu reproduzieren, aber es fehlten uns die Ressourcen. Wenn DORA viel Sponsoring in Anspruch nimmt und die Studie sechs Monate dauert, haben wir unsere Studie in kurzer Zeit durchgeführt. Wir wollten ein DevOps-Modell aufbauen, wie es DORA tut, und das werden wir auch in Zukunft tun. Vorerst haben wir uns auf Heatmaps beschränkt:

Wir haben uns die Verteilung der Ingenieurspraktiken unter den Teams jedes Profils angesehen und festgestellt, dass Teams mit hohem Profil im Durchschnitt häufiger Ingenieurspraktiken nutzen. Mehr dazu erfahren Sie in unserem Bericht.

Wechseln wir zur Abwechslung von komplexen Statistiken zu einfachen.

Was haben wir sonst noch entdeckt?

Werkzeuge

Wir stellen fest, dass die Linux-Betriebssystemfamilie die meisten Befehle verwendet. Aber Windows liegt immer noch im Trend – mindestens ein Viertel unserer Befragten gab an, die eine oder andere Version davon zu verwenden. Der Markt scheint dieses Bedürfnis zu haben. Daher können Sie diese Kompetenzen weiterentwickeln und auf Konferenzen Vorträge halten.

Unter den Orchestratoren ist es kein Geheimnis, dass Kubernetes führend ist (52 %). Der nächste Orchestrator in der Reihe ist Docker Swarm (ca. 12 %). Die beliebtesten CI-Systeme sind Jenkins und GitLab. Das beliebteste Konfigurationsmanagementsystem ist Ansible, gefolgt von unserer beliebten Shell.

Unter den Cloud-Hosting-Anbietern nimmt Amazon derzeit die Spitzenposition ein. Der Anteil russischer Wolken nimmt allmählich zu. Im nächsten Jahr wird es interessant sein zu sehen, wie es den russischen Cloud-Anbietern geht und ob ihr Marktanteil steigt. Es gibt sie, sie sind nutzbar und das ist gut so:

Ich erteile Igor das Wort, der weitere Statistiken liefern wird.

Verbreitung von Praktiken

Igor Kurochkin: Unabhängig davon haben wir die Befragten gebeten, anzugeben, wie die betrachteten Ingenieurspraktiken im Unternehmen verteilt sind. Die meisten Unternehmen verfolgen einen gemischten Ansatz, der aus unterschiedlichen Mustern besteht, und Pilotprojekte erfreuen sich großer Beliebtheit. Wir haben auch einen leichten Unterschied zwischen den Profilen festgestellt. Vertreter des High Profile nutzen häufiger das Muster „Initiative von unten“, bei dem kleine Teams von Spezialisten Arbeitsprozesse und Tools ändern und erfolgreiche Entwicklungen mit anderen Teams teilen. Bei Medium handelt es sich um eine Top-Down-Initiative, die das gesamte Unternehmen durch die Schaffung von Communities und Kompetenzzentren berührt:

Agile und DevOps

Die Beziehung zwischen Agile und DevOps wird in der Branche häufig diskutiert. Diese Frage wird auch im State of Agile Report für 2019/2020 aufgeworfen, daher haben wir uns entschieden, den Zusammenhang zwischen Agile- und DevOps-Aktivitäten in Unternehmen zu vergleichen. Wir haben festgestellt, dass DevOps ohne Agile selten ist. Bei der Hälfte der Befragten begann die Verbreitung von Agile merklich früher, etwa 20 % beobachteten einen gleichzeitigen Beginn, und eines der Anzeichen für eine Zurückhaltung wird das Fehlen von Agile- und DevOps-Praktiken sein:

Teamtopologien

Ende letzten Jahres erschien das Buch „Teamtopologien", das einen Rahmen zur Beschreibung von Teamtopologien vorschlägt. Wir fragten uns, ob es für russische Unternehmen gelten würde. Und wir stellten die Frage: „Welche Muster sehen Sie?“

Bei der Hälfte der Befragten werden Infrastrukturteams sowie separate Entwicklungs-, Test- und Betriebsteams beobachtet. Einzelne DevOps-Teams machten 45 % aus, wobei hochrangige Vertreter häufiger anzutreffen sind. Als nächstes kommen funktionsübergreifende Teams, die bei High ebenfalls häufiger anzutreffen sind. Separate SRE-Befehle erscheinen in den Profilen High und Medium und sind im Low-Profil selten zu finden:

DevQaOps-Verhältnis

Wir haben diese Frage auf FaceBook vom Teamleiter des Skyeng-Plattformteams gesehen – ihn interessierte das Verhältnis von Entwicklern, Testern und Administratoren in Unternehmen. Wir haben es gefragt und uns die Antworten unter Berücksichtigung der Profile angesehen: Vertreter des Hochprofils haben eine geringere Anzahl von Test- und Betriebsingenieuren für jeden Entwickler:

Pläne für 2021 Jahr

In ihren Plänen für das nächste Jahr vermerkten die Befragten folgende Aktivitäten:

Hier sehen Sie den Schnittpunkt mit der DevOps Live 2020-Konferenz. Wir haben das Programm sorgfältig geprüft:

• Infrastruktur als Produkt
• DevOps-Transformation
• Verbreitung von DevOps-Praktiken
• DevSecOps
• Fallclubs und Diskussionen

Aber unser Vortrag wird nicht genug Zeit haben, um alle Themen abzudecken. Hinter den Kulissen:

• Plattform als Dienstleistung und als Produkt;
• Infrastruktur als Code, Umgebungen und Clouds;
• Kontinuierliche Integration und Bereitstellung;
• Die Architektur;
• DevSecOps-Muster;
• Plattform- und funktionsübergreifende Teams.

Bericht Unseres ist umfangreich, 50 Seiten lang, und Sie können es sich genauer ansehen.

Zusammenfassend

Wir hoffen, dass unsere Forschung und unser Bericht Sie dazu inspirieren, mit neuen Ansätzen für Entwicklung, Tests und Betrieb zu experimentieren, und Ihnen dabei helfen, sich zurechtzufinden, sich mit anderen Teilnehmern der Studie zu vergleichen und Bereiche zu identifizieren, in denen Sie Ihre eigenen Ansätze verbessern können .

Ergebnisse der ersten Studie zum Stand von DevOps in Russland:

• Schlüsselkennzahlen. Wir haben festgestellt, dass sich Schlüsselmetriken (Lieferzeit, Bereitstellungsrate, Wiederherstellungszeit und Änderungsfehler) zur Analyse der Wirksamkeit von Entwicklungs-, Test- und Betriebsprozessen eignen.
• Profile: Hoch, Mittel, Niedrig. Basierend auf den gesammelten Daten ist es möglich, statistisch unterschiedliche Gruppen zu identifizieren: Hoch, Mittel, Niedrig, mit charakteristischen Merkmalen basierend auf Metriken, Praktiken, Prozessen und Tools. Vertreter des High-Profils zeigen bessere Ergebnisse als Low. Es ist wahrscheinlicher, dass sie ihre Ziele erreichen und übertreffen.
• Indikatoren, Pandemie und Pläne für 2021. Ein besonderer Indikator ist in diesem Jahr die Bewältigung der Pandemie durch die Unternehmen. High schnitt besser ab, verzeichnete einen Anstieg der Benutzeraktivität und die Hauptgründe für den Erfolg waren effiziente Entwicklungsprozesse und eine starke Ingenieurskultur.
• DevOps-Praktiken, Tools und deren Entwicklung. Zu den Hauptplänen der Unternehmen für das nächste Jahr gehören die Entwicklung von DevOps-Praktiken und -Tools, die Einführung von DevSecOps-Praktiken sowie Änderungen in der Organisationsstruktur. Und die effektive Umsetzung und Entwicklung von DevOps-Praktiken erfolgt durch Pilotprojekte, die Bildung von Communities und Kompetenzzentren sowie Initiativen auf der oberen und unteren Ebene des Unternehmens.

Wir freuen uns über Ihre Bewertungen, Geschichten und Ihr Feedback. Wir danken allen, die an der Studie teilgenommen haben, und freuen uns auf Ihre Teilnahme im nächsten Jahr.

Source: habr.com