Twój system działa świetnie. Dopóki pracuje osoba, która wie, dlaczego.
Firma ma system, który powstawał przez siedem lat. Działa. Obsługuje klientów. Łączy się z innymi systemami. Realizuje procesy, bez których firma właściwie nie mogłaby normalnie funkcjonować.
Przez te siedem lat przy projekcie pracowało pięciu programistów. Do tego dwóch freelancerów i jedna agencja. Część dokumentacji znajduje się w Confluence, część na Google Drive, część w ticketach. Gdzieś jest jeszcze stary dokument dotyczący jednej z integracji. A kiedy ktoś pyta, dlaczego konkretny fragment systemu działa właśnie w taki sposób, odpowiedź brzmi: "Chyba pamiętał to Michał."
Michał odszedł trzy lata temu.
I właśnie wtedy zaczyna się prawdziwy problem.
Nie dlatego, że system jest źle napisany. Nie dlatego, że nagle przestał działać. Problem polega na tym, że firma przestała posiadać pełną wiedzę o swoim własnym systemie.
System działa, ale firma może go nie kontrolować
To jedna z najbardziej niedocenianych form długu technologicznego.
Kiedy mówimy o długu technologicznym, zwykle myślimy o starym kodzie, nieaktualnych bibliotekach, błędach architektonicznych, braku testów albo rozwiązaniach, które kiedyś były szybkie, ale dziś utrudniają rozwój.
Tymczasem istnieje jeszcze inny rodzaj długu. Dług wiedzy.
Powstaje wtedy, gdy system jest zależny od informacji, których nie ma w dokumentacji, repozytorium, procedurach ani w organizacji, tylko w głowach konkretnych osób.
I dopóki te osoby są dostępne, wszystko może wyglądać normalnie.
Problem pojawia się przy zmianie zespołu, odejściu programisty, zakończeniu współpracy z software house'em, awarii serwera, zmianie administratora albo konieczności szybkiego wdrożenia nowego rozwiązania.
Nagle okazuje się, że firma ma kod, ale nie ma wiedzy.
Ma serwer, ale nie ma pewności, kto ma dostęp.
Ma integrację, ale nie wiadomo, na jakim koncie została założona.
Ma dokumentację, ale nie wiadomo, która jej wersja jest aktualna.
Ma proces, ale nie wiadomo, dlaczego został zaprojektowany właśnie tak.
I wtedy bardzo szybko pojawia się pytanie: kto właściwie jest właścicielem tego systemu?
Bus factor, czyli co się stanie, jeśli zniknie jedna osoba?
W świecie IT funkcjonuje pojęcie bus factor. Upraszczając, oznacza ono liczbę osób, których niedostępność może spowodować, że zespół przestaje być w stanie skutecznie rozwijać lub utrzymywać projekt.
Nie chodzi oczywiście o dosłowne zdarzenie. To sposób myślenia o koncentracji wiedzy.
Jeżeli tylko jedna osoba wie, jak działa krytyczna integracja, bus factor dla tej wiedzy wynosi jeden.
Jeżeli tylko jeden administrator ma dostęp do produkcji, bus factor wynosi jeden.
Jeżeli tylko jeden człowiek wie, dlaczego system wykonuje określony proces każdej nocy, bus factor może wynosić jeden.
Jeżeli firma współpracuje z zewnętrznym software house'em, a po stronie klienta nikt nie rozumie architektury rozwiązania, powstaje jeszcze większy problem - wiedza może znajdować się poza organizacją.
To nie oznacza, że każda firma musi mieć pięciu ekspertów od każdego fragmentu systemu.
Chodzi o coś znacznie prostszego: firma powinna wiedzieć, gdzie znajduje się krytyczna wiedza i czy potrafi ją odzyskać bez konkretnej osoby.
Kod mówi, jak. Nie zawsze mówi, dlaczego.
Programista może przeczytać kod i zrozumieć, co robi dana funkcja.
Nie zawsze będzie jednak wiedział, dlaczego została napisana właśnie w ten sposób.
To ogromna różnica.
Można znaleźć fragment odpowiedzialny za wysyłanie danych do zewnętrznego systemu. Można przeanalizować endpoint, parametry, autoryzację i obsługę błędów.
Ale kod niekoniecznie odpowie na pytania:
- Dlaczego dane wysyłamy o 2:00 w nocy?
- Dlaczego ten konkretny status jest pomijany?
- Dlaczego po błędzie system ponawia próbę dokładnie trzy razy?
- Dlaczego jedna wartość jest przeliczana przed wysłaniem?
- Dlaczego nie można zmienić kolejności tych operacji?
- Dlaczego ta integracja korzysta z konkretnego konta?
Odpowiedź może znajdować się w historii projektu, dawnym tickecie, mailu sprzed sześciu lat albo - co gorsza - wyłącznie w pamięci człowieka, który już nie pracuje w firmie.
Dlatego dobra dokumentacja nie powinna być wyłącznie instrukcją "co kliknąć".
Powinna przechowywać również kontekst i decyzje.
Największym problemem może być integracja, o której nikt już nie pamięta
Nowoczesny system prawie nigdy nie działa całkowicie samodzielnie.
Łączy się z systemem ERP. CRM. Bramką płatniczą. Dostawcą SMS. Systemem kurierskim. API partnera. Usługą chmurową. Platformą analityczną. Systemem księgowym. Mechanizmem autoryzacji.
Każde takie połączenie jest częścią technologicznego łańcucha.
I każda część tego łańcucha może mieć własnego właściciela, konto, klucz API, certyfikat, umowę, limit, wersję API oraz cykl życia.
Po kilku latach nikt może już nie pamiętać, kto zakładał dane konto.
A wtedy wystarczy wygaśnięcie certyfikatu albo zmiana API, żeby system przestał działać.
Jeszcze gorzej, jeżeli firma nie wie nawet, że dana zależność istnieje.
Dlatego w dojrzałym podejściu do systemów coraz większego znaczenia nabiera proweniencja oprogramowania, zarządzanie zależnościami i transparentność łańcucha dostaw oprogramowania. NIST w swoich aktualnych materiałach dotyczących bezpieczeństwa łańcucha dostaw wskazuje m.in. na znaczenie informacji o komponentach, ich pochodzeniu, cyklu życia i zależnościach. SBOM, czyli Software Bill of Materials, jest jednym z narzędzi pozwalających uporządkować wiedzę o tym, z jakich komponentów składa się oprogramowanie.
To nie jest już wyłącznie temat dla zespołu security.
To również temat dla zarządu.
Bo jeżeli firma nie wie, z czego zbudowany jest jej system, trudniej jej ocenić ryzyko, koszt utrzymania i konsekwencje zmian.
Dokumentacja nie jest kosztem. Jest polisą.
W wielu firmach dokumentacja jest traktowana jako coś, co "zrobi się później".
Najpierw funkcjonalność.
Potem wdrożenie.
Potem poprawki.
Potem kolejny projekt.
A dokumentacja?
"Jak będzie czas."
Problem polega na tym, że czas na dokumentację pojawia się zwykle wtedy, kiedy jest już za późno.
Dokumentacja powinna działać jak biznesowe ubezpieczenie. Nie dlatego, że ktoś będzie codziennie ją czytał. Wręcz przeciwnie - oby jak najrzadziej była potrzebna w sytuacji awaryjnej.
Ale kiedy wydarzy się problem, firma powinna mieć możliwość odpowiedzi na podstawowe pytania:
- Jak działa system?
- Z czego się składa?
- Gdzie jest środowisko produkcyjne?
- Kto ma dostęp?
- Jakie są krytyczne integracje?
- Jakie konta i usługi zewnętrzne są wykorzystywane?
- Jakie są zależności?
- Jak wykonywane są backupy?
- Jak wygląda proces wdrożenia?
- Co dzieje się podczas awarii?
- Które elementy są krytyczne dla biznesu?
- Dlaczego kluczowe decyzje architektoniczne zostały podjęte?
- Kto może przejąć utrzymanie systemu?
To nie musi oznaczać setek stron dokumentacji.
Dobra dokumentacja ma być przede wszystkim użyteczna, aktualna i dostępna dla właściwych osób.
"Nie ruszajmy, bo działa" nie zawsze jest złą decyzją
Jest jeszcze jeden bardzo częsty problem.
System działa od lat, więc firma przyjmuje zasadę: "Nie ruszamy. Działa."
I czasami jest to absolutnie rozsądne.
Nie każda stara technologia wymaga natychmiastowej wymiany. Nie każdy starszy fragment kodu trzeba przepisywać. Nie każda biblioteka oznacza katastrofę. Nie każda architektura sprzed kilku lat jest błędna.
Problem zaczyna się wtedy, kiedy "nie ruszajmy" oznacza również:
- "Nie analizujmy."
- "Nie dokumentujmy."
- "Nie sprawdzajmy zależności."
- "Nie pytajmy, kto ma dostęp."
- "Nie sprawdzajmy, czy nadal mamy wszystkie konta."
- "Nie ustalajmy, co się stanie, gdy obecny wykonawca przestanie być dostępny."
Wtedy brak zmian nie jest strategią.
Jest odkładaniem ryzyka.
Czasami najlepszą decyzją techniczną jest rzeczywiście niczego nie przebudowywać.
Ale ta decyzja powinna wynikać z wiedzy o systemie, a nie z braku wiedzy o systemie.
Co powinien obejmować audyt odziedziczonego systemu?
Kiedy firma przejmuje system po innym software house'ie, freelancerze albo wewnętrznym zespole, pierwszym krokiem nie powinno być automatyczne przepisywanie wszystkiego.
Najpierw trzeba zrozumieć, co właściwie zostało przejęte.
Audyt powinien odpowiedzieć przynajmniej na kilka podstawowych obszarów.
Architektura. Jak zbudowany jest system? Jakie są jego główne komponenty? Gdzie znajdują się dane? Jak komunikują się poszczególne elementy?
Kod i repozytoria. Czy firma posiada kompletny kod źródłowy? Czy wiadomo, która gałąź i wersja są produkcyjne? Czy proces budowania i wdrażania jest możliwy do odtworzenia?
Infrastruktura. Gdzie działa produkcja? Jak wygląda środowisko testowe? Kto ma dostęp? Jak wygląda monitoring i backup?
Integracje. Z czym system się komunikuje? Jakie API wykorzystuje? Kto jest właścicielem poszczególnych kont i kluczy?
Zależności. Jakie biblioteki, frameworki i komponenty zewnętrzne są wykorzystywane? Czy są aktualizowane? Czy mają znane problemy bezpieczeństwa? Jak wygląda ich cykl życia?
Proces wdrożeniowy. Czy nowa osoba jest w stanie przygotować, przetestować i wdrożyć zmianę bez telefonu do byłego programisty?
Wiedza. Co znajduje się w dokumentacji, a co nadal istnieje tylko w głowach ludzi?
Ryzyko biznesowe. Co się stanie, jeżeli określony komponent przestanie działać przez godzinę, dzień albo tydzień?
Współczesne podejście do bezpieczeństwa łańcucha dostaw oprogramowania coraz mocniej podkreśla właśnie potrzebę wiedzy o komponentach, dostawcach, zależnościach, ich pochodzeniu i cyklu życia. NIST wskazuje również na znaczenie due diligence wobec dostawców technologii i oceny odporności oraz ryzyka związanego z całym łańcuchem dostaw.
Audyt nie oznacza "napiszmy system od nowa"
To ważne, ponieważ audyt techniczny bywa błędnie utożsamiany z przebudową.
Tymczasem audyt może zakończyć się bardzo prostym wnioskiem: "System jest w porządku. Trzeba tylko uporządkować wiedzę i usunąć kilka ryzyk."
Może się też okazać, że system wymaga modernizacji tylko w jednym obszarze.
Albo że największym problemem nie jest kod, tylko brak dostępu do infrastruktury.
Albo że aplikacja jest dobrze napisana, ale nikt nie ma aktualnej wiedzy o procesie wdrożeniowym.
Albo że wszystko działa, ale firma jest uzależniona od jednego dostawcy zewnętrznego.
Dlatego dobra analiza odziedziczonego projektu powinna odpowiedzieć na pytanie: "Co naprawdę trzeba zmienić, a czego nie trzeba ruszać?"
Dopiero wtedy można podejmować decyzje inwestycyjne.
A co, jeśli zmieniasz software house?
To jeden z momentów, w których problem niewidocznego długu wiedzy wychodzi na jaw.
Firma kończy współpracę z wykonawcą.
Nowy partner otrzymuje repozytorium.
I zaczyna zadawać pytania:
- "Gdzie jest produkcja?"
- "Jak uruchomić projekt lokalnie?"
- "Która wersja jest aktualna?"
- "Do czego służy ten serwis?"
- "Kto posiada konto do tego API?"
- "Co robi ten cron?"
- "Dlaczego ten proces uruchamia się o tej godzinie?"
- "Skąd bierzemy ten parametr?"
- "Co się stanie, jeżeli go wyłączymy?"
Jeżeli odpowiedź na większość pytań brzmi "nie wiemy", nowy software house nie przejmuje projektu. Najpierw musi go odkryć.
A odkrywanie systemu kosztuje czas. Czas, który później płaci klient.
Dlatego przekazanie projektu pomiędzy zespołami powinno być procesem, a nie wrzuceniem ZIP-a z kodem i hasła do jednego konta.
System powinien przeżyć ludzi
To chyba najważniejsza zasada.
Ludzie się zmieniają. Programiści zmieniają pracę. Freelancerzy kończą współpracę. Software house'y zmieniają klientów. Administratorzy przechodzą do innych firm. Zarządy się zmieniają.
System pozostaje.
Dlatego system powinien być zaprojektowany tak, aby wiedza potrzebna do jego utrzymania była możliwa do odzyskania.
Nie oznacza to, że każdy pracownik ma wiedzieć wszystko.
Oznacza to, że organizacja powinna posiadać mechanizm przechowywania wiedzy:
- Repozytoria.
- Dokumentację.
- Rejestr integracji.
- Informacje o infrastrukturze.
- Dostępy zarządzane przez firmę.
- Opis kluczowych procesów.
- Historię istotnych decyzji.
- Informacje o zależnościach.
- Procedury awaryjne.
- I przede wszystkim - ludzi, którzy potrafią tę dokumentację wykorzystać.
NIST w aktualnych wytycznych dotyczących planowania bezpieczeństwa systemów również zwraca uwagę na formalne określenie odpowiedzialności, statusu operacyjnego systemu oraz ról osób, które system zarządzają, wspierają lub mają do niego dostęp.
To pokazuje szerszą zmianę w myśleniu o technologii.
System nie jest tylko kodem. System to również ludzie, procesy, infrastruktura, zależności, dane, dostęp i odpowiedzialność.
W Web24 często zaczynamy właśnie od pytania: "Co tu właściwie mamy?"
Przejęcie istniejącego projektu nie powinno zaczynać się od obietnicy, że wszystko zostanie napisane od nowa.
Powinno zacząć się od zrozumienia sytuacji:
- Co działa?
- Co nie działa?
- Co jest krytyczne?
- Co jest przestarzałe?
- Gdzie są największe ryzyka?
- Czego brakuje w dokumentacji?
- Jakie zależności są niewidoczne?
- Czy można bezpiecznie rozwijać istniejący system?
- Czy potrzebna jest modernizacja, czy tylko uporządkowanie?
Dopiero potem można zdecydować, czy projekt należy rozwijać, przebudować, częściowo przepisać czy po prostu dobrze udokumentować.
To szczególnie ważne przy projektach, które przez lata były rozwijane przez różne osoby i różne firmy.
Bo dobry partner technologiczny nie powinien być potrzebny dlatego, że tylko on wie, jak działa system.
Powinien być potrzebny dlatego, że potrafi ten system rozwijać, zabezpieczać i przekazywać wiedzę dalej.
Najgroźniejszym błędem może być człowiek, który już odszedł
Nie zawsze problemem jest stary kod.
Nie zawsze problemem jest przestarzała technologia.
Nie zawsze problemem jest brak najnowszego frameworka.
Czasami największym ryzykiem jest informacja, której nikt nie zapisał.
Jedno hasło.
Jedna decyzja architektoniczna.
Jedna integracja.
Jeden wyjątek w procesie.
Jeden człowiek, który przez lata wiedział, jak to działa.
A potem odszedł.
Dlatego warto zadać sobie dziś bardzo proste pytanie: Gdyby jutro z firmy zniknęła osoba, która najlepiej zna Wasz system, czy nadal bylibyście w stanie nim zarządzać?
Jeżeli odpowiedź brzmi "tak" - świetnie.
Jeżeli brzmi "nie wiem" - warto sprawdzić.
A jeżeli brzmi "zdecydowanie nie" - prawdopodobnie właśnie znaleźliście jeden z najważniejszych obszarów technologicznego ryzyka w swojej firmie.
System powinien być większy niż pamięć jednej osoby.
