Come registrare le modifiche al server?

Quindi probabilmente abbiamo tutti avuto questa situazione: fai il debug di un problema, solo per rendertene conto che è stato causato da una modifica alla configurazione che hai fatto sei mesi fa e non riesci a ricordare perché l'hai fatto. Quindi lo annulli e risolvi il problema, e ora qualche altro problema ritorna. Oh sì, ORA mi ricordo! Quindi lo aggiusti correttamente.

È perché non hai preso appunti, sciocco! Ma qual è un buon modo per farlo?

In ingegneria abbiamo un sacco di software pensato per aiutarci a rilevare e tenere traccia delle modifiche. Controllo del codice sorgente, revisioni del codice e così via. Ogni modifica viene tracciata, ogni modifica richiede un commento su ciò che è. E i dipartimenti di ingegneria tipici richiedono buoni commenti in modo che in sei mesi, quando stai scoprendo perché l'hai rotto in quel modo, puoi usare una caratteristica storica di "colpa" o build di ricerca binaria per individuare il problema. Questi strumenti sono strumenti di comunicazione e record storici molto efficaci.

Ma in serverland abbiamo 500 servizi diversi, tutti con modi diversi di configurarli. E non hanno sempre un formato di testo (considerare l'impostazione delle autorizzazioni su una cartella o l'alterazione della posizione del file di paging) sebbene possano avere una rappresentazione testuale.

Nel nostro ambiente, controlliamo quali file di configurazione possiamo inserire in Perforce, ma ce ne sono pochi. Impossibile controllare esattamente nel DB di Active Directory ... anche se forse un dump che potrebbe essere diff ...

In passato ho provato a tenere un registro delle modifiche manuale nella nostra wiki, ma è molto difficile mantenere la disciplina per farlo (lo so, non è una buona scusa, ma è davvero dura).

LA MIA DOMANDA: Quali strategie e strumenti utilizzate per far fronte a questo problema di tracciamento delle modifiche alla configurazione sui vostri server?

-- Aggiornare --

Nota: non sto cercando strumenti per prendere appunti condivisi (ho familiarità con OneNote, ecc.) Tanto quanto strumenti automatizzati pensati specificamente per aiutare a monitorare le modifiche del server. Non esiste uno strumento completo per tenere traccia delle modifiche alla configurazione del server, ma forse ce ne sono alcune per applicazioni specifiche come l'oggetto Criteri di gruppo.

Inoltre sono molto interessato a strategie specifiche che hai trovato utili. "Condividiamo le note in Sharepoint" è piuttosto vago. Come mantieni la disciplina? Quale formato usi per tenere traccia delle tue modifiche? Come organizzi i tuoi dati di modifica? Vorrei davvero esempi e idee.

Nella terra Linux, le persone stanno perseguendo un paio di strategie diverse:

• Sistemi di vincoli di configurazione , come cfengine o burattino o cuoco . Questi sono simili agli oggetti Criteri di gruppo di Windows. Il punto è che tutta la configurazione del server è intenzionalmente documentata in un unico posto e sai a quale granularità (sala server, gruppo, server specifico) viene attuata la politica. Questo non ti salverà del tutto da "cosa diavolo era diverso sei mesi fa?" ma ti consente di eseguire solo l'annullamento della configurazione di un server e la ricostruzione da zero. Potresti mettere le politiche di cfengine e burattini sotto controllo di revisione per rispondere alla domanda.
• Controllo di revisione / ecc . Generalmente, i programmi Linux memorizzano la loro configurazione in un unico posto, / ecc. Gli audaci stanno iniziando a scrivere script per mettere / etc nel controllo di revisione. Uno di questi programmi che conosco è etckeeper :

Descrizione: store / etc in git, mercurial, bzr o darcs
 Il programma etckeeper è uno strumento per lasciare / etc essere archiviato in un git, mercurial,
 repository bzr o darcs. Si collega ad APT per eseguire il commit automatico delle modifiche
 fatto a / etc durante gli aggiornamenti del pacchetto. Tiene traccia dei metadati di quella versione
 i sistemi di controllo normalmente non supportano, ma questo è importante per / etc, ad esempio
 come le autorizzazioni di / etc / shadow. È abbastanza modulare e configurabile, mentre
 essendo anche semplice da usare se capisci le basi del lavorare con la versione
 controllo.

