Smashing Podcast Episodul 42 cu Jeff Smith: Ce este DevOps?

În acest episod, vorbim despre DevOps. Ce este și este un șir de adăugat la arcul tău de dezvoltare web? Drew McLellan vorbește cu expertul Jeff Smith pentru a afla.

Afișați note

• Jeff pe Twitter
• Cartea lui Jeff Operations Anti-Patterns, DevOps Solutions
• DevOps realizabil

Actualizare săptămânală

• Reducerea decalajului dintre designeri și dezvoltatori scris de Matthew Talebi
• API-uri React utile pentru construirea de componente flexibile cu TypeScript scris de Gaurav Khanna
• Soluții CSS inteligente pentru provocări comune ale UI scrise de Cosima Mielke
• Sfaturi și trucuri pentru evaluarea designerilor UX/UI scrise de Nataliya Sambir
• Rezolvarea problemelor CLS într-un site web de comerț electronic alimentat de Next.js, scris de Arijit Mondal

Transcriere

Drew McLellan: Este un practicant DevOps care se concentrează pe niveluri atinse de implementări DevOps, indiferent de locul în care vă aflați în călătoria dvs. El este director de operațiuni de producție la platforma de publicitate digitală Centro, precum și un vorbitor public, împărtășind cunoștințele sale DevOps cu publicul de pe tot globul. El este autorul cărții, Operations Anti-Patterns, DevOps Solutions for Manning Publishing, care arată cum să implementați tehnici DevOps în mediile imperfecte în care lucrează majoritatea dezvoltatorilor. Deci știm că este un expert în DevOps, dar îl cunoașteți pe George Clooney îl consideră cel mai bun producător de avioane de hârtie al unei generații? Prietenii mei Smashing, vă rog bun venit lui Jeff Smith. Salut Jeff. Ce mai faci?

Jeff Smith: Mă zdrobesc, Drew, ce mai faci?

Drew: Sunt bine. Mulțumesc. Mă bucur să aud asta. Așa că am vrut să vă vorbesc astăzi despre subiectul DevOps, care este una dintre principalele voastre cheie. Mulți dintre ascultătorii noștri vor fi implicați în dezvoltarea web și a aplicațiilor, dar poate au doar o familiaritate slabă cu ceea ce se întâmplă în ceea ce privește operațiunile. Știu că aceia dintre noi care ar putea lucra în companii mai mari vor avea echipe întregi de colegi care fac operațiuni. Suntem recunoscători că orice ar face ei, o fac bine. Dar auzim că DevOps se menționează din ce în ce mai mult și se simte ca unul dintre acele lucruri pe care, în calitate de dezvoltatori, ar trebui să le înțelegem cu adevărat. Deci, Jeff, ce este DevOps?

Jeff: Deci, dacă întrebi 20 de persoane ce este DevOps, s-ar putea să primești 20 de răspunsuri diferite. Așa că vă voi da părerea mea despre asta, în regulă, și să știți că dacă sunteți la o conferință și menționați asta, ați putea intra într-o bătaie de mână cu cineva. Dar pentru mine, DevOps este într-adevăr despre acea relație dintre, și ne concentrăm pe dezvoltare și operațiuni, dar într-adevăr acea relație între echipe și modul în care ne structurăm munca și, mai important, ne structurăm obiectivele și stimulentele pentru a ne asigura că acestea sunt aliniate astfel încât să lucrăm către un obiectiv comun. Și multe dintre ideile și conceptele de bază de la DevOps provin din lumea veche, în care dev-ul și operațiunile erau întotdeauna contradictorii, unde a existat acest conflict constant. Și când te gândești la asta, este din cauza modului în care cele două echipe sunt stimulate. O echipă este motivată să impulsioneze schimbări. O altă echipă este stimulată să păstreze stabilitatea, ceea ce înseamnă mai puține schimbări.

Jeff: Când faci asta, creezi acest conflict inerent și totul se revarsă de acolo. Deci, DevOps este într-adevăr despre alinierea acelor echipe și obiective, astfel încât să lucrăm la o strategie comună, dar apoi să adoptăm practici din ambele părți, astfel încât dev să înțeleagă mai multe despre operațiuni și operațiuni să înțeleagă mai multe despre dev, ca o modalitate de a câștiga și de a împărtăși empatie unul cu celălalt, astfel încât să înțelegem perspectiva de unde vine cealaltă persoană.

Jeff: Dar apoi și pentru a ne îmbunătăți munca. Pentru că, din nou, dacă vă înțeleg perspectiva și țin cont de asta în munca mea, va fi mult mai benefic pentru fiecare dintre noi. Și există multe lucruri pe care operațiunile pot învăța de la dezvoltatori în ceea ce privește automatizarea și modul în care abordăm lucrurile, astfel încât acestea să fie ușor de reprodus. Deci este acest amestec și abilități. Și ceea ce vedeți acum este că acest lucru se aplică diferitelor combinații de grupuri, așa că auziți lucruri precum DevSecOps, DevSecFinOps, DevSecFinHROps. Doar că va continua să crească și să crească și să crească. Deci este într-adevăr o lecție pe care o putem înlătura în întreaga organizație.

Drew: Așadar, este să luăm unele dintre conceptele pe care le înțelegem ca dezvoltatori și să ne răspândim ideile mai departe în organizație și, în același timp, să învățăm ce putem din operațiuni pentru a încerca să-i muți pe toți mai departe.

Jeff: Absolut, da. Și un alt aspect al operațiunilor, și l-ați menționat puțin în introducere, este că credem că este doar pentru aceste organizații mai mari cu echipe operaționale dedicate și lucruri de genul acesta, dar la un lucru la care să vă gândiți este că operațiunile se întâmplă în organizația dvs. indiferent de dimensiune. Este doar o chestiune că tu o faci sau dacă o echipă separată o face, dar cumva implementezi cod. Cumva ai un server care rulează undeva. Deci, operațiunile există undeva în organizația dvs., indiferent de dimensiune. Întrebarea este, cine o face? Și dacă este o singură persoană sau un singur grup, atunci DevOps ar putea fi chiar și mai important pentru dvs., deoarece trebuie să înțelegeți tipurile de lucruri pe care le face ops.

Drew: În calitate de dezvoltatori profesioniști, cât de important credeți că este pentru noi să înțelegem bine ce este DevOps și ce înseamnă să implementăm?

