Quali cose da amministratore di sistema dovrebbero sapere tutti i programmatori?

Come programmatore, tendiamo a dare per scontati gli amministratori di sistema. Le poche volte che sono stato senza un buon amministratore di sistema mi hanno davvero fatto apprezzare quello che fate. Quando ci avventuriamo in un ambiente senza un amministratore di sistema, quali parole di saggezza puoi offrirci?

Vorrei iniziare con:

1. Avere sempre un sistema di backup di qualche tipo. Ancora meglio se ha una storia.
2. Prendi in considerazione singoli punti di errore e come gestirli in caso di fallimento.
3. A seconda della quantità di computer coinvolti, la ricerca di un modo per creare e creare un'immagine standard su tutti i computer renderà la vita di tutti più semplice - non "funziona sulla mia" perché hanno un programma simile e normalmente non installato.
4. Documentare tutto, se non altro perché si si dimentica come si imposta qualcosa.
5. Tieniti aggiornato sugli aggiornamenti di sicurezza.

<inserisci qui la dichiarazione di non responsabilità di grandi dimensioni>

Alcuni di questi sono già stati detti, ma vale la pena ripeterli.

Documentazione:

• Documenta tutto. Se non ne hai uno, installa un wiki sotto il radar, ma assicurati di eseguirne il backup. Inizia con la raccolta dei fatti e un giorno si formerà un quadro generale.

• Crea diagrammi per ogni blocco logico e tienili aggiornati. Non sono riuscito a contare il numero di volte in cui una mappa di rete o un diagramma a cluster accurati mi ha salvato.

• Conserva i log di compilazione per ciascun sistema, anche se sono solo i comandi di copia e incolla su come costruirlo.

