Zrozumieć odziedziczony serwer: czytaj, zanim zmienisz

Trafił ci się Proxmox, którego nie budowałeś. Osoba, która go zbudowała, odeszła, dokumentacji nie ma, a ty odpowiadasz teraz za niego. Pierwszym odruchem w takiej sytuacji jest w coś szturchnąć i zobaczyć, co się stanie. Właśnie tego nie należy robić najpierw, bo nie wiesz jeszcze, co jest z czym połączone.

Pierwszy tydzień jest tygodniem czytania. Na każde poniższe pytanie da się odpowiedzieć bez zmieniania czegokolwiek.

Pytanie pierwsze: co tu działa

Nie ile jest maszyn, tylko które z nich faktycznie wykonują pracę. Na odziedziczonych serwerach prawie zawsze stoją wyłączone maszyny, których nikt nie ma odwagi skasować. Nie zamierzasz ich teraz kasować, zamierzasz je tylko wypisać.

Pytanie drugie: gdzie fizycznie mieszka dysk każdej maszyny

To pytanie, na które widoki list odpowiadają najgorzej, i pytanie, które decyduje najwięcej. Bo odpowiedź mówi ci: czy śmierć jednego dysku zabiera jedną maszynę, czy osiem.

Idź za łańcuchem do końca: maszyna, dysk wirtualny, magazyn, pula, dysk fizyczny. Zobaczenie, że dyski wirtualne ośmiu maszyn schodzą się na tym samym dysku fizycznym, jest najcenniejszą pojedynczą rzeczą, jakiej możesz się o tym serwerze dowiedzieć.

Pytanie trzecie: co ma kopie i ile lat ma najnowsza

Nie patrz, czy istnieją zadania kopii, patrz na wiek najnowszej kopii. Znalezienie zadania kopii, które po cichu stanęło, jest na odziedziczonych konfiguracjach rzeczą częstą, a dowiedzenie się o tym w pierwszym tygodniu jest znacznie tańsze niż w szóstym miesiącu.

Pytanie czwarte: kto może tu wejść

Nie ilu jest użytkowników, tylko czemu wolno któremu. W odziedziczonych systemach są konta osób, które odeszły, zapomniane klucze automatyzacji i uprawnienia, których nikt nie pamięta nadawać. To też na razie tylko wypisz.

Pytanie piąte: jak bardzo jest z tyłu

Zobacz oczekujące aktualizacje i to, czy zainstalowano jądro, po którym nie było restartu. To drugie ma znaczenie: maszyna może wyglądać na aktualną, a w rzeczywistości pracować na starym jądrze.

Pułapka zdania, że działa od dwóch lat, więc musi być solidny

Czas pracy nie jest zdrowiem, tylko brakiem restartu. Maszyna działająca od dwóch lat to maszyna nietestowana od dwóch lat. Usługi uruchomione ręcznie i nigdy niedodane do startu, punkty montowania nigdy niewpisane do konfiguracji, wszystko to przez te dwa lata leży nieruszane i wychodzi razem przy pierwszym restarcie.

Dlatego pierwszy zaplanowany restart odziedziczonego serwera powinien nastąpić w wybranej przez ciebie chwili, z kopią zapasową w ręku. Chwila, której nie wybrałeś, przychodzi prędzej czy później.

Zapisz, co znajdziesz

Dokument napisany w pierwszym tygodniu jest dokumentem, który ratuje cię w szóstym miesiącu. Nie musi być długi: która maszyna co robi, gdzie siedzi jej dysk, czy ma kopie, kto może do niej sięgnąć. Nawet pięć linijek jest nieskończenie lepsze niż nic.

Przez jakiś czas niczego nie kasuj

Nieopisana maszyna, której nikt nie potrafi rozpoznać, jest ryzykiem, ale skasowanie jej jest ryzykiem większym. Wyłącz ją i poczekaj. Jeśli przez dwa tygodnie nikt nie krzyknie, wtedy decydujesz. Nauki po skasowaniu nie da się cofnąć; nauka po wyłączeniu to jeden przycisk.

Co robi Atlas

Atlas rysuje dwa łańcuchy, a na odziedziczonym serwerze te dwa łańcuchy to dokładnie to, czego potrzebujesz.

Mapa zasobów prowadzi od maszyny aż do dysku fizycznego: maszyna, jej udział w procesorze i pamięci, dysk wirtualny, magazyn, pula, a na dole prawdziwy dysk. Na pytanie, gdzie faktycznie siedzi dysk tej maszyny, odpowiada się więc, idąc wzdłuż linii, a nie otwierając konfigurację każdej maszyny po kolei. Zobaczenie, że osiem maszyn schodzi się na tym samym dysku, dzieje się na tym samym ekranie.

Mapa sieci rysuje drugi łańcuch: maszyna, mostek, port fizyczny, świat zewnętrzny. Razem pozwalają odczytać w jedno popołudnie, jak wygląda serwer, którego nie budowałeś.