036. Incidentes y Guardias (SEVs y Oncalls)
- 12:07
- Fri Dec 12 2025
- Temporada 1 • Ep. 30
El software se rompe todo el tiempo. Por eso se necesita gente que responda a problemas todo el tiempo. En el episodio de hoy hablamos de cómo se mantienen vivos los dragones de software 24/7, como funcionan en empresas con el proceso aceitado y se hace la transición de equipos chicos a equipos más grandes.
Una de las razones más comunes de renuncia y de baja moral en startups son guardias extendidas que afectan la salud mental y la vida personal de los trabajadores.
Acá es donde viene una de las mejores oportunidades para avanzar en tu carrera rápidamente.
Bienvenidos a Tecnología Informal, un espacio para hablar de carrera, de inversión, de producto, de cultura y de todo lo relacionado con startups. Yo soy Gabriel Benmergui y soy un programador con más de una década de experiencia viviendo y trabajando en California, Estados Unidos.
En la industria del software sabemos que todo está lleno de bugs. Con productos digitales que andan las 24 horas y se rompen en el mismo ciclo, es necesario tener un proceso para lidiar con los incidentes que afectan al negocio y a los usuarios.
En el episodio de hoy vamos a hablar de las guardias en tecnología, las on-call.
¿Qué es un incidente y cómo se manejan?
En la industria del software, cuando hay un problema en el servicio que causa interrupción en los usuarios o en el negocio, se le llama un incidente, o un SEV en la jerga de startups. Los SEV se categorizan por números y, mientras menor el número, es más serio.
El 2 de marzo de 2020, Robinhood se cayó. Millones de usuarios perdieron acceso a la aplicación y no podían acceder ni a su plata ni usar el producto, en un incidente que se hizo famoso en todo el mundo de startups. Robinhood categorizó al incidente como un SEV 0, un incidente que pone a toda la empresa en riesgo. Esto pasaría otra vez el 28 de enero de 2021 con la debacle de GameStop, donde los brokers estuvieron obligados a restringir la operatoria en el pico de una euforia especulativa.
En las empresas chicas, los incidentes se manejan de una manera casera. Generalmente los founders y los programadores más experimentados tienen la capacidad y la dedicación para resolverlos de primera mano. Pero a medida que la empresa crece, los incidentes son más frecuentes, más serios y más difíciles de resolver.
Si no se crea un proceso para mejorar la respuesta a incidentes, todos terminan siendo responsables en todo momento de responder a problemas, haciendo imposible desconectarse del trabajo y generando mucho estrés y expectativas que terminan quemando a los programadores.
Una de las razones más comunes de renuncia y de baja moral en startups son guardias extendidas que afectan la salud mental y la vida personal de los trabajadores.
Diseñando un proceso de on-call
Diseñar un proceso de on-call es bastante desafiante. Aunque hay buenas prácticas establecidas en la industria, cada organización es distinta y requiere un diseño particular para la empresa. Depende del organigrama, del producto y del tipo de problemas técnicos reales que enfrenta la empresa.
Lo primero que se hace es repartir la carga con rotaciones semanales, con una persona de guardia mientras el resto se puede desconectar. Cuando uno está en la rotación de on-call, tiene que poder responder un llamado en un determinado tiempo, pueden ser 15 o 30 minutos.
Hay productos como PagerDuty, OpsGenie o Rootly que facilitan la comunicación y la organización de los participantes. Manejan los calendarios, los teléfonos, las alertas y más.
Para reducir el estrés y tener cobertura de todo el producto, se ponen políticas de redundancia, más de un on-call por área de producto. Y políticas de escalar un incidente cuando no responden los on-call o no pueden resolver el problema, típicamente managers y luego directores o VPs (Vice Presidents).
Estar en on-call es una responsabilidad de todo el día y puede incluir monitorear servicios o manejar deployments, salidas a producción de código. La prioridad son las responsabilidades del on-call por arriba del trabajo diario. Estar en la rotación es, por definición, más trabajo y responsabilidad, por lo que la sensación general es negativa.
En Europa, estar de guardia es considerado trabajo para la ley laboral y por lo tanto tiene que estar remunerado en pago o contado como horario laboral. En empresas americanas prácticamente no existe pagarle extra a los programadores por on-call, con Google siendo una excepción.
Para mí, monetizar el on-call dándole plata a los que participan genera incentivos inciertos. Por un lado, los que quieren cobrar más hacen más on-call, que si se permite, genera incentivos inciertos. Por otro lado, el horario de guardia no se traduce en un salario de manera limpia y puede resultar insultante ponerle un precio que no se ajuste al esfuerzo percibido del programador.
Tecnología Informal es un podcast de Silver.dev.
Cobran dólares.
Silver.dev es una agencia de talento para programadores.
Andá a silver.dev y descubrí qué ofrece el mercado para vos.
El proceso de respuesta a incidentes
Lo central del proceso de las guardias es la respuesta a los incidentes, el SEV. Típicamente empieza con un reporte de usuario, de empleados o de sistemas de alertas y un desarrollador lo publica en un canal de Slack o comunicación interna de la empresa y hacen triaging.
Triaging es el proceso en el que se evalúa un incidente para entender su severidad, su impacto y su origen. Triaging lo puede hacer cualquier persona, aunque si requiere aplicar más criterios o buscar más información, se le pide al on-call que lo investigue.
Si el problema es suficientemente serio, se empieza un SEV, que crea automáticamente canales de Slack, notifica a los on-call relevantes y asigna un comandante.
Especialmente con los incidentes serios, hay un paralelismo con los accidentes de la vida real. La situación tiene mucha incertidumbre y mucho estrés, y en el que se acerca mucha gente, nadie sabe qué hacer. En un incidente suele verse el síntoma, pero puede ser muy difícil descifrar por qué está pasando. Mientras uno está tratando de entender, decenas de mensajes y comunicaciones internas y externas hacen muy difícil pensar con claridad y procesar la información.
La responsabilidad del comandante es poner orden en el caos. El comandante organiza la información y la resume brevemente para enfocar a los participantes. Hace reconocimiento y lectura de toda la información que van juntando los programadores para ir armando la historia de lo que está pasando desde un punto de vista global, y asigna responsabilidades concisas y claras con nombre y apellido para asegurarse que la gente no entre en parálisis de acción.
Es un auténtico rol de liderazgo y los buenos comandantes se reconocen inmediatamente. Mantienen la cabeza fría, procesan toda la información y toman decisiones con determinación y claridad.
Resolución de incidentes: mitigar, resolver y prevenir
La resolución de los SEVs tiene tres partes: mitigar, resolver y prevenir.
Lo más importante de todo es siempre el negocio. Todo lo que afecte al usuario o al servicio tiene que resolverse lo antes posible.
La mitigación es reducir el impacto o el costo del problema. Puede ser desactivar un feature que causa problemas, retrotraer una versión del producto o poner un parche que resuelva el problema temporalmente. La mitigación reduce la severidad del problema y le saca el filo a la situación. La velocidad de mitigación es una métrica importante para medir el Site Reliability, qué tan confiable es el servicio.
A veces la mitigación alcanza para resolver el SEV enteramente, pero si no, sigue a resolver el problema de fondo, el Root Cause. Entender el Root Cause es fundamental para poder prevenir el problema en el futuro. Mientras que durante un SEV un parche rápido puede ser aceptable para mitigar, hay que dedicarle tiempo a resolver problemas de manera correcta para tener mejores resultados de largo plazo.
La última es prevenir. Los incidentes siempre tienen que concluir con follow-up actions, qué es lo que hay que hacer para que no se repita ese mismo incidente o ese tipo de incidente.
Los problemas generalmente surgen por más de una razón. Si no es la confluencia de varios problemas combinados, generan problemas de orden mayor. El problema puede ser una práctica del código, un sistema que está mal implementado o un proceso en la organización que produce o esconde errores.
El proceso establecido en la industria es el Postmortem, un documento que explica detalles del incidente, el Root Cause, los follow-up actions y algunas preguntas sobre qué tan bien se manejó el SEV y qué tan bien se detectaron y diagnosticaron los problemas. Dependiendo de su severidad, puede ser presentado en reuniones periódicas con los managers de más alto nivel del área o empresa.
En el manejo y la evaluación de incidentes no se le echa la culpa a una persona, sino al sistema, con el principio llamado Blameless. Sí, una persona finalmente es atribuible a introducir un error, pero los errores son de todos y poner barreras para evitar que errores individuales afecten a todos es la clave de una organización saludable.
Aprendizaje y oportunidades en incidentes
Lo que siempre es difícil de resolver incidentes es que un sistema de ingeniería de software es más grande que la imaginación de cualquier individuo. Con cientos de partes moviéndose, con patrones de uso y tráfico distintos, con computadores que varían de capacidad, es un animal salvaje, impredecible y complejo. Y entender qué hace y cómo funciona es información específica de cada empresa.
Los skills fundamentales para lidiar con incidentes son el uso de herramientas de observabilidad, como ver información de la plataforma, navegar la arquitectura y poder diagnosticar y entender problemas.
Acá es donde viene una de las mejores oportunidades para avanzar en tu carrera rápidamente. Participar en la resolución de SEVs es la forma más intensa y rápida para entender el sistema a escala y entender los problemas que existen en el margen, los problemas que están en el borde de lo que el sistema puede hacer.
Los que pueden lidiar con los SEVs están en el centro de la innovación de la empresa y, con exposición repetida, se vuelven no solo expertos de sistemas, sino expertos en liderar la organización.
Cuando se rompe algo y sos el primero en entender el problema, resolverlo, escribir el postmortem y presentárselo a los líderes de la empresa, tu visibilidad y responsabilidad va a ser premiada en el muy corto plazo. Te generás una reputación en la empresa, clave para promociones y conseguir nuevas oportunidades.
Por esta razón, yo recomiendo a todos, inclusive a los juniors, participar de los procesos de SEVs de sus empresas y no tenerle miedo al on-call, sino aprovecharlo como una catapulta para su carrera.
El rol del SRE
Eventualmente, las empresas crecen hasta el punto de crear un equipo de SRE, Site Reliability Engineers. Este rol nace de Google, pero es estándar en la industria. El equipo de SRE participa de muchos SEVs como observadores y recopilan y procesan toda la información para crear herramientas, procesos y empujar equipos a hacer lo que tienen que hacer para mejorar las operaciones.
Sus métricas principales son los tiempos para detectar y corregir incidentes, y también la frecuencia y severidad con la que ocurren, especialmente a medida que el servicio escala con nuevos productos y usuarios.
Los SRE pueden ser auténticos comodines de distintas tecnologías, dependiendo del producto, pero tienden a enfocarse más en infraestructura, monitoreo y sistemas.
Conclusión
Los on-call son una responsabilidad tediosa de los programadores, pero también son oportunidades para destacarse. De lo más interesante que pasa en software es que se rompe en los márgenes. ¿Qué es lo que el sistema no sabe hacer bien y cómo corregirlo? Lidiar con SEVs es la forma más rápida de aprender liderazgo, responsabilidad y hacer una carrera meteórica en una startup.
Si les gustó el podcast de hoy, se vienen muchos más. Suscribite al podcast en Spotify o seguime en Twitter en @Conanbatt para estar al tanto de todo el contenido.
Silver.dev es mi agencia de talentos donde ayudo a programadores a conseguir trabajos de contratación directa para startups en Estados Unidos. Todos los puestos son en dólares y van desde 60 a 200 mil dólares anuales de salario.
Con Silver.dev hablás con un programador de carrera que te ayuda a prepararte para entrevistas técnicas, navegar el mercado y negociar tu salario. Para más información, podés visitar silver.dev y agendar una consulta.
SILVER.DEV