IT knowledge base
CTRL+F per cercare la tua parola chiave

Miti DevOps

DevOps è una parola d'ordine di marketing senza nulla dietro! O c'è comunque? Forse DevOps è un insieme di strumenti "giusti" o è una cultura così speciale. E chi dovrebbe farlo, cos'è un ingegnere DevOps? In una parola, ci sono alcune discrepanze nei concetti e ci sono molti miti . Alcuni sono completamente banali e pochi ci crederanno, e alcuni si radicano nelle menti di rispettati specialisti. Lo scopriremo insieme agli esperti DevOps'ers Alexander Titov e Ivan Evtuhovich ( evtuhovich ). Sebbene credano che DevOps sia una soluzione al problema di produrre prodotti digitali e chiamare un individuo nello stile del business russo.
Relatori : Alexander Titov e Ivan Evtukhovich rappresentano Express 42, una società di consulenza DevOps. Ci sono molte aziende famose tra i suoi clienti, ad esempio MTS, Raiffeisenbank, Alfa-Bank e altri.
Per 5 anni di lavoro, sono stati raccolti un sacco di miti su DevOps che esistono nella società. Nel loro rapporto al RIT ++ 2017, Alexander e Ivan hanno discusso di questo argomento. Ivan in tono perentorio annunciò la saggezza convenzionale e Alexander cercò di convincere il pubblico che questo era solo un mito.

Mito n. 1. DevOps può essere svolto da un reparto DevOps o da un ingegnere DevOps.

Per svolgere le normali attività DevOps, assumiamo ingegneri DevOps o creiamo un reparto DevOps, e questo è tutto: abbiamo DevOps completi nella nostra azienda!

Questa è una dichiarazione molto impegnativa che sentiamo costantemente. C'è un'enorme quantità di materiali che spiegano perché non ci sono ingegneri DevOps , perché non è necessario creare un dipartimento DevOps , ecc. Tuttavia, vengono visualizzati i reparti DevOps, gli ingegneri DevOps vengono reclutati e ci sono sempre più posti vacanti per gli specialisti DevOps.
Apparentemente, le persone non credono pienamente alle argomentazioni fornite negli articoli e nei rapporti. Proverò a raccontartelo di nuovo. Questa è la mia opinione personale, che è supportata dall'esperienza personale.
Vedo spesso questa situazione. Una società normale, non accade nulla fino a quando l'amministratore delegato o il consiglio di amministrazione non si ammala di trasformazione digitale . È una malattia altamente contagiosa che di solito si diffonde durante le conferenze degli amministratori delegati o del top management. Dopodiché, nella sua testa compaiono le parole Agile, DevOps, digitale, prodotto, ecc.. La persona riunisce i subordinati e dice: "Ragazzi, abbiamo bisogno di Agile, DevOps, digitale, guarda e fallo".
In effetti, non è compito del regista capirlo. Ha capito da solo, ad esempio, come aumentare le entrate, i flussi di valore e si è reso conto che questo è correlato l'uno con l'altro.
Quindi i ragazzi si riuniscono e iniziano a pensare a cosa farne. Leggi su Wikipedia su DevOps : "Una metodologia che riunisce sviluppatori, operazioni, test per la consegna continua del software . "
Nella loro azienda, la consegna del software è continua , distribuita una volta ogni 3 mesi. Gli sviluppatori e gli amministratori di sistema visitano continuamente le barre insieme: non ci sono problemi con l'interazione . Dobbiamo prendere una decisione volitiva e rinominare alcuni reparti in DevOps.
In definitiva, il reparto qualità viene rinominato DevOps o il reparto operativo, a seconda dell'esperienza delle persone che lo fanno. Ma cosa fare con questo reparto se ci sono ingegneri di qualità / problema? Questo è sbagliato e devono essere rinominati ingegneri DevOps.
I dipendenti vengono rinominati, vengono pubblicati nuovi posti vacanti . Rivedo regolarmente i lavori DevOps perché noi e i nostri clienti siamo alla ricerca di ingegneri. Puoi anche andare su hh.ru, My Circle e vedere i posti vacanti per gli ingegneri DevOps. Sono tutti così diversi!
È impossibile individuare qualsiasi standardizzazione o digitazione rigorosa: dalle persone che configurano una pipeline per Jenkins, ai tester che scrivono gli autotest; dagli esperti nell'implementazione su Amazon, a coloro che impostano il monitoraggio, implementano software, ecc. Tutte le possibili professioni che esistono nell'IT sono etichettate come ingegnere DevOps.
L'eccezione sono le piccole aziende che realizzano effettivamente prodotti digitali che hanno una reale fornitura continua di software. Cercano persone che siano all in one, perché è difficile individuare una qualifica separata . Quindi viene semplicemente delineata la posizione vacante di un ingegnere DevOps, in cui è scritto tutto ciò che è in generale: Jenkins, Ansible, Chef, Docker, Kubernetes, Silex, Prometheus. Mi piace che le persone spesso scrivano male i nomi delle tecnologie.

