Niedawno uczestniczyłem w DevOpsForum 2019, którego gospodarzem jest Logrocon. Uczestnicy tej konferencji próbowali znaleźć rozwiązania i nowe narzędzia efektywnej interakcji pomiędzy biznesem a specjalistami ds. rozwoju i usług informatycznych.
Konferencja zakończyła się sukcesem: było naprawdę dużo przydatnych raportów, ciekawe formaty prezentacji i dużo komunikacji z prelegentami. A szczególnie ważne jest to, że nikt nie próbował mi niczego sprzedać, co ostatnio jest winą prelegentów na dużych konferencjach.
Fragment przemówień Raiffeisenbank, Alfastrakhovanie, doświadczenie Mango Telecom we wdrażaniu automatyzacji i inne szczegóły objęte cięciem.
Mam na imię Yana, pracuję jako tester, zajmuję się automatyzacją, a także DevOps i uwielbiam chodzić na konferencje i spotkania. W ciągu ostatnich dwóch lat byłem na konferencjach Olega Bunina (HighLoad++, TeamLead Conf), wydarzeniach Jug (Heisenbug, JPoint), TestCon Moskwa, DevOps Pro Moskwa, Big Data Moskwa.
W pierwszej kolejności zwracam uwagę na program konferencji. Mniej patrzę na to, o czym będzie raport, a bardziej na mówcę. Nawet jeśli raport okaże się bardzo technologiczny i ciekawy, nie jest faktem, że część dobrych praktyk z raportu będziesz mógł zastosować w swojej firmie. A wtedy potrzebujesz głośnika.
Światło na końcu rurociągu w Raiffeisenbank
Zazwyczaj z boku szukam mówców, którzy mnie interesują. Na DevOpsForum 2019 moje zainteresowanie wzbudził prelegent z Raiffeisenbank Mikhail Bizhan. Podczas swojego wystąpienia opowiedział o tym, jak stopniowo uzależniają swoje zespoły od DevOps, dlaczego tego potrzebują i jak sprzedać pomysł transformacji DevOps biznesowi. Cóż, ogólnie mówiłem o tym, jak zobaczyć światło na końcu rurociągu.
Michaił Bizhan, dyrektor ds. automatyzacji w Raiffeisenbank
Teraz nie mają „DevOps” w swojej firmie. Oznacza to, że pracuje, ale nie we wszystkich zespołach. Wdrażając DevOps stawiają na gotowość zespołów, zarówno pod względem konkretnych inżynierów, jak i pod względem zapotrzebowania na produkt i dojrzałości platformy, na której ten produkt jest zbudowany. Misha opowiedziała, jak wytłumaczyć biznesowi, dlaczego DevOps jest potrzebny.
Segment bankowy ma kilka czynników wzrostu: koszty usług i rozwój bazy klientów. Zwiększanie kosztów usług nie jest zbyt dobrym czynnikiem, ale powiększanie bazy klientów jest odwrotnością. Jeśli konkurencja wypuści obiektywnie fajny produkt, wszyscy klienci tam pójdą, a z biegiem czasu rynek się wyrówna. Dlatego też wprowadzanie nowych produktów na rynek i szybkość ich wprowadzania to najważniejsza rzecz, na której skupiają się banki. Właśnie do tego służy DevOps i firmy to rozumieją.
Następna ważna uwaga: DevOps nie zawsze skraca czas wprowadzenia produktu na rynek. DevOps nie może działać sam, jest tylko częścią procesu tworzenia i wprowadzania produktu na rynek od opracowania do produkcji (od kodu do klienta). Ale wszystko przed kodem nie jest bezpośrednio związane z DevOps. Oznacza to, że marketerzy mogą latami badać rynek i spędzić całe życie na doganianiu konkurencji. Trzeba szybko zrozumieć, czego potrzebuje klient i zaplanować wdrożenie tej czy innej funkcjonalności – często to właśnie nie wystarczy, aby DevOps zadziałał, a firma osiągnęła swój cel. Dlatego przede wszystkim Raiffeisenbank zgodził się z biznesem, że trzeba nauczyć się korzystać z DevOps. Automatyzacja dla samej automatyzacji niewiele pomoże w walce o nowych klientów.
Generalnie Misha uważa, że DevOps trzeba wdrażać, ale mądrze. A trzeba być przygotowanym na to, że na początku transformacji produktywność zespołu spadnie, będzie on mniej zarabiał, ale wtedy będzie to uzasadnione.
Automatyzacja testów w Mango Telecom
Kolejny ciekawy raport dla mnie jako testera wygłosił Egor Maslov z Mango Telecom. Prezentacja nosiła tytuł „Automatyzacja pełnego cyklu testowania w zespole SCRUM”. Egor uważa, że DevOps został stworzony specjalnie dla SCRUM-a, ale jednocześnie wprowadzenie DevOps do zespołu SCRUM-owego jest dość problematyczne. Dzieje się tak dlatego, że zespół SCRUM ciągle gdzieś biegnie, nie ma czasu na rozpraszanie się innowacjami i przebudowywanie procesu. Problem polega również na tym, że SCRUM nie zakłada wyodrębnienia w zespole podzespołów (zespół testujący, zespół programistyczny itd.). No cóż, poza tym, żeby zautomatyzować istniejący proces, potrzebna jest dokumentacja, a w SCRUM-ie najczęściej nie ma dokumentacji w całości – „ważniejszy jest produkt niż jakieś pisanie”.
Po przejściu na SCRUM testerzy zaczęli konsultować się z programistami w sprawie testowania funkcji. Stopniowo zwiększała się liczba funkcjonalności, nie było dokumentacji i zaczęli wychwytywać wiele błędów w funkcjonalności, które nie były objęte testami i ogólnie nie było już jasne, kto i kiedy to testował. Krótko mówiąc – zamieszanie i wahanie. Zdecydowaliśmy się przejść na automatyzację testów. Ale nawet wtedy doszło do całkowitej porażki. Zatrudnili zewnętrznych specjalistów od automatyzacji, którzy pisali na stosie nieznanym wewnętrznym testerom. Ramy autotestów oczywiście zadziałały, ale po odejściu outsourcerów trwało to dwa tygodnie. Następna była próba wprowadzenia autotestowania numer dwa. Zaczęło się od tego, że wszystko trzeba zbudować wewnątrz firmy, samodzielnie (właściwy wektor: budować kompetencje wewnętrznie), w ramach SCRUM i przy okazji stworzyć dokumentację. Stos do automatyzacji powinien być równy stosowi produktu (tutaj go dodaję, nie testuj swojego projektu JavaScript z niczym innym). Na koniec sprintu zrobili demo, jak działa autotest z całym zespołem (pomocne). Tym samym wzrosło zaangażowanie wszystkich członków zespołu w proces automatyzacji, a także zaufanie do autotestów i szansa, że ten autotest na pewno zostanie wykorzystany (a nie będzie komentowany za miesiąc ze względu na ciągłe awarie).
Swoją drogą na DevOpsForum 2019 nie zabrakło otwartego mikrofonu – znanego od dawna i moim zdaniem przydatnego formatu wystąpień. Chodzisz tak, słuchasz relacji, a potem decydujesz, że na konferencji warto poruszyć jakiś temat lub problem, dzieląc się odpowiednimi doświadczeniami w rozwiązaniu problemu.
Zauważyłem też, że organizatorzy przygotowali potok krótkich relacji. Każdy raport trwa nie dłużej niż 10 minut, po którym następują pytania. W ten sposób możesz poruszać wiele tematów na raz i zadawać pytania prelegentom, którzy Cię interesują.
Pomiędzy prezentacjami chodziłem po stoiskach partnerów konferencji i ukradłem/wygrałem mnóstwo rzeczy. Och, uwielbiam ulotkę!
Okrągły stół i kwestie DevOps z dyrektorem ds. rozwoju w Alfastrakhovanie
Wisienką na torcie DevOpsForum 2019 była dla mnie godzinna sesja plenarna z ekspertami DevOps. Czterech uczestników sesji zostało zaproszonych do spojrzenia na DevOps z różnych punktów widzenia: Anton Isanin (Alfastrakhovanie, dyrektor ds. rozwoju), Nailya Zamashkina (Fintech Lab, dyrektor operacyjny), Oleg Egorkin (Rostelecom, Agile Coach) i Anton Martyanov (niezależny ekspert, przyjrzał się DevOps z biznesowego punktu widzenia).
Eksperci usiedli bliżej ludzi i wtedy zaczęło się dziać: przez całą godzinę uczestnicy z widowni zadawali pytania, a eksperci przyjmowali rap. Czasami dochodziło do prawdziwych debat. Pytania były bardzo różne, np.: czy inżynierowie DevOps są w ogóle potrzebni, dlaczego nie można ich szkolić na administratorów systemów, czy DevOps powinien być oferowany każdemu, jaka jest jego wartość i tak dalej.
Potem osobiście rozmawiałem z Antonem Isaninem. Omówiliśmy potrzebę wprowadzenia kultury DevOps do każdego domu i ujawniliśmy ciemną stronę transformacji DevOps.
Wyobraźmy sobie, że wszyscy zebrali się razem i zdecydowali, że DevOps jest potrzebny zarówno produktowi, jak i biznesowi i zespołowi. Chodźmy to wdrożyć. Wszystko się udało. Odetchnęliśmy. DevOps zbliżył nas do klienta, teraz możemy szybko spełnić wszystkie jego życzenia. W rezultacie mamy duży dział operacyjny z rygorystycznymi przepisami i wymaganiami, który stale znajduje defekty w produkcie i generuje mnóstwo żądań. Co więcej, wszystkim usterkom przypisywany jest status „pilny”, nawet jeśli Klient niespodziewanie chciał pokolorować przycisk na żółto, a nie na zielono. Projekt rośnie, rośnie liczba wydań, a co za tym idzie, liczba defektów i niezrozumienia nowych funkcjonalności przez klientów. Ops zatrudnia 10 dodatkowych osób, aby nadążać za zgłaszaniem defektów, a dział rozwoju zatrudnia kolejnych 15 osób, aby nadążać za ich zamykaniem. Zamiast wprowadzać nowe funkcje, zespół pracuje z nieskończoną liczbą SD, wyjaśniając użytkownikowi funkcjonalność i jednocześnie udzielając wsparcia. W rezultacie zarówno operacje operacyjne, jak i programistyczne działają, ale klient i firma są niezadowoleni: nowe funkcje utknęły. Okazuje się, że DevOps wydaje się istnieć, ale wydaje się, że nie istnieje.
Odnosząc się do konieczności wdrożenia DevOps, Anton jasno stwierdził, że zależy to bezpośrednio od skali biznesu. Jeśli obsługa jednego klienta rocznie przynosi firmie miliard, DevOps nie jest potrzebny (pod warunkiem, że nie trzeba regularnie wdrażać nowych zmian u tego klienta). Wszystko jest oblane czekoladą. Jeśli jednak firma się rozwinie i pojawi się więcej klientów, musisz się zastosować. Z reguły na początku w firmie nie ma fajnych Opsów. Najpierw kroimy produkt i dopiero wtedy rozumiemy, że aby produkt działał, musimy mieć oko na serwery i monitorować dostawy. Wtedy właśnie powstaje Ops. Należy zrozumieć, że Ops, jako odrębna dywizja, zacznie stawiać szereg barier dla rozwoju i wszystkie dostawy zaczną się zatrzymywać. Oznacza to, że w tym przypadku kultura DevOps jest już aktualna, ale nie możemy zapominać o jej ciemnej stronie.
Źródło: www.habr.com