5 diferențe de bază între DevOps și SRE despre care ar trebui să știți
Publicat: 2021-02-22Lumea tehnologiei informației și a dezvoltării software combină adesea DevOps cu SRE pentru a însemna unul și același lucru. Cu toate acestea, există diferențe mari între cele două. În timp ce Site Reliability Engineering (SRE) a câștigat popularitate în ultimii ani, DevOps a existat mult mai mult timp (chiar înainte de a exista termenul DevOps).
Pentru a spune simplu, DevOps și SRE sunt ambele practici puse în aplicare pentru a furniza software-ul mai rapid. Singura diferență dintre cei doi este în abordările lor; DevOps se concentrează pe reducerea ciclului de viață al dezvoltării software, iar SRE se concentrează pe eliminarea punctelor slabe ale sistemului pentru a atinge același scop.
În acest articol, vom analiza modurile fundamentale în care DevOps și SRE diferă unul de celălalt. Înainte de a face asta, să începem cu a înțelege ce sunt DevOps și SRE.
Cuprins
Ce este DevOps?
În cuvintele lui Gene Kim, autorul Manualului DevOps și al Proiectului Phoenix,
„DevOps este [setul] de norme culturale și practici tehnologice care [permite] fluxul rapid al activității planificate, printre altele, de la dezvoltare, prin teste în operațiuni, păstrând în același timp fiabilitatea, operarea și securitatea de clasă mondială. DevOps nu este despre ceea ce faci, ci despre rezultatele tale.”
Deci, DevOps se concentrează în principal pe transformarea practicilor culturale din interiorul unei organizații pentru a accelera ciclul de viață al dezvoltării software (SDLC). Nu vizează o persoană, un grup sau o poziție. DevOps își propune să consolideze colaborarea atât între operațiunile de tehnologia informației, cât și echipele de dezvoltare software.
Ce face și cum face acest lucru nu este important; numai rezultatul procesului este recunoscut.
DevOps folosește un set de principii pentru a intensifica expunerea echipelor de inginerie software la sistemele de producție și permite echipei de operațiuni IT să escaladeze discrepanțele către echipa de dezvoltare mai eficient. De fapt, SRE joacă un rol crucial într-o organizație DevOps, facilitând testarea proactivă, viteza, permițând observabilitatea și îmbunătățirea fiabilității serviciilor. DevOps încurajează fiecare organizație centrată pe DevOps să funcționeze conform principiilor culturale subliniate în modelul său CALMS.
Ce este SRE?
SRE, prescurtare pentru Site Reliability Engineering, este un termen inventat de VP senior Google, Ben Treynor, responsabil cu supravegherea operațiunilor tehnice.
Drew Farnsworth (de la Green Lane Design) explică: „În general îmi place să mă gândesc la SRE ca la un sistem în care dezvoltarea controlează operațiunile. Acesta este un sistem în care mediul este defalcat la cele mai de bază componente ale stivei IT și implementat cu cele mai bune practici incluse în hardware.”
În esență, echipa SRE cu experiență în dezvoltarea de software are responsabilitatea de a rezolva problemele din producția sistemului, menținând în același timp un echilibru între viteza de livrare și fiabilitatea sistemului. În acest mod, abordarea SRE reunește personalul de dezvoltare de software în roluri de operațiuni pentru a aplica practici de inginerie structurată pentru a susține politicile unei organizații.
Ei se asigură că sistemele sunt disponibile și funcționează eficient în orice moment, pentru ca echipele de software să dezvolte servicii tehnice pentru a spori fiabilitatea sistemului. Este responsabilitatea SRE să identifice orice potențială slăbiciune înainte ca aceasta să devină o problemă majoră.
DevOps vs SRE: Principalele diferențe între DevOps și SRE
În practică, DevOps și SRE ar trebui privite ca discipline complementare în care SRE, ca parte a unei structuri centrate pe DevOps, se concentrează pe îmbunătățirea fiabilității serviciilor lor tehnice. Deci, în esență, nu există un DevOps versus SRE.
Prin urmare, ceea ce facem în această secțiune este să evaluăm diferențele fundamentale dintre DevOps și SRE.
Implementarea Schimbarii
Pentru ca actualizările să aibă loc frecvent și utilizatorii să aibă acces la o tehnologie mai nouă și mai relevantă, atât DevOps, cât și SRE intenționează să creeze un pas rapid. Cu toate acestea, DevOps avansează treptat, cu prudență, în timp ce SRE ia în considerare costul eșecului de a se deplasa mai rapid.
Ambele implementează automatizarea și folosesc instrumente pentru a atinge acest scop.
Privind eșecurile ca fiind normale
DevOps este uriaș în acceptarea eșecurilor și în privința lor drept opresiune de învățare. Din acest motiv, încurajează o cultură fără vină, acceptând că eșecurile sunt o parte a procesului și nu se concentrează pe a face sistemele 100% tolerante la erori. Un exemplu în acest sens este Netflix cu armata sa simiană.
SRE, pe de altă parte, sprijină postmortem fără vină. Scopul din spatele acestui lucru este de a identifica cauza eșecului, de a atribui responsabilitatea și de a lucra pentru a evita eșecuri similare în viitor. Câte defecțiuni poate suferi un sistem sunt incluse în bugetul de erori. Valorile SLI, SLO și SLA determină acest lucru pentru a reduce costul de producție. Practic, SRE adoptă practici proactive de monitorizare și alertă pentru a preveni un potențial eșec.
Învață cursuri de dezvoltare software online de la cele mai bune universități din lume. Câștigați programe Executive PG, programe avansate de certificat sau programe de master pentru a vă accelera cariera.
Automatizare vs inovare
DevOps acordă cea mai mare importanță automatizării. Într-un mediu axat pe DevOps, acest lucru se traduce prin automatizarea cât mai mult posibil a sistemelor, ceea ce duce la lansări plictisitoare. După ce un dezvoltator a comis codul, majoritatea activităților următoare, dacă nu toate, trebuie să fie automatizate.
Prin urmare, motivul DevOps pentru a urmări CI/CD este să dezvolte sisteme de înaltă calitate la o viteză mai mare.
Motivele SRE de a urma CI/CD sunt diferite, ele vizează reducerea costului eșecului. Orice sarcini obișnuite, generice sau repetitive în operațiuni precum implementarea și backup-urile sunt considerate ca fiind mai puțin demne de atenție. Prin urmare, SRE-urile alocă o anumită perioadă de timp pentru a evita munca operațională. Acest lucru se face astfel încât aceștia să poată îndeplini sarcini mai atrăgătoare, cum ar fi executarea sau inovarea de noi tehnologii sau activități legate de arhitectură.
Checkout: Proiecte DevOps pentru începători
Defalcarea silozurilor organizaționale
Dezvoltatorii și operatorii intră în conflict când vine vorba de procesul de implementare. În timp ce dezvoltatorii ar beneficia de implementarea funcțiilor de îndată ce sunt codificate, oamenii de operare se concentrează pe punerea la dispoziție a sistemelor care împiedică procesul de implementare.
Atât DevOps, cât și SRE diferă în ceea ce privește modul în care elimină silozurile dintr-o organizație.
DevOps, așa cum este explicat în Manualul DevOps, abordează această problemă incluzând practici precum operarea în loturi mai mici și gestionarea mai bună a configurațiilor.
SRE-urile nu urmăresc doar să optimizeze fluxul dintre echipe, ci și să ajute sistemele în producție. Ei fac acest lucru integrându-se în echipe ca consultanți și sprijinind dezvoltatorii împărțind responsabilitatea rulării sistemelor. Acesta este modul în care SRE-urile defalcă silozurile într-o organizație.
Măsurarea unei implementări de succes
Valorile DevOps sunt toate despre viteza operațiunilor; aceasta include cât de des au loc implementările, timpul necesar pentru a face acest lucru și cât de des se confruntă cu probleme.
Conform raportului din 2017 de la Puppet și DORA, măsurarea unei implementări de succes în DevOps depinde de următoarele:
- frecvența la care au loc implementările
- durata de timp dintre comiterea unui cod și implementarea acestuia
- frecvența la care eșuează implementările
- este nevoie de timp pentru recuperarea dintr-un eșec de implementare
Aceste bucle de feedback sunt puse în aplicare pentru a ajuta DevOps să îmbunătățească calitatea sistemului, facilitând în același timp o schimbare la experimentare.
SRE, pe de altă parte, lucrează la îmbunătățirea sistemelor, ținând cont de fiabilitatea acestora. Acesta ia în considerare următoarele valori cheie pentru a determina o implementare de succes:
- obiectiv la nivel de serviciu (SLO)
- indicator de nivel de serviciu (SLI)
- acord de nivel de serviciu (SLA)
Valorile menționate mai sus sunt indicatori ai fiabilității unui sistem. Aceste valori determină în prealabil dacă o lansare pentru modificare va ajunge sau nu la producție.
În SRE, aceste metrici de viteză și calitate sunt utile atunci când se construiește un buget de eroare și se îmbunătățește fiabilitatea sistemelor, mai degrabă decât se lucrează la noi caracteristici.
Citiți: Salariu inginer DevOps în India
Concluzie
Google a publicat o carte electronică despre modul în care implementează Site Reliability Engineering în sistemele lor de producție, în care Treynor a explicat SRE ca:
„SRE este ceea ce se întâmplă atunci când îi ceri unui inginer software să proiecteze o echipă de operațiuni.”
Când vine vorba de cât de diferite sunt DevOps și SRE, tot ce trebuie să rețineți este că SRE este condus de dezvoltatori, mai degrabă decât de o echipă de operare. Atât întreținerea, cât și monitorizarea sunt în mare parte sub controlul dezvoltatorilor. Acesta este ceea ce deosebește în primul rând cele două discipline.
Dacă sunteți interesat să aflați mai multe despre DevOps mari, dezvoltarea full stack, consultați programul Executive PG în dezvoltare software de la upGrad și IIIT-B - Specializare în dezvoltare Full Stack, care este conceput pentru profesioniști care lucrează și oferă peste 500 de ore de formare riguroasă, Peste 9 proiecte și sarcini, statutul de absolvenți IIIT-B, proiecte practice practice și asistență pentru locuri de muncă cu firme de top.
