Agile amministratore di sistema e devops - Come realizzare? [chiuso]

Al giorno d'oggi, l'amministrazione dei sistemi agili e gli sviluppatori sono alcuni degli argomenti più di tendenza riguardanti l'amministrazione e le operazioni dei sistemi. Entrambi questi concetti si concentrano principalmente sul colmare il divario tra operazioni / amministratori di sistema e progetti (sviluppatori, aziende, ecc.). Anche se non hai mai sentito parlare del concetto devops, sono sicuro che anche questo argomento sia di tuo interesse.

Quindi, quali strumenti e tecniche usi per realizzare gli sviluppatori nelle tue aziende? Sono particolarmente interessato ad argomenti come la gestione delle modifiche, l'integrazione continua e l'automazione, ma non solo su questi argomenti. Per favore, condividi i tuoi pensieri. Non vedo l'ora di leggere le vostre risposte / opinioni :)

• svn / git - controllo di revisione, ovviamente.

• trac / redmine / jira - ticketing.

• calzolaio - per il provisioning del server del sistema operativo di base. Cobbler è un prodotto focalizzato sulla famiglia redhat ma sono sicuro che ci sia qualcosa di simile per debian / ubuntu. Allo stesso modo la maggior parte delle società del "pannello di controllo cloud" come RightScale fornirà questo per te. La parola d'ordine qui è "JEOS" o "sistema operativo sufficiente". Il mio percorso è quello di utilizzare la riga "% pacchetti --nobase" nei miei kickstart e quindi costruire il mio stack specifico tramite ...

• burattino / cuoco - per la gestione della configurazione e l'applicazione della coerenza. Ci sono anche altre opzioni qui, è più importante che tu ne usi una rispetto alla quale. Un trucco che ho trovato particolarmente importante è quello di archiviare le configurazioni nello stesso sistema di controllo versione utilizzato dagli sviluppatori. Questo aiuta a riunire il flusso di lavoro dei due team e renderlo visibile l'uno all'altro.

• func (o capistrano o cluster-ssh) - per eseguire lo script deploy attraverso il cluster. Il trucco qui è quello di renderlo qualcosa che gli sviluppatori senior possano correre da soli per spingere le cose nuove dal vivo e spingere le inevitabili correzioni.
  Questo è davvero il nucleo di devops, che consente agli sviluppatori di rompere e riparare l'ambiente. Molti amministratori di sistema sono troppo assetati di potere per lasciarsi andare così, o la loro gestione lavora ancora sull'idea errata che gli amministratori di sistema dovrebbero essere gli sviluppatori di polizia (come se potessimo anche leggere la metà di ciò che stanno facendo).

• cactus / gangli / collectd / munin - i grafici sono davvero fondamentali. È il valore commerciale delle metriche con il valore umano di elementi visivi semplici. Correlare la data / ora del push del codice con la data / ora dei cambiamenti nei grafici è immensamente prezioso nella risoluzione dei problemi di regressione delle prestazioni e nella visualizzazione di fatti reali sulle decisioni relative alle prestazioni. C'è un punto chiave qui nel fatto che i grafici devono essere facili da vedere e usare dagli sviluppatori e il loro management deve aspettarselo da loro.

• nagios / zabbix / smokeping / etc - monitoraggio delle cose del server e metriche delle prestazioni di tipo "pagina base". Anche in questo caso i grafici sono fondamentali. Questi sono più per il lato operativo della squadra.

• gomez / keynote / browsermob - monitoraggio esterno delle prestazioni complete del browser, tenendo conto dei servizi di terze parti, delle CDN e dei problemi di tempo di rendering. Questi sono più per il lato sviluppo della squadra.

Questo è un mix di strumenti e tecniche, concentrarsi sulle tecniche. In particolare il cambiamento nella mentalità del lato "sysadmin" di devops da "admin" a "operazioni". Si tratta di abilitare gli sviluppatori. Consentendo loro di fare le cose, consentendo loro di sistemare le cose, consentendo loro di vedere fatti reali / metriche / grafici su ciò che hanno fatto. Al contrario, gli sviluppatori devono accettare di essere stati abilitati e svolgere effettivamente il compito di osservare le tendenze delle prestazioni, i problemi di debug e pensare non solo alle funzionalità ma a come implementarle e in che modo influenzeranno la salute dell'intero sistema / ambiente .

Stiamo lavorando per fare proprio questo su National Instruments. Puoi leggere di più su ciò che stiamo facendo su http://dev2ops.org/blog/2010/4/27/qa-ernest-mueller-on-bringing-agile-to-operations.html

Il mix di strumenti menzionati da Cagenut sta andando nella direzione in cui ci stiamo muovendo qui.

L'approccio migliore è comprendere l'ambiente in cui lavori. Inizia parlando con gli sviluppatori e i gestori. Cerca di coinvolgerli e rimbalza le idee. Molto probabilmente avranno una buona idea di come vanno le cose e se le tue idee per introdurre devops causeranno problemi.

Da lì, inizia a guardare le applicazioni e presentale una alla volta per risolvere i problemi.

Sebbene gli strumenti e le tecniche siano importanti, il percorso critico è la collaborazione nell'intera organizzazione. In questi giorni Operations è Business Operations. Etsy mostra i cambiamenti delle entrate sui loro dashboard, visibili a tutti.