Las entrevistas de DevOps y SRE tratan menos de nombrar herramientas y más de juicio bajo restricciones: qué revertir primero, sobre qué alertar, y qué dejar deliberadamente roto hasta la mañana. Aquí están las preguntas hechas más a menudo, cada una con una respuesta modelo. Middle: comprensión más profunda, optimización y situaciones reales de trabajo.
kubectl describe pod primero, porque la sección de eventos lleva fallos de pull de imagen, montajes fallidos, OOMKilled y fallos de probe — la mayor parte de la respuesta antes de haber leído una línea de log. Luego kubectl logs --previous, ya que el contenedor en ejecución puede tener segundos de vida y no haber logueado nada. Luego el código de salida, y si huele a OOM, el límite de memoria contra el uso real.
Mapea tu configuración a recursos reales así Terraform sabe qué posee. Es peligroso porque es autoritativo: piérdelo y Terraform ofrece reconstruir todo, ya que no sabe que esos recursos existen. También guarda secretos en texto plano, y dos applies a la vez sin locking lo corrompen — por eso los backends remotos con locking, encriptación y versionado no son opcionales.
Un SLI es lo que mides, un SLO es el objetivo sobre una ventana, y el error budget es la falta de confiabilidad que tienes permitido gastar. Su valor no es como métrica sino como herramienta de negociación: convierte "deberíamos frenar y arreglar confiabilidad" de una opinión, que pierde contra un roadmap, en aritmética que ambos lados acordaron de antemano.
Rolling necesita poca capacidad de sobra pero corre dos versiones a la vez, así que la migration debe ser retrocompatible te guste o no. Blue-green da rollback instantáneo y duplica la infraestructura, y hace la migration más difícil en vez de más fácil porque ambos entornos comparten una base de datos. Canary atrapa problemas reales pero solo si la observabilidad los nota dentro de la ventana del canary.
Un store externo — Vault, un gestor de secretos de cloud — con el workload autenticándose por identidad en vez de por otro secreto, que es la parte que lo hace más que mover el problema. La inyección en runtime le gana a hornearlo en la imagen, porque una imagen se copia y cachea en todos lados. La rotación es el requisito que la gente diseña afuera y luego no puede agregar después.
Una métrica es un número en el tiempo y responde si algo está mal. Un log es un evento con detalle y responde qué pasó. Un trace sigue un request a través de servicios y responde dónde se fue el tiempo. Los equipos usualmente sobreinvierten en logs, que son lo más caro de almacenar y lo menos útil para detectar un problema que no estabas buscando ya.
Suficiente para saber que la instancia puede servir, y nada más. Verificar una base de datos compartida significa que un problema de base de datos remueve cada instancia a la vez; no verificar nada más que el proceso significa que el tráfico sigue llegando a una instancia que no puede responder. La respuesta usual es un endpoint superficial que confirma que la app está arriba y sus propias dependencias son alcanzables, separado del readiness check profundo.
Dos causas usuales. O te quedaste sin inodes en vez de bytes — millones de archivos pequeños — que df -i muestra de inmediato. O un proceso todavía tiene abierto un archivo eliminado, así que los bloques no se liberan mientras df ya no cuenta el archivo; lsof +L1 lo encuentra y reiniciar quien lo tiene abierto libera el espacio. Una tercera posibilidad en filesystems ext es el 5% reservado para root, que un escritor no-root no puede tocar.
Solo llaves — PasswordAuthentication no — sin login root directo, un enfoque no estándar de quién puede loguearse vía AllowUsers o un grupo, y un bastion al frente en vez de exponer cada host. Llaves por persona, no una llave compartida, porque una llave compartida no se puede revocar para una persona que se va. Más allá de eso: evitar el agent forwarding a favor de ProxyJump, restricciones command= en llaves de automatización, y una autoridad certificadora una vez que la flota es lo bastante grande como para que la distribución de llaves sea su propio problema.
En una entrevista real hablas bajo presión. Cam hace estas mismas preguntas, evalúa cada respuesta y muestra exactamente qué mejorar.
Practicar entrevista de Middle DevOps / SRE →