Wypełnianie luk: znaczenie komunikacji DevOps

Choć metodologia DevOps jest z nami już od dłuższego czasu, nadal jest centrum gorących dyskusji. Firmy tego chcą, ale nie są pewne, jak do tego podejść.

DevOps jest wszędzie. I choć to ciekawy trend, powinien być dopasowany do produktów, a nie odwrotnie.

Ale niektórzy ludzie nie widzą tego w ten sposób. Często zadają mi pytania typu: „Czy uważasz, że powinniśmy zacząć używać Dockera, czy od razu przejść do Kubernetes?” Takie pytania są bez znaczenia, nawet nie wiedząc, o co chodzi w produkcie.

Wszystkie te wymyślne terminy — chmura, Kubernetes, kontenery, zarządzanie konfiguracją, infrastruktura jako kod — obiecują pewne ulepszenia. Ale są dla DevOps, tak jak teleskopy dla astronomii. Mogą być przydatne, ale nie są konieczne.

Zasadniczo DevOps ma na celu wypełnienie luki między tym, co zamówił klient, a tym, co dostarczył zespół programistów. Nacisk kładziony jest na krótkie cykle wydawnicze, iteracyjne podejście do projektowania i automatyzację powtarzalnych kroków. Jak myślisz, co jest najważniejsze, aby je urzeczywistnić?

Jeśli powiedziałeś „świetna komunikacja”, masz rację. Wszystkie narzędzia są w porządku. Ale są warte zainwestowanych w nie pieniędzy tylko wtedy, gdy poprawiają komunikację.

Jednym z aspektów komunikacji jest wiedza o tym, co jest konieczne do wykonania pracy. A praca nie oznacza, że ​​„kod jest przesyłany do repozytorium”. Pomyśl o tym raczej jako „klient zobaczył zmianę w produkcji i zaakceptował ją”.

Jak tylko ten pierwszy krok zostanie określony i wszyscy wiedzą, co musi się wydarzyć, jest to najlepszy czas, aby go zapisać. Gdzie? Cóż, jestem wielkim zwolennikiem utrzymania pliku README.md . Każda osoba w zespole może zawsze zajrzeć do środka i poznać stan projektu, a dla nowicjuszy jest to naturalny kierunek.

Automatyzacja, kolejny krok po napisaniu README, jest opcjonalna. Jest to jednak naturalna konsekwencja dokumentowania tego procesu. I tak, automatyzacja jest tym, co często przychodzi na myśl, gdy myślimy o DevOps.

Chwileczkę… automatyzacja jest opcjonalna, jeśli chodzi o DevOps? Czy DevOps nie jest działem osoby, która wykonuje wdrożenia?

Pod pojęciem „inżynier DevOps” ludzie zwykle rozumieją inżyniera niezawodności oprogramowania, inżyniera platformy lub inżyniera automatyzacji operacji. Są to wszystkie ważne role, które umożliwiają ćwiczenie DevOps, ale użycie zbiorczego terminu „inżynier DevOps” może być nieco niejednoznaczne.

Przyjrzyjmy się więc bliżej samemu DevOps.

Wyjaśnienie DevOps

Najpierw pokażę, czym DevOps nie jest:

1. To nie tylko prefiks tytułu zawodowego
2. To nie jest zespół (ale „Dev” i „Ops”) są)
3. To nie jest technologia
4. Nie oznacza „administratora systemu, który potrafi kodować”
5. Nie oznacza „automatyzacji rzeczy”
6. Nie oznacza to, że „nie ma teraz zespołu operacyjnego”

Wiedząc o tym, jesteś teraz świadomy, że nie możesz po prostu „zatrudnić inżyniera DevOps” lub „stworzyć zespół DevOps” w firmie, aby upewnić się, że jesteś przygotowany na przyszłość. DevOps jest podobny do rozwoju Agile. Czy zatrudniłbyś programistę Agile jako takiego ? Prawdopodobnie nie. Albo rozwijasz produkt w sposób zwinny, albo nie.

Jak zatem można opisać DevOps? To metodologia. A może kultura. Może nawet duch. Wykonywanie produktu zgodnie z zasadami DevOps oznacza, że ​​wszyscy — czy to programista, inżynier operacyjny czy menedżer produktu — mają wspólną wizję, utrzymując ją poprzez komunikację. W mniejszym stopniu oznacza to również, że wszyscy korzystają z tych samych narzędzi. Te narzędzia nie mają na celu pomóc żadnej pojedynczej grupie ludzi. Mają na celu popychanie produktu do przodu.

