DevOpsForum 2019. Die Einführung von DevOps kann nicht aufgeschoben werden.

Vor kurzem habe ich das DevOpsForum 2019 besucht, das von Logrocon veranstaltet wurde. Auf dieser Konferenz versuchten die Teilnehmer, Lösungen und neue Werkzeuge für eine effektive Zusammenarbeit zwischen Unternehmen und Fachleuten für Softwareentwicklung sowie IT-Services zu finden.

Die Konferenz war ein voller Erfolg: es gab viele nützliche Vorträge, interessante Präsentationsformate und zahlreiche Gespräche mit den Referenten. Besonders bemerkenswert war, dass mir niemand etwas verkaufen wollte, was in letzter Zeit bei großen Konferenzen oft der Fall ist.

Hier sind die wichtigsten Erkenntnisse aus den Vorträgen von Raiffeisenbank, Alfastrakhovanie, sowie Erfahrungen von Mango Telecom zur Implementierung von Automatisierung und weitere Details im Folgenden.

Ich heiße Jana, arbeite als Tester, beschäftige mich mit Automatisierung und DevOps und liebe es, Konferenzen und Meetups zu besuchen. 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 und Big Data Moscow.

Zuerst achte ich auf das Programm der Konferenz. Weniger auf das Thema der Präsentation, viel mehr auf den Referenten. Selbst wenn die Präsentation sehr technisch und interessant ist, ist es nicht sicher, dass du irgendwelche Best Practices in deinem Unternehmen anwenden kannst. Du benötigst also einen guten Referenten.

Das Licht am Ende des Pipelines bei der Raiffeisenbank

In der Regel jage ich in den Korridoren nach interessanten Referenten. Auf dem DevOpsForum 2019 fiel mir ein Sprecher von der Raiffeisenbank ins Auge – Michael Bijan. Während seines Vortrags erklärte er, wie sie schrittweise ihre Teams auf DevOps umstellen, warum sie das brauchen und wie sie der Geschäftsführung die Idee der DevOps-Transformation verkaufen können. Er sprach auch allgemein darüber, wie man das Licht am Ende des Pipelines sieht.

Michael Bijan, Automatisierungsdirektor bei der Raiffeisenbank

Aktuell gibt es in ihrem Unternehmen kein 'echtes DevOps'. Das bedeutet, es gibt tatsächlich echte DevOps, jedoch nicht in allen Teams. Bei der Implementierung von DevOps verlassen sie sich auf die Bereitschaft der Teams, sowohl in Bezug auf die spezifischen Ingenieure als auch auf die Bedürfnisse des Produkts und die Reife der Plattform, auf der dieses Produkt basiert. Misha erklärte, wie man dem Geschäftsbereich den Nutzen von DevOps verständlich machen kann.

Der Bankensektor hat mehrere Wachstumsfaktoren: die Kosten für Dienstleistungen und die Erweiterung des Kundenstamms. Eine Erhöhung der Dienstleistungskosten ist kein besonders guter Wachstumsfaktor, während das Wachstum des Kundenstamms das Gegenteil ist. Wenn Wettbewerber ein objektiv tolles Produkt herausbringen, wandern alle Kunden dorthin, aber mit der Zeit gleicht sich der Markt wieder aus. Daher ist die Einführung neuer Produkte und die Geschwindigkeit, mit der sie auf den Markt kommen, das Hauptaugenmerk der Banken. Genau dafür ist DevOps notwendig, und das Geschäft versteht dies.

Eine wichtige Anmerkung: DevOps verkürzt nicht immer die Markteinführungszeit. DevOps kann nicht allein funktionieren; es ist lediglich ein Teil des Prozesses, der von der Entwicklung bis zur Markteinführung reicht (von Code bis Kunde). Alles, was vor dem Code geschieht, hat nichts mit DevOps zu tun. Das bedeutet, dass Marketingteams jahrelang den Markt analysieren und lebenslang den Konkurrenten hinterherlaufen können. Es ist wichtig, schnell zu verstehen, was der Kunde benötigt, und die Umsetzung bestimmter Funktionen zu planen – oft fehlt genau das, damit DevOps funktioniert und das Unternehmen seine Ziele erreicht. Daher wurde im Raiffeisenbank als Erstes eine Einigung mit dem Geschäft erzielt, dass DevOps effektiv genutzt werden muss. Automatisierung um der Automatisierung willen wird wenig bringen, um neue Kunden zu gewinnen.

