Cosa significa per te il termine "amministratore di sistema" o "amministratore di sistema"? Cosa fa un amministratore di sistema? Come fai a sapere di esserlo?
Domande esistenziali come questa raramente hanno risposte concrete e le risposte che si presentano da sole possono essere piuttosto fluide. Le risposte sono inoltre significativamente diverse per persone diverse e dipendono dalla loro esperienza lavorativa.
Sei un amministratore di sistema?
Nel mio libro, “The Linux Philosophy for SysAdmins , Cerco di rispondere all'ultima domanda. Ho creato questo breve elenco per aiutarti a determinare se sei un amministratore di sistema. Potresti essere solo un amministratore di sistema se:
- Credi che i miei libri possano essere una lettura divertente.
- Le persone ti chiedono spesso di aiutarli con i loro computer.
- Controlli i server ogni mattina prima di fare qualsiasi altra cosa.
- Scrivi script di shell per automatizzare anche compiti semplici.
- Condividi i tuoi script di shell.
- Concedi in licenza i tuoi script di shell con una licenza open source.
- Sai cosa significa open source.
- Documenti tutto ciò che fai.
- Hai violato il router wireless per installare il software Linux.
- Trovi i computer con cui interagire più facilmente rispetto alla maggior parte degli esseri umani.
- Capisci :(){ :|:&};:
- Pensi che la riga di comando sia divertente.
- Ti piace avere il controllo completo.
- Sei root.
- Rispondi sempre "no" quando qualcuno ti chiede se si può fare qualcosa o meno.
- Dopo aver discusso e aver scoperto ciò che la persona vuole veramente realizzare, sai che può essere fatto in 30 secondi con uno script di shell che hai già scritto, ma dici loro che ci vorranno "pochi giorni" prima di poter arrivare a esso.
- Capisci la differenza tra "libero come nella birra" e "libero come nella parola" quando applicato al software.
- Hai installato un computer in un armadio rack.
- Hai sostituito la ventola di raffreddamento della CPU standard con una che dissipa più calore.
- Acquisti le parti e costruisci i tuoi computer.
- Utilizzi il raffreddamento a liquido per la tua CPU.
- Installa Linux su tutto ciò che puoi.
- Hai un Raspberry Pi collegato al televisore.
- Usi un Raspberry Pi come firewall per la tua rete domestica.
- Esegui i tuoi server di posta elettronica, DHCP, NTP, NFS, DNS e/o SSH.
- Hai violato il tuo computer di casa per sostituire il processore con uno più veloce.
- Hai aggiornato il BIOS in un computer.
- Lasci le coperture del computer perché sostituisci frequentemente i componenti.
- Il router fornito dal tuo ISP è in modalità "pass-through".
- Usi un computer Linux come router.
Ti viene l'idea. Potrei elencare molte altre cose che potrebbero renderti un amministratore di sistema, ma ci sarebbero centinaia di elementi. Sono sicuro che puoi pensare a molte altre soluzioni adatte a te.
Quell'elenco riguarda te come qualcuno che fa tutte le cose dell'amministratore di sistema piuttosto che una definizione effettiva. Ma esiste davvero una definizione unica che vada bene per tutti? La mia esperienza dice che gli amministratori di sistema non possono essere facilmente definiti.
La mia storia
Ho lavorato per il governo del mio stato d'origine per circa cinque anni, assunto per mantenere e riscrivere quasi completamente un insieme interconnesso di programmi Perl esistenti. C'erano circa venticinque di questi programmi in esecuzione su un piccolo desktop Intel. Questi programmi hanno generato pagine Web CGI basate su dati archiviati in file flat. Queste pagine Web erano l'interfaccia di gestione per il sistema di posta elettronica statale che comprendeva diverse grandi agenzie in tutto lo stato. Il sistema di posta elettronica stesso funzionava su più server Sun Microsystems.
Dato che questo è iniziato come progetto pilota, per la mia parte del progetto è stato utilizzato un solo computer. Quel computer era un vecchio abbandono di un altro dipartimento quando è stato "regalato" al progetto e installato sul mio desktop. E 'servito anche come la mia postazione di lavoro personale. Non ricordo le specifiche esatte, ma aveva un processore Pentium originale a 32 bit che funzionava a 33 MHz con 16 MB di RAM e due dischi rigidi. Ha eseguito una versione anticipata di Red Hat Linux.
Stava diventando impossibile mantenere questi programmi per aggiungere nuove funzioni e individuare e correggere i bug a causa della complessità del codice. Il mio compito assegnato era correggere i bug e aggiungere alcune funzionalità aggiuntive a questi programmi.
Quando ho iniziato a cercare di dare un senso alla complessità del codice, è diventato chiaro che la mia prima priorità doveva essere semplificare il codice. Dopo aver abbondantemente commentato il codice e corretto alcuni bug mentre procedevo, ho cominciato a raccogliere del codice che era stato inserito in due o più di questi programmi ea raccoglierlo nelle librerie Perl. Ciò ha semplificato la risoluzione dei problemi perché dovevano essere risolti solo in un'unica posizione:la libreria. Ho raddrizzato altro codice, semplificando i percorsi di esecuzione comuni.
Ma ero anche responsabile della manutenzione dei vecchi sistemi, sia hardware che software. Ho installato aggiornamenti, aggiornato a un paio di versioni più recenti di Red Hat Linux nel corso degli anni e risolto un buon numero di problemi di configurazione di Linux causati dalla mancanza di conoscenza da parte dell'amministratore precedente. Ho controllato continuamente i registri e le prestazioni del sistema e ho apportato modifiche all'ottimizzazione tutte le volte che era necessario.
Ho anche gestito la sicurezza per questo host. Ho fatto tutto questo con un solo computer, senza backup, dal vivo, online, con i clienti che continuano a utilizzare il sito web. Alla fine, abbiamo convinto la dirigenza che avessimo bisogno di un secondo computer da poter utilizzare per un ambiente di test. Erano tempi divertenti.
Grande impresa
Ho lavorato per circa cinque anni in una grande impresa, abbastanza tardi nella mia carriera. È stato un lavoro divertente in parte perché aveva due componenti correlati.
Una parte del lavoro consisteva nello scrivere casi di test per dispositivi basati su Linux che l'azienda stava sviluppando. Ho usato Tcl/Expect, che si integrava bene con l'infrastruttura di test già esistente. In qualità di tester, ho scritto codice per buona parte del tempo, ma poi ho anche dovuto testare la suite di test e quindi eseguire i test veri e propri.
La seconda parte di questo lavoro è stata quella di assistente amministratore di laboratorio per diverse file di rack che costituivano il nostro laboratorio di prova, circa la metà del mio tempo. Lì si trovavano apparecchiature di ogni tipo, dai server Linux 1U agli enormi router che si estendevano su un intero rack e dozzine di host Linux e Solaris.
I miei compiti come amministratore di laboratorio mi prevedevano di ordinare nuove apparecchiature, montarle e cablarle quando arrivavano e installare Linux su tutte le scatole Intel. Non avevamo la responsabilità della gestione della rete in laboratorio, ma i vari dipartimenti hanno lavorato bene insieme e il gruppo di rete ci ha fornito una propria automazione. Abbiamo compilato un modulo Web richiedendo un indirizzo IP dall'elenco gestito da DHCP di indirizzi statici e una voce DNS, configurando immediatamente questi due elementi e quindi potremmo procedere con le nostre installazioni Linux.
Per accelerare l'installazione della configurazione speciale di Red Hat Linux, ho scritto uno script per automatizzare quel processo. Ne ho parlato in un articolo pubblicato su Linux Magazine nel giugno 2008. L'articolo è ora disponibile sul mio sito Web personale: Complete Kickstart e su Linux Today.
Utilizzando queste procedure sviluppate con gli altri gruppi, siamo stati in grado di decomprimere, rack, cablare e installare Linux su da sei a otto nuovi server in un giorno.
Ho anche creato diverse sessioni di formazione Lunch-n-Learn per aiutare gli altri dipendenti ad aggiornarsi su Linux.
Silos
L'ultimo lavoro W-2 che abbia mai avuto come cosiddetto amministratore di sistema è stato per circa un anno presso una particolare organizzazione che è un fantastico esempio del fallimento della tradizionale metodologia del "team" portata all'estremo. La parte peggiore è che è stato anche un pendolarismo quotidiano orribile.
In questa organizzazione, che rimarrà senza nome, la direzione aveva creato silos molto stretti e altissimi per contenere tutto.
C'erano più team, il team Unix, il team delle applicazioni, il team di rete, il team hardware, il team DNS, il team rack, il team via cavo, il team di alimentazione, praticamente qualsiasi team a cui puoi pensare. E le procedure erano sbalorditive. Ad esempio, uno dei miei progetti consisteva nell'installare Linux su diversi server da utilizzare per vari aspetti del sito Web dell'organizzazione. Il primo passo è stato ordinare i server, ma la richiesta ha richiesto settimane per farsi strada attraverso la burocrazia amministrativa.
Una volta consegnati i server, il team Unix li avrebbe inseriti nel laboratorio di installazione e installato il sistema operativo. Abbiamo avuto quella parte molto bene. Ma prima dovevamo richiedere un indirizzo IP. Non potevamo farlo prima di aver consegnato i server perché la richiesta di un indirizzo IP richiedeva i numeri di serie dei server e gli indirizzi MAC delle schede di rete.
Il problema qui era che ogni silo doveva avere un Service Level Agreement (SLA) con ogni altro silo e il tempo di risposta definito dallo SLA era di un minimo di due settimane. E ogni silo ha impiegato non meno tempo per rispondere di quello specificato nello SLA. Tuttavia, non siamo riusciti a ottenere l'indirizzo IP fino a quando non abbiamo assegnato una posizione del rack nella sala server perché gli indirizzi IP sono stati assegnati in base al rack e alla posizione nel rack. Quindi abbiamo dovuto inviare una richiesta per l'assegnazione di un rack e attendere due settimane per fornirla.
Quindi il passaggio successivo dopo aver ottenuto l'indirizzo IP è stato inviarlo al silo che gestiva la configurazione DHCP. Quindi sono trascorse almeno due settimane dopo aver ottenuto l'indirizzo IP che abbiamo dovuto attendere prima che il DHCP venisse impostato.
Solo quando i dati di configurazione della rete per il server sono stati configurati sul server DHCP è stata possibile inviare la richiesta di spostamento del server dal nostro rack alla sala server. Un'altra svolta di due settimane.
Dopo che la richiesta di spostamento è stata approvata, e solo dopo, abbiamo potuto inviare una richiesta per installare il computer nel rack. Al termine dell'installazione, potremmo inviare la richiesta di cablare il server con rete e alimentazione. Al termine, potremmo inviare una richiesta di accensione del server.
Fatta eccezione per l'installazione del sistema operativo, non abbiamo potuto toccare il server. Non ci è stato nemmeno permesso di entrare nella stanza del server. Mai.
Inutile dire che ci sono voluti mesi per installare ciascun server e renderlo funzionante e pronto per l'assunzione dei team di produzione. Potrei parlare di molti altri modi in cui questo posto è stato un disastro funzionale, ma penso che tu abbia avuto l'idea. Le loro squadre erano principalmente feudi politici protetti da silos impenetrabili.
Lavoro autonomo e consulenza
Nel corso degli anni, ho avuto due società mie che ho utilizzato per la consulenza mentre ero tra altri lavori. Ciò ha evitato buchi nel mio curriculum che avrebbero sollevato domande durante le interviste. Ho avuto dei buoni clienti in questo periodo e ho imparato molto.
In questo ruolo, ho fatto praticamente di tutto, dalla pianificazione di nuove installazioni alla formazione e all'esecuzione degli aggiornamenti. Ho addebitato tariffe scandalose per dedicare alcuni minuti a reimpostare la password di root su alcuni sistemi Linux in più di un caso. Sembra che i capi dai capelli a punta tendano a licenziare gli amministratori di sistema senza comprendere la necessità di una transizione graduale durante la quale otterrebbero tutte le password.
Pensionamento – una specie di
Ora sono presumibilmente in pensione, ma sembro essere più impegnato che mai. Scrivo articoli e libri e ho alcuni computer Linux da supportare.
Ho mantenuto da quattro a dieci computer che appartenevano a me o a una delle mie aziende nel mio laboratorio di casa. Ovviamente, eseguono tutti Linux. Attualmente, ho 12 computer nel mio laboratorio di casa, ma questo include tre su cui sto lavorando a vari progetti per la mia chiesa. Gestisco anche i computer e la rete della mia chiesa e di un paio di amici che ho convinto a provare Linux.
Quindi, sono l'amministratore di sistema per la maggior parte di questi computer, supporto hardware e software completo per gli altri. Fornisco anche formazione a varie persone nel mio ruolo attuale.
[ Cerchi di più sull'automazione dei sistemi? Inizia con The Automated Enterprise, un libro gratuito di Red Hat. ]
Conclusione
Un amministratore di sistema è molte cose, a volte tutte contemporaneamente.
La mia esperienza ha funzionato la gamma. Non ho mai avuto un lavoro che considererei un lavoro di amministratore di sistema "puro". Ogni organizzazione ha esigenze uniche e, nella maggior parte dei casi, l'amministratore di sistema viene "offerto" per ricoprire ruoli mai menzionati nel colloquio o nella descrizione del lavoro. Gli amministratori di sistema tendono ad avere le conoscenze e le competenze per fare quasi tutto ciò che è necessario. Le persone con cui lavoriamo e per le quali generalmente lo capiscono, quindi riceviamo quegli incarichi difficili che ci vengono affidati.
Mi piace.