Pójście z tą koncepcją wymaga poważnej zmiany nastawienia, co jest główną przeszkodą. Dlaczego? To dlatego, że ludzie muszą wyjść ze swojej strefy komfortu i zacząć współpracować z ludźmi, którzy mają różne kompetencje. Deweloperzy nagle muszą nauczyć się, jak działa chmura i zacząć wdrażać własny kod. Pracownicy działu operacyjnego muszą zrezygnować z ręcznych konfiguracji i zacząć kodować. Każdy musi nauczyć się nowych pojęć. Każdy ma nowe obowiązki .

Nie jest to łatwe, ale przy dobrej komunikacji i wspólnym celu jest to całkiem możliwe. Ta komunikacja obejmuje ustanowienie kultury, tworzenie lekkich procesów i utrzymywanie odpowiedniej dokumentacji.

Automatyzacja DevOps to dokumentacja

Prawdopodobnie nigdy nie myślałeś o tym w ten sposób. Jednak większość narzędzi powszechnie kojarzonych z DevOps to narzędzia dokumentacyjne :

• Skrypty kompilacji napisane z myślą o czytelności służą do dokumentowania procesu kompilacji
• Ciągłe potoki integracji dokumentują proces integracji, od budowania pojedynczych elementów do całego produktu
• Potoki ciągłego wdrażania idą dalej, dokumentując, jak wdrożyć produkt, z którego może korzystać Twój klient
• Pliki zarządzania konfiguracją dokumentują proces instalacji i konfiguracji
• Specyfikacje infrastruktury jako kodu dokumentują niezbędną infrastrukturę (w rzeczywistości całkiem formalnie!)
• Kontenery są dostarczane z własnymi Dockerfile , które dokumentują, jak zbudować i skonfigurować daną mikrousługę

Wszystkie te wymyślne koncepcje mają zasadniczo jedną funkcję: pomagają członkom zespołu lepiej komunikować się poprzez dokumentowanie procesów. Procesy te można następnie uruchomić ręcznie lub zautomatyzować. Co ważne, każdy interesariusz projektu jest w stanie ich śledzić.

Dokumentowanie procesów jako kodu ma jedną dużą przewagę nad zwykłymi instrukcjami obsługi. Kod można zweryfikować i zachowuje się predykcyjnie. Biorąc pod uwagę te same dane wejściowe, generuje te same dane wyjściowe.

Dzięki pisemnym instrukcjom będziesz miał tyle interpretacji, ilu jest czytelników. Jeśli napiszesz dokumentację niejednoznaczną lub niejasną, osoba, która ją czyta, uzupełni luki. Chodzi o to, że nie masz kontroli nad tym, co trafia do luk.

Z kodem jest to znacznie prostsze. Bez konkretnych kroków program przestanie działać. Te konkretne kroki są jednym z kluczowych aspektów komunikacji DevOps.

Komunikacja DevOps: jedyny sposób na wypełnienie luki między rozwojem a operacjami

W książce The Phoenix Project jesteśmy świadkami problemów niedawno awansowanego menedżera, którego zadaniem jest wdrożenie dużego projektu. Ponieważ nikt nie wie, co się dzieje, wszyscy walczą z pożarami bez większych postępów. Podtytuł książki wspomina, że ​​jest to opowieść o DevOps. Zgadzam się z tym.

Co jednak ciekawe, w trakcie tej książki nie zostało wprowadzone żadne nowe narzędzie. Czy możesz osiągnąć stan DevOps, poprawiając samą komunikację? Zrobili to bohaterowie książki, więc i dla Ciebie jest nadzieja!

Mimo że podejście protagonistów można uznać za „starą szkołę” (używanie prawdziwych kartek papierowych zamiast właściwego systemu śledzenia błędów), sytuacja zaczyna się zmieniać na lepsze dopiero wtedy, gdy wszystkie zaangażowane strony zaczną ze sobą rozmawiać.

