Construirea unui sistem rezistent: călătoria noastră către observabilitate la Intercom

La Intercom ne concentrăm mai presus de toate pe experiența clienților – disponibilitatea și performanța serviciilor noastre sunt prioritatea noastră principală. Acest lucru necesită o cultură puternică a observabilității în echipele și sistemele noastre.

Drept urmare, investim mult în fiabilitatea aplicației noastre. Dar eșecurile imprevizibile sunt inevitabile, iar atunci când se întâmplă, oamenii sunt cei care le remediază.

Operăm un sistem socio-tehnic, iar capacitatea lui de a se recupera atunci când se confruntă cu adversitate se numește reziliență. Una dintre componentele cruciale ale rezilienței este observabilitatea, pașii pe care îi luăm pentru a le permite oamenilor să „privadă” în interiorul sistemelor pe care le rulează.

Această postare va explora drumul către construirea unei culturi mai puternice a observabilității și lecțiile pe care le-am învățat pe parcurs.

Ce înțelegem prin observabilitate la Intercom?

La Intercom, livrăm pentru a învăța. Mediul nostru de producție este locul în care codul nostru, infrastructura, dependențele de la terți și clienții noștri se reunesc pentru a crea o realitate obiectivă – este singurul loc pentru a învăța și a valida impactul muncii noastre. Definim observabilitatea ca un proces continuu prin care oamenii pun întrebări despre producție și obțin răspunsuri*.

Haideți să dezvăluim asta puțin mai mult:

• Proces continuu: observabilitatea cu succes înseamnă că oamenii observă cât mai des posibil.
• Întrebări despre producție: ne-am dorit ca definiția noastră să fie largă, generică și reprezentativă pentru gama largă de fluxuri de lucru pentru care ne ocupăm.
• Răspunsuri*: Observați asteriscul. Niciun instrument nu vă va oferi răspunsuri, oferă doar piste pe care le puteți urmări pentru a găsi răspunsurile reale. Trebuie să vă folosiți propriile modele mentale și să înțelegeți sistemele pe care le executați.

Etapa 1: Problemă și soluție

Înarmați cu propria noastră definiție a observabilității, ne-am evaluat practicile existente și am formulat o enunțare a problemei. Până de curând, instrumentele noastre de observabilitate s-au bazat în principal pe valori. Un flux de lucru tipic presupunea analiza unui tablou de bord plin de diagrame cu valori tăiate și tăiate în cuburi de diferite combinații de atribute. Oamenii ar căuta corelații, dar deseori pleacă fără să împlinească perspective.

„Metricile sunt ușor de adăugat și de înțeles, dar le lipsesc atribute cu cardinalitate ridicată (de exemplu, ID-ul clientului), ceea ce face dificilă finalizarea unei investigații”

Valorile sunt ușor de adăugat și de înțeles, dar le lipsesc atribute cu cardinalitate ridicată (de exemplu, ID-ul clientului), ceea ce face dificilă finalizarea unei investigații. Anterior, câțiva campioni ai observabilității continuau fluxul de lucru folosind instrumente secundare (de exemplu, jurnalele, excepțiile etc.), încercând să acceseze informațiile cu cardinalitate ridicată și să construiască o imagine mai completă. Această abilitate necesita o practică constantă – o cerere nerealistă pentru majoritatea inginerilor de produs care sunt ocupați cu livrarea produsului.

Am identificat această lipsă de experiență de observabilitate consolidată ca o problemă care trebuie rezolvată. Am vrut să fie ușor pentru oricine să pună o întrebare arbitrară despre producție și să obțină informații fără a fi nevoie să stăpânească un set de instrumente deconectate, subconfigurate și costisitoare. Pentru a atenua problema, am decis să dublăm telemetria de urmărire.

Un tablou de bord operațional tipic pe care l-am folosit înainte de a ne dubla pe urme

De ce urme?

Orice instrument de observabilitate este doar un instrument cu un om în spate – iar oamenii au nevoie de vizualizări bune. Nu contează ce fel de date alimentează vizualizarea, doar că instrumentul vă permite să comutați fără probleme între diferite vizualizări și să obțineți perspective alternative asupra problemei.

Urmele au un avantaj imens față de alte date de telemetrie – ele codifică suficiente informații despre tranzacții pentru a alimenta aproape orice vizualizare. Construirea fluxurilor de lucru de observabilitate pe deasupra urmelor asigură o experiență consolidată fără a fi nevoie să comutați datele de bază sau instrumentul.

Unele dintre tipurile de vizualizări care pot fi alimentate de urme

Etapa 2: Implementarea urmelor

La Intercom începem puțin, decidem cum arată succesul și monitorizăm progresul pe parcurs. Obiectivul nostru principal a fost să confirmăm că urmele ar face fluxurile de lucru de observabilitate mai eficiente. Pentru asta, trebuia să punem urme în mâinile inginerilor cât mai curând posibil.

