Definicja DevOps jest bardzo złożona, dlatego za każdym razem dyskusję na ten temat musimy zaczynać od nowa. Tylko na temat Habré istnieje tysiąc publikacji na ten temat. Ale jeśli to czytasz, prawdopodobnie wiesz, czym jest DevOps. Ponieważ ja nie. cześć, mam na imię Aleksander Titow (@), a my po prostu porozmawiamy o DevOps i podzielę się swoim doświadczeniem.
Długo zastanawiałam się, jak uczynić moją historię użyteczną, dlatego będzie tutaj mnóstwo pytań – tych, które sama sobie zadaję i tych, które zadaję klientom naszej firmy. Odpowiadając na te pytania, zrozumienie staje się lepsze. Powiem Ci, dlaczego DevOps jest potrzebny z mojego punktu widzenia, czym jest z mojego punktu widzenia i jak zrozumieć, że z mojego punktu widzenia ponownie zmierzasz w stronę DevOps. Ostatnim punktem będą pytania. Odpowiadając na nie samodzielnie, możesz zrozumieć, czy Twoja firma zmierza w stronę DevOps, czy też występują w jakiś sposób problemy.
Swego czasu płynąłem na falach fuzji i przejęć. Najpierw pracowałem dla małego start-upu o nazwie Qik, potem został on kupiony przez nieco większą firmę o nazwie Skype, którą następnie kupiła nieco większa firma o nazwie Microsoft. W tym momencie zacząłem widzieć, jak idea DevOps zmienia się w firmach różnej wielkości. Potem zainteresowałem się spojrzeniem na DevOps z rynkowego punktu widzenia i wraz z kolegami założyliśmy firmę Express 42. Od 6 lat poruszamy się po falach rynku.
Między innymi jestem jednym z organizatorów społeczności DevOps w Moskwie i organizatorem DevOps-Days 2017, ale nie organizowałem 2018. Express 42 współpracuje z wieloma firmami. Rozwijamy tam DevOps, obserwujemy jak to się dzieje, wyciągamy wnioski, analizujemy, przekazujemy wszystkim nasze wnioski i szkolimy ludzi z praktyk DevOps. Generalnie staramy się poszerzać nasze doświadczenie i wiedzę w tym zakresie.
Dlaczego DevOps
Pierwsze pytanie, które dręczy każdego i zawsze brzmi: dlaczego? Wiele osób uważa, że DevOps to po prostu automatyzacja lub coś podobnego, co każda firma już miała.
— Mieliśmy ciągłą integrację – oznacza to, że mieliśmy już DevOps i dlaczego to wszystko jest potrzebne? Bawią się za granicą, ale nam przeszkadzają w pracy!
Przez 9 lat rozwoju społeczności i metodologii stało się już jasne, że to jeszcze nie marketingowy blask, choć nadal nie do końca wiadomo, po co jest potrzebny. Jak każde narzędzie i proces, DevOps ma określone cele, które ostatecznie osiąga.
Wszystko to wynika z faktu, że świat się zmienia. Odchodzi od podejścia przedsiębiorczego, kiedy firmy idą prosto w stronę marzeń, jak śpiewał nasz petersburski klasyk, z punktu A do punktu B według określonej strategii, z zbudowaną do tego pewną strukturą.
W zasadzie wszystko w IT powinno być budowane według tego podejścia. Tutaj IT służy wyłącznie do automatyzacji procesów.
Automatyzacja nie zmienia się często, bo gdy firma popada w wydeptaną rutynę, co jest do zmiany? Działa – nie dotykaj tego. Teraz podejścia na świecie się zmieniają, a to, które nazywa się Agile, sugeruje, że punkt końcowy B nie jest od razu widoczny.
Kiedy firma przechodzi przez rynek, współpracuje z klientem, stale eksploruje rynek i zmienia punkt końcowy B. Co więcej, im częściej firma zmienia swój kierunek, tym ostatecznie odnosi większy sukces, ponieważ wybiera więcej rynku nisze.
Strategię demonstruje ciekawa firma, o której niedawno się dowiedziałem. One Box Shave to subskrypcyjna usługa dostarczania maszynek do golenia i akcesoriów do golenia w pudełku. Wiedzą, jak dostosować swoje „pudełko” do różnych klientów. Dokonuje tego określone oprogramowanie, które następnie wysyła zamówienie do koreańskiej fabryki produkującej towar.
Produkt ten został kupiony przez Unilever za 1 miliard dolarów. Obecnie konkuruje z Gillette i odebrał znaczną część konsumentów na rynku amerykańskim. One Box Shave mówi:
— 4 ostrza? Mówisz serio? Po co ci to - nie poprawia jakości golenia. Specjalnie dobrany krem, zapach i wysokiej jakości maszynka do golenia z dwoma ostrzami rozwiązują znacznie więcej problemów niż te głupie 4 ostrza Gillette! Czy wkrótce dobijemy do 10?
Tak zmienia się świat. Unilever twierdzi, że ma fajny system informatyczny, który na to pozwala. Ostatecznie wygląda to na koncepcję Czas na rynek, o którym nikt już nie mówił.
Punktem czasu wprowadzenia produktu na rynek nie jest częstotliwość wdrażania. Można często wdrażać, ale cykle wydawnicze będą długie. Jeżeli nałożymy na siebie trzymiesięczne cykle wydawnicze, przesuwając je o tydzień, okaże się, że firma wydaje się wdrażać raz w tygodniu. A od pomysłu do ostatecznej realizacji potrzeba 3 miesięcy.
Time-to-market polega na minimalizacji czasu od pomysłu do ostatecznej realizacji.
W tym przypadku oprogramowanie wchodzi w interakcję z rynkiem. W ten sposób witryna One Box Shave współdziała z klientem. Nie mają sprzedawców – tylko stronę internetową, na której odwiedzający klikają i zostawiają życzenia. W związku z tym coś nowego musi być stale publikowane na stronie i aktualizowane zgodnie z życzeniami. Na przykład w Korei Południowej golą się inaczej niż w Rosji i lubią zapach nie sosny, ale na przykład marchewki i wanilii.
Ponieważ konieczna jest szybka zmiana zawartości witryny, rozwój oprogramowania bardzo się zmienia. Poprzez oprogramowanie musimy dowiedzieć się, czego chce klient. Wcześniej uczyliśmy się tego okrężnymi drogami, na przykład poprzez zarządzanie przedsiębiorstwem. Potem to zaprojektowaliśmy, włożyliśmy wymagania do systemu informatycznego i wszystko było w porządku. Teraz jest inaczej – oprogramowanie projektują wszyscy, którzy są zaangażowani w proces, w tym inżynierowie, ponieważ poprzez specyfikacje techniczne uczą się, jak działa rynek, a także dzielą się swoimi spostrzeżeniami z biznesem.
Na przykład w Qik nagle dowiedzieliśmy się, że ludzie bardzo lubią przesyłać listy kontaktów na serwer i dostarczyli nam aplikację. Początkowo o tym nie myśleliśmy. W klasycznej firmie wszyscy uznaliby, że to błąd, ponieważ specyfikacja nie mówiła, że powinno to działać świetnie i ogólnie było to wdrażane na kolanie, wyłączyliby tę funkcję i powiedzieli: „Nikt tego nie potrzebuje, najważniejsze jest to, że główna funkcjonalność działa.” . Firma technologiczna postrzega to jako szansę i zaczyna zgodnie z tym zmieniać oprogramowanie.
W 1968 roku wizjoner Melvin Conway sformułował następujący pomysł.
Organizacja tworząca system jest ograniczona projektem, który replikuje strukturę komunikacyjną tej organizacji.
Mówiąc bardziej szczegółowo, aby produkować systemy innego typu, trzeba mieć także strukturę komunikacyjną w firmie innego typu. Jeśli Twoja struktura komunikacji jest odgórnie hierarchiczna, nie pozwoli to na stworzenie systemów, które będą w stanie zapewnić bardzo wysoki wskaźnik Time-to-Market.
Czytać można . Jest to ważne dla zrozumienia kultury i filozofii DevOps, ponieważ jedyne co zasadniczo zmienia się w DevOps to struktura komunikacji pomiędzy zespołami.
Z procesowego punktu widzenia, przed DevOps, wszystkie etapy: analityka, rozwój, testowanie, działanie, miały charakter liniowy.
W przypadku DevOps wszystkie te procesy zachodzą jednocześnie.
Jedynym sposobem, w jaki można to osiągnąć, jest wprowadzenie produktu na rynek. Dla ludzi, którzy pracowali według starego procesu, wygląda to nieco kosmicznie i ogólnie tak sobie.
Dlaczego więc potrzebujesz DevOps?
Do rozwoju produktów cyfrowych. Jeśli Twoja firma nie posiada produktu cyfrowego, DevOps nie jest potrzebny – jest bardzo ważny.
DevOps pokonuje ograniczenia prędkości sekwencyjnej produkcji oprogramowania. W nim wszystkie procesy zachodzą jednocześnie.
Trudność wzrasta. Kiedy ewangeliści DevOps mówią ci, że ułatwi ci to wydawanie oprogramowania, jest to nonsens.
Dzięki DevOps sprawy staną się jeszcze bardziej skomplikowane.
Na konferencji na stoisku Avito można było zobaczyć jak wygląda wdrożenie kontenera Docker – zadanie nierealne. Złożoność staje się wygórowana; musisz żonglować wieloma piłkami jednocześnie.
DevOps całkowicie zmienia proces i organizację w firmie — dokładniej, to nie DevOps się zmienia, ale produkt cyfrowy. Aby przejść do DevOps, musisz jeszcze całkowicie zmienić ten proces.
Pytania do specjalisty
Co masz? 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. Oznacza to, że Twoja firma zmierza w stronę DevOps.
Czy Twoja firma tworzy już produkt cyfrowy? Oznacza to, że możesz wznieść się o kolejny poziom wyżej i robić rzeczy bardziej interesująco – znowu z punktu widzenia DevOps. Mówię tylko z tego punktu widzenia.
Czy Twoja firma jest jednym z liderów rynku w niszy produktów cyfrowych? Spotify, Yandex, Uber to firmy, które są obecnie u szczytu postępu technologicznego.
Zadaj sobie te pytania, a jeśli wszystkie odpowiedzi brzmią nie, to może nie powinieneś zajmować się DevOps w tej firmie. Jeżeli temat DevOps jest dla Ciebie naprawdę interesujący, to może... powinieneś przenieść się do innej firmy? Jeśli Twoja firma chce wejść w DevOps, ale na wszystkie pytania odpowiedziałeś „Nie”, to jest jak ten piękny nosorożec, który nigdy się nie zmieni.
Organizacja
Jak powiedziałem, zgodnie z prawem Conwaya zmienia się organizacja przedsiębiorstwa. Zacznę od tego, co z organizacyjnego punktu widzenia uniemożliwia DevOps wniknięcie do wnętrza firmy.
Problem „studni”
Angielskie słowo „Silos” zostało tu przetłumaczone na rosyjski jako „dobrze”. Istota tego problemu jest taka nie ma wymiany informacji pomiędzy zespołami. Każdy zespół zagłębia się w swoją wiedzę, nie budując wspólnej mapy do nawigacji.
W pewnym sensie przypomina mi to osobę, która właśnie przybyła do Moskwy i nie wie jeszcze, jak poruszać się po mapie metra. Moskale zwykle bardzo dobrze znają swój teren, a po całej Moskwie mogą poruszać się za pomocą mapy metra. Kiedy po raz pierwszy przyjeżdżasz do Moskwy, nie masz tej umiejętności i jesteś po prostu zdezorientowany.
DevOps sugeruje przetrwanie tego momentu dezorientacji i współpracę wszystkich działów w celu zbudowania wspólnej mapy interakcji.
Utrudniają to dwa czynniki.
Konsekwencje systemu zarządzania przedsiębiorstwem. Jest zbudowany w oddzielnych, hierarchicznych „studniach”. Na przykład istnieją pewne wskaźniki KPI w firmach obsługujących ten system. Z drugiej strony na przeszkodzie staje mózg osoby, której trudno jest wyjść poza granice swojej wiedzy i poruszać się po całym systemie. To po prostu niewygodne. Wyobraź sobie, że jesteś na lotnisku w Bangkoku – nie znajdziesz tam szybko drogi. DevOps jest również trudny w nawigacji i dlatego ludzie mówią, że musisz znaleźć przewodnik, aby się tam dostać.
Ale najważniejsze jest to, że problem „studni” dla inżyniera przepojonego duchem DevOps, czytającego Fowlera i masę innych książek, wyraża się w tym, że „studnie” nie pozwalają na robienie „oczywistych” rzeczy. Często spotykamy się po DevOps w Moskwie, rozmawiamy ze sobą i ludzie narzekają:
— Chcieliśmy po prostu uruchomić CI, ale okazało się, że zarząd tego nie potrzebował.
Dzieje się tak właśnie dlatego CI и Ciągły proces dostawy są na granicy wielu egzaminów. Po prostu bez przezwyciężenia problemu „studni” na poziomie organizacyjnym nie będziesz w stanie ruszyć do przodu, bez względu na to, co zrobisz i bez względu na to, jak smutne to będzie.
Każdy uczestnik procesu w firmie: programiści backendowi i frontendowi, testujący, DBA, operacyjny, sieciowy kopie w swoim kierunku i nikt nie ma wspólnej mapy poza menadżerem, który w jakiś sposób ich monitoruje i zarządza nimi za pomocą „dziel i zwyciężaj” metodą.
Ludzie walczą o jakieś gwiazdy lub flagi, każdy kopie swoją wiedzę.
W rezultacie, gdy pojawia się zadanie połączenia tego wszystkiego w jedną całość i zbudowania wspólnego rurociągu, a nie ma już potrzeby walki o gwiazdy i flagi, pojawia się pytanie – co w ogóle robić? Musimy się jakoś dogadać, ale w szkole nikt nas tego nie uczył. Od szkoły uczono nas: ósma klasa – wow! - w porównaniu do siódmej klasy! Tutaj jest tak samo.
Czy w Twojej firmie jest podobnie?
Aby to sprawdzić, możesz zadać sobie następujące pytania.
Czy zespoły korzystają ze wspólnych narzędzi i przyczyniają się do zmian w tych wspólnych narzędziach?
Jak często zespoły się reorganizują – niektórzy specjaliści z jednego zespołu przechodzą do innego zespołu? To właśnie w środowisku DevOps staje się to normalne, ponieważ czasami człowiek po prostu nie jest w stanie zrozumieć, czym zajmuje się inny obszar specjalizacji. 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 zmian i coś zmienić? A może wymaga to silnej ręki najwyższego kierownictwa i kierownictwa? Niedawno pisałem na Facebooku, jak jeden mało znany bank wdraża narzędzia poprzez zamówienia: piszemy zlecenie, realizujemy przez rok i zobaczymy, co się stanie. To oczywiście jest długie i smutne.
Jak ważne jest dla menedżerów otrzymywanie osobistych osiągnięć bez uwzględnienia osiągnięć firmy?
Jeśli sam odpowiesz sobie na te pytania, stanie się jasne, czy masz taki problem w swojej firmie.
Infrastruktura jako kod
Po zażegnaniu tego problemu pierwszą ważną praktyką, bez której trudno jest dalej awansować w DevOps, jest infrastruktura jako kod.
Najczęściej infrastrukturę jako kod postrzega się w następujący sposób:
— Zautomatyzujmy wszystko w bashu, zajmijmy się skryptami, aby administratorzy mieli mniej pracy ręcznej!
Ale to nieprawda.
Infrastruktura jako kod oznacza, że system informatyczny, z którym pracujesz, opisujesz w formie kodu, aby stale rozumieć jego stan.
Razem z innymi zespołami tworzysz mapę w formie kodu, który każdy może zrozumieć i potrafi nawigować oraz nawigować. Nie ma znaczenia na czym się to robi – Chef, Ansible, Salt, czy przy użyciu plików YAML w Kubernetesie – nie ma różnicy.
Na konferencji kolega z 2GIS opowiedział jak zrobili własną wewnętrzną rzecz dla Kubernetesa, która opisuje strukturę poszczególnych systemów. Aby opisać systemy 500 potrzebowali osobnego narzędzia generującego ten opis. Gdy jest taki opis, każdy może się ze sobą sprawdzić, monitorować zmiany, jak to zmienić i poprawić, czego brakuje.
Zgadzam się, poszczególne skrypty bash zwykle nie zapewniają takiego zrozumienia. W jednej z firm, w których pracowałem, istniała nawet nazwa skryptu „tylko do zapisu” – gdy skrypt jest napisany, ale nie można go już odczytać. Myślę, że to również jest Ci znane.
Infrastruktura taka, jaka jest kod opisujący aktualny stan infrastruktury. Wiele zespołów ds. produktów, infrastruktury i usług współpracuje nad tym kodem, a co najważniejsze, wszyscy muszą zrozumieć, jak ten kod faktycznie działa.
Kod jest utrzymywany zgodnie z najlepszymi praktykami kodowania: wspólny rozwój, przegląd kodu, programowanie w XP, testowanie, pull requesty, CI dla infrastruktury kodu – wszystko to jest odpowiednie i może być wykorzystane.
Kod staje się wspólnym językiem dla wszystkich inżynierów.
Zmiana infrastruktury w kodzie nie zajmuje dużo czasu. Tak, kod infrastrukturalny może również mieć dług techniczny. Zwykle zespoły spotykają się z tym półtora roku po rozpoczęciu wdrażania „infrastruktury jako kodu” w postaci kilku skryptów lub nawet Ansible, które piszą jak spaghetti kod, a do tego dorzucają także skrypty bash!
To jest ważne: Jeśli jeszcze tego nie próbowałeś, pamiętaj o tym Ansible nie jest bashem! Przeczytaj uważnie dokumentację, przestudiuj, co o niej piszą.
Infrastruktura jako kod polega na rozdzieleniu kodu infrastruktury na osobne warstwy.
W naszej firmie wyróżniamy 3 podstawowe warstwy, które są bardzo przejrzyste i proste, choć może być ich więcej. Możesz sprawdzić kod infrastruktury i stwierdzić, czy występuje ten stan, czy nie. Jeśli nie są podświetlone żadne warstwy, musisz poświęcić trochę czasu i dokonać małej refaktoryzacji.
warstwa podstawowa - tak konfiguruje się system operacyjny, kopie zapasowe i inne rzeczy niskiego poziomu, np. jak wdrażany jest Kubernetes na poziomie podstawowym.
Poziom usług - są to usługi, które dostarczasz deweloperowi: logowanie jako usługa, monitorowanie jako usługa, baza danych jako usługa, balanser jako usługa, kolejka jako usługa, Continuous Delivery jako usługa - pakiet usług, które poszczególne zespoły może zapewnić rozwój. Wszystko to należy opisać w osobnych modułach w systemie zarządzania konfiguracją.
Warstwa, w której tworzone są aplikacje i opisuje, jak będą się one rozwijać na wierzchu dwóch poprzednich warstw.
Pytania kontrolne
Czy Twoja firma posiada wspólne repozytorium infrastruktury? Czy zarządzasz długiem technicznym w swojej infrastrukturze? Czy stosujesz praktyki programistyczne w repozytorium infrastruktury? Czy Twoja infrastruktura jest podzielona na warstwy? Możesz sprawdzić diagram Base-service-APP. Jak trudno jest dokonać zmiany?
Jeśli doświadczyłeś, że wprowadzenie zmian zajęło półtora dnia, oznacza to, że masz dług techniczny i musisz nad nim popracować. Właśnie natknąłeś się na prowizję techniczną w swoim kodzie infrastruktury. Pamiętam wiele takich historii, gdy żeby zmienić jakiś CCTL, trzeba przepisać połowę kodu infrastruktury, bo kreatywność i chęć automatyzacji wszystkiego doprowadziły do tego, że wszędzie wszystko jest skorodowane, wszystkie uchwyty zostały usunięte, a konieczna jest refaktoryzacja.
Ciągła dostawa
Porównajmy debet z kredytem. Najpierw pojawia się opis infrastruktury, który może być dość prosty. Nie musisz opisywać wszystkiego szczegółowo, ale wymagany jest podstawowy opis, abyś mógł z tym pracować. W przeciwnym razie nie jest jasne, co dalej zrobić z dostawą ciągłą. Wszystkie te praktyki rozwijają się jednocześnie, gdy przychodzisz do DevOps, ale zaczyna się od zrozumienia tego, co masz i jak tym zarządzać. To jest właśnie praktyka infrastruktury jako kodu.
Gdy stanie się jasne, że już go masz i jak nim zarządzać, zaczynasz zastanawiać się, jak jak najszybciej wysłać kod programisty do produkcji. Mam na myśli razem z deweloperem - pamiętamy o problemie „studni”, czyli nie wymyślają tego indywidualni ludzie, ale zespół.
Kiedy jesteśmy z Wania Jewtuchowicz widziałem pierwszą książkę Jez Pokorny i grupy autorów „Ciągła dostawa”, który ukazał się w 2009 roku, długo zastanawialiśmy się, jak przetłumaczyć jego tytuł na język rosyjski. Chcieli przetłumaczyć to jako „Stałe dostarczanie”, ale niestety przetłumaczono to jako „Ciągła dostawa”. Wydaje mi się, że w naszej nazwie jest coś rosyjskiego, z presją.
Stale dostarczanie środków
Kod znajdujący się w repozytorium produktu zawsze można pobrać na produkcję. Może nie jest osłabiony, ale zawsze jest na to gotowy. W związku z tym zawsze piszesz kod z trudnym do wyjaśnienia uczuciem niepokoju pod kością ogonową. Często pojawia się podczas wdrażania kodu infrastruktury. To uczucie pewnego niepokoju powinno być obecne - uruchamia procesy mózgowe, które pozwalają na pisanie kodu nieco inaczej. Należy to odnotować w regulaminie opracowania.
Aby zapewnić spójne dostarczanie, potrzebny jest format artefaktu, który działa na platformie infrastrukturalnej. Jeśli wrzucisz na platformę infrastrukturalną „odpady życiowe” o różnych formatach, wówczas stanie się to ujednolicone, trudne w utrzymaniu i pojawi się problem długu technicznego. Trzeba dopasować format artefaktu – to także zadanie zbiorowe: wszyscy musimy się zebrać, pokombinować i wymyślić taki format.
Artefakt jest stale ulepszany i zmienia się, aby dostosować się do środowiska produkcyjnego w miarę jego przemieszczania się w rurociągu dostaw. Kiedy artefakt przemieszcza się wzdłuż potoku, stale napotyka pewne niewygodne dla niego rzeczy, które są podobne do tych, z którymi spotyka się artefakt, który wprowadzasz do produkcji. Jeśli w klasycznym rozwoju robi to administrator systemu, który wykonuje rollout, to w procesie DevOps dzieje się to cały czas: tutaj przetestowali to za pomocą kilku testów, tutaj wrzucili do klastra Kubernetes, który jest mniej więcej podobny do produkcji, a potem nagle rozpoczęli testy obciążeniowe.
Przypomina to nieco grę Pac-Man - artefakt przechodzi jakąś historię. Jednocześnie ważne jest, aby kontrolować, czy kod faktycznie przechodzi przez historię i czy jest w jakiś sposób powiązany z Twoją produkcją. Historie z produkcji można wciągnąć w proces Continuous Delivery: tak było, gdy coś spadło, teraz po prostu zaprogramujmy ten scenariusz w systemie. Za każdym razem kod będzie przechodził przez ten scenariusz i następnym razem nie napotkasz tego problemu. Dowiesz się o tym znacznie wcześniej, niż dotrze ono do Twojego klienta.
Różne strategie wdrażania. Na przykład używasz testów AB lub wdrożeń Canary, aby przetestować kod w różny sposób na różnych klientach, uzyskać informacje o działaniu kodu i to znacznie wcześniej niż wtedy, gdy zostanie on wdrożony dla 100 milionów użytkowników.
„Konsekwentnie dostarczaj” wygląda tak.
Proces dostawy Dev, CI, Test, PreProd, Prod nie jest odrębnym środowiskiem, są to etapy lub stacje z ognioodpornymi sumami, przez które przechodzi Twój artefakt.
Jeśli masz kod infrastruktury opisany jako aplikacja usługi podstawowej, to pomaga nie zapomnij o wszystkich skryptachi zapisz je jako kod tego artefaktu, promować artefakt i zmieniaj to w miarę upływu czasu.
Pytania autotestu
Czas od opisu funkcji do wprowadzenia do produkcji w 95% przypadków to mniej niż tydzień? Czy jakość artefaktu poprawia się na każdym etapie rurociągu? Czy jest jakaś historia, przez którą to przechodzi? Czy stosujesz różne strategie wdrażania?
Jeśli wszystkie odpowiedzi są twierdzące, to jesteś niesamowicie fajny! Odpowiedzi napiszcie w komentarzach – będzie mi miło).
Napisz do nas
To najtrudniejsza praktyka ze wszystkich. Na konferencji DevOpsConf kolega z Infobip, mówiąc o tym, był trochę zdezorientowany w swoich słowach, ponieważ jest to naprawdę bardzo złożona praktyka, a o tym, że trzeba wszystko monitorować!
Na przykład dawno temu, kiedy pracowałem w Qik, zdaliśmy sobie sprawę, że musimy wszystko monitorować. Zrobiliśmy to i obecnie w Zabbix mamy 150 000 pozycji, które są stale monitorowane. To było straszne, dyrektor techniczny skręcił palec w skroń:
- Chłopaki, dlaczego gwałcicie serwer czymś niejasnym?
Ale potem miał miejsce incydent, który pokazał, że jest to naprawdę bardzo fajna strategia.
Jedna z usług zaczęła się ciągle zawieszać. Początkowo się nie zawieszał, co ciekawe, nie dodano tam kodu, bo był to 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 i nagle zaczęła się zawieszać z błędem „Błąd segmentacji”.
Byliśmy w szoku, otworzyliśmy nasze wykresy w Zabbix i okazało się, że półtora tygodnia temu zachowanie żądań w usłudze API, z której korzysta ten broker, uległo znacznej zmianie. Następnie zauważyliśmy, że zmieniła się częstotliwość wysyłania określonego rodzaju wiadomości. Później dowiedzieliśmy się, że byli to klienci z Androidem. Pytaliśmy:
— Chłopaki, co się z wami stało półtora tygodnia temu?
W odpowiedzi usłyszeliśmy ciekawą historię o tym, jak przeprojektowali interfejs użytkownika. Jest mało prawdopodobne, aby ktokolwiek od razu powiedział, że zmienił bibliotekę HTTP. Dla klientów Androida jest to jak zmiana mydła w łazience – po prostu nie pamiętają. W rezultacie po 40 minutach rozmowy dowiedzieliśmy się, że zmienili bibliotekę HTTP i zmieniły się jej domyślne taktowania. Doprowadziło to do zmiany zachowania ruchu na serwerze API, co doprowadziło do sytuacji, która spowodowała wyścig w brokerze i zaczęła się zawieszać.
Bez dokładnego monitorowania otwarcie tego jest zazwyczaj niemożliwe. Jeśli w organizacji nadal występuje problem „studni”, gdy wszyscy obrzucają się nawzajem pieniędzmi, może to trwać latami. Po prostu zrestartuj serwer, ponieważ nie da się rozwiązać problemu. Kiedy monitorujesz, śledzisz, śledzisz wszystkie zdarzenia, które masz i wykorzystujesz monitorowanie jako testowanie - napisz kod i od razu wskaż, jak go monitorować, również w postaci kodu (mamy już infrastrukturę jako kod), wszystko staje się jasne, jak na dłoni. Nawet tak złożone problemy można łatwo śledzić.
Zbierz wszystkie informacje o tym, co dzieje się z artefaktem na każdym etapie procesu dostawy – nie w fazie produkcji.
Wrzuć monitoring do CI, a pewne podstawowe rzeczy będą już tam widoczne. Później zobaczysz je w testach Test, PredProd i testach obciążeniowych. Zbieraj informacje na wszystkich etapach, nie tylko metryki, statystyki, ale także logi: przebieg działania aplikacji, anomalie - zbieraj wszystko.
Inaczej trudno będzie to ustalić. Mówiłem już, że DevOps jest bardziej złożony. Aby poradzić sobie z tą złożonością, musisz mieć normalne analizy.
Pytania do samokontroli
Czy monitorowanie i rejestrowanie danych jest dla Ciebie narzędziem programistycznym? Czy pisząc kod, Twoi programiści, w tym Ty, zastanawiają się, jak go monitorować?
Czy słyszysz o problemach ze strony klientów? Czy lepiej rozumiesz klienta poprzez monitorowanie i logowanie? Czy lepiej rozumiesz system dzięki monitorowaniu i logowaniu? Czy zmieniasz system po prostu dlatego, że widzisz, że trend w systemie jest rosnący i rozumiesz, że za kolejne 3 tygodnie wszystko umrze?
Kiedy już będziesz mieć te trzy komponenty, możesz zastanowić się, jakiego rodzaju platformę infrastrukturalną posiadasz w swojej firmie.
Platforma infrastrukturalna
Nie chodzi o to, że jest to zestaw odmiennych narzędzi, którymi dysponuje każda firma.
Istotą platformy infrastrukturalnej jest to, że wszystkie zespoły korzystają z tych narzędzi i wspólnie je rozwijają.
Oczywiste jest, że za rozwój poszczególnych elementów platformy infrastrukturalnej odpowiadają odrębne zespoły. Jednocześnie jednak każdy inżynier ponosi odpowiedzialność za rozwój, wydajność i promocję platformy infrastrukturalnej. Na poziomie wewnętrznym staje się powszechnym narzędziem.
Wszystkie zespoły opracowują platformę infrastrukturalną i traktują ją ostrożnie jak własne IDE. W swoim IDE instalujesz różne wtyczki, aby wszystko było ładne i szybkie, oraz konfigurujesz skróty klawiszowe. Kiedy otwierasz Sublime, Atom lub Visual Studio Code, wylewają się błędy w kodzie i zdajesz sobie sprawę, że w ogóle nie da się pracować, od razu robi ci się smutno i biegniesz naprawić swoje IDE.
Traktuj swoją platformę infrastrukturalną w ten sam sposób. Jeśli rozumiesz, że coś jest z tym nie tak, zostaw prośbę, jeśli nie możesz sam tego naprawić. Jeśli jest coś prostego, edytuj to sam, wyślij żądanie ściągnięcia, chłopaki to rozważą i dodadzą. To nieco inne podejście do narzędzi inżynieryjnych w głowie dewelopera.
Platforma infrastrukturalna zapewnia transfer artefaktu z fazy rozwojowej do klienta przy ciągłej poprawie jakości. Adres IP jest zaprogramowany za pomocą zestawu historii, które dzieją się z kodem w fazie produkcyjnej. Na przestrzeni lat rozwoju tych historii powstało wiele, niektóre z nich są wyjątkowe i dotyczą tylko Ciebie - nie można ich wyszukać w Google.
W tym momencie platforma infrastrukturalna staje się Twoją przewagą konkurencyjną, ponieważ ma w sobie coś, czego nie ma w narzędziu konkurencji. Im głębsze jest Twoje IP, tym większa jest Twoja przewaga konkurencyjna pod względem czasu wprowadzenia produktu na rynek. Pojawia się tutaj problem z blokadą dostawcy: Możesz skorzystać z czyjejś platformy, ale korzystając z cudzego doświadczenia, nie zrozumiesz, jak istotna jest ona dla Ciebie. Tak, nie każda firma może zbudować platformę taką jak Amazon. To trudna linia, gdzie doświadczenie firmy ma związek z jej pozycją na rynku i nie można tam zastosować blokady dostawcy. Warto o tym również pomyśleć.
Schemat
To podstawowy schemat platformy infrastrukturalnej, który pomoże Ci skonfigurować wszystkie praktyki i procesy w firmie DevOps.
Przyjrzyjmy się, z czego się składa.
System orkiestracji zasobów, który zapewnia procesor, pamięć, dysk aplikacjom i innym usługom. Poza tym - usługi na niskim poziomie: monitorowanie, logowanie, silnik CI/CD, przechowywanie artefaktów, infrastruktura jako kod systemowy.
Usługi na wyższym poziomie: baza danych jako usługa, kolejki jako usługa, Load Balance jako usługa, zmiana rozmiaru obrazu jako usługa, Big Data Factory jako usługa. Poza tym - potok dostarczający stale modyfikowany kod Twojemu klientowi.
Otrzymujesz informacje o tym, jak Twoje oprogramowanie działa dla klienta, zmieniasz je, dostarczasz ten kod ponownie, otrzymujesz informację – i tak stale rozwijasz zarówno platformę infrastrukturalną, jak i swoje oprogramowanie.
Na schemacie rurociąg dostaw składa się z wielu etapów. Ale to jest schematyczny diagram podany jako przykład - nie ma potrzeby powtarzania go jeden po drugim. Etapy wchodzą w interakcję z usługami tak, jakby były usługami – każdy element platformy niesie ze sobą własną historię: w jaki sposób przydzielane są zasoby, w jaki sposób aplikacja jest uruchamiana, współpracuje z zasobami, jest monitorowana i zmienia się.
Warto zrozumieć, że każda część platformy niesie ze sobą jakąś historię i zadać sobie pytanie, jaką historię niesie ze sobą ta cegiełka, może warto ją wyrzucić i zastąpić usługą strony trzeciej. Czy na przykład można zamontować Okmeter zamiast cegły? Być może chłopaki rozwinęli już tę wiedzę znacznie bardziej niż my. Ale może nie - być może mamy wyjątkową wiedzę, musimy zainstalować Prometheusa i dalej go rozwijać.
Stworzenie platformy
To złożony proces komunikacji. Kiedy masz podstawowe praktyki, rozpoczynasz komunikację między różnymi inżynierami i specjalistami, którzy opracowują wymagania i standardy, i stale zmieniają je na różne narzędzia i podejścia. Ważna jest tutaj kultura, którą mamy w DevOps.
Z kulturą wszystko jest bardzo proste - chodzi o współpracę i komunikację, czyli chęć wspólnej pracy na wspólnym polu, chęć wspólnego władania jednym instrumentem. Nie ma tu żadnej rakiety - wszystko jest bardzo proste, banalne. Na przykład wszyscy mieszkamy w przedpokoju i dbamy o czystość - taki poziom kultury.
Co masz?
Znowu pytania, które możesz sobie zadać.
Czy platforma infrastrukturalna jest dedykowana? Kto jest odpowiedzialny za jego rozwój? Czy rozumiesz przewagę konkurencyjną swojej platformy infrastrukturalnej?
Musisz stale zadawać sobie te pytania. Jeśli coś można przenieść do zewnętrznych usług, należy to przekazać; jeśli zewnętrzna usługa zacznie blokować Twój ruch, musisz zbudować w sobie system.
A więc DevOps...
...to skomplikowany system, musi posiadać:
- Produkt cyfrowy.
- Moduły biznesowe rozwijające ten produkt cyfrowy.
- Zespoły produktowe piszące kod.
- Praktyki ciągłego dostarczania.
- Platformy jako usługa.
- Infrastruktura jako usługa.
- Infrastruktura jako kod.
- Oddzielne praktyki utrzymania niezawodności wbudowane w DevOps.
- Praktyka informacji zwrotnej, która opisuje wszystko.
Możesz skorzystać z tego diagramu, podkreślając w nim to, co już w jakiejś formie masz w swojej firmie: czy jest rozwinięte, czy jeszcze wymaga rozwoju.
To się skończy za kilka tygodni . w ramach RIT++. Przyjdź na konferencję, na której znajdziesz wiele fajnych raportów na temat ciągłego dostarczania, infrastruktury jako kodu i transformacji DevOps. , ostatni termin składania ofert upływa 20 maja
Źródło: www.habr.com