Incidentes y Guardias (SEVs y Oncalls) - Tecnología Informal • Silver.dev

Una de las razones más comunes de renuncias 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 Ben Mergui, y soy un programador con más de una década de experiencia viviendo y trabajando en California, Estados Unidos. La industria del software sabemos que todo está lleno de bugs.

Con productos digitales que andan las veinticuatro horas, que se rompan 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 oncor. 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 CEV, en la jerga de startups. Los CEV se categorizan por números y mientras menor el número es más serio. El dos de marzo de veinte veinte, RomiHood 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. Robbie Hull categorizó al incidente como un ZEB cero, un incidente que pone a toda la empresa en riesgo. Esto pasaría otra vez el veintiocho de enero de veinte veintiuno 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 generar mucho estrés y expectativas que terminan quemando 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ñar un proceso de oncol 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, 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 quince o treinta minutos. Hay productos como Pager of Duty, Ups Genio o Rootly que facilitan la comunicación y la organización de los participantes.

Manejas 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 oncOL por área de producto, y políticas de escalar un incidente cuando no responden los oncol o no pueden resolver el problema, típicamente managers y luego directores o VPs, vicepresidentes. 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, Star de Guardia es considerado trabajo para la ley laboral y, por lo tanto, tienen que estar remuneradas en pago o contadas como horario laboral. En empresas americanas prácticamente no existe pagarle extra a los programadores por onkle, con Google siendo una excepción. Para mí, monetizar el onkle 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 concentración de responsabilidad, que es lo que se quiere evitar desde un principio. Por otro lado, el horario de guardia no se traduce a un salario de manera limpia y puede resultar insultante ponerle un precio que no se ajuste al esfuerzo percibido al programador.

Tecnología Informal es un podcast de Silver punto dev, cobra en dólares. Silver dev es una agencia de talento para programadores. Andá a Silver punto dev y descubrí qué ofrece el mercado para vos. Lo central del proceso de las guardias es la respuesta a los incidentes, el CEF. Típicamente empieza con un reporte de usuario, de empleados o de sistemas de alertas, y un desarrollador lo publicita 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 seguridad, su impacto y su origen. Trieshing lo puede hacer cualquier persona, aunque si requiere aplicar más criterios o buscar más información, se le pide al oncle que lo investigue. Si el problema es suficientemente serio, se empieza un SEV, que crea automáticamente canales de Slack, notifica a los onkle 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, al 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. Mantiene la cabeza fría, procesan toda la información y toman decisiones con determinación y claridad. La resolución de los SEPS 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 relability, qué tan confiable es el servicio. A veces, la mitigación alcanza para resolver el CEVE enteramente, pero si no, sigue resolver el problema de fondo, el root cost.

Entender el root cost es fundamental para poder prevenir el problema en el futuro. Mientras que durante un CEB 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, sino es la confluencia de varios problemas que combinados generan problemas de orden mayor.

El problema puede ser una práctica de 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 post mortem, un documento que explica detalles del incidente, el root cost, la follow up actions y algunas preguntas sobre qué tan bien se manejó el CEB, y qué tan bien se detectaron y diagnosticaron los problemas. Dependiendo de su seguridad, puede ser presentado en reuniones periódicas frente a 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 de introducir un error, pero los errores son de todos.

Poner barreras para evitar que errores individuales afecten a todos es la clave de una organización saludable. Lo que siempre hace difícil resolver incidentes es que un sistema de ingeniería de software es más grande que la imaginación de cualquier individuo. Tiene cientos de partes moviéndose, con patrones de uso y tráfico distintos, con computadoras que varían de capacidad. Es un animal salvaje, impredecible y complejo, Entender qué hace, 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 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 CEPs 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 post mortem y presentárselo a los líderes de la empresa, tu visibilidad y responsabilidad va a ser premiada en el muy corto plazo. Te generas una reputación en la empresa clave para promociones y conseguir nuevas oportunidades. Por esta razón, yo recomiendo a todos, inclusive los juniors, participar de los procesos de CEF de sus empresas y no tenerle miedo al on call, sino aprovecharlo como una catapulta para su carrera.

Eventualmente, las empresas crecen hasta el punto de crear un equipo de SRE, site relability engineers. Este rol nace de Google, pero es estándar en la industria. El equipo de SRE participa de muchos SEPS 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. Son 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 SRB pueden ser auténticos comodines de distintas tecnologías dependiendo del producto, pero tienden a enfocarse más en infraestructura, monitoreo y sistemas.

Los oncolls 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, que es lo que el sistema no sabe hacer bien y cómo corregirlo. Lidiar con Zerbs es la forma más rápida de aprender liderazgo, responsabilidad y hacer una carrera meteórica en una estafa. Si les gustó el podcast de hoy, se vienen muchos más. Suscribite al podcast en Spotify o seguime en Twitter, en Conan Bat, con doble t, para estar al tanto de todo el contenido.

Silver punto dev es mi agencia de talento 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 sesenta o doscientos mil dólares anuales de salario. Con silver punto dev hablás con un programador de carrera que te ayuda a prepararte para entrevistas técnicas, navegar al mercado y negociar tu salario. Para más información, podés visitar silver punto dev y agendar una consulta.

36. Incidentes y Guardias (SEVs y Oncalls)