DevOpsForum 2019. DevOps-Implementierungen können nicht warten.

Neulich war ich auf dem DevOpsForum 2019, das von Logrocon veranstaltet wurde. Auf dieser Konferenz versuchten die Teilnehmer, Lösungen und neue Werkzeuge für die effektive Zusammenarbeit zwischen Unternehmen und Fachleuten für Entwicklung und IT-Service zu finden.

Die Konferenz war ein voller Erfolg: Es gab wirklich viele nützliche Vorträge, interessante Formate und jede Menge Austausch mit den Referenten. Besonders wichtig war, dass mir niemand etwas verkaufen wollte, was bei großen Konferenzen in letzter Zeit häufig der Fall ist.

Zusammenfassungen der Vorträge von Raiffeisenbank, AlfaStrakhovanie, die Erfahrungen von Mango Telecom bei der Implementierung von Automatisierung und weitere Details nach dem Cut.

Mein Name ist Jana, ich arbeite als Tester, beschäftige mich mit Automatisierung sowie DevOps und liebe es, an Konferenzen und Meetups teilzunehmen. In den letzten zwei Jahren war ich auf den Konferenzen von Oleg Bunin (HighLoad++, TeamLead Conf), bei Jug-Veranstaltungen (Heisenbug, JPoint), auf der TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.

Zuerst achte ich auf das Programm der Konferenz. Weniger darauf, worüber der Vortrag gehalten wird, mehr auf den Referenten. Selbst wenn der Vortrag sehr technologieorientiert und interessant ist, ist es nicht sicher, dass du einige Best Practices aus dem Vortrag in deinem Unternehmen anwenden kannst. Und dann brauchst du einen guten Referenten.

Das Licht am Ende der Pipeline bei Raiffeisenbank

Normalerweise suche ich in den Pausen nach interessanten Referenten. Auf dem DevOpsForum 2019 fiel mir ein Referent von der Raiffeisenbank – Michail Bizhan – auf. Während seines Vortrags erklärte er, wie sie ihre Teams schrittweise auf DevOps umstellen, warum sie das benötigen und wie man der Unternehmensführung die Idee der DevOps-Transformation verkauft. Er sprach auch darüber, wie man das Licht am Ende der Pipeline sehen kann.

Michail Bizhan, Direktor für Automatisierung bei Raiffeisenbank

In ihrem Unternehmen gibt es derzeit kein „echtes DevOps“. Es ist echt, aber nicht in allen Teams. Bei der Implementierung von DevOps stützen sie sich auf die Bereitschaft der Teams, sowohl aus Sicht der einzelnen Ingenieure als auch in Bezug auf die Bedürfnisse des Produkts und die Reife der Plattform, auf der dieses Produkt aufgebaut ist. Misha erzählte, wie man dem Geschäft erklärt, warum DevOps notwendig ist.

Der Bankensektor hat mehrere Wachstumsfaktoren: die Kosten der Dienstleistungen und die Erweiterung des Kundenstamms. Die Erhöhung der Kosten ist kein besonders guter Wachstumsfaktor, während das Wachstum des Kundenstamms im Gegenteil positiv ist. Wenn die Wettbewerber ein objektiv gutes Produkt anbieten, gehen alle Kunden dorthin, und im Laufe der Zeit stabilisiert sich der Markt. Daher ist die Einführung neuer Produkte und die Geschwindigkeit, mit der sie auf den Markt gebracht werden, das Hauptaugenmerk der Banken. Genau dafür wird DevOps benötigt, und das Geschäft versteht das.

Ein weiterer wichtiger Punkt: DevOps verkürzt nicht immer die Markteinführungszeit. DevOps kann nicht für sich allein arbeiten; es ist nur ein Teil des Prozesses zur Erstellung und Markteinführung des Produkts von der Entwicklung bis zur Produktion (von Code zu Kunde). Alles, was vor dem Code passiert, hat nichts mit DevOps zu tun. Das heißt, die Marketer können jahrelang den Markt analysieren und ein Leben lang hinter den Wettbewerbern herlaufen. Es ist entscheidend, schnell zu erkennen, was der Kunde braucht, und die Umsetzung eines bestimmten Features zu planen – oft fehlt genau das, damit DevOps effektiv arbeitet und das Unternehmen seine Ziele erreicht. Daher wurde zunächst bei Raiffeisenbank mit dem Geschäft vereinbart, dass man lernen muss, DevOps zu nutzen. Automatisierung um der Automatisierung willen wird im Kampf um neue Kunden nicht viel helfen.

