Consultoría DevOps e infraestructura

Hay equipos donde desplegar es un ritual: se hace los martes por la mañana, lo hace siempre la misma persona y nadie respira hasta que termina. Donde los secretos de producción viven en un Excel compartido. Donde los backups se hacen —pero nadie ha restaurado uno jamás—. Y donde la factura del cloud sube cada mes sin que nadie sepa explicar por qué.

Si alguna de estas te suena, el problema no es tu equipo: es que la infraestructura creció a parches y nadie la ha tratado como lo que es, parte del producto.

Mi criterio después de años montando esto: el DevOps bueno es el que no se nota. PRs que levantan su propio entorno, secretos que no viven en un Excel, backups probados restaurándolos. Eso es lo que ofrezco como consultoría, y lo que opero yo mismo a diario.

Qué significa que no se note

Se nota en lo que deja de pasar:

• Abres un pull request y aparece un entorno completo —con su base de datos, sus secretos y su dominio— sin que nadie toque nada. Revisar código deja de ser leer a ciegas.
• Un secreto rota sin reunión de emergencia: se cambia en un único sitio y llega solo a donde tiene que llegar.
• El día que algo se rompe, restaurar es seguir un runbook, no un salto al vacío.

Todo esto es ingeniería aburrida, hecha con mimo y mantenida en Git.

Lo que monto

• CI/CD que acelera de verdad. Pipelines que la gente no tiene miedo de tocar: tests en paralelo, caché bien puesta, validación estricta de manifiestos y escaneo de secretos. Un pipeline lento o frágil no es una molestia: es un impuesto sobre cada cambio.
• GitOps. Toda la infraestructura declarada en Git: push a main y está en producción, con ArgoCD vigilando que el clúster no se desvíe de lo declarado. Volver atrás es revertir un commit.
• Entornos de preview por PR. Cada pull request levanta su namespace, su base de datos y su dominio, y se borra solo al cerrarse. En Konect los previews arrancan con una copia de los datos reales, así que las migraciones se prueban contra el esquema de verdad.
• Gestión de secretos. Infisical como fuente y External Secrets para inyectarlos donde toca. Adiós al Excel: cada secreto tiene un lugar, un dueño y un historial.
• Backups que se restauran. Copia continua y retenciones escalonadas, sí, pero sobre todo restores probados y un runbook escrito. Un backup que nunca has restaurado es una esperanza, no un backup.
• Self-hosting con números. A veces compensa salirse del cloud y a veces no. Lo resuelvo con números, no con ideología: hierro, luz y horas frente a tu factura, y decides con datos.
• Runners propios de CI. Runners autoalojados que escalan de cero a varios según el trabajo, con imagen propia. Sin minutos facturados ni colas de espera.

Cómo trabajo

1. Auditoría. Mido lo que hay: cuánto tarda un deploy, quién puede hacerlo, dónde viven los secretos, cuándo se restauró el último backup. Sin datos no hay plan, hay opiniones.
2. Plan ordenado por riesgo. Primero lo que quema: casi siempre secretos y backups; después, el pipeline.
3. Montaje en Git. Todo queda declarado en vuestro repositorio, con sus runbooks. La infraestructura se la queda el equipo: no creo dependencias.
4. Traspaso. Formo a quien la va a operar y me quedo disponible, pero el objetivo es que no me necesitéis.

De dónde viene la experiencia

No vendo nada que no opere yo mismo. En Konect montamos la plataforma completa: Kubernetes con GitOps, registry Harbor propio, secretos en Infisical, devcontainers para todo el equipo y un entorno de preview por cada pull request que replica staging copiando sus datos.

En mi propia infraestructura —la que sirve esta web, con clientes encima— aplico lo mismo: ArgoCD en modo app-of-apps, ApplicationSets que generan entornos desde un fichero JSON y runners self-hosted que escalan a cero cuando no hay trabajo; hasta la imagen del runner se construye a sí misma. Lo cuento entero en el post de Kubernetes y GitOps del homelab.

Y el tema que más me preocupa cuando entro en un sitio nuevo: los backups. Todos los míos convergen en cervantes, el MinIO que corre en el TrueNAS llamado spinoza —restic y k8up guardan ahí las copias, al otro lado de la pasarela Tailscale que también lleva su nombre—. PostgreSQL tiene WAL continuo y copia diaria con recuperación a cualquier instante de los últimos 30 días, y los restores se prueban restaurando. Los detalles, incluida la deuda que aún queda, están en el post de backups y restauración.

Cuándo tiene sentido (y cuándo no)

Encaja si tienes un equipo de producto sin nadie de plataforma a tiempo completo, si desplegar da respeto, si nadie ha restaurado nunca un backup o si la factura del cloud crece sin explicación. También si quieres self-hostear pero te falta alguien que lo haya hecho antes en producción.

No encaja si tu deploy ya es aburrido y tus restores están probados —enhorabuena, no me necesitas—. Tampoco si buscas externalizar la operación para siempre: monto el sistema para que lo opere tu equipo, no para que dependas de mí.

Cuéntame cómo es un deploy en tu empresa y te digo qué atacaría primero. Reserva una toma de contacto y lo vemos.