Ich habe kürzlich am DevOpsForum 2019 teilgenommen, das von Logrocon veranstaltet wurde. Auf dieser Konferenz versuchten die Teilnehmer, Lösungen und neue Werkzeuge für eine effektive Interaktion zwischen Geschäfts- und Entwicklungs- und Informationstechnologiedienstleistungsspezialisten zu finden.
Die Konferenz war ein Erfolg: Es gab wirklich viele nützliche Berichte, interessante Vortragsformate und viel Kommunikation mit den Referenten. Und es ist besonders wichtig, dass niemand versucht hat, mir etwas zu verkaufen, was sich in letzter Zeit Rednern auf großen Konferenzen schuldig gemacht hat.
Ein Auszug aus den Reden der Raiffeisenbank, Alfastrakhovanie, der Erfahrung von Mango Telecom bei der Implementierung von Automatisierung und anderen Details im Rahmen des Schnitts.
Mein Name ist Yana, ich arbeite als Testerin, mache Automatisierung und DevOps und gehe gerne zu Konferenzen und Meetups. In den letzten zwei Jahren war ich auf Oleg Bunins Konferenzen (HighLoad++, TeamLead Conf), Jug-Events (Heisenbug, JPoint), TestCon Moskau, DevOps Pro Moskau und Big Data Moskau.
Zunächst möchte ich auf das Konferenzprogramm aufmerksam machen. Ich schaue weniger darauf, worum es in dem Bericht geht, sondern mehr auf den Redner. Auch wenn sich der Bericht als sehr technologisch und interessant herausstellt, ist es keine Tatsache, dass Sie einige der Best Practices aus dem Bericht in Ihrem Unternehmen anwenden können. Und dann brauchen Sie einen Redner.
Licht am Ende der Pipeline bei der Raiffeisenbank
Normalerweise suche ich am Spielfeldrand nach Rednern, die mich interessieren. Beim DevOpsForum 2019 hat ein Redner der Raiffeisenbank, Mikhail Bizhan, mein Interesse geweckt. Während seiner Rede sprach er darüber, wie sie ihre Teams nach und nach für DevOps begeistern, warum sie es brauchen und wie sie die Idee der DevOps-Transformation an Unternehmen verkaufen können. Nun, im Allgemeinen habe ich darüber gesprochen, wie man das Licht am Ende der Pipeline sieht.
Mikhail Bizhan, Direktor für Automatisierung bei der Raiffeisenbank
Jetzt haben sie kein „DevOps“ in ihrem Unternehmen. Das heißt, er funktioniert, aber nicht in allen Teams. Bei der Implementierung von DevOps verlassen sie sich auf die Bereitschaft der Teams, sowohl im Hinblick auf bestimmte Ingenieure als auch im Hinblick auf den Bedarf des Produkts und den Reifegrad der Plattform, auf der dieses Produkt aufbaut. Mischa erklärte, wie man einem Unternehmen erklärt, warum DevOps benötigt wird.
Das Bankensegment hat mehrere Wachstumstreiber: Kosten für Dienstleistungen und Erweiterung des Kundenstamms. Eine Erhöhung der Dienstleistungskosten ist kein besonders guter Treiber, die Vergrößerung des Kundenstamms ist jedoch das Gegenteil. Wenn Wettbewerber ein objektiv cooles Produkt herausbringen, gehen alle Kunden dorthin, und mit der Zeit stabilisiert sich der Markt. Daher stehen für Banken vor allem die Markteinführung neuer Produkte und die Geschwindigkeit ihrer Einführung im Vordergrund. Genau dafür ist DevOps da und Unternehmen verstehen das.
Der nächste wichtige Hinweis: DevOps verkürzt nicht immer die Markteinführungszeit. DevOps kann nicht alleine funktionieren, es ist nur ein Teil des Prozesses der Erstellung und Markteinführung eines Produkts von der Entwicklung bis zur Produktion (vom Code bis zum Kunden). Aber alles vor dem Code steht nicht in direktem Zusammenhang mit DevOps. Das heißt, Vermarkter können den Markt jahrelang studieren und ihr ganzes Leben damit verbringen, mit der Konkurrenz Schritt zu halten. Es ist notwendig, schnell zu verstehen, was der Kunde braucht, und die Implementierung dieser oder jener Funktion zu planen – oft reicht dies nicht aus, damit DevOps funktioniert und das Unternehmen sein Ziel erreicht. Daher war sich die Raiffeisenbank zunächst mit der Wirtschaft einig, dass es notwendig sei, den Umgang mit DevOps zu erlernen. Automatisierung um der Automatisierung willen hilft im Kampf um neue Kunden nicht viel.
Im Allgemeinen glaubt Misha, dass DevOps implementiert werden muss, aber mit Bedacht. Und wir müssen darauf vorbereitet sein, dass zu Beginn der Transformation die Produktivität des Teams sinkt, es weniger Geld verdient, aber dann wird es gerechtfertigt sein.
Automatisierung von Tests bei Mango Telecom
Ein weiterer für mich als Tester interessanter Bericht stammt von Egor Maslov von Mango Telecom. Der Vortrag trug den Titel „Automatisierung des gesamten Testzyklus in einem SCRUM-Team“. Egor glaubt, dass DevOps speziell für SCRUM entwickelt wurde, aber gleichzeitig ist die Einführung von DevOps in einem SCRUM-Team ziemlich problematisch. Dies geschieht, weil das SCRUM-Team immer irgendwo läuft und keine Zeit bleibt, sich von Innovationen ablenken zu lassen und den Prozess neu aufzubauen. Das Problem liegt auch darin, dass SCRUM keine Trennung von Unterteams im Team (Testteam, Entwicklungsteam usw.) vorsieht. Um einen bestehenden Prozess zu automatisieren, ist außerdem eine Dokumentation erforderlich, und in SCRUM gibt es meistens keine vollständige Dokumentation – „das Produkt ist wichtiger als irgendeine Art von Schrift.“
Nach dem Wechsel zu SCRUM begannen die Tester, sich mit den Entwicklern darüber zu beraten, wie Funktionen getestet werden sollten. Allmählich nahm der Funktionsumfang zu, es gab keine Dokumentation und man fing an, viele Fehler in der Funktionalität zu entdecken, die nicht durch Tests abgedeckt wurden, und im Allgemeinen war nicht mehr klar, wer sie wann getestet hat. Kurz gesagt: Verwirrung und Schwanken. Wir haben uns entschieden, auf Testautomatisierung umzusteigen. Aber auch dann kam es zum völligen Misserfolg. Sie stellten ausgelagerte Automatisierungsspezialisten ein, die auf einem Stack schrieben, der den hauseigenen Testern unbekannt war. Das Framework für Autotests funktionierte natürlich, aber nachdem die Outsourcer gegangen waren, hielt es zwei Wochen lang durch. Als nächstes folgte der Versuch, Autotest Nummer zwei einzuführen. Es begann damit, dass alles im Unternehmen selbst aufgebaut werden muss (der richtige Vektor: Know-how intern aufbauen), im Rahmen von SCRUM und dabei Dokumentation erstellen. Der Stack für die Automatisierung sollte dem Stack des Produkts entsprechen (hier füge ich ihn hinzu, testen Sie Ihr JavaScript-Projekt nicht mit etwas anderem). Am Ende des Sprints führten sie mit dem gesamten Team eine Demo durch, wie der Autotest funktioniert (hilfreich). Dadurch stieg die Einbindung aller Teammitglieder in den Automatisierungsprozess sowie das Vertrauen in Autotests und die Chance, dass dieser Autotest definitiv genutzt wird (und aufgrund ständiger Ausfälle nicht in einem Monat auskommentiert wird).
Beim DevOpsForum 2019 gab es übrigens ein offenes Mikrofon – ein seit langem bekanntes und meiner Meinung nach nützliches Redensformat. Sie gehen so herum, hören sich Berichte an und entscheiden dann, dass es sich lohnt, auf der Konferenz ein bestimmtes Thema oder Problem zu diskutieren und relevante Erfahrungen bei der Lösung des Problems auszutauschen.
Mir ist auch aufgefallen, dass die Organisatoren eine Reihe von Kurzberichten erstellt haben. Jeder Bericht dauert maximal 10 Minuten, gefolgt von Fragen. Auf diese Weise können Sie viele Themen gleichzeitig behandeln und den Referenten, die Sie interessieren, Fragen stellen.
Zwischen den Vorträgen bin ich an den Ständen der Konferenzpartner herumgelaufen und habe jede Menge Sachen gestohlen/gewonnen. Oh, ich liebe das Handout!
Runder Tisch und DevOps-Themen mit dem Entwicklungsleiter bei Alfastrakhovanie
Das Tüpfelchen auf dem DevOpsForum 2019 war für mich die einstündige Plenarsitzung mit DevOps-Experten. Vier Sitzungsteilnehmer wurden eingeladen, DevOps aus verschiedenen Blickwinkeln zu betrachten: Anton Isanin (Alfastrakhovanie, Entwicklungsleiter), Nailya Zamashkina (Fintech Lab, Betriebsleiterin), Oleg Egorkin (Rostelecom, Agile Coach) und Anton Martyanov (unabhängiger Experte, betrachteten DevOps). aus betriebswirtschaftlicher Sicht).
Die Experten setzten sich näher an die Menschen und dann ging es los: Eine ganze Stunde lang stellten Teilnehmer aus dem Publikum ihre Fragen, und die Experten übernahmen die Verantwortung. Manchmal gab es echte Debatten. Die Fragen waren sehr unterschiedlich, zum Beispiel: Werden DevOps-Ingenieure überhaupt benötigt, warum können sie nicht zu Systemadministratoren ausgebildet werden, sollte DevOps allen angeboten werden, welchen Wert hat es und so weiter.
Dann habe ich persönlich mit Anton Isanin gesprochen. Wir haben die Notwendigkeit besprochen, die DevOps-Kultur in jedes Zuhause zu bringen, und die Schattenseiten der DevOps-Transformation aufgezeigt.
Stellen wir uns vor, dass alle zusammenkommen und entscheiden, dass DevOps sowohl für das Produkt als auch für das Unternehmen und das Team erforderlich ist. Lasst es uns umsetzen. Es hat alles geklappt. Wir atmeten aus. DevOps hat uns näher an den Kunden gebracht, jetzt können wir alle seine Wünsche schnell erfüllen. Daher verfügen wir über eine große Betriebsabteilung mit strengen Vorschriften und Anforderungen, die ständig Mängel am Produkt findet und eine Reihe von Anfragen generiert. Darüber hinaus erhalten alle Mängel den Status „dringend“, auch wenn der Kunde den Button unerwarteterweise gelb statt grün einfärben wollte. Das Projekt wächst, die Zahl der Releases wächst und dementsprechend auch die Zahl der Mängel und Missverständnisse neuer Funktionalitäten seitens der Kunden. Ops stellt 10 weitere Leute ein, um mit der Meldung von Fehlern Schritt zu halten, und die Entwicklung stellt 15 weitere Leute ein, um mit der Behebung der Fehler Schritt zu halten. Und anstatt neue Funktionen einzuführen, arbeitet das Team mit endlosen SDs, um dem Benutzer die Funktionalität zu erklären und gleichzeitig zu unterstützen. Infolgedessen funktionieren sowohl der Betrieb als auch die Entwicklung, aber der Kunde und das Unternehmen sind unzufrieden: Neue Funktionen bleiben hängen. Es stellt sich heraus, dass DevOps zu existieren scheint, aber es scheint nicht zu existieren.
Bezüglich der Notwendigkeit, DevOps zu implementieren, stellte Anton klar fest, dass diese direkt von der Größe des Unternehmens abhängt. Wenn die Betreuung eines Kunden pro Jahr dem Unternehmen eine Milliarde einbringt, ist DevOps nicht erforderlich (vorausgesetzt, Sie müssen bei diesem Kunden nicht regelmäßig neue Änderungen einführen). Alles ist mit Schokolade überzogen. Aber wenn das Geschäft wächst und mehr Kunden hinzukommen, müssen Sie sich daran halten. In der Regel gibt es zunächst keine coolen Ops im Unternehmen. Zuerst schneiden wir das Produkt ab und erst dann verstehen wir, dass wir die Server im Auge behalten und die Vorräte überwachen müssen, damit das Produkt funktioniert. Dann entsteht Ops. Es bleibt abzuwarten, dass Ops als eigenständige Abteilung eine Reihe von Hürden für die Entwicklung errichten wird und alle Auslieferungen ins Stocken geraten werden. Das heißt, in diesem Fall ist die DevOps-Kultur bereits relevant, aber wir dürfen ihre Schattenseiten nicht vergessen.
Source: habr.com