Menu

Collaborazione in DevOps

collaboration devops

Prova Il Nostro Strumento Per Eliminare I Problemi

Collaborazione in DevOps:

Piccoli incrementi di consegne in DevOps è stato spiegato in dettaglio nel nostro precedente tutorial.

Sappiamo che il mantra chiave di DevOps è la collaborazione e da qui è arrivata la parola DevOps.

Leggi tutto => Tutorial DevOps approfonditi

La collaborazione consiste nel riunirsi come un unico team per affrontare qualsiasi problema nel programma, che ostacola il programma di concentrarsi sul cliente e risolverli considerandoli come un problema il più rapidamente possibile, senza alcun gioco di colpa.

puoi usare qualsiasi auricolare vr per ps4

Collaborazione in DevOps

La collaborazione insegna a tutti a parlare tra loro, incontrarsi faccia a faccia, coinvolgersi a vicenda nelle loro riunioni, discussioni, capire i reciproci compiti, la dipendenza e avere trasparenza nel lavoro e lavorare in modo proattivo per prevenire i problemi.

VIDEO Parte 2 Blocco 5: Collaborazione - 15 minuti 36 secondi

Trascrizione:

Il termine collaborazione è stato ripetuto più volte in DevOps e il mantra di Devops è collaborazione. Quindi, cerchiamo di capire cosa significa veramente 'collaborazione' nello sviluppo del software e nel contesto DevOps.

Secondo me, non appena un'organizzazione dice che stiamo implementando DevOps, automaticamente il pensiero di collaborazione che è collegato alla pratica devops prende il via nella mente di tutti e li rende più concentrati e attenti alla collaborazione e iniziano a sentire che hanno bisogno di collaborare . Questa è la magia della collaborazione.

Quindi, avviare la collaborazione DevOps fin dall'inizio del progetto è molto essenziale per l'organizzazione e il team. La squadra intendo, i membri della squadra del programma.

Spiegherò un paio di casi in cui ho visto Dev collaborare con Ops e ops collaborare con il team di sviluppo in modo da sapere cosa significa effettivamente collaborare nel contesto DevOps.

Questa è la rappresentazione dell'istanza uno.

Si è verificato un problema sconosciuto nello script di installazione o nello script di configurazione in cui il team operativo stava trovando una sfida nell'installazione del software su una particolare configurazione di un cluster in una particolare area geografica.

Stava generando un errore sconosciuto ed era un puro problema di produzione, che non si è mai verificato nell'ambiente di sviluppo e il team operativo ha davvero speso molti sforzi per risolverli da soli pensando che fosse qualcosa correlato alla configurazione e che devono risolvere esso, che non è stato risolto per molto tempo.

Quindi immediatamente il team di sviluppo è intervenuto senza nemmeno essere invitato ad aiutare, anche se il fuso orario era diverso, ha preso il controllo del sito di produzione, sai che generalmente l'accesso alla produzione non sarà dato a tutti, Ops condivide semplicemente l'errore dettagli o qualsiasi altra informazione necessaria al team per il debug.

Ma questa situazione è necessaria per dare accesso a uno dei membri del team di sviluppo, che ha dedicato alcune ore ad analizzare il problema dal vivo e ha fornito un lavoro immediato e quindi il problema è stato risolto rapidamente.

Questo è l'istanza della collaborazione in cui il team di sviluppo è stato proprietario volontario del problema e ha aiutato il team operativo a risolverlo. Questo è un puro esempio di collaborazione.

Allo stesso modo, un altro esempio, permettetemi di mostrarlo schematicamente, che ho disegnato. Un altro esempio è che le cose funzionavano abbastanza bene dopo l'aggiornamento del software su un determinato sito per alcuni giorni, all'improvviso le prestazioni dell'applicazione hanno iniziato a rallentare.

Gli utenti finali hanno iniziato ad affrontare gravi perdite transazionali a causa di questo rallentamento. Molte chiamate di reclamo hanno iniziato ad arrivare ai CSR, voglio dire, ai rappresentanti del servizio clienti e, a loro volta, hanno iniziato a seguire il team sulla questione.

In questo caso, immediatamente sia il team Dev che quello Ops si sono riuniti e, con le informazioni ei dettagli di telemetria forniti dal team Ops al team di sviluppo, hanno potuto eseguire il debug del problema e identificare che c'era qualche problema nell'aspetto della condivisione del carico e quindi la prestazione era lenta.