Im Allgemeinen ist Misha der Meinung, dass DevOps implementiert werden sollte, jedoch mit Bedacht. Man muss bereit sein, dass die Produktivität des Teams zu Beginn der Transformation zurückgeht und es weniger Geld verdienen wird, aber letztlich wird sich das auszahlen.

Automatisierung von Tests bei „Mango Telekom“

Egor Maslov von „Mango Telecom“ hat einen weiteren interessanten Vortrag für mich als Tester gehalten. Die Präsentation trug den Titel „Automatisierung des vollständigen Testzyklus in einem SCRUM-Team“. Egor ist der Meinung, dass DevOps speziell für SCRUM geschaffen wurde, aber die Implementierung von DevOps in ein SCRUM-Team ist ziemlich herausfordernd. Das liegt daran, dass das SCRUM-Team ständig in Eile ist und keine Zeit hat, sich mit Neuerungen zu beschäftigen und den Prozess umzustellen. Ein weiteres Problem besteht darin, dass SCRUM keine Unterteams innerhalb des Teams vorsieht (z. B. ein Testteam, ein Entwicklerteam usw.). Außerdem ist zur Automatisierung des bestehenden Prozesses Dokumentation erforderlich, die in SCRUM jedoch häufig vollständig fehlt – „das Produkt ist wichtiger als irgendwelches Geschriebene“.

Nach der Einführung von SCRUM begannen die Tester, sich mit den Entwicklern abzusprechen, wie sie Funktionen testen sollten. Allmählich wuchs der Funktionsumfang, während die Dokumentation fehlte, und sie entdeckten zahlreiche Bugs in der Funktionalität, die nicht durch Tests abgedeckt war. Es war nicht mehr klar, wer wann getestet hatte. Kurz gesagt – ein Durcheinander. Sie entschieden sich, die Testautomatisierung einzuführen. Doch auch das endete in einem kompletten Fiasko. Sie holten externe Spezialisten zur Automatisierung, die in einem für die internen Tester unbekannten Technologie-Stack arbeiteten. Der Framework für die automatisierten Tests funktionierte zwar, aber nachdem die Outsourcing-Spezialisten gegangen waren, hielt er nur zwei Wochen lang. Dann gab es den Versuch, die automatisierte Testung ein zweites Mal einzuführen. Es begann damit, dass alles intern im Unternehmen, mit eigenen Kräften aufgebaut werden sollte (der richtige Ansatz: Expertise intern aufbauen), im Rahmen von SCRUM, und währenddessen Dokumentation zu erstellen. Der Stack für die Automatisierung sollte dem Produkt-Stack entsprechen (hier stimme ich vollkommen zu, testen Sie ein Projekt nicht mit etwas anderem als den Tools, die auch im Projekt verwendet werden). Am Ende des Sprints führten sie eine Demo durch, um zu zeigen, wie der automatisierte Test funktioniert, mit der gesamten Teamteilnahme (sehr hilfreich). Auf diese Weise wurde das Engagement aller Teammitglieder im Automatisierungsprozess erhöht, ebenso wie das Vertrauen in die automatisierten Tests und die Wahrscheinlichkeit, dass dieser automatisierte Test wirklich verwendet wird (und nicht einen Monat später wegen ständiger Fehler auskommentiert wird).

Übrigens gab es beim DevOpsForum 2019 ein offenes Mikrofon — ein seit langem bekanntes und, meiner Meinung nach, hilfreiches Format für Präsentationen. Man sitzt da, hört sich die Vorträge an und entscheidet dann, dass es im Rahmen der Konferenz wertvolle Themen oder Probleme gibt, die man diskutieren oder relevante Lösungsansätze teilen möchte.

Ich habe außerdem bemerkt, dass die Organisatoren einen Block mit kurzen Vorträgen eingerichtet haben. Jeder Vortrag dauert nicht länger als 10 Minuten, gefolgt von Fragen. So können viele Themen schnell behandelt und Fragen an die Sprecher gerichtet werden, die einem besonders aufgefallen sind.

Zwischen den Vorträgen habe ich mich an den Ständen der Partner der Konferenz umgesehen und viel Schnickschnack gewonnen / mitgenommen. Ach, ich liebe die Giveaway-Artikel!