Jeff: Cred că este foarte important, mai ales în această fază a călătoriei DevOps. Și motivul pentru care cred că este important este că unul, cred că suntem mereu mai eficienți, din nou, când înțelegem ce fac omologii noștri. Dar celălalt lucru este să poți ține cont de preocupările operaționale în timpul dezvoltării designului și implementării oricărei tehnologii. Așa că un lucru pe care l-am învățat în cariera mea este că, deși credeam că dezvoltatorii sunt stăpâni ai universului și înțeleg tot ceea ce are legătură cu computerele, se pare că nu este chiar așa. Se pare că există o mulțime de lucruri pe care le externalizează operațiunilor în termeni de înțelegere și, uneori, acestea au ca rezultat alegeri specifice de proiectare sau alegeri de implementare care ar putea să nu fie optime pentru o implementare de producție.

Jeff: S-ar putea să fie bine în dezvoltare și testare și lucruri de genul ăsta, dar odată ce ajungi la producție, este un pic diferit de joc. Deci, ca să nu spun că trebuie să dețină întregul set de expertiză, dar cel puțin trebuie să știe suficient pentru a ști ceea ce nu știu. Deci ei știu când să se angajeze devreme în operațiuni, pentru că acesta este un model comun pe care îl vedem că dezvoltarea face o alegere. Nici nu voi spune să faci o alegere, pentru că ei nici măcar nu sunt conștienți că este o alegere, dar se întâmplă ceva care duce la o decizie suboptimă pentru operațiuni și dezvoltarea a fost complet inconștientă. Așadar, având puțin mai multe cunoștințe despre operațiuni, chiar dacă este suficient să spunem, poate ar trebui să aducem operațiunile în acest sens pentru a obține perspectiva lor înainte de a merge mai departe. Acest lucru ar putea economisi mult timp, energie și stabilitate, evident, deoarece se referă la orice produse pe care le lansați.

Drew: Văd atât de multe paralele cu modul în care vorbești despre relația dintre dev și operațiuni așa cum avem noi între design și dev, unde ai designeri care lucrează la modul în care funcționează și arată o interfață și au o bună înțelegere. despre modul în care va fi de fapt construit în rolul de dezvoltare și aducerea dezvoltatorilor pentru a se consulta poate îmbunătăți într-adevăr soluția generală doar prin acea comunicare clară și o înțelegere a ceea ce fac unii ceilalți. Se pare că este același principiu jucat cu DevOps, ceea ce este foarte, foarte bine de auzit.

Drew: Când mă gândesc la lucrurile pe care le aud despre DevOps, aud termeni precum Kubernetes, Docker, Jenkins, CircleCI. De ani de zile aud despre Kubernetes. Încă nu am idee despre ce este, dar din ceea ce spui, se pare că DevOps nu este doar despre... Nu vorbim doar despre instrumente aici, nu-i așa? Dar mai multe despre procese și modalități de comunicare privind fluxurile de lucru, nu-i așa?

Jeff: Absolut. Deci, mantra mea în ultimii 20 de ani a fost întotdeauna instrumentele de procesare a oamenilor. Îi faci pe oameni să accepte viziunea. De acolo, definiți cum va arăta procesul dumneavoastră pentru a realiza acea viziune. Și apoi aduci instrumente care vor modela oricare ar fi procesul tău. Așa că întotdeauna pun instrumente la capătul conversației DevOps, în principal pentru că dacă nu ai acel buy-in, atunci nu contează. Aș putea veni cu cea mai mare conductă de implementare continuă vreodată, dar dacă oamenii nu sunt convinși de ideea de a trimite fiecare schimbare direct la producție, nu contează, nu? La ce bun instrumentul? Deci, acele instrumente fac cu siguranță parte din conversație, doar pentru că sunt o modalitate standardizată de a îndeplini unele obiective comune pe care le-am definit.

Jeff: Dar trebuie să te asiguri că acele obiective care sunt definite au sens pentru organizația ta. Poate că implementarea continuă nu are sens pentru tine. Poate că nu doriți să expediați fiecare schimbare în momentul în care apare. Și există o mulțime de companii și organizații și motive pentru care nu ai dori să faci asta. Așa că poate ceva de genul o conductă de implementare continuă nu are sens pentru tine. Deci, deși instrumentele sunt importante, este mai important să vă concentrați pe ceea ce va aduce valoare organizației dvs. și apoi să modelați și să implementați instrumentele care sunt necesare pentru a realiza acest lucru.

Jeff: Dar nu intrați online și aflați ce fac toată lumea și fiți așa, oh, ei bine, dacă vom face DevOps, trebuie să trecem la Docker și Kubernetes pentru că acesta este lanțul de instrumente. Nu, asta nu este. S-ar putea să nu ai nevoie de aceste lucruri. Nu toată lumea este Google. Nu toată lumea este Netflix. Nu mai citiți postări de pe Netflix și Google. Vă rugăm să încetați să le citiți. Pentru că îi entuziasmează pe toți și ei spun că asta trebuie să facem. Și e ca și cum, ei bine, ei rezolvă probleme foarte diferite decât problemele pe care le ai tu.

Drew: Deci, dacă spunem că încep un nou proiect, poate că sunt o afacere startup, care creează software ca produs de serviciu. Am trei dezvoltatori, am un depozit Git gol și am vise la IPO. Pentru a fi complet într-o abordare DevOps pentru construirea acestui produs, care sunt numele elementelor de bază pe care ar trebui să le am în ceea ce privește oamenii și procesele și de unde să încep?

Jeff: Deci, în exemplul tău specific, primul loc cu care aș începe este să merg pe cea mai mare parte cât mai mult posibil și să folosesc ceva de genul Heroku sau ceva în acest sens. Pentru că sunteți atât de entuziasmat de toate aceste lucruri AWS, lucruri Docker și, în realitate, este atât de greu să construiți un produs de succes. Ideea că vă concentrați pe partea DevOps a ei este ca, ei bine, aș spune că externalizați cât mai mult posibil din acele lucruri până când devine de fapt un punct de durere. Dar dacă sunteți în acel moment în care spuneți bine, suntem gata să luăm aceste lucruri în casă și suntem gata să le ducem la nivelul următor. Aș spune că primul loc de început este, unde sunt punctele tale de durere? care sunt lucrurile care vă fac probleme?

