Ten wpis jest krótki spostrzeżeniem po świetnej książce Dawida Myśliwca “Przepis na człowieka”. Opisuje on w przystępny w jaki sposób 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ć z 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 (jak np. MMR), które pozwalają wyłapać błędy i je naprawić. Na tym etapie 99% błędów w nowym DNA zostanie wyłapane. Koniec końców szacuje się, że pomyłki w nie zdarzają się częściej niż 1 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 wystąpi błąd.

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