Niewidzialny dług techniczny. Jak walczyć z przeciwnikiem, którego nie widać?

Czy Twoja aplikacja teraz działa? Czy klienci są z niej zadowoleni? Jeśli musisz to sprawdzić, bo nie jesteś pewien, nie martw się, ten artykuł może chwilę poczekać. Zastanówmy się jednak, kiedy możemy powiedzieć, że system informatyczny działa. Wbrew pozorom nie jest to takie proste pytanie. Jeszcze trudniej określić, czy klienci korzystający z aplikacji są zadowoleni. W tym artykule postaram się zwrócić uwagę na aspekty procesu wytwarzania oprogramowania, o których nam wszystkim zdarza się zapominać.

dług techniczny

Michał Malec. DevOps Engineer w IDEMIA. Swoją przygodę w IT rozpoczął od stanowiska Junior Java Developera. Szybko jednak zaczął interesować się chmurami obliczeniowymi, kontenerami, a także uruchamianiem aplikacji. Od tego czasu jego stanowisko zmieniło się na DevOps Engineer, a to czym zajmuję się na co dzień głównie dotyczy aplikacji uruchomionych w chmurze AWS. W swojej pracy miał okazję uczestniczyć w licznych integracjach z klientami, a także wdrożeniach wielu systemów. Wielokrotnie zajmował się opracowywaniem infrastruktury oraz rozwiązań dostosowanych do niezawodnego działania w publicznej chmurze obliczeniowej.


Po co nam te aplikacje?

Czy zastanawialiście się kiedyś, dlaczego tworzymy tak wiele aplikacji? Oczywiście odpowiedź jest prosta – jeśli jest popyt, jest też podaż. Wymagania użytkowników rosną, coraz więcej chcemy załatwiać przez Internet, a najchętniej za pośrednictwem telefonu. Nowe potrzeby sprawiają, że powstaje coraz więcej sklepów internetowych, aplikacji mobilnych dla sklepów stacjonarnych, aplikacji bankowych, komunikatorów itp.
W dzisiejszym świecie, każda firma powinna posiadać porządną stronę internetową oraz aplikację mobilną. Cyfrowa rewolucja to nie tylko sklepy.

W telefonie chcemy mieć dokumenty, bilety, certyfikaty, a nawet recepty. Wszystko chcielibyśmy robić szybko. Po co czekać na dostarczenie karty SIM, skoro elektroniczną kartę eSIM możemy mieć od razu w telefonie? Po co czekać na wyprodukowanie karty płatniczej, skoro w ciągu kilku sekund i tę kartę możemy mieć w telefonie? Wszystko to jest szczególnie dobre dla nas, czyli osób związanych z wytwarzaniem oprogramowania. Jednak duża liczba aplikacji, prowadzi do dużej konkurencji.

W naszym świecie, użytkownik niezadowolony z oprogramowania szybko zmieni je na inne. Ryzyko jest takie, że zmieniając oprogramowanie zmieni też swój bank, sklep, w którym codziennie robi zakupy, czy nawet lekarza – to jest właśnie sedno problemu. Skoro systemy informatyczne coraz częściej są nam potrzebne do życia, to zmiana systemu może zmienić nasze przyzwyczajenie. Jedna firma na tym straci, a inna zyska.

#TODO #FIXME, czyli dług techniczny

Tworząc aplikacje czasem zdarza się zostawiać coś na później. Wiele razy widziałem w kodzie (a nawet w konfiguracji) aplikacji popularne „TODO” oraz „FIXME”. Sam też wielokrotnie używałem tych skrótów, bo przeważnie nie jest to coś złego. Jesteśmy świadomi, że pewien fragment kodu wymaga poprawek, udoskonaleń lub innych modyfikacji, ale podejmujemy decyzję o odłożeniu ich na później. Przecież nie wszystko można zrobić natychmiast. Czasem w ten sposób oznaczamy brakujący test lub dokumentację. Wszystko to prowadzi do powstawania długu technicznego.