Możesz myśleć, że poprawa współpracy między programowaniem a operacjami jest możliwa tylko poprzez tworzenie lepszych interfejsów między nimi, takich jak umowy dotyczące poziomu usług lub zaległości dotyczące incydentów. Ale jest odwrotnie. Rozbijając interfejsy i wprowadzając empatię i wspólną sprawę, będziesz miał zespół, który pracuje nad wspólnym celem.

Struktura zespołu DevOps: kto jest w zespole?

Idealnie, każdy produkt powinien mieć tylko jeden zespół: zespół produktu.

Byłem kiedyś w zespole deweloperskim, w którym brakowało wspólnego celu z innymi zespołami. Zespół programistów chciał wprowadzić jak najwięcej zmian. Zespół walidacyjny miał za zadanie zapobiegać wprowadzaniu defektów. Mieli różnych menedżerów i byli oceniani indywidualnie.

Wynik? Development and Validation grali w ping-ponga z raportami o defektach. Kiedy Validation znalazł test, który nie przeszedł pomyślnie, programiści byli bardziej zainteresowani znalezieniem błędów w samym kodzie testowym niż próbą stworzenia własnego kodu wolnego od błędów.

Cykl wydawniczy oczywiście rozrósł się, ponieważ konieczne były ogromne koszty ogólne, aby właściwie wypełnić raporty, kontr-raporty i tak dalej. Większość zdawała się nie dostrzegać, że jeśli chodzi o produkt, oba zespoły powinny mieć wspólny cel i współpracować, aby go osiągnąć. Jednak brak odpowiedniej współpracy i silosowa mentalność sprawiły, że bardzo trudno było to zauważyć.

Walka z marnotrawstwem to wspólny wysiłek

Nastawienie na szczupłą produkcję, które zainspirowało The Manifesto for Agile Software Development (który z kolei wprowadził nas w DevOps), dotyczyło walki z marnotrawstwem. Przez odpady rozumiemy wszystko, co nie ma bezpośredniego związku z zamówieniem klienta. Nagromadzone prace w toku to marnotrawstwo. Każdy etap procesu, który nie prowadzi wyraźnie do uwolnienia, jest marnotrawstwem.

Ale odpady można zobaczyć tylko z wysokiego poziomu. W ramach jednego zespołu niektóre procedury mogą wydawać się niezbędne. Jednak z punktu widzenia produktu mogą być bezużyteczne.

Aby dowiedzieć się, które wysiłki są stracone, musisz połączyć siły i rozważyć cykl życia wysyłanego produktu. Musisz także myśleć z perspektywy klienta. Czy ta funkcja jest czymś, czego chciał klient? Jeśli nie, równie dobrze możesz to teraz pominąć. Czy Twoje procesy są proste i szczupłe? Przyjrzyj się dokładniej zwłaszcza tym, którzy przekraczają granice zespołu.

Chcesz mieć pewność, że rozwój produktu będzie tak wydajny, jak to tylko możliwe? Zaproś osobę z zewnątrz, aby zobaczył, jak pracujesz. Osoba, która nie jest częścią Twojego zespołu, będzie mogła zadawać wnikliwe pytania i znajdować nowe obszary do poprawy.

Zasady DevOps: Zachowaj spokój (S)

CALMS to bardzo dokładny opis tego, jak należy praktykować DevOps:

• Kultura
• Automatyzacja
• Lean
• Pomiar
• Udostępnianie

Zauważ, że jest uformowany jak kanapka. Trzy środkowe wartości są bardziej techniczne, podczas gdy zewnętrzne odnoszą się do umiejętności miękkich. Ale podstawą całej kultury jest komunikacja: wymieniamy się naszymi wartościami i przekonaniami z innymi członkami zespołu, dopóki nie osiągniemy konsensusu co do tego, jak powinny się zachowywać.

To samo dotyczy dzielenia się. Dzielenie się czymś podstawowym, takim jak jedzenie, nie wymaga komunikacji. Sam gest może być jednak również postrzegany jako akt komunikacji. „Dbam o ciebie, więc dzielę się z tobą.” Nie chcemy ograniczać zakresu tylko do komunikacji werbalnej.

Dzielenie się pomysłami i narzędziami wymaga jednak komunikacji. Jak powinniśmy się nimi dzielić? Gdzie mamy je umieścić? Czy są przydatne dla każdej osoby w zespole, czy tylko dla mniejszej grupy?

