Senior DevOps / SRE — Preguntas de entrevista DevOps

¿Cómo diseñas un rollback que realmente funcione?

Haciendo que cada deploy sea reversible de forma independiente, lo que mayormente restringe la base de datos: expandir antes de contraer, nunca eliminar en el mismo release que deja de escribir. El segundo requisito es que el rollback se ejercite — un camino usado una vez al trimestre en un incidente es un camino que no funciona. Los feature flags desacoplan el release del deploy y convierten la mayoría de los rollbacks en un cambio de config.

Un incidente está en curso y no sabes la causa. ¿Cómo lo corres?

Restaura el servicio primero y diagnostica después: mitigaciones como revertir, redirigir tráfico o escalar no requieren una causa raíz. Alguien es dueño de la coordinación y no está también debuggeando, y la línea de tiempo se escribe sobre la marcha, porque la memoria la reconstruye mal después. El postmortem pregunta qué hizo posible la falla y qué la hizo lenta de detectar, no quién tecleó el comando.

¿Cómo decides sobre qué alertar?

Sobre síntomas que el usuario siente — tasa de error, latencia, indisponibilidad — no sobre causas, porque las causas son numerosas y mayormente inofensivas. Cada alerta debe tener una acción; una que rutinariamente se reconoce y se ignora está entrenando a la gente a ignorar alertas. La medida de una buena configuración de alertas es cuántos pages fueron innecesarios, y ese número debería revisarse.

Un cluster cuesta tres veces lo que debería. ¿Dónde miras?

En los requests versus el uso real primero, porque los requests sobrecomprometidos reservan capacidad que nadie usa y son la mayor fuente de desperdicio. Luego en el sizing de nodos y el bin packing, luego en qué está corriendo que nadie posee — entornos viejos, load balancers olvidados, snapshots. El almacenamiento y el egress son las líneas que crecen calladamente y nunca están en la primera estimación.

¿Cómo introduces infrastructure as code en un estado construido a mano?

Importando en vez de recreando, un pedazo acotado a la vez, empezando con algo de bajo riesgo para que el flujo se ejercite antes de que importe. La parte difícil no es la herramienta sino la regla de que los cambios manuales se detienen, porque un codebase que se desvía de la realidad es peor que ningún codebase — se confía en él y está mal. La detección de drift tiene que correr en un horario.

¿Cómo mantienes sostenible el on-call?

Tratando el volumen de alertas como un conteo de defectos con un dueño, no como el clima. Una rotación que hace pages cada noche quema a la gente y la rotación de personal cuesta más que el tiempo de ingeniería para arreglar las causas. Las prácticas concretas son una tarea de seguimiento por cada page, un tope de cuánto toil es aceptable, y tiempo en el próximo sprint reservado para lo que surgió la última rotación.