Jak ograniczyć niekontrolowany rozrost oprogramowania
Trzy oznaki niekontrolowanego rozrostu oprogramowania i strategie zaradcze
Andrew Boyagi
Starszy ewangelista
Model monolityczny szybko zanika. Niezliczone firmy na całym świecie stawiają obecnie w przypadku tworzenia oprogramowania na luźno powiązaną architekturę. Rozproszone, autonomiczne zespoły dzielą monolityczne aplikacje na kolekcje komponentów, takich jak mikrousługi.
Dlaczego? Luźno powiązana architektura ułatwia skalowanie wydajności i odporności oprogramowania przy jednoczesnym zmniejszeniu ryzyka i skróceniu czasu wdrażania nowych funkcji aplikacji. Korzyści nie ograniczają się do samego oprogramowania. Luźno powiązana architektura umożliwia zespołom pracę we własnym tempie i częste wprowadzanie zmian, co jest korzystne dla użytkowników. Autonomiczne zespoły, które tworzą oprogramowanie z zastosowaniem luźno powiązanej architektury, są bardziej zadowolone, zaangażowane i wydajne.
Jednak nowe sposoby pracy pociągają za sobą nowe wyzwania. Tworząc dynamiczne i skalowalne środowisko, w którym poszczególne komponenty powstają niezależnie od siebie, zwiększa się złożoność, dając początek nowemu rodzajowi wyzwania, jakim jest niekontrolowany rozrost oprogramowania.
Wypróbuj Compass bezpłatnie
Ulepsz środowisko programistyczne, skataloguj wszystkie usługi i popraw kondycję oprogramowania.
Co to jest nadmierna rozbudowa oprogramowania?
Nadmierna rozbudowa oprogramowania ma miejsce, gdy liczba aplikacji lub komponentów oprogramowania w środowisku szybko rośnie i zmienia się, znacznie zwiększając złożoność i powodując niepowodzenie tradycyjnych metod zarządzania oprogramowaniem. Ten scenariusz często występuje wraz ze wzrostem tempa w rozproszonej architekturze oprogramowania.
Modernizacja nawet jednej monolitycznej aplikacji prawdopodobnie zaowocuje setkami mikrousług zarządzanych przez wiele zespołów, które niezależnie i często wydają nowe funkcje do produkcji. Rozszerzenie tego na portfel aplikacji potencjalnie oznacza wprowadzenie tysięcy mikrousług w wielu zespołach programistycznych. Nic dziwnego, że tradycyjne sposoby zarządzania nawet niewielkim portfelem aplikacji raczej nie doprowadzą do długoterminowego sukcesu. Na drodze Atlassian ku tysiącom mikrousług, które dziś leżą u podstaw naszych produktów, odkryliśmy, że okiełznanie nadmiernej rozbudowy oprogramowania było kluczem do uwolnienia potencjału luźno powiązanej architektury i autonomicznych zespołów.
materiały pokrewne
Porównanie mikrousług z architekturą monolityczną
POZNAJ ROZWIĄZANIE
Ulepsz swoje środowisko programistyczne dzięki narzędziu Compass
Objawy niekontrolowanego rozrostu oprogramowania mogą być początkowo trudne do rozpoznania. Może zaczynać się od drobnych uciążliwości, które są pomijane ze względu na wyższe priorytety. Jednak brak kontroli nad tym zjawiskiem może spowodować, że zespoły programistów będą miały większe obciążenie poznawcze, zmniejszy się ich zaangażowanie, a korzyści wynikające z architektury luźno powiązanej zostaną zaprzepaszczone. Jak mówi chińskie przysłowie: „Najlepszy moment na posadzenie drzewa był 20 lat temu. Drugi najlepszy moment jest teraz”. Przyszły sukces zależy od powstrzymania niekontrolowanego rozrostu oprogramowania, zanim stanie się on problemem.
Poniżej opisujemy trzy oznaki nadmiernej rozbudowy oprogramowania i sposoby opanowania chaosu poprzez tworzenie innowacyjnego i dynamicznego środowiska, które uwalnia potencjał każdego zespołu.
Przeglądy po incydentach wskazują zmiany na nadrzędnym poziomie jako przyczynę źródłową
Wczesnym objawem nadmiernej rozbudowy oprogramowania są wielokrotne przeglądy po incydentach (PIR) wskazujące zmiany na nadrzędnym poziomie jako przyczynę źródłową incydentu. Rosnąca liczba mikrousług i zwiększenie ilości zmian w środowisku mogą nadwyrężyć istniejące normy dotyczące współpracy programistów i koordynacji zmian. Nawet niewielki wzrost częstotliwości zmian z miesięcznego na tygodniowy dla jednej zmodernizowanej aplikacji może skutkować 100-krotnym wzrostem wydań miesięcznie. Nic dziwnego, że programiści muszą dostosować sposób współpracy. Incydenty są bardziej prawdopodobne w produkcji, gdy normy współpracy programistów nie skalują się w szybko zmieniającym się środowisku.
Opracowanie nieinwazyjnego sposobu, aby programiści byli świadomi zmian na nadrzędnym i podrzędnym poziomie, to świetny sposób na okiełznanie rozrastania się oprogramowania. W Atlassian korzystamy z Compass — portalu dla programistów, który pomaga zespołom poruszać się po architekturach rozproszonych — aby wysyłać do zespołów programistycznych powiadomienia w aplikacji o najważniejszych zmianach w usługach zarówno na nadrzędnym, jak i podrzędnym poziomie. Potwierdzenie tego powiadomienia sygnalizuje inicjatorowi zmiany, że zespoły odpowiedzialne za usługi zależne wiedzą o zmianie. Daje to możliwość współpracy przy zmianie, jeśli spodziewane są jakiekolwiek problemy, zmniejszając prawdopodobieństwo niezamierzonego wpływu na produkcję. Ponieważ incydenty mają miejsce w dynamicznym środowisku, współpraca programistów podczas incydentu ma kluczowe znaczenie dla szybkiego przywracania usług.
W przypadku analiz po incydencie, w których przyczyną źródłową są zmiany na nadrzędnym poziomie, często zdarza się, że na czas przywrócenia usług wpływa czas potrzebny do zidentyfikowania problematycznej zmiany na nadrzędnym poziomie, a także zespołu lub osoby, która jest właścicielem usługi. Logicznie rzecz biorąc, skrócenie czasu potrzebnego na zidentyfikowanie problematycznej zmiany na nadrzędnym poziomie skraca średni czas przywrócenia usługi (MTTR). Jest to trudniejsze w luźno powiązanej architekturze, gdzie usługi mają rozbudowaną hierarchię zależności, a przyczyna źródłowa incydentu może znajdować się w dowolnym miejscu stosu. W tradycyjnym układzie osoby reagujące na incydenty przeczesują dzienniki lub rejestry zmian, aby zidentyfikować zmianę, która mogła spowodować incydent. W dynamicznym środowisku jest to jak rozbieranie mrowiska w celu znalezienia mrówki, która Cię ukąsiła.
W Atlassian używamy kanału aktywności w narzędziu Compass, aby zmniejszyć MTTR. Pokazuje on wszystkie zdarzenia dla systemów nadrzędnych wraz z danymi zespołu, który jest ich właścicielem. To znacznie skraca czas segregowania poprzez wspieranie współpracy programistów podczas incydentu. Incydenty będą się zdarzać, ale zidentyfikowanie w odpowiednim czasie zmiany w systemie nadrzędnym jako przyczyny źródłowej incydentu jest kluczowe dla zapewnienia minimalizacji wpływu i szybkiego przywrócenia usług.
Kanał aktywności w narzędziu Compass pokazuje wszystkie zdarzenia dla systemów nadrzędnych, skracając czas segregacji podczas incydentu.
Wydajność zespołu jest wysoka, ale brakuje wyników pracy
Przejście w kierunku luźno powiązanej architektury jest jednym z kluczowych składników produktywności i szczęścia zespołu — zdolności do niezależnego poruszania się z dużą autonomią. Niekontrolowana nadmierna rozbudowa oprogramowania może odwrócić niektóre z tych korzyści, powodując, że zespół jest zajęty, ale nieproduktywny i nieszczęśliwy. Częstą skargą podczas rozmów z zespołami programistów jest „wszystko działa dobrze, dopóki nie musimy zaangażować się w pracę innego zespołu”. Jest to spotęgowane, gdy problemem staje się niekontrolowana rozbudowa oprogramowania. Szybko rozwijające się i zmieniające środowisko zmniejsza zdolność programistów do monitorowania, kogo należy zaangażować w zależności na nadrzędnym lub podrzędnym poziomie, co prowadzi do ostatecznego spowolnienia i nagromadzenia frustracji zespołów, które próbują dostarczać produkty w odpowiednim tempie.
Hipotetycznie rzecz ujmując, powiedzmy, że zespół alfa i zespół beta mają co tydzień identyczną liczbę zgłoszeń i punktów historyjki przeniesionych do kategorii „gotowe” w Jira. Zespół alfa poświęca 90% swojego wysiłku na wysyłanie nowych funkcji do produkcji, natomiast zespół beta poświęca 30% na nowe funkcje i 70% na wypracowanie sposobu współpracy z wieloma usługami nadrzędnymi, od których jest zależny. Rezultaty pracy obu zespołów są na tym samym poziomie, ale tylko alfa może być uznany za produktywny. Nadmierna rozbudowa oprogramowania zwiększa potrzebę współpracy pomiędzy zespołami. Zidentyfikowanie inteligentnych sposobów zaangażowania autonomicznych zespołów na życzenie jest kluczem do uwolnienia potencjału luźno powiązanego środowiska.
W szybko rozwijającym się i dynamicznym środowisku zdolność do samoobsługi informacyjnej jest ważna dla produktywności i szczęścia zespołu. Jednym ze sposobów na osiągnięcie tego celu jest wdrożenie scentralizowanego katalogu komponentów oprogramowania ze zdecentralizowanym zarządzaniem; jest to scentralizowany katalog, w którym każdy zespół jest odpowiedzialny za tworzenie i aktualizację usług, których jest właścicielem. Tradycyjne środowiska z reguły mają scentralizowany katalog, który jest zarządzany przez konkretny zespół lub stanowisko. Jednak takie rozwiązanie może nie nadążać za tempem zmian w środowisku rozproszonym, co powoduje, że zespoły tworzą nieoficjalne zasady na temat tego, kogo i jak należy angażować. W Atlassian odkryliśmy, że zdecentralizowane podejście zmniejsza niewidoczny i zmarnowany wysiłek zespołów, poprawia możliwości samoobsługi i tworzy środowisko zaangażowania na życzenie. Okiełznanie nadmiernej rozbudowy oprogramowania poprzez umożliwienie samoobsługi w zakresie informacji o zależnościach nadrzędnych i podrzędnych jest świetnym sposobem na zwiększenie produktywności zespołu, a także na dodatkowe efekty w postaci szczęścia i zaangażowania zespołu.
Compass stanowi centralną lokalizację informacji specyficznych dla programistów na temat komponentów oprogramowania, które posiadają i od których są zależni.
Zarządzanie zmianami staje się wąskim gardłem
Innym kluczowym objawem nadmiernej rozbudowy oprogramowania jest sytuacja, w której funkcje nadzoru, takie jak zarządzanie zmianami i cyberbezpieczeństwo, w coraz większym stopniu stają się wąskim gardłem dla dostarczania zmian do systemów produkcyjnych. Funkcje te odgrywają kluczową rolę w spełnianiu standardów organizacyjnych i oczekiwań przed wdrożeniem zmian do produkcji. Stają się one jednak mniej skuteczne, gdy w grę wchodzi nadmierna rozbudowa oprogramowania. W środowisku, w którym występuje zjawisko nadmiernej rozbudowy oprogramowania, funkcje nadzoru ulegają stopniowemu przeciążeniu wraz ze wzrostem tempa zmian, tworząc backlog zmian i wniosków do przeglądu, co opóźnia wdrożenia do produkcji. Raport Stan DevOps w 2022 wykazał, że 56 procent respondentów badania uważa, że procesy zapewnienia bezpieczeństwa oprogramowania w ich organizacji spowalniają proces rozwoju.
W idealnej sytuacji praktyki zapewnienia bezpieczeństwa są wbudowane w procesy rozwoju, ale w rzeczywistości wiele organizacji zleca pracownikom przeglądanie zmian przed wdrożeniem produkcyjnym. Nie jest to efektywne przy skali wymaganej w środowisku rozproszonym. Oprócz spowolnienia zdolności organizacji do dostarczania zmian, może to powodować tarcia między zespołami programistów a osobami odpowiedzialnymi za zapewnienie spełnienia standardów organizacyjnych.
W środowisku, w którym występuje zjawisko nadmiernej rozbudowy oprogramowania, kluczowe jest zapewnienie dużej szybkości działania przy jednoczesnym osiągnięciu pożądanych standardów organizacyjnych na dużą skalę. Zautomatyzowane lub częściowo zautomatyzowane karty wyników są świetnym sposobem na komunikowanie standardów organizacyjnych i zapewniają nienachalny sposób kontroli zgodności w całym środowisku. W Atlassian używamy narzędzia Compass do ustalania organizacyjnych standardów jakości i oczekiwań — karta wyników dla każdego komponentu oprogramowania zapewnia organizacji przejrzystość w zakresie zgodności. Zespoły i liderzy inżynierii mogą dodawać standardy specyficzne dla danego produktu do kart wyników, co daje pełny obraz organizacyjnych oczekiwań dotyczących jakości i statusów dla każdego w organizacji. Jest to istotna zmiana w nadzorze i kontroli zgodności na końcu cyklu dostarczania na wczesne ustalanie oczekiwań i umożliwienie zespołom ich spełnienia w całym procesie rozwoju. Zespoły nadzorujące mogą ustalać oczekiwania w dynamicznym środowisku, natomiast zespoły dostarczające oprogramowanie mają możliwość zrozumienia i spełnienia wymagań w trakcie cyklu dostarczania. Ponieważ wpływ nadmiernej rozbudowy oprogramowania może być szkodliwy zarówno dla zespołów zajmujących się dostarczaniem oprogramowania, jak i dla zespołów nadzorujących, karty wyników dają możliwość opanowania nadmiernej rozbudowy.
Karta wyników Compass jest używana do zrozumienia kondycji komponentów oprogramowania w odniesieniu do zestawu zdefiniowanych oczekiwań.
Podsumowując…
Nie ma cudownego sposobu na okiełznanie nadmiernej rozbudowy oprogramowania. Jednak długoterminowy sukces zależy od wczesnego zidentyfikowania i zajęcia się skutkami tego zjawiska. Niektóre z wczesnych oznak nadmiernej rozbudowy oprogramowania obejmują liczne incydenty spowodowane przez zmiany na nadrzędnych lub podrzędnych poziomach, zajęte zespoły, które nie realizują swoich celów, a także wąskie gardła w nadzorze. Najlepszym sposobem na zidentyfikowanie nadmiernej rozbudowy oprogramowania jest rozmowa z programistami i zrozumienie wyzwań, przed którymi stoją.
Firma Atlassian opracowała narzędzie Compass, aby pomóc opanować nadmierną rozbudowę oprogramowania poprzez zarządzanie złożonością rozproszonych architektur w miarę ich skalowania. Jest to rozszerzalna platforma środowiska programistycznego, która w centralnej lokalizacji z możliwością wyszukiwania łączy wszystkie niepowiązane informacje o wynikach prac inżynierskich i współpracy zespołowej.
Udostępnij ten artykuł
Następny temat
Zalecane lektury
Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.