Meniu

Colaborare în DevOps

collaboration devops

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Colaborare în DevOps:

Incrementări mici de livrări în DevOps a fost explicat în detaliu în tutorialul nostru anterior.

Știm că mantra cheie a DevOps este colaborarea și de aici a sosit cuvântul DevOps.

Citiți prin intermediul> Tutoriale în profunzime pentru DevOps

Colaborarea trebuie să se reunească ca o singură echipă pentru a rezolva orice problemă din program, ceea ce împiedică concentrarea în atenția clienților asupra programului și rezolvarea acestora, deținându-le drept propria problemă cât mai repede posibil, fără niciun joc de vina.

Colaborare în DevOps

Colaborarea îi învață pe toți să vorbească, să se întâlnească față în față, să se implice în întâlnirile lor, în discuții, să înțeleagă sarcinile, dependența și să aibă transparență în muncă și să lucreze proactiv pentru a preveni problemele.

VIDEO Partea 2 Blocul 5: Colaborare - 15 minute 36 secunde

Transcriere:

Termenul de colaborare este repetat din nou și din nou în DevOps, iar mantra Devops este colaborare. Așadar, să înțelegem ce înseamnă cu adevărat „colaborare” în contextul dezvoltării software și DevOps.

Potrivit meu, de îndată ce o organizație spune, implementăm DevOps, automat gândirea de colaborare care este atașată practicii devops începe în mintea tuturor și îi face să fie mai concentrați și mai atenți la colaborare și încep să simtă că trebuie să colaboreze. . Aceasta este magia colaborării.

Deci, inițierea colaborării DevOps chiar de la începutul proiectului este foarte esențială pentru organizație și echipă. Echipa vreau să spun, membrii echipei din program.

Voi explica câteva cazuri în care am văzut că Dev colaborează cu Ops și operează colaborând cu echipa de dezvoltatori, astfel încât să știm ce înseamnă de fapt colaborarea în contextul DevOps.

Aceasta este reprezentarea exemplului unu.

A existat o situație în care a existat o problemă necunoscută în scriptul de instalare sau în scriptul de configurare, care a găsit o provocare în instalarea software-ului pe o anumită configurație a unui cluster într-o anumită geografie.

A aruncat o eroare necunoscută și a fost o problemă pură de producție, care nu a apărut niciodată în mediul de dezvoltare și echipa de operațiuni a depus mult efort pentru a le rezolva singure, crezând că este ceva legat de configurare și trebuie să rezolve aceasta, care nu a fost rezolvată de mult timp.

Apoi, imediat echipa Dev a intrat fără a fi invitată să ajute, deși fusul orar a fost diferit, a preluat controlul site-ului de producție, știți că, în general, accesul la producție nu va fi acordat tuturor, Ops împărtășește doar eroarea detalii sau orice alte informații de care echipa are nevoie în scopul depanării.

Dar această situație este necesară pentru a oferi acces unuia dintre membrii echipei de dezvoltatori, care a dedicat cu dedicare câteva ore analizând problema în direct și a oferit o muncă imediată și, prin urmare, problema a fost rezolvată rapid.

Acesta este cazul colaborării în care echipa de dezvoltatori a deținut în mod voluntar problema și a ajutat echipa operatorilor să o rezolve. Acesta este un exemplu pur de colaborare.

În mod similar, un alt exemplu, permiteți-mi să arăt schematic acest lucru, pe care l-am desenat. Un alt caz este că lucrurile au funcționat destul de bine după actualizarea software-ului pe un anumit site timp de câteva zile, dintr-o dată performanța aplicației a început să încetinească.

Utilizatorii finali au început să se confrunte cu pierderi tranzacționale severe din cauza acestei încetiniri. O mulțime de apeluri de reclamații au început să vină la CSR, adică reprezentanții serviciului pentru clienți și aceștia, la rândul lor, au început să urmărească cu echipa problema.

În acest caz, imediat atât echipa Dev, cât și echipa Ops s-au reunit, iar cu informațiile și detaliile de telemetrie furnizate de echipa Ops echipei dev, au putut depana problema și a identifica că a existat o anumită problemă în aspectul partajării încărcării și prin urmare, performanța a fost lentă.

Deci, ambele echipe au lucrat împreună pentru a remedia problema și a readuce la normalitate în câteva ore. Deci, atât Dev, cât și Ops împreună au venit și au colaborat împreună pentru rezolvarea problemei, în loc ca Dev să spună problema Ops și Ops considerând că este problema lui Dev, iar echipa dev trebuie să o analizeze și să o remedieze.

