Forem: Jorge

Aprobé ese ticket sin leerlo. Y tú también.

Jorge — Fri, 03 Apr 2026 18:00:00 +0000

"Las aprobaciones manuales existen para garantizar control. Pero cuando todos las aprueban por inercia, el control es una ilusión. Y en el fondo, todos lo saben."

Hay un momento que ocurre en casi todos los equipos técnicos y que nadie documenta en los postmortems.

Alguien abre una solicitud de aprobación. Lee el título. Mira brevemente la descripción. Y hace click en aprobar.

No porque haya revisado cada detalle. No porque tenga total certeza de que todo está correcto. Sino porque conoce al equipo, confía en que ya lo revisaron, tiene otras cinco cosas pendientes, y en el fondo sabe que si no aprueba, el proceso se detiene y alguien va a preguntar ¿por qué?.

Así que aprueba.

Y lo mismo hace la persona que aprueba después. Y la que aprueba después de esa.

El proceso tiene tres aprobaciones requeridas. Las tres ocurren en menos de cuatro minutos. Nadie leyó nada en serio.

Aquí no aplica "hay que desconfiar hasta de la sombra"

Por qué existen las aprobaciones manuales

Las aprobaciones manuales nacen de una intención legítima: poner un punto de control humano antes de que algo importante ocurra. Un deploy a producción, un cambio de configuración crítico, un acceso a un sistema sensible.

La lógica es razonable. Si alguien con criterio revisa antes de que el cambio llegue a producción, hay una oportunidad de detectar errores que el autor no vio, decisiones que no siguen las políticas del equipo, o impactos que no fueron contemplados.

En teoría, la aprobación es una red de seguridad.

En la práctica, con frecuencia es otra cosa.

Cómo la aprobación se convierte en teatro

El problema no es la aprobación en sí. Es lo que ocurre cuando el volumen de solicitudes supera la capacidad real de revisión del equipo.

Cuando hay dos o tres solicitudes de aprobación por semana, es razonable revisarlas con cuidado. Cuando hay veinte por día, y cada una requiere entender contexto, revisar código o configuración, y tomar una decisión informada — la matemática no da.

El equipo tiene dos opciones reales: convertirse en un cuello de botella bloqueando todo hasta poder revisar apropiadamente, o desarrollar un criterio implícito de cuándo revisar de verdad y cuándo simplemente aprobar.

Casi siempre eligen lo segundo. No por negligencia — sino porque el sistema los puso en una posición donde no hay otra salida sostenible.

Y así, gradualmente, la aprobación deja de ser una revisión y se convierte en un ritual. Un paso del proceso que todos saben que existe, que todos cumplen, y que nadie espera que realmente detenga algo.

El problema más profundo: la confianza que no se nombra

Detrás de cada aprobación por inercia hay algo que vale la pena nombrar: una confianza implícita que el proceso oficial no reconoce.

Cuando alguien aprueba sin leer, generalmente no lo hace porque sea irresponsable. Lo hace porque conoce a quien hizo la solicitud, porque sabe cómo trabaja ese equipo, porque ha visto su historial y sabe que raramente se equivocan en cosas graves.

Es confianza real. Pero es confianza que vive en las personas, no en el sistema.

El problema es que esa confianza es invisible, no transferible y frágil. Funciona mientras las personas que la sostienen estén en el equipo, conozcan el contexto, y tengan el criterio para distinguir cuándo algo merece revisión real. Cuando alguien nuevo llega al equipo y hereda la responsabilidad de aprobar, no hereda el contexto — hereda el proceso vacío.

Y entonces aprueba igual, pero sin ni siquiera la confianza implícita que tenía el anterior. Solo el hábito.

Lo que el sistema debería saber

Aquí está la pregunta que pocos equipos se hacen en voz alta:

Si el 90% de las aprobaciones se otorgan sin revisión real porque todos confían en que el equipo ya verificó — ¿por qué el sistema no puede verificar eso mismo?

