Categories
Uncategorized

L’aumento dei DevOps mentalità

TheMummichogblog è un partecipante al Amazon Services LLC Associates programma, un programma di affiliazione pubblicitario progettato per fornire un mezzo per siti per guadagnare tariffe pubblicitarie con la pubblicità e il link al amazon.com. Amazon, il logo di Amazon, AmazonSupply, e il logo AmazonSupply sono marchi di Amazon.com, Inc. o delle sue affiliate.

--------------------------------------------------------------------------------------------------
Booking.com
Colui che non aveva conosciuto peccato, Dio lo trattò da peccato in nostro favore, perché noi potessimo diventare per mezzo di lui giustizia di Dio.
----------------------------------------------------------------------------------------------

L’aumento dei DevOps mentalità
DevOps è diventata una di quelle parole d’ordine con molte definizioni contrastanti. Che cosa è per certo è che è in aumento. Nel nostro sviluppatore Survey 2020, circa l’80% degli intervistati ritiene che DevOps è almeno un po ‘importante. Prendiamo uno sguardo al fenomeno, alcune definizioni, e parlare con i nostri tecnici su alcune delle …

DevOps è diventata una di quelle parole d’ordine con molte definizioni contrastanti. Che cosa è per certo è che è in aumento. Nel nostro sviluppatore Survey 2020, circa l’80% degli intervistati ritiene che DevOps è almeno un po ‘importante. Prendiamo uno sguardo al fenomeno, alcune definizioni, e parlare con i nostri tecnici di alcune delle tendenze nostre statistiche del sondaggio sono riflettenti.

Qual è DevOps e perché è così popolare?
I problemi DevOps cerca di affrontare sono nel nome. Ha lo scopo di superare il divario istituzionale tra la squadra che scrive il codice (Dev) e la squadra che gestisce l’infrastruttura e gli strumenti utilizzati per eseguire e gestire il prodotto (Ops). Come i cicli di vita di sviluppo del software diventano più complessi, si è arrivati ​​più difficile tenere traccia delle responsabilità per l’esito e più facile da incolpare altri reparti per i colli di bottiglia, scadenze in ritardo o carenze nella qualità del prodotto.

Dev, QA, ed i gruppi Ops spesso ulteriormente frammentate possono essere inconsapevoli delle reciproche posti di blocco, hanno poca comprensione del contesto aziendale, o anche puntare per opporsi obiettivi. Sfiducia sta danneggiando l’organizzazione e le foglie tutti i soggetti coinvolti infelice.

Tom Limoncelli, Site Reliability Engineering Manager presso Stack Overflow messo i punti di dolore breve e semplice: “Il ciclo di vita di sviluppo del software nella maggior parte dei luoghi è rotto. DevOps aiuta a sistemare le cose.”

I DevOps termine incarna la soluzione ad una delle domande più cruciali del nostro tempo: il valore di business come team di sviluppo software in grado di fornire la migliore? La risposta? Gli sviluppatori e operazioni che lavorano insieme (DevOps) anziché in isolamento

Se DevOps tiene a ciò che promette, i benefici possono includere una maggiore frequenza di distribuzione, il time-to-market più veloce, più basso il fallimento di nuove uscite, e più breve tempo tra le correzioni. Con i vantaggi di una maggiore prevedibilità, l’efficienza, la sicurezza, e la manutenibilità spuntando lungo il ciclo di vita completo. O, per dirla semplicemente, come Teresa Dietrich, Chief Product Officer di Stack Overflow, “La cultura DevOps destra in ultima analisi, rende il prodotto si esprime meglio.”

Con il 44% di questo anno di Stack Overflow per sviluppatori intervistati lavora in aziende con almeno un dipendente DevOps dedicato, molti team di ingegneri di tutto il mondo stanno cercando di ridurre alcuni dei dolori di sviluppo del software moderno.

Così come si possono DevOps mantenere le sue promesse?

Quali problemi si DevOps cercando di risolvere?
Ad alto livello, DevOps ha tre pilastri: Comunicazione, Automazione e Misura. Lo Stato di DevOps relazione ha rilevato che le aziende riuscire a DevOps condividevano questi fili comuni.

pausa di lasciare che giù un po ‘di più e dare un’occhiata a alcune pratiche DevOps insieme ai problemi che stanno cercando di affrontare.

Dal silos a One-team-pensiero

Devs principalmente lavoro con sviluppatori, ingegneri operazioni in primo luogo il lavoro con gli ingegneri delle operazioni, gli ingegneri di infrastruttura concentrarsi sui propri problemi infrastrutturali. E ‘facile finire isolato.

