Jak ograniczyć niekontrolowany rozrost oprogramowania

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.

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.

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.