Czego architektura może nas nauczyć o systemach samonaprawiających się

Zespoły DevOps i inżynierowie niezawodności witryny (SRE) codziennie mają do czynienia z kodem. W ten sposób uczą się analizować swój świat, dokonywać wnikliwych obserwacji i znajdować nieoczekiwane połączenia. W końcu, choć z natury wysoce logiczny i matematyczny, tworzenie oprogramowania jest, przynajmniej częściowo, formą sztuki. 

Nie jesteś przekonany tym stwierdzeniem? Rozważ podobieństwa między najbardziej niezwykłymi wyczynami architektonicznymi w historii a nowoczesną inżynierią oprogramowania. To trafne porównanie: podobnie jak inżynieria oprogramowania, architektura wykorzystuje złożone obliczenia matematyczne, aby stworzyć coś pięknego. A w obu dyscyplinach drobny błąd w obliczeniach może prowadzić do poważnych konsekwencji. Fascynujące jest to, że wiele słynnych błędów architektonicznych jest analogicznych do problemów, które znajdujemy w kodzie.

Pamiętaj, inspiracja jest wszędzie – pod warunkiem, że wiesz, gdzie szukać. Oto kilka lekcji, których inżynierowie oprogramowania mogą się nauczyć z architektonicznych objawień na przestrzeni wieków, zwłaszcza w odniesieniu do przyszłości systemów samonaprawiających się.

Lekcja 1: Sprawy Edge zawsze będą wykorzystywać luki systemowe

Citicorp Tower – obecnie nazywana 601 Lexington – zakończyła budowę w Nowym Jorku w 1977 roku, kiedy to była siódmym co do wysokości budynkiem na świecie. Najnowocześniejszy projekt wieżowca obejmował trzy ponad 100-metrowe szczudła. To był cud na ukończeniu. Jednak student studiów licencjackich wkrótce odkrył coś niepokojącego: silne wiatry mogłoby zagrozić integralności budynku. Konkretnie, jeśli silne ćwiartkowe wiatry uderzyły w rogi Citicorp Tower, konstrukcja groziła zawaleniem – dosłownie przypadek krawędzi.

Wieża miała jedną szansę na 16 zawalenia się każdego roku. Te szanse mogą zachęcić kogoś siedzącego przy stole hazardowym, ale perspektywy dla architektów i inżynierów stojących za Citicorp Tower były ponure. Na szczęście technicy byli w stanie wzmocnić połączenia śrubowe budynku. Katastrofy udało się uniknąć.

Inżynierowie konstrukcyjni wiedzieli, że wieżowiec Citicorp w końcu napotka wiatr na tyle silny, że uszkodzi jego łożyska. Podobnie doświadczeni inżynierowie oprogramowania wiedzą, że solidne monitorowanie wydajności aplikacji (APM) i zarządzanie zdarzeniami nie wystarczą do ochrony systemu przed nieuniknionymi przypadkami brzegowymi. To dlatego, że systemy statyczne bez uczenie maszynowe (ML) zdolności nie są w stanie poradzić sobie z nieoczekiwanymi i nieplanowanymi nowymi sytuacjami, takimi jak wiatry ćwiartkowe. Opierając się wyłącznie na narzędziach do monitorowania, administrator-człowiek musi rozszyfrować błędy i eskalować proces zarządzania incydentami.

Aby skrócić średni czas do odzyskania (MTTR)/średni czas do wykrycia (MTTD), zespoły DevOps muszą zaakceptować wysokie prawdopodobieństwo wystąpienia przypadków brzegowych i pracować nad zapobiegawczym wdrażaniem samouczących się rozwiązań. Ta lekcja ma długą historię, ponieważ przewidywanie ma kluczowe znaczenie w inżynierii.

Lekcja 2: „Budowanie samolotu w trakcie lotu” tworzy niekończący się cykl

Tragiczne wydarzenia przyniosły kilka najważniejsze lekcje w historii lotnictwa. Kiedy samolot uległ ogromnej dekompresji podczas lotu i rozbił się w 1954 roku, inżynierowie stwierdzili, że kwadratowe okna pasażerskie były niepotrzebnym punktem stresu. Odtąd, samoloty były wyposażone w zaokrąglone okna. Pożary na pokładzie doprowadziły do ​​​​nowego rozmieszczenia siedzeń, dla których priorytetem była łatwość ewakuacji. Te zmiany uratowały niezliczone życia.