• Quando costruisci il tuo sistema, installa e configura le tue app, testa che funzioni ed esegui il benchmarking. Ora, cancella i dischi. Sul serio. 'dd' il primo megabyte dalla parte anteriore dei dischi o rendere la casella non avviabile altrimenti. Il tempo stringe: prova che la tua documentazione può ricostruirla da zero (o, ancora meglio, prova che il tuo collega può fare nient'altro che la tua documentazione). Ciò costituirà la metà del piano di Disaster Recovery.

• Ora hai la prima metà del tuo piano di Disaster Recovery, documenta il resto; come ripristinare lo stato dell'applicazione (ripristinare i file dal nastro, ricaricare i database dai dump), i dettagli del fornitore / supporto, i requisiti di rete, come e dove ottenere l'hardware sostitutivo - tutto ciò che si può pensare che aiuterà a ripristinare il sistema.

Automazione:

• Automatizza il più possibile. Se devi fare qualcosa tre volte, assicurati che il secondo sia dedicato allo sviluppo dell'automazione in modo che il terzo sia completamente automatizzato. Se non riesci ad automatizzarlo, documentalo. Ci sono suite di automazione là fuori - vedi se riesci a farle funzionare per te.

Monitoraggio:

• La strumentazione dell'applicazione è oro puro. Essere in grado di guardare le transazioni che passano attraverso il sistema semplifica notevolmente il debug e la risoluzione dei problemi.

• Crea test end-to-end che dimostrano non solo che l'applicazione è viva, ma fa davvero quello che dovrebbe. I punti sono tuoi se possono essere inseriti nel sistema di monitoraggio a scopo di avviso. Questo serve a doppio dovere; oltre a provare che l'app funziona, semplifica notevolmente gli aggiornamenti del sistema (monitoraggio dei rapporti di sistema verde, aggiornamento funzionante, tempo di tornare a casa).

• Confronta, monitora e raccogli metriche su tutto ciò che è sano di mente. I benchmark indicano quando aspettarsi che qualcosa emetta il fumo magico. Il monitoraggio ti dice quando ha. Le metriche e le statistiche rendono più semplice ottenere nuovi kit (con fumo magico fresco) attraverso la gestione.

• Se non si dispone di un sistema di monitoraggio, implementarne uno. Punti bonus se effettivamente esegui i test end-to-end di cui sopra.

Sicurezza:

• "chmod 777" (noto anche come accesso / privilegi) non è mai la soluzione.

• Abbonati al principio del "minimo bit"; se non è installato, copiato o vivente in altro modo sul disco, non può essere compromesso. L'installazione del sistema operativo e del software "Kitchen sink" può semplificare la vita durante la fase di costruzione, ma alla fine paghi per questo.

• Scopri a cosa serve ogni porta aperta su un server. Controllali frequentemente per assicurarti che non vengano visualizzati nuovi.

• Non provare a pulire un server compromesso; deve essere ricostruito da zero. Ricostruisci su un server di riserva con supporti appena scaricati, ripristinando solo i dati dai backup (poiché i file binari potrebbero essere compromessi) o clona l'host compromesso in un luogo isolato per l'analisi in modo da poterlo ricostruire sullo stesso kit. C'è un intero incubo legale intorno a questo, quindi sbaglia dal lato della conservazione nel caso in cui tu debba perseguire vie legali. (Nota: IANAL).

Hardware:

• Non dare mai per scontato che qualcosa farà ciò che dice sulla scatola. Dimostra che fa quello che ti serve, nel caso in cui non lo faccia. Ti ritroverai a dire "funziona quasi" più frequentemente di quanto ti aspetti.

• Non lesinare sulla gestione dell'hardware remoto. Le console seriali e la gestione delle luci spente dovrebbero essere considerate obbligatorie. Punti bonus per le prese multiple controllate a distanza per quelle volte in cui non hai più opzioni.

(A parte: ci sono due modi per risolvere un problema alle 3 del mattino, uno prevede di essere caldo, lavorare su un laptop su una VPN in pigiama, l'altro comporta una giacca spessa e un'unità per il datacenter / ufficio. So quale preferire.)

Gestione di progetto:

• Coinvolgere le persone che manterranno il sistema fin dal primo giorno del ciclo di vita del progetto. I tempi di consegna sul kit e sul tempo del cervello possono e sorprenderanno, e non c'è dubbio che avranno (dovrebbero?) Standard o requisiti che diventeranno dipendenze del progetto.

• La documentazione fa parte del progetto. Non avrai mai tempo per scrivere tutto dopo che il progetto è stato chiuso e il sistema è passato alla manutenzione, quindi assicurati che sia incluso come sforzo nel programma all'inizio.

• Implementare l'obsolescenza pianificata nel progetto dal primo giorno e avviare il ciclo di aggiornamento sei mesi prima del giorno di spegnimento specificato nella documentazione del progetto.

I server hanno una durata definita quando sono adatti per l'uso in produzione. La fine di questo ciclo di vita viene generalmente definita come ogni volta che il fornitore inizia a addebitare più costi di manutenzione annuale di quanto non costerebbe aggiornare il kit, o circa tre anni, a seconda di quale sia il periodo più breve. Dopo questo periodo, sono perfetti per gli ambienti di sviluppo / test, ma non dovresti fare affidamento su di essi per gestire l'azienda. Rivisitare l'ambiente a 2 anni e mezzo ti dà un sacco di tempo per saltare attraverso i cerchi di gestione e finanza necessari per ordinare il nuovo kit e per implementare una migrazione regolare prima di inviare il vecchio kit al grande fornitore nel cielo.

Sviluppo:

• Assicurati che i tuoi sistemi di sviluppo e gestione temporanea assomiglino alla produzione. Le macchine virtuali o altre tecniche di virtualizzazione (zone, LDOM, vservers) semplificano i cloni di produzione reali in ogni senso ma con prestazioni.

I backup

• I dati di cui non si esegue il backup sono dati che non si desidera. Questa è una legge immutabile. Assicurati che la tua realtà corrisponda a questa.

• I backup sono più difficili di quanto sembri; alcuni file saranno aperti o bloccati, mentre altri devono essere sospesi per avere qualche speranza di recupero e tutti questi problemi devono essere risolti. Alcuni pacchetti di backup hanno agenti o altri metodi per gestire file aperti / bloccati, altri no. Scaricare i database su disco e eseguire il backup di tali backup è considerato una forma di "sospensione", ma non è l'unico metodo.

• I backup sono inutili a meno che non vengano testati. Ogni pochi mesi, estrarre un nastro casuale dagli archivi, assicurarsi che contenga effettivamente dei dati e che i dati siano coerenti.

E, soprattutto...

Scegli le modalità di fallimento, altrimenti Murphy ... e Murphy non funziona secondo i tuoi programmi.

Progettare per guasti, documentare i punti deboli progettati da ciascun sistema, cosa li innesca e come recuperare. Farà la differenza quando qualcosa va storto.

Non dare per scontato che sia facile. Conosco molti programmatori che pensano che solo perché possono installare IIS o Apache sulla loro casella di sviluppo possono eseguire una web farm. Comprendi cosa comporta il lavoro e fai le tue ricerche e la tua pianificazione, non pensare solo che il lavoro di amministratore di sistema sia la cosa facile che puoi fare in 10 minuti per distribuire la tua app.

• Renditi conto che, nel bene o nel male, molti dei server e / o delle apparecchiature di rete tendono a somigliare molto ai bambini di una seconda famiglia. Questi sono i loro bambini. Li curano, li aiutano quando sono malati e li sorvegliano vigili per i problemi. Non dovrebbe essere così, ma dopo molti anni lo è spesso . Tienilo a mente mentre comunichi loro le tue preoccupazioni sull'attrezzatura che non funziona correttamente o sulle aspettative. E se ricevi una risposta che non capisci, prova a filtrarla attraverso questa visione del mondo.
• Sii in buone condizioni di lavoro. Sembra sfacciato, ma vale il suo peso in oro. Un giorno avrai bisogno di un favore speciale. E un giorno quel amministratore di sistema sarà felice di fare di tutto per rendere la vita un po 'più facile per te, solo per questa volta.
• Quel rapporto di lavoro va in entrambe le direzioni. Se l'amministratore di sistema è molto impegnato e potresti rendere la vita un po 'più semplice scrivendo un piccolo script o programma, allora fallo! Lo apprezzeranno più di quanto tu sappia.
• Sii molto chiaro. "Questo fa schifo" non è così chiaro come "avere una connessione di rete intermittente è un po 'fastidioso, hai qualche possibilità di vederlo?"
• Se ritieni che la tua app si ridimensionerà, chiedi all'amministratore prima di assumerlo . Potrebbero "vedere" qualcosa che non conosci o sapere qualcosa sui limiti di prestazione dell'attrezzatura su cui stai per schierare.
• Se la tua app deve essere ottimizzata, ma non sembra essere un problema di codice, chiedi gentilmente come stanno andando i server. Gli amministratori di sistema curano le loro macchine con amorevole cura e non sono contenti quando sono "malati" o "comportati male". Chiedere bene farà girare una macchina malata (o la farà riparare / sostituire).
• (come menzionato altrove) documentare le impostazioni utilizzate e il motivo per cui le si utilizza. Il solo fatto di "impostare la casella di controllo X" o "la riga del file di configurazione del commento Y" non aiuta. Potresti impostare l'opzione che cancella tutti i tuoi dati al prossimo riavvio per tutto quello che sai.
• Se non si ha il tempo di documentare l'impostazione su carta, se possibile provare a documentarla nel sistema. Con i file di configurazione, questa dovrebbe essere quasi una pratica standard: ogni modifica alle impostazioni deve essere sottoposta a un nuovo datamping, con le iniziali, l'effetto previsto di tale impostazione e il motivo per cui è stata modificata (vedere il precedente punto elenco). Questa piccola abitudine mi ha salvato la pancetta più di una volta durante il crunch-time. "Perché l'abbiamo fatto?" "Perché abbiamo imposto la politica X e l'impostazione Y ci dà il comportamento di cui abbiamo bisogno per la politica X".
• Birra. O Cola. O addirittura acqua. Le bevande sono sempre ben accette. Essere un amministratore di sistema è un lavoro assetato.

La sicurezza non è un ripensamento. Mentre un'app compromessa può rendere incompetente il programmatore, è (almeno) un fine settimana perso trascorso a verificare, pulire e / o ripristinare dai backup per un amministratore di sistema.

Per questo motivo, non trattare i backup come controllo di versione. Sono per il ripristino di emergenza e non sono progettati per ripristinare il codice perché hai dimenticato cosa hai cambiato.

E smetti di incolpare ciecamente gli aggiornamenti di Windows per la violazione del codice. Non mi interessa che abbia funzionato beforte, dimmi perché non funziona ora - quindi possiamo vedere di chi è la colpa.

Come eseguire il debug dei problemi di rete e guardare l'esecuzione del programma con gli strumenti sysadmin. Come programmatore che ha iniziato nell'amministrazione del sistema, sono sorpreso da quanto impotenti molti programmatori diventino una volta che la rete "si ferma".

• Wireshark , per vedere il tuo codice correre in una scatola nera, pacchetto per pacchetto
• Strumenti per connettersi direttamente ai servizi di rete:
  • Telnet, netcat o socat per connessioni semplici su TCP o UDP
  • OpenSSL per la stessa cosa con la crittografia (suggerimento: provare openssl s_client -connect target-host:portqualche volta), per la connessione manuale ai servizi di rete
• dig (nel pacchetto BIND 9) per il debug della risoluzione dei nomi
• Essere in grado di dire quale parte dello stack di rete non è riuscita in base alla tempistica e ad altre caratteristiche di una connessione non riuscita
• Forse HTTPFox e / o Firebug

Sapere come risolvere i problemi.

È molto facile passare il dollaro (ad esempio, la tua rete sta perdendo la mia comunicazione con il database). Potrebbe essere colpa della rete, ma dovresti avere registri delle applicazioni con errori che, utilizzando Google o SO, potrebbero rivelare un problema nella configurazione di un'app.

A tutti piace incolpare l'hardware, il sistema operativo o la rete, quindi se pratichi un po 'più di dovuta diligenza, renderai l'amministratore di sistema una persona felice. Perché, se non altro, potresti essere in grado di indicarli in una direzione specifica su cosa potrebbe essere sbagliato (al contrario di dire "la tua rete fa schifo" o qualcosa di ugualmente utile).

Documenta tutto ciò che puoi. Non posso dirti quante volte l'ultimo amministratore di sistema ha pensato che sarebbe stato carino non documentare qualcosa per la "sicurezza del lavoro" o qualcuno voleva solo entrare e uscire. Proprio come un programmatore dovrebbe lasciare buoni commenti, gli amministratori di sistema dovrebbero documentare. Sarebbe bello anche un diagramma della topologia.

Piano B.

Tenere sempre presente un piano di ripristino di emergenza durante la progettazione e lo sviluppo di una soluzione. Riconoscere i singoli punti di errore che possono portare a un'interruzione.

Documentazione: non c'è bisogno di impazzire, ma come funziona l'applicazione, un diagramma che mostra come si adattano i bit e come testare ogni componente quando tutto va storto. I dati di esempio e l'output sono belli.

Requisiti: su quali moduli si basa? Versioni? OS?

Monitoraggio: idealmente gli sviluppatori dovrebbero includere informazioni di monitoraggio e test con l'applicazione.

A proposito di imballaggi, CONFEZIONI! Niente di peggio di una "distribuzione" che significa estrarre una nuova revisione di un file da VCS e copiarlo su un gruppo di server. Troppo spesso i programmatori non apprezzano la complessità della distribuzione del software: ci sono ragioni per cui il software confezionato con versione costituisce la spina dorsale della maggior parte dei sistemi operativi.

Se uno sviluppatore venisse da me con un RPM che si installava per la prima volta con una documentazione concisa e completa e alcuni test Nagios sarebbero stati il ​​mio nuovo migliore amico.

Sono sorpreso che finora nessuna delle 17 risposte fornite qui includa alcunché per garantire che l'applicazione venga eseguita quando si accede come utente standard.

Oltre al processo di installazione, l'applicazione dovrebbe funzionare correttamente quando si accede con un account utente standard.

Backup Backup Backup .... Prova il backup .... Siate sempre pronti al rollback

Questo può applicarsi solo ai programmatori principianti, ma mi occupo di alcune cose su ogni progetto con alcuni programmatori.

1. "Funziona sulla mia macchina" non è mai una dichiarazione valida. È responsabilità del programmatore creare un programma di installazione da utilizzare sul server, o almeno documentare ogni connessione, dll e componente aggiuntivo richiesti sul server.

2. (L'ho sentito più volte, quindi per favore non ridere) Corro exe sul server dalla mia macchina e funziona. Ma quando lo eseguo sul server (Citrix, Terminal Server, ecc.) Non funziona. Ti preghiamo di comprendere dll e ocx e qualsiasi altra cosa il tuo programma richiede e dove e come sono registrati e come il tuo programma li utilizza.

Questi possono sembrare semplici, ma ci penso costantemente.

Brian

• parla al tuo amministratore in modo formale e informale di ciò che stai facendo. Di solito saranno interessati e potranno presto esprimere possibili impatti sulla produzione. Non devi essere d'accordo, ma aiuta a identificare i punti problematici.
• No, non puoi avere l'intero server per te ... Se necessario, è una decisione politica, indipendentemente da quanto tecnicamente sia valido. Se vuoi lavorare in politica, vai avanti.
• L'hardware di produzione ha spesso un aspetto diverso rispetto al server di sviluppo e, anche all'interno delle farm, le specifiche sui computer sono diverse.
• Scopri come è impostata la produzione, perché probabilmente non puoi replicarla sul desktop, in questo modo ti impedirai di fare ipotesi scadenti.
• Solo perché è possibile memorizzare nella cache roba in memoria non significa che si dovrebbe, attendere prima il collo di bottiglia (nel test unitario o test delle prestazioni pre-produzione)
• se si stanno attaccando i dati in un database, pensare a come dividere i dati in dati di sola lettura (che possono essere ridimensionati orizzontalmente) e dati di lettura-scrittura (che di solito si ridimensionano solo verticalmente).
• se stai attaccando i dati in un database, deve essere davvero un RDBMS? ci sono altri sistemi coppia chiave-valore là fuori che scalano meglio (netcache).
• non pensare che AJAX sia la soluzione definitiva, ha un bell'aspetto, ma limita le possibilità di monitoraggio e automazione. Non sto dicendo di non usarlo, basta pensarci due volte.

OK, questo è leggermente rantolante ma:

a) Quando si codifica, si supponga che l'infrastruttura sottostante possa fallire e non provenga da terreni sempre felici e felici. O Google.

b) Probabilmente non abbiamo le risorse per implementare qualcosa di simile all'infrastruttura di cui hai letto, quindi rilassati quando le cose vanno male. È probabile che sappiamo cosa deve essere fatto, ma per qualsiasi motivo non è ancora successo. Siamo i tuoi partner!

