Infrastruktura jako kod: jak przezwyciężyć problemy przy użyciu XP

Witaj, Habro! Wcześniej narzekałem na życie w Infrastrukturze jako paradygmat kodu i nie oferowałem niczego, co mogłoby rozwiązać obecną sytuację. Dziś wracam, aby opowiedzieć Ci, jakie podejścia i praktyki pomogą Ci uciec z otchłani rozpaczy i skierować sytuację we właściwym kierunku.

W poprzednim artykule „Infrastruktura jako kod: pierwsza znajomość” Podzieliłem się wrażeniami z tego obszaru, próbowałem zastanowić się nad obecną sytuacją w tym obszarze, a nawet zasugerowałem, że pomocne mogą być standardowe praktyki znane wszystkim deweloperom. Mogłoby się wydawać, że było wiele skarg na życie, ale nie było propozycji wyjścia z obecnej sytuacji.

Kim jesteśmy, gdzie jesteśmy i jakie mamy problemy

Obecnie jesteśmy w Zespole Sre Onboarding Team, który składa się z sześciu programistów i trzech inżynierów infrastruktury. Wszyscy próbujemy napisać infrastrukturę jako kod (IaC). Robimy to, ponieważ zasadniczo wiemy, jak pisać kod i mamy historię bycia „ponadprzeciętnymi” programistami.

• Mamy zestaw atutów: pewne wykształcenie, znajomość praktyk, umiejętność pisania kodu, chęć uczenia się nowych rzeczy.
• Jest też część zapadająca się, co jest również minusem: brak wiedzy na temat sprzętu infrastrukturalnego.

Stos technologii, którego używamy w naszym IaC.

• Terraform do tworzenia zasobów.
• Packer do montażu obrazów. Są to obrazy systemu Windows, CentOS 7.
• Jsonnet, aby stworzyć potężną kompilację w drone.io, a także wygenerować plik Json pakujący i nasze moduły terraform.
• Lazur.
• Ansible podczas przygotowywania obrazów.
• Python dla usług pomocniczych i skryptów udostępniania.
• A wszystko to w VSCode z wtyczkami współdzielonymi pomiędzy członkami zespołu.

Wniosek z mojego ostatni artykuł wyglądało to tak: starałem się zaszczepić (przede wszystkim w sobie) optymizm, chciałem powiedzieć, że spróbujemy znanych nam podejść i praktyk, aby stawić czoła trudnościom i zawiłościom, które istnieją w tym obszarze.

Obecnie zmagamy się z następującymi problemami związanymi z IaC:

• Niedoskonałość narzędzi i środków do tworzenia kodu.
• Powolne wdrażanie. Infrastruktura jest częścią prawdziwego świata i może działać powoli.
• Brak podejść i praktyk.
• Jesteśmy nowi i niewiele wiemy.

Na ratunek przychodzi Extreme Programming (XP).

Wszyscy programiści znają Extreme Programming (XP) i praktyki, które za nim stoją. Wielu z nas stosowało to podejście i okazało się ono skuteczne. Dlaczego więc nie skorzystać z określonych tam zasad i praktyk, aby pokonać wyzwania związane z infrastrukturą? Postanowiliśmy przyjąć to podejście i zobaczyć, co się stanie.

Sprawdzenie możliwości zastosowania podejścia XP w Twojej branżyOto opis środowiska, w którym XP dobrze się sprawdza, i jego związek z nami:

1. Dynamicznie zmieniające się wymagania programowe. Było dla nas jasne, jaki jest ostateczny cel. Ale szczegóły mogą się różnić. Sami decydujemy, gdzie musimy taksować, więc wymagania zmieniają się okresowo (głównie sami). Jeśli weźmiemy zespół SRE, który sam zajmuje się automatyzacją i sam ogranicza wymagania i zakres prac, to ten punkt pasuje.

2. Ryzyka wynikające z projektów terminowych wykorzystujących nową technologię. Używając nieznanych nam rzeczy, możemy napotkać ryzyko. I to jest w 100% nasz przypadek. Cały nasz projekt polegał na wykorzystaniu technologii, z którymi nie do końca się znaliśmy. Generalnie jest to problem ciągły, bo... W sektorze infrastruktury cały czas pojawia się wiele nowych technologii.

