Rzeczywistość inżyniera sieciowego (z makaronem i... solą?)
Ostatnio omawiając różne incydenty z inżynierami zauważyłem ciekawą prawidłowość.
W tych dyskusjach niezmiennie pojawia się pytanie o „pierwotną przyczynę”. Wierni czytelnicy zapewne wiedzą, że tak nadotycząca . W wielu organizacjach analiza incydentów opiera się całkowicie na tej koncepcji. Stosują różne techniki identyfikacji związków przyczynowo-skutkowych, np . Metody te przyjmują jako niepodważalny dogmat tzw. „liniowość zdarzeń”.
Kiedy kwestionujesz tę koncepcję i wskazujesz, że liniowość jest uspokajająco zwodnicza w złożonych systemach, rodzi się fascynująca dyskusja. Dyskutanci z zapałem podkreślają, że jedynie wiedza o „przyczynie źródłowej” pozwala nam zrozumieć, co się dzieje.
Zauważyłem ciekawą prawidłowość: programiści i devopsi inaczej reagują na ten pomysł. Z mojego doświadczenia wynika, że programiści częściej twierdzą, że pierwotna przyczyna ma znaczenie i że w zdarzeniach zawsze można ustalić związki przyczynowo-skutkowe. Z drugiej strony DevOps częściej zgadzają się, że złożony świat nie zawsze przestrzega liniowości.
Zawsze zastanawiałem się, dlaczego tak jest? Co sprawia, że programiści krytykują w ten sposób pomysł, że „podstawową przyczyną jest mit”? Jak układ odpornościowy, który rozpoznaje obcego czynnika. Dlaczego reagują w ten sposób, podczas gdy devops raczej skłonny rozważyć ten pomysł?
Nie jestem do końca pewien, ale mam pewne przemyślenia na ten temat. Odnosi się to do różnych kontekstów, w których ci specjaliści wykonują swoją codzienną pracę.
Programiści często pracują z narzędziami deterministycznymi. Oczywiście kompilatory, linkery, systemy operacyjne to systemy złożone, ale jesteśmy przyzwyczajeni do tego, że dają wynik deterministyczny i wyobrażamy sobie je jako deterministyczne: jeśli podajemy te same dane wejściowe, to zwykle oczekujemy tego samego wyniku z tych systemów. A jeśli wystąpi problem z wynikami („błąd”), programiści rozwiązują go, analizując dane wejściowe (albo od użytkownika, albo z zestawu narzędzi podczas procesu programowania). Szukają „błędu”, a następnie zmieniają dane wejściowe. To naprawia „błąd”.
Podstawowe założenie tworzenia oprogramowania: te same dane wejściowe w sposób niezawodny i deterministyczny dają ten sam wynik.
W rzeczywistości niedeterministyczny wynik sam w sobie jest uważany za błąd: jeśli nieoczekiwane lub błędne wyjście nie zostanie odtworzone, programiści mają tendencję do rozszerzania badania na inne części stosu (system operacyjny, sieć itp.), które również zachowują się lepiej lub mniej deterministycznie, dając ten sam wynik przy tych samych danych wejściowych... i jeśli tak nie jest, to nadal jest to uważane za błąd. To po prostu błąd systemu operacyjnego lub sieci.
W każdym razie determinizm jest podstawowym, niemal oczywistym założeniem dla większości programistów.
Ale dla każdego devopsa, który spędził dzień na składaniu sprzętu lub opracowywaniu API w chmurze, idea całkowicie deterministycznego świata (o ile w ogóle możliwe jest zmapowanie wszystkich danych wejściowych!) jest w najlepszym razie ulotną koncepcją. Nawet jeśli odłożysz to na bok doświadczeni inżynierowie widzieli najdziwniejsze rzeczy na tym świecie. Oni to wiedzą , nie wspominając o milionach innych czynników środowiskowych.
Dlatego doświadczonym inżynierom łatwiej jest wątpić, że wszystkie zdarzenia mają jedną pierwotną przyczynę, a techniki takie jak „Pięć powodów” prawidłowo (i powtarzalnie!) doprowadzą do tej pierwotnej przyczyny. W rzeczywistości stoi to w sprzeczności z ich własnym doświadczeniem, gdzie w praktyce elementy układanki nie pasują tak idealnie. Dlatego łatwiej akceptują ten pomysł.
Oczywiście nie twierdzę, że programiści są naiwni, głupi lub niezdolni do zrozumienia, jak liniowość może być zwodnicza.
Wydaje mi się jednak, że powszechna reakcja programistów w tych debatach często wiąże się z faktem, że koncepcja determinizmu ogólnie dobrze im służy w codziennej pracy. Nie spotykają się z niedeterminizmem tak często, jak inżynierowie muszą łapać koty Schrödingera na swojej infrastrukturze.
Może to nie wyjaśnia w pełni obserwowanych reakcji wywoływaczy, ale stanowi mocne przypomnienie, że nasze reakcje są złożoną mieszaniną wielu czynników.
Ważne jest, aby pamiętać o tej złożoności, niezależnie od tego, czy mamy do czynienia z pojedynczym incydentem, współpracujemy nad potokiem dostarczania oprogramowania, czy też próbujemy zrozumieć szerszy świat.
Źródło: www.habr.com