Si una solicitud cumple con las convenciones de nombres definidas, si el recurso solicitado está dentro de los permitidos para ese equipo, si el ambiente es el correcto, si los tags requeridos están presentes, si la región es la autorizada — eso no requiere un criterio humano. Requiere una validación.

Y una validación puede vivir en código.

La aprobación humana tiene valor real cuando hay criterio genuino que aplicar: cuando el cambio tiene implicaciones de arquitectura que no están capturadas en ninguna política, cuando hay un contexto de negocio que el sistema no conoce, cuando la decisión requiere sopesar factores que no son codificables.

Para todo lo demás — para las verificaciones que hoy se hacen por inercia — el sistema puede hacerlo mejor, más rápido y sin despertar a nadie a las 3am para que haga click en un botón.

El costo de la fricción sin valor

Cada aprobación que no agrega valor real tiene un costo que rara vez se contabiliza.

El tiempo del aprobador que podría estar haciendo algo que requiera su criterio real. El tiempo del solicitante esperando un proceso que en el fondo sabe que es automático. La sensación acumulada de que los procesos existen para cumplirse, no para proteger algo. Y en el largo plazo, la erosión de la seriedad con que el equipo trata los controles que sí importan.

Cuando todo requiere aprobación, nada parece realmente importante. Cuando la aprobación es automática por defecto, la excepción — el cambio que sí necesita revisión humana — pierde el peso que debería tener.

El ruido mata la señal. En alertas, en documentación, y también en aprobaciones.

Qué cambiaría si el sistema validara en lugar de que las personas aprobaran

No estoy hablando de eliminar el control humano. Estoy hablando de moverlo al lugar donde agrega valor.

Si el sistema valida automáticamente que una solicitud cumple todas las políticas codificadas, el aprobador humano puede enfocarse en lo que el sistema no puede evaluar. El volumen de aprobaciones reales baja. La calidad de la revisión sube. El proceso deja de ser un ritual y vuelve a ser lo que siempre debió ser: un punto de control con criterio.

Y el equipo que hacía click en aprobar por inercia recupera tiempo para hacer el trabajo que justifica que estén ahí.

En el siguiente post: el ingeniero que se fue y se llevó el contexto — y por qué el bus factor es un riesgo operacional que casi nunca aparece en los planes de continuidad.

¿Cuántas aprobaciones procesas por semana que en el fondo sabes que son automáticas? Cuéntalo en los comentarios — sin nombres, sin empresas. Solo el número. "¡Cuéntanos el pecado, pero no el santo!"

El oncall que nadie quiere tener a las 3am

Jorge — Fri, 27 Mar 2026 01:17:49 +0000

No toda alerta merece despertar a una persona. Pero alguien sigue levantándose por ella. El problema real no es la alerta — es que se volvió paisaje.

Ya conoces esa sensación.

Son las 3am. El celular suena. Abres un ojo, lo agarras, y lees la alerta antes de estar completamente despierto. El ritmo cardíaco se dispara antes de que el cerebro haya procesado si esto es realmente serio.

Abres el laptop. Revisas el dashboard. Miras los logs.

Y entonces — treinta segundos después — cierras el laptop y vuelves a la cama. Porque no era nada. Un umbral configurado demasiado agresivo. Un pico transitorio que se resolvió solo. Una métrica que cruzó una línea que alguien dibujó hace años y que nadie ha revisado desde entonces.

No arreglaste nada. Solo confirmaste que no había nada que arreglar.

Y mañana en la noche, probablemente va a pasar de nuevo.

La alerta que nadie tiene asignada

Hay una pregunta que vale la pena hacer en la próxima retrospectiva del equipo:

De cada alerta que disparó el mes pasado — ¿Cuándo fue la última vez que alguien revisó deliberadamente si esa alerta debería seguir existiendo?