3,4. Mały, zlokalizowany, rozszerzony zespół programistów. Zautomatyzowana technologia, z której korzystasz, pozwala na przeprowadzanie testów jednostkowych i funkcjonalnych. Te dwa punkty nie do końca nam odpowiadają. Po pierwsze nie jesteśmy zgranym zespołem, a po drugie jest nas dziewięcioro, co można uznać za duży zespół. Chociaż według niektórych definicji „dużego” zespołu dużo to 14+ osób.

Przyjrzyjmy się niektórym praktykom XP i ich wpływowi na szybkość i jakość informacji zwrotnej.

Zasada pętli sprzężenia zwrotnego XP

W moim rozumieniu informacja zwrotna jest odpowiedzią na pytanie, czy postępuję dobrze, czy zmierzamy w tym kierunku? XP ma na to boski plan: pętlę sprzężenia zwrotnego w czasie. Co ciekawe, im niżej jesteśmy, tym szybciej jesteśmy w stanie sprawić, że system operacyjny odpowie na niezbędne pytania.

Jest to dość interesujący temat do dyskusji, że w naszej branży IT można szybko uzyskać system operacyjny. Wyobraź sobie, jak bolesne jest robienie projektu przez sześć miesięcy i dopiero wtedy dowiadujesz się, że na samym początku był błąd. Dzieje się tak podczas projektowania i każdej konstrukcji złożonych systemów.

W naszym przypadku IaC pomaga nam informacja zwrotna. Od razu dokonam małej korekty na powyższym diagramie: plan wydawniczy nie ma cyklu miesięcznego, ale występuje kilka razy dziennie. Istnieje kilka praktyk związanych z tym cyklem systemu operacyjnego, którym przyjrzymy się bardziej szczegółowo.

Ważne: informacja zwrotna może być rozwiązaniem wszystkich problemów wymienionych powyżej. W połączeniu z praktykami XP może wyciągnąć Cię z otchłani rozpaczy.

Jak wyciągnąć się z otchłani rozpaczy: trzy praktyki

Testy

Testy są wspomniane dwukrotnie w pętli sprzężenia zwrotnego XP. To nie tylko tak. Są one niezwykle ważne dla całej techniki Programowania Ekstremalnego.

Zakłada się, że masz testy jednostkowe i akceptacyjne. Niektóre przekazują informację zwrotną w ciągu kilku minut, inne w ciągu kilku dni, więc ich pisanie zajmuje więcej czasu i są sprawdzane rzadziej.

Istnieje klasyczna piramida testowania, która pokazuje, że testów powinno być więcej.

W jaki sposób te ramy odnoszą się do nas w projekcie IaC? Właściwie... wcale.

• Testów jednostkowych, mimo że powinno być ich dużo, nie może być za dużo. Albo testują coś bardzo pośrednio. Właściwie można powiedzieć, że w ogóle ich nie piszemy. Ale oto kilka zastosowań takich testów, które udało nam się wykonać:
  1. Testowanie kodu jsonnet. To na przykład nasz rurociąg do montażu dronów, który jest dość skomplikowany. Kod jsonnet jest dobrze objęty testami.
     Używamy tego Framework do testów jednostkowych dla Jsonnet.
  2. Testuje skrypty, które są wykonywane podczas uruchamiania zasobu. Skrypty pisze się w Pythonie, dlatego można na nich pisać testy.