Jeff: Deci pentru unii oameni este la fel de simplu ca testarea automată. Ideea că, hei, trebuie să rulăm teste de fiecare dată când cineva face un commit, pentru că uneori trimitem lucruri care sunt prinse de testele unitare pe care le-am scris deja. Atunci poate începeți cu integrarea continuă. Poate că implementările dvs. durează ore pentru a se finaliza și sunt foarte manuale, atunci acolo vă concentrați și spuneți cum ar fi, bine, de ce automatizare avem nevoie pentru a putea face asta o afacere cu un singur buton? Dar urăsc să prescriu un general, de aici începi, doar pentru că situația ta particulară și punctele tale de durere vor fi diferite. Și chestia este că, dacă este un punct dureros, ar trebui să țipe la tine. Ar trebui să țipe absolut la tine.

Jeff: Ar trebui să fie unul dintre acele lucruri în care cineva spune, oh, ce e nasol în organizația ta? Și ar trebui să fie ca, oh, știu exact ce este asta. Așa că, atunci când îl abordați din această perspectivă, cred că următorii pași devin destul de evidenti pentru dvs. în ceea ce privește ceea ce trebuie să despachetați și să începeți să lucrați în setul de instrumente DevOps. Și apoi devin aceste schimbări incrementale minime care continuă să apară și observi că, pe măsură ce obții noi capabilități, apetitul tău pentru lucruri substandard devine foarte mic. Deci treci de la, oh, da, implementările durează trei ore și e în regulă. Depuneți ceva efort în asta și următorul lucru pe care îl știți, în trei săptămâni, sunteți ca, omule, nu pot să cred că desfășurarea durează încă 30 de minute. Cum reducem asta de la 30 de minute? Apetitul tău devine nesățios pentru îmbunătățire. Deci lucrurile se revarsă de acolo.

Drew: Am citit cartea ta recentă și asta evidențiază ceea ce numești cei patru piloni ai DevOps. Și niciunul dintre ele nu este instrumente, așa cum am menționat, dar există aceste patru domenii principale de focalizare, dacă doriți, pentru DevOps. Am observat că prima dintre ele este cultura, am fost destul de surprins de asta, în primul rând, pentru că mă așteptam să vorbiți mai mult despre instrumente și acum înțelegem de ce, dar când vine vorba de cultură, mi se pare pur și simplu ciudat. lucru de avut la început. Există o bază pentru o abordare tehnică. Cum afectează cultura cât de reușită poate fi implementarea DevOps în cadrul unei organizații?

Drew: … cât de reușită poate fi implementarea DevOps în cadrul unei organizații.

Jeff: Cultura este cu adevărat piatra de bază a tuturor lucrurilor când te gândești la asta. Și este important pentru că cultura, și intrăm în asta puțin mai adânc în carte, dar cultura într-adevăr pregătește scena pentru norme în cadrul organizației. Dreapta. Probabil că ai fost la o companie în care, dacă ai depus un PR fără testare automată, asta nu este mare lucru. Oamenii o acceptă și merg mai departe.

Jeff: Dar mai sunt și alte organizații în care acesta este un păcat capital. Dreapta. Unde, dacă ai făcut asta, este de genul: „Ui, ești nebun? Ce faci? Nu există cazuri de testare aici.” Dreapta. Asta e cultura insa. Aceasta este cultura care impune acea normă de a spune de genul: „Nu este ceea ce facem.”

Jeff: Oricine poate scrie un document care spune că vom avea cazuri de testare automatizate, dar cultura organizației este cea care impune acest mecanism în rândul oamenilor. Acesta este doar un mic exemplu de ce cultura este atât de importantă. Dacă ai o organizație în care cultura este o cultură a fricii, o cultură a răzbunării. E ca și cum faci o greșeală, corect, asta e un sacrilegiu. Dreapta. Asta echivalează cu trădare. Dreapta.

Jeff: Creați comportamente în acea organizație care sunt negative pentru orice ar putea fi riscant sau potențial eșuează. Și asta ajunge să lase multe oportunități pe masă. În timp ce, dacă creezi o cultură care îmbrățișează învățarea din eșec, îmbrățișează această idee de siguranță psihologică, în care oamenii pot experimenta. Și dacă greșesc, își pot da seama cum să eșueze în siguranță și să încerce din nou. Obțineți o cultură a experimentării. Obțineți o organizație în care oamenii sunt deschiși la idei noi.

Jeff: Cred că am fost cu toții la acele companii în care se spune: „Ei bine, așa se face. Și nimeni nu schimbă asta.” Dreapta. Nu vrei asta pentru că lumea este în continuă schimbare. De aceea punem cultura în prim plan, pentru că multe dintre comportamentele din cadrul unei organizații există datorită culturii care există.

Jeff: Și chestia este că actorii culturali pot fi bine sau rău. Dreapta. Ceea ce este ironic, și despre asta vorbim și în carte, este că nu este nevoie de atât de mulți oameni pe cât crezi pentru a schimba cultura organizațională. Dreapta. Pentru că majoritatea oamenilor, sunt detractori, apoi sunt susținători și apoi sunt gardieni când vine vorba de orice fel de schimbare. Și cei mai mulți oameni sunt gardieni. Dreapta. Este nevoie doar de o mână de suporteri pentru a înclina cu adevărat balanța. Dar, în același sens, este nevoie de o mână de detractori pentru a înclina balanța.

Jeff: E ca și cum, nu este nevoie de mult pentru a schimba cultura în bine. Și dacă pui acea energie în asta, chiar și fără a fi un lider senior, poți influența cu adevărat cultura echipei tale, care apoi ajunge să influențeze cultura departamentului tău, care ajunge apoi să influențeze cultura organizației.

Jeff: Puteți face aceste schimbări culturale în calitate de contributor individual, doar adoptând aceste idei și aceste comportamente cu voce tare și spunând: „Aceste sunt beneficiile pe care le obținem din asta.” De aceea cred că cultura trebuie să fie în prim plan pentru că trebuie să-i convingi pe toată lumea în această idee și trebuie să înțeleagă că, ca organizație, va merita și să o susțină.

Drew: Da. Trebuie să fie un mod de viață, cred.

Jeff: Exact.

Drew: Da. Sunt foarte interesat de domeniul automatizării, deoarece de-a lungul carierei mele, nu am văzut niciodată vreo automatizare care a fost pusă în aplicare care să nu fi fost de folos. Dreapta. Adică, în afară de lucrul ciudat, poate unde ceva este automatizat și merge prost. În general, atunci când vă faceți timp să vă așezați și să automatizați ceva ce ați făcut manual, vă economisește întotdeauna timp și vă economisește spațiu în cap și este doar o greutate de pe umeri.