In generale, non sono contrario al nome DevOps engineer o al reparto DevOps. Ma la cosa più importante per cui è necessario DevOps è creare l'intero flusso di valore nell'azienda . DevOps dovrebbe coprire tutto, dalle analisi alle operazioni specifiche. Questa non è una professione separata o un ruolo dedicato, ma semplicemente un pezzo che risolve il problema della produzione rapida di prodotti digitali.
La prima menzione di questa parola risale al 2009, quando Patrick Debois disse in una conferenza:

- Abbiamo iniziato a utilizzare un nuovo approccio. Ora stiamo producendo prodotti digitali e abbiamo un problema: niente funziona come prima. Io da solo non posso risolverlo. Invito tutti alla comunità per capire come convivere con questo. Chiamiamo questo problema DevOps.

DevOps è la soluzione al problema della produzione digitale. Chiamare una persona in questo modo è nello stile della nostra attività russa: nessuna persona - nessun problema, c'è una persona - c'è una soluzione . Logica inversa.
Se stai cercando un tecnico DevOps, considera perché ne hai bisogno. Meglio individuare una competenza specifica e cercarla sul mercato che uno specialista incomprensibile.

Aiuto per persone frugali: di solito un amministratore di sistema con conoscenza di Docker da un ingegnere DevOps con conoscenza di Docker differisce non nella conoscenza, ma nel prezzo: il primo costa a condizione 90.000, il secondo - 150.000. Puoi risparmiare.

In precedenza, la frase "getta il lenzuolo sul muro" era popolare, quando lo sviluppo è stato messo in funzione - "Mettilo!", Lo hanno ributtato indietro - "Non si alza!". Con l'avvento del dipartimento DevOps, lo gettiamo oltre il muro due volte: in primo luogo, lo sviluppo nel dipartimento DevOps e quelli già nel dipartimento Ops.

Mito n. 2. DevOps riguarda l'assunzione di specialisti multi-sito che possono fare tutto

Ti dirò la mia interpretazione della provenienza di questo problema. Quando è iniziata l'intera storia di DevOps, sono stati davvero gli specialisti multi-sito a fare tutto il lavoro. Ad esempio, una persona stava costruendo una pipeline di consegna, impostando il monitoraggio, ecc. Io stesso ho iniziato con la stessa cosa e ho fatto tutto da solo, perché non sapevo a chi potesse essere affidato questo: ho bisogno di ricercare qui, rovinare qui, farlo lì. Di conseguenza, ero uno specialista multi-macchina che configurava Linux, scriveva in Chef e rovinava l'API per Zabbix, ecc. dovevo fare tutto.
Ma non funziona davvero .

Prestazione

  • 18 artigiani che possono realizzare da soli una spilla realizzano 360 spille al giorno
  • 18 artigiani, suddivisi in 18 specialità, realizzano 48.000 spilli.