Uno dei problemi in questa situazione è che, in realtà, si tratta di un problema aziendale combinato / problema tecnologico. Ed è decisamente più grande del semplice monitoraggio delle modifiche apportate da un amministratore. È inoltre necessario tenere d'occhio le modifiche impreviste e un buon coordinamento tra amministratori o unità in modo che una modifica su un controller AD non rompa le impostazioni delle autorizzazioni del database su alcuni server dipartimentali. Cioè, la tua domanda è una lattina gigante di vermi :)

Nella mia organizzazione, abbiamo circa un anno per implementare processi e sistemi per affrontare questo problema. Per il lato dei processi aziendali abbiamo formato un team di gestione del cambiamento. Secondo SOP, tutte le modifiche agli ambienti di produzione sono coordinate attraverso di esse. Compilano tutte le modifiche, insieme all'ambito, ai sistemi interessati, ai servizi interessati, ecc. Applicano una buona documentazione sulle modifiche, nonché i piani di roll-out e roll-back. Organizza riunioni settimanali (aperte) per esaminare le imminenti modifiche dell'ambiente, quindi invia e-mail con i dettagli di tutte queste modifiche. L'obiettivo finale di questo processo è che, in modo efficace, tutti i membri dell'IT sappiano tutto ciò che sta succedendo. Questo aiuta a fermare il problema, ad esempio, di un amministratore di sistema che installa una patch del kernel e riavvia un sistema che eliminerà il database del timeclock.

Per quanto riguarda il lato tecnologico, posso parlare solo dei ragazzi Unix / Linux poiché non mi occupo di Windows. Hanno implementato Puppet, di Reductive Labs, per la gestione della configurazione di tutti questi sistemi. Semplicemente, è un sistema client / server in cui si definisce una configurazione della macchina sul server e il client tira queste possibilità ogni tanto (30 minuti per impostazione predefinita). Inoltre, se viene fatta qualche possibilità per i file gestiti localmente, vengono ripristinati anche in quel momento. Lo usiamo per gestire i servizi in esecuzione, le configurazioni del firewall, l'autorizzazione dell'utente, ecc.

Consiglierei anche di esaminare qualcosa come TippingPoint. È un servizio client che controlla la configurazione del sistema e invia avvisi sulle modifiche. Ci rende felici gli addetti alla sicurezza. È ampiamente utilizzato per tenere traccia delle modifiche dannose o non pubblicate.

Sono stato in 4 o 5 aziende ora non ricordo davvero.

Abbiamo avuto tutti questo problema. Nessuno di noi lo ha risolto al 100 percento, ma presso l'azienda che sono attualmente abbiamo quella che penso sia la migliore strategia fino ad oggi.

Sharepoint / wiki / Evernote / PIN

• Sharepoint
  • gemiti tutto quello che vuoi ... ha alcune caratteristiche dell'elenco molto belle.
  • Elenchi di indirizzi IP
  • inventario
  • account di servizio e utilizzo
  • cambia registri di notifica
• wiki
  • How-to
  • elenchi di attività a lungo raggio
• Evernote
  • io e il mio compagno usiamo questo per mettere tutto ciò che non vogliamo in Wiki
  • più istruzioni pratiche di natura tecnica
  • gratta e vinci che entrambi dobbiamo vedere
  • contabilità delle attività per la settimana
  • elenchi di attività del contraente
  • evernote clipper semplifica lo screening delle impostazioni AD / diritti
  • disponibile ovunque
• PIN
  • Repository password

Probabilmente ci sono strumenti migliori per alcuni di questi, ma questo è quello che usiamo:

• Tieni traccia delle modifiche alla configurazione e degli aggiornamenti / patch in base al server in un wiki privato
• Conserva anche gli howtos e un registro di problemi / soluzioni nella wiki
• Usa Sharepoint o Google Documenti per conservare copie autorizzate di cose come elenchi IP statici
• utilizzare Subversion per tenere traccia delle modifiche ai file di configurazione