• Potencjalnie istnieje możliwość sprawdzenia konfiguracji w testach, jednak tego nie robimy. Możliwe jest także skonfigurowanie sprawdzania reguł konfiguracji zasobów poprzez flint. Jednak tamtejsze kontrole są po prostu zbyt proste dla terraforma, ale wiele skryptów testowych napisano dla AWS. Jesteśmy na platformie Azure, więc to znowu nie ma zastosowania.
• Testy integracji komponentów: zależy to od tego, jak je sklasyfikowasz i gdzie je umieścisz. Ale w zasadzie działają.

  Tak wyglądają testy integracyjne.

  
  
  To jest przykład budowania obrazów w Drone CI. Aby do nich dotrzeć, musisz poczekać 30 minut, aż uformuje się obraz Packera, a następnie poczekać kolejne 15 minut, aż przejdą. Ale oni istnieją!

  Algorytm weryfikacji obrazu

  1. Packer musi najpierw całkowicie przygotować obraz.
  2. Obok testu znajduje się terraform ze stanem lokalnym, którego używamy do wdrożenia tego obrazu.
  3. Podczas rozkładania wykorzystuje się leżący obok niewielki moduł ułatwiający pracę z obrazem.
  4. Po wdrożeniu maszyny wirtualnej z obrazu można rozpocząć sprawdzanie. Zasadniczo kontrole przeprowadzane są samochodem. Sprawdza, jak skrypty działały przy uruchomieniu i jak działają demony. W tym celu poprzez ssh lub winrm logujemy się do nowo podniesionej maszyny i sprawdzamy status konfiguracji lub czy usługi działają.

• Podobnie sytuacja wygląda w przypadku testów integracyjnych w modułach dla terraforma. Oto krótka tabela wyjaśniająca cechy takich testów.

  
  
  Informacje zwrotne na temat rurociągu trwają około 40 minut. Wszystko dzieje się bardzo długo. Można go zastosować do regresji, ale w przypadku nowego rozwoju jest generalnie nierealny. Jeżeli jesteś na to bardzo, bardzo przygotowany, przygotuj działające skrypty, wtedy możesz skrócić ten czas do 10 minut. Ale to wciąż nie są testy jednostkowe, które wykonują 5 elementów w 100 sekund.

Brak testów jednostkowych podczas składania obrazów lub modułów terraform zachęca do przeniesienia pracy do oddzielnych usług, które można po prostu uruchomić poprzez REST, lub do skryptów Pythona.

Na przykład musieliśmy się upewnić, że maszyna wirtualna po uruchomieniu zarejestruje się w serwisie SkalaFT, a kiedy maszyna wirtualna została zniszczona, sama się usunęła.

Ponieważ mamy ScaleFT jako usługę, jesteśmy zmuszeni pracować z nią poprzez API. Było tam napisane opakowanie, które można było wyciągnąć i powiedzieć: „Wejdź i usuń to i tamto”. Przechowuje wszystkie niezbędne ustawienia i dostępy.

Możemy już napisać do tego normalne testy, ponieważ nie różni się to od zwykłego oprogramowania: wyśmiewa się jakiś rodzaj apiha, wyciągasz go i widzisz, co się stanie.

Wyniki testów: Testy jednostkowe, które za minutę powinny dać system operacyjny, nie dają tego. A rodzaje testów znajdujących się wyżej w piramidzie są skuteczne, ale obejmują tylko część problemów.

Programowanie par

Testy są oczywiście dobre. Można ich pisać wiele, mogą być różnego typu. Będą pracować na swoim poziomie i przekażą nam informacje zwrotne. Jednak problem złych testów jednostkowych, które dają najszybszy system operacyjny, pozostaje. Jednocześnie nadal chcę szybkiego systemu operacyjnego, z którym praca będzie łatwa i przyjemna. Nie mówiąc już o jakości powstałego rozwiązania. Na szczęście istnieją techniki, które mogą zapewnić jeszcze szybszą informację zwrotną niż testy jednostkowe. To jest programowanie w parach.

Pisząc kod, chcesz jak najszybciej uzyskać informację zwrotną na temat jego jakości. Tak, możesz napisać wszystko w gałęzi funkcji (aby nikomu niczego nie zepsuć), wysłać żądanie ściągnięcia w Githubie, przypisać je osobie, której opinia ma znaczenie i poczekać na odpowiedź.

Ale możesz poczekać długo. Wszyscy są zajęci, a odpowiedź, nawet jeśli taka istnieje, może nie być najwyższej jakości. Załóżmy, że odpowiedź przyszła natychmiast, recenzent od razu zrozumiał całą ideę, ale odpowiedź i tak przychodzi z opóźnieniem, po fakcie. Chciałbym, żeby było to wcześniej. Właśnie temu ma służyć programowanie w parach – już w momencie pisania tego tekstu.

Poniżej znajdują się style programowania w parach i ich zastosowanie w pracy nad IaC:

1. Klasyczny, Doświadczony + Doświadczony, przesunięcie według timera. Dwie role – kierowca i nawigator. Dwoje ludzi. Pracują na tym samym kodzie i zmieniają role po określonym z góry czasie.

Rozważmy zgodność naszych problemów ze stylem:

• Problem: niedoskonałość narzędzi i narzędzi do tworzenia kodu.
  Negatywny wpływ: rozwój trwa dłużej, zwalniamy, zatraca się tempo/rytm pracy.
  Jak walczymy: używamy innego narzędzia, wspólnego IDE, a także uczymy się skrótów.
• Problem: Powolne wdrażanie.
  Negatywny wpływ: zwiększa czas potrzebny na utworzenie działającego fragmentu kodu. Nudzimy się czekając, nasze ręce wyciągają się, żeby zająć się czymś innym.
  Jak walczymy: nie pokonaliśmy tego.
• Problem: brak podejść i praktyk.
  Negatywny wpływ: nie ma wiedzy, jak to zrobić dobrze, a jak źle. Wydłuża czas otrzymania informacji zwrotnej.
  Jak walczymy: wzajemna wymiana poglądów i praktyk w pracy w parach niemal rozwiązuje problem.

Głównym problemem stosowania tego stylu w IaC jest nierównomierne tempo pracy. W tradycyjnym tworzeniu oprogramowania ruch jest bardzo jednolity. Możesz spędzić pięć minut i napisać N. Poświęć 10 minut i napisz 2N, 15 minut - 3N. Tutaj możesz spędzić pięć minut i napisać N, a następnie spędzić kolejne 30 minut i napisać jedną dziesiątą N. Tutaj nic nie wiesz, utknąłeś, głupi. Badanie zajmuje czas i odwraca uwagę od samego programowania.

Wniosek: w czystej postaci nie jest dla nas odpowiedni.

2. Ping-pong. Podejście to polega na tym, że jedna osoba pisze test, a druga zajmuje się jego implementacją. Biorąc pod uwagę fakt, że w przypadku testów jednostkowych wszystko jest skomplikowane i trzeba napisać test integracyjny, którego zaprogramowanie zajmuje dużo czasu, cała łatwość ping-ponga odchodzi w niepamięć.

Mogę powiedzieć, że próbowaliśmy oddzielić odpowiedzialność za zaprojektowanie skryptu testowego i zaimplementowanie dla niego kodu. Scenariusz wymyślił jeden z uczestników, w tej części pracy to on był odpowiedzialny i to on miał ostatnie słowo. A drugi był odpowiedzialny za wdrożenie. To zadziałało dobrze. Jakość skryptu przy takim podejściu wzrasta.

Wniosek: niestety tempo pracy nie pozwala na wykorzystanie ping-ponga jako praktyki programowania w parach w IaC.

3. Mocny styl. Trudna praktyka. Pomysł jest taki, że jeden uczestnik zostaje nawigatorem dyrektyw, a drugi pełni rolę sterownika wykonawczego. W takim przypadku prawo do podejmowania decyzji należy wyłącznie do nawigatora. Sterownik tylko drukuje i może wpływać na to, co dzieje się za pomocą słowa. Role nie zmieniają się przez długi czas.

Dobry do nauki, ale wymaga silnych umiejętności miękkich. W tym miejscu zawiedliśmy. Technika była trudna. I tu nawet nie chodzi o infrastrukturę.

Wniosek: potencjalnie można to wykorzystać, nie rezygnujemy z prób.

4. Mobbing, rój i wszystkie znane, ale nie wymienione style Nie bierzemy tego pod uwagę, ponieważ Nie próbowaliśmy tego i nie da się o tym mówić w kontekście naszej pracy.

Ogólne wyniki korzystania z programowania w parach:

• Mamy nierówne tempo pracy, co jest mylące.
• Natrafiliśmy na niewystarczająco dobre umiejętności miękkie. A tematyka nie pomaga przezwyciężyć tych naszych niedociągnięć.
• Długie testy i problemy z narzędziami utrudniają rozwój w parach.

5. Mimo to były sukcesy. Opracowaliśmy własną metodę „Zbieżność – Rozbieżność”. Opiszę pokrótce jak to działa.