c) Come detto sopra, sarebbe davvero d'aiuto se avessi familiarità con gli strumenti per risolvere i problemi dell'infrastruttura, come ping, traceroute (o combinando entrambi - mtr), scavare, ecc. Punti bonus enormi anche per conoscere Wireshark.

d) Se programmi un computer, dovresti davvero sapere come si connette alla rete e le basi come poter analizzare l'output di ipconfig / all o ifconfig. Dovresti essere in grado di rendere operativa la tua connessione Internet con il minimo aiuto.

Altrimenti penso che Avery l'abbia praticamente inchiodato. Gli sviluppatori che fanno un po 'di sysadmin valgono il loro peso in oro! Ma allo stesso modo, gli amministratori di sistema che capiscono come vanno gli sviluppatori sulle cose (incluso il versioning, ecc.) Sono praticamente essenziali ai giorni nostri.

Questo sembra essere nell'aria al momento, ho notato più discussioni sulla relazione dev / ops nei blog - dai un'occhiata

Mantenere Twitter Twitter

Partizioni e guerra

Test prima nelle operazioni

Che nessun gruppo o funzione sia "migliore" di un altro e che nessuno richieda "cervelli più grandi" l'uno dell'altro. Ho visto che entrambe le parti sono diventate prima-dona'ish nell'altra compagnia - state tutti cercando di raggiungere gli stessi obiettivi - concentratevi su queste somiglianze e non sul fatto che usate strumenti diversi.