Jeśli skupisz się tylko na bardziej technicznych aspektach — automatyzacji, Lean i pomiarach — tracisz sens DevOps. Co jest takiego dobrego w posiadaniu zautomatyzowanego skryptu wdrażania, którego nikt poza autorem nigdy nie używa? Jeśli scenariusz oszczędzi jej trochę czasu, może być uzasadniony. Ale wyobraź sobie, ile czasu można by zaoszczędzić, gdyby wszyscy udostępnili ten skrypt. To mówi coś o walce z marnotrawstwem!

DevOps przybliża biznes do rozwoju

Niektórzy twierdzą, że DevOps przybliża operacje do rozwoju. To prawda, ale to nie cała prawda. Gdy zrobisz to dobrze, DevOps przybliża każdą jednostkę. Pozwala biznesowi i klientom zobaczyć, co dzieje się w rozwoju, niemal w czasie rzeczywistym.

Ta krótsza pętla informacji zwrotnych jest korzystna dla wszystkich interesariuszy. Praca jest ogólnie bardziej widoczna, a programiści również mogą łatwo zobaczyć, w jaki sposób klienci używają tworzonego kodu. Przy tradycyjnym wdrożeniu możesz poczekać kilka miesięcy, zanim ktoś zauważy błędy lub pominięte wymagania. Dzięki ciągłemu wdrażaniu każdy może reagować na pojawiające się problemy. Deweloperzy, operacje, biznes i klienci mogą siedzieć w jednym pomieszczeniu i modyfikować działającą aplikację zgodnie z aktualnymi potrzebami.

Najpierw narzędzia DevOps? Pomyśl jeszcze raz

Oczywiście, aby było to możliwe, potrzebne są wszystkie narzędzia.

Jednak żadna ilość narzędzi nie może zastąpić dobrej komunikacji i empatii w firmie. Kiedyś zaobserwowałem produkt, w którym proces budowania należał do jednego zespołu, a dostarczony kod należał do innego.

Problemy z systemem kompilacji były powszechne. Deweloperzy nie byli pewni, jak z niego korzystać. Opierał się na standardowych narzędziach, ale zostały one dostosowane do tego stopnia, że ​​każda dokumentacja dostępna w sieci okazywała się bezużyteczna.

Wszyscy chcieli poprawić sytuację, ale nie było porozumienia między dwoma zespołami. Oznaczało to, że obie strony wprowadziły nowe narzędzia bez konsultacji z drugą stroną. To tylko poszerzyło lukę, zamiast ją zamknąć.

Jeśli chcesz rozpocząć transformację DevOps w swojej organizacji, zacznij od poprawy sposobu komunikacji. Nie zakładaj po prostu rozwiązania: najpierw zrób burzę mózgów z otwartym umysłem . Wtedy może się okazać, że np. wsparcie narzędziowe jest niewystarczające dla Twoich potrzeb. Wtedy możesz rozważyć ulepszenie swoich obecnych narzędzi lub wprowadzenie nowych — w przeciwnym razie prawdopodobnie powiększysz pierwotny problem.

Najszybszy sposób na ustanowienie DevOps? Lepsza komunikacja!

We wstępie wspomniałem o pytaniu, które często zadają mi klienci: „Czy powinienem iść z Dockerem, czy powinienem przeskoczyć od razu do Kubernetesa?” Po przeczytaniu tego artykułu możesz zobaczyć, że na takie pytanie najlepiej odpowiedzieć po wykonaniu pewnych prac przygotowawczych — z nastawieniem DevOps.

Jeśli wiesz, że Twój zespół produktowy rozumie korzyści płynące z DevOps dla siebie i dla klienta, zespół i klient mogą zacząć od ustalenia swoich oczekiwań. Następnie inżynierowie mogą opracować model rozwoju i wdrażania. Na koniec możesz określić, które narzędzia są potrzebne.

Po udokumentowaniu wszystkich wymagań wybór technologii jest znacznie łatwiejszy.

Jestem zwolennikiem wszystkich świetnych narzędzi do automatyzacji DevOps, które sprawiają, że nasza praca jest łatwiejsza i łatwiejsza w zarządzaniu. Ale naszą codzienną pracą jest praca z ludźmi . Zainwestujmy trochę czasu w udoskonalenie tego aspektu najlepszych praktyk DevOps, zamiast zdobywania kolejnego certyfikatu technologii.