Niedawno uczestniczyłem w DevOpsForum 2019, które organizował Logrocon. Na tej konferencji uczestnicy starali się znaleźć rozwiązania i nowe narzędzia do efektywnej współpracy między biznesem a specjalistami z zakresu rozwoju oraz wsparcia IT.
Konferencja była udana: było naprawdę wiele przydatnych prezentacji, interesujące formaty wystąpień i mnóstwo rozmów z prelegentami. Co ważne, nikt nie próbował mi nic sprzedać, co jest powszechne na dużych konferencjach w ostatnim czasie.
Podsumowanie wystąpień Raiffeisen Bank, AlfaStrachowania, doświadczenia Mango Telecom w zakresie wprowadzania automatyzacji oraz inne szczegóły znajdziesz poniżej.
Nazywam się Jana, pracuję jako tester, zajmuję się automatyzacją, a także DevOps i uwielbiam uczestniczyć w konferencjach i meetupach. W ciągu ostatnich dwóch lat byłam na konferencjach Olega Bunina (HighLoad++, TeamLead Conf), na wydarzeniach Jug (Heisenbug, JPoint), na TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Najpierw zwracam uwagę na program konferencji. Mniej interesuje mnie temat wykładu, bardziej prelegent. Nawet jeśli wykład będzie bardzo technologiczny i interesujący, nie ma gwarancji, że uda się zastosować jakieś praktyki w mojej firmie. Dlatego ważny jest prelegent.
Światło na końcu pipeline w Raiffeisen Bank
Zwykle poluję na interesujących mnie prelegentów w kuluarach. Na DevOpsForum 2019 w moim kręgu zainteresowań znalazł się prezentujący z Raiffeisen Bank - Michaił Bizhan. Podczas wystąpienia opowiadał o tym, jak stopniowo wprowadzają swoje zespoły w DevOps, dlaczego to potrzebne i jak sprzedać pomysł transformacji DevOps biznesowi. Ogólnie mówił o tym, jak dostrzec światło na końcu pipeline.
Michaił Bizhan, dyrektor ds. automatyzacji w Raiffeisen Bank
Obecnie w ich firmie nie ma "prawdziwego DevOps". To znaczy, że jest on rzeczywisty, ale nie w wszystkich zespołach. Przy wdrażaniu DevOps opierają się na gotowości zespołów zarówno z perspektywy konkretnych inżynierów, jak i potrzeb produktu oraz dojrzałości platformy, na której ten produkt jest zbudowany. Misza opowiedział, jak wyjaśnić biznesowi, dlaczego DevOps jest potrzebny.
Sektor bankowy ma kilka czynników wzrostu: koszt usług oraz rozszerzenie bazy klientów. Zwiększenie kosztów usług nie jest zbyt skutecznym czynnikiem, natomiast wzrost bazy klientów wręcz przeciwnie. Kiedy konkurenci wypuszczają obiektywnie dobry produkt, wszyscy klienci przechodzą do nich, a potem z czasem rynek się stabilizuje. Dlatego wprowadzanie nowych produktów na rynek i szybkość ich wprowadzenia to kluczowe kwestie, na które koncentrują się banki. Właśnie dla tego potrzebny jest DevOps, co biznes doskonale rozumie.
Kolejna ważna uwaga: DevOps nie zawsze skraca czas wprowadzenia na rynek. DevOps nie może działać samodzielnie, to tylko część procesu tworzenia i wprowadzania produktu na rynek od etapu rozwoju do produkcji (od kodu do klienta). Wszystko, co dzieje się przed napisaniem kodu, nie ma bezpośredniego związku z DevOps. To znaczy, że marketingowcy mogą przez lata analizować rynek i całe życie doganiać konkurentów. Niezbędne jest szybkie zrozumienie potrzeb klienta i planowanie realizacji danej funkcji — często tego właśnie brakuje, aby DevOps działał poprawnie i firma osiągała swoje cele. Dlatego, w pierwszej kolejności, w Raiffeisen Bank ustalono z biznesem, że należy nauczyć się wykorzystywać DevOps. Automatyzacja dla samej automatyzacji niewiele pomoże w walce o nowych klientów.
Ogólnie rzecz biorąc, Misha uważa, że DevOps należy wdrażać, ale z rozwagą. I trzeba być gotowym na to, że na początku transformacji wydajność zespołu spadnie, będą zarabiać mniej pieniędzy, ale na dłuższą metę się to opłaci.
Automatyzacja testowania w "Mango Telecom".
Jeszcze jeden interesujący wykład dla mnie jako testera wygłosił Egor Masłow z «Mango Telecom». Prezentacja nosiła tytuł „Automatyzacja pełnego cyklu testowania w zespole SCRUM”. Egor uważa, że DevOps został stworzony właśnie dla SCRUM, ale jednocześnie wdrożenie DevOps w zespole SCRUM jest dość problematyczne. Wynika to z tego, że zespół SCRUM cały czas się gdzieś spieszy, a nie ma czasu na nowe innowacje i przebudowę procesu. Problem polega także na tym, że SCRUM nie przewiduje wydzielania sub-zespołów w zespole (zespół testerów, zespół programistów itp.). Poza tym, aby automatyzować istniejący proces, potrzebna jest dokumentacja, a w SCRUM często dokumentacja jest całkowicie nieobecna — „produkt jest ważniejszy niż jakaś pisma”.
Po przejściu na SCRUM, testerzy zaczęli konsultować się z programistami, jak testować funkcje. Stopniowo rośnie objętość funkcjonalności, brakowało dokumentacji, a oni zaczęli łapać wiele błędów w funkcjonalności, która nie była pokryta testami i w ogóle nie było jasne, kto i kiedy ją testował. Krótko mówiąc — chaos i zamieszanie. Zdecydowali się na automatyzację testowania. Ale wtedy również wydarzył się całkowity fail. Zaangażowali specjalistów zewnętrznych do automatyzacji, którzy pisali w nieznanym dla etatowych testerów stosie technologicznym. Ramy dla autotestów oczywiście działały, ale po tym, jak zewnętrzni pracownicy odeszli, przetrwały tylko dwa tygodnie. Następnie była próba wprowadzenia autotestowania numer dwa. Rozpoczęło się to od tego, że wszystko należy budować wewnątrz firmy, własnymi siłami (właściwy kierunek: rozwijajcie wiedzę wewnętrzną), w ramach SCRUM, i w procesie tworzyć dokumentację. Stos do automatyzacji powinien być równy stosowi produktu (tu zdecydowanie się zgadzam, nie testujcie projektu w JavaScript czymś innym). Na koniec sprintu organizowali demo tego, jak działa autotest, z udziałem całego zespołu (przydatne). W ten sposób rosła zaangażowanie wszystkich członków zespołu w proces automatyzacji, a także zaufanie do autotestów i szansa na to, że ten autotest z pewnością będzie wykorzystywany (a nie zostanie zakomentowany po miesiącu z powodu ciągłych porażek).
Tak przy okazji na DevOpsForum 2019 działał otwarty mikrofon — od dawna znany i moim zdaniem przydatny format wystąpień. Chodzisz tak, słuchasz referatów, a potem decydujesz, że warto omówić jakiś temat lub problem w ramach konferencji, podzielić się odpowiednim doświadczeniem w rozwiązaniu zadania.
Zauważyłam jeszcze, że organizatorzy wprowadzili sesję krótkich wystąpień. Każde wystąpienie trwa nie dłużej niż 10 minut, potem są pytania. W ten sposób można od razu poruszyć wiele tematów i zadawać pytania prelegentom, którzy nas zainteresowali.
Między wystąpieniami spacerowałam po stoiskach partnerów konferencji i zdobyłam/wygrałam wiele różnych drobiazgów. Ech, uwielbiam gadżety!
Okrągły stół i pytania DevOps z dyrektorem ds. rozwoju w Alfabank.
Wisienką na torcie DevOpsForum 2019 dla mnie była godzinna sesja plenarna z ekspertami DevOps. Zaproszono czterech uczestników sesji, którzy mieli przyjrzeć się DevOps z różnych perspektyw: Anton Isanin (Alfabank, dyrektor ds. rozwoju), Nailia Zamashkina (FinTech Lab, dyrektor operacyjny), Oleg Egorkin (Rostelecom, Agile coach) oraz Anton Martyanov (niezależny ekspert, patrzył na DevOps z punktu widzenia biznesu).
Eksperci usiedli bliżej ludzi i zaczęło się: przez cały godzinę uczestnicy z sali zadawali swoje pytania, a eksperci odpowiadali. Czasami wywiązywały się prawdziwe debaty. Pytania były najrozmaitsze, na przykład: czy w ogóle potrzebni są inżynierowie DevOps, dlaczego nie można ich wyhodować z administratorów systemów, czy wszystkim należy proponować DevOps, jaka jest jego wartość i tak dalej.
Potem osobiście rozmawiałam z Antonem Isaninem. Omówiliśmy potrzebę wprowadzenia kultury DevOps do każdego domu i odkryliśmy mroczną stronę transformacji DevOps.
Wyobraźmy sobie, że wszyscy się zebrali i uznali, że DevOps jest potrzebny zarówno produktowi, jak i biznesowi oraz zespołowi. Zaczęli wprowadzać zmiany. Wszystko poszło gładko. Odetchnęli. DevOps przybliżył nas do klienta, teraz będziemy szybko realizować wszystkie jego życzenia. W rezultacie mamy dużą jednostkę Ops z rygorystycznymi regulaminami i wymaganiami, która wciąż produkuje defekty w produkcie, generując mnóstwo zgłoszeń. Co więcej, wszystkie defekty są oznaczone jako „pilne”, nawet gdy klient nagle postanawia pomalować przycisk na żółto zamiast zielonego. Projekt rośnie, liczba wydań i odpowiednio liczba defektów oraz niezrozumienia nowej funkcjonalności przez klientów wzrasta. Ops zatrudnia dodatkowe 10 osób, aby zdążyć zgłaszać defekty, a dział rozwoju zatrudnia kolejnych 15, aby zdążyć je zamykać. Zamiast wprowadzać nowe funkcje, zespół zajmuje się nieskończonymi zadaniami SD, tłumacząc użytkownikom funkcjonalność, a przy okazji również wsparciu. W efekcie zarówno Ops, jak i dział rozwoju są zajęte, ale klient i biznes są niezadowoleni: nowe funkcje utknęły. Wydaje się, że DevOps jest, a jednocześnie go nie ma.
Anton jednoznacznie stwierdził, że potrzeba wprowadzenia DevOps jest ściśle związana z wielkością biznesu. Jeśli obsługa jednego klienta rocznie przynosi firmie miliard - DevOps nie jest potrzebny (pod warunkiem, że nie ma potrzeby wprowadzania nowych zmian dla tego klienta regularnie). Wszyscy są zadowoleni. Ale jeśli biznes rośnie, pojawia się więcej klientów, wtedy trzeba dostosować się do sytuacji. Zazwyczaj w firmie nie ma jeszcze porządnego Ops. Najpierw tworzymy produkt, a dopiero potem rozumiemy, że aby produkt działał, należy również przyglądać się serwerami, śledzić dostawy. Wówczas powstaje Ops. Pozostaje zrozumieć, że Ops, jako oddzielna jednostka, zacznie stawiać wiele barier dla rozwoju, a wszystkie dostawy zaczną się opóźniać. Oznacza to, że w tym przypadku kultura DevOps jest już aktualna, ale trzeba nie zapominać o jej ciemnej stronie.
Źródło: habr.com
