Ten wpis jest krótki spostrzeżeniem po świetnej książce Dawida Myśliwca “Przepis na człowieka”. Opisuje on w przystępny sposób jak geny wpływają na nasze życie, i jak to wszystko pod spodem działa.

Jest tam ciekawy fragment o procesie kopiowania DNA, który może wydać Ci się interesujący kontekście niezawodności systemów informatycznych.

By Madprime(wikipedia) (DNA replication split horizontal) CC BY-SA 2.0

Otóż podczas kopiowania nici DNA zachodzą błędy na pojedynczych elementach (nukleotydach) i uzyskana kopia nie jest idealnie identyczna. Przynajmniej raz na 10 mln par element skopiowany może się nie zgadzać ze swoim bazowym kolegą. Jednak nie jest tak, że twój organizm zostawi nić DNA w takim stanie.

Posiadasz dodatkowe mechanizmy naprawy nieprawidłowo skopiowanych elementów (np. MMR), które pozwalają wyłapać błędy i je naprawić. Na tym etapie 99% błędów w nowym DNA zostanie poprawione. Koniec końców szacuje się, że pomyłki w nie zdarzają się częściej niż raz na miliard. I tutaj przychodzi nam efekt skali…

Otóż podczas kopiowania pojedynczej komórki w twoim organizmie dochodzi do przynajmniej 2-3 mutacji - nienaprawionych błędów kopiowania. Samych czerwonych krwinek tworzysz od 173 miliardów do 259 mld dziennie (źródło). Efekt jest taki, że w zasadzie wszystkie twoje komórki zawierają mutacje. I co najlepsze - dalej jesteś w stanie egzystować. Organizm toleruje błędy i działa pomimo ich występowania.

Porównanie do systemów informatycznych

Możesz się teraz zastanowić co to ma wspólnego z systemem informatycznym? Spójrz na to z perspektywy SLA - niezawodności pracy organizmu przy kopiowaniu DNA:

• Podstawowy proces ma “niezawodność” na poziomie 99,9999%.
• Przy skali działania błędy były zbyt częste.
• Stworzony został dodatkowy mechanizm kontroli, który zwiększał “niezawodność” do 99,9999999%.
• To zaś nie dało rady wyeliminowało problemów - błędy dalej zachodzą.
• Pomimo błędów, organizm (w znakomitej większości przypadków) dalej działa.

Taki “system” działa ponieważ opiera się na bardzo zdroworozsądkowych założeniach:

• Stworzenie bardzo niezawodnego procesu jest skomplikowane i zwykle nieopłacalne.
• Dodatkowe procesy naprawiające błędy są tańszą metodą by zwiększyć ogólną niezawodność.
• Dodatkowe procesy naprawiające błędy nie rozwiążą wszystkich problemów - zawsze istnieje szansa, że błąd się prześlizgnie.
• System nie powinien całkowicie przestawać działać gdy błąd nie zostanie naprawiony.

I takie założenia warto przyjąć gdy tworzysz swój system informatyczny - na przykładzie procesu zamówienia w sklepie:

• Proces zamówienia oprze się np. o kolejkę, której SLA jest na poziomie 99.99% - potencjalnie 1/10000 wiadomości się zgubi.
• Możesz dodać osobny proces, który będzie monitorować zamówienia i naprawi błąd gdy zamówienie gdzieś “utknie”.
• To zaś nie uchroni Cię od błędów w samym “naprawiaczu” - np. podczas naprawiania proces może natrafić na nietypową wiadomość, która będzie nienaprawialna.
• W takich sytuacjach trzeba zadbać by ta sytuacja nie zablokowała pracy reszty systemy - błędną wiadomość lepiej pominąć i np. wrzucić na dead-letter queue niż bez przerwy ponawiać przetwarzanie.

Ogólne wrażenie jest takie, że warto czytać książki spoza IT by zauważać więcej w IT 😉

W artykule pominąłem bardzo wiele elementów genetyki, które może i pasowałyby do artykuły (np. niszczenie komórek jako metafora ubijania niedziałających podów w Kubernetesie), ale utrudniłyby ogólny odbiór artykułu. Less is more.