Mamy stałych partnerów na kilka dni (niecały tydzień). Wspólnie wykonujemy jedno zadanie. Siedzimy razem przez chwilę: jeden pisze, drugi siedzi i obserwuje zespół wsparcia. Potem rozpraszamy się na jakiś czas, każdy zajmuje się niezależnymi rzeczami, potem znów się spotykamy, bardzo szybko synchronizujemy, robimy coś razem i znowu się rozpraszamy.

Planowanie i komunikacja

Ostatnim blokiem praktyk rozwiązujących problemy z systemem operacyjnym jest organizacja pracy z samymi zadaniami. Obejmuje to również wymianę doświadczeń poza pracą w parach. Przyjrzyjmy się trzem praktykom:

1. Cele poprzez drzewo celów. Zorganizowaliśmy całościowe zarządzanie projektem poprzez drzewo, które sięga nieskończenie w przyszłość. Technicznie rzecz biorąc, śledzenie odbywa się w Miro. Zadanie jest jedno – jest to cel pośredni. Z tego wychodzą albo mniejsze cele, albo grupy zadań. Same zadania pochodzą od nich. Wszystkie zadania są tworzone i utrzymywane na tej tablicy.

Ten schemat zapewnia również informację zwrotną, która pojawia się raz dziennie, gdy synchronizujemy się na wiecach. Posiadanie wspólnego planu przed wszystkimi, ale ustrukturyzowanego i całkowicie otwartego, pozwala każdemu być świadomym tego, co się dzieje i jak daleko posunęliśmy się.

Zalety wizualnej wizji zadań:

• Przyczynowość. Każde zadanie prowadzi do jakiegoś globalnego celu. Zadania pogrupowane są w mniejsze cele. Sama domena infrastruktury jest dość techniczna. Nie zawsze jest od razu jasne, jaki konkretny wpływ na firmę ma na przykład napisanie runbooka dotyczącego migracji na inny nginx. Posiadanie docelowej karty w pobliżu sprawia, że ​​jest to wyraźniejsze.
  
  Przyczynowość jest ważną właściwością problemów. Odpowiada bezpośrednio na pytanie: „Czy postępuję właściwie?”
• Równoległość. Jest nas dziewięciu i po prostu fizycznie niemożliwe jest rzucenie wszystkich do jednego zadania. Zadania z jednego obszaru też nie zawsze będą wystarczające. Jesteśmy zmuszeni pracować równolegle pomiędzy małymi grupami roboczymi. Jednocześnie grupy przez jakiś czas siedzą nad swoim zadaniem, może je wzmocnić ktoś inny. Czasami ludzie odchodzą od tej grupy roboczej. Ktoś jedzie na urlop, ktoś zgłasza raport na konferencję DevOps, ktoś pisze artykuł na temat Habr. Bardzo ważna staje się wiedza o tym, jakie cele i zadania można realizować równolegle.

2. Zastępczy prowadzący porannych spotkań. Na stand-upach mamy ten problem – ludzie wykonują wiele zadań równolegle. Czasami zadania są luźno ze sobą powiązane i nie wiadomo, kto co robi. A opinia innego członka zespołu jest bardzo ważna. Jest to dodatkowa informacja, która może zmienić przebieg rozwiązania problemu. Oczywiście zazwyczaj ktoś jest przy Tobie, ale rady i wskazówki zawsze się przydadzą.

Aby poprawić tę sytuację, zastosowaliśmy technikę „Zmiana wiodącego stand-upu”. Teraz są one obracane według określonej listy i to ma swój efekt. Kiedy nadejdzie Twoja kolej, musisz zagłębić się w szczegóły i zrozumieć, co się dzieje, aby poprowadzić dobre spotkanie Scrumowe.

3. Demo wewnętrzne. Pomoc w rozwiązaniu problemu z programowania w parach, wizualizacja drzewa problemów i pomoc na porannych spotkaniach scrumowych są dobre, ale nie idealne. Jako para ogranicza Was jedynie wiedza. Drzewo zadań pomaga globalnie zrozumieć, kto co robi. A prezenter i współpracownicy na porannym spotkaniu nie będą zagłębiać się w twoje problemy. Z pewnością może im czegoś zabraknąć.