Drew: Având o abordare DevOps, ce fel de lucruri ați căuta să automatizați în fluxurile dvs. de lucru? Și ce câștiguri te-ai aștepta să vezi din asta față de completarea manuală a lucrurilor?

Jeff: Când vine vorba de automatizare, în opinia dvs., foarte rar există un moment în care automatizarea nu a făcut viața mai bună. Dreapta. Problema pe care o întâlnesc oamenii este să găsească timp pentru a construi acea automatizare. Dreapta. Și de obicei, la locul meu de muncă actual, pentru noi este de fapt scopul solicitării. Dreapta. Pentru că la un moment dat trebuie să spui: „Voi înceta să mai fac asta manual și o voi automatiza”.

Jeff: Și poate să fie momentul în care primiți o solicitare în care spuneți: „Știi ce? Acest lucru va dura două săptămâni. Știu că în mod normal o întoarcem în câteva ore, dar va dura două săptămâni, deoarece aceasta este cererea care devine automatizată.” În ceea ce privește identificarea a ceea ce automatizați. La Central, folosesc procesul prin care, practic, aș eșantiona toate tipurile diferite de solicitări care au venit într-o perioadă de patru săptămâni, să spunem. Și le-aș clasifica ca muncă planificată, muncă neplanificată, muncă cu valoare adăugată, muncă trudă. Munca fiind o muncă care nu este cu adevărat utilă, dar din anumite motive, organizația mea trebuie să o facă.

Jeff: Și apoi identificând acele lucruri care sunt de genul „Bine, care este fructul care agăța jos de care putem scăpa dacă ar fi să automatizăm asta? Ce putem face pentru a simplifica acest lucru?” Iar unele dintre criterii a fost riscul procesului. Dreapta. Eșuarea automată a bazei de date este puțin înfricoșătoare, deoarece nu le faceți atât de des. Și se schimbă infrastructura. Dreapta. Noi spunem: „Cât de des facem acest lucru?” Dacă o facem o dată pe an, s-ar putea să nu merite automatizarea, deoarece are foarte puțină valoare. Dar dacă este unul dintre acele lucruri pe care le primim de două, trei ori pe lună, bine, să aruncăm o privire la asta. In regula.

Jeff: Acum, care sunt lucrurile pe care le putem face pentru a accelera acest lucru? Și lucrul este că, când vorbim despre automatizare, am sărit instantaneu la „Voi face clic pe un buton și chestia asta se va face ca magic.” Dreapta. Dar există atât de mulți pași diferiți pe care îi puteți face în automatizare dacă vă simțiți stânjeniți. Dreapta. De exemplu, să presupunem că aveți 10 pași cu 10 comenzi CLI diferite pe care le-ați rula în mod normal. Primul pas de automatizare ar putea fi la fel de simplu ca să rulați acea comandă sau cel puțin să afișați acea comandă. Dreapta. Spune: „Hei, asta am de gând să execut. Crezi că e în regulă?” "Da." "Bine. Acesta este rezultatul pe care l-am primit. Este în regulă să continui?” "Da." "Bine. Acesta este rezultatul pe care l-am obținut.” Dreapta.

Jeff: Așa ai încă un pic de control. Te simți confortabil. Și apoi, după 20 de execuții, îți dai seama că doar lovești, da, da, da, da, da, da. Tu spui: „Bine. Să legăm toate aceste lucruri împreună și să le facem pe toate una.” Nu este ca și cum trebuie să sari în capătul adânc al, să dai clic pe el și să-l uiți imediat de la rupere. Puteți păși în asta până când vă simțiți confortabil.

Jeff: Acestea sunt tipurile de lucruri pe care le-am făcut ca parte a efortului nostru de automatizare a fost pur și simplu, cum grăbim timpul de rezolvare a acestui lucru și cum reducem nivelul de efort din partea noastră? Poate că nu este 100% prima zi, dar scopul este întotdeauna să ajungem la 100%. Vom începe cu bucăți mici pe care le vom automatiza părți cu care ne simțim confortabil. Da. Suntem foarte încrezători că acest lucru va funcționa. Pe această parte suntem puțin îndoielnici, așa că poate vom obține o verificare umană înainte de a continua.

Jeff: Celălalt lucru pe care l-am analizat în ceea ce privește vorbim despre automatizare, dar este ce valoare adăugăm unui anumit proces? Și acest lucru este deosebit de important pentru operațiuni. Pentru că de multe ori operațiunile servesc drept intermediar pentru un proces. Atunci implicarea lor nu este altceva decât ceva de acces. Dreapta. E ca și cum, ei bine, ops trebuie să o facă pentru că ops este singura persoană care are acces.

Jeff: Ei bine, este ca, ei bine, cum externalizăm acel acces, astfel încât oamenii să poată face acest lucru? Pentru că realitatea este că nu ne facem griji că dezvoltatorii au acces la producție. Dreapta. Ne facem griji că dezvoltatorii au acces neîngrădit la producție. Și asta este într-adevăr o chestie de siguranță. Dreapta. Este ca și cum dacă cutia mea de instrumente are doar cuțite ascuțite, voi fi foarte atentă cui îi dau. Dar dacă pot amesteca cutia de instrumente cu o lingură și un ciocan, astfel încât oamenii să poată alege unealta potrivită pentru muncă, atunci este mult mai ușor să o împrumut.

Jeff: De exemplu, am avut un proces în care oamenii trebuiau să ruleze scripturi Ruby ad-hoc în producție, indiferent de motiv. Dreapta. Trebuie să curățați datele, trebuie să corectați o înregistrare proastă, indiferent. Și asta venea întotdeauna prin echipa mea. Și e ca și cum, ei bine, nu adăugăm nicio valoare la asta pentru că nu pot aproba acest bilet. Dreapta. Nu am nici o idee. Ai scris software-ul, așa că la ce mă folosește să stau peste umărul tău și să spun: „Ei bine, cred că e în siguranță”? Dreapta. Nu am adăugat nicio valoare la introducerea lui pentru că scriu doar exact ceea ce mi-ai spus să scriu. Dreapta.