En la mayoría de los equipos, la respuesta honesta es: nadie. O alguien que ya no trabaja ahí.

Las alertas se acumulan. Se crean durante incidentes, se agregan como precaución después de un postmortem, se copian de plantillas sin pensar demasiado si aplican al contexto específico. Y luego se quedan. Porque eliminar una alerta se siente arriesgado — ¿y si algo realmente pasa y no lo detectamos? o como dice las abuelas "es mejor la seguridad que la policia" — mientras mantenerla se siente seguro, aunque signifique falsas alarmas ocasionales a las 3am.

El resultado es un sistema de alertas que crece en una sola dirección. Más alertas, más ruido, más interrupciones. Y un equipo que lentamente aprende a tratar las alertas como la mayoría de la gente trata las alarmas de los carros: como ruido de fondo que probablemente no significa nada.

Ese es un lugar peligroso. No porque el equipo sea descuidado — sino porque la desensibilización es una respuesta humana natural al ruido constante de bajo valor. Cuando todo es urgente, nada lo es.

El costo real no es el sueño perdido

El sueño importa. El sueño interrumpido tiene consecuencias reales en el rendimiento cognitivo, la calidad de las decisiones y la salud a largo plazo. Eso solo debería ser suficiente para tomarlo en serio.

Pero hay un costo que es más difícil de ver y más fácil de ignorar: la pérdida de confianza en el sistema de monitoreo y observabilidad.

Cada falsa alarma a las 3am es un retiro de una cuenta de confianza. El equipo empieza a tratar las alertas con escepticismo. Los tiempos de respuesta se alargan. El modelo mental cambia de "una alerta significa que algo está mal" a "una alerta significa que tengo que verificar si algo está mal". No son lo mismo, y la diferencia importa cuando ocurre un incidente real.

También está el costo del cambio de contexto. Una verificación de treinta segundos a las 3am tarda más de treinta segundos en recuperarse. Volver a dormir después de un pico de adrenalina no es inmediato. Retomar un pensamiento complejo a la mañana siguiente desde donde lo dejaste la noche anterior no es gratis.

Estos costos no aparecen en dashboards. Aparecen en la resignación silenciosa, en el ingeniero que deja de mencionar las interrupciones porque las aceptó como parte del trabajo, en el declive gradual del compromiso que antecede a una renuncia que nadie vio venir.

Cómo llegamos aquí

La cultura de oncall en Cloud Operations tiende a seguir un camino conocido.

Empieza razonable. Un equipo pequeño, un sistema crítico, alguien necesita estar disponible si algo se rompe. La rotación es liviana, las alertas son significativas, y las interrupciones son lo suficientemente infrecuentes como para sentirse aceptables.

Luego el sistema crece. Más servicios, más dependencias, más casos. Más alertas agregadas después de cada incidente — porque después de un incidente, el instinto siempre es agregar cobertura, nunca cuestionar si la cobertura existente sigue bien calibrada.

La rotación mantiene el mismo tamaño mientras la superficie de lo que necesita monitorearse se expande. La relación entre señal y ruido cambia. Y en algún punto — nadie puede precisar exactamente cuándo — el equipo cruza una línea de "estamos cubiertos" a "nos estamos ahogando en cobertura que no cubre las cosas correctas".

Nadie decidió que esto era aceptable. Simplemente se volvió la línea base.

Viví esto de primera mano con un desborde de base de datos que ningún índice podía contener. Una sola consulta mal optimizada derribaba el servicio — cinco minutos de aplicación caída, búsqueda desesperada de escalamiento vertical, y rezar para que la base secundaria tuviese toda la información replicada antes de subirla y restablecer. Lo hacíamos una y otra vez. Éramos expertos en el procedimiento de recuperación.

Lo que no nos preguntábamos era por qué teníamos que recuperar.