Questo è un famoso esempio della crescita della produzione in un mulino a spilli dal libro di Adam Smith. In effetti, la storia di questi spilli non è stata inventata da lui, ma solo onestamente rubata dall'Enciclopedia britannica.
In realtà, questa logica non è andata da nessuna parte. Quando sento che gli specialisti dovrebbero essere interfunzionali, penso davvero che i team dovrebbero essere interfunzionali , ma in nessun modo sono specialisti. Altrimenti, arriviamo a una storia in cui abbiamo bisogno di produrre 48.000 pin e semplicemente non ci sono abbastanza persone.
Nel libro "Progetto" Phoenix ". Un romanzo su come DevOps cambia in meglio il business ”descrive la storia di Brandon, che fa tutto in azienda, e tutto è chiuso in lui, come un collo di bottiglia. Questa è solo la storia di un fantastico specialista multi-strumento.
Ma sorge immediatamente la domanda: se non assumi un operatore multi-macchina, chi assumerai? Non c'è una risposta chiara a questa domanda, il problema è che noi della nostra comunità russa ne parliamo poco. Amiamo abbozzare i problemi, ma a nessuno piace risolverli. Non ci concentriamo su specializzazioni specifiche per le persone DevOps.
Cercherò di evidenziare questi ruoli a grandi linee e ti inviterò a questo lavoro, perché senza dividere i ruoli, parleremo sempre di specialisti multi-strumento.

DevOps, altri ruoli:

  • Uno sviluppatore con una comprensione dell'architettura e del lavoro del software in produzione (scrive test e codice dell'infrastruttura)
In che modo questo sviluppatore differisce da un laureato di una tipica università russa? Uno sviluppatore di una tipica università russa sa come scrivere algoritmi - e questo è tutto. Lo sviluppatore DevOps non solo sa come scrivere descrizioni, ma sa anche come questa descrizione prende vita .
Sono arrivato all'IT dall'elettronica e quello che stava succedendo qui è stato sorprendente per me: la gente pensa che un diagramma schematico sia un prodotto funzionante. Un ingegnere elettronico non ha un tale mito in testa, ma nell'informatica sì.
Abbiamo bisogno di sviluppatori che sappiano che uno schema elettrico non è un prodotto funzionante . Ce ne sono pochi, provengono da aree adiacenti, ad esempio dall'elettronica. Le persone formate dalle università russe non lo sanno. Pensano che abbiamo scritto il codice - ok.
Se hai intenzione di implementare DevOps nella tua azienda, questa competenza è molto spesso più facile da costruire internamente : identifica il problema se non puoi, assumi una persona che formerà le persone, assegna loro le categorie necessarie, come lavorare con il software in produzione.
  • Ingegnere dell'infrastruttura (scrive i collegamenti dell'infrastruttura, fornisce una piattaforma per lo sviluppatore)
In effetti, questo ruolo è così ricco che può essere ulteriormente scomposto. Essenzialmente, include il product owner manager che possiede il prodotto della piattaforma di consegna continua e le competenze individuali delle persone che costruiscono la piattaforma di consegna continua. Ma questo è per le grandi aziende.
È più facile per le piccole aziende. Questo è un ingegnere che conosce bene il sistema di gestione della configurazione, sa che Docker, Kubernetes, può creare sulla base un processo di distribuzione del software continuo e darlo allo sviluppatore.
  • Sviluppatore di servizi infrastrutturali (DBaS, Monitoring as Service, Logging as Service)
Questi sono servizi che vengono forniti allo sviluppatore come prodotto. Nota, puoi andare su Amazon e acquistare questi servizi separati. Amazon può essere considerato un modello di ruolo DevOps, il che significa che ciò che vendono può essere coltivato internamente.
  • Release manager (gestisce il processo e le dipendenze)
Questa non è la persona che costruisce la build. Gestisce le dipendenze , le versioni, facilita i team per concordare gli ambienti di integrazione, supervisiona il lavoro della pipeline di consegna continua, ecc.
Spesso è un uomo, ma è una fata che dà la magia alla tua squadra in modo che possa fornire continuamente software.

Mito 3. Stiamo sviluppando un sistema IT aziendale e abbiamo DevOps dal 1995

Lo sviluppiamo da molti anni per un sistema IT aziendale e lo pubblichiamo ogni settimana. Tutti i tuoi DevOps sono solo ragazzi in jeans con i polsini che sono venuti e hanno cambiato ciò che siamo stati in grado di fare per molti anni.

A proposito, è piuttosto interessante che di solito in tali team, il processo DevOps si attivi effettivamente quando si verificano incidenti. In tali situazioni, i confini sono nettamente labili tra i singoli team di sviluppatori, tester, ecc. Hanno il loro processo, che è stato sviluppato nel corso degli anni. Non è affatto formalizzato , ma sembra davvero DevOps.
Da dove nasce questo mito?