Im Großen und Ganzen ist Misha der Meinung, dass DevOps eingeführt werden muss, aber mit Bedacht. Man muss darauf vorbereitet sein, dass anfangs die Produktivität des Teams sinkt und weniger Geld verdient wird, aber letztendlich wird sich das auszahlen.

Die Testautomatisierung bei "Mango Telecom"

Eine weitere interessante Präsentation hielt Egor Maslov von "Mango Telecom" für mich als Tester. Die Präsentation trug den Titel "Automatisierung des gesamten Testzyklus im SCRUM-Team". Egor ist der Ansicht, dass DevOps speziell für SCRUM geschaffen wurde, doch gleichzeitig ist es ziemlich problematisch, DevOps in ein SCRUM-Team umzusetzen. Das liegt daran, dass das SCRUM-Team ständig irgendwohin eilt und keine Zeit hat, um sich mit Neuerungen und Prozessanpassungen zu beschäftigen. Außerdem gibt es das Problem, dass SCRUM keine Unterteams innerhalb des Teams (Tester-Team, Entwickler-Team usw.) vorsieht. Darüber hinaus ist für die Automatisierung des bestehenden Prozesses Dokumentation erforderlich, und im SCRUM fehlt diese häufig vollständig - "das Produkt ist wichtiger als irgendwelche Aufzeichnungen."

Nach dem Wechsel zu SCRUM begannen die Tester, die Entwickler zu konsultieren, wie sie die Funktionen testen sollten. Allmählich nahm das Funktionsvolumen zu, die Dokumentation fehlte, und sie entdeckten viele Bugs in den Funktionen, die nicht getestet wurden, und es war unklar, wer und wann sie getestet hatte. Kurz gesagt - Chaos und Verwirrung. Sie beschlossen, zur Automatisierung des Testens überzugehen. Doch auch dann gab es ein komplettes Fiasko. Sie engagierten externe Spezialisten für die Automatisierung, die in einem für die internen Tester unbekannten Stack programmierten. Das Framework für die Autotests funktionierte zwar, aber nachdem die Outsourcing-Spezialisten weg waren, hielt es nur zwei Wochen. Dann gab es einen zweiten Versuch der Einführung automatisierter Tests. Dieser begann damit, dass alles innerhalb der Firma und mit eigenen Kräften aufgebaut werden musste (richtige Richtung: Expertise im Unternehmen aufbauen), im Rahmen von SCRUM und während des Prozesses Dokumentationen zu erstellen. Der Stack für die Automatisierung sollte dem Produktstack entsprechen (hier stimme ich voll und ganz zu, testen Sie ein Projekt nicht mit etwas anderem als JavaScript). Am Ende jedes Sprints veranstalteten sie eine Demo, wie der Autotest funktioniert, mit der gesamten Teamteilnahme (nützlich). Auf diese Weise wurde das Engagement aller Teammitglieder im Automatisierungsprozess gesteigert, das Vertrauen in die Autotests gestärkt und die Wahrscheinlichkeit erhöht, dass dieser Autotest tatsächlich genutzt wird (und nicht nach einem Monat wegen ständiger Fehler auskommentiert wird).

Übrigens gab es auf dem DevOpsForum 2019 ein offenes Mikrofon – ein längst bekanntes und meiner Meinung nach nützliches Format für Vorträge. Man geht dahin, hört sich die Vorträge an und entscheidet dann, dass es im Rahmen der Konferenz sinnvoll ist, ein bestimmtes Thema oder ein Problem zu erörtern und relevante Erfahrungen zur Lösung einer Aufgabe zu teilen.

Ich habe außerdem bemerkt, dass die Organisatoren einen Stream für kurze Vorträge eingerichtet haben. Jeder Vortrag dauert nicht länger als 10 Minuten, danach folgt eine Fragerunde. So kann man zahlreiche Themen abdecken und Fragen an die Referenten stellen, die einem interessant erscheinen.