Acesta este exemplul clar de colaborare în care toată lumea deține problemele, în loc să joace jocul de vina, indiferent de a cui este problema sau pierderea timpului pentru a afla a cui este problema, ținând cont de faptul că utilizatorul final suferă și problema are nevoie să fie reparat în curând.

Deci, din nou aici, problema nu trebuie să provină doar din producție, ar putea fi orice problemă simplă de dezvoltare software internă, la fel de simplă ca problema de zi cu zi, sau o problemă de proiectare, sau o problemă de arhitectură, sau chiar o simplă problema instrumentului.

Orice problemă legată de program sau orice problemă pe care echipa o știe, cauzează pagube clientului sau încetinește programul, trebuie să fie deținută de toată lumea, în loc să izoleze problema că este vorba de o problemă de dezvoltare sau de operațiuni sau o problemă de testare, și să contribuiți la abordarea acestuia cât mai repede posibil, este o colaborare.

Deci, colaborarea în contextul DevOps este dezvoltarea și operațiunile care se reunesc și lucrează împreună pentru a rezolva problema cât mai curând posibil, ținând cont de atenția clientului.

Colaborarea este atât Dev, cât și Ops care dețin ceea ce se întâmplă în direct, monitorizarea și înregistrarea și verificarea performanței fiind de top pentru a rezolva problema care apare mai ales în producție în interesul utilizatorului final.

SAU pur și simplu, pot spune, că întreaga echipă, lucrând constant împreună pentru a rezolva problema pentru a atinge obiectivele programului, ținând cont de atenția clienților este colaborarea. Repet, lucrând constant împreună pentru a rezolva problemele, pentru a atinge obiectivele programului, ținând cont de atenția clientului este colaborarea.

Apoi apare o întrebare, cum dezvoltăm această colaborare și când trebuie să inițiem colaborarea în rândul echipei, care stau la kilometri distanță unul de celălalt ??

Evident, știm că atât Dev, cât și Ops nu pot co-localiza. Echipa Ops trebuie să fie mai aproape de locul de lucru sau de centrele de date, iar programatorul trebuie să fie mai aproape de centrul de dezvoltare software. Deci, cum putem realiza colaborarea constantă între ambele echipe ??

În primul rând inițierea colaborării DevOps chiar de la începutul proiectului este foarte esențială pentru organizație și echipă. Echipa la care mă refer aici, sunt membrii echipei din program.

Practicarea câtorva dintre următoarele lucruri ar ajuta la reducerea decalajului dintre echipă și la depășirea constrângerii echipelor virtuale și va ajuta la realizarea colaborării.

Deci, să vedem care sunt acele practici care ajută la realizarea colaborării.

Implicați dezvoltarea în toate întâlnirile și discuțiile relevante ale echipei de operațiuni și invers.

Acest lucru nu numai că îi reunește, ci și ajută la înțelegerea fiecărei zone de lucru, a problemelor de zi cu zi și a modului în care munca lor se impactează reciproc și care sunt lucrurile critice de care fiecare ar trebui să aibă grijă ca să evite problemele ulterioare și prin urmare, îi apropie și inițiază de fiecare dată o discuție confortabilă între ei.

Înainte de introducerea practicii DevOps, echipa de dezvoltatori nu se preocupa niciodată de livrarea software-ului către operațiuni. Știți că obișnuiau să fie ignoranți sau să nu se deranjeze niciodată despre lucruri precum infrastructura, configurațiile, configurările serverului, configurațiile rețelei, monitorizarea performanțelor live etc.,

Ei obișnuiau să creadă că toate aceste activități sunt responsabilitățile echipei de operațiuni, iar echipa de dezvoltatori nu știa niciodată despre asta. Anterior, livrarea pentru echipa de dezvoltare a însemnat să fie livrarea numai echipei de operațiuni, dar cu practica DevOps, livrarea înseamnă producție și nu doar operațiuni.

În mod similar, operatorii nu se preocupau niciodată de codul pe care echipa de dezvoltare îl producea. Orice problemă cu care se confruntă în timpul instalării software-ului, funcționalitate sau probleme de performanță în producție, pur și simplu obișnuiau să transmită dolarul echipei de dezvoltare și să le ceară să o repare și să o dea înapoi.

Așadar, cunoașterea muncii reciproce și înțelegerea sarcinii lor și deținerea problemei reciproce pe tot parcursul ciclului ajută echipa să rezolve rapid problemele.