Il punto è che le persone cercano di misurare la distribuzione continua del software in base ai rilasci per unità di tempo . Chiedono: "Se usciamo una volta alla settimana, è DevOps?" In generale, questo è un buon risultato. Ma in realtà, hanno cicli di rilascio diversi, anche all'interno dello stesso team, componenti di funzionalità separati. Allo stesso tempo, il ciclo di rilascio richiede tre mesi e vengono consegnati una volta alla settimana, in base a diversi cicli di rilascio. Si scopre un hack chiamato DevOps. In effetti, c'è stata una sostituzione di concetti.
Il punto principale di DevOps è fornire il time-to-market . Questo non è il numero di implementazioni per unità di tempo, ma il tempo che trascorre dalla scrittura della prima riga di codice all'implementazione in produzione . Qui l'indicatore di una settimana è già molto interessante e tre mesi non sono davvero cool. Questo non è più DevOps.

Il time-to-market è necessario alle aziende che realizzano prodotti digitali per fare del bene ai propri clienti. Un'azienda digitale è composta da uomini d'affari, proprietari di prodotti e altri e ingegneri che scrivono software. Di solito in queste aziende c'è un'enorme quantità di feedback, perché non lavorano personalmente con i clienti.
Uber non comunica personalmente con il cliente finché non è soddisfatto dei suoi servizi. In questo caso, la persona apre il telefono e lì ha Get, Yandex-taxi, Maxim. Può prendere una decisione e passare rapidamente a un altro giocatore. Pertanto, è necessario elaborare molto rapidamente il feedback del mercato, inoltre il mercato (clienti) è ancora in continua evoluzione.
Pertanto, il parametro principale che guida DevOps in un'organizzazione è il real time-to-market. Se hai un'azienda che non produce software digitale per grandi mercati, molto probabilmente nemmeno DevOps è necessario. È solo una parola d'ordine che ha colpito la testa del CEO e non l'ha compresa appieno.
Dall'esterno sembra qualcosa del genere.

Amazon in realtà distribuisce una volta ogni 11 secondi , ovvero possono essere necessari 11 secondi dalla scrittura del codice all'implementazione. In effetti, c'è molto lavoro dietro questo e un numero enorme di pratiche DevOps.

Pratiche DevOps per TTM

Ho delineato le principali pratiche DevOps che si concentrano esclusivamente sul time-to-market, senza il quale è impossibile ottenere un feedback continuo dai clienti e dal mercato.
  • Strategie di rollout ( rollout blue-green, canary release, a/b testing)
Sembra buono e piuttosto semplice: distribuiamolo allo 0,1% degli utenti. Ma per questo è necessario fare un lavoro straordinario, ad esempio passare da un'architettura monolitica a una a microservizi.
  • Monitoraggio continuo
Questo monitoraggio è come il test, quando lo sviluppatore sotto forma di codice descrive ciò che deve essere monitorato in produzione. Successivamente, l'artefatto viene girato insieme a una descrizione di ciò che deve essere monitorato e immediatamente in tutte le fasi della pipeline di consegna continua, tutto viene aggiunto al monitoraggio. Puoi effettivamente vedere cosa sta succedendo con l'applicazione.
Quando esegui l'implementazione dello 0,1%, puoi capire se il software funziona come dovrebbe o se c'è qualcosa che non va. È inutile eseguire il rollout dello 0,1% se non si sa cosa sta succedendo con il software.
  • Registrazione end-to-end
Ecco quando, per ID, puoi vedere nel sistema come sono cambiati i dati del cliente: qui è arrivato al front-end, da lì al back-end, poi alla coda, è salito in coda come lavoratore asincrono , il lavoratore asincrono è andato al database, ha cambiato lo stato della cache: tutto questo viene registrato. Senza questo, è impossibile scoprire cosa è successo nel sistema e anche il roll-out è dello 0,1%.
Immagina di aver deciso di distribuire del nuovo software a tutti i 2.000 visitatori del festival Russian Internet Technologies, ma non hai la registrazione end-to-end. Queste 2000 persone scrivono che non funzionano. Chiedi loro cosa non funziona, perché dal tuo punto di vista sta accadendo una sorta di poltergeist. Argomento inutile.
  • Autotest (come forma di accordo tra i team)