Zwischen den Vorträgen bin ich durch die Stände der Konferenzpartner geschlendert und habe viele verschiedene Dinge eingesammelt/gewonnen. Ach, ich liebe die Giveaways!

Runder Tisch und Fragen zu DevOps mit dem Entwicklungsleiter von AlfaStrakhovanie

Das Sahnehäubchen des DevOpsForum 2019 für mich war die einstündige Plenarsitzung mit DevOps-Experten. Vier Teilnehmer wurden eingeladen, um DevOps aus verschiedenen Perspektiven zu betrachten: Anton Isanin (AlfaStrakhovanie, Entwicklungsleiter), Nailya Zamashkina (Fintech Lab, Betriebsleiter), Oleg Yegorkin (Rostelecom, Agile-Coach) und Anton Martyanov (unabhängiger Experte, der DevOps aus geschäftlicher Sicht betrachtete).

Die Experten setzten sich näher zu den Teilnehmern und es ging los: Eine ganze Stunde lang stellten die Teilnehmer aus dem Saal ihre Fragen, während die Experten sich den Antworten stellten. Manchmal entbrannten echte Debatten. Die Fragen waren sehr unterschiedlich, zum Beispiel: Braucht man überhaupt DevOps-Ingenieure? Warum kann man sie nicht aus Systemadministratoren heranziehen? Sollte man jedem DevOps anbieten? Was ist der Wert davon und so weiter.

Danach habe ich persönlich mit Anton Isanin gesprochen. Wir diskutierten über die Notwendigkeit, die DevOps-Kultur in jedes Haus zu tragen, und beleuchteten die dunkle Seite der DevOps-Transformation.

Stellen wir uns vor, alle haben sich versammelt und beschlossen, dass DevOps sowohl für das Produkt als auch für das Geschäft und das Team notwendig ist. Los geht's mit der Implementierung. Es hat geklappt. Aufatmen. DevOps hat uns näher zum Kunden gebracht, nun können wir all seine Wünsche schnell erfüllen. Am Ende haben wir eine große Ops-Abteilung mit strengen Regulierungen und Anforderungen, die ständig Fehler im Produkt erzeugt und viele Anfragen erstellt. Dabei haben alle Fehler den Status "dringend", selbst wenn der Kunde plötzlich möchte, dass ein Button gelb statt grün wird. Das Projekt wächst, die Anzahl der Releases steigt und damit auch die Anzahl der Fehler und das Unverständnis der neuen Funktionalitäten bei den Kunden. Ops stellt zehn weitere Personen ein, um Fehler zu berichten, und die Entwicklung stellt fünfzehn ein, um sie zu beheben. Und anstatt neue Funktionen zu implementieren, beschäftigt sich das Team mit endlosen SDs, indem es dem Nutzer und gleichzeitig dem Support die Funktionalität erklärt. Am Ende sind sowohl Ops als auch Entwicklung beschäftigt, aber der Kunde und das Geschäft sind unzufrieden: Neue Features stecken fest. Es scheint, als gäbe es DevOps, aber irgendwie auch nicht.

Zur Notwendigkeit der Einführung von DevOps hat Anton unmissverständlich erklärt, dass dies direkt von der Größe des Unternehmens abhängt. Wenn die Betreuung eines Kunden im Jahr der Firma eine Milliarde einbringt – dann ist DevOps nicht nötig (vorausgesetzt, dass man diesem Kunden nicht regelmäßig neue Änderungen bereitstellen muss). Es läuft alles bestens. Aber wenn das Geschäft wächst und mehr Kunden hinzukommen, dann muss man sich anpassen. In der Regel gibt es anfangs kein richtiges Ops im Unternehmen. Zuerst entwickeln wir das Produkt, und erst dann wird uns klar, dass wir darauf achten müssen, dass das Produkt funktioniert, indem wir die Lieferungen im Auge behalten. ServernDann entsteht Ops. Wir müssen jedoch verstehen, dass Ops als separate Abteilung viele Barrieren für die Entwicklung aufstellen wird und alle Lieferungen ins Stocken geraten. Das bedeutet, dass in diesem Fall die DevOps-Kultur bereits relevant ist, wir jedoch die dunkle Seite nicht vergessen dürfen.

Quelle: habr.com