Eine Diskussionsrunde und Fragen zum Thema DevOps mit dem Entwicklungsdirektor von Альфастрахование

Das Highlight des DevOpsForum 2019 war für mich eine einstündige Plenarsitzung mit DevOps-Experten. Vier Teilnehmer wurden eingeladen, um DevOps aus verschiedenen Perspektiven zu betrachten: Anton Isanin (AlfaStrakhovanie, Entwicklungsdirektor), Nailya Zamashkina (Fintech Lab, Betriebsleiterin), Oleg Yegorkin (Rostelecom, Agile Coach) und Anton Martyánov (unabhängiger Experte, der die Geschäftsperspektive von DevOps betrachtet hat).

Die Experten nahmen Platz nah am Publikum, und schon ging es los: Eine ganze Stunde lang stellten die Teilnehmer aus dem Publikum ihre Fragen, während die Experten sich anstrengten, sie zu beantworten. Manchmal gab es echte Debatten. Die Fragen waren sehr vielfältig, z.B.: Braucht man überhaupt DevOps-Engineers, warum kann man sie nicht aus Systemadministratoren entwickeln, sollte DevOps jedem angeboten werden, was ist dessen Wert und so weiter.

Anschließend hatte ich ein persönliches Gespräch mit Anton Isanin. Wir besprachen die Notwendigkeit, die DevOps-Kultur in jedes Zuhause zu bringen, und beleuchteten die Schattenseiten der DevOps-Transformation.

Stellen Sie sich vor, alle haben sich versammelt und entschieden, dass DevOps sowohl für das Produkt als auch für das Unternehmen und das Team notwendig ist. Der Implementierungsprozess begann. Es hat geklappt. Wir atmen erleichtert auf. DevOps hat uns näher an den Kunden gebracht, sodass wir nun schnell auf all seine Wünsche reagieren können. Am Ende haben wir eine große Ops-Abteilung mit strengen Vorschriften und Anforderungen, die ständig Defekte im Produkt erzeugt und eine Menge Tickets erstellt. Außerdem kommen alle Defekte mit dem Status „dringend“, selbst wenn der Kunde plötzlich möchte, dass ein Knopf von grün auf gelb umgefärbt wird. Das Projekt wächst, die Anzahl der Releases steigt und damit auch das Volumen an Defekten sowie das Verständnis von neuen Funktionen seitens der Kunden. Ops stellt 10 weitere Mitarbeiter ein, um mit dem Melden der Defekte Schritt zu halten, während die Entwicklung 15 neue Leute anheuert, um diese zu beheben. Anstatt neue Features einzuführen, beschäftigt sich das Team mit endlosen SDs und erklärt die Funktionalität sowohl den Benutzern als auch dem Support. Am Ende sind sowohl Ops als auch die Entwicklung beschäftigt, aber der Kunde und das Unternehmen sind unzufrieden: Neue Funktionen kommen nicht voran. Es scheint, als hätten wir DevOps, aber irgendwie auch nicht.

Anton betonte eindeutig, dass die Notwendigkeit zur Einführung von DevOps direkt von der Unternehmensgröße abhängt. Wenn die Betreuung eines Kunden im Jahr dem Unternehmen eine Milliarde einbringt – dann wird DevOps nicht benötigt (vorausgesetzt, es sind keine regelmäßigen Änderungen für diesen Kunden erforderlich). Alles läuft rund. Doch wenn das Geschäft wächst und mehr Kunden hinzukommen, ist es notwendig, sich entsprechend zu organisieren. In der Regel hat ein Unternehmen anfangs keinen ausgeprägten Operations-Bereich. Zuerst entwickeln wir das Produkt und erkennen dann, dass wir darauf achten müssen, dass es funktioniert und Lieferungen überwacht werden müssen. Servern gearbeitet werden.Dann entsteht der Bedarf nach Operations. Es bleibt zu klären, dass Ops als eigenständige Abteilung eine Menge Barrieren für die Entwicklung aufbauen kann, wodurch alle Lieferungen ins Stocken geraten. In diesem Fall ist die DevOps-Kultur bereits relevant, wobei jedoch die dunkle Seite nicht vergessen werden sollte.

Quelle: habr.com