Il test automatizzato è noto da tempo, esiste da molti anni ed è stato utilizzato per migliorare la qualità del software. Qui gli autotest devono essere trattati in modo leggermente diverso, come una forma di accordo tra i team. I team, invece di risolvere una serie di piccoli problemi nel software durante l'integrazione, concordano sul fatto che ogni team scriva autotest e risolva questi problemi anche nella fase di sviluppo di un modulo, elemento separato, ecc. Scrivere autotest è una storia a parte.
Tutti gli elementi costitutivi descritti - pratiche DevOps per TTM - richiedono molto tempo e lavoro, se non inizi da zero, ma, ad esempio, riscrivi un monolite. Ma senza di loro non è possibile raggiungere un time-to-market elevato.

Mito 4: DevOps è lo strumento giusto

È possibile eseguire DevOps utilizzando gli strumenti "giusti": prendi Kubernetes, ricoprilo con Ansible, installa Prometheus, avvita la Mesosfera sul lato e avvolgila con Docker - e DevOps completo inizierà immediatamente nell'organizzazione!


In generale, questa è la solita vista ingegneristica, ma spesso accade così:

Ho già descritto quanto è necessario fare per passare alla consegna continua. Inoltre, dobbiamo ancora trovare un accordo all'interno della squadra. Se scriviamo autotest, si tratta esattamente dell'accordo all'interno del team, oltre al fatto che è necessario avere l'abilità di scrivere autotest.
Spesso, quando vogliono implementare DevOps, Kubernetes è installato, usato per un po', e poi si scopre che sarebbe più facile a mano, che ci sono molti componenti, a volte sono difettosi e finora tutto questo non è necessario.
Le unghie vengono semplicemente piantate con strumenti potenti. Naturalmente, DevOps non riguarda solo gli strumenti giusti . Ma allo stesso tempo, esiste davvero una classe di strumenti direttamente correlati a DevOps e creati dalla stessa community nata da Patrick Debois.
Per ognuno di questi strumenti ci sono anche le istruzioni per l'uso: non solo una descrizione di come installarlo o come funziona al suo interno, ma anche un manuale su come usarlo.
Ad esempio, quando installi Git, non capisci davvero come funziona l'hashing internamente. Qualcuno sa, qualcuno no, ma in generale questa conoscenza è inutile. È lo stesso con Kubernetes: questa conoscenza è necessaria solo agli ingegneri che la gestiscono. E gli ingegneri in giro devono sapere come lavorarci. È questa conoscenza che è importante, non dovresti dimenticartene.
Nei primi giorni della nostra azienda, avevamo un paio di implementazioni di Chef che gestivano la configurazione mentre eravamo in azienda. Non appena siamo partiti, lo Chef è rimasto in disparte e il processo è tornato al vecchio corso. Questi erano i nostri punti di riferimento, per così dire. Ma, tuttavia, abbiamo avuto storie del genere.

Mito 5. DevOps è una “filosofia”, una cultura speciale che è nata in Occidente e non può essere trasferita alle realtà russe.

Molti credono che ci sia un mitico west, dove mitici unicorni fanno mitici DevOps, e siamo scortesi l'uno con l'altro e DevOps non nascerà mai qui.

È una domanda molto difficile. In effetti, le tecnologie digitali nascono in team in cui funziona una mente molto aperta, il pensiero critico, ecc.
Perché quando lavori con un ecosistema complesso, e con gli occhi quasi chiusi, cioè hai una scatola nera e un gruppo di persone che la usano, devi davvero pensare molto.
Ma allo stesso tempo, la filosofia non è la cosa più importante. Ci sono anche conoscenze e competenze specifiche, ci sono strumenti e approcci che sono inclusi anche in DevOps. La presenza della cultura non dà luogo alla presenza dei processi necessari . L'emergere di una certa cultura in due giorni di formazione di allenatori appositamente formati non porterà da nessuna parte.
Inoltre, se dopo l'allenamento non inizi subito a fare qualcosa, tutto ciò che è stato messo in testa durante l'allenamento scompare e passa senza lasciare traccia. Noi, come persone che hanno condotto molti corsi di formazione, lo sappiamo per certo. Noi stessi siamo andati agli allenamenti. Questo non funziona.
Non basta imparare un nuovo modo di pensare , bisogna subito provare a farne qualcosa con le proprie mani - con gli strumenti che si usano, e preferibilmente su un compito reale.
Pertanto, DevOps non è solo una filosofia, ma una filosofia è parte di DevOps. Sono dell'opinione che DevOps faccia parte di una più ampia filosofia Agile . Esistono valori Agile e DevOps è incluso come un insieme di pratiche e strumenti di progettazione che aiutano a realizzare questi valori.

