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

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.

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.

Oferty pracy z

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ą.

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