Ich habe kürzlich das von Logrocon gehostete DevOpsForum 2019 besucht. Auf dieser Konferenz versuchten die Teilnehmer, Lösungen und neue Tools für das effektive Zusammenspiel von Unternehmen und Spezialisten für Entwicklungs- und Informationstechnologiedienstleistungen zu finden.
Die Konferenz war ein Erfolg: Es gab wirklich viele nützliche Berichte, interessante Präsentationsformate und viel Kommunikation mit den Rednern. Und es ist besonders wichtig, dass niemand versucht hat, mir etwas zu verkaufen, als die Redner auf großen Konferenzen in letzter Zeit beschuldigt haben.
Alfastrakhovanie, die Erfahrung von Mango Telecom bei der Implementierung von Automatisierung und andere Details im Rahmen des Schnitts.
Mein Name ist Yana, ich arbeite als Tester, ich beschäftige mich mit Automatisierung sowie mit DevOps und ich gehe gerne zu Konferenzen und Meetings. In den letzten zwei Jahren war ich auf Konferenzen von Oleg Bunin (HighLoad ++, TeamLead Conf), Krugveranstaltungen (Heisenbug, JPoint), TestCon Moskau, DevOps Pro Moskau und Big Data Moskau.
Zunächst achte ich auf das Konferenzprogramm. In geringerem Maße schaue ich mir an, worum es in dem Bericht geht, in größerem Maße - für den Redner. Auch wenn sich der Bericht als sehr technologisch und interessant herausstellt, ist es keine Tatsache, dass Sie in Ihrem Unternehmen einige Best Practices aus dem Bericht anwenden können. Und dann brauchen Sie einen Lautsprecher.
Licht am Ende der Pipeline an der Raiffeisenbank
Normalerweise gehe ich am Rande auf die Suche nach interessanten Rednern. Auf dem DevOpsForum 2019 kam ein Sprecher der Raiffeisenbank, Mikhail Bizhan, in mein Interessengebiet. Während der Rede erzählte er, wie sie ihre Teams stetig auf DevOps setzen, warum sie es brauchen und wie sie die Idee der DevOps-Transformation an Unternehmen verkaufen können. Im Allgemeinen habe ich darüber gesprochen, wie man das Licht am Ende der Pipeline sieht.
Mikhail Bizhan, Director of Automation bei der RaiffeisenbankJetzt hat ihre Firma keine "DevOps" mehr. Das heißt, er ist wahr, aber nicht in allen Teams. Bei der Implementierung von DevOps verlassen sie sich auf die Bereitschaft von Teams, sowohl aus Sicht bestimmter Ingenieure als auch aus Sicht der Produktanforderungen und der Reife der Plattform, auf der dieses Produkt basiert. Mischa erklärte dem Unternehmen, wie man erklärt, warum DevOps benötigt wird.
Das Bankensegment weist mehrere Wachstumstreiber auf: die Kosten für Dienstleistungen und die Erweiterung des Kundenstamms. Die Erhöhung der Servicekosten ist kein sehr guter Treiber, aber das Wachstum des Kundenstamms ist umgekehrt. Wenn Wettbewerber ein objektiv cooles Produkt produzieren, gehen alle Kunden dorthin, dann wird sich der Markt im Laufe der Zeit ausgleichen. Daher ist die Einführung neuer Produkte auf dem Markt und die Geschwindigkeit ihrer Einführung die Hauptsache, an der sich die Banken orientieren. Genau dafür ist DevOps gedacht, und das Unternehmen versteht dies.
Der folgende wichtige Hinweis: DevOps verkürzt nicht immer die Markteinführungszeit. DevOps kann nicht alleine arbeiten, 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 hat keine direkte Beziehung zu DevOps. Das heißt, Vermarkter können den Markt jahrelang studieren und ihr ganzes Leben lang mit Wettbewerbern mithalten. Sie müssen schnell verstehen, was der Kunde benötigt, und die Implementierung einer bestimmten Funktion planen. Oft reicht dies nicht aus, damit DevOps funktioniert und das Unternehmen das Ziel erreicht. Daher stimmte die Raiffeisenbank zunächst dem Unternehmen zu, dass es notwendig sei, den Umgang mit DevOps zu erlernen. Automatisierung im Interesse der Automatisierung wird im Kampf um neue Kunden nicht viel helfen.
Im Allgemeinen glaubt Mischa, dass DevOps implementiert werden sollte, aber mit Bedacht. Und Sie müssen darauf vorbereitet sein, dass das Team zu Beginn der Transformation an Produktivität verliert, weniger Geld verdient, aber dann wird es wahr.
Testautomatisierung bei Mango Telecom
Yegor Maslov von Mango Telecom machte einen weiteren interessanten Bericht für mich als Tester. Die Präsentation hieß "Automatisierung des gesamten Testzyklus im SCRUM-Team". Egor glaubt, dass DevOps speziell für SCRUM entwickelt wurde, aber gleichzeitig ist die Einführung von DevOps in das SCRUM-Team ziemlich problematisch. Dies liegt daran, dass das SCRUM-Team immer irgendwo unterwegs ist und keine Zeit bleibt, sich von Innovationen ablenken zu lassen und den Prozess neu aufzubauen. Das Problem liegt auch in der Tatsache, dass SCRUM keine Subteams (Testerteam, Entwicklungsteam usw.) impliziert. Darüber hinaus ist Dokumentation erforderlich, um den vorhandenen Prozess zu automatisieren, und in SCRUM gibt es meistens überhaupt keine Dokumentation - „ein Produkt ist wichtiger als irgendeine Art von Scribble“.
Nach dem Wechsel zu SCRUM begannen die Tester, sich mit Entwicklern über das Testen von Funktionen zu beraten. Allmählich nahm das Funktionsvolumen zu, die Dokumentation fehlte und es wurden viele Fehler in der Funktionalität festgestellt, bei denen es keine Testabdeckung gab, und im Allgemeinen war nicht mehr klar, wer und wann sie getestet wurden. Auf den Punkt gebracht - Verwirrung und Taumeln. Wir haben uns für die Testautomatisierung entschieden. Aber dann gab es einen völligen Misserfolg. Sie zogen ausgelagerte Spezialisten für Automatisierung an, die auf einen Stapel schrieben, der regulären Testern unbekannt war. Das Autotest-Framework hat sicherlich funktioniert, aber nachdem die Outsourcer gegangen waren, lebte er zwei Wochen. Dann gab es einen Versuch, den Selbsttest Nummer zwei einzuführen. Es begann mit der Tatsache, dass alles innerhalb des Unternehmens selbst erstellt werden muss (der richtige Vektor: Steigerung des Fachwissens innerhalb des Unternehmens), im Rahmen von SCRUM und bei der Erstellung von Dokumentationen. Der Stapel für die Automatisierung sollte dem Stapel des Produkts entsprechen (hier werde ich direkt darauf hinweisen, dass Sie Ihr Projekt in JavaScript nicht mit irgendetwas anderem testen sollten). Am Ende des Sprints arrangierten sie unter Beteiligung des gesamten Teams eine Demo der Funktionsweise des Autotests (nützlich). Dadurch wurde die Beteiligung aller Teammitglieder am Automatisierungsprozess sowie das Vertrauen in Autotests und die Wahrscheinlichkeit, dass dieser Autotest genau verwendet wird (und aufgrund ständiger Fehler in einem Monat nicht auskommentiert wird), erhöht.
Übrigens hat ein offenes Mikrofon im DevOpsForum 2019 funktioniert - ein seit langem bekanntes und meiner Meinung nach nützliches Format für Aufführungen. Sie gehen so, hören sich Berichte an und entscheiden dann, dass es sich lohnt, ein Thema oder Problem im Rahmen der Konferenz zu diskutieren und relevante Erfahrungen bei der Lösung des Problems auszutauschen.
Mir ist auch aufgefallen, dass die Organisatoren einen Strom von Kurzberichten gemacht haben. Jeder Bericht dauert nicht länger als 10 Minuten, dann kommen Fragen. Auf diese Weise können Sie viele Themen gleichzeitig behandeln und Fragen an interessierte Redner beantworten.
Zwischen den Berichten ging ich um die Stände der Konferenzpartner herum und zog / gewann eine Menge Sachen. Eh, ich liebe Razdatku!Runder Tisch und DevOps-Fragen mit Alfastrah Development Director
Die Kirsche auf dem DevOpsForum 2019-Kuchen war für mich eine einstündige Plenarsitzung mit DevOps-Experten. Vier Teilnehmer waren eingeladen, DevOps aus verschiedenen Blickwinkeln zu betrachten: Anton Isanin (Alfastrakhovanie, Entwicklungsleiter), Naila Zamashkina (Fintech Lab, Betriebsleiter), Oleg Egorkin (Rostelecom, Agile-Coach) und Anton Martyanov (unabhängig) Experte, betrachtete DevOps aus geschäftlicher Sicht).
Die Experten saßen näher an den Menschen und es begann: Eine Stunde lang stellten die Teilnehmer aus dem Publikum ihre Fragen, und die Experten blähten auf. Manchmal kam eine echte Debatte heraus. Die Fragen waren sehr unterschiedlich, zum Beispiel: Werden DevOps-Ingenieure überhaupt benötigt, warum können sie nicht von Systemadministratoren wachsen, sollten DevOps allen angeboten werden, welchen Wert sie haben und so weiter.
Dann habe ich persönlich mit Anton Isanin gesprochen. Wir diskutierten die Notwendigkeit, die DevOps-Kultur in jedes Haus zu bringen, und enthüllten 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 benötigt wird. Beeilte sich vorzustellen. Es hat alles geklappt. Ausgeatmet. DevOps hat uns dem Kunden näher gebracht, jetzt können wir schnell alle seine Wünsche erfüllen. Infolgedessen haben wir eine große Ops-Abteilung mit strengen Vorschriften und Anforderungen, die ständig Fehler für das Produkt herausfindet und eine Reihe von Anwendungen erstellt. Darüber hinaus haben alle Mängel den Status "dringend", auch wenn der Kunde den Knopf plötzlich gelb statt grün streichen wollte. Das Projekt wächst, die Anzahl der Releases wächst und dementsprechend die Anzahl der Fehler und Missverständnisse neuer Funktionen durch Kunden. Ops stellt weitere 10 Mitarbeiter ein, um mit den Fehlern Schritt zu halten, und Development stellt weitere 15 Mitarbeiter ein, um mit ihnen Schritt zu halten. Und anstatt neue Funktionen einzuführen, arbeitet das Team mit endlosen SDs und erklärt dem Benutzer die Funktionalität und den Support für eine. Infolgedessen arbeiten sowohl Ops als auch Entwicklung, aber der Kunde und das Unternehmen sind unglücklich: Neue Funktionen bleiben hängen. Es stellt sich heraus, dass DevOps da zu sein scheint, aber es scheint nicht so zu sein.
Über die Notwendigkeit, DevOps zu implementieren, erklärte Anton unmissverständlich, dass dies direkt von der Größe des Geschäfts abhängt. Wenn die Wartung eines Kunden pro Jahr dem Unternehmen eine Milliarde bringt - DevOps wird nicht benötigt (vorausgesetzt, Sie müssen nicht regelmäßig neue Änderungen an diesem Kunden vornehmen). Alles ist so Schokolade. Aber wenn das Geschäft wächst, mehr Kunden auftauchen, müssen wir uns bereits daran halten. In der Regel hat das Unternehmen zunächst keine coolen Ops. Zuerst haben wir das Produkt gesehen und erst dann haben wir verstanden, dass das Produkt funktionieren sollte. Sie müssen sich die Server ansehen und die Lieferungen überwachen. Dann entsteht Ops. Es bleibt abzuwarten, dass Ops als separate Einheit eine Reihe von Hindernissen für die Entwicklung aufdecken wird und alle Lieferungen ins Stocken geraten werden. Das heißt, in diesem Fall ist die DevOps-Kultur bereits relevant, aber Sie dürfen ihre Schattenseiten nicht vergessen.