Jeff: Și în cel mai rău caz, și la sfârșit, sunt într-adevăr doar un obstacol pentru tine, pentru că trimiți un bilet, apoi aștepți să mă întorc de la prânz. M-am întors de la prânz, dar mai am aceste alte lucruri de lucrat. Am spus: „Cum automatizăm acest lucru, astfel încât să putem pune acest lucru în mâinile dezvoltatorilor și, în același timp, abordăm oricare dintre aceste preocupări de audit pe care le-am putea avea?”

Jeff: Am introdus-o într-un flux de lucru JIRA, unde am avut un bot care ar automatiza executarea comenzilor care au fost specificate în biletul JIRA. Și apoi am putea specifica în biletul JIRA că necesita aprobarea unuia dintre câțiva ingineri seniori. Dreapta.

Jeff: Este mai logic ca un inginer să aprobe munca altui inginer pentru că are contextul. Dreapta. Nu trebuie să stea în preajmă așteptând operațiunile. Se răspunde la piesa de audit deoarece avem un flux de lucru clar care a fost definit în JIRA și care este documentat pe măsură ce cineva aprobă, așa cum a solicitat cineva. Și avem automatizare care trage acea comandă și execută acea comandă literal în terminal. Dreapta.

Jeff: Nu trebuie să-ți faci griji că am scris greșit. Nu trebuie să-ți faci griji că am luat biletul greșit. Asta a mărit timpul de livrare pentru acele bilete, cam de zece ori. Dreapta. Dezvoltatorii sunt deblocați. Echipa mea nu este legată să facă asta. Și tot ce a fost nevoie de o săptămână sau două săptămâni de investiție pentru a dezvolta automat automatizarea și permisiunea necesară pentru a le avea acces pentru aceasta.

Jeff: Acum suntem complet îndepărtați de asta. Și dezvoltarea este de fapt capabilă să externalizeze o parte din această funcționalitate către părți inferioare ale organizației. L-au împins în asistența clienților. Este ca acum, când serviciul pentru clienți știe că această înregistrare trebuie actualizată pentru orice, nu au nevoie de dezvoltare. Ei își pot trimite scriptul standard pe care l-am aprobat pentru această funcționalitate. Și îl pot rula prin același flux de lucru pe care îl face dezvoltarea. Este într-adevăr o binefacere peste tot.

Jeff: Și apoi ne permite să împingem munca din ce în ce mai jos în întreaga organizație. Pentru că, pe măsură ce facem asta, munca devine din ce în ce mai ieftină, deoarece aș putea avea un dezvoltator scump și scump care rulează asta. Dreapta. Sau pot avea o persoană de asistență pentru clienți care lucrează direct cu clientul, să o execute ea însăși în timp ce sunt la telefon cu un client care corectează o problemă.

Jeff: Cred că automatizarea este cheia oricărei organizații. Și ultimul punct pe care îl voi spune este că vă permite și să exportați expertiză. Dreapta. Acum, s-ar putea să fiu singura persoană care știe cum să facă asta dacă am nevoie să fac o grămadă de comenzi pe linia de comandă. Dar dacă pun asta în automatizare, pot da asta oricui. Și oamenii știu care este rezultatul final, dar nu trebuie să cunoască toți pașii intermediari. Mi-am mărit valoarea de zece ori prin transmiterea acesteia către organizație și luându-mi expertiza și codificând-o în ceva care poate fi exportat.

Drew: Ați vorbit despre automatizarea sarcinilor care apar frecvent. Există vreun argument pentru automatizarea sarcinilor care se întâmplă atât de rar, încât unui dezvoltator îi ia destul de mult timp pentru a reveni la curent cu cum ar trebui să funcționeze? Pentru că toată lumea este uitată. A trecut atât de mult. A trecut un an, poate nimeni nu a mai făcut-o. Există vreun argument pentru automatizarea unor astfel de lucruri?

Jeff: Acesta este un act de echilibru greu. Dreapta. Și întotdeauna spun să o luăm de la caz la caz. Și motivul pentru care spun asta este că una dintre mantrele din DevOps este dacă ceva dureros, fă-o mai des. Dreapta. Pentru că cu cât o faci mai des, cu atât devine mai multă memorie musculară și ajungi să te antrenezi și să rezolvi acele îndoieli.

Jeff: Problema pe care o vedem cu automatizarea sarcinilor foarte rare este că peisajul mediului tinde să se schimbe între execuțiile acelei automatizări. Dreapta. Ceea ce ajunge să se întâmple este că codul tău face anumite ipoteze despre mediu, iar acele ipoteze nu mai sunt valabile. Deci automatizarea ajunge să se rupă oricum.

Drew: Și atunci ai două probleme.

Jeff: Corect. Dreapta. Exact. Exact. Și tu spui: „Am scris greșit? Sau asta e? Nu, chestia asta este de fapt stricata.” Asa de-

Jeff: Tastați greșit sau nu, acest lucru este de fapt stricat. Deci, când vine vorba de automatizarea sarcinilor rare, o luăm de la caz la caz pentru a înțelege, ei bine, care este riscul dacă acest lucru nu funcționează, corect. Dacă înțelegem greșit, suntem într-o stare proastă sau doar că nu am terminat această sarcină? Deci, dacă vă puteți asigura că acest lucru va eșua cu grație și nu va avea un impact negativ, atunci merită să încercați automatizarea acestuia. Pentru că cel puțin, atunci aveți un cadru de înțelegere a ceea ce ar trebui să se întâmple, pentru că cel puțin, cineva va putea citi codul și va înțelege, bine, asta este ceea ce făceam. Și nu înțeleg de ce acest lucru nu mai funcționează, dar am o înțelegere clară a ceea ce trebuia să se întâmple cel puțin pe baza timpului de proiectare, când a fost scris acest lucru.

Jeff: Dar dacă vă aflați vreodată într-o situație în care eșecul ar putea duce la modificări de date sau ceva de genul acesta, de obicei greșesc din partea precauției și o păstrez manual doar pentru că, dacă am un script de automatizare, dacă găsesc un document de confluență asta are trei ani care spune rulați acest script, tind să am încredere sută la sută în acel script și îl execut. Dreapta. În timp ce, dacă este vorba despre o serie de pași manuali care au fost documentați în urmă cu patru ani, o să spun că trebuie să fac niște verificări aici. Dreapta? Lasă-mă să trec puțin peste asta și să vorbesc cu câțiva oameni. Și uneori, când proiectăm procese, merită să forțăm acel proces de gândire, nu? Și trebuie să te gândești la componenta umană și la modul în care se vor comporta. Și uneori merită să facem procesul puțin mai greoi pentru a forța oamenii să se gândească că ar trebui să fac asta acum?