L'architetto dell'infrastruttura è diventato programmatore, ma potrebbe voler ripristinare tale transazione in futuro :)

1. Parlare tra loro, presto e spesso. Esamina i progetti con i ragazzi che gestiranno l'infrastruttura su cui verrà distribuita la tua app (se sai chi sarà).
2. Nessuna perdita di dati è possibile, ma è una responsabilità condivisa da sviluppatori e amministratori di sistema. Anche in questo caso, parlare tra loro può aiutare qui.
3. Il personale dell'infrastruttura avrebbe dovuto essere coinvolto nella determinazione dei requisiti non funzionali.
4. Organizza la birra (quando il lavoro è finito) e la pizza (mentre stiamo lavorando). In qualche modo, la presenza di quel tipo di cibo influisce sulla nostra capacità di far fare alle nostre simpatiche scatoline da 32 cpu qualunque cosa tu voglia che facciano :)

Come qualcuno che è stato un amministratore di sistema per gli sviluppatori e uno sviluppatore, il consiglio fornito qui non è solo oro, ma dovrebbe far parte della documentazione di assunzione per i nuovi sviluppatori per le aziende di tutto il mondo.

Qualcosa che non ho ancora visto (ancora) spiegato è che gli sviluppatori dovrebbero davvero conoscere i prodotti che useranno per creare i programmi per i quali vengono pagati. Il numero di volte che ho dovuto spiegare e configurare server Apache, installazioni di Eclipse e Visual Studio e database su macchine sviluppatore è un po 'preoccupante.