Dług ten to nie tylko „TODO” oraz „FIXME”, składa się na niego wiele innych rzeczy. Jedną z nich są przestarzałe wersje bibliotek. Przeciętny projekt zawiera wiele zewnętrznych zależności. Każda z nich żyje własnym życiem, a codziennie pojawiają się nowe wersje. Niestety śledzenie tych wszystkich zmian oraz poprawne dokonywanie aktualizacji wymagałoby zatrudnienia dodatkowej osoby zajmującej się właśnie tym zagadnieniem. Dlatego z reguły wersje bibliotek aktualizowane są tylko, gdy naprawdę jest taka potrzeba. Takie podejście może prowadzić do wykorzystywania kodu zawierającego podatności na ataki oraz błędy naprawione w nowszych wersjach. Dług techniczny to także kod, do którego nie zostały utworzone testy lub powstały niewłaściwe testy. W tej samej kategorii znajdziemy skomplikowany kod aplikacji, w którym łatwo o pomyłkę.

Cały ten dług ma jedną wspólną cechę. Najczęściej jesteśmy jego świadomi lub chociaż byliśmy jego świadomi w momencie, gdy został zaciągnięty. Jeśli nawet ta świadomość nie jest bezpośrednia, to istnieją narzędzia, które wskazują miejsca występowania długu technicznego w kodzie. Świadomość ta pozwala nam rozsądnie zarządzać ryzykiem i z czasem spłacać zaciągnięty kredyt poprzez poprawianie aplikacji. Jeśli nie uda nam się dokonać poprawki przed wystąpieniem usterki, czyli np. nie utworzymy testu przed realną awarią, to świadomość istnienia długu technicznego może przyspieszyć rozwiązywanie problemu.

Co nam umyka? Niewidzialny dług

Prawdziwym problemem jest to, czego nie widzimy, to o czym zapominamy, to o czego istnieniu nawet nie wiemy. Jest to niewidzialny dług techniczny lub inaczej ciemny dług techniczny. W skrócie, dług ten wynika z nieustannie rosnącego poziomu skomplikowania projektu. Ma na niego wpływ rosnąca liczba osób zaangażowanych w projekt, a także zwiększająca się liczba wykorzystywanych komponentów. Produkcyjne wdrożenie systemu informatycznego to nie tylko aplikacja. Aplikację musimy gdzieś uruchomić, a więc potrzebne są serwery. Zazwyczaj będziemy też potrzebowali bazy danych. Wszystko działa w sieci komputerowej, czyli potrzebne są urządzenia sieciowe, przewody itp. Gdy zdecydujemy się na uruchomienie aplikacji w chmurze obliczeniowej kilka problemów nam odpadnie, ale pojawią się nowe.

Korzystając z serwisów w chmurze musimy umieć je obsługiwać i konfigurować. Aplikacje zazwyczaj generują logi, często też metryki obrazujące działanie systemu. Ze względów bezpieczeństwa w wielu przypadkach będzie nam potrzebny Web Application Firewall. Ze względu na wydajność i dostępność aplikacji będziemy potrzebowali Load Balancerów, a może także proxy. Część aplikacji generują dane, które muszą być poddane dalszej analizie. Stan działania aplikacji chcielibyśmy wizualizować w formie pulpitów. Prawdopodobnie będziemy też korzystali z konteneryzacji.

Okazuje się, że uruchomienie systemu informatycznego poza samą aplikacją będzie wymagało skorzystania z technologii i rozwiązań takich jak: Kubernetes, Docker, Helm, Grafana, Loki, Prometheus, Splunk, AWS, GCP, Azure, Nginx, HAProxy, Linux, sieci komputerowe, serwery, WAF, Jenkins, SQL, NoSQL, DNS, RabbitMQ, Redis, Kafka, Terraform oraz wiele, wiele innych, naprawdę jeszcze wiele można byłoby tutaj dopisać. Połączenie tych wszystkich elementów najczęściej prowadzi do nieoczekiwanych skutków. Jednak to jeszcze nie wszystko. Realny system informatyczny, to także użytkownicy, którzy z niego korzystają oraz operatorzy, którzy czuwają nad jego działaniem.

Poza tym musimy jeszcze uwzględnić procedury i dokumentację opisujące sposób działania systemu i sposób postępowania w przypadku nieoczekiwanych zdarzeń. W pewnych sytuacjach będziemy mieli również do czynienia z niechcianymi użytkownikami, czyli takimi którzy chcą włamać się do naszej aplikacji. Żadne testy nie będą w stanie zasymulować najbardziej pechowej sytuacji, która może się wydarzyć w przypadku prawdziwej aplikacji uruchomionej produkcyjnie. Do najbardziej nieoczekiwanej i jednocześnie najpoważniejszej awarii dojdzie wskutek złożenia się wielu z wymienionych wyżej czynników.