Quindi, entrambe le squadre hanno lavorato insieme per risolvere il problema e riportarlo alla normalità entro poche ore. Quindi, qui sia lo sviluppo che le operazioni insieme si sono fatti avanti e hanno collaborato insieme per risolvere il problema, invece dello sviluppatore dicendo il suo problema operativo e gli operatori pensavano che fosse un problema dello sviluppatore e il team di sviluppo deve esaminarlo e risolverlo.

Questo è il chiaro esempio di collaborazione in cui tutti possiedono i problemi, invece di giocare al gioco della colpa, indipendentemente da chi sia il problema o perdere tempo a scoprire di chi è il problema, tenendo presente che l'utente finale sta soffrendo e il problema ha bisogno da risolvere a breve.

Quindi, anche in questo caso, il problema non deve essere solo dalla produzione, potrebbe essere qualsiasi semplice problema di sviluppo software interno, semplice come il problema quotidiano, o un problema di progettazione, o un problema di architettura, o anche un semplice problema dello strumento.

Qualsiasi problema relativo al programma o qualsiasi problema che il team sa che sta causando danni al cliente o rallenta il programma deve essere di proprietà di tutti, invece di isolare il problema che è un problema di sviluppo o un problema di operazioni o un problema di test, e contribuire a farlo affrontare il più velocemente possibile, è una collaborazione.

Quindi, la collaborazione nel contesto DevOps è lo sviluppo e le operazioni che si uniscono e lavorano insieme per risolvere il problema il prima possibile, tenendo presente l'attenzione del cliente.

La collaborazione è sia Dev che Ops possiede ciò che sta accadendo in tempo reale, il monitoraggio e la registrazione e il controllo delle prestazioni sono in primo piano per risolvere il problema che si verifica soprattutto nella produzione nell'interesse dell'utente finale.

O semplicemente, posso dire, che l'intero team, lavorando costantemente insieme per risolvere il problema per raggiungere gli obiettivi del programma, tenendo presente l'attenzione del cliente è la collaborazione. Ripeto, lavorare costantemente insieme per risolvere i problemi al fine di raggiungere gli obiettivi del programma tenendo presente l'attenzione del cliente è collaborazione.

Quindi sorge una domanda, come sviluppiamo questa collaborazione e quando dobbiamo iniziare la collaborazione tra il team, che è seduto a miglia di distanza l'uno dall'altro ??

Ovviamente, sappiamo che sia Dev che Ops non possono co-localizzarsi. Il team operativo deve essere più vicino al sito di lavoro o ai data center e lo sviluppatore deve essere più vicino al centro di sviluppo software. Allora, come si ottiene la collaborazione costante tra le due squadre ??

Innanzitutto avviare la collaborazione DevOps dall'inizio del progetto è molto essenziale per l'organizzazione e il team. La squadra che intendo qui, sono i membri della squadra del programma.

Praticare un paio delle seguenti cose aiuterebbe a colmare il divario tra il team e superare il vincolo dei team virtuali e aiuta a raggiungere la collaborazione.

Quindi, vediamo quali sono quelle pratiche che aiutano a raggiungere la collaborazione.

Coinvolgere lo sviluppo in tutte le riunioni e discussioni pertinenti del team operativo e viceversa.

Questo non solo li riunisce, ma aiuta anche a comprendere ciascuna delle loro aree di lavoro, i loro problemi quotidiani e il modo in cui il loro lavoro ha un impatto reciproco, e quali sono le cose critiche di cui ciascuno dovrebbe occuparsi per evitare i problemi in seguito e quindi li avvicina e avvia ogni volta una comoda discussione tra loro.

Prima dell'introduzione della pratica DevOps, il team di sviluppo non si è mai preoccupato di fornire il software alle operazioni. Sai che erano ignoranti o non si preoccupavano mai di cose come infrastrutture, configurazioni, impostazioni del server, configurazioni di rete, monitoraggio delle esibizioni dal vivo ecc.,

Pensavano che tutte queste attività fossero responsabilità del team operativo e che il team di sviluppo non ne fosse mai stato a conoscenza. In precedenza, la consegna per il team di sviluppo significava essere consegnata solo al team operativo, ma con la pratica DevOps, la consegna significa per la produzione e non solo per le operazioni.

Allo stesso modo, gli operatori non si sono mai preoccupati del codice prodotto dal team di sviluppo. Qualsiasi problema riscontrato durante l'installazione del software, problemi di funzionalità o prestazioni nella produzione, erano semplicemente soliti passare il denaro al team di sviluppo e chiedere loro di risolverlo e restituirlo.