Mito 6. ITIL include già DevOps e non dovresti spacciare il vecchio per il nuovo. Le stesse pratiche vengono utilizzate in DevOps.

Sì, in effetti lo è. Ma posso dire anche più cool. Tutte le discipline che vengono utilizzate in ITIL sono nello stabilimento chimico, tra cui:
  • gestione degli incidenti;
  • gestione della configurazione;
  • cambio gestione;
  • gestione della capacità;
  • gestione della disponibilità.
Queste sono discipline generali dell'ingegneria . La gestione dei progetti ha già 100 anni, sono più o meno gli stessi: poiché operano molte fabbriche, finché esistono queste discipline. È solo che le discipline già esistenti un tempo sono state spostate sull'IT, che era in quel momento.
Questo IT è fondamentalmente diverso dall'IT che realizza prodotti digitali. Questo è un argomento separato per la conversazione. Il punto è che le discipline sono le stesse, ma il contenuto e il contenuto sono diversi : standard, approcci, metodi, strumenti.
Generalmente ITIL è fatto per qualcos'altro. Quindi, da un lato, sì, sono davvero simili, ma, dall'altro, non sono applicabili, non possono essere utilizzati.

Mito 7: DevOps è una parola d'ordine di marketing senza nulla dietro.

Tutti hanno appeso questa etichetta e tutto è diventato così DevOps, ma in realtà questa parola non significa nulla. Ricorda, c'è stato un periodo di massimo splendore per gli sviluppatori Agile Java, proprio come quello nei posti vacanti e scritto.

Ora toccherò un argomento molto polemico. I nostri colleghi integratori e grandi fornitori hanno ascoltato ciò di cui parlano i registi geniali e hanno rinominato i loro prodotti in prodotti DevOps. Quei prodotti che sono stati realizzati per il vecchio IT aziendale, e non per la produzione di un prodotto digitale, sono stati semplicemente rinominati - era HP OpenView, è diventato DevOps HP OpenView - e basta.
Questa è più o meno la stessa storia di ITIL.

Ma c'è una vera comunità che è nata dopo le parole di Patrick Debois. Un evento chiamato DevOps Days si tiene regolarmente e nel 2017 si è tenuto a Mosca. Ci sono circa 150 eventi di questo tipo nel mondo ogni anno e penso che ce ne saranno ancora di più.
Queste persone parlano di qualcosa, i normali tipi hardcore risolvono quelli normali, compresi i problemi di ingegneria, non solo quelli manageriali. Cioè, ha senso, e se ha senso, allora non è solo una parola di marketing.
Il mio consiglio per le persone che pensano che questa sia una parola di marketing è di prestare attenzione al contenuto che produce DevOps Days, non c'è il tocco del venditore e l'hype. La Russia ha anche un sacco di risorse:
  • https://www.meetup.com/DevOps-Moscow-in-Russian/
  • http://devopsdeflope.ru
  • https://www.2d1o.ru
  • http://hangops.ru
I problemi di DevOps sono discussi qui: puoi venire, ascoltare e capire che non c'è marketing in questo. Le persone fanno DevOps perché ne hanno davvero bisogno.
Domande e risposte

- Hai affermato che si è verificato un errore durante l'implementazione delle pratiche DevOps. Le persone hanno lavorato con te con Chef, e poi sono tornate. Quali sono le statistiche di tali rollback alle precedenti metodologie di lavoro nella tua pratica?

- Fino a un certo momento, fino a quando non eravamo impegnati in questo, era il 50%. La metà è tornata indietro perché non abbiamo detto affatto come lo facciamo. A proposito, questo è molto importante anche per coloro che sono coinvolti in DevOps. Se hai un trucco, devi trasmetterlo alle persone. Noi stessi non abbiamo capito che dovevamo raccontare tutto, metterlo in parole, essere d'accordo, ecc.
Nella nostra pratica, la parte tecnica dell'implementazione di DevOps è un quarto del lavoro . Le questioni organizzative, come coinvolgere le persone dell'azienda del cliente in questo processo, richiedono molto più tempo. Altrimenti, sarà davvero il caso che DevOps sia in disparte e il processo rimarrà lo stesso di prima.