ZOBACZ TEŻ:  Czy sortowanie produktów jest potrzebne?

Przecież nikt nie przewidzi, że zmiana obostrzeń w czasie pandemii spowoduje zwiększoną sprzedaż, co doprowadzi do większej liczby logów generowanych przez aplikację. Większa liczba logów spowoduje zwiększone zapotrzebowanie na zasoby aplikacji, która te logi analizuje. W efekcie inna aplikacja będzie miała mniej dostępnych zasobów i przestanie działać prawidłowo. Sytuację tę zauważy operator i postara się przywrócić system do pełnej sprawności na podstawie procedury. Niestety ta właśnie procedura nie była aktualna,
a działania operatora doprowadziły do całkowitej awarii systemu. To właśnie efekt występowania niewidzialnego długu technicznego.

Połączenie ludzi, procedur, środowiska, aplikacji oraz różnych technologii doprowadziło do awarii. Jest to zdarzenie, którego nikt nie analizował na etapie wytwarzania oprogramowania. Pojawia się teraz naturalne pytanie – Jak się przed tym ochronić? Co zrobić, żeby nasza aplikacja była odporna na coś czego nie widać? Czy w ogóle możemy coś zrobić?

Dlaczego?

To bardzo ważne pytanie. Warto zastanawiać się, czemu coś robimy, a czegoś innego nie. Dlatego zanim przeanalizujemy, jak poradzić sobie z niewidzialnym długiem technicznym zastanówmy się, dlaczego w ogóle powinniśmy próbować sobie z nim poradzić. Każda awaria jest zjawiskiem niepożądanym. Niezależnie od przyczyny będzie to coś czego chcielibyśmy uniknąć. Awaria, która powstała ze względu na występowanie niewidzialnego długu technicznego będzie niespodziewana, zaskakująca i trudna do naprawienia. Warto podkreślić, że awaria, to nie tylko sytuacja, w której system przestaje działać całkowicie. Awaria ma miejsce również, gdy niedostępna jest część funkcjonalności aplikacji.

Co więcej, awaria to także sytuacja, w której czas procesowania zapytań do aplikacji został wydłużony. W dzisiejszym świecie nikt nie będzie czekał więcej niż kilka sekund na załadowanie się strony. Jeśli taka sytuacja powtórzy się kilka razy, to najprawdopodobniej zrezygnujemy z korzystania z tego systemu i skorzystamy z innego. Takie niezbyt widoczne awarie są jeszcze trudniejsze do wykrycia i tym bardziej do naprawienia. Przejdźmy teraz do rzeczy najważniejszej. Niedziałająca aplikacja w prosty sposób będzie prowadziła do strat finansowych. Z jednej strony firma poniesie koszt przywrócenia systemu do sprawności.

Z drugiej strony, gdy aplikacja nie działa, firma nie może na niej zarabiać, czyli np. nie może prowadzić sprzedaży w sklepie internetowym. W przypadku części systemów informatycznych niesprawność może powodować konieczność zapłaty kary określonej w umowie pomiędzy firmami. W każdym z przypadków firma ucierpi, a poza pieniędzmi, straci również swój wizerunek. Warto też dodać, że powinno nam po prostu zależeć na tworzeniu porządnych, wysokodostępnych systemów, które nie będą ulegały częstym awariom.

Jak uchronić się przed niewidzialnym długiem technicznym?

Teraz, gdy już wiesz czym jest niewidzialny dług techniczny możesz spróbować sobie z nim poradzić. Pokonanie go w całości będzie bardzo trudne, ale możemy chociaż spróbować znacznie zminimalizować skutki jego występowania.

Wszystko zaczyna się już na etapie projektowania systemu informatycznego. Zazwyczaj na tym etapie zastanawiamy się nad architekturą aplikacji, nad API, nad funkcjonalnościami itp. Często jednak umyka nam jedna rzecz. Już w tym miejscu warto pomyśleć o tym jak aplikacja będzie uruchomiona. Warto zoptymalizować sposób uruchomienia do wymagań konkretnej aplikacji. Jest to szczególnie ważne w przypadku chmury obliczeniowej, w której dostępne jest wiele serwisów. Wybór i konfiguracja właściwych może być kluczem do sukcesu.