Drew: Există alte modalități de a identifica ceea ce ar trebui automatizat prin monitorizarea sistemelor și măsurarea lucrurilor? Adică, mă gândesc la DevOps și mă gândesc la tablouri de bord ca unul dintre lucruri, grafice frumoase. Și sunt sigur că aceste tablouri de bord au mult mai mult decât să arate frumos, dar este întotdeauna plăcut să ai tablouri de bord drăguțe. Există modalități de a măsura ce face un sistem, pentru a vă ajuta să luați astfel de decizii?

Jeff: Absolut. Și acest tip de trecere în porțiunea de metrică a camerelor, nu, care sunt lucrurile pe care le urmărim în sistemele noastre pentru a ști că funcționează eficient? Și unul dintre capcanele comune ale valorilor este că căutăm erori în loc să verificăm succesul. Și acestea sunt două practici foarte diferite, nu? Deci ceva ar putea curge prin sistem și nu neapărat să iasă din eroare, dar nu neapărat să treacă prin întregul proces așa cum ar trebui. Deci, dacă aruncăm un mesaj într-o coadă de mesaje, ar trebui să existe o valoare corespunzătoare care să spună „Și acest mesaj a fost preluat și procesat”, nu? Dacă nu, corect, vei avea rapid un dezechilibru și sistemul nu funcționează așa cum ar trebui. Cred că putem folosi valorile ca o modalitate de a înțelege și diferite lucruri care ar trebui automatizate pe măsură ce ajungem în acele stări proaste.

Jeff: Nu? Pentru că de multe ori este un pas foarte simplu care trebuie făcut pentru a curăța lucrurile, nu? Pentru oamenii care au fost operațiuni de ceva timp, corect, alerta de spațiu pe disc, toată lumea știe despre asta. Oh, suntem plini de disc. Oh, am uitat că este sfârșitul lunii și facturarea a rulat și facturarea umple întotdeauna jurnalele. Și apoi jurnalul VAR consumă tot spațiul pe disc, așa că trebuie să rulăm o rotire a jurnalului. Dreapta? Ai putea să te trezești la trei dimineața pentru asta, dacă asta este un fel de preferință. Dar dacă știm cumva că acesta este comportamentul, valorile noastre ar trebui să ne poată da un indiciu în acest sens. Și putem automatiza pur și simplu comanda de rotire a jurnalului, nu? Oh, am atins acest prag, executați comanda de rotire a jurnalului. Să vedem dacă alerta se șterge. Dacă se întâmplă, continuă cu viața. Dacă nu, atunci poate trezim pe cineva, corect.

Jeff: Vedeți acest lucru mult mai mult și cu automatizarea infrastructurii, corect, unde este ca, „Hei, cererile noastre pe secundă ating maximul nostru teoretic? Poate că trebuie să mărim clusterul. Poate că trebuie să adăugăm trei sau patru noduri la pool-ul de echilibrare a încărcăturii.” Și putem face asta fără a necesita neapărat să intervină cineva. Putem doar să ne uităm la acele valori și să luăm acțiunea și apoi să contractăm acea infrastructură odată ce scade sub un anumit prag, dar trebuie să aveți acele valori și trebuie să aveți acele cârlige în mediul dvs. de monitorizare pentru a putea face asta. Și aici intervine întreaga porțiune de valori a conversației.

Jeff: În plus, este și bine să poți partaja acele informații cu alte persoane, deoarece odată ce ai date, poți începe să vorbești despre lucruri într-o realitate comună, nu, pentru că ocupat este un termen generic, dar 5.200 de solicitări pe secundă este ceva mult mai concret despre care ne putem gândi cu toții. Și cred că atât de des atunci când avem conversații despre capacitate sau orice altceva, folosim acești termeni ondulați, când în schimb am putea să ne uităm la un tablou de bord și să dăm valori foarte specifice și să ne asigurăm că toată lumea are acces la acele tablouri de bord, că they're not hidden behind some ops wall that only we have access to for some unknown reason.

Drew: So while sort of monitoring and using metrics as a decision-making tool for the businesses is one aspect of it, it sounds like the primary aspect is having the system monitor itself, perhaps, and to respond maybe with some of these automations as the system as a whole gives itself feedback on onto what's happening.

Jeff: Absolutely. Feedback loops are a key part of any real system design, right, and understanding the state of the system at any one time. So while it's easy in the world where everything is working fine, the minute something goes bad, those sorts of dashboards and metrics are invaluable to have, and you'll quickly be able to identify things that you have not instrumented appropriately. Dreapta. So one of the things that we always talk about in incident management is what questions did you have for the system that couldn't be answered, right. So what is it, or you're like, “Oh man, if we only knew how many queries per second were going on right now.” Dreapta.

Jeff: Well, okay. How do we get that for next time? How do we make sure that that's radiated somewhere? And a lot of times it's hard when you're thinking green field to sit down and think of all the data that you might want at any one time. But when you have an incident, it becomes readily apparent what data you wish you had. So it's important to sort of leverage those incidents and failures and get a better understanding of information that's missing so that you can improve your incident management process and your metrics and dashboarding.

Drew: One of the problems we sometimes face in development is that teammate members, individual team members hold a lot of knowledge about how a system works and if they leave the company or if they're out sick or on vacation, that knowledge isn't accessible to the rest of the team. It seems like the sort of DevOps approach to things is good at capturing a lot of that operational knowledge and building it into systems. So that sort of scenario where an individual has got all the information in their head that doesn't happen so much. Este o evaluare corectă?

Jeff: It is. I think we've probably, I think as an industry we might have overstated its efficacy. And the only reason I say that is when our systems are getting so complicated, right? Gone are the days where someone has the entire system in their head and can understand it from beginning to end. Typically, there's two insidious parts of it. One, people typically focus on one specific area and someone doesn't have the whole picture, but what's even more insidious is that we think we understand how the system works. Dreapta. And it's not until an incident happens that the mental model that we have of the system and the reality of the system come into conflict. And we realize that there's a divergence, right? So I think it's important that we continuously share knowledge in whatever form is efficient for folks, whether it be lunch and learns, documentation, I don't know, presentations, anything like that to sort of share and radiate that knowledge.