Quindi, conoscere il lavoro degli altri, comprendere il loro compito e possedere i problemi degli altri durante tutto il ciclo aiuta il team a risolvere i problemi rapidamente.

Perché sanno dov'è il problema e cosa sta succedendo nel programma e cosa sta causando il problema nella produzione e quindi possono andare direttamente a risolverlo senza troppe difficoltà.

Pertanto, collaborazione significa che il team di sviluppo deve comprendere l'infrastruttura e la configurazione e il team operativo deve preoccuparsi del codice, della qualità, della consegna e delle tempistiche.

Comprendere la dipendenza l'uno dall'altro aiuterà ad accelerare il lavoro ea consegnarlo in tempo.

Come durante l'installazione del software, il team operativo dipende da un team di sviluppo per risolvere eventuali problemi relativi all'installazione. Allo stesso modo, durante la codifica, il team di sviluppo dipende da molte precondizioni esistenti in tempo reale che il team operativo deve fornire per prendersi cura durante il processo di codifica.

Un altro Esempio è il team di test dipende dal team operativo per fornire dati in tempo reale di esempio dalla produzione per i test. Dettagli di configurazione dell'ambiente da impostare nell'ambiente di sviluppo ecc.

Quindi, entrambi i team devono collaborare tra loro e comprendere la dipendenza l'uno dall'altro e fornire i dati o le informazioni in tempo senza causare alcun ritardo, tenendo presente il fattore del fuso orario.

Mantieni la trasparenza adottando le pratiche DevOps come il controllo del codice sorgente o il controllo della versione che consente al team di comprendere tutto ciò che riguarda il programma e aiuta a evitare qualsiasi malinteso.

Quindi, questo è fondamentalmente mantenere la trasparenza all'interno del team.

I membri del team non devono dipendere da alcun individuo o da qualsiasi particolare informazione, ad esempio se qualcuno vuole conoscere la configurazione impostata in un particolare nodo nel cluster, quindi non è necessario attendere che il team operativo si svegli e fornire loro questi dettagli, piuttosto possono andare allo strumento di controllo della versione e recuperare queste informazioni e possono completare il loro compito senza alcun ritardo.

Imparare gli uni dagli altri soprattutto dagli errori degli altri è la caratteristica più grande della collaborazione. In modo che non ripetano questi errori già fatti da qualcun altro.

Quindi, lo sviluppo sta imparando dall'operazione e le operazioni stanno imparando dallo sviluppo, che si tratti di una nuova tecnologia, di uno strumento o di fare qualcosa in un modo più semplice e migliore. Dove in entrambi sono sulla stessa pagina e quindi collaborano tra loro imparando l'uno dall'altro.

Le operazioni erano sempre abituate a ritenere che il team di sviluppo fosse molto lento e non fossero in grado di consegnare in tempo, ora che interagiscono quotidianamente con il team di sviluppo, capiscono cosa sta causando il ritardo, sia che sia meno chiarezza nel requisiti, problema di progettazione, problema di codifica o qualsiasi altro problema di strumento.

Anche loro stanno fornendo i loro preziosi suggerimenti per migliorare.

Inoltre, in caso di qualsiasi problema dalla produzione o dal sito di sviluppo, DevOps introduce una cultura di risoluzione del problema prima di cercare di scoprire chi o quale team ha introdotto questo problema. E così tutti cercano di concentrarsi sulla risoluzione del problema piuttosto che perdere tempo a scoprire chi ha causato il problema.

Quindi, smettila di incolpare e considerare il problema di ciascuno come proprio e di venire avanti per risolverli insieme e sostenere il problema, sostenersi a vicenda durante i loro problemi è di nuovo una collaborazione.

Quindi, posso dire, smettila di incolpare il gioco, incolpare il gioco è ancora una volta una caratteristica della collaborazione.

Quando tutti iniziano a pensare comunemente nella stessa direzione, la stessa mentalità e lavorare sugli stessi aspetti e pratiche è di nuovo una collaborazione come ogni volta che viene sviluppata una nuova funzionalità, tutti pensano a come testarla, come implementarla, come monitorarla, è una collaborazione.

Quindi, pensando comunemente, all'interno del team è ancora una volta una caratteristica della collaborazione.

Facciamo una pausa ora e capiamo poco di più sulla collaborazione nel nostro prossimo video.

Tutorial PREV | PROSSIMO Tutorial

Lettura consigliata

^