- Come viene misurata l'efficacia dell'attuazione di queste pratiche?

- L'unico parametro è il time-to-market. Ma il fatto è che se cambi l'intero processo, il vecchio KPI perde il suo significato. Pertanto, diciamo che se sei interessato al time-to-market, ha senso che tu ci giochi, il KPI dovrà ancora essere rifatto. Ma fare DevOps pezzo per pezzo non è realistico.
È possibile misurare in singole fasi, ma se vengono apportate alcune modifiche a tratti, questi KPI non sono molto facili nel cuore, perché il processo complessivo è ancora negativo.

- Mi chiedo dalla tua pratica, è una tattica tutto o niente, o è possibile combinare DevOps con la vecchia tecnologia RUP a cascata? Se possibile, cosa, dove e come è segmentato?

- Con RUP, ovviamente, è possibile una combinazione. In genere è previsto un modello iterativo.
Ci sono due opzioni quando ti muovi in ​​questo modo:
  1. Il tuo management è abbastanza maturo e comprende che è necessario preparare il terreno per poter produrre prodotti digitali. Poi tutto va d'accordo, solo che è necessario, in base a ciò che è, costruire una pipeline di consegna continua, almeno in forma approssimativa, in modo che funzioni più o meno automaticamente. Lascia che non sia completamente monitorato, lascia che non siano schieramenti canarini, ma deve essere lì. Alle persone viene insegnato a lavorare con questo e si adatta normalmente a qualsiasi processo, devi solo capire i limiti in questo momento.
  2. Se stai già realizzando un prodotto digitale, molto probabilmente il processo Rup sarà restrittivo, perché ci sono così tante restrizioni. Allora questa storia di convivenza sarà deplorevole. Molto probabilmente, distruggerà semplicemente il processo Rup da sola, perché l'azienda dirà: "Dai, dai, presto! Più veloce! " - di conseguenza, si verificherà l'autodistruzione. Certo, è meglio quando si verifica una distruzione deliberata, ma se non si tiene conto di questo momento, può crollare in modo che tutto lo sviluppo crolli nel processo.

- C'è una cosa del genere ChatOps. Pensi che questa sia una parte integrante o è una cosa separata che non ha nulla a che fare con DevOps?

ChatOps è parte integrante. Come ho già detto, l'interazione degli sviluppatori è molto importante, compreso l'accordo sugli autotest. L'integrazione dei singoli componenti senza ChatOps è molto difficile.
Ad esempio, abbiamo implementato qualcosa, dobbiamo immediatamente recuperare i dati dal monitoraggio. Prima di tutto, abbiamo bisogno che il team che sviluppa questo componente dia il contesto di questo cambiamento immediatamente nella stessa chat. Quando ci integriamo, lanciamo il componente, gli ultimi log vengono pubblicati nella chat, tutti i messaggi di monitoraggio, i messaggi di sistema, i ragazzi hanno scritto lì che sono cambiati. Posso concludere rapidamente cosa c'è che non va nella mia domanda, o chiedere ai ragazzi di eseguire il rollback o risolverlo da solo rapidamente, ecc.
Pertanto, ChatOps è una delle pratiche essenziali nella fase di integrazione.

Questo articolo è una trascrizione di uno dei migliori discorsi al RootConf 2017, la conferenza Operations and DevOps nell'ambito del festival RIT++ . Il prossimo festival si svolgerà a fine maggio, e possiamo già parlarvi di alcune interessanti applicazioni:

  • Mikhail Kuzmin di JetBrains prevede di smantellare molte domande associate a questo processo di gestione dell'infrastruttura di consegna continua .
  • Ivan Glushkov di Postmates propone di trasferire l'esperienza di lavoro con i gestori di pacchetti convenzionali a k8s.
  • Insieme ad Alexander Khayorov (Ingram Micro Cloud), cercheremo di colmare le lacune e parleremo della magia della rete di kubernetes , dal pod all'ingresso.


Guarda l'elenco completo delle applicazioni per RootConf o per l'intero RIT ++ , scegli tu stesso il più significativo e questo è un link per prenotare i biglietti , il cui prezzo continuerà a salire.