Guàrdies ben fetes: resposta a incidents sense cremar l'equip
Les guàrdies són una de les maneres més ràpides d'enfonsar la moral d'un equip d'enginyeria si es fan malament. I la majoria d'empreses les fan malament.
Els símptomes són previsibles: sempre reben les alertes les mateixes dues persones, perquè ningú més «coneix prou bé el sistema». Els enginyers arriben a la setmana de guàrdia amb angúnia. Els incidents es repeteixen perquè ningú no ataca les causes arrel. Els millors enginyers marxen, i tu no entens per què la retenció és tan dolenta.
He dut el busca durant anys de resposta a incidents a escala enterprise, i et puc dir que construir una cultura de guàrdia sana no és complicat. Cal pensar amb claredat, tenir quatre bones eines i un lideratge que tracti la guàrdia com una responsabilitat de primer ordre, no com un afegitó.
SLA vs. SLO: saber què gestiones realment
Abans de muntar una rotació de guàrdia, has de saber què defenses. I això comença per distingir entre SLA i SLO, perquè la majoria d'equips els confonen.
Un SLA (Service Level Agreement) és un contracte amb els teus clients: «Garantim un 99,9% de disponibilitat; si l'incomplim, rebràs crèdits de servei». Els SLA tenen conseqüències legals i financeres.
Un SLO (Service Level Objective) és un objectiu intern més estricte que l'SLA. Si l'SLA promet un 99,9%, l'SLO pot apuntar al 99,95%. L'SLO et dona marge — un error budget — abans d'incomplir l'SLA.
Si el teu SLO és del 99,95% en una finestra mòbil de 30 dies, tens uns 21 minuts d'indisponibilitat permesos al mes. Mentre vas sobrat de pressupost, desplega funcionalitats amb ambició. Quan te'l vas cremant, frena i prioritza la fiabilitat.
Per què això importa per a les guàrdies: els enginyers de guàrdia han de saber quins SLO defensen i en quin estat és l'error budget. «Ens queden 14 minuts de pressupost aquest mes» crea urgència. «Mantén el sistema dret» és tan vague que no vol dir res.
Una rotació sostenible comença a quatre persones
L'error més habitual amb les guàrdies és fer-les massa feixugues per a cada persona. Això és el que funciona en equips de 5-8 enginyers, la mida típica d'una startup:
Rotació setmanal amb un únic primari. Una persona atén totes les alertes durant una setmana (de dilluns a dilluns). Senzill i eficaç si hi ha prou gent a la rotació.
La rotació mínima viable és de quatre persones. Amb menys de quatre, cadascú està de guàrdia més del 25% del temps: insostenible. Amb 5-6, surt una cadència còmoda d'una setmana de cada cinc.
Follow-the-sun per a equips distribuïts. Els enginyers d'Europa cobreixen de 08.00 a 20.00 CET i els d'Amèrica, la resta. Ningú no perd hores de son. És un dels avantatges reals dels equips distribuïts.
Guàrdia secundària com a via d'escalada. Si el primari no ho resol en 30-60 minuts, l'incident escala al secundari — algú amb un coneixement més profund del sistema. Fes rotar tots dos rols.
Norma innegociable: a la persona de guàrdia no se li pot exigir el mateix rendiment a l'sprint. Estar de guàrdia vol dir ser interrompible. Si a sobre li demanes que tanqui 8 story points, l'aboques a fer malament totes dues coses.
La base d'eines són quatre eines, no una plataforma
No cal una gran inversió en eines, però sí els fonaments:
Alertes i avisos: PagerDuty o Opsgenie. S'encarreguen de l'encaminament d'alertes, les polítiques d'escalada, els calendaris i els canvis de torn. PagerDuty és l'estàndard del sector; Opsgenie (ara dins d'Atlassian) és una alternativa sòlida i més barata. No et refiïs de les notificacions de Slack ni del correu per avisar la gent: Slack se silencia, els correus passen de llarg. Una trucada de PagerDuty a les tres de la matinada no s'ignora.
Runbooks: per a cada alerta que desperta algú hi hauria d'haver un runbook — un document que respon: què vol dir aquesta alerta? Quina és la causa més probable? Quines són les tres primeres coses a comprovar? Com es mitiga? On són els logs i els dashboards? Un runbook converteix 45 minuts de pànic en un diagnòstic de 10. Guarda'ls al wiki i enllaça'ls directament des de l'alerta.
Pàgina d'estat: Statuspage (Atlassian), Instatus o fins i tot una pàgina estàtica ben senzilla. Quan alguna cosa cau, els clients ho han de saber per la teva pàgina d'estat, no perquè proven d'usar el producte i no se'n surten. L'enginyer de guàrdia ha de poder actualitzar-la en menys d'un minut.
Canal d'incident: un canal de Slack (o equivalent) que es crea automàticament per a cada incident. Tota la comunicació hi passa: ni missatges directes ni fils paral·lels. Així obtens una cronologia automàtica que val or per al postmortem.
Postmortems sense culpables: com se'n fa un de debò
El «postmortem sense culpables» s'ha convertit en una etiqueta de moda que molts equips diuen que practiquen i pocs practiquen de veritat. Un de debò té aquesta pinta:
Quan: dins de les 48 hores següents a la resolució. Si esperes una setmana, la gent ja ha oblidat els detalls.
Qui hi assisteix: tothom qui ha intervingut en l'incident, més qualsevol que en vulgui aprendre.
Estructura:
- Reconstrucció de la cronologia. Què va passar i en quin ordre, del primer senyal fins a la resolució.
- Anàlisi de la causa arrel. No «qui l'ha vessada», sinó «què hi havia al sistema que ho ha permès». Un error humà no és mai la causa arrel; ho és el sistema que l'ha deixat arribar a producció.
- Factors contribuents. Què va fer lenta la detecció? Què va complicar la resolució?
- Accions. Concretes, assignades i amb data. «Millorar el monitoratge» no és una acció. «Afegir una alerta quan la taxa d'error de pagaments superi el 2% durant 5 minuts, assignada a la Sofia, per al 15 de setembre», sí que ho és.
L'element cultural crític: ningú no és castigat per un incident. Si la gent té por del retret, amaga informació. Si amaga informació, no pots aprendre. I si no pots aprendre, els incidents es repeteixen.
Compensar les guàrdies com cal
Aquí em planto: si no compenses els enginyers de guàrdia, no tens una rotació — tens explotació.
Estar de guàrdia et condiciona el temps personal. No pots anar d'acampada on no hi ha cobertura. Sempre tens el portàtil a mà. Fer veure que «forma part de la feina» és la manera més ràpida de perdre la teva millor gent.
Conec el contraargument: els sous sènior ja ho porten incorporat. A vegades és veritat — i si aquest és el teu model, endavant, però posa-ho per escrit al contracte. La compensació implícita no és res més que feina no pagada disfressada.
Models de compensació que funcionen:
- Plus fix per torn de guàrdia. 200-500 EUR per setmana, tant si reps alertes com si no.
- Bonificació per incident. Compensació addicional per cada resposta real fora de l'horari laboral.
- Descans compensatori. T'han despertat a les tres de la matinada i hi has dedicat dues hores? Mig dia lliure l'endemà. Innegociable.
- Combinació. Plus fix + descans compensatori és el model més habitual i més equitatiu.
El que importa és que sigui explícit, que consti al contracte laboral i que s'apliqui de manera consistent.
Senyals que la teva cultura de guàrdia fa aigües
Si res d'això et sona, tens feina a fer:
- La gent té pànic a la setmana de guàrdia. No una molèstia lleu: pànic de debò. En parlen als 1:1 i s'intercanvien torns constantment.
- Sempre acaba rebent l'alerta la mateixa persona. Coneixement concentrat en una sola persona o alertes mal configurades — sigui el que sigui, és insostenible.
- Els incidents es repeteixen. La mateixa fallada cada poques setmanes. Les accions del postmortem no es prioritzen mai.
- Ni compensació ni reconeixement. La guàrdia es dona per feta però és invisible.
- La guàrdia es fa servir de ritu d'iniciació. Els enginyers nous entren de guàrdia abans d'entendre el sistema.
- No hi ha runbooks. Cada incident és una investigació des de zero.
Tot això té solució, i cap de les solucions no demana un gran pressupost. Si aquest fos el meu equip, això és el que faria aquest trimestre:
- Auditar cada alerta que desperta una persona. Si no té runbook, escriure'l o deixar d'avisar-ne.
- Portar la rotació com a mínim a quatre persones i deixar la via d'escalada per escrit.
- Posar la compensació de guàrdia al contracte laboral — plus fix, descans compensatori o tots dos.
- Fer un postmortem sense culpables dins de les 48 hores del proper incident, amb accions assignades i datades.
El que demanen totes quatre és un lideratge que es prengui la salut operativa tan seriosament com el lliurament de funcionalitats.
A Conectia, els enginyers sènior que integrem als teus equips han viscut cultures de guàrdia bones i de terribles. Aporten maduresa operativa: escriuen runbooks, configuren bé les alertes i construeixen l'automatització que evita els incidents en lloc de limitar-se a respondre'ls. Quan al teu equip hi ha gent que tracta la fiabilitat en producció com un ofici, la guàrdia deixa de ser una càrrega i passa a ser una part normal i ben gestionada de la vida d'enginyeria.
Necessites enginyers que construeixin sistemes fiables, i no només funcionalitats? Parla amb un CTO — els nostres enginyers sènior de LATAM aporten la maduresa operativa que converteix la guàrdia d'obligació temuda en pràctica sostenible.