Diversi dipartimenti e gli esperti hanno bisogno di cominciare a pensare come una squadra, verso un unico obiettivo. Al fine di rendere le squadre lavorano insieme senza attriti ci deve essere un cambiamento culturale e gli strumenti in atto per favorire la trasparenza.

Questa idea è descritta dalla ampiamente citato Gene Kim come una transizione uniforme tra tutti i passaggi SDLC, dall’identificazione dei requisiti, per costruire realmente l’applicazione (s), allora il codice mano verso operazioni IT, e infine consegna al cliente.

Mai piu ‘al mese inferno’ durante la stampa

Quando silos prevalgono, la maggior parte delle aziende si sentiranno una maggiore dolore tra Devs e Ops intorno implementazioni delle applicazioni.

Limoncelli ricorda dal suo tempo presso altre società, quando le nuove versioni destinate giorni o settimane di implementazione manuale non era raro per questo coinvolgere lavorare durante il fine settimana. Molti posti hanno ‘mese inferno’: un periodo di stress di tempo in cui tutti si è affrettata a finire un rilascio e distribuirlo. In alcune aziende capita più di 12 volte l’anno.” Con le buone pratiche DevOps, spariscono quelle ‘mesi Hell’. L’automazione è una parte importante di eliminare l’inferno mese. Questo impedisce burn-out, riduce l’attrito e rende le aziende più sostenibili.

Allo stesso modo, lo Stato di DevOps relazione evidenzia la necessità per le squadre di consegna di standardizzare i loro modelli e componenti. Gli autori del rapporto riconoscono che la complessità di questo compito è molto variabile. “Alcune squadre fanno senza pensarci troppo. Altri, in particolare quelli che ereditano il codice da ogni parte di un’organizzazione, devono adottare un approccio metodico verso l’eliminazione delle variabili e di raggiungere la standardizzazione.”

Tuttavia, Limoncelli è convinto che il cambiamento sta avvenendo. Lui è contento di vedere cambiamenti nella cultura. Dal punto di vista delle assunzioni, mi dice che la mancanza di “mesi Hell” usato per essere un “perk” solo poche aziende in grado di offrire. “Alla fine”, egli prevede, “le aziende che non hanno buone pratiche DevOps avranno difficoltà a noleggio a tutti.”

La standardizzazione pile tech e percorsi pigri

Ci sono molte ragioni storiche o, a volte politici per inutili complessità e la variazione. Così la standardizzazione come parte del processo di automazione rende più facile.

Andi Mann, Chief Technology Advocate a Splunk, scrive nello Stato di DevOps riferiscono che le aziende di successo mostrano un ‘sforzo concertato per normalizzare la pila e di sbarazzarsi di valori anomali o fiocchi di neve che devono essere mantenuti, testato, e gestito come una tantum. ‘gli autori includono la costruzione di un set standard di tecnologia, mantenendo le configurazioni delle applicazioni di controllo di versione, testare modifiche all’infrastruttura prima della distribuzione, e rendere il codice sorgente a disposizione di altre squadre come passi essenziali per le prime fasi di DevOps.

Per una nuova prospettiva su come fare DevOps un successo, Limoncelli suggerisce lotta per ‘basso contesto’.

Un sistema di basso contesto, invece di uno con elevata contesto, richiede poca conoscenza a priori. Il semplice esempio Limoncelli mi ha dato è la seguente: segnaletica aeroporto è facile da capire per tutti, i viaggiatori provenienti da tutto il mondo possono avere bisogno di sapere come raggiungere il bagno (se siete fortunati). Mentre i costumi a una cena di famiglia, e il rapporto complicato tra tutti i partecipanti, si imparano per decenni senza essere scritto.

Limoncelli crede DevOps squadre sono più efficaci quando si sforzano di creare un ambiente di lavoro a basso contesto. Ad esempio, egli sostiene che il modo migliore per convincere la gente ad adottare una pratica consigliata è quello di rendere il ‘percorso pigro’. “Se il tuo default per gli strumenti fondamentali come la CI / CD e Git soddisfa le vostre pratiche raccomandate, si stanno facendo fare la cosa giusta lo stesso di fare la cosa facile. Vuoi che la gente a cadere nel pozzo di successo. “

Se volete saperne di più sulla creazione di un ambiente a basso DevOps contesto, clicca qui per vedere webinar di Tom (gratuito, richiesta la registrazione).

Ripetendo un processo e perfezionare viene espresso anche da Gene con “ripetizione e la pratica [come] il prerequisito per padronanza”.

Lo Stato di DevOps parla il riutilizzo della costruzione di blocchi in questo contesto. Essa sottolinea che questo non solo consente di risparmiare la squadra che migliora anche la ‘consuma’ un momento in blocco di costruzione e fatica, attraverso il feedback sui modelli condivisi sul utensili utilizzati in tutta l’organizzazione.