Jeff: But we also have to prepare and we have to prepare and define a reality where people may not completely understand how the system works. Dreapta. And the reason I think it's important that we acknowledge that is because you can make a lot of bad decisions thinking you know how the system behaves and being 100% wrong. Dreapta. So having the wherewithal to understand, okay, we think this is how the system works. We should take an extra second to verify that somehow. Dreapta. I think that's super important in these complicated environments in these sprawling complex microservice environments. Whereas it can be very, it's easy to be cavalier if you think, oh yeah, this is definitely how it works. And I'm going to go ahead and shut the service down because everything's going to be fine. And then everything topples over. So just even being aware of the idea that, you know what, we may not know a hundred percent how this thing works.

Jeff: So let's take that into account with every decision that we make. I think that's key. And I think it's important for management to understand the reality of that as well because for management, it's easy for us to sit down and say, “Why didn't we know exactly how this thing was going to fail?” And it's like, because it's complicated, right, because there's 500 touch points, right, where these things are interacting. And if you change one of them, it changes the entire communication pattern. So it's hard and it's not getting any easier because we're getting excited about things like microservices. We're getting excited about things like Kubernetes. We're giving people more autonomy and these are just creating more and more complicated interfaces into these systems that we're managing. And it's becoming harder and harder for anyone to truly understand them in their entirety.

Drew: We've talked a lot about a professional context, big organizations and small organizations too. But I know many of us work on smaller side projects or maybe we volunteer on projects and maybe you're helping out someone in the community or a church or those sorts of things. Can a DevOps approach benefit those smaller projects or is it just really best left to big organizations to implement?

Jeff: I think DevOps can absolutely benefit those smaller projects. And specifically, because I think sort of some of the benefits that we've talked about get amplified in those smaller projects. Dreapta? So exporting of expertise with automation is a big one, right? If I am… Take your church example, I think is a great one, right? If I can build a bunch of automated tests suites to verify that a change to some HTML doesn't break the entire website, right, I can export that expertise so that I can give it to a content creator who has no technical knowledge whatsoever. Dreapta. They're a theologian or whatever, and they just want to update a new Bible verse or something, right. But I can export that expertise so that they know that I know when I make this content change, I'm supposed to run this build button.

Jeff: And if it's green, then I'm okay. And if it's red, then I know I screwed something up. Dreapta. So you could be doing any manner of testing in there that is extremely complicated. Dreapta. It might even be something as simple as like, hey, there's a new version of this plugin. And when you deploy, it's going to break this thing. Dreapta. So it has nothing to do with the content, but it's at least a red mark for this content creator to say “Oh, something bad happened. I shouldn't continue. Dreapta. Let me get Drew on the phone and see what's going on.” Dreapta. And Drew can say, “Oh right. This plugin is upgraded, but it's not compatible with our current version of WordPress or whatever.” Dreapta. So that's the sort of value that we can add with some of these DevOps practices, even in a small context, I would say specifically around automation and specifically around some of the cultural aspects too.

Jeff: Right? So I've been impressed with the number of organizations that are not technical that are using get to make changes to everything. Dreapta. And they don't really know what they're doing. They just know, well, this is what we do. This is the culture. And I add this really detailed commit message here. And then I push it. They are no better than us developers. They know three get commands, but it's the ones they use over and over and over again. But it's been embedded culturally and that's how things are done. So everyone sort of rallies around that and the people that are technical can take that pattern.

Jeff: … around that and the people that are technical can take that pattern and leverage it into more beneficial things that might even be behind the scenes that they don't necessarily see. So I think there's some value, definitely. It's a matter of how deep you want to go, even with the operations piece, right? Like being able to recreate a WordPress environment locally very easily, with something like Docker. They may not understand the technology or anything, but if they run Docker Compose Up or whatever, and suddenly they're working on their local environment, that's hugely beneficial for them and they don't really need to understand all the stuff behind it. In that case, it's worthwhile, because again, you're exporting that expertise.

Drew: We mentioned right at the beginning, sort of putting off as much sort of DevOps as possible. You mentioned using tools like Heroku. And I guess that sort of approach would really apply here on getting started with, with a small project. What sort things can platforms like Heroku offer? I mean, obviously, I know you're not a Heroku expert or representative or anything, but those sorts of platforms, what sort of tools are they offering that would help in this context?

Jeff: So for one, they're basically taking that operational context for you and they're really boiling it down into a handful of knobs and levers, right? So I think what it offers is one, it offers a very clear set of what we call the yellow brick road path, where it's like, “If you go this route, all of this stuff is going to be handled for you and it's going to make your life easier. If you want to go another route, you can, but then you got to solve for all this stuff yourself.” So following the yellow brick road route helps because one, they're probably identifying a bunch of things that you hadn't even thought of. So if you're using their database container or technology, guess what? You're going to get a bunch of their metrics for free. You're going to get a lot of their alerting for free. You didn't do anything. You didn't think anything. It's just when you need it, it's there. And it's like, “Oh wow, that's super are helpful.”

Jeff: Two, when it comes to performance sizing and flexibility, this becomes very easy to sort of manage because the goal is, you're a startup that's going to become wildly successful. You're going to have hockey stick growth. And the last thing you necessarily really want to be doing is figuring out how to optimize your code for performance, while at the same time delivering new features. So maybe you spend your way out of it. You say, “Well, we're going to go up to the next tier. I could optimize my query code, but it's much more efficient for me to be spending time building this next feature that's going to bring in this new batch of users, so let's just go up to the next tier,” and you click button and you move on.

Jeff: So being able to sort of spend your way out of certain problems, I think it's hugely beneficial because tech debt gets a bad rap, but tech debt is no different than any debt. It's the trade off of acquiring something now and dealing with the pain later. And that's a strategic decision that you have to make in every organization. So unchecked tech debt is bad, right? But tech debt generally, I think, is a business choice and Heroku and platforms like that enable you to make that choice when it comes to infrastructure and performance.

Drew: You've written a book, Operations, Anti-Patterns, DevOps Solutions, for Manning. I can tell it's packed with years of hard-earned experience. The knowledge sort of just leaps out from the page. And I can tell it's been a real labor of love. It's packed full of information. Who's your sort of intended audience for that book? Is it mostly those who are already working in DevOps, or is it got a broader-

Jeff: It's got a broader… So one of the motivations for the book was that there were plenty of books for people that we're already doing DevOps. You know what I mean? So we were kind of talking to ourselves and high-fiving each other, like, “Yeah, we're so advanced. Awesome.” But what I really wanted to write the book for were people that were sort of stuck in these organizations. I don't want to use the term stuck. That's unfair, but are in these organizations that maybe aren't adopting DevOps practices or aren't at the forefront of technology, or aren't necessarily cavalier about blowing up the way they do work today, and changing things.

