Capire un server che hai ereditato: leggere prima di cambiare

Ti è capitato tra le mani un Proxmox che non hai costruito. Chi l’ha costruito non c’è più, non c’è documentazione, e ora ne sei responsabile. Il primo istinto in questa situazione è toccare qualcosa e vedere che succede. È esattamente la cosa da non fare per prima, perché non sai ancora che cosa è attaccato a che cosa.

La prima settimana è una settimana di lettura. Tutte le domande qui sotto si rispondono senza cambiare nulla.

Prima domanda: che cosa gira qui

Non quante macchine ci sono, ma quali di esse fanno davvero un lavoro. Sui server ereditati ci sono quasi sempre macchine spente che nessuno osa cancellare. Non le cancellerai adesso, le metterai solo in elenco.

Seconda domanda: dove sta fisicamente il disco di ogni macchina

È la domanda a cui le viste a elenco rispondono peggio, ed è quella che decide di più. Perché la risposta ti dice questo: la morte di un solo disco porta via una macchina o otto.

Segui la catena fino in fondo: macchina, disco virtuale, storage, pool, disco fisico. Vedere che i dischi virtuali di otto macchine scendono sullo stesso disco fisico è la cosa più preziosa che tu possa imparare su quel server.

Terza domanda: di che cosa ci sono backup, e di quando è il più recente

Non guardare se esistono lavori di backup, guarda l’età del backup più recente. Trovare un lavoro fermatosi in silenzio è cosa comune negli impianti ereditati, e saperlo la prima settimana costa molto meno che saperlo al sesto mese.

Quarta domanda: chi può entrare qui

Non quanti utenti ci sono, ma a chi è permesso che cosa. Nei sistemi ereditati restano account di persone andate via, chiavi di automazione dimenticate e permessi che nessuno ricorda di aver concesso. Anche questi, per ora, scrivili soltanto.

Quinta domanda: quanto è rimasto indietro

Guarda gli aggiornamenti in attesa e se c’è un kernel installato ma senza riavvio. Il secondo punto conta: la macchina può sembrare aggiornata mentre in realtà gira sul kernel vecchio.

La trappola del "gira da due anni, quindi è solido"

Il tempo di attività non è salute, è l’assenza di un riavvio. Una macchina che gira da due anni è una macchina non provata da due anni. Servizi avviati a mano e mai aggiunti all’avvio, montaggi mai scritti nella configurazione, tutto questo resta senza prova per quei due anni ed esce insieme al primo riavvio.

Per questo il primo riavvio pianificato su un server ereditato deve avvenire in un momento scelto da te, con un backup in mano. Il momento che non hai scelto arriva prima o poi.

Scrivi ciò che trovi

Il documento che scrivi la prima settimana è quello che ti salva al sesto mese. Non deve essere lungo: quale macchina fa cosa, dove sta il suo disco, se ha un backup, chi può raggiungerla. Anche cinque righe valgono infinitamente più di niente.

Per un po’ non cancellare nulla

Una macchina senza etichetta che nessuno sa identificare è un rischio, ma cancellarla è un rischio maggiore. Spegnila e aspetta. Se per due settimane nessuno urla, allora deciderai. Imparare dopo aver cancellato non si annulla; imparare dopo aver spento è un pulsante.

Che cosa fa Atlas

Atlas disegna due catene, e su un server ereditato sono esattamente queste due catene quelle di cui hai bisogno.

La mappa delle risorse scende dalla macchina fino al disco fisico: la macchina, la sua quota di processore e memoria, il disco virtuale, lo storage, il pool e in fondo il disco reale. La domanda "dove sta davvero il disco di questa macchina" si risponde quindi seguendo la linea, e non aprendo una a una la configurazione di ogni macchina. Vedere che otto macchine scendono sullo stesso disco avviene su quella stessa schermata.

La mappa di rete disegna l’altra catena: macchina, bridge, porta fisica, mondo esterno. Messe insieme, in un pomeriggio puoi leggere che aspetto ha un server che non hai costruito.