Un día alguien hizo el símil: éramos como el que toma una pastilla para el dolor de cabeza todos los días. La pastilla funciona, el dolor pasa, y mañana vuelve. Funciona tan bien que nunca vamos al médico. Hasta que un día decidimos ir — y en una hora de análisis encontramos que la consulta tenía un costo altísimo y los índices estaban completamente fragmentados. La solución real tardó una hora en identificarse. La automatización que generamos después desescalaba en las noches para reducir costos, la escalaba antes de iniciar la jornada, y desfragmentaba los índices día de por medio.

Meses de oncall nocturno, resueltos con una hora de análisis que nunca habíamos priorizado porque siempre había algo más urgente.

No toda alerta merece despertar a una persona

Esto es obvio una vez que se dice en voz alta, pero rara vez se dice explícitamente:

Una alerta que consistentemente no requiere acción no necesita despertar a una persona. Necesita ser arreglada, automatizada, o eliminada.

Las tres categorías que vale aplicar a cada alerta del sistema:

Arréglarla. Si una alerta dispara porque algo genuinamente está mal pero la solución siempre es la misma — reiniciar un servicio, limpiar una cola, ajustar un parámetro — eso no es una alerta. Es una automatización esperando ser escrita. La alerta debería disparar un script, no una llamada.

Automatizar la respuesta. Si la alerta requiere investigación pero la investigación casi siempre lleva a la misma conclusión, esa conclusión puede codificarse. No toda alerta necesita una decisión humana. Algunas necesitan una revisión humana de una decisión que el sistema ya tomó correctamente.

Eliminarla. Si una alerta dispara regularmente y regularmente no requiere acción, no es una alerta — es ruido. El miedo de eliminarla es real, pero el costo de mantenerla también es real, y ese costo lo paga la persona cuyo sueño interrumpe.

El objetivo no es cero alertas. El objetivo es que cada alerta que dispare tenga un dueño claro, una respuesta esperada clara, y una razón para creer que una persona necesita estar involucrada en esa respuesta.

La conversación que la mayoría de los equipos evita

Hay una razón por la que la higiene de alertas está perpetuamente en el backlog y perpetuamente sin priorizarse: requiere una conversación que se siente incómoda.

Requiere que alguien mire una alerta que fue creada después de un incidente real y diga "esta alerta disparó cuarenta veces en los últimos noventa días y tomamos acción dos veces — quizás no debería existir en su forma actual". Y eso se siente como decir que el incidente no importó, o que la persona que creó la alerta estaba equivocada.

También requiere admitir que el estado actual de la rotación de oncall no es sostenible, lo que significa admitir que algo que el equipo normalizó no debería haberse normalizado.

Estas conversaciones valen la pena. No en un postmortem, no cuando alguien está agotado después de una semana difícil de guardia, sino deliberadamente, cuando hay espacio para mirar el sistema con ojos frescos y preguntar: si estuviéramos diseñando este oncall desde cero hoy, ¿se vería así?

Casi siempre, la respuesta es no.

Cómo se ve cuando funciona bien

Un oncall bien calibrado no se mide por qué tan raramente suena el pager. Se mide por qué tan seguros está el equipo de que cuando suena, importa.

Esa confianza cambia todo. Cambia qué tan rápido responden las personas, qué tan en serio toman la investigación, cuánta energía cognitiva le dedican al problema. Cambia la relación entre el equipo y los sistemas que operan.

También cambia quién quiere estar en el equipo. Los ingenieros que están construyendo sus carreras no quieren pasar años despertándose por alertas que no los necesitan. Los mejores tienen opciones, y las ejercen.

Y hay algo que pocas veces se dice en voz alta: los ingenieros existimos para mejorar la calidad de vida de las personas. Es triste que en nuestra propia área seamos los descuidados — como dice el dicho: en casa de herrero, cuchillo de palo. Es preferible dejar de apagar incendios y empezar a preguntarnos: ¿por qué se está incendiando?

