Definicja DevOps jest bardzo skomplikowana, dlatego za każdym razem trzeba na nowo rozpoczynać dyskusję na ten temat. Tylko na Habrze jest tysiące publikacji na ten temat. Ale jeśli to czytasz, to z pewnością wiesz, czym jest DevOps. Bo ja sam nie wiem. Cześć, nazywam się Aleksandr Titow (@), i po prostu porozmawiamy o DevOps, a ja podzielę się swoim doświadczeniem.
Długo myślałem, jak uczynić moją opowieść użyteczną, dlatego znajdzie się tu wiele pytań - tych, które sam sobie zadaję, oraz tych, które zadaję klientom naszej firmy. Odpowiadając na te pytania, rozumienie staje się lepsze. Opowiem, po co potrzebny jest DevOps z mojego punktu widzenia, co to jest, znów z mojej perspektywy, oraz jak zrozumieć, że zmierzasz w kierunku DevOps znowu z mojego punktu widzenia. Ostatni punkt będzie poprzez pytania. Odpowiadając na nie samemu sobie, będziecie w stanie zrozumieć, czy wasza firma zmierza w kierunku DevOps, czy są jakieś problemy.
Kiedyś przemieszczałem się w falach fuzji i przejęć. Najpierw pracowałem w małym startupie Qik, który później został zakupiony przez trochę większą firmę Skype, a ta została potem przejęta przez jeszcze większą firmę Microsoft. W tym momencie zyskałem wizję, jak postrzeganie DevOps transformuje się w różnych wielkościach firm. Po tym zaciekawiło mnie, jak rynek postrzega DevOps, więc z kolegami zorganizowaliśmy firmę Ekspress 42. Już od 6 lat płyniemy na tym rynku.
Oprócz tego jestem jednym z organizatorów społeczności DevOps Moscow i organizatorem DevOps Days 2017, ale w 2018 roku nie organizowałem. Ekspress 42 współpracuje z wieloma firmami. Rozwijamy tam DevOps, obserwujemy, jak to się odbywa, wyciągamy wnioski, analizujemy, dzielimy się swoimi spostrzeżeniami ze wszystkimi, uczymy ludzi praktyk DevOps. Ogólnie rzecz biorąc, w każdym sensie rozwijamy doświadczenie i ekspertyzę.
Po co DevOps
Pierwsze pytanie, które nurtuje wszystkich zawsze - po co? Wiele osób uważa, że DevOps to po prostu automatyzacja lub coś podobnego, co już było w każdej firmie.
- Mieliśmy Continuous Integration - to znaczy, mieliśmy już DevOps, więc po co to wszystko? Tam za granicą się bawią, a nam przeszkadzają w pracy!
Po 9 latach rozwoju społeczności i metodologii stało się jasne, że to wcale nie są tylko marketingowe błyski, ale nadal nie do końca wiadomo, po co to wszystko. Jak w przypadku każdego narzędzia i procesu, DevOps ma konkretne cele, które ostatecznie realizuje.
Wszystko to związane jest z tym, że świat się zmienia. Odchodzi od podejścia enterprise, gdy firmy dążą od razu do marzenia, jak śpiewał nasz klasyk z Petersburga, z punktu A do punktu B według określonej strategii, zbudowanej do tego celu odpowiedniej struktury.
Tak naprawdę w IT wszystko powinno być zbudowane pod to podejście. Tutaj IT jest wykorzystywane wyłącznie do automatyzacji procesów.
Automatyzacja rzadko się zmienia, ponieważ gdy firma toczy się po utartej ścieżce — co tam zmieniać? Działa — nie dotykaj. Obecnie na świecie podejścia się zmieniają, i to, co nazywa się słowem Agile, mówi o tym, że docelowy punkt B nie jest od razu widoczny.
Gdy firma działa na rynku i współpracuje z klientem — nieustannie bada rynek i zmienia docelowy punkt B. Przy czym im częściej firma zmienia kierunek, tym większą osiąga sukces, ponieważ wybiera więcej nisz rynkowych.
Strategię pokazuje interesująca firma, o której niedawno się dowiedziałem. One Box Shave — to serwis dostarczający maszynki do golenia i akcesoria do golenia w systemie subskrypcyjnym. Potrafią dostosować swoją „pudełko” do różnych klientów. Zajmuje się tym odpowiednie oprogramowanie, które później wysyła zamówienie do koreańskiej fabryki produkującej towar.
Ten produkt został zakupiony przez firmę Unilever za 1 miliard dolarów. Teraz konkuruje z Gillette i zdobył znaczną część konsumentów na amerykańskim rynku. One Box Shave mówi:
— 4 ostrza? Serio? Po co wam to — to wcale nie poprawia jakości golenia. Starannie dobrany krem, zapach i wysokiej jakości maszynka z dwoma ostrzami rozwiązują znacznie więcej problemów niż te głupie 4 ostrza Gillette! Wkrótce dojdziemy do 10?
Tak świat się zmienia. Unilever ogłasza, że mają świetny system IT, który to umożliwia. W efekcie to wygląda jak koncepcja Time-to-market, o której już nie wiadomo, kto tylko nie mówił.
Znaczenie Time-to-market nie polega na tym, jak często wprowadzamy zmiany. Można wprowadzać zmiany często, ale cykle wydania mogą być długie. Jeśli nałożymy na siebie trzy miesiące cyklu wydania, przesuwając je o tydzień, wydaje się, że firma wprowadza zmiany co tydzień. A od pomysłu do ostatecznej realizacji upływa 3 miesiące.
Time-to-market to minimalizacja czasu od pomysłu do ostatecznej realizacji.
W tym przypadku oprogramowanie wchodzi w interakcję z rynkiem. Jak w One Box Shave strona internetowa współdziała z klientem. Nie mają sprzedawców — to tylko strona, na której odwiedzający klikają i zostawiają swoje życzenia. W związku z tym na stronie trzeba cały czas zamieszczać coś nowego, aktualizować ją zgodnie z życzeniami. Na przykład w Korei Południowej golą się inaczej niż w Rosji i wolą, aby zapach nie był sosnowy, a na przykład waniliowo-marchewkowy.
Ponieważ konieczna jest szybka zmiana zawartości strony, rozwój oprogramowania znacznie się zmienia. Dzięki oprogramowaniu musimy dowiedzieć się, co chce klient. Kiedyś odkrywaliśmy to pośrednio, na przykład poprzez zarządzanie biznesem. Następnie projektowaliśmy, definiowaliśmy wymagania w systemie IT, a wszystko było w porządku. Teraz jest inaczej — oprogramowanie projektują wszyscy zaangażowani w proces, w tym inżynierowie, ponieważ dowiadują się przez dane techniczne, jak działa rynek, i dzielą się swoimi spostrzeżeniami z biznesem.
Na przykład w firmie Qik nagle odkryliśmy, że ludziom bardzo podoba się możliwość przesyłania list kontaktów na serwer i przygotowali dla nas aplikację. Początkowo nie braliśmy tego pod uwagę. W klasycznej firmie wszyscy doszliby do wniosku, że to błąd, ponieważ w specyfikacji nie napisano, że to ma działać świetnie i w ogóle zostało zrealizowane naprędce; wyłączyliby funkcję i powiedzieli: „Nikt tego nie potrzebuje, najważniejsze, że podstawowa funkcjonalność działa”. Technologiczna firma widzi w tym możliwość i zaczyna dostosowywać oprogramowanie do tego.
W 1968 roku przenikliwy człowiek Melvin Conway sformułował następującą ideę.
Organizacja, która tworzy system, jest ograniczona przez projekt, który kopiuje strukturę komunikacji w tej organizacji.
Jeśli chodzi o szczegóły, aby wytwarzać systemy innego typu, trzeba dodatkowo posiadać wewnętrzną strukturę komunikacyjną innego rodzaju. Jeśli w twojej firmie istnieje struktura komunikacyjna hierarchiczna, to nie pozwoli ci to tworzyć systemów, które mogą zapewniać bardzo wysoki wskaźnik Time-to-market.
Poczytaj można . Jest to ważne dla zrozumienia kultury lub filozofii DevOps, ponieważ jedyną rzeczą, która zasadniczo zmienia się w DevOps, jest właśnie struktura komunikacji między zespołami..
Z punktu widzenia procesu, przed DevOps wszystkie etapy: analityka, rozwój, testowanie, eksploatacja, przebiegały liniowo.
W przypadku DevOps wszystkie te procesy odbywają się równocześnie.
Time-to-market może być realizowane tylko w ten sposób. Dla osób, które pracowały w starym procesie, wygląda to nieco kosmicznie i ogólnie jakoś tak sobie.
To po co potrzebny jest DevOps?
Do rozwoju produktów cyfrowych.Jeśli w twojej firmie nie ma produktu cyfrowego, DevOps nie jest potrzebny — to bardzo ważne.
DevOps pokonuje ograniczenia prędkości liniowego schematu produkcji oprogramowania.W nim wszystkie procesy zachodzą równocześnie.
Zwiększa się złożoność. Kiedy ewangelizatorzy DevOps opowiadają, że z nim łatwiej będzie wydawać oprogramowanie — to jest bzdura.
Z DevOps wszystko będzie tylko trudniejsze.
Na konferencji na stoisku Avito można było zobaczyć, co to znaczy wdrożyć kontener Docker — to niewykonalne zadanie. Złożoność staje się nieprzyzwoita, trzeba żonglować wieloma piłkami jednocześnie.
DevOps całkowicie zmienia proces i organizację w firmie — dokładniej, to nie DevOps zmienia, lecz produkt cyfrowy. Aby przejść do DevOps, trzeba jednak całkowicie zmienić ten proces. Pytania dla specjalisty
A co z tobą? Pytania, które możesz sobie zadać, pracując w firmie i rozwijając się jako specjalista.
Czy masz strategię tworzenia produktu cyfrowego?
Jeśli tak — to już dobrze. To oznacza, że twoja firma zmierza w kierunku DevOps. Czy twoja firma już tworzy produkt cyfrowy?
To oznacza, że możesz wspiąć się jeszcze wyżej, zajmować się ciekawszymi sprawami — z punktu widzenia DevOps ponownie. Mówię tylko z tego punktu widzenia. Czy twoja firma jest jednym z liderów rynku w niszy z produktem cyfrowym?
Czy Twoja firma jest jednym z liderów rynku w niszy cyfrowych produktów? Spotify, Yandex, Uber - to firmy, które obecnie znajdują się na szczycie postępu technologicznego.
Zadaj sobie te pytania, a jeśli na wszystkie odpowiedzi są negatywne, to być może nie warto zajmować się DevOps w tej firmie. Jeśli jednak temat DevOps naprawdę Cię interesuje, może warto przejść do innej firmy? Jeśli Twoja firma chce przejść do DevOps, ale na wszystkie pytania odpowiedziałeś "Nie", to przypomina to pięknego nosorożca, który nigdy się nie zmieni.
Organizacja
Jak już mówiłem, zgodnie z prawem Conwaya w firmie zmienia się organizacja. Zaczynając od tego, co utrudnia DevOps przeniknięcie do wnętrza firmy, patrząc z perspektywy organizacji.
Problem "silosów"
Angielskie słowo "Silo" przetłumaczone jest tutaj na polski jako "silos". Istota tego problemu polega na tym, że między zespołami nie ma wymiany informacji. Każdy zespół wykopuje swoją ekspertyzę w głąb, nie budując wspólnej mapy, na której można się nawigować.
Przypomina to osobę, która dopiero co przyjechała do Warszawy i jeszcze nie umie orientować się w komunikacji miejskiej. Mieszkańcy zazwyczaj doskonale znają swój rejon, a w całej Warszawie orientują się po mapie komunikacyjnej. Kiedy przyjeżdżasz do Warszawy po raz pierwszy, nie masz jeszcze tej umiejętności i po prostu jesteś zdezorientowany.
DevOps oferuje przejście przez ten moment dezorientacji i wspólne zbudowanie mapy interakcji dla wszystkich działów.
Utrudniają to dwa czynniki.
Konsekwencja korporacyjnego systemu zarządzania. Jest zbudowany na oddzielnych, hierarchicznych "silosach". Na przykład istnieją określone KPI w firmach, które wspierają ten system. Z drugiej strony, przeszkadza umysł człowieka, któremu trudno wyjść poza granice swojej ekspertyzy i orientować się w całym systemie. To po prostu niekomfortowe. Wyobraź sobie, że jesteś na lotnisku w Bangkoku - tam szybko nie da się zorientować. W DevOps też trudno się orientować, dlatego ludzie mówią, że trzeba znaleźć przewodnika, aby się tam dostać.
Ale najważniejsze jest to, że problem "silosów" dla inżyniera, który wczuł się w ducha DevOps, przeczytał książki Fowlersa i wiele innych, wyraża się w tym, że "silosy" nie pozwalają robić "oczywistych" rzeczy. Często spotykamy się po DevOps Warsaw, rozmawiamy ze sobą, a ludzie skarżą się:
— Chcieliśmy po prostu uruchomić CI, a okazało się, że menedżment tego nie potrzebuje.
Dzieje się tak właśnie dlatego, że CI i proces dostarczania ciągłego znajdują się na granicy wielu dziedzin wiedzy. Po prostu nie pokonując problemu «stref cienia» na poziomie organizacyjnym, nie można pójść dalej, cokolwiek byście nie robili i jak smutno by to nie brzmiało.
Każdy uczestnik procesu w firmie: programiści backendu i frontendu, testerzy, DBA, operacje, sieć, kopie w swoją stronę, a nikt nie ma wspólnej mapy, poza menedżerem, który jakoś ich przegląda i zarządza metodą «dziel i rządź».
Ludzie walczą o jakieś gwiazdki lub flagi, każdy kopie swoją ekspertyzę.
W rezultacie, gdy pojawia się zadanie połączenia tego wszystkiego razem i już nie trzeba walczyć o gwiazdki i flagi, pojawia się pytanie — co w ogóle robić? Jakoś trzeba się dogadać, a jak to zrobić, nikt nas w szkole tego nie uczył. Jeszcze ze szkoły nauczyliśmy się: ósma klasa — wow! — w porównaniu do siódmej klasy! Tutaj jest to samo.
Czy w waszej firmie jest podobnie?
Aby to sprawdzić, można zadać sobie następujące pytania.
Czy zespoły korzystają z takich samych narzędzi, czy wkładają wkład w zmiany tych wspólnych narzędzi?
Jak często zespoły są przekształcane — jedni specjaliści z jednej drużyny przechodzą do innej drużyny? W środowisku DevOps to staje się normą, ponieważ czasami człowiek po prostu nie może zrozumieć, czym zajmuje się inna dziedzina ekspertyzy. Przechodzi do innego działu, pracuje tam przez dwa tygodnie, aby stworzyć dla siebie mapę orientacji i interakcji z tym działem.
Czy można utworzyć komitet do zmian i coś zmienić? Czy potrzebna jest do tego silna ręka najwyższego kierownictwa i zarządzenie? Niedawno napisałem na Facebooku, jak jeden mało znany bank wprowadza narzędzia poprzez zarządzenia: napisali zarządzenie, wdrażamy przez rok, patrzymy, co się dzieje. Oczywiście to jest długie i smutne.
Jak ważne jest dla menedżerów uzyskiwanie osobistych osiągnięć bez uwzględnienia osiągnięć firmy?
Jeśli odpowiesz sobie na te pytania, stanie się jasne, czy masz taki problem w swojej firmie.
Infrastruktura jako kod
Gdy już ten problem zostanie rozwiązany, pierwszą ważną praktyką, bez której trudno jest posunąć się dalej w DevOps, jest infrastruktura jako kod.
Najczęściej infrastrukturę jako kod postrzega się w ten sposób:
– Zautomatyzujmy wszystko w bash, pokryjmy się skryptami, aby admini mieli mniej ręcznej pracy!
Ale to nie prawda.
Infrastruktura jako kod oznacza, że IT-system, z którym pracujesz, opisujesz w formie kodu, aby stale rozumieć jego stan.
Wspólnie z innymi zespołami tworzysz mapę w formie kodu, która jest zrozumiała dla wszystkich, według której można się orientować, nawigować. Nie ma znaczenia, na czym to zrobiono – Chef, Ansible, Salt, czy użyto plików YAML w Kubernetes – nie ma różnicy.
Na konferencji kolega z 2GIS opowiadał, jak stworzyli swoje wewnętrzne narzędzie dla Kubernetes, które opisuje strukturę poszczególnych systemów. Aby opisać 500 systemów, potrzebowali oddzielnego narzędzia, które generuje te opisy. Kiedy jest to opisane, każdy może się odniesć do siebie, monitorować zmiany, jak to zmienić i poprawić, czego brakuje.
Przyznajcie, że oddzielne skrypty bash zwykle nie dają tego zrozumienia. W jednej z firm, w której pracowałem, istniało nawet określenie „skrypt write only” – kiedy skrypt jest napisany, a przeczytać go już nie można. Myślę, że to wam także jest znane.
Infrastruktura jako kod to kod, który opisuje aktualny stan infrastruktury. Nad tym kodem wspólnie pracuje wiele zespołów produktowych, infrastrukturalnych i serwisowych, i co najważniejsze, wszyscy muszą rozumieć, jak ten kod w ogóle działa.
Kod jest wspierany zgodnie z najlepszymi praktykami pracy z kodem: wspólne tworzenie, przegląd kodu, programowanie XP, testowanie, pull requesty, CI dla infrastruktury kodu – to wszystko jest wartościowe i można to zastosować.
Kod staje się wspólnym językiem dla wszystkich inżynierów.
Zmiana infrastruktury w kodzie nie zajmuje dużo czasu. Tak, w kodzie infrastrukturalnym także może być dług technologiczny. Zwykle zespoły spotykają się z nim półtora roku po rozpoczęciu wdrażania „infrastruktury jako kod” w formie zestawu skryptów lub nawet Ansible, które piszą jako spaghetti kod, a do tego jeszcze dorzucają skrypty bash do pieca!
Ważne: jeśli jeszcze nie próbowałeś tego badziewia, zapamiętaj, że Ansible — to nie bash! Uważnie czytaj dokumentację, dowiedz się, co na ten temat piszą.
Infrastruktura jako kod — to podział kodu infrastrukturalnego na osobne warstwy.
W naszej firmie wyróżniamy 3 podstawowe warstwy, które są bardzo zrozumiałe i proste, ale może ich być więcej. Możesz spojrzeć na swój kod infrastrukturalny i sprawdzić, czy spełniasz ten warunek. Jeśli żadne warstwy nie są wydzielone, należy znaleźć czas i trochę zrefaktoryzować.
Warstwa podstawowa — to jak konfiguruje się system operacyjny, kopie zapasowe i inne niskopoziomowe rzeczy, na przykład, jak uruchamiany jest Kubernetes na poziomie podstawowym.
Poziom usług — to te usługi, które udostępniasz programiście: logowanie jako usługa, monitoring jako usługa, baza danych jako usługa, load balancer jako usługa, kolejka jako usługa, Continuous Delivery jako usługa — mnóstwo usług, które różne zespoły mogą dostarczać programowaniu. Wszystko to należy opisać w osobnych modułach w Twoim systemie zarządzania konfiguracją.
Warstwa, w której tworzy się aplikacje i opisuje, jak będą się one uruchamiać na dwóch poprzednich warstwach.
Pytania kontrolne
Czy w Twojej firmie istnieje wspólny repozytorium infrastruktury? Czy kontrolujesz dług technologiczny w infrastrukturze? Czy stosujesz praktyki rozwoju w repozytorium infrastruktury? Czy Twoja infrastruktura jest podzielona na warstwy? Można to zweryfikować zgodnie z schematem Base-service-APP. Jak trudno jest wprowadzić zmianę?
Jeśli spotkałeś się z sytuacją, że wprowadzenie zmian zajmowało półtora dnia, oznacza to, że masz do czynienia z długiem technologicznym i trzeba to rozwiązać. Natknąłeś się właśnie na pułapki długu technologicznego w kodzie infrastrukturalnym. Pamiętam wiele takich przypadków, gdy zmiana jakiegoś CCTL wymagała przepisania połowy kodu infrastrukturalnego, ponieważ chęć do automatyzacji i kreatywność doprowadziły do tego, że wszędzie pojawiły się przeszkody, wszystkie ręce zostały usunięte i konieczna jest refaktoryzacja.
Ciągła dostawa
Podsumujmy debet z kredytem. Najpierw pojawia się opis infrastruktury, który może być dość podstawowy. Nie trzeba wszystkiego opisywać szczegółowo, ale jakieś podstawowe omówienie jest wymagane, aby móc z tym pracować. W przeciwnym razie nie jest jasne, na czym można dalej budować ciągłe dostarczanie. Wszystkie te praktyki rozwijają się równocześnie, gdy przechodzicie do DevOps, ale należy zacząć od zrozumienia, co posiadacie i jak tym zarządzać. To jest właśnie praktyka infrastruktury jako kodu.
Po tym, jak stało się jasne, co posiadacie, jak tym zarządzać, zaczynacie myśleć, jak maksymalnie szybko dostarczyć kod dewelopera na produkcję. Mówię tu o współpracy z deweloperem — pamiętamy o problemie "studni", czyli nie jest to coś, co wymyślają oddzielni ludzie, ale zespół.
Kiedy my z Waną Jewtuchowiczem zobaczyliśmy pierwszą książkę Jezza Hembla i grupy autorów „Continuous Delivery”, która ukazała się w 2009 roku, długo zastanawialiśmy się, jak przetłumaczyć jej tytuł na język polski. Chcieliśmy przetłumaczyć jako „Ciągłe dostarczanie”, ale niestety przetłumaczyliśmy jako „Niekontrolowana dostawa”. Wydaje mi się, że w naszej nazwie jest coś takiego polskiego, z impetem.
Ciągłe dostarczanie — to znaczy
Kod znajdujący się w repozytorium produktu zawsze może być dostarczony na produkcję. Może nie być dostarczony, ale zawsze jest na to gotowy. W związku z tym, zawsze piszecie kod z trudnym do wyjaśnienia poczuciem pewnego niepokoju w dolnej części pleców. Pojawia się to uczucie, gdy wdrażacie kod infrastrukturalny. To poczucie pewnego niepokoju powinno być obecne — wywołuje procesy myślowe, które pozwalają pisać kod nieco inaczej. Powinno być to uwzględnione w zasadach wewnątrz rozwoju.
Aby ciągle dostarczać, potrzebny jest format artefaktu, który przechodzi przez platformę infrastrukturalną. Jeśli wrzucacie do platformy infrastrukturalnej różne formaty "odpady życiowe", staje się ona nieuładzona, trudna w utrzymaniu, pojawia się problem długu technicznego. Format artefaktu należy ujednolicić — to też wspólne zadanie: wszyscy muszą się zebrać, pomyśleć wspólnie i wymyślić ten format.
Artefakt jest ciągle doskonalony i dostosowywany do środowiska produkcyjnego w trakcie przechodzenia przez pipeline dostaw. Kiedy artefakt porusza się przez pipeline, non stop spotyka się z różnymi wyzwaniami, które przypominają te, z którymi może się zetknąć artefakt w produkcji. Jeśli w klasycznym procesie rozwijania robi to administrator systemu podczas wdrożenia, to w procesie DevOps dzieje się to nieustannie: tutaj przeszedł przez różne testy, tam został wrzucony do klastra Kubernetes, który jest bardziej lub mniej podobny do produkcji, a tu nagle wystartowano testy obciążeniowe.
To przypomina grę Pac-Man – artefakt przechodzi przez jakąś historię. Ważne jest przy tym kontrolowanie, czy kod faktycznie realizuje tę historię i jest jakoś związany z twoją produkcją. Historie z produkcji można włączyć w proces Continuous Delivery: było tak, że coś się zepsuło, więc zaprogramujmy ten scenariusz w systemie. Za każdym razem kod przejdzie przez ten scenariusz, i nie napotkasz tej samej problemu następnym razem. Dowiesz się o tym znacznie wcześniej, zanim dotrze do klienta.
Różne strategie wdrożeń. Na przykład, używasz testów AB lub wdrożeń kanaryjnych, aby różnie 'testować' kod na różnych klientach, zbierać informacje o tym, jak działa kod, i znacznie wcześniej, zanim zostanie wdrożony dla 100 milionów użytkowników.
„Ciągłe dostarczanie” wygląda tak.
Proces dostarczania Dev, CI, Test, PreProd, Prod – to nie są oddzielne środowiska, to etapy lub stacje z nieodłączonymi kwotami, przez które przemieszczany jest twój artefakt.
Jeśli masz kod infrastrukturalny, który opisany jest jako Base Service APP, to pomaga nie zapomnieć o wszystkich scenariuszach, i zapisać je również w postaci kodu dla tego artefaktu, promować artefakt i zmieniać go w trakcie jego drogi.
Pytania do samosprawdzania
Czas od opisu funkcji do wdrożenia na produkcji w 95% przypadków jest krótszy niż tydzień? Czy jakość artefaktu poprawia się na każdym etapie pipeline? Czy istnieje historia, przez którą przechodzi? Czy używasz różnych strategii wdrożeń?
Jeśli wszystkie odpowiedzi brzmią tak, to jesteś niesamowicie świetny! Napisz odpowiedzi w komentarzach – ucieszy mnie to).
Informacje zwrotne
To najtrudniejsza praktyka ze wszystkich. Na konferencji DevOpsConf kolega z Infobip, opowiadając o niej, nieco plątał się w słowach, ponieważ to naprawdę bardzo skomplikowana praktyka dotycząca monitorowania absolutnie wszystkiego!
Na przykład, dawno temu, kiedy pracowałem w Qik, zrozumieliśmy, że musimy monitorować wszystko. Zrobiliśmy to i w Zabbix mieliśmy 150 000 elementów, które były monitorowane non stop. To było przerażające, dyrektor techniczny kręcił palcem przy skroni:
— Chłopaki, po co tak katujecie serwer niewiadomo czym?
Ale później wydarzyło się coś, co pokazało, że to naprawdę świetna strategia.
Jedna z usług zaczęła regularnie padać. Początkowo nie padała, co ciekawe, do kodu nie wprowadzano żadnych zmian, ponieważ to był podstawowy broker, który praktycznie nie miał funkcjonalności biznesowej — po prostu przesyłał wiadomości pomiędzy poszczególnymi usługami. Usługa nie zmieniała się przez 4 miesiące, a nagle zaczęła padać z błędem „Segmentation fault”.
Byliśmy w szoku, otworzyliśmy nasze wykresy w Zabbix i okazało się, że półtora tygodnia temu znacznie zmieniło się zachowanie zapytań w API serwisie, który korzysta z tego brokera. Potem zauważyliśmy, że zmieniła się częstotliwość wysyłania określonego typu wiadomości. Po chwili dowiedzieliśmy się, że to klienci android. Zapytałem:
— Chłopaki, co się u was wydarzyło półtora tygodnia temu?
W odpowiedzi usłyszeliśmy ciekawą historię o tym, że zmienili UI. Mało kto od razu powie, że zmienił bibliotekę HTTP. Dla klientów android to jak wymiana mydła w łazience — po prostu tego nie pamiętają. W końcu, po 40 minutach rozmowy, dowiedzieliśmy się, że jednak zmienili bibliotekę HTTP, a w niej zmieniły się domyślne czasy. To spowodowało, że zmieniło się zachowanie ruchu na serwerze API, co doprowadziło do sytuacji, która wywołała wyścig wewnątrz brokera i zaczęła on padać.
Bez głębokiego monitoringu to byłoby zupełnie niemożliwe do wykrycia.. Jeśli w organizacji istnieje jeszcze problem "studni", gdzie każdy przerzuca odpowiedzialność na drugiego, to może to trwać latami. Po prostu restartujesz serwer, ponieważ rozwiązanie problemu jest niemożliwe. Kiedy monitorujesz, śledzisz, rejestrujesz wszystkie zdarzenia, które masz, i używasz monitorowania jako testowania — piszesz kod i od razu wskazujesz, jak go monitorować, również w formie kodu (już mamy infrastrukturę jako kod), wszystko staje się jasne jak na dłoni. Nawet tak skomplikowane problemy są łatwe do śledzenia.
Zbieraj wszelkie informacje o tym, co dzieje się z artefaktem na każdym etapie procesu dostarczania — nie w produkcji.
Monitoring wrzuć do CI, a tam już będą widoczne jakieś podstawowe rzeczy. Później będziesz je widzieć zarówno w Test, jak i w PredProd, oraz w testach obciążeniowych. Zbieraj informacje na wszystkich etapach, przy czym nie tylko metryki, statystyki, ale i logi: jak aplikacja została wdrożona, anomalie — zbieraj wszystko.
W przeciwnym razie będzie trudno się połapać. Już mówiłem, że DevOps to większa złożoność. Aby poradzić sobie z tą złożonością, trzeba mieć dobrą analitykę..
Pytania do samooceny.
Czy Twój monitoring i logowanie to narzędzie rozwoju dla Ciebie? Czy Twoi programiści, w tym Ty, kiedy piszą kod, myślą o tym, jak go monitorować?
Czy dowiadujesz się o problemach od klientów? Czy rozumiesz klienta lepiej dzięki monitorowaniu i logowaniu? Czy rozumiesz system lepiej dzięki monitorowaniu i logowaniu? Czy zmieniasz system tylko dlatego, że zauważyłeś, że trend w systemie rośnie i rozumiesz, że jeszcze 3 tygodnie i wszystko upadnie?
Kiedy masz te trzy komponenty, możesz pomyśleć o tym, jaka jest w Twojej firmie platforma infrastrukturalna.
Platforma infrastrukturalna.
Chodzi o to, że to nie jest zestaw rozproszonych narzędzi, które ma każda firma.
Sens platformy infrastrukturalnej polega na tym, że wszystkie zespoły korzystają z tych narzędzi i rozwijają je wspólnie.
Jasne jest, że są osobne zespoły, które odpowiadają za rozwój poszczególnych części platformy infrastrukturalnej. Ale odpowiedzialność za rozwój, funkcjonowanie i promocję platformy infrastrukturalnej spoczywa na każdym inżynierze. Na poziomie wewnętrznym staje się to wspólnym narzędziem.
Wszystkie zespoły rozwijają platformę infrastrukturalną, traktując ją ostrożnie jak własne IDE. W swoim IDE instalujesz różne wtyczki, aby wszystko wyglądało ładnie i działało szybko, konfigurujesz skróty klawiszowe. Kiedy otwierasz Sublime, Atom lub Visual Studio Code, pojawiają się błędy kodu i rozumiesz, że praca staje się praktycznie niemożliwa, od razu czujesz smutek i biegasz naprawić swoje IDE.
Dokładnie w ten sam sposób traktuj swoją platformę infrastrukturalną. Jeśli rozumiesz, że coś jest nie tak, składaj zgłoszenie, jeśli nie możesz naprawić samodzielnie. Jeśli to coś prostego — poprawiaj samodzielnie, wysyłaj pull request — chłopaki to rozważą, dodadzą. To nieco inne podejście do inżynieryjnego warsztatu w głowie programisty.
Platforma infrastrukturalna zapewnia przesyłanie artefaktu od dewelopera do klienta z ciągłym podnoszeniem jakości. W IP zaprogramowany jest zestaw historii, które dzieją się z kodem w produkcji. W trakcie lat rozwoju tych historii staje się bardzo dużo, część z nich jest unikalna i odnosi się tylko do ciebie — nie można ich znaleźć w sieci.
W tym momencie platforma infrastrukturalna staje się twoim przewagą konkurencyjną, ponieważ zawiera elementy, których nie ma w narzędziach konkurencji. Im głębsza twoja IP, tym większa twoja przewaga konkurencyjna w kontekście Time-to-market. Pojawia się tutaj problem vendor lock: możesz wybrać sobie cudzą platformę, ale korzystając z cudzych doświadczeń, nie będziesz rozumieć, jak bardzo są one odpowiednie dla ciebie. Tak, nie każda firma może zbudować platformę na miarę Amazonu. To trudna granica, gdzie doświadczenie firmy jest relevantne dla jej pozycji na rynku, i nie można dopuścić do vendor lock. O tym również warto pomyśleć.
Schemat
To podstawowy schemat platformy infrastrukturalnej, który pomoże ci zorganizować wszystkie praktyki i procesy w firmie DevOps.
Przyjrzyjmy się, z czego się składa.
System orkiestracji zasobów, który zapewnia CPU, pamięć, dysk aplikacjom i innym usługom. Na tym z kolei — usługi niskiego poziomu: monitorowanie, logowanie, CI/CD Engine, magazyn artefaktów, infrastruktura jako kod systemów.
Usługi wyższego poziomu: baza danych jako usługa, kolejki jako usługa, Load Balance jako usługa, resizing obrazków jako usługa, Big Data fabryka jako usługa. Na tym wszystkim — pipeline, który dostarcza stale modyfikowany kod do twojego klienta.
Otrzymujesz informacje o tym, jak twoje oprogramowanie działa u klienta, zmieniasz, ponownie dostarczasz ten kod, uzyskujesz informacje — i tak stale rozwijasz zarówno infrastrukturę, jak i swoje oprogramowanie.
Na schemacie delivery pipeline składa się z wielu stacji. Ale to jest zasadnicza schemat, który pokazano jako przykład — nie należy go powtarzać jeden do jednego. Stacje współdziałają z usługami jako usługami — każdy element platformy niesie swoją historię: jak przydzielane są zasoby, jak aplikacja jest uruchamiana, działa z zasobami, monitorowana, zmieniana.
Ważne jest zrozumienie, że każda część platformy niesie historię, i pytanie siebie — jaką historię niesie ten element, może warto go wyrzucić i zastąpić zewnętrzną usługą. Na przykład, czy można zamiast elementu postawić Okmeter? Być może chłopaki już rozwinęli tę ekspertyzę znacznie bardziej niż my. Ale może też nie — być może mamy unikalną ekspertyzę, musimy postawić Prometheus i rozwijać to dalej.
Budowanie platformy
To skomplikowany proces komunikacyjny. Kiedy masz podstawowe praktyki, uruchamiasz komunikację między różnymi inżynierami i specjalistami, którzy opracowują wymagania i standardy, i stale je zmieniają w odniesieniu do różnych narzędzi i podejść. Tutaj ważna jest kultura, która istnieje w DevOps.
Z kulturą wszystko jest bardzo proste — to współpraca i komunikacja, czyli chęć pracy na wspólnym polu razem, chęć wspólnego korzystania z jednego narzędzia. Nie ma w tym żadnej nauki rakietowej — wszystko jest bardzo proste, banalne. Na przykład, wszyscy żyjemy w klatce schodowej i dbamy o jej czystość — taki poziom kultury.
A co u was?
Znowu pytania, które możesz sobie zadać.
Czy infrastruktura jest wyróżniona? Kto odpowiada za jej rozwój? Czy rozumiesz przewagi konkurencyjne swojej infrastruktury?
Te pytania należy zadawać sobie na bieżąco. Jeśli coś można przenieść na zewnętrzne usługi – należy to zrobić. Jeśli zewnętrzna usługa zaczyna blokować twoje działania, powinieneś zbudować system wewnętrznie.
A więc, DevOps…
… to złożony system, który musi zawierać:
- Cyfrowy produkt.
- Moduły biznesowe, które rozwijają ten cyfrowy produkt.
- Zespoły produktowe, które piszą kod.
- Praktyki Continuous Delivery.
- Platformy jako usługa.
- Infrastruktura jako usługa.
- Infrastruktura jako kod.
- Oddzielne praktyki zapewnienia niezawodności, wbudowane w DevOps.
- Praktyka feedbacku, która opisuje to wszystko.
Można wykorzystać ten schemat, zaznaczając w nim to, co już masz w firmie w pewnej formie: to się rozwija lub jeszcze należy rozwinąć.
Już za kilka tygodni odbędzie się . w ramach RIT++. Przyjdź na konferencję, gdzie czeka na ciebie wiele świetnych wykładów na temat ciągłej dostawy, infrastruktury jako kodu i transformacji DevOps. , ostatni termin cenowy 20 maja
Źródło: habr.com
