Co kilka miesięcy jakaś duża usługa zawodzi w sposób, który zabiera ze sobą dużą część internetu, a przyczyna okazuje się leżeć w warstwie, o której wszyscy myśleli, że została zabstrahowana.
Abstrakcja ukrywa warstwę, nie usuwa jej
Historia opowiadana o infrastrukturze przez ostatnie piętnaście lat mówi, że zniknęła w chmurze. Serwery stały się instancjami, potem kontenerami, potem funkcjami. Sieci stały się konfiguracją. Pamięć masowa stała się interfejsem.
Każdy z tych kroków jest realny i użyteczny, i żaden niczego nie usunął. Pakiet nadal musi dotrzeć do celu. Nazwa nadal musi się rozwiązać. Certyfikat nadal musi być ważny i aktualny. Dysk nadal musi mieć pojemność. Zegar nadal musi się zgadzać z innymi zegarami.
To, co się zmieniło, to kto zauważa awarię jednej z tych rzeczy i jak trudno ją dostrzec.
Abstrakcja oddala awarię od osoby, która jej doświadcza, co utrudnia znalezienie usterki i podnosi wartość osoby, która potrafi ją znaleźć.
To jest robocza teza tego kierunku. Nie nostalgia za montowaniem serwerów w szafach, tylko obserwacja, że liczba ludzi potrafiących rozumować, co naprawdę dzieje się pod spodem, spadła szybciej niż zapotrzebowanie na nich.
Co obejmuje ten kierunek
Zakres: systemy operacyjne, sprzęt, sieci, serwery, administracja i rozwiązywanie problemów.
Cztery obszary.
Sieci. Adresowanie, routing, rozwiązywanie nazw, równoważenie obciążenia, zapory sieciowe i droga, którą faktycznie przechodzi żądanie.
Systemy operacyjne. Procesy, uprawnienia, systemy plików, usługi i logi, na platformach, na których działa organizacja.
Tożsamość i katalogi. Uwierzytelnianie, autoryzacja, certyfikaty i systemy, które je wystawiają.
Operacje. Monitorowanie, kopie zapasowe i odzyskiwanie, pojemność, łatanie i uporządkowane rozwiązywanie problemów.
To zawsze DNS, i dlaczego ten żart jest prawdziwy
Stały żart wśród inżynierów infrastruktury wskazuje na coś realnego w tym, jak zawodzą systemy.
Rozwiązywanie nazw leży pod niemal wszystkim, jest niewidoczne, gdy działa, i daje objawy wyglądające jak zupełnie inne problemy. Aplikacja wygląda na wolną, gdy rozwiązywanie nazwy przekracza czas oczekiwania. Usługa wygląda na wyłączoną, gdy rekord wskazuje na wycofany adres. Zmiana propaguje się nierówno przez buforowanie na kilku warstwach, więc system jest zepsuty dla części użytkowników i sprawny dla reszty, co jest najtrudniejszym do zdiagnozowania wzorcem awarii.
Trzej inni członkowie tej samej rodziny powodują podobną część incydentów z tego samego powodu.
Certyfikaty. Wygasają. W dniu znanym z wielu lat wyprzedzeniem. Poważne awarie w dużych organizacjach były wywoływane dokładnie przez to, wielokrotnie, bo odnowienie było ręczne, a osoba, która o tym wiedziała, odeszła z firmy.
Czas. Dryf zegara psuje protokoły uwierzytelniania, unieważnia sprawdzanie certyfikatów, psuje korelację logów i sprawia, że systemy rozproszone zachowują się niespójnie. Objawia się jako problem z uwierzytelnianiem, więc ludzie badają uwierzytelnianie.
Routing i trasa. Asymetryczne trasy, zmiany trasy, reguły zapory dodane w jednym celu, a wpływające na inny. Objawy pojawiają się z przerwami i tylko dla niektórych źródeł.
Łączy je to, że każdy jest infrastrukturą, od której wszyscy zależą i której nikt nie jest właścicielem, i każdy daje objawy dużo dalej od przyczyny. Inżynierowie, którzy wiedzą, żeby sprawdzić to najpierw, rozwiązują w kilka minut to, co inaczej zajmuje dzień.
Gdzie to się mieści w domenie
Systemy IT i sieci komputerowe to siódmy z ośmiu kierunków w domenie AI, danych i informatyki Astra Trainer, i działa jako linia zaopatrzenia dla reszty. Cloud computing i DevOps, cyberbezpieczeństwo i platform engineering rekrutują właśnie stąd, a wszystkie opierają się na rozumieniu, które buduje ten kierunek.
Łączy się najbezpośredniej z informatyką w zakresie modelu systemu operacyjnego i sieci oraz z cyberbezpieczeństwem, gdzie umiejętność rozumowania, co system naprawdę robi, jest fundamentem detekcji i reagowania. Zobacz osiem kierunków tutaj.
Rozwiązywanie problemów to metoda, nie talent
Najbardziej przenośna i najsłabiej nauczana kompetencja w tym kierunku. Traktuje się ją jako coś, co się ma albo czego się nie ma, a to jest procedura.
Ustal, co faktycznie się zmieniło. Systemy, które działały wczoraj, a dziś zawodzą, zwykle się zmieniły, nawet gdy wszyscy mówią, że nic się nie zmieniło. Wdrożenia, odnowienia certyfikatów, aktualizacje reguł, wygasłe dane uwierzytelniające, pełny dysk przekraczający próg.
Zdefiniuj zakres precyzyjnie. Wszyscy użytkownicy czy niektórzy. Wszystkie lokalizacje czy jedna. Cały czas czy z przerwami. Każda odpowiedź eliminuje całe kategorie przyczyn, a nieprecyzyjność tutaj powoduje, że dochodzenie błądzi.
Pracuj wzdłuż ścieżki. Żądanie przechodzi przez znaną sekwencję komponentów. Testuj w punktach wzdłuż niej i ustal, gdzie zachowanie przestaje odpowiadać oczekiwaniom. To zamienia otwarty problem w przeszukiwanie o skończonej odpowiedzi.
Zmieniaj jedną rzecz na raz. Zmiana kilku i odkrycie, że działa, zostawia cię bez wiedzy dlaczego, czyli bez możliwości zapobiegnięcia temu ani naprawienia tego następnym razem.
Czytaj logi właściwie. Nie ostatni błąd, który często jest efektem wtórnym, tylko pierwszą anomalię i sekwencję wokół niej, z czasami skorelowanymi między systemami.
Wiedz, kiedy przywrócić, a kiedy diagnozować. Podczas awarii przywrócenie usługi i zbadanie tego później jest często słuszne. Mylenie odzyskiwania z przyczyną źródłową to sposób, w jaki ten sam incydent wraca.
Nauczane wprost, to sprawia, że zwykli inżynierowie stają się dramatycznie skuteczniejsi. Pozostawione domyślności, ludzie rozwijają to przez lata albo nigdy.
Prawdziwy problem karierowy tego kierunku
Warto nazwać go wprost, bo to jest realne ograniczenie, i nie jest techniczne.
Praca nad infrastrukturą jest traktowana jak koszty ogólne. Pojawia się w budżetach jako koszt, mierzy się ją brakiem problemów i zauważa niemal wyłącznie, gdy coś zawiedzie. Development buduje rzeczy, które się ogłasza. Infrastruktura utrzymuje działanie, co nie generuje żadnych ogłoszeń.
Wynikają z tego cztery konsekwencje.
Płaca i status zostają w tyle za pokrewnymi rolami o porównywalnej lub mniejszej trudności, co wypycha zdolnych ludzi z tej dyscypliny.
Inwestycje przychodzą po incydentach i opadają po nich, więc kompetencje budowane są reaktywnie.
Outsourcing usunął poligon szkoleniowy. Stanowiska juniorskie, na których budowało się rozumienie infrastruktury, w wielu organizacjach zostały oddane na zewnątrz, co jest tym samym zablokowaniem lejka, opisanym w artykule o cyberbezpieczeństwie.
Wiedza jest nieudokumentowana i osobista. Które systemy mają znaczenie, jak wygląda normalność, gdzie jest dziwna zależność. Odchodzi razem z osobą, a jej następca odbudowuje to powoli i drogo.
Organizacja, która chce mieć kompetencje w chmurze, bezpieczeństwie i platform engineering, powinna zauważyć, że aktualnie niedoinwestowuje populację, z której te dyscypliny rekrutują, i że to decyzja, którą może tanio odwrócić.
Role, nazwane wprost
Administratorzy systemów, na głównych platformach.
Inżynierowie i architekci sieci.
Inżynierowie infrastruktury.
Specjaliści od tożsamości i katalogów.
Inżynierowie pamięci masowej i kopii zapasowych, których znaczenie staje się oczywiste dokładnie raz.
Specjaliści od wirtualizacji.
Inżynierowie stanowisk końcowych i end user computing.
Service desk i wsparcie techniczne, najczęstszy punkt wejścia do całej domeny.
Technicy centrów danych, populacja, która znów urosła wraz z rozbudową mocy obliczeniowej.
Kogo można w to przeszkolić
Personel service desk i wsparcia. Klasyczna i wciąż najlepsza droga. Już widzą całą infrastrukturę, wiedzą, co się psuje, i mają instynkt rozwiązywania problemów, który uporządkowane szkolenie zamienia w metodę.
Technicy telekomunikacji. W stronę sieci, mając warstwę fizyczną i transmisyjną.
Personel wojskowych systemów łączności i informatyki. Często doskonali, przychodzący zarówno z umiejętnościami technicznymi, jak i z dyscypliną operacyjną.
Elektrycy i technicy systemów budynkowych. W stronę pracy przy centrach danych i infrastrukturze fizycznej.
Każdy, kto nieformalnie administrował systemami, w małej firmie albo jako osoba, do której inni się zwracają. Realna kompetencja bez formalnego uznania.
Deweloperzy. W stronę ról infrastrukturalnych i platformowych, potrzebujący połowy operacyjnej, której nigdy nie mieli.
Osoby zmieniające karierę z ról operacyjnych w logistyce, produkcji lub sektorze użyteczności publicznej, gdzie dyscyplina procesowa i praca zmianowa przenoszą się wprost.
Dostęp, kontrola zmian i obowiązki ciągłości działania. Dostęp administracyjny do systemów produkcyjnych to pozycja wysokiego uprzywilejowania, regulowana przez zarządzanie zmianą, logowanie i wymagania rozdziału obowiązków, a w sektorach regulowanych – przez konkretne ramy kontrolne. Zdolność do tworzenia kopii zapasowych i odzyskiwania podlega obowiązkom prawnym i umownym w wielu branżach, a nietestowane kopie zapasowe wielokrotnie zawodziły, gdy były potrzebne. Astra Trainer buduje kompetencje techniczne i świadomość, gdzie te obowiązki mają zastosowanie. Nie nadaje autoryzacji do dostępu do żadnego systemu i nie zastępuje wymagań kontrolnych organizacji.
Co z tego wynieść
Abstrakcje chmurowe przeniosły infrastrukturę za interfejs, nie usuwając jej, co utrudniło lokalizację usterek i podniosło wartość ludzi, którzy potrafią je zlokalizować.
Rozwiązywanie nazw, certyfikaty, czas i routing powodują nieproporcjonalnie dużą część awarii, bo są niewidoczne, dopóki nie zawiodą, i dają objawy daleko od przyczyny.
Rozwiązywanie problemów to metoda, której można nauczyć, a nie talent, a nauczanie jej wprost to jedna z interwencji technicznych o najwyższym zwrocie.
Prawdziwym ograniczeniem jest tu status i lejek kadrowy, nie popyt, a outsourcing usunął stanowiska juniorskie, na których to rozumienie się budowało.
A każdy zespół chmury, DevOps i bezpieczeństwa rekrutuje z tej populacji. Niedoinwestowanie tu to niedoinwestowanie wszystkich pozostałych.
Czy chmura uczyniła kompetencje infrastrukturalne przestarzałymi?
Nie. Przeniosła infrastrukturę za interfejs. Sieci, systemy operacyjne, rozwiązywanie nazw i pamięć masowa nadal istnieją i nadal zawodzą, a abstrakcja oddala awarię od objawu, co utrudnia diagnozę.
Dlaczego DNS, certyfikaty i czas powodują tak wiele awarii?
Bo wszystko od nich zależy, nikt nie jest ich właścicielem, są niewidoczne, gdy działają, a ich awarie dają objawy na zupełnie innej warstwie. Wygasanie certyfikatów w szczególności wielokrotnie powodowało poważne awarie w dniach znanych z wieloletnim wyprzedzeniem.
Czy rozwiązywania problemów można nauczyć?
Tak. Ustal, co się zmieniło, zdefiniuj zakres precyzyjnie, testuj wzdłuż ścieżki żądania, zmieniaj jedną rzecz naraz, czytaj logi od pierwszej anomalii, a nie ostatniego błędu, i odróżniaj przywrócenie usługi od znalezienia przyczyny źródłowej.
Dlaczego infrastruktura jest niedoceniana?
Bo mierzy się ją brakiem problemów i zauważa tylko podczas awarii, więc w budżetach pojawia się jako koszt. Płaca i status zostają w tyle za pokrewnymi rolami, inwestycje przychodzą reaktywnie po incydentach, a outsourcing usunął stanowiska juniorskie budujące tę kompetencję.
Kto dobrze przekwalifikowuje się do ról infrastrukturalnych?
Najpierw personel service desk i wsparcia, potem technicy telekomunikacji w stronę sieci, personel wojskowej łączności, elektrycy w stronę centrów danych, nieformalni administratorzy i deweloperzy potrzebujący połowy operacyjnej.