Una rotación de oncall sostenible es una estrategia de retención. Y también es simplemente lo correcto construir.

En el siguiente post: la aprobación en la que todos hacen click sin leer — y lo que dice sobre los procesos que construimos alrededor de una confianza que en realidad no tenemos.

¿Tu equipo ha hecho una auditoría de alertas recientemente? ¿Qué encontraron? Cuéntalo en los comentarios — lo gracioso es que estos patrones pasan en tu equipo, en tu país, y en equipos del resto del mundo. No somos los únicos a los que nos ha pasado esto.

¿Tu runbook refleja tu infraestructura actual?

Jorge — Fri, 13 Mar 2026 16:50:00 +0000

Hay una conversación que ocurre en casi todos los equipos de Cloud Operations, y casi nunca ocurre en una reunión formal.

Ocurre en el pasillo, en un mensaje directo, o en el hilo de Slack donde alguien pregunta algo y otra persona responde de memoria:

"Oye, ¿Cómo se llama la convención de nombres que usamos para los buckets en staging?"

"Creo que era ambiente-equipo-servicio… o era equipo-ambiente-servicio. Pregúntale a "Fulano" que él lo definió."

""Fulano" ya no está en el equipo."

"Ah. Entonces revisa el documento en la wiki."

"Lo revisé. Tiene dos versiones distintas y ninguna tiene fecha."

Bienvenido al problema que nadie agenda en el sprint pero todos viven en el día a día.

1. Las políticas nacen como documentos — y tiene todo el sentido

Cuando un equipo define cómo va a operar su infraestructura, lo natural es escribirlo. Una wiki, un repositorio de documentación, un PDF en una carpeta compartida. La herramienta no importa — el acto de escribirlo sí.

En ese momento, el documento es verdad. Refleja decisiones reales tomadas por personas que entendían el contexto. Es útil, es consultado, es mantenido.

El problema no es el documento. El problema es lo que pasa después.

2. La infra evoluciona. El repositorio también. El documento, no siempre.

La nube no es estática. Los proveedores deprecan servicios, cambian nombres de recursos, agregan opciones que antes no existían y eliminan otras que ya no tienen sentido. Lo que era la forma correcta de hacer algo hace dieciocho meses puede ser hoy la forma incorrecta, la forma cara, o simplemente la forma que ya no funciona.

El código de IaC lo siente primero. Un módulo de Terraform que funcionaba perfectamente empieza a lanzar warnings de deprecación. Un recurso que se creaba con un bloque específico ahora requiere una configuración diferente. El proveedor cambió su API y el provider de Terraform lo refleja en la siguiente versión.

El equipo actualiza el código. Abre un PR, lo revisa, lo mergea. La infra sigue funcionando.

Pero el documento que describía cómo funciona ese módulo — la wiki que explica la arquitectura, el runbook que detalla los pasos — ese no tiene un pipeline de CI/CD que lo valide. No tiene tests. No tiene nadie asignado como responsable de mantenerlo sincronizado con la realidad.

Y así, en silencio, sin que nadie lo decida explícitamente, el documento empieza a describir una infra que ya no existe.

3. El día a día no deja espacio para verificar

Aquí es donde hay que ser honestos.

Todos sabemos que deberíamos revisar periódicamente si la documentación sigue siendo válida. Todos sabemos que deberíamos tener una tarea recurrente en el backlog que diga "auditar documentación de infraestructura" o algo similar.

Pero también todos sabemos lo que pasa con esa tarea.

En el mejor caso, existe en algún tablero, tiene una etiqueta de "deuda técnica", y lleva meses sin que nadie la toque porque siempre hay algo más urgente. En el peor caso, nunca se creó porque en el momento en que alguien iba a crearla llegó una alerta, un cliente, un deploy urgente, o simplemente el fin del día.