W wielu branżach – w tym w lotnictwie – nie ma możliwości przeprowadzenia wyczerpujących testów warunków skrajnych produktu. Jak wspomniano wcześniej, przypadki skrajne są nieuniknione. Najważniejszym wnioskiem jest to, że inżynierowie oprogramowania muszą zwracać uwagę na luki w zabezpieczeniach swojego systemu, kiedy się prezentują. Stamtąd muszą się do nich odpowiednio zwracać. Wymaga to dwóch rzeczy: (1) zidentyfikowania i śledzenia właściwych kluczowych wskaźników wydajności (KPI) oraz (2) zainwestowania czasu i zasobów w ulepszanie systemów w oparciu o odpowiednie wskaźniki.

Przeciętny zespół inżynierów inwestuje w od 16 do 40 narzędzi do monitorowania, ale często nie trafia w punkt, w którym wskaźniki wskazują na sukces. Mniej niż 15% zespołów śledzi MTTD, więc przegapiają 66% cyklu życia incydentu. I jedna czwarta zespołów zgłasza brak ich umów o gwarantowanym poziomie usług (SLA) pomimo znacznych inwestycji w śledzenie dostępności. To mówi nam, że gromadzenie danych wymaga dokładnej, systematycznej analizy, aby to ograniczyć – rozwiązania punktowe już nie wystarczają.

Inżynierowie oprogramowania, zespoły DevOps i SRE muszą nadać priorytet procesom i narzędziom, które wydobywają wartość z przytłaczającej ilości informacji o dostępności. Zamiast po prostu obserwować krytyczny błąd, muszą wziąć stronę z książki inżyniera lotnictwa i szybko podjąć krytyczne decyzje. Sekret tego leży w sztucznej inteligencji.

Lekcja 3: Sztuczna inteligencja jest podstawowym budulcem samonaprawiających się systemów

Całkowicie autonomiczny, doskonale działający, samonaprawiający się system jest idealny dla każdego inżyniera oprogramowania. Systemy, które same się łatają, są dobre dla zadowolenia klientów, ponieważ eliminują kosztowne przestoje. Co więcej, są niezwykle korzystne dla funkcji zarządzania usługami IT (ITSM), ponieważ znacznie zmniejszają potrzebę żmudnego zarządzania zgłoszeniami. Zbudowanie takiego systemu wymaga kilku komponentów, z których wiele jest obecnie poza zasięgiem. Ale jesteśmy bliżej samonaprawiającej się rzeczywistości, niż niektórzy mogą sobie zdawać sprawę.

Brak powszechnej adopcji sztucznej inteligencji pozostaje największą przeszkodą, z jaką borykają się obecnie samonaprawiające się systemy. Chociaż wiele firm przyjęło podstawowe narzędzia oparte na sztucznej inteligencji lub uczeniu maszynowym, integralność tych narzędzi jest wątpliwa. Oznacza to, że wielu inżynierów zajmuje się sztuczna inteligencja dla operacji IT (AIOps) technologie, które stosują logikę automatyzacji opartą na regułach zamiast autonomicznych algorytmów sztucznej inteligencji. Różnica może wydawać się niewielka, ale w praktyce jest to różnica między godzinami utraconej produktywności a milionami możliwych strat.

Chodzi o to, że oparte na regułach narzędzia AIOps analizują interakcje między różnymi rozwiązaniami punktowymi i prawdopodobnie mogą identyfikować typowe błędy danych. Jednak systemy oparte na automatyzacji nie są w stanie przetwarzać ewolucji całkowicie nowych błędów w czasie ani przewidywać nowych awarii danych. Dzieje się tak dlatego, że administratorzy kodujący te funkcje proszą system o podążanie za jeśli to, to tamto wzór logiczny. Naprawdę wydajne narzędzia AIOps ograniczają błędy, które pojawiają się we wszystkich czterech klasycznych punktach telemetrycznych — od wykrywania do rozdzielczości — poprzez klasyfikację nowych i problematycznych wzorców, zanim technicy zdadzą sobie sprawę z ich istnienia. 

Podczas gdy czekamy na nadchodząca trzecia fala AI, ta wersja AIOps jest najbliższa systemom samonaprawiającym się. Interesujące będzie śledzenie, w jaki sposób obecne aplikacje AIOps wpłyną na przyszłość sztucznej inteligencji, która będzie obejmować w pełni zrealizowaną automatyzację i możliwości niezależnego myślenia. Może wtedy inżynierowie budowlani również skorzystają z samonaprawiającego się systemu opartego na sztucznej inteligencji.

• Dystrybucja treści i PR oparta na SEO. Uzyskaj wzmocnienie już dziś.
• Platoblockchain. Web3 Inteligencja Metaverse. Wzmocniona wiedza. Dostęp tutaj.
• Źródło: https://www.dataversity.net/what-architecture-can-teach-us-about-self-healing-systems/