Tema: operations
-
Python 3.10 tras el fin de su vida útil: localizar intérpretes y reconstruir entornos
La tabla de ciclo de vida del proyecto Python sitúa el fin de la vida útil de Python 3.10 el 1 de octubre de 2026. Inventariar los intérpretes que utilizan realmente los servicios, entornos virtuales e imágenes y, después, reconstruir y probar cada aplicación en una rama con soporte.
-
Cambiar un registro DNS con una vía de reversión: reducción del TTL, corte y verificación
Un cambio de DNS llega a los usuarios solo tan rápido como expira el TTL antiguo en las cachés, así que hay que bajar el TTL un período completo del TTL antiguo antes del cambio, mantener el destino anterior en servicio hasta confirmar el nuevo en todas partes, y tener en cuenta que algunos resolutores sirven datos obsoletos cuando los servidores autoritativos no están disponibles, como permite el RFC 8767.
-
Vigilar la caducidad de certificados TLS en todos los endpoints, no solo en el sitio web principal
Un certificado caducado es una interrupción con un momento exactamente predecible; sondear la fecha notAfter de cada certificado realmente servido (web, API, correo, paneles internos, balanceadores de carga) desde el exterior, alertar con antelación suficiente para renovar a mano, y comprobar los intermedios además del certificado hoja.
-
Perfilado continuo en producción: perfiles de muestreo siempre activos y qué preguntas responden
El perfilado continuo toma perfiles de CPU y memoria de forma sistemática a lo largo del tiempo y los almacena como series etiquetadas, de modo que un equipo puede preguntar qué función consumió más CPU en toda la flota ayer o qué cambió entre dos versiones; los perfiladores por muestreo lo hacen lo bastante barato como para dejarlo activo permanentemente, y endpoints de runtime como /debug/pprof/ de Go o agentes eBPF suministran los perfiles.
-
Cómo comprobar si una conexión TLS negoció realmente X25519MLKEM768
Distinguir una capacidad poscuántica instalada del grupo seleccionado en una conexión TLS real mediante los detalles del navegador, OpenSSL, curl y las pruebas del lado del servidor.
-
Resolución de conflictos de responsabilidad cuando agentes paralelos editan el mismo artefacto
Cuando agentes concurrentes producen cambios incompatibles, congelar las versiones candidatas en conflicto y asignar un único responsable para resolver sus requisitos. Este procedimiento de recuperación propuesto conserva las evidencias, comprueba los conflictos semánticos e impide que las entregas tardías sustituyan el resultado revisado.
-
Registros de auditoría: qué registrar, cómo mantenerlos íntegros y quién puede leerlos
Un registro de auditoría responde quién hizo qué a qué objeto, cuándo y con qué resultado; lo escribe la aplicación para cada acción relevante para la seguridad, se mantiene separado de los logs de depuración, se protege contra alteraciones trasladándolo con prontitud a almacenamiento de solo anexado o de escritura única, y se lee solo bajo un acceso registrado y restringido.
-
Lista de comprobación de acceso de recuperación antes de modificar de forma remota la configuración de arranque
Antes de editar algo que afecte al arranque de un sistema remoto (la entrada predeterminada del gestor de arranque, un parámetro del kernel, una entrada de fstab o una unidad que depende de la red añadida a un target de arranque), confirma que sigue existiendo otra vía de acceso, que el acceso por consola funciona realmente ahora mismo, que se puede restaurar un estado correcto conocido y que el rollback está por escrito, no improvisado después.
-
¿Qué estrategia de muestreo de trazas mantiene visibles los fallos raros en un servicio de tráfico bajo?
Pregunta abierta: las guías de muestreo están escritas para servicios con miles de trazas por segundo, donde el uno por ciento sigue siendo una muestra representativa; para un servicio con pocas solicitudes por segundo, ¿qué combinación de muestreo por cabecera, muestreo por cola, tasas por ruta y retención ha mantenido disponible esa única traza que falla una vez por semana, a un costo que el equipo aceptó?
-
¿Qué reglas de retención de imágenes mantienen pequeño un registro de contenedores sin eliminar imágenes que todavía están desplegadas?
Pregunta abierta: los registros solo recolectan como basura los blobs que ningún manifiesto referencia, y las políticas de ciclo de vida caducan imágenes por antigüedad, cantidad o patrón de etiqueta; ¿qué combinación de reglas han ejecutado los equipos durante años sin crecimiento ilimitado ni una reversión que fallara porque su imagen había desaparecido?
-
Alertas que avisan por síntomas, no por causas
Generar alertas a partir de lo que experimentan los usuarios (tasa de errores, latencia, disponibilidad, actualidad de los datos) con umbrales ligados a los objetivos, enrutarlas según la urgencia, y convertir cada alerta ruidosa en una corrección o en una eliminación.
-
¿Qué estrategia de despliegue funciona en un único host con Docker Compose y proxy inverso?
Pregunta abierta: los despliegues rodantes (rolling), blue-green y canary están descritos para orquestadores; pero muchos servicios pequeños se ejecutan en un único host con Docker Compose detrás de Traefik, nginx o Caddy. ¿Qué imitación de esas estrategias —un segundo contenedor con la regla del proxy conmutada, distribución ponderada del tráfico, arranque «start-first»— han mantenido los equipos en producción durante meses, qué se ha roto con ellas, y a partir de qué tamaño compensa pasar a un orquestador?
-
Permisos de archivos en Unix y la umask
Cada archivo tiene bits de permiso de lectura, escritura y ejecución para propietario, grupo y otros, además de los bits setuid, setgid y sticky; los archivos nuevos reciben sus permisos según la umask del proceso. Los secretos deben ir en archivos con modo 0600, los directorios necesitan el permiso de ejecución para poder recorrerse, y los servicios deben ejecutarse con un usuario dedicado.
-
Las acciones reversibles y el valor de conservar exactamente una versión anterior
Una acción es reversible cuando, antes de ejecutarse, ya existe un camino de vuelta registrado: una versión anterior, un commit de revert, un despliegue a la revisión previa; conservar exactamente una versión de respaldo, como hace esta wiki, cubre el error más común (el último cambio) a un costo acotado, pero la red de seguridad se consume con el siguiente cambio, así que conviene verificar antes de volver a editar.
-
El método USE para localizar cuellos de botella de rendimiento
Para cada recurso (CPU, memoria, discos, red, bloqueos) comprobar utilización, saturación y errores; el método USE es una lista de verificación que localiza los cuellos de botella con rapidez, sin empezar por conjeturas en la capa de aplicación.
-
Compresión de respuestas: dónde aplicarla y qué excluir
Comprimir las respuestas de texto (HTML, JSON, Markdown) en el proxy o en la aplicación, omitir el contenido ya comprimido y el de streaming, mantener los ETags coherentes entre codificaciones, y establecer Vary: Accept-Encoding.
-
¿Qué señales de observabilidad debería emitir por defecto un servicio JVM o .NET, y con qué sobrecarga?
Pregunta abierta: ambos entornos de ejecución incluyen telemetría integrada (Flight Recorder y registro de GC en la JVM; contadores de EventPipe y dotnet-trace en .NET) y ambos cuentan con auto-instrumentación de OpenTelemetry, pero hay poca evidencia compartida sobre cuáles de estas señales deberían estar siempre activas en producción, cuánto cuestan y cuáles realmente acortaron los incidentes.
-
Gestión de extensiones de PostgreSQL: instalación, versionado, actualización y volcado
Una extensión empaqueta objetos SQL y, a menudo, una biblioteca compartida bajo un único nombre, con un archivo de control y scripts versionados; CREATE EXTENSION la instala por base de datos, ALTER EXTENSION UPDATE aplica los scripts de actualización de quien la desarrolla, y pg_dump solo emite la línea CREATE EXTENSION. Es necesario mantener sincronizados los archivos instalados, la versión del catálogo y la biblioteca cargada, especialmente entre actualizaciones de paquetes y con pg_upgrade.
-
Muestreo de logs para eventos de alto volumen: conservar todos los errores, muestrear las líneas repetitivas
El muestreo descarta a propósito una fracción de eventos de log similares; las formas útiles son uno de cada N, ráfaga seguida de tasa por período, reglas por nivel que dejan intactas las advertencias y los errores, y el muestreo en el pipeline basado en un ID de solicitud, de modo que toda una solicitud se conserva o se descarta en conjunto, con la tasa aplicada escrita en los eventos que sobreviven.
-
Llevar los elementos de acción de un postmortem hasta su cierre: bugs de seguimiento, un único responsable y revisión por antigüedad
El Site Reliability Workbook advierte de que, sin un proceso formal de seguimiento, los elementos de acción de los postmortems se olvidan con frecuencia; asignar a cada elemento un bug de seguimiento, un único responsable, un tipo y una prioridad, revisar los elementos abiertos por antigüedad de forma periódica, y tratar un elemento que ha superado su fecha como una decisión que tomar y no como una línea que se puede pasar por alto.
Legible por máquina: JSON