Pentru că știu unde este problema și ce se întâmplă în program și ce cauzează problema în producție și, prin urmare, pot merge direct și să o rezolve fără mari dificultăți.

Deci, colaborarea înseamnă că echipa de dezvoltare trebuie să înțeleagă infrastructura și configurația, iar echipa de operațiuni trebuie să se preocupe de cod, calitate, livrare și calendar.

Înțelegerea dependenței reciproce va ajuta la accelerarea lucrării și la livrarea la timp.

Ca și în timpul instalării software-ului, echipa de operațiuni depinde de o echipă de dezvoltare pentru a rezolva orice probleme legate de instalare. În mod similar, în timp ce codificarea echipei de dezvoltare depinde de o mulțime de condiții prealabile care există în direct pentru ca echipa de operațiuni să le asigure pentru a avea grijă în timpul procesului de codificare.

O alta Exemplu este echipa de testare care depinde de echipa de operațiuni pentru a furniza probe de date live din producție pentru testare. Detalii de configurare a mediului care trebuie configurate în mediul de dezvoltare etc.

Deci, ambele echipe trebuie să colaboreze reciproc și să înțeleagă dependența reciprocă și să furnizeze datele sau informațiile la timp, fără a provoca nicio întârziere, ținând cont de factorul de fus orar.

Mențineți transparența prin adoptarea practicilor DevOps, cum ar fi controlul sursei sau controlul versiunilor, care permite echipei să înțeleagă totul despre program și ajută la evitarea oricăror neînțelegeri.

Deci, aceasta este practic menținerea transparenței în interiorul echipei.

Membrii echipei nu trebuie să depindă de nicio persoană sau de o anumită informație, să spună dacă cineva dorește să cunoască configurația configurată la un anumit nod din cluster, deci nu trebuie să aștepte ca echipa de operațiuni să se trezească și le oferiți aceste detalii, mai degrabă pot merge la instrumentul de control al versiunilor și pot prelua aceste informații și își pot finaliza sarcina fără întârziere.

Învățarea reciprocă, în special din greșeala celorlalți, este cea mai mare caracteristică a colaborării. Pentru a nu repeta deja aceste greșeli făcute de altcineva.

Deci, dezvoltarea este învățarea din operațiune, iar operațiunile învață din dezvoltare, fie că este vorba de o nouă tehnologie, un instrument sau de a face ceva într-un mod mai simplu și mai bun. În cazul în care ambele sunt pe aceeași pagină și, prin urmare, colaborează între ele învățând unul de la altul.

Operațiunile au fost întotdeauna utilizate pentru a simți că echipa de dezvoltatori este foarte lentă și nu poate livra la timp, acum că interacționează cu echipa de dezvoltare în fiecare zi, înțeleg ce cauzează întârzierea, fie că este mai puțin clar cerințele, problema de proiectare, problema de codare sau orice altă problemă a instrumentului.

Chiar și ei prezintă și oferă sugestiile lor valoroase pentru a îmbunătăți.

De asemenea, în cazul oricărei probleme, fie de la producție, fie de la site-ul de dezvoltare, DevOps introduce o cultură de rezolvare a problemei mai întâi decât încercarea de a afla cine sau care echipă au introdus această problemă. Și astfel toată lumea încearcă să se concentreze pe remedierea problemei, mai degrabă decât pe pierderea timpului pentru a afla cine a cauzat problema.

Așadar, opriți vina și considerați problema fiecăruia ca fiind a lor și veniți în față pentru a le rezolva împreună și susținerea problemei, sprijinirea reciprocă în timpul problemelor lor este din nou o colaborare.

Așadar, pot spune că nu mai da vina pe joc, vina jocurilor este încă o dată o caracteristică a colaborării.

Când toată lumea începe să gândească în mod obișnuit în aceeași direcție, aceeași mentalitate și să lucreze la aceleași aspecte și practici este din nou o colaborare ca de fiecare dată când este dezvoltată o nouă caracteristică, toată lumea se gândește cum să testeze acest lucru, cum să implementeze acest lucru, cum să monitorizeze acest lucru, este o colaborare.

Deci, gândirea obișnuită, în cadrul echipei este o caracteristică a colaborării din nou.

cum se deschid fișiere apk pe Android

Să luăm o pauză acum și să înțelegem puțin mai multe despre colaborare în următorul nostru videoclip.

PREV Tutorial | NEXT Tutorial

Lectură recomandată

^