Per Windows, controlla la serie Microsofts System Center o qualsiasi altro concorrente nella configurazione e nella gestione dei servizi per quella piattaforma.

Le modifiche devono essere instradate attraverso una routine di gestione delle modifiche decente che da sola le approva e le registra prima che vengano effettivamente eseguite. Questo può essere manuale al 100% per i principianti. Con alcuni dei migliori strumenti integrati potresti chiedere allo strumento di apportare le modifiche effettive e ottenere la disconnessione "automatica" da esso a un database di configurazione centrale, anziché andare a mani nude nella console di un singolo server, scavando manualmente tra le impostazioni per prova a risolvere un problema in stile cowboy.

Dovresti assolutamente attuare un processo di gestione delle modifiche, soprattutto se ci sono più persone che hanno la possibilità / l'accesso per apportare modifiche a livello di sistema nel tuo ambiente. Ciò fornisce anche un modo per la gestione di firmare su potenziali modifiche, tuttavia il rovescio della medaglia induce latenza nel processo di modifica se non è possibile apportare modifiche al volo.

Alcuni modi per tenere traccia delle modifiche potrebbero includere la convalida di eventi nel proprio SEM (supponendo che si disponga di un Security Event Manager) o strumenti come Nessus (con molto lavoro in grado di controllare l'ambiente per trovare le modifiche).

Questa è una risposta più localizzata, basata su * nix. Non ho trovato buoni strumenti per emularlo su Windows.

Ci sono alcuni modi per implementarlo ... e prenderlo quando lo dimentichi.

I sistemi di controllo delle revisioni come sovversione, git, cvs o RCS sono un buon modo per tenere traccia della cronologia di un file di configurazione. Se non si desidera installare un sistema di controllo delle revisioni sui server di produzione, l'archiviazione delle directory dei file di configurazione in locale o in remoto utilizzando qualcosa come rsnapshot offre la maggior parte dei vantaggi di un RCS, ma si perde la possibilità di controllare o lasciare commit registri (anche se questo potrebbe essere risolto con commenti all'interno dei file stessi).

Per aiutarti a ricordare di registrare le modifiche, la segnalazione automatica delle modifiche di configurazione tramite una corsa tripwire cronizzata di notte è un buon inizio. Dopo aver creato il database di tripwire dello stato corrente dei file, qualsiasi modifica ad essi produrrà un'e-mail durante la prossima esecuzione. Continuerai a ricevere questa mail fino a quando il database non sarà aggiornato, quindi "resettando" il tripwire.

Vorrei utilizzare un sistema di tracciamento dei problemi come flyspray (tutti lo faranno, ma mi piace flyspray per cose non di programmazione). Prima che qualcuno tocchi una configurazione, il miglioramento / problema dovrebbe essere registrato. Quando lo risolvi / implementalo, le modifiche vanno nel ticket.

Un wiki può essere utile per documentare la configurazione corrente, ma è facile che non sia aggiornato e sembra che ci voglia uno sforzo maggiore per aggiornare l'IMO.

Non troverai qualcosa di automatizzato per farlo, anche se probabilmente potresti configurarlo, quindi le modifiche a determinati file di configurazione vengono inviate automaticamente via e-mail al tracker dei problemi, se lo desideri.

Penso che si tratti solo di una buona politica, strumenti e disciplina a bassa barriera.

Abbiamo creato qualcosa di fatto in casa per effettuare il tracciamento dei cambiamenti nel nostro ambiente; non è niente di super complicato e funziona abbastanza bene.

• Una politica di auto-polizia è l'impostazione che qualsiasi cambiamento che nella tua stima devia da una configurazione pronta all'uso o che potrebbe potenzialmente causare problemi, dovrebbe essere documentato nel sistema di log delle modifiche.
  • il lato opposto di questa 'moneta' è se stai risolvendo un problema, cerca voci di registro recenti o correlate.