Parlando di feedback: questo è un altro abilità da padroneggiare per DevOps.

Dal dito puntato verso anelli di retroazione

Se date i vostri colleghi il beneficio del dubbio, che si dovrebbe, allora si può supporre un problema solo viene preso a calci fino alla prossima squadra verso il basso il ciclo di sviluppo a causa della mancanza di informazioni o di comunicazione. La risposta a questa domanda è: la quota maggiore.

Come Gene sottolinea “Con la condivisione viene fiducia e con la fiducia arriva maggiori livelli di collaborazione.” Nella sua teoria olistica della DevOps, anelli di retroazione sono uno dei suoi tre “modo di DevOps” principi.

Come uno stack overflow utente scrive di ciclo di Gene “questo è realizzato attraverso l’integrazione continua / consegna / distribuzione e condiviso di monitoraggio e di allarme.” Gli autori dello Stato della DevOps Rapporto eco questo. Vedono il monitoraggio self-service e di allarme come uno degli antidoti per l’anti-modello di dev e ops lavorano in silos. “L’accesso semplicemente aprendo a questi parametri chiave permette una cultura di condivisione, popola cicli di feedback, permette un feedback continuo, e promuove una cultura di apprendimento continuo tra i team.”

Secondo Gene, questo ciclo di feedback da Ops torna Dev significa che ogni sviluppatore dovrebbe lavorare verso la comprensione di feedback tutti i loro clienti. Qui vede dipartimenti su tutta la linea come clienti interni.

Limoncelli vede anche DevOps annunciando la fine della cultura dito puntato, “bisogna essere in due al tango,” Gli piace metterlo. “I miglioramenti non possono essere effettuate solo Devs o Operazioni (ingegneri operazioni, amministratori di sistema, tecnici di produzione, SRE) in quanto tali. DevOps è di avere responsabilità condivisa e quindi la cooperazione.”

Fare amicizia con insufficienza

I DevOps mentalità non solo comporta sempre meglio a passare sul feedback di errori. Significa sempre meglio a commettere errori, in primo luogo.

Il Blog Miglior Linux Nella Unixverse
@nixcraft
Fare errori è umano.

automatizzandoli è DevOps.

550
02:21 – 3 DICEMBRE 2017
Twitter Ads informazioni e privacy
277 persone stanno parlando di questo
Uno dei pilastri descritti da Gene è continua sperimentazione, e sottolinea l’importanza di prendere rischi e di apprendimento da quel fallimento. Tim Hunter, il cui introito su di Gene tre modi è entrato canone ufficiale, spiega che DevOps persone hanno bisogno di “interruzioni di pratica e [a] trovare modi innovativi per trattare con loro.”

Entrambi scrivere su DevOps come dare le squadre la fiducia necessaria per spingere contro le limitazioni, perché non v’è un processo a ripiegare su e gestire i risultati. iterazioni più frequenti e risultato positivo in un prodotto migliore.

DevOps come self-service

Nota che lo Stato di DevOps relazione comprende self-service nella loro quinta e ultima fase di stadi archetipici di successo DevOps. Così si potrebbe considerare come raggiungere più alti stadi di DevOps.

Ecco l’attuazione della filosofia org dovrebbe permettere a tutti lungo il ciclo di vita per ottenere l’accesso a servizi interni, tra cui lo sviluppo, la gestione, la sicurezza, ITSM, e altre aree funzionali.

Rendere questi self-service consente ai team e gli individui a lavorare alla loro velocità, senza dover aspettare che le cose come i biglietti da approvare, le chiavi di licenza di ottenere, configurazioni necessarie per essere installato, o Sara di tornare dalle vacanze.

Un requisito importante per questo, secondo lo Stato di DevOps relazione, è che Ops fornisce sistemi e configurazioni per essere utilizzati da QA e Dev che hanno l’ambiente di produzione finale. Senza questo, il software è spesso testato in un ambiente che è dissimile dalla produzione. infrastrutture self-service aiuta ad avere i due ambienti siano il più possibile simili.

Strumenti: Quali sono gli strumenti che definiscono?
Strumenti non magicamente risolvere i problemi. Tuttavia, le pratiche migliori richiedono lo strumento giusto. Che speravano alcuni nomi per essere nominato?

Sulla rete sorella di Stack Overflow abbiamo una comunità Stack scambio DevOps dedicato. La maggior parte degli ingegneri DevOps passano il loro tempo con noi su questo sito così come Stackoverflow.com. Questi tag sono una abbastanza buona indicazione di quello DevOps ingegneri stanno lavorando con questo momento.