„În loc să instrumentăm aplicația noastră cu urme de la zero, am folosit o bibliotecă de urmărire existentă care s-a întâmplat să fie deja în dependențe”

Pentru a economisi timp, am folosit furnizorul nostru existent, Honeycomb, pentru dovada noastră de concept. Am construit deja o relație excelentă cu ei în timp ce le folosim instrumentul pentru evenimente structurate în trecut.

În loc să instrumentăm aplicația noastră cu urme de la zero, am folosit o bibliotecă de urmărire existentă care s-a întâmplat să fie deja în dependențe și am efectuat o mică ajustare pentru a converti datele de urmărire în formatul nativ Honeycomb. Am început cu o eșantionare deterministă simplă, reținând ~1% din toate tranzacțiile procesate.

Permiterea coechipierilor să adopte urme

Schimbarea unei organizații către urme nu este o faptă mică. Urmele sunt mai complexe decât valorile sau jurnalele și au o curbă de învățare abruptă. Instrumentele, conducta de date și instrumentele sunt toate importante, dar cea mai mare provocare este să le permiti colegilor să-și maximizeze utilizarea urmelor. Odată cu dovada noastră de concept în curs de producție, am început imediat să ne concentrăm pe construirea unei culturi a observabilității.

„Nu ne-am concentrat doar pe ingineri – am vorbit cu directori, manageri tehnici de programe, membri ai echipei de securitate și reprezentanți de asistență pentru clienți pentru a sublinia modul în care urmele i-ar putea ajuta să-și rezolve problemele specifice.”

Găsirea aliaților a fost cheia succesului. Am adunat un grup de campioni care erau deja pricepuți la observabilitate. Ei ne-au ajutat să confirmăm presupunerile noastre și să răspândească vestea despre urme în cadrul echipelor lor. Dar nu ne-am concentrat doar pe ingineri – am vorbit cu directori, manageri tehnici de programe, membri ai echipei de securitate și reprezentanți ai asistenței pentru clienți pentru a sublinia modul în care urmele i-ar putea ajuta să-și rezolve problemele specifice.

Personalizarea mesajului nostru a ajutat la blocarea asistenței. Introducerea de noi scule implică întotdeauna un anumit risc – demonstrând potențialul și entuziasmând oamenii, ne-am mărit șansele de succes.

Etapa 3: Alegerea furnizorului potrivit

Odată cu lansarea programului de activare, am început să ne uităm la furnizorii moderni centrați pe urmărire și am formulat un set de criterii pentru a evalua potențialii candidați.

Fluxuri de lucru : Am identificat fluxul de lucru exploratoriu ca fiind cel mai important – acesta le-ar permite inginerilor să detalieze în mod arbitrar datele de producție și să obțină informații prin vizualizări și atribute de înaltă cardinalitate. O mare parte a diagnosticării unei probleme este acela de a o identifica, iar asta înseamnă să înțelegeți cum arată „normalul”. Am vrut să le facilităm inginerilor să exploreze producția punând întrebări cât mai des posibil, nu doar atunci când apar probleme.

„Am vrut control deplin asupra modului în care datele vor fi eșantionate și reținute”

Controale de eșantionare și reținere : am dorit control total asupra modului în care datele vor fi eșantionate și reținute. Eșantionarea deterministă ne-a ajutat să ne punem în funcțiune rapid, dar am vrut să fim mai selectivi și să păstrăm mai multe urme „interesante” (de exemplu, erori, solicitări lente) folosind eșantionarea dinamică inteligentă, rămânând sub limita contractului.

Vizualizări precise de date : Am vrut să ne asigurăm că, indiferent de tehnica de eșantionare pe care am folosit-o, instrumentele de observabilitate le gestionează în mod transparent prin expunerea numerelor aproximate „adevărate” în vizualizări. Fiecare furnizor a abordat această problemă în mod diferit – unii necesită trimiterea tuturor datelor către un agregator global pentru a deduce valori pentru indicatori cheie precum rata de eroare, volumul etc. Aceasta nu a fost o opțiune pentru noi, având în vedere volumul masiv de date generat de instrumentația noastră bogată.

Prețuri : ne-am dorit o schemă de prețuri simplă, previzibilă, care să se coreleze cu valoarea pe care am obține-o de la instrument. Taxarea pentru cantitatea de date reținute și expuse părea corectă.

Valori de implicare : am dorit ca furnizorul să fie un partener bun și să ne ajute să urmărim adoptarea și eficacitatea instrumentului prin expunerea valorilor cheie de utilizare și nivelurilor de implicare.

Nu există un furnizor perfect, așa că fiți gata să faceți niște compromisuri. În cele din urmă, am ajuns la concluzia că Honeycomb nu numai că a funcționat mai bine pentru fluxul de lucru principal pe care l-am identificat, ci și a bifat căsuțele privind valorile de eșantionare, prețuri și utilizare – așa că am evitat migrarea costisitoare a furnizorului.

