SRE (Site Reliability Engineering) és un enfocament per garantir la disponibilitat de projectes web. Es considera un marc per a DevOps i parla sobre com aconseguir l'èxit en l'aplicació de les pràctiques de DevOps. Traducció en aquest article llibres de Google. Vaig preparar aquesta traducció jo mateix i em vaig basar en la meva pròpia experiència en la comprensió dels processos de seguiment. Al canal de Telegram и També vaig publicar un enllaç a la traducció del capítol 4 del mateix llibre sobre els objectius del nivell de servei.
Traducció per cat. Gaudeix de la lectura!
Els equips SRE de Google tenen principis bàsics i pràctiques recomanades per crear sistemes de monitorització i notificació amb èxit. Aquest capítol ofereix orientació sobre quins problemes pot trobar un visitant d'una pàgina web i com resoldre els problemes que dificulten la visualització de les pàgines web.
Definicions
No hi ha un únic vocabulari utilitzat per parlar de temes relacionats amb el seguiment. Fins i tot a Google, els termes següents no s'utilitzen habitualment, però enumerarem les interpretacions més habituals.
Seguiment
Recollida, processament, agregació i visualització de dades quantitatives en temps real sobre el sistema: nombre de peticions i tipus de peticions, nombre d'errors i tipus d'error, temps de processament de sol·licituds i temps d'activitat del servidor.
Monitorització de caixa blanca
Supervisió basada en mètriques que mostren els components interns del sistema, com ara els registres, les mètriques de perfils de la màquina virtual Java o les mètriques del controlador HTTP que generen estadístiques internes.
Monitorització de caixa negra
Prova el comportament de l'aplicació des del punt de vista de l'usuari.
panell
Una interfície (normalment web) que ofereix una visió general dels indicadors de salut clau dels serveis. El tauler pot tenir filtres, la possibilitat de seleccionar els indicadors que es mostren, etc. La interfície està dissenyada per identificar els indicadors que són més importants per als usuaris. El tauler també pot mostrar informació per al personal d'assistència tècnica: una cua de sol·licituds, una llista d'errors d'alta prioritat i un enginyer assignat per a una determinada àrea de responsabilitat.
Alerta (notificació)
Notificacions destinades a ser rebudes per una persona per correu electrònic o altres mitjans, que es poden desencadenar per errors o un augment de la cua de sol·licituds. Les notificacions es classifiquen en: entrades, alertes per correu electrònic i missatges de missatgeria instantània.
Causa arrel
Un defecte del programari o error humà que, un cop corregit, no s'hauria de tornar a produir. El problema pot tenir diverses causes principals: automatització insuficient del procés, defecte del programari, elaboració insuficient de la lògica de l'aplicació. Cadascun d'aquests factors pot ser la causa principal, i cadascun d'ells s'ha d'eliminar.
Node i màquina (node i màquina)
Termes intercanviables per referir-se a una única instància d'una aplicació en execució en un servidor físic, màquina virtual o contenidor. Una màquina pot allotjar diversos serveis. Els serveis poden ser:
- connectats entre si: per exemple, un servidor de memòria cau i un servidor web;
- serveis no relacionats en una única peça de maquinari: per exemple, un dipòsit de codi i un assistent per a un sistema de configuració, com ara o .
Empenta
Qualsevol canvi en la configuració del programari.
Per què cal un seguiment
Hi ha diversos motius pels quals cal supervisar les aplicacions:
Anàlisi de tendències a llarg termini
Quina mida té la base de dades i quina velocitat creix? Com canvia el nombre diari d'usuaris?
Comparació de rendiment
Les sol·licituds són més ràpides a Acme Bucket of Bytes 2.72 en comparació amb Ajax DB 3.14? Quant millor s'emmagatzemen les sol·licituds a la memòria cau després de l'aparició d'un node addicional? El lloc funciona més lent en comparació amb la setmana passada?
Alerta (notificacions)
Alguna cosa està trencada i algú ho ha d'arreglar. O alguna cosa es trencarà aviat i algú ho ha de comprovar aviat.
Creació de quadres de comandament
Els taulers han de respondre a preguntes bàsiques i incloure alguna cosa de — retards (latència), trànsit (trànsit), errors (errors) i mida de càrrega (saturació).
Realització d'anàlisis retrospectives (depuració)
El retard en el processament de la sol·licitud ha augmentat, però què més va passar al mateix temps?
Els sistemes de monitorització són útils com a font de dades per als sistemes d'intel·ligència empresarial i per facilitar l'anàlisi d'incidències de seguretat. Com que aquest llibre se centra en àrees d'enginyeria en les quals els SRE tenen experiència, aquí no parlarem de les tècniques de monitorització.
La supervisió i les alertes permeten que el sistema us digui quan s'ha avariat o quan està a punt d'avariar-se. Quan un sistema no pot reparar-se automàticament, volem que un humà analitzi l'alerta, determini si el problema encara està actiu, el resolgui i determini la causa arrel. Si no auditeu els components del sistema, mai rebeu una alerta simplement perquè "alguna cosa sembla una mica estranya".
Carregar una persona amb notificacions és un ús força car del temps d'un empleat. Si l'empleat està treballant, l'alerta interromp el procés de treball. Si l'empleat és a casa, l'alerta interromp l'horari personal i possiblement el son. Quan les alertes es produeixen amb massa freqüència, els empleats les repassen, les posposen o ignoren les alertes entrants. De tant en tant ignoren l'alerta real, que queda emmascarada pels esdeveniments de soroll. Les interrupcions del servei poden durar llargs períodes de temps, ja que els esdeveniments de soroll impedeixen que el problema es diagnostiqui i es corregeixi ràpidament. Els sistemes d'avís efectius tenen una bona relació senyal-soroll.
Establir expectatives raonables per al sistema de seguiment
Configurar la supervisió d'una aplicació complexa és una tasca d'enginyeria complexa en si mateixa. Fins i tot amb una infraestructura important d'eines de recollida, visualització i alerta, un equip de Google SRE de 10 a 12 membres sol incloure una o dues persones l'objectiu principal de les quals és crear i mantenir sistemes de supervisió. Aquesta xifra ha anat disminuint amb el temps a mesura que anem consolidant i centralitzant la infraestructura de monitorització, però cada equip SRE normalment té almenys una persona dedicada exclusivament a la supervisió. Hem de dir que, tot i que els taulers de control del sistema són força interessants de veure, els equips SRE eviten amb cura les situacions que requereixen que algú miri una pantalla per controlar els problemes.
En general, Google s'ha passat a sistemes de monitoratge senzills i ràpids amb eines d'anàlisi posteriors al fet òptimes. Evitem els sistemes "màgics" que intenten predir llindars o detectar automàticament la causa arrel. Els sensors que detecten contingut no desitjat a les sol·licituds dels usuaris finals són l'únic contraexemple; Mentre aquests sensors siguin senzills, poden detectar ràpidament les causes d'anomalies greus. Altres formats per utilitzar dades de monitorització, com ara la planificació de la capacitat o la previsió de trànsit, són més complexos. L'observació durant un període de temps molt llarg (mesos o anys) a una taxa de mostreig baixa (hores o dies) revelarà una tendència a llarg termini.
L'equip de Google SRE ha tingut un èxit mixt amb jerarquies de dependència complexes. Poques vegades fem servir regles com "si descobreixo que la base de dades és lenta, rebo una alerta que la base de dades és lenta, en cas contrari rebo una alerta que el lloc és lent". Les regles basades en la dependència solen fer referència a parts immutables del nostre sistema, com ara el sistema per filtrar el trànsit dels usuaris al centre de dades. Per exemple, "si el filtratge de trànsit al centre de dades està configurat, no m'aviseu sobre els retards en el processament de les sol·licituds dels usuaris" és una regla general per a les alertes del centre de dades. Pocs equips de Google admeten jerarquies de dependència complexes perquè la nostra infraestructura té un índex constant de refactorització contínua.
Algunes de les idees descrites en aquest capítol encara són rellevants: sempre hi ha l'oportunitat de passar més ràpidament del símptoma a la causa arrel, especialment en sistemes en constant canvi. Per tant, tot i que en aquest capítol es descriuen alguns objectius dels sistemes de monitorització i com aconseguir-los, és important que els sistemes de monitoratge siguin senzills i comprensibles per a tots els membres de l'equip.
De la mateixa manera, per mantenir els nivells de soroll baixos i els nivells de senyal alts, els enfocaments per controlar els actius alertats han de ser molt senzills i fiables. Les normes que generen avisos per a les persones han de ser fàcils d'entendre i presentar un problema clar.
Símptomes versus causes
El vostre sistema de control hauria de respondre a dues preguntes: "què es va trencar" i "per què es va trencar".
"El que es va trencar" parla del símptoma, i "per què es va trencar" parla de la causa. La taula següent mostra exemples d'aquestes connexions.
Un símptoma
Raó
S'està obtenint l'error HTTP 500 o 404
Els servidors de bases de dades rebutgen connexions
Respostes lentes del servidor
Alta utilització de la CPU o cable Ethernet danyat
Els usuaris de l'Antàrtida no reben GIF de gats
El vostre CDN odia els científics i els gats, de manera que algunes adreces IP van acabar a la llista negra
El contingut privat s'ha fet disponible des de tot arreu
El llançament d'una nova versió de programari va fer que el tallafoc oblidés totes les ACL i permetés que tothom hi entrés
"Què" i "per què" són alguns dels elements bàsics més importants per crear un bon sistema de monitorització amb el màxim de senyal i el mínim soroll.
Caixa negra vs caixa blanca
Combinem un ampli monitoratge de caixa blanca amb un monitoratge modest de caixa negra per a mètriques crítiques. La manera més fàcil de comparar Black-box amb White-box és que Black-box està centrat en els símptomes i és reactiu en lloc d'un control proactiu: "el sistema no funciona correctament ara mateix". La caixa blanca depèn de les capacitats de verificació interna dels sistemes: registres d'esdeveniments o servidors web. Així, White-box permet detectar problemes imminents, errors que semblen ser una retransmissió d'una sol·licitud, etc.
Tingueu en compte que en un sistema multicapa, un símptoma a l'àrea de responsabilitat d'un enginyer és un símptoma a l'àrea de responsabilitat d'un altre enginyer. Per exemple, el rendiment de la base de dades ha disminuït. Les lectures lentes de la base de dades són un símptoma de la base de dades SRE que les detecta. Tanmateix, per a un SRE frontal que observa un lloc web lent, la causa de la mateixa lectura lenta de la base de dades és una base de dades lenta. Per tant, el seguiment de la caixa blanca de vegades es centra en els símptomes i de vegades en la causa, depenent de l'extensitat que sigui.
Quan es recull la telemetria per a la depuració, cal la supervisió de la caixa blanca. Si els servidors web tarden a respondre a les consultes de la base de dades, cal saber amb quina rapidesa es comunica el servidor web amb la base de dades i amb quina rapidesa respon. En cas contrari, no podreu diferenciar entre un servidor de base de dades lent i un problema de xarxa entre el servidor web i la base de dades.
El seguiment de la caixa negra té un avantatge clau a l'hora d'enviar alertes: activeu la notificació al destinatari quan el problema ja ha provocat símptomes reals. D'altra banda, el seguiment no serveix per a un problema de caixa negra que encara no ha sorgit però que és imminent.
Quatre senyals d'or
Els quatre senyals de monitoratge daurats són la latència, el trànsit, els errors i la saturació. Si només podeu mesurar quatre mètriques del sistema d'usuari, centreu-vos en aquestes quatre.
Retard
El temps necessari per tramitar la sol·licitud. És important distingir entre la latència de les sol·licituds reeixides i les que no tenen èxit. Per exemple, un error HTTP 500 causat per una pèrdua de connexió a una base de dades o un altre backend es pot diagnosticar molt ràpidament, però, un error HTTP 500 pot indicar una sol·licitud fallida. La determinació de l'impacte d'un error 500 en la latència general pot conduir a conclusions errònies. D'altra banda, un error lent és fins i tot un error ràpid! Per tant, és important controlar la latència dels errors en lloc de filtrar-los.
trànsit
El nombre de sol·licituds al vostre sistema es mesura en mètriques de sistema d'alt nivell. Per a un servei web, aquesta mesura normalment representa el nombre de sol·licituds HTTP per segon, dividit per la naturalesa de les sol·licituds (per exemple, contingut estàtic o dinàmic). Per a un sistema de transmissió d'àudio, aquesta mesura pot centrar-se en la velocitat d'E/S de la xarxa o en el nombre de sessions simultànies. Per a un sistema d'emmagatzematge de valor-clau, aquesta mesura podria ser transaccions o resultats de cerca per segon.
Errors
Aquesta és la taxa de sol·licituds fallides que són explícites (per exemple, HTTP 500), implícites (per exemple, HTTP 200 però combinades amb contingut no vàlid) o polítiques (per exemple, "Si heu capturat una resposta en un segon, qualsevol segon és un error"). Si els codis de resposta HTTP no són suficients per expressar totes les condicions de fallada, és possible que es requereixin protocols secundaris (interns) per detectar fallades parcials. El seguiment de totes aquestes sol·licituds errònies pot no ser informatiu, mentre que les proves del sistema d'extrem a extrem us ajudaran a detectar que esteu processant contingut incorrecte.
Saturació
La mètrica mostra amb quina intensitat s'utilitza el vostre servei. Aquesta és una mesura de supervisió del sistema que identifica els recursos que estan més restringits (per exemple, en un sistema restringit per la memòria, mostra la memòria, en un sistema restringit per E/S, mostra el nombre d'E/S). Tingueu en compte que molts sistemes degraden el rendiment abans d'arribar al 100% d'utilització, per la qual cosa és important tenir un objectiu d'utilització.
En sistemes complexos, la saturació es pot complementar amb mesures de càrrega de nivell superior: pot el vostre servei gestionar correctament el doble de trànsit, gestionar només un 10% més de trànsit o gestionar encara menys trànsit del que fa actualment? Per a serveis senzills que no tenen paràmetres que canviïn la complexitat de la sol·licitud (per exemple, "No em doneu res" o "Necessito un nombre enter monòton únic"), que rarament canvien la configuració, pot ser adequat un valor de prova de càrrega estàtica. Tanmateix, com s'ha comentat al paràgraf anterior, la majoria dels serveis han d'utilitzar senyals indirectes, com ara la utilització de la CPU o l'amplada de banda de la xarxa, que tenen un límit superior conegut. L'augment de la latència és sovint un indicador principal de saturació. Mesurar el temps de resposta del percentil 99 en una finestra petita (per exemple, un minut) pot proporcionar un senyal de saturació molt primerenc.
Finalment, la saturació també s'associa amb prediccions sobre la saturació imminent, per exemple: "Sembla que la vostra base de dades omplirà el vostre disc dur en 4 hores".
Si mesureu els quatre senyals daurats i quan hi ha un problema amb una de les mètriques (o, en el cas de saturació, un problema proper), aviseu una persona, el vostre servei estarà més o menys cobert per la supervisió.
Preocupacions per la "cua" (o instrumentació i rendiment)
Quan es crea un sistema de monitorització des de zero, hi ha la temptació de desenvolupar un sistema basat en valors mitjans: latència mitjana, utilització mitjana de la CPU dels nodes o plenitud mitjana de la base de dades. El perill dels dos últims exemples és evident: els processadors i les bases de dades s'eliminen d'una manera molt imprevisible. El mateix s'aplica al retard. Si executeu un servei web amb una latència mitjana de 100 ms amb 1000 sol·licituds per segon, l'1% de les sol·licituds pot trigar 5 segons. Si els usuaris depenen de diversos serveis web d'aquest tipus, el percentil 99 d'un backend pot convertir-se fàcilment en el temps de resposta mitjà del frontend.
La manera més senzilla de diferenciar entre la mitjana lenta i la cua molt lenta de les sol·licituds és recollir mesures de les sol·licituds expressades en estadístiques (una bona eina per mostrar són els histogrames) en lloc de les latències reals: quantes sol·licituds va atendre el servei que van trigar entre 0 ms i 10 ms, entre 10 ms i 30 ms, entre 30 ms i 100 ms, entre 100 ms i 300 ms, etc. Ampliar els límits de l'histograma de manera aproximadament exponencial (per un factor aproximat de 3) sovint és una manera senzilla de visualitzar la distribució. de peticions.
Selecció del nivell de detall adequat per a les mesures
Els diferents elements del sistema s'han de mesurar amb diferents nivells de detall. Per exemple:
- El seguiment de la utilització de la CPU durant un període de temps no mostrarà pics a llarg termini que condueixin a altes latències.
- D'altra banda, per a un servei web orientat a no més de 9 hores d'inactivitat a l'any (99,9% de temps de funcionament anual), és probable que la comprovació d'una resposta HTTP 200 més d'una o dues vegades per minut sigui innecessàriament freqüent.
- De la mateixa manera, probablement no sigui necessari comprovar la disponibilitat del 99,9% de l'espai del disc dur més d'una vegada cada 1-2 minuts.
Tingueu cura de com estructureu la granularitat de les vostres mesures. Recollir la càrrega de la CPU una vegada per segon pot proporcionar dades interessants, però aquestes mesures freqüents poden ser molt costoses de recopilar, emmagatzemar i analitzar. Si el vostre objectiu de supervisió requereix una granularitat elevada i no requereix una gran capacitat de resposta, podeu reduir aquests costos configurant la recollida de mètriques al servidor i després configurant un sistema extern per recopilar i agregar aquestes mètriques. Podries:
- Mesureu la càrrega de la CPU cada segon.
- Redueix el detall al 5%.
- Agrega mètriques cada minut.
Aquesta estratègia us permetrà recopilar dades amb una granularitat elevada sense incórrer en una gran sobrecàrrega d'anàlisi i emmagatzematge.
Tan senzill com sigui possible, però no més senzill
La superposició de diferents requisits uns sobre els altres pot donar lloc a un sistema de control molt complex. Per exemple, el vostre sistema pot tenir els següents elements complicats:
- Alertes segons diferents llindars de latència de processament de sol·licituds, en diferents percentils, per a tot tipus d'indicadors diferents.
- Escriptura de codi addicional per detectar i identificar possibles causes.
- Crea taulers de control relacionats per a cadascuna de les possibles causes dels problemes.
Les fonts de complicacions potencials no s'acaben mai. Com tots els sistemes de programari, la supervisió pot arribar a ser tan complexa que esdevé fràgil i difícil de canviar i mantenir.
Per tant, dissenyeu el vostre sistema de monitorització per simplificar-lo al màxim. Quan escolliu què voleu fer el seguiment, tingueu en compte el següent:
- Les regles que més sovint capturen incidents reals han de ser tan senzilles, previsibles i fiables com sigui possible.
- S'hauria d'eliminar la configuració per a la recollida, l'agregació i les alertes de dades que es realitzen amb poca freqüència (per exemple, menys que trimestralment per a alguns equips SRE).
- Les mètriques que es recullen però que no es mostren a cap tauler de previsualització ni que s'utilitzen per cap alerta són candidates a suprimir-se.
A Google, la recopilació i l'agregació de mètriques bàsiques, combinades amb alertes i taulers de control, funcionen bé com a sistema relativament autònom (el sistema de monitorització de Google en realitat es divideix en diversos subsistemes, però la gent normalment coneix tots els aspectes d'aquests subsistemes). Pot ser temptador combinar la supervisió amb altres tècniques per examinar sistemes complexos: perfils detallats del sistema, depuració de processos, detalls de seguiment sobre excepcions o errors, proves de càrrega, recopilació i anàlisi de registres o inspecció de trànsit. Tot i que la majoria d'aquestes coses tenen punts en comú amb el control bàsic, barrejar-les donarà lloc a massa resultats i crearà un sistema complex i fràgil. Com passa amb molts altres aspectes del desenvolupament de programari, donar suport a diferents sistemes amb punts d'integració clars, senzills i poc acoblats és la millor estratègia (per exemple, utilitzar una API web per recuperar dades agregades en un format que pugui mantenir-se coherent durant un llarg període de temps). ).
Lligar els principis junts
Els principis tractats en aquest capítol es poden combinar en una filosofia de monitorització i alerta que sigui aprovada i seguida pels equips de Google SRE. Adherir-se a aquesta filosofia de seguiment és desitjable, és un bon punt de partida per crear o revisar la vostra metodologia d'alertes i us pot ajudar a fer les preguntes adequades de la vostra funció d'operacions, independentment de la mida de la vostra organització o de la complexitat del servei o sistema.
Quan creeu regles de supervisió i alerta, fer les preguntes següents us pot ajudar a evitar falsos positius i alertes innecessàries:
- Detecta aquesta regla un estat del sistema, d'altra manera indetectable, que és urgent, crida a l'acció i afecta inevitablement a l'usuari?
- Puc ignorar aquest avís sabent que és benigne? Quan i per què puc ignorar aquest avís i com puc evitar aquest escenari?
- Aquesta alerta significa que els usuaris es veuen afectats negativament? Hi ha situacions en què els usuaris no es veuen afectats negativament, com ara mitjançant el filtratge de trànsit o quan s'utilitzen sistemes de prova per als quals s'haurien de filtrar les alertes?
- Puc prendre mesures com a resposta a aquesta alerta? Són urgents aquestes mesures o es poden esperar fins al matí? Es pot automatitzar una acció de manera segura? Aquesta acció serà una solució a llarg termini o una solució alternativa a curt termini?
- Algunes persones reben diverses alertes per aquest problema, per tant, hi ha alguna manera de reduir el nombre d'alertes?
Aquestes preguntes reflecteixen la filosofia fonamental dels sistemes d'alertes i avisos:
- Cada vegada que arriba una alerta, he de reaccionar immediatament. Puc reaccionar amb urgència diverses vegades al dia abans de cansar-me.
- Cada alerta ha de ser rellevant.
- Tota resposta a una alerta ha de requerir la intervenció humana. Si la notificació es pot processar automàticament, no hauria d'arribar.
- Les alertes haurien de ser sobre un problema o esdeveniment nou que no existia abans.
Aquest enfocament difumina certes distincions: si l'alerta compleix les quatre condicions anteriors, no importa si l'alerta s'envia des d'un sistema de monitorització de caixa blanca o caixa negra. Aquest enfocament també reforça certes diferències: és millor dedicar-se molt més a identificar els símptomes que a les causes; quan es tracta de causes, només cal preocupar-se per les causes inevitables.
Seguiment a llarg termini
En els entorns de productivitat actuals, els sistemes de monitorització controlen un sistema de producció en constant evolució amb arquitectura de programari canviant, característiques de càrrega de treball i objectius de rendiment. Les alertes que actualment són difícils d'automatitzar poden arribar a ser habituals, potser fins i tot val la pena abordar-les. En aquest punt, algú ha de trobar i eliminar les causes arrels del problema; si aquesta resolució no és possible, la resposta a l'alerta requereix una automatització total.
És important que les decisions de seguiment es prenguin tenint en compte objectius a llarg termini. Cada alerta que s'executa avui distreu una persona de millorar el sistema demà, de manera que sovint es produeix una reducció de la disponibilitat o rendiment d'un sistema productiu pel temps necessari per millorar el sistema de monitorització a llarg termini. Vegem dos exemples per il·lustrar aquest fenomen.
Bigtable SRE: A Tale of Over-Alert
La infraestructura interna de Google normalment es subministra i es mesura en funció d'un nivell de servei (SLO). Fa molts anys, el servei SLO de Bigtable es basava en el rendiment mitjà d'una transacció sintètica que simulava un client en directe. A causa de problemes a Bigtable i als nivells més baixos de la pila d'emmagatzematge, el rendiment mitjà va ser impulsat per una cua "gran": el pitjor 5% de les consultes sovint eren significativament més lentes que la resta.
S'enviaven notificacions per correu electrònic a mesura que s'acostava el llindar de SLO i s'enviaven alertes de missatgeria quan es superava l'SLO. Tots dos tipus d'alertes s'enviaven amb força freqüència, consumint quantitats inacceptables de temps d'enginyeria: l'equip va passar una quantitat significativa de temps ordenant les alertes per trobar les poques que eren realment rellevants. Sovint ens vam perdre un problema que realment afectava els usuaris perquè només algunes de les alertes eren per a aquest problema específic. Moltes de les alertes no eren urgents a causa de problemes comprensibles a la infraestructura i es van processar de manera estàndard, o no es van processar gens.
Per solucionar la situació, l'equip va adoptar un enfocament de tres eixos: mentre treballem dur per millorar el rendiment de Bigtable, vam establir temporalment el nostre objectiu SLO per ser el percentil 75 per a la latència de resposta a les consultes. També vam desactivar les alertes per correu electrònic perquè n'hi havia tantes que era impossible dedicar temps a diagnosticar-les.
Aquesta estratègia ens va permetre començar a solucionar problemes a llarg termini a Bigtable i als nivells inferiors de la pila d'emmagatzematge, en lloc de solucionar constantment problemes tàctics. Els enginyers podrien fer el treball sense ser bombardejats amb alertes tot el temps. En definitiva, ajornar temporalment el processament d'alertes ens va permetre millorar la qualitat del nostre servei.
Gmail: Respostes humanes algorítmiques previsibles
En els seus inicis, Gmail es va construir sobre un sistema de gestió de processos de cua de treball modificat que estava dissenyat per processar fragments d'un índex de cerca per lots. Workqueue es va adaptar a processos de llarga durada i posteriorment es va aplicar a Gmail, però alguns errors en el codi opac del programador van resultar molt difícils de solucionar.
Aleshores, el seguiment de Gmail estava estructurat de manera que s'activarien alertes quan es cancel·lessin tasques individuals mitjançant Workqueue. Aquest enfocament no era ideal perquè fins i tot en aquell moment, Gmail realitzava milers de tasques, cadascuna de les quals es proporcionava a una fracció d'un percentatge dels nostres usuaris. Ens preocupava molt oferir als usuaris de Gmail una bona experiència d'usuari, però la gestió de tantes alertes estava fora de l'abast.
Per solucionar aquest problema, Gmail SRE va crear una eina per ajudar a depurar el programador de la millor manera possible per minimitzar l'impacte sobre els usuaris. L'equip va tenir algunes discussions sobre si simplement automatitzar tot el cicle des del descobriment del problema fins a la correcció fins que es va trobar una solució a llarg termini, però alguns estaven preocupats que aquesta solució retardés la solució del problema.
Aquesta tensió era habitual a l'equip i sovint reflectia una falta de confiança en l'autodisciplina: mentre que alguns membres de l'equip volen donar temps per a la solució correcta, d'altres es preocupen que la solució definitiva s'oblidi i la solució temporal trigarà per sempre. Aquest problema mereix atenció perquè és massa fàcil solucionar els problemes temporalment en lloc de fer que la situació sigui permanent. Els directius i el personal tècnic tenen un paper clau a l'hora d'implementar solucions a llarg termini, donant suport i prioritzant solucions potencialment a llarg termini fins i tot després que el "dolor" inicial disminueixi.
Les alertes regulars i repetitives i les respostes algorítmiques haurien de ser una bandera vermella. La reticència del vostre equip a automatitzar aquestes alertes significa que l'equip no té confiança en poder confiar en els algorismes. Aquest és un problema greu que cal abordar.
Llarg termini
Un tema comú enllaça els exemples de Bigtable i Gmail: la competència entre la disponibilitat a curt i llarg termini. Sovint, un fort esforç pot ajudar un sistema fràgil a aconseguir una alta disponibilitat, però aquest camí sol ser de curta durada, ple d'esgotament de l'equip i dependència d'un petit nombre de membres d'aquest mateix equip heroic.
La reducció controlada i a curt termini de la disponibilitat sovint és dolorosa, però estratègicament important per a l'estabilitat del sistema a llarg termini. És important no mirar cada alerta de manera aïllada, sinó considerar si el nivell global de volum d'alertes condueix a un sistema saludable, degudament accessible, amb un equip viable i un pronòstic favorable. Analitzem les estadístiques de freqüència d'alerta (generalment expressades com a incidents per torn, on un incident pot consistir en múltiples incidents relacionats) en informes trimestrals a la direcció, cosa que permet als responsables de prendre decisions tenir una visió continuada de la càrrega del sistema d'alerta i de la salut general de l'equip.
Conclusió
El camí cap a un seguiment i una alerta saludables és senzill i clar. Se centra en els símptomes del problema que desencadenen alertes, i el seguiment de la causa serveix com a ajuda per a la depuració dels problemes. La supervisió dels símptomes és més fàcil com més amunt esteu a la pila que controleu, tot i que la supervisió de la càrrega i el rendiment de la base de dades s'hauria de fer directament a la base de dades. Les notificacions per correu electrònic tenen una utilitat molt limitada i solen convertir-se fàcilment en soroll; en comptes d'això, hauríeu d'utilitzar un tauler que controli tots els problemes actuals que desencadenen alertes per correu electrònic. El tauler també es pot combinar amb un registre d'esdeveniments per analitzar les correlacions històriques.
A llarg termini, cal aconseguir una rotació exitosa d'alertes sobre símptomes i problemes reals imminents, adaptant els objectius per garantir que el seguiment admeti un diagnòstic ràpid.
Gràcies per llegir la traducció fins al final. Subscriu-te al meu canal de Telegram sobre monitoratge и .
Font: www.habr.com
