Praktyki bezpiecznego wdrażania

Czasami wydanie nie spełniło oczekiwań. Pomimo zastosowania najlepszych rozwiązań i przekazywania wszystkich bram jakości, czasami występują problemy, które powodują wdrożenie produkcyjne powodujące nieprzewidziane problemy dla użytkowników. Aby zminimalizować i wyeliminować wpływ tych problemów, zespoły DevOps są zachęcane do przyjęcia progresywnej strategii ekspozycji , która równoważy narażenie danej wersji na sprawdzoną wydajność. Ponieważ wydanie okazuje się w środowisku produkcyjnym, staje się dostępne dla warstw szerszego grona odbiorców, dopóki nie będą z niego korzystać wszyscy. Zespoły mogą używać bezpiecznych praktyk wdrażania w celu zmaksymalizowania jakości i szybkości wydań w środowisku produkcyjnym.

Kontrolowanie ekspozycji na klientów

Zespoły DevOps mogą stosować różne rozwiązania w celu kontrolowania ujawnienia aktualizacji klientom. W przeszłości testowanie A/B było popularnym wyborem dla zespołów, które chcą zobaczyć, jak różne wersje usługi lub interfejsu użytkownika działają w odniesieniu do celów docelowych. Testowanie A/B jest również stosunkowo łatwe w użyciu, ponieważ zmiany są zwykle niewielkie i często porównują tylko różne wersje na brzegu usługi dostępnej dla klienta.

Sejf wdrażanie za pośrednictwem pierścieni

W miarę rozwoju platform skalowanie infrastruktury i odbiorcy mają tendencję do wzrostu. Tworzy to zapotrzebowanie na model wdrażania, który równoważy ryzyko związane z nowym wdrożeniem z korzyściami oferowanymi przez te aktualizacje. Ogólną ideą jest to, że dana wersja powinna być najpierw widoczna tylko dla małej grupy użytkowników o najwyższej tolerancji dla ryzyka. Następnie, jeśli wydanie działa zgodnie z oczekiwaniami, może być narażone na szerszą grupę użytkowników. Jeśli nie ma problemów, proces może być kontynuowany przez szersze grupy użytkowników lub pierścienie, dopóki wszyscy nie będą używać nowej wersji. W przypadku nowoczesnych platform ciągłego dostarczania , takich jak GitHub Actions i Azure Pipelines, tworzenie procesu wdrażania z pierścieniami jest dostępne dla zespołów DevOps o dowolnym rozmiarze.

Flagi funkcji

Niektóre funkcje czasami muszą być wdrażane w ramach wydania, ale nie są początkowo widoczne dla użytkowników. W takich przypadkach flagi funkcji zapewniają rozwiązanie, w którym funkcje mogą być włączone za pośrednictwem zmian konfiguracji na podstawie środowiska, pierścienia lub innego konkretnego wdrożenia.

Zgoda użytkownika

Podobnie jak w przypadku flag funkcji, użytkownik wyraża zgodę na ograniczanie narażenia. W tym modelu dana funkcja jest włączona w wersji, ale nie jest aktywowana dla użytkownika, chyba że chce jej użyć. Decyzja o tolerancji ryzyka jest odciążona dla użytkowników, aby mogli zdecydować, jak szybko chcą wdrożyć pewne aktualizacje.

Wiele praktyk jest często stosowanych jednocześnie. Na przykład zespół może mieć eksperymentalną funkcję przeznaczoną dla bardzo konkretnego przypadku użycia. Ponieważ jest to ryzykowne, wdroży je w pierwszym pierścieniu, aby użytkownicy wewnętrzni mogli wypróbować. Jednak mimo że funkcje znajdują się w kodzie, ktoś będzie musiał ustawić flagę funkcji dla określonego wdrożenia w pierścieniu, aby funkcja została uwidoczniona za pośrednictwem interfejsu użytkownika. Nawet wtedy flaga funkcji może uwidocznić tylko opcję, aby użytkownik zdecydował się na korzystanie z nowej funkcji. Każda osoba, która nie znajduje się w pierścieniu, na tym wdrożeniu lub nie zdecydowała się na to, nie będzie widoczna dla tej funkcji. Chociaż jest to dość zawstydzony przykład, służy do zilustrowania elastyczności i praktyczności postępowej ekspozycji.

Typowe problemy, z którymi zespoły napotykają na wczesnym etapie

W miarę jak zespoły przechodzą w kierunku bardziej elastycznej praktyki DevOps, mogą one napotkać problemy zgodne z innymi osobami, które zmigrowały się z dala od tradycyjnych monolitycznych dostaw. Zespoły używane do wdrażania raz na kilka miesięcy mają nastawienie, które bufory na potrzeby stabilizacji. Oczekuje się, że każde wdrożenie wprowadzi znaczną zmianę w swojej usłudze i że wystąpią nieprzewidziane problemy.