După un an dificil de muncă, am finalizat partea tehnică a programului de observabilitate. Aceasta este ceea ce am realizat:

• Principala noastră aplicație monolit a fost auto-instrumentată cu urme bogate în atribute de înaltă calitate.
• Inginerii au avut un set mic de metode convenabile pentru a adăuga instrumente personalizate la codul lor.
• Am implementat Honeycomb Refinery pentru a eșantiona datele în mod dinamic și pentru a păstra mai multe urme „interesante”. Am încurajat inginerii să configureze reguli personalizate de păstrare pentru un control mai granular. Pentru cele mai valoroase tranzacții și atunci când este fezabil din punct de vedere economic, am oferit reținere 100% pentru a oferi oamenilor datele de care aveau nevoie.

Etapa 4: Creșterea adopției

După ce ne-am angajat la Honeycomb și am finalizat lucrările la conducta de date, ne-am reîntors atenția către activare. Pentru a construi o cultură a observabilității, trebuie să faceți mai ușor pentru oameni să ajungă la bord. Iată câteva dintre modalitățile prin care am ajutat echipele să adopte noi instrumente de observabilitate:

Urmărirea în mediul de dezvoltare

Pentru a familiariza inginerii cu instrumentele de urmărire și pentru a-i încuraja să o adauge la codul lor, am oferit urmărirea opțională din mediul de dezvoltare locală cu urmele expuse în Honeycomb. Acest lucru i-a ajutat pe oameni să vizualizeze noi instrumente personalizate exact în același mod în care ar vedea-o atunci când codul va ajunge în producție.

Jurnalele pot fi dificil de citit și interpretat, în timp ce vizualizările de urme sunt mult mai structurate și organizate

Comenzi rapide de interogare Slackbot

Când producția are probleme, ultimul lucru pe care îl doriți este să trebuiască să căutați interogarea potrivită. Am adăugat o reacție bot personalizată la un mesaj „arată-mi performanța web”. Urmărirea linkului Slackbot deschide o performanță a punctelor finale web defalcate în funcție de serviciu.

Ne simplificăm fluxul de lucru privind observabilitatea cu un Slackbot care oferă o comandă rapidă către o interogare populară în instrumentele noastre de observabilitate

Etapa 5: Reflecții și pașii următori

Măsurarea adopției

Măsurarea rentabilității investiției (ROI) pe instrumentele de observabilitate este o provocare. Urmărirea numărului de utilizatori activi este un bun indicator al frecvenței cu care inginerii interacționează cu uneltele și am beneficiat foarte mult de valorile de utilizare ale Honeycomb.

Acest grafic arată creșterea numărului de utilizatori activi Honeycomb de când a început activarea observabilității

Am mers mai departe și am măsurat utilitatea acelor angajamente. Am postulat că, dacă informațiile obținute din instrumentele de observabilitate ar fi valoroase, oamenii le-ar împărtăși colegilor lor. Fluxurile noastre de lucru de inginerie depind în mare măsură de problemele Github, așa că am decis să numărăm numărul de probleme sau solicitări de extragere la care Honeycomb a fost menționat sau legat (urmă, rezultat al interogării etc.) ca proxy pentru o metrică de adoptare. Pe măsură ce ne-am dublat abilitarea spre sfârșitul anului 2021, am observat o explozie a numărului de numere care menționau Honeycomb, demonstrând că suntem pe drumul cel bun.

Diagramă cu bare care arată numărul de probleme GitHub în care Honeycomb este menționat în titlu sau descriere

Fluxuri de lucru neașteptate

Construirea unei baze solide de observabilitate a permis fluxuri de lucru pe care nu ne-am fi putut imagina înainte. Iată câteva dintre preferatele noastre:

Program de informare a costurilor : Deoarece urmărim tot traficul și avem intervale pentru interogări SQL, solicitări Elasticsearch etc., putem investiga creșterile de utilizare a părților partajate separate ale infrastructurii noastre (de exemplu, clusterul bazei de date) și le putem atribui unui singur client. Potrivind aceste date cu costul componentelor individuale ale infrastructurii, putem pune o etichetă de preț aproximativă pentru fiecare tranzacție pe care o servim. Observabilitatea a devenit în mod neașteptat o componentă integrală a programului nostru de costuri de infrastructură.

Îmbunătățirea auditului de securitate : capacitatea de a păstra 100% din tranzacțiile selectate ne-a permis să păstrăm toate interacțiunile cu consola noastră de date de producție, ajutând securitatea să stabilească o vizibilitate mai bună asupra accesului la datele clienților noștri.

Ce urmeaza?

Construirea unei culturi a observabilității va continua să facă parte din programul nostru tehnic: ne vom concentra pe îmbunătățirea materialului nostru de onboarding, pe țeserea în continuare a observabilității prin urme în operațiunile noastre de cercetare și dezvoltare și pe explorarea instrumentelor de front-end.

Sunteți interesat să vă alăturați echipei noastre? Consultați aici rolurile noastre de inginerie deschise.