Jeff: Am vrut să le scriu lor, în principal colaboratorilor individuali și managerilor de mijloc, pentru a spune: „Nu trebuie să fii CTO pentru a putea face astfel de schimbări incrementale și nu trebuie să ai asta. întreaga revoluție a vânzărilor pentru a putea obține unele dintre beneficiile DevOps.” Așa că a fost într-adevăr un fel de scrisoare de dragoste pentru ei să le spună: „Hei, poți face asta în bucăți. Puteți face acest lucru singur. Și există toate aceste lucruri despre care s-ar putea să nu credeți că sunt legate de DevOps, deoarece vă gândiți la ele ca instrumente și Kubernetes.” Nu orice organizație... Dacă ați fi pentru acest stat New York, precum guvernul de stat, nu veți intra și implementați Kubernetes peste noapte. Dreapta? Dar puteți implementa modul în care echipele vorbesc între ele, cum lucrează împreună, cum ne înțelegem problemele reciproce și cum putem aborda aceste probleme prin automatizare. Acestea sunt lucruri care se află în sfera ta de influență și care îți pot îmbunătăți viața de zi cu zi.

Jeff: Așadar, a fost într-adevăr o scrisoare către acești oameni, dar cred că există suficiente date acolo și suficiente informații pentru ca oamenii care fac parte dintr-o organizație DevOps să poată să culeagă și să spună de genul „Hei, asta este încă util pentru noi. ” Și o mulțime de oameni cred că identifică rapid citind cartea că nu fac parte dintr-o organizație DevOps, ci doar o schimbare a titlului postului. Și asta se întâmplă destul de puțin. Așa că ei spun: „Hei, acum suntem ingineri DevOps, dar nu facem astfel de practici despre care se vorbește în această carte și cum ajungem acolo?”

Drew: Deci se pare că cartea ta este una dintre ele, dar există alte resurse la care ar putea apela oamenii care doresc să înceapă cu DevOps? Există locuri bune pentru a învăța aceste lucruri?

Jeff: Da. Cred că DevOps For Dummies de Emily Freeman este un loc grozav de început. Într-adevăr, face o treabă grozavă de sortare a expunerii unor concepte și idei de bază și pentru ce ne străduim. Așa că ar fi un loc bun pentru a începe, doar pentru a obține un fel de întindere a terenului. Cred că Proiectul Phoenix este, evident, o altă sursă grozavă a lui Gene Kim. Și asta este grozav, așa ceva creează terenul pentru tipurile de probleme pe care nu le poate crea fără a fi într-un mediu DevOps. Și face o treabă grozavă de a evidenția aceste tipare și personalități care apar și pe care le vedem în toate tipurile de organizații din nou și din nou. Cred că face o treabă grozavă de a le sublinia. Și dacă citești acea carte, cred că vei ajunge să țipi la pagini spunând: „Da, da. Acest. Acest." Deci, acesta este un alt loc grozav.

Jeff: Și apoi, de acolo, mergând în oricare din manualul DevOps. O să mă bat pentru că spun asta, dar Google SRE Handbook a fost un alt loc grozav în care să caut. Înțelegeți că nu sunteți Google, așa că nu credeți că trebuie să implementați totul, dar cred că multe dintre ideile și strategiile lor sunt bune pentru orice organizație și sunt locuri grozave în care puteți să luați lucruri și spuneți de genul „Bine, vom face mediul nostru de operațiuni puțin mai eficient.” Și asta, cred că va fi deosebit de important pentru dezvoltatorii care joacă un rol operațional, deoarece se concentrează pe o mulțime de tip de abordare programatică pentru rezolvarea unora dintre aceste probleme.

Drew: Deci, am învățat totul despre DevOps. Despre ce ai învățat în ultima vreme, Jeff?

Jeff: Kubernetes, omule. Da. Kubernetes a fost un adevărat fel de sursă de lectură și cunoaștere pentru noi. Așa că încercăm să implementăm asta la Centro în prezent, ca un mijloc de a împuternici dezvoltatorii. Vrem să ducem lucrurile cu un pas mai departe de locul în care ne aflăm. Avem o mulțime de automatizări, dar chiar acum, când vine vorba de integrarea unui nou serviciu, echipa mea este încă destul de puternic implicată în asta, în funcție de natura serviciului. Și nu vrem să fim în acea linie de muncă. Dorim ca dezvoltatorii să poată prelua o idee de la concept la cod până la implementare și să facă asta acolo unde expertiza operațională este codificată în sistem. Deci, pe măsură ce vă deplasați prin sistem, sistemul vă ghidează. Așa că credem că Kubernetes este un instrument care ne va ajuta să facem asta.

Jeff: Este doar incredibil de complicat. Și este o bucată mare de care să mușcăm. Deci, să vă dați seama cum arată implementările? Cum folosim acești operatori în Kubernetes? Cum arată CICD în această lume nouă? Deci s-a citit mult, dar în acest domeniu, înveți constant, nu? Nu contează de cât timp ai fost în el, de cât timp ai făcut-o, ești un idiot într-un anumit aspect al acestui domeniu undeva. Deci, este doar ceva la care te cam adaptezi

Drew: Ei bine, jos pălăria, așa cum spun, chiar și după toți acești ani, deși am înțeles unde se află în stivă, încă nu am nicio idee ce face Kubernetes.

Jeff: Mă simt similar uneori. Pare că face puțin din toate, nu? Este DNS-ul secolului 21.

Drew: Dacă tu, cel care ascultă, ai dori să afli mai multe de la Jeff, îl poți găsi pe Twitter, unde se află la dark and nerdy, și poți găsi cartea lui și link-uri către prezentări și postări anterioare pe blog pe site-ul său, attainabledevops.com. Îți mulțumim că ești alături de noi astăzi, Jeff. Ai avut cuvinte de despărțire?

Jeff: Continuă să înveți, ieși, continuă să înveți și vorbește cu colegii tăi. Vorbește, vorbește, vorbește. Cu cât poți vorbi mai mult cu oamenii cu care lucrezi, cu atât mai bună înțelegere, cu atât mai bună empatie vei genera pentru ei și, dacă există cineva în special în organizația pe care o urăști, asigură-te că vorbești mai întâi cu ei.