Mentre si lavora sul Cookbook Devops con i miei colleghi autori Gene Kim , John Willis , Mike Orzenstiamo raccogliendo un sacco di "devops" pratiche. Per qualche tempo abbiamo lottato con loro strutturazione nel libro. Ho pensato che ci mancava un modello mentale di mettere in relazione le pratiche / storie da.
Questo blogpost è un primo tentativo di fornire una struttura per codificare le pratiche devops . Il testo, le descrizioni sono il lavoro più o meno in corso, ma li ho trovati abbastanza importante da condividere per ottenere il vostro feedback.
Devops nella giusta prospettiva
Come probabilmente sapete ormai, ci sono molte definizioni di devops. Una cosa che appare di tanto in tanto è che la gente vuole cambiare il nome di estenderlo ad altri gruppi nella zona TI: star-ops, dev-qa-ops, sec-ops, ... Fin dall'inizio penso che le persone coinvolte nel pensiero prima devops avuto l'idea di ampliare il processo di pensiero oltre la semplice dev e ops. (Ma un nome di bus-qa-sec-net-ops sarebbe quella accattivante :).
Ho iniziato Refer a:
- devops : la collaborazione, l'ottimizzazione in tutta l'organizzazione. Anche al di là IT (HR, Finance ...) e confini aziendali (fornitori)
- devops 'lite' : quando la gente lo zoom su dev 'giusta' e la collaborazione ops.
Come giustamente sottolineato da Damon Edwards , devops non si tratta di una tecnologia, devops tratta di un problema aziendale . La teoria dei Vincoli ci dice di ottimizzare le intere e non 'silos "l'individuo. Per me quel tutto è il business al problema del cliente, o in magra dire, l'intera catena del valore. Colli di bottiglia e miglioramenti potrebbero essere succedere ovunque e hanno un impatto a livello locale da parte dev e ops della società.
Quindi, anche se il problema esiste in dev o ops, o da qualche parte tra, l'ottimizzazione potrebbe essere necessario fare in un'altra parte della società. Il risultato pre-descrittivi che descrive i passaggi per risolvere il problema 'devops' (se esiste un problema) sono impossibili. I problemi che stiamo affrontando all'interno della vostra azienda potrebbe essere molto diversa e le soluzioni al problema potrebbero avere effetti diversi / bisogni.
Se non pre-descrittivo, siamo in grado di raccogliere le pratiche persone sono state facendo per superare le situazioni simili. Ho sempre incoraggiato la gente a condividere le loro storie in modo che altri potessero imparare da loro. (Uno dei motivi principali devopsdays esiste) Questo aiuta nelle pratiche di cattura, l'avevo lasciato a metà per dire che sono buone o le pratiche migliori.
Attualmente un sacco di storie / pratiche ingrandimento di settori come la distribuzione, dev e la collaborazione ops, ecc metriche. (Devops Lite). Si tratta di una naturale evoluzione di avere dev e ops nel nome del termine e tenuto conto del contesto di persone che attualmente discutendo gli approcci. Mi auguro che in futuro questa discussione si espande per silos aziendali anche altri: fi sinergizzare HR e Devops (Spike Morelli) o si riferiscono i nostri parametri di informativa finanziaria.
Un'altra cosa da considerare è che un sistema / società è continuamente in movimento: ogni volta che qualcosa modifiche al sistema si può avere un impatto; Così non si può dare per scontato che i problemi, i colli di bottiglia non riemergere dopo un po ' tempo. Ha bisogno di continua attenzione. Questo sarà più facile se ci si avvicina ad una steady-state, ma ancora, devops quali la sicurezza è un viaggio, non una fine.
Oltre la semplice dev e ops
Andiamo zoom su alcune delle pratiche che sono comunemente discussi: il campo diretto tra 'dev' e 'ops'.
Nella maggior parte dei casi, 'dev' in realtà significa 'progetto' e 'produzione' dei ops dei regali. All'interno di progetti che abbiamo metodologie di tipo (Scrum, Kanban, ...) e nell'ambito delle operazioni (ITIL, Visble Ops, ...). Entrambe le parti hanno esteso la loro metodologia di progetto nel corso degli anni: dal punto di vista dev questo ha portato a 'consegna in continuo' e dal lato Ops ITIL è stato esteso, con ciclo di vita dell'applicazione (ALM). Entrambi hanno lavorato duramente sul ottimizzare la parte individuale della società e meno per l'integrazione con le altre parti. Tali metodologie avuto un momento difficile risolvere un collo di bottiglia che fuori dal loro 'autorità'. Penso che questo devops dove entra in gioco: si cerca la collaborazione attiva tra diversi silos in modo da poter iniziare a vedere il sistema completo e ottimizzare, ove necessario, non solo in silos individuali.
Aree Devops
Nel mio modello mentale di devops ci sono quattro aree "chiave":
- Area 1: Estendere la consegna alla produzione (si pensi Jez Humble): questo è dove dev e ops collaborare per migliorare qualche cosa sulla realizzazione del progetto alla produzione
- Area 2: prorogare l'operazione al progetto (si pensi John Allspaw): tutte le informazioni dalla produzione viene irradiata di nuovo al progetto
- Area 3: Embed Project (Dev) nelle operazioni: quando il progetto è co-proprietà di tutto ciò che accade nella produzione
- Area 4: Produzione Embed (Ops) in Project: quando le operazioni sono coinvolti fin dall'inizio del progetto
In ciascuna di queste aree ci sarà una bi-directonal interazione tra dev e ops, con conseguente scambio di conoscenze e retroazione.
A seconda di dove il più urgente collo di bottiglia 'current' si manifesta, è possibile affrontare le cose in diversi settori. Non c'è bisogno di cose primo indirizzo di area1 area2. Pensate a loro come punti di pressione che si può sottolineare, ma che richiede una pressione equilibrata.
Area 1 e Area 2 tendono ad essere più pesante sul lato strumenti, ma non è strettamente strumenti focalizzati. Area3 e Area4 sarà più legata alle persone e ai cambiamenti culturali come il loro 'portata' è a valle della catena.
Quando visualizzate in una tabella di questo ti dà:
Come si può vedere:
- la parte DEV e OPS continuare ad avere i propri processi interni specifici per il loro lavoro
- i due processi sono sempre allineati e le aree estendono sia DEV e OPS alla produzione e progetti
- è quasi come un doppio ciclo con area1 e area2 come il primo ciclo e area3 e area4 come il secondo ciclo
Nota 1 : queste aree sicuramente bisogno di 'orecchiabili' i nomi per renderli più facili da ricordare. Nota 2 : dopo Ben Rockwoods su "I tre aspetti della Devops" elenca già 3 aspetti, ma penso che le aree di renderla più specifica
Area Livelli
In ciascuna di queste aree, siamo in grado di interagire a strumenti tradizionali dei 'Livelli', processi, persone:
Così ogni volta che ho sentito la storia, cerco di mettere in relazione la sua pratica ad una di queste aree come sopra descritto e il livello è indirizzamento. Pratiche possono avere un impatto a diversi livelli in modo da io li vedo come 'tag' per etichettare rapidamente storie. Un altro vantaggio è che ogni volta che si guarda una zona, ci si può chiedere quali pratiche che possiamo fare per migliorare ciascuno di questi strati. Per avere un impatto massimo su ciascuno degli strati, è chiaro che l'approccio deve essere sovrapposti in tutti e tre.
Gli strumenti finali devops avrebbe sostenuto tutto il popolo e di processo in tutti questi ambiti, non solo in Area1 (distribuzione) o Area2 (monitoraggio / metriche). Pertanto un devops toolchain con strumenti diversi interagiscono in ciascuna delle zone più senso. Anche lo strumento di per sé non ne fanno uno strumento devops: Mangement sistemi di configurazione, come chef e marionette sono grandi, ma quando applicata in Ops solo non aiutano il nostro problema molto. Naturalmente Ops ottiene agilitity infrastrutture, ma non fino a quando non viene applicata alla consegna (fi per creare ambienti di test e di sviluppo) che diventa dei devops dei. Ciò dimostra che la mentalità della persona applicare lo strumento lo rende uno strumento devops non, lo strumento di per sé.
Area di maturità Livelli
Ora che abbiamo le aree e gli strati individuati, vogliamo tenere traccia dei progressi mentre iniziamo a risolvere i nostri problemi e le cose stanno migliorando.
Adrian Cockroft suggerito di usare i livelli CMMI per devops :
Livelli CMMI consentono di quantificare la 'maturità' del processo. Questo risolve un solo strato (anche se un altrettanto importante). In poche parole CMMI descrive i vari livelli come:
- Iniziale processo di imprevedibile e poco controllato e natura reattiva:
- Gestito Incentrato sulla natura del progetto e ancora reattivo:
- Definito : Incentrato sulla organizzazione e proattiva
- Quantively gestito : misurato e l'approccio di controllo
- Ottimizzazione : Focus sul miglioramento
Tutti questi livelli potrebbero essere applicati a dev, ops o devops combinati. Ti dà un'idea di quale processo livello è in, mentre si sta ottimizzando in una zona.
Un modo alternativo di esprimere livelli di maturità viene utilizzato dal modello di Continuous Integration Maturity . Si mette un insieme di pratiche in livelli di maturità: (consenso dell'industria)
- Intro : con controllo del codice sorgente ...
- Novizio : trigger build da commit ...
- Intermediate : distribuzione automatizzata di testing ..
- Avanzato : test funzionali automatizzati ...
- Insane : un continuo sviluppo alla produzione ...
Invece di concentrarsi sui proces soli, potrebbe essere applicato ad una serie di strumenti, processi o pratiche persone. Quello che la gente considera il più avanzato otterrebbe il massimo livello di maturità.
Pratiche, modelli e principi
Una pratica potrebbe essere qualsiasi cosa da un elemento aneddotico ad un approccio sistemico.Pratiche simili possono essere raggruppati in schemi di elevare ad un altro livello. Simile a Design Patterns il software che può iniziare le pratiche di raggruppamento devops nei modelli devops.
Pratiche e modelli si basano su principi ed è di questi principi di fondo che vi guideranno quando e di applicare il modello o la pratica. Questi principi possono essere 'presi in prestito' da altri campi come Lean, etc Teoria dei Sistemi, psicologia umana. I principi sono quelli che il manifesto è di circa agile per esempio.
Lentamente ci rivolgeremo alle pratiche -> modelli -> principi.
Nota: mi chiedo se ci saranno nuovi principi che emergono dalla stessa o da devops sarà applicare il principio esistente ad una nuova prospettiva.
Alcuni esempi pratici:
Qui di seguito sono 'pratiche' alcuni esempi codificate in un modello standard. Le pratiche / modelli / Principi non sono ancora molto ben descritto. Il punto è più che questo può servire come modello per codificare le pratiche.
Indicatori di Area
L'idea è quella di elencare parametri / indicatori che possono monitorati. I numeri come tale non può essere troppo essere rilevante, ma il tasso di variazione sarebbe. Questo è simile al monitoraggio della velocità del storypoints o il tracking del tempo medio di recupero.
Nota: ho paura di presentare questi come metriche da monitorare, quindi io li chiamo gli indicatori per ammorbidire questo.
Esempi potrebbero essere:
- Strumenti Layer: implementa / Giorno
- Livello di processo: Numero di richieste di modifica al giorno
- Persone Layer: Le persone coinvolte per deploy
Questo non è ancora concretizzati abbastanza, sto cercando di indovinare si baserà sulla mia ricerca fatto per la mia Velocity 2011 Presentazione (Metrics Devops)
Devops Scorecard
Per presentare i progressi durante il viaggio 'devops' si possono mettere tutte queste cose in una matrice bello, per avere una panoramica da dove ti trovi ad ottimizzare i diversi livelli e settori.
Ovviamente questo ha senso solo se non mentire a se stessi, il vostro capo, i tuoi clienti.
Team di progetto, team di sviluppo prodotti e NOOPS
Jez Humble parla spesso team di progetto in evoluzione per i team di prodotto: silos largere dividerà di non dall'abilità, ma per la funzionalità del prodotto che stanno consegnando. Teams Divisione del genere, ha il potenziale pericolo di creare nuovi silos. E 'ovvio questi gruppi di prodotti hanno bisogno di collaborare di nuovo. Si dovrebbe trattare di altri team di prodotto sono dipendenze esterne, proprio come Silos altri. Le aree di interazione sarà molto simile.
Inoltre è possibile vedere le NOOPS termine come lavorare con i team di prodotto fuori della vostra azienda, come ti affidi a SAAS per determinate funzioni. È importante non solo per integrare in ciascuna delle aree sullo strato utensili, ma anche dalle persone e strato di processo. Qualcosa che viene spesso dimenticato. Automazione e astrazione permette di andare più veloce ma quando le cose non riescono o addirittura si verifichino dei cambiamenti, la sincronizzazione deve avvenire.
CAMS e aree
L' acronimo CAMS (Cultura, automazione, misura, condivisione) può essere liberamente mappato sulla struttura aree:
- Automation sembra mappare Area1: il processo di consegna
- Misura sembra mappare Area2: il feedback processo
- Cultura a Area3: sviluppatori embedded in produzione
- Condivisione di Area4: ops integrati nei progetti
Naturalmente automazione, la misurazione, la cultura e la condivisione può avvenire in una delle zone, ma alcune delle aree sembrano avere una maggiore attenzione su ciascuna di queste parti.
Conclusione
Aree Devops, strati e livelli di maturità, ci danno un quadro per catturare nuove storie pratiche e può essere utilizzato per identificare aree di miglioramento relativi al campo devops. Mi piacerebbe feedback su questo. Se qualcuno vuole aiutare, mi piacerebbe aprire un sito web dove le persone possono entrare nelle loro storie in questa struttura e renderla facilmente disponibile per chiunque voglia imparare. Non ho i cicli della CPU troppo lasciato al momento, ma sono felice di ricevere questo andare.
Nessun commento:
Posta un commento
Nota. Solo i membri di questo blog possono postare un commento.