• Accedi al sistema e scegli il server, il servizio o il componente hardware che stai modificando
  • i componenti sono stati precedentemente inseriti nello stesso sistema con le informazioni "demografiche" di base (posizione, fornitore, numero di serie, dipartimento responsabile)
• Scegli da un menu a discesa di categorie di base
  • Tempo di inattività non programmato
  • patching
  • Manutenzione dell'hardware
  • Installazione software
• Inserisci i dettagli di ciò che hai fatto, visto, osservato
• una copia viene inviata alla parte responsabile e memorizzata come file XML indicizzati da un'appliance di ricerca.
• Profitto

Come ho già detto, niente di speciale. Utilizza PERL CGI (è stato scritto un miliardo di anni fa) e un'appliance di ricerca di Google per l'indicizzazione.

carenze:

• È difficile lavorare con gruppi di servizi, ad esempio, hai appena aggiunto la stessa patch a tutti i 25 controller di dominio; non abbiamo un gruppo "Controller di dominio", quindi dobbiamo selezionarli manualmente tutti
• Non si integra con l'hardware, il software o la segnalazione degli errori del registro eventi per facilitare la risoluzione dei problemi
• di conseguenza, l'inserimento manuale dei dati per tutti i dati "demografici" come ho detto sopra

Ad ogni modo, se dopo tutto quello che ti interesserebbe il codice, fammi sapere e probabilmente potrò prenderlo per condividerlo.

Come detto, è spesso un problema culturale - dopo tutto, alcuni negozi di sviluppo non si preoccupano più dei commenti (il codice di auto-documentazione è una parola d'ordine alla moda oggi!) E alcuni usano un sistema di controllo della versione come un santo graal di documenti storici. Ovviamente, questi non sono perfetti.

Quindi, l'unico vero modo per risolverlo è renderlo una soluzione culturale. Assicurati che tutti i motivi della modifica siano registrati in un tracker bug (o knowledge base o wiki) e assicurati che tutte le modifiche siano registrate in un sistema di controllo delle modifiche.

Abbiamo clienti dei servizi di emergenza, ogni cambiamento che accade al loro sistema viene registrato e ogni volta che accediamo al loro sistema, dobbiamo registrarlo. Per alcuni di loro, dobbiamo prima telefonare per avere il permesso (e immagino che anche loro lo registrino!). Ogni modifica viene registrata e sarà un reato disciplinare cambiare il sistema del cliente senza registrarlo.

Sembra oneroso, ma non lo è. Si prende rapidamente l'abitudine di aggiungersi al registro degli accessi e al registro delle modifiche - non è peggio che dover scrivere un commento quando si effettua il check in una modifica del codice.

Consiglio un bugtracker come log delle ragioni del controllo delle modifiche, dato che di solito sono facili da aggiornare (io uso Mantis).

Se stai cercando la "soluzione aziendale" (ad esempio, hai più soldi di Dio e vuoi avere uno strumento davvero interessante), lo strumento che ho usato per supportare e fornire lavoro in loco fa questo come una delle sue molteplici funzioni.

Non ho idea di quale sia il prezzo base, ma prima che HP acquistasse Opsware, era ~ $ 350.000 US (senza supporto e fidati di me - volevi supporto quando ho iniziato con Opsware).

Molti dei clienti che abbiamo avuto mentre lavoravo lì hanno utilizzato la configurazione dell'applicazione e le funzionalità di istantanea insieme a Tripwire .

Certo, se non hai budget, questa è una scelta sbagliata ™ :)

E, in seguito, l'annuncio che è apparso nella parte superiore di questa pagina per me quando l'ho ricaricato era per le spezie . Sembra potente simile a HPSA :)

Se tutto ciò che vuoi fare è tenere traccia delle modifiche e non gestire l'intero processo (ad esempio, tramite Chef o Puppet), solo la rsynctua etcdirectory (ovunque si trovi) in un repository git locale.

for HOST in alpha bravo charlie delta ...; do

    rsync -avz --exclude-from=exclusions -e ssh admin@$HOST:/opt/local/etc/ ./$HOST

done

Puoi ovviamente aggiungere altre fonti se necessario.