Ładunki są zbyt duże

Usługi wdrażane co kilka miesięcy są zwykle wypełniane wieloma zmianami. Zwiększa to prawdopodobieństwo wystąpienia natychmiastowych problemów, a także utrudnia rozwiązywanie tych problemów, ponieważ jest tak wiele nowych rzeczy. Przechodząc do częstszych dostaw, różnice w wdrożonych elementach stają się mniejsze, co pozwala na bardziej skoncentrowane testowanie i łatwiejsze debugowanie.

Brak izolacji usługi

Systemy monolityczne są tradycyjnie skalowane przez wyrównanie sprzętu, na którym są wdrażane. Jednak gdy coś pójdzie nie tak z wystąpieniem, prowadzi to do problemów dla wszystkich. Jednym z prostych rozwiązań jest dodanie wielu wystąpień w celu równoważenia obciążenia użytkowników. Może to jednak wymagać znaczących zagadnień dotyczących architektury, ponieważ wiele starszych systemów nie jest tworzonych jako wiele wystąpień. Ponadto konieczne może być przydzielenie znaczących zduplikowanych zasobów na potrzeby funkcji, które mogą być lepiej skonsolidowane w innym miejscu.

W miarę dodawania nowych funkcji sprawdź, czy architektura mikrousług może ułatwić działanie i skalowanie dzięki lepszej izolacji usług.

Ręczne kroki prowadzą do błędów

Gdy zespół wdraża tylko kilka razy w roku, automatyzacja dostaw może nie wydawać się warta inwestycji. W związku z tym wiele procesów wdrażania jest zarządzanych ręcznie. Wymaga to znacznego czasu i wysiłku i jest podatne na błędy ludzkie. Wystarczy zautomatyzować najbardziej typowe zadania kompilacji i wdrażania, aby znacznie skrócić czas utraty i niewymuszone błędy.

Zespoły mogą również korzystać z infrastruktury jako kodu , aby mieć lepszą kontrolę nad środowiskami wdrażania. Eliminuje to konieczność wprowadzania ręcznych zmian przez zespół operacyjny w miarę wprowadzania nowych funkcji lub zależności w różnych środowiskach wdrażania.

Tylko operacyjnego mogą wykonywać wdrożenia

Niektóre organizacje mają zasady, które wymagają zainicjowania wszystkich wdrożeń i zarządzania nimi przez personel operacyjny. Chociaż w przeszłości może istnieć dobre powody, proces Agile DevOps znacznie przynosi korzyści, gdy zespół programistyczny może inicjować i kontrolować wdrożenia. Nowoczesne platformy ciągłego dostarczania oferują szczegółową kontrolę nad tym, kto może inicjować wdrożenia, oraz kto może uzyskiwać dostęp do dzienników stanu i innych informacji diagnostycznych, upewniając się, że odpowiednie osoby mają odpowiednie informacje tak szybko, jak to możliwe.

Nie można wycofać nieprawidłowych wdrożeń

Czasami wdrożenie pójdzie źle, a zespoły muszą rozwiązać ten problem. Jednak jeśli procesy są ręczne i dostęp do informacji jest powolny i ograniczony, może to być trudne do wycofania się z poprzedniego roboczego wdrożenia. Na szczęście istnieją różne narzędzia i praktyki mające na celu ograniczenie ryzyka niepomyślnie wdrożeń.

Podstawowe zasady

Zespoły, które chcą wdrożyć bezpieczne praktyki wdrażania, powinny stosować pewne podstawowe zasady, aby stanowić podstawę wysiłku.

Zachowaj spójność

Te same narzędzia używane do wdrażania w środowisku produkcyjnym powinny być używane w środowiskach deweloperskich i testowych. Jeśli występują problemy, takie jak te, które często wynikają z nowych wersji zależności lub narzędzi, powinny one zostać przechwycone na dobre, zanim kod jest blisko wydania do środowiska produkcyjnego.

Dbanie o sygnały jakości

Zbyt wiele zespołów wpada w wspólną pułapkę, że naprawdę nie dbają o sygnały jakości. W miarę upływu czasu mogą stwierdzić, że piszą testy lub wykonują zadania dotyczące jakości, aby po prostu zmienić żółte ostrzeżenie na zielone zatwierdzenie. Sygnały jakości są naprawdę ważne, ponieważ reprezentują impuls projektu. Sygnały dotyczące jakości używane do zatwierdzania wdrożeń powinny być stale śledzone codziennie.

Wdrożenia powinny wymagać zerowego przestoju

Chociaż nie ma kluczowego wpływu na to, aby każda usługa zawsze była dostępna, zespoły powinny podejść do etapów dostarczania i operacji Metodyki DevOps z myślą, że mogą i powinny wdrażać nowe wersje bez konieczności ich wyłączania przez cały czas. Nowoczesne narzędzia infrastruktury i potoku są wystarczająco zaawansowane, gdy jest to możliwe dla praktycznie każdego zespołu w celu osiągnięcia 100% czasu pracy.