Rozwiązaniem było wzajemne pokazanie wykonanej pracy i następnie jej omówienie. Spotykamy się raz w tygodniu na godzinę i przedstawiamy szczegóły rozwiązań zadań, które wykonaliśmy w ciągu ostatniego tygodnia.

Podczas demonstracji konieczne jest ujawnienie szczegółów zadania i koniecznie zademonstrowanie jego działania.

Raport można przeprowadzić za pomocą listy kontrolnej.1. Wejdź w kontekst. Skąd się wzięło to zadanie, dlaczego było w ogóle konieczne?

2. Jak wcześniej rozwiązywano problem? Na przykład wymagane było masowe klikanie myszą lub w ogóle nie można było nic zrobić.

3. Jak to udoskonalamy. Na przykład: „Spójrz, teraz jest scriptosik, tutaj jest plik Readme.”

4. Pokaż jak to działa. Wskazane jest bezpośrednie wdrożenie jakiegoś scenariusza użytkownika. Chcę X, robię Y, widzę Y (lub Z). Na przykład wdrażam NGINX, palę adres URL i otrzymuję 200 OK. Jeśli akcja jest długa, przygotuj ją wcześniej, aby móc ją później pokazać. Wskazane jest, aby nie łamać go zbyt mocno na godzinę przed demonstracją, jeśli jest delikatny.

5. Wyjaśnij, jak pomyślnie rozwiązano problem, jakie trudności pozostały, co nie zostało ukończone, jakie ulepszenia są możliwe w przyszłości. Przykładowo teraz CLI, potem będzie pełna automatyzacja w CI.

Zaleca się, aby każdy mówca utrzymywał ten czas na poziomie 5–10 minut. Jeśli Twoje przemówienie jest oczywiście ważne i zajmie więcej czasu, skoordynuj to wcześniej na kanale sre-takeover.

Po części bezpośredniej zawsze następuje dyskusja w wątku. To tutaj pojawia się informacja zwrotna, której potrzebujemy na temat naszych zadań.

W rezultacie przeprowadzana jest ankieta, która ma określić przydatność tego, co się dzieje. Jest to informacja zwrotna na temat istoty wypowiedzi i wagi zadania.

Długie wnioski i co dalej

Może się wydawać, że ton artykułu jest nieco pesymistyczny. To jest źle. Działają dwa niższe poziomy informacji zwrotnej, a mianowicie testy i programowanie w parach. Nie tak doskonały jak w przypadku tradycyjnego rozwoju, ale jest z tego pozytywny efekt.

Testy w swojej obecnej formie zapewniają jedynie częściowe pokrycie kodu. Wiele funkcji konfiguracyjnych pozostaje nieprzetestowanych. Ich wpływ na faktyczną pracę podczas pisania kodu jest niewielki. Testy integracyjne mają jednak wpływ i pozwalają bez obaw przeprowadzać refaktoryzacje. To wielkie osiągnięcie. Ponadto wraz z przeniesieniem uwagi na rozwój w językach wysokiego poziomu (mamy Pythona, go) problem znika. I nie potrzebujesz wielu kontroli „kleju”, wystarczy ogólna kontrola integracji.

Praca w parach zależy bardziej od konkretnych osób. Jest czynnik zadaniowy i nasze umiejętności miękkie. U niektórych osób sprawdza się to bardzo dobrze, u innych gorzej. Z pewnością są z tego korzyści. Wiadomo, że nawet jeśli zasady pracy w parach nie są dostatecznie przestrzegane, już sam fakt wspólnego wykonywania zadań pozytywnie wpływa na jakość rezultatu. Osobiście uważam, że praca w parach jest łatwiejsza i przyjemniejsza.

Wyższy poziom oddziaływania na system operacyjny – planowanie i praca z zadaniami precyzyjnie dają efekty: wysokiej jakości wymianę wiedzy i lepszą jakość rozwoju.

Krótkie wnioski w jednym wierszu

• Praktycy HR pracują w IaC, ale z mniejszą wydajnością.
• Wzmacniaj to, co działa.
• Wymyśl własne mechanizmy i praktyki kompensacyjne.

Źródło: www.habr.com