Jeśli odłożymy te zadania na później, to zabraknie nam czasu na właściwą analizę. Wybór jest bardzo szeroki, a jeśli wybierzemy źle to możemy przyczynić się do awarii. Znaczna część awarii systemów informatycznych związana jest z infrastrukturą. Dlatego w tym samym czasie, gdy powstaje kod aplikacji powinniśmy opracowywać infrastrukturę i jak najszybciej przeprowadzać testy na środowisku zbliżonym do produkcyjnego. Bardzo ciężko poradzić sobie z problemami wynikającymi z niewłaściwych lub brakujących procedur i dokumentacji. Zazwyczaj te dwie rzeczy tworzymy niechętnie, a do tego szybko się one dezaktualizują.

Najłatwiej byłoby powiedzieć, że powinniśmy to robić i już. Jednak jest coś innego, co również może pomóc, gdy nadejdzie awaria. Aplikacja powinna być wyposażona w odpowiednie rozwiązania pozwalająca na monitorowanie jej działania. Metryki i utworzone na ich podstawie pulpity mogą być najlepszym źródłem informacji o pojawieniu się problemu, a także miejscu jego występowania. Czas poświęcony na przygotowanie narzędzi umożliwiających dokładne monitorowanie aplikacji przez zespół utrzymaniowy może uchronić nas przed wieloma awariami. Wczesne zauważanie nadchodzącego problemu umożliwi jego naprawę przed wystąpieniem poważnej awarii.

Monitoring to także cenne źródło wiedzy o zachowaniu aplikacji w czasie niewłaściwego działania. Poza tym, skąd mamy wiedzieć, czy nasz system żyje, jeśli nie znamy jego parametrów życiowych. Ciężko również poradzić sobie z problemami związanymi z ludźmi. Na użytkowników nie mamy za dużego wpływu, ale możemy wpłynąć na osoby zaangażowane w tworzenie oraz utrzymywanie aplikacji. Najważniejsza rzecz leży częściowo po stronie pracownika, a częściowo po stronie pracodawcy, a jest nią stałe podnoszenie kompetencji. Wewnętrzne szkolenia dotyczące produktów firmy są najlepszą okazją do wymiany wiedzy niezbędnej w celu obsługi aplikacji.

Dodatkowo stałe podnoszenie poziomu wiedzy pomoże w wyborze właściwych komponentów zewnętrznych dla konkretnej aplikacji. Natomiast w przypadku awarii umożliwi szybsze rozwiązanie problemu. Jest jeszcze jedna rzecz, którą warto zrobić, choć nie jest ona łatwa.

Chaos Engineering, czyli symulacja awarii

Chaos Engineering to zbiorowa nazwa testów mających za zadanie przetestowanie realnej aplikacji w jej naturalnym środowisku podczas wystąpienia niespodziewanej awarii. Ćwiczenia Chaos Engineering testują zarówno aplikację, jak i ludzi, procesy, dokumentację oraz infrastrukturę. Polegają na wywołaniu niezaplanowanej awarii (np. wprowadzeniu zakłócenia w ruchu sieciowym), a następnie obserwowaniu reakcji. Osoba przeprowadzająca ćwiczenie notuje zachowanie ludzi, a także wpływ awarii na aplikację. Po zakończonym ćwiczeniu dokonuje się analizy przeprowadzonych działań oraz poprawia to co zawiodło.

W ten sposób dzięki symulowanej awarii możemy chociaż częściowo przygotować się na to, co nadejdzie w przyszłości. Nie wszystko da się zrobić od razu. Nie naprawimy wszystkich problemów w naszych aplikacjach jednego dnia. Teraz gdy już wiesz o istnieniu niewidzialnego długu technicznego możesz z nim walczyć. Zrób coś, choćby najprostszą rzecz. Popraw nieaktualną dokumentację. Utwórz procedurę opisującą jak poradzić sobie z jakimś problemem. Przygotuj nowy pulpit obrazujący działanie aplikacji. Może to właśnie Twoja zmiana, choćby bardzo mała, uchroni aplikację przed awarią.


najwięcej ofert html

Zdjęcie główne artykułu pochodzi z unsplash.com.

Zapraszamy do dyskusji

Patronujemy

 
 
More Stories
Jak wygląda praca w bankowości? Devdebata cz.2