El problema no es falta de disciplina. Es que verificar documentación no tiene una alerta asociada. Nadie recibe un PagerDuty a las 3am porque el runbook de recuperación de base de datos tiene pasos que ya no aplican. Ese problema solo aparece cuando alguien necesita ejecutar ese runbook en una situación de estrés alto — que es exactamente el peor momento para descubrir que está desactualizado.

El día a día en Cloud Operations es reactivo por naturaleza. Las tareas de mantenimiento preventivo de documentación compiten con incidentes reales, y los incidentes siempre ganan.

4. El chisme del pasillo se vuelve la palabra de Dios

Y entonces ocurre algo que todos hemos vivido pero pocos escriben: el conocimiento operacional migra de los documentos a las personas.

No como una decisión. Como una consecuencia natural de que preguntar es más rápido que leer, y leer es más rápido que verificar si lo que dice el documento sigue siendo verdad.

"¿Cuánto tiempo tarda en propagarse un cambio de DNS en este ambiente?"

La respuesta no está en ningún documento actualizado. Está en la cabeza de alguien que lo midió hace seis meses y lo recuerda con relativa precisión.

"¿Qué pasa si el job de backup falla silenciosamente?"

Hay un runbook. Pero la persona que lo escribió ya no está, y quien lo está ejecutando prefiere preguntarle al colega que "sabe de eso" antes que leer cuatro páginas que pueden o no reflejar la configuración actual.

El problema con esta dinámica no es que sea ineficiente — a veces es la forma más rápida de resolver algo. El problema es que el conocimiento que vive en personas se va con las personas. Y cuando la persona que "sabe de eso" cambia de proyecto, toma vacaciones, o simplemente no está disponible a las 2am de un domingo, el equipo opera sobre supuestos que nadie puede validar.

5. A veces la respuesta es parar y empezar de nuevo

Hay una conclusión que la industria tarda en aceptar porque suena a derrota, pero que los equipos con experiencia real reconocen como madurez:

A veces el documento no se puede actualizar. A veces hay que escribir uno nuevo.

No como admisión de fracaso. Como reconocimiento de que la realidad cambió tanto que el documento existente genera más confusión que claridad — y más cuando las lecciones aprendidas son de momento — porque mezcla lo que era verdad con lo que es verdad ahora, y ya no es fácil distinguir entre ambos.

Un punto y aparte. Una nueva documentación que parte de lo que realmente existe hoy, no de lo que existía cuando alguien tuvo tiempo de escribir por última vez.

Y más importante que eso: una conversación honesta sobre dónde debería vivir esa documentación para que no vuelva a quedar obsoleta sin que nadie lo note.

La respuesta que más me ha convencido después de años en Cloud Operations no es una wiki mejor, ni un proceso de revisión más estricto, ni más disciplina de equipo.

Es mover la gobernanza del documento al sistema.

Las políticas que viven en código — que se validan en cada deploy, que el mismo sistema que despliega infraestructura ejecuta antes de actuar — no pueden quedar desactualizadas en silencio. Si la política cambia, el código cambia. Si el código cambia, hay un PR, hay una revisión, hay un registro.

El runbook que nadie lee no falla silenciosamente. La política que vive en el pipeline falla ruidosamente, en el momento correcto, antes de que el daño ocurra.

Eso no resuelve todo. La documentación narrativa — el contexto, el razonamiento detrás de las decisiones, la historia de por qué las cosas son como son — sigue siendo necesaria y sigue siendo humana.

Pero las reglas operacionales, los guardrails, las convenciones que determinan qué está permitido y qué no: esas merecen vivir donde el sistema pueda ejecutarlas, no donde alguien tenga que recordar leerlas.

En el siguiente post voy a mostrar cómo se ve eso en la práctica — qué significa exactamente mover una política de un documento a un sistema, y qué cambia cuando lo haces.

Si esto resonó con algo que has vivido en tu equipo, cuéntalo en los comentarios. Estas anécdotas son más comunes de lo que aparecen en las conferencias.