Senza ulteriori indugi, i 30 argomento Top Tag su DevOps:

Il vostro kit DevOps strumento sarà molto probabilmente includerà:

Lavoro Tracking: Asana, Lunedi, Jira,
controllo del codice sorgente: Git, Github, GitLab, BitBucket, TFS
CI / CD: Jenkins, squadra della città, Github azioni
Fonte analisi del codice: SonarQube
gestione Artefatto: Artifactory, Docker Container Registrati
Configuration Management: Terraform, Ansible, PowerShell / DSC, Puppet, (che sono dietro lo Stato di DevOps relazione) e Chef
Contenitore di orchestrazione: Docker, kubernetes
Monitoraggio: Prometheus
Per migliorare ulteriormente gli strumenti di automazione, infrastrutture virtuali consentono alle organizzazioni di configurare un server in modo automatico. Amazon Web Services e Microsoft Azure sono esempi di infrastrutture virtuali.
Nota: La maggior parte di questi DevOps tag hanno risorse di conoscenza enorme su Stackoverflow.com. Come per molti DevOps cose, non pensare ad esso come una pila di tecnologia rigida. La realtà più probabile sarà strumenti che sono debolmente accoppiati con quelli adiacenti nel ciclo di vita dell’applicazione.

DevOps ovunque?
Ha percorso una lunga strada dal giorno alla conferenza Agile di Toronto nel 2008, quando la discussione intorno a come Ops e Dev potrebbero migliorare la collaborazione notoriamente attratto solo un pubblico di uno. Al contrario, Stack Overflow sondaggio sviluppatore 80% di quest’anno degli intervistati ritiene che DevOps è almeno un po importante.

Inoltre, 44% rapporto di lavoro in un luogo con almeno un dipendente DevOps dedicato. Vediamo anche la crescente domanda riflette nel cartellino del prezzo su esperti del settore. La specializzazione si colloca ai vertici del PayScale per i singoli contribuenti.

Top sviluppatori di guadagno nel 2020.
Non solo, se si conto per esperienza, vediamo che DevOps comando uno stipendio sproporzionatamente superiore rispetto agli sviluppatori all’interno di un analogo livello di esperienza in ruoli diversi.

Anche se quest’anno circa il 12% del nostro Developer Survey partecipanti auto-identificato come DevOps specialisti, il processo di adozione di un DevOps mentalità non può mai significare assumere uno di quegli specialisti ben pagati con DevOps nel titolo di lavoro e di essere fatto con esso. DevOps ingegneri devono costruire strumenti e persone in pullman sulle pratiche DevOps. Il modo sbagliato è quello di avere una squadra DevOps dedicato che si prevede di fare il lavoro per gli altri, e con questo la creazione di un nuovo silo. Esattamente quello che DevOps è stabilito di abbattere.

Leadership nello spazio viene da alcuni dei soliti noti, ma non è limitata ad essi. Come i DevOps mentalità è interpretato in una squadra da basi squadra possono essere diversi. E come si evolverà per incorporare i team di sicurezza in un approccio olistico allo sviluppo del software come best practice è emozionante da guardare.

Si dice solo pochi unicorni (si pensi. Netflix, Amazon o Google) mai raggiungere il continuo distribuzione ideale della “Distribuzione tutta la strada in produzione senza alcun intervento umano.

Ero curioso di sapere dove i dipendenti Stack Overflow avrebbero messo sul spettro. Le persone con cui ho parlato (per lo più SRE) tutti sembrano essere d’accordo, siamo da qualche parte nel mezzo.

Tom Limoncelli, Site Reliability Engineering Manager a Stack Overflow, vede l’azienda al momento tre delle cinque stelle per DevOps eccellenza. Ha anche alcuni progetti ambiziosi in cantiere per migliorare ulteriormente la nostra operazione. “Chiedimi di nuovo in un anno!” esclama.

L’introduzione di DevOps è un enorme cambiamento organizzativo. Non ci sono senza dubbio rischi. Quindi è necessario una certa curiosità e impegno. Spafford a Garner una volta ha detto come “DevOps sfida convenzionale pensando che, la sua costante evoluzione, e la sua richiesta di accettazione e gestione del rischio.”

Con la mancanza di un approccio standard, a questo punto, non v’è una definizione, tuttavia, che si attacca con me. Si tratta di parlare con Chris Hunt, Site Reliability Engineer di Stack Overflow: “DevOps è come il cucchiaio in Matrix. Non sono gli DevOps che si piega, ma te stesso.”

Tags: elettronica, DevOps, StackOverflow

The rise of the DevOps mindset

Amazon e il logo di Amazon sono marchi di Amazon.com, Inc., o delle sue affiliate.