Wdrożenia powinny odbywać się w godzinach pracy

Jeśli zespół pracuje z nastawieniem, że wdrożenia wymagają zerowego przestoju, to nie ma znaczenia, gdy wdrożenie zostanie wypchnięte. Ponadto korzystne jest wypychanie wdrożeń w godzinach pracy, szczególnie na początku dnia i na początku tygodnia. Jeśli coś pójdzie nie tak, należy go prześledzić wystarczająco wcześnie, aby kontrolować promień wybuchu. Ponadto wszyscy będą już pracować i skupić się na rozwiązywaniu problemów.

Wdrażanie oparte na pierścieniu

Zespoły z dojrzałymi rozwiązaniami dotyczącymi wydania metodyki DevOps są w stanie przyjąć wdrożenie oparte na pierścieniu. W tym modelu nowe funkcje są najpierw wdrażane dla klientów chcących zaakceptować największe ryzyko. W miarę udowodnienia wdrożenia odbiorcy rozszerzają liczbę użytkowników, dopóki nie będą z niej korzystać wszyscy.

Przykładowy model pierścieniowy

Typowy model wdrażania pierścienia został zaprojektowany tak szybko, jak to możliwe, dzięki starannemu segmentacji użytkowników i infrastruktury. W poniższym przykładzie pokazano, jak pierścienie są używane przez główny zespół firmy Microsoft.

Pierścień	Purpose	Użytkownicy	Centrum danych
0	Znajduje większość usterek wpływających na użytkownika wprowadzonych przez wdrożenie	Tylko wewnętrzne, wysoka tolerancja dla ryzyka i błędów	Zachodnio-środkowe stany USA
1	Obszary, w których zespół nie testuje obszernie	Klienci korzystający z szerokiej gamy produktu	Małe centrum danych
2	Problemy związane ze skalowaniem	Konta publiczne, najlepiej bezpłatne przy użyciu zróżnicowanego zestawu funkcji	Średnie lub duże centrum danych
3	Problemy ze skalowaniem na kontach wewnętrznych i problemy związane z międzynarodowymi	Duże konta wewnętrzne i klienci europejscy	Wewnętrzne centrum danych i europejskie centrum danych
100	Pozostałe jednostki skalowania	Wszyscy	Wszystkie cele wdrożenia

Zezwalaj na czas pieczenia

Termin czas pieczenia odnosi się do czasu, przez jaki wdrożenie może zostać uruchomione przed rozszerzeniem na następny pierścień. Niektóre problemy mogą potrwać kilka godzin lub dłużej, aby rozpocząć wyświetlanie objawów, dlatego wydanie powinno być używane przez odpowiedni czas, zanim zostanie uznane za gotowe.

Ogólnie rzecz biorąc, 24-godzinny dzień powinien być wystarczający, aby większość scenariuszy ujawniała ukryte usterki. Jednak ten okres powinien obejmować okres szczytowego użycia, który wymaga pełnego dnia roboczego, w przypadku usług, które są szczytowe w godzinach pracy.

Przyspiesz poprawki

Zdarzenie na żywo witryny (LSI) występuje, gdy usterka ma poważny wpływ na produkcję. LSI wymaga utworzenia poprawki, która jest aktualizacją poza pasmem zaprojektowaną w celu rozwiązania problemu o wysokim priorytcie.

Jeśli usterka to Sev 0, najpoważniejszy typ usterki, poprawka może zostać wdrożona bezpośrednio w jednostce skalowania, której dotyczy problem, tak szybko, jak to możliwe. Chociaż ważne jest, aby poprawka nie pogorszyła się, usterki tej ważności są uważane za tak destrukcyjne, że należy je natychmiast rozwiązać.

Usterki oceniane jako 1 muszą być wdrażane za pośrednictwem pierścienia 0, ale można je wdrożyć w jednostkach skalowania, których dotyczy problem, natychmiast po zatwierdzeniu.

Poprawki dla usterek o niższej ważności należy wdrożyć we wszystkich pierścieniach zgodnie z planem.

Podjąć klucza

Każdy zespół chce szybko dostarczać aktualizacje i w najwyższej możliwej jakości. Dzięki odpowiednim rozwiązaniom dostarczanie może być produktywną i bezbolesną częścią cyklu DevOps.

• Wdrażanie często.
• Pozostań zielony przez cały przebieg.
• Używaj spójnych narzędzi wdrażania w programowaniu, testowaniu i środowisku produkcyjnym.
• Użyj platformy ciągłego dostarczania, która umożliwia automatyzację i autoryzację.
• Postępuj zgodnie z bezpiecznymi praktykami wdrażania.

Następne kroki

Dowiedz się, jak flagi funkcji pomagają kontrolować narażenie nowych funkcji na użytkowników.