Oportunidades remotas / Equipos internacionales
Vitor Schiavo
Senior Platform y Site Reliability Engineer
Sistemas confiables.
Equipos más fuertes.
Plataformas en la nube confiables e inferencia de IA, con mejoras medidas en entrega, resiliencia y costo.
Abierto a oportunidades Senior y Staff en Platform Engineering y SRE.
Compila una vez. Promueve con confianza.
Una vista previa aislada, la misma imagen probada y una ruta de limpieza explícita.
Piloto en dos repositorios · 34 verificaciones automatizadas
Explora este casoTrabajos seleccionados
Infraestructura de IA y serving de LLM
Operar LLMs multimodales entre motores y nubes
Construí flujos de serving con vLLM y llama.cpp, aislé runtimes de modelos incompatibles y validé un fallback autenticado en todos los entornos. El trabajo abarca un POC de router y una posterior integración en producción.
Lee las decisiones y los resultados ↗Dos motores de serving. Despliegue en producción validado por separado del POC de router.
FinOps e ingeniería de costos
Menos desperdicio en la nube. Más valor de ingeniería.
Reduje el gasto de infraestructura mediante el rightsizing de Kubernetes, una migración de monitoreo y el retiro seguro de servicios heredados. Cada resultado está vinculado a su propia línea base y moneda.
Explora los ahorros y las decisiones ↗Iniciativas separadas de 2025–2026. Reducciones mensuales × 12.
Observabilidad y migración
Encontrar la falla detrás de un dashboard en verde
Una migración de runtime dejó los filtros de alerta coincidiendo en silencio con nada. Rastreé los cambios de logging y verifiqué cada corrección contra mensajes que se sabe que existen.
Lee las decisiones y los resultados ↗Valida contra un mensaje que se sabe que existe.
Profundidad en toda la plataforma.
Las disciplinas detrás del trabajo. Explora los proyectos que las ponen en práctica.
Platform y entrega
Flujos de trabajo reutilizables que conectan el código con producción.
Kubernetes · Terraform · ArgoCDExplorar trabajosConfiabilidad y observabilidad
Señales que los ingenieros pueden usar para diagnosticar y actuar.
Prometheus · Grafana · JenkinsExplorar trabajosIngeniería de costos
Entiende la factura. Cambia la arquitectura.
Facturación en la nube · Rightsizing · AlmacenamientoExplorar trabajosSeguridad y confianza
Controles prácticos integrados en la plataforma.
mTLS · IAM · Redes privadasExplorar trabajosInfraestructura de IA
Serving, arranque y rutas de falla bajo escrutinio.
vLLM · GPU serving · POC de fallbackExplorar trabajosArquitectura en la nube
Entornos conectados con límites claros.
GCP · AWS · AzureExplorar trabajosExperiencia construida en entornos exigentes
Facilita el trabajo del próximo ingeniero.
Mi experiencia en desarrollo de software moldea mi forma de trabajar en infraestructura. Busco causas comunes, construyo capacidades reutilizables y documento decisiones para que los equipos puedan operar de forma independiente.
Cómo trabajo ↗Trabajo de ingeniería
Explora resultados, arquitectura y lecciones de operación. El trabajo profesional y los proyectos personales se etiquetan por separado.
Restaurar la confianza en el pipeline de QA
40 fallas de plataforma a cero
El defecto del reporte compartido fue reparado; las fallas de la aplicación quedaron como una investigación aparte.
Qué cambió
Un defecto en el reporte compartido hacía que pruebas que pasaban parecieran fallidas. Rastreé la falla común, reparé la plataforma de agentes y separé las fallas reales de pruebas del ruido de infraestructura. Ejecución de validación con 65 jobs; las fallas restantes de pruebas de la aplicación se identificaron por separado.
Un lugar seguro para probar cada funcionalidad
Entornos de vista previa con un ciclo de vida completo
Piloto en dos repositorios: promover la imagen probada y luego eliminar los recursos de vista previa cuando se cierra el PR.
Qué cambió
Construí un piloto en dos repositorios que crea entornos aislados a partir de pull requests, promueve la misma imagen probada y elimina los recursos de vista previa cuando se cierra el PR. 16 verificaciones de Go y 18 de Node antes de las compilaciones; digest de imagen verificado durante la promoción.
Encontrar la falla detrás de un dashboard en verde
22 políticas de alerta y 2 métricas reparadas
Cambiar solo el tipo de recurso fue insuficiente; los filtros también debían coincidir con formatos de log específicos del runtime.
Qué cambió
Una migración de runtime dejó los filtros de alerta coincidiendo en silencio con nada. Rastreé los cambios de logging y verifiqué cada corrección contra mensajes que se sabe que existen. Los controles positivos demostraron que reemplazar solo el tipo de recurso seguiría omitiendo los logs estructurados de Go.
Cloud Functions: migración por etapas a Gen2
Modernización de runtimes y pipelines de despliegue; el seguimiento en producción expuso y corrigió un cambio implícito de identidad del runtime.
Una migración por etapas; el seguimiento en producción también verificó la cuenta de servicio del runtime.
Qué cambió
Modernización de runtimes y pipelines de despliegue; el seguimiento en producción expuso y corrigió un cambio implícito de identidad del runtime.
Modernizar Grafana y Prometheus
Actualizaciones de versión mayor, recording rules y un stack de monitoreo más mantenible.
El trabajo combinó actualizaciones de versión, recording rules y validación operativa.
Qué cambió
Actualizaciones de versión mayor, recording rules y un stack de monitoreo más mantenible.
Redes en GKE: Dataplane V2 y un bootstrap repetible
Una migración escalonada fuera de producción con rollback y validación explícitos; la producción quedó excluida de esa entrega.
Entrega fuera de producción con verificaciones y rollback explícitos; la producción estuvo fuera de este alcance.
Qué cambió
Una migración escalonada fuera de producción con rollback y validación explícitos; la producción quedó excluida de esa entrega.
Reconstruir GKE sin reemitir certificados
Septiembre de 2026 · Un ensayo real de reconstrucción expuso fallas que la revisión de código pasó por alto y luego permitió reconstruir tres clústeres sin consumir la cuota de emisión de certificados.
El ensayo adoptó 49 de 49 certificados sin reemitirlos. Es una prueba de recuperación, no un SLA de tiempo de recuperación en producción.
Mi aporte y el resultado
Ensayé una reconstrucción completa del clúster, reparé defectos de orden de restauración y de ciclo de vida del controlador, y luego reutilicé el proceso al renumerar tres entornos.
Encontrar la latencia oculta en el DNS de Kubernetes
Julio de 2026 · Separar el tiempo de resolución de DNS del tiempo de conexión TCP reveló por qué una API saludable seguía activando alertas de latencia.
La mejora de aproximadamente 9× describe la resolución de DNS medida, no cada solicitud a la API ni una garantía sostenida de nivel de servicio.
Mi aporte y el resultado
Aislé la sobrecarga de DNS de la latencia de red de la base de datos, cambié la configuración de DNS del Helm compartido y verifiqué el despliegue en producción contra la medición original.
Observar una flota efímera de inferencia de IA
Abril de 2026 · El descubrimiento dinámico de Prometheus mantuvo visibles a los workers de GPU y los pods de inferencia a medida que cambiaban sus direcciones del proveedor.
Cinco targets estaban UP en la captura del despliegue. Esta entrega agregó visibilidad; las reglas de paging fueron un seguimiento aparte.
Mi aporte y el resultado
Conecté el inventario del router con el service discovery HTTP de Prometheus y un dashboard de la flota, eliminando la necesidad de mantener una lista estática de targets después de cada despliegue de GPU.
Hacer observables los jobs programados
Agosto de 2026 · Un wrapper de ejecución reutilizable hizo visibles los jobs de corta duración sin cambiar su lógica de negocio ni permitir que las fallas de telemetría los rompieran.
24 de 26 entradas activas fueron instrumentadas. Los umbrales de frescura reflejan cada programación; las fallas de telemetría no reemplazan el resultado del job.
Mi aporte y el resultado
Instrumenté 24 de 26 entradas de cron activas, agregué reglas de frescura conscientes de la programación y verifiqué que el monitoreo preservara el resultado real de cada job.
Arregla el worker antes de escalar la flota
Septiembre de 2026 · Un despliegue de autoescalado basado en colas expuso workers de navegador atascados; el escalado solo resultó útil después de contener la fuga de recursos.
KEDA estuvo activo en cuatro entornos. El tope de 50 réplicas en producción es configuración, no capacidad de rendimiento demostrada.
Mi aporte y el resultado
Rastreé el backlog y los OOMs hasta procesos hijos atascados, corregí su ciclo de vida y reemplacé el escalado por CPU/memoria con un disparador de backlog de Pub/Sub en cuatro entornos.
Ingeniería de costos en la nube en todo el stack
Kubernetes, observabilidad y retiro de sistemas heredados · 2025–2026
Preservar los datos requeridos y el comportamiento del servicio; medir cada iniciativa contra su propia línea base de facturación.
Reducción de costos como disciplina de ingeniería
Equivalentes anualizados documentados: aproximadamente US$30.1K por un retiro de sistema heredado, £26.5K por una instantánea de rightsizing de Kubernetes y £14K por una línea de ingesta de monitoreo. Las distintas monedas y líneas base se mantienen separadas.
Hacer visible el costo de Kubernetes
Asignación de costos a nivel de namespace, resource requests y consolidación de nodos.
La asignación de costos informa los resource requests y la consolidación; los ahorros requieren una línea base de facturación.
Qué cambió
Asignación de costos a nivel de namespace, resource requests y consolidación de nodos.
Mover cargas de trabajo entre clústeres de Kubernetes
Migración por fases de aplicación y datos, cutover de DNS, validación y rollback.
Preparar la migración de aplicación y datos antes del cutover de DNS, luego validar el destino.
Qué cambió
Migración por fases de aplicación y datos, cutover de DNS, validación y rollback.
Una actualización por fases de Strapi a una versión mayor
Adaptar los lifecycle hooks y validar la compatibilidad antes del cutover a producción.
Los cambios de versión mayor incluyeron lifecycle hooks y verificaciones de comportamiento antes del cutover a producción.
Qué cambió
Adaptar los lifecycle hooks y validar la compatibilidad antes del cutover a producción.
Mantener Metabase útil en producción
Carga controlada del dashboard: ~49.7 s → ~3.1 s; actualizaciones, acceso de solo lectura y aislamiento de consultas.
Una carga controlada en producción mejoró de ~49.7 s a ~3.1 s; quedó un cuello de botella aparte en un filtro de MongoDB.
Qué cambió
Carga controlada del dashboard: ~49.7 s → ~3.1 s; actualizaciones, acceso de solo lectura y aislamiento de consultas.
La postura de seguridad como un sistema observable
Escaneos de seguridad, alcanzabilidad de sondas verificada y controles reversibles de secretos, con alcances de despliegue documentados.
La visibilidad por lotes incluye dimensiones de riesgo y frescura de los escaneos; no es detección de amenazas en tiempo real.
Qué cambió
Conecté los escaneos de seguridad con Prometheus y Grafana, mejoré la confiabilidad del escáner y verifiqué sondas de exposición de configuración. Un trabajo relacionado agregó entrega acotada de secretos y controles de versión reversibles.
Reducir el gasto de ingesta de monitoreo
£1,165.80/month eliminados de una línea de facturación de ingesta de Prometheus.
La línea de ingesta gestionada fue eliminada; el cómputo autogestionado, el almacenamiento y el mantenimiento aún tienen costos.
Qué cambió
Reemplacé la ruta de ingesta gestionada preservando los targets de monitoreo y los dashboards. El equivalente anualizado es £13,989.60; los costos de hosting y mantenimiento quedan fuera de esa línea de facturación.
Ciclo de vida y retención de almacenamiento en GCP
Escalonamiento de almacenamiento según el acceso y revisión de retención.
Un ciclo de vida simplificado: deben validarse la versión de política vigente y los requisitos de eliminación.
Alcance y resultado
El portafolio histórico reportó una reducción del 95.9%. Los ahorros absolutos se omiten hasta conciliar la moneda, la línea base de facturación y la versión de política.
Consolidación de Airflow — 86% menos recursos asignados
Consolidar un despliegue sobreaprovisionado.
La asignación de recursos registrada bajó; esto no significa que la plataforma tenga costo operativo cero.
Alcance y resultado
La asignación registrada cambió de 100 a 14 pods, de 20 a 2.8 vCPUs y de 200 a 28 GB de memoria. Son reducciones de asignación, no una afirmación de costo operativo cero.
mTLS con Cloudflare — Arquitectura Zero-Trust
2024–2025 · Seguridad avanzada · Arquitectura de red
Los certificados, la rotación y la revocación complementan los controles de red.
Problema
El TLS estándar solo autentica el servidor ante el cliente. Se requería autenticación mutua, donde tanto el cliente como el servidor verifican su identidad mediante certificados, algo crítico para la seguridad de las API y el cumplimiento de ISO 27001.
Solución
- Configuré Cloudflare para TLS mutuo; ahora ambos lados presentan certificados, no solo el servidor
- Generé y distribuí certificados de cliente a cada servicio autorizado
- Agregué revocación y rotación de certificados para poder anular de inmediato los certificados comprometidos
- La validación de certificados agrega un control de identidad junto a las restricciones de red
- Automaticé el ciclo de vida de los certificados para que la rotación no requiera pasos manuales
Flujo mTLS
Cliente (con certificado) → Cloudflare (valida el certificado del cliente) → Servidor de origen (valida el certificado de CF)
Verificación mutua en cada capa · Cifrado y autenticado de extremo a extremo
Impacto en el negocio
- Cada solicitud autenticada por certificado; nada pasa solo por su posición en la red
- Cumplimiento de ISO 27001 satisfecho
- Protección contra ataques MITM y abuso de API
- Revocación instantánea si un certificado se ve comprometido
HA VPN AWS-GCP — Conectividad Multi-Cloud
2024 · Redes Multi-Cloud · Alta disponibilidad
BGP provee enrutamiento y failover; IPSec cifra el tráfico transportado por la VPN.
Problema
Se necesitaba comunicación segura y confiable entre AWS y GCP para cargas de trabajo híbridas. El enrutamiento por internet público era inaceptable para datos sensibles. Se requería redundancia para alta disponibilidad.
Solución
- Construí una HA VPN entre AWS y GCP con túneles redundantes en ambos lados
- Configuré BGP para que el failover sea automático, sin intervención manual cuando cae un túnel
- Asigné IPs privadas y configuré tablas de enrutamiento internas para que el tráfico use direccionamiento privado sobre túneles VPN cifrados
- El tráfico dentro de los túneles VPN se cifra con IPSec
- Agregué monitoreo y alertas para la salud de los túneles, de modo que los problemas se detecten antes de afectar las cargas de trabajo
Impacto en el negocio
- Conectividad redundante a través de múltiples túneles VPN
- Failover automático vía BGP (<30 segundos)
- Direccionamiento privado de servicios sobre túneles VPN cifrados
- Conectividad entre nubes con endpoints privados y túneles monitoreados
Sistema de despliegue canary personalizado
2024–2025 · Entrega progresiva · Automatización
Cada compuerta de release puede detener el avance y devolver el tráfico a la versión estable.
Problema
Los despliegues blue-green tradicionales requieren un cambio del 100% del tráfico, lo cual es riesgoso. Las herramientas listas para usar no encajaban con nuestra configuración de Kubernetes multientorno. Se necesitaba un rollout gradual con rollback automático basado en métricas.
Solución
- Escribí desde cero una automatización de despliegue canary personalizada; las herramientas listas para usar no encajaban con la configuración multientorno
- Reparto progresivo del tráfico: 10% → 25% → 50% → 100%, con una compuerta en cada etapa
- Las verificaciones de salud se ejecutan en cada etapa antes de que avance el tráfico
- El rollback automático se activa cuando la tasa de errores o la latencia cruzan umbrales definidos
- Integrado en los pipelines de Jenkins, funciona igual para cada equipo
Impacto en el negocio
- Contención de fallas: las compuertas de salud y el rollback automatizado limitan la exposición durante la entrega progresiva
- Mayor frecuencia de despliegue: los equipos publican con más frecuencia porque el costo de un mal release bajó drásticamente
- Integración con el pipeline: la automatización personalizada encaja en el flujo de entrega existente
Fortalecimiento de seguridad de bases de datos — 60+ bases de datos
2023–2025 · Arquitectura de seguridad · Cumplimiento
Las redes privadas, el transporte cifrado y los controles de acceso forman capas de defensa separadas.
Problema
Bases de datos expuestas con IPs públicas, conexiones sin cifrar y autenticación solo por contraseña. Sin cumplir con ISO 27001. Vulnerables a sniffing de red y acceso no autorizado.
Impacto en el negocio
- 60+ bases de datos aseguradas (MongoDB Atlas + PostgreSQL)
- Controles de plataforma posteriores: piloté External Secrets en tres repositorios; hice que las actualizaciones de secretos preservaran los campos existentes; deshabilité de forma reversible 133 versiones antiguas en 97 secretos de cuatro proyectos. Las excepciones de identidad en producción quedaron documentadas.
- Cero incidentes de seguridad tras la implementación
- Certificación ISO 27001 lograda
Kong Gateway — Gestión de API a escala
2023–2024 · Gestión de API · Arquitectura
El gateway centraliza la autenticación, los límites de tasa y el enrutamiento del tráfico de la aplicación.
Problema
160+ aplicaciones con ingress directo de nginx y sin gestión de API, limitación de tasa ni capa de autenticación centralizadas. Difícil aplicar políticas o monitorear el uso de las API de forma consistente.
Impacto en el negocio
- 160+ aplicaciones ahora pasan por un único gateway, ofreciendo un solo lugar para aplicar políticas
- Limitación de tasa configurada de forma centralizada; sin necesidad de implementarla por servicio
- Autenticación, CORS y headers aplicados de forma global; los desarrolladores no lo manejan por app
- Logging y tracing centralizados reducen significativamente el tiempo de diagnóstico
ArgoCD GitOps — Entrega continua multiclúster
Marzo de 2026 · GitOps · Kubernetes multiclúster
GitOps separa el estado deseado en Git de su aplicación controlada a los clústeres.
Problema
Los despliegues en cuatro clústeres de GKE (dev · stg · prd · sandbox) eran manuales, inconsistentes y propensos a errores. Sin una única fuente de verdad para el estado de los clústeres, sin registro de auditoría y con alto riesgo de drift de configuración entre entornos. Los equipos necesitaban acceso con kubectl para desplegar, sin un modelo de autoservicio.
Solución — Implementación en 9 fases
- Fase 0: Instalé ArgoCD en el clúster GKE PRD mediante Helm con valores de nivel producción
- Fase 1: Definí la estructura del repositorio GitOps: jerarquía apps/environments/charts con plantillas de Helm charts y overrides de valores por entorno
- Fase 2: Configuré Applications y AppProjects de ArgoCD con límites de RBAC por equipo y namespace
- Fase 3: Registro multiclúster; los cuatro clústeres de GKE (dev · stg · prd · sandbox) como targets de ArgoCD con credenciales de clúster almacenadas en Secrets
- Fase 4: Integración del pipeline de CI/CD mediante el image updater de GitHub Actions para la propagación automática de tags de imagen, promoción de ramas dev → stg → prd
- Fase 5: SSO/OIDC con Google Workspace + políticas de RBAC por equipo
- Fase 6: Métricas de Prometheus + dashboards de Grafana para la observabilidad de GitOps
- Fase 7: Migración incremental de las cargas existentes; audité todos los namespaces, los convertí a Helm charts, y habilité self-heal y prune en no producción
- Fase 8: Entrega progresiva con Argo Rollouts, despliegues canary con reparto de tráfico y rollback automatizado
Impacto en el negocio
- 4 clústeres de GKE gestionados como una sola flota GitOps (dev · stg · prd · sandbox)
- Gestión del drift: Git provee el estado deseado, con reconciliación y self-healing donde está habilitado
- Registro de auditoría completo: cada cambio de despliegue queda registrado como un commit de Git firmado
- Rollback instantáneo: revierte un commit de Git y el clúster se reconcilia en segundos
- Autoservicio para desarrolladores: los ingenieros despliegan vía PR, sin necesidad de acceso con kubectl
- Promoción automatizada: el image updater de GitHub Actions publica nuevos tags en todos los entornos sin ediciones manuales de YAML
Infraestructura GKE — Terraform de nivel producción + Shared VPC
Febrero de 2026 · Infraestructura como código · GKE · Terraform
Módulos reutilizables de Terraform aprovisionan los límites de red y los recursos de GKE de forma consistente.
Problema
Los clústeres de GKE y la infraestructura de red subyacente se aprovisionaban manualmente, sin IaC. Sin una estrategia multientorno consistente, sin protección prevent-destroy en los recursos de red críticos, y con una configuración de Terraform monolítica e imposible de reutilizar entre entornos.
Solución — Entrega en 8 fases
- Fase 1 — Diseño de arquitectura: Definí la topología de Shared VPC, la estrategia de subredes y los requisitos de los clústeres de GKE para 4 entornos
- Fase 2 — Configuración de proyectos GCP: Creé proyectos, habilité APIs y configuré cuentas de servicio de IAM con bindings de privilegio mínimo
- Fase 3 — Infraestructura de red: Desplegué el proyecto host de Shared VPC, subredes, Cloud NAT y reglas de firewall mediante Terraform
- Fase 4 — Terraform modular: Refactoricé de recursos inline monolíticos a módulos reutilizables; convertí la configuración raíz en llamadas a módulos con archivos de variables específicos por entorno
- Fase 5 — Automatización de CI/CD: Workflows de GitHub Actions para terraform plan en los PR y terraform apply al hacer merge; workflows separados por entorno
- Fase 6 — Despliegue de clústeres GKE: Desplegué los cuatro clústeres de GKE (dev · stg · prd · sandbox) usando los pipelines automatizados
-
Fase 7 — Barreras de seguridad: Agregué bloques de ciclo de vida
prevent_destroy = trueen la VPC, las subredes y Cloud NAT para proteger contra un terraform destroy accidental - Fase 8 — Documentación: Diagramas de arquitectura, runbooks operativos y documentación de módulos para la transferencia de conocimiento
Impacto en el negocio
- 100% de infraestructura como código: cada recurso de red y de clúster gestionado mediante Terraform
- 4 clústeres de GKE desplegados en una sola ejecución del pipeline automatizado
- Cero aprovisionamiento manual: los nuevos entornos se crean solo a partir de archivos de variables
-
Salvaguardas de producción:
prevent_destroyevita la pérdida accidental de infraestructura de red crítica - Shared VPC + Cloud NAT validados: todos los proyectos de servicio enrutan el egress a través de un gateway NAT centralizado
Serving de LLM multimodal entre motores y nubes
Selección de runtime según el modelo, verificación de la revisión servida y fallback autenticado.
El POC de router y la posterior integración del fallback en producción tienen mediciones y alcances de despliegue separados.
Alcance y resultado
Construí rutas de serving con vLLM y llama.cpp conscientes del modelo, reparé despliegues que servían una revisión antigua y validé el fallback autenticado de la aplicación en cuatro entornos. El router anterior de tres proveedores sigue siendo un POC aparte.
Defender Kubernetes contra ataques a la cadena de suministro
Seguridad · Kubernetes · Defensa de la cadena de suministro
Combina verificaciones del pipeline con detección de anomalías a nivel de nodo y un procedimiento de contención explícito.
La amenaza
Una dependencia comprometida puede colar un cryptominer (como xmrig) en un build y pasar la revisión de código, para luego consumir CPU en silencio en un nodo de producción sin síntomas en la aplicación. El código malicioso nunca aparece en un diff, porque llega a través de un paquete transitivo y se ensambla en el bundle en tiempo de build.
Detección y defensa en profundidad
- Detectar en el nodo: las alertas de anomalías de CPU a nivel de nodo (ventana de umbral corta) son el disparador cuando la aplicación en sí parece saludable
- Contener rápido: aislar (cordon) el nodo afectado, drenarlo y reprogramar en nodos limpios, luego remediar el origen y fijar las versiones transitivas
-
Controlar el pipeline:
npm audit --audit-level=highmás el escaneo de imágenes con Trivy en cada build previo al despliegue - Exigir lockfiles: se requieren lockfiles commiteados; el CI falla si faltan o cambian sin revisión
- Restringir el runtime: Pod Security Standards (restricted) en todos los namespaces para bloquear la escalada de privilegios
- Egress denegado por defecto: las network policies bloquean las salidas hacia mining pools y endpoints desconocidos, de modo que una intrusión queda sin salida
Respuesta a incidentes en producción — Caída P1 y falla de autenticación de socio
Marzo de 2026 · Respuesta a incidentes · Confiabilidad en producción
Un modelo de respuesta simplificado para incidentes de dependencia y de autenticación; el trabajo de recuperación es compartido.
Incidente A — Cargador de CMS de terceros [P1]: HTTP 500 en dos mercados regionales
- Impacto: 100% de las cargas de página devolviendo HTTP 500 desde las 13:08 UTC; caída total de producción en dos mercados regionales
- Causa raíz: la dependencia de la API del CMS de terceros tuvo una caída; todas las páginas fallaron en el renderizado del lado del servidor
- Respuesta: identifiqué la falla de dependencia, implementé un fallback estático de emergencia y escalé al soporte del proveedor
- Resolución: servicio restaurado; agregué un patrón circuit-breaker y monitoreo de salud para las dependencias externas de CMS
Incidente B — API de socio [P2]: la rotación de credenciales causa falla de autenticación
- Impacto: todas las llamadas de autenticación del socio devolviendo 401 desde las ~14:30 UTC tras la rotación de contraseña del lado del socio
- Causa raíz: el socio rotó las credenciales sin una notificación coordinada; la contraseña antigua fue revocada a media jornada
- Respuesta: diagnostiqué la falla de autenticación a partir de los logs, obtuve nuevas credenciales, actualicé GCP Secret Manager y disparé un reinicio continuo
- Fortalecimiento: establecí un runbook de rotación de credenciales y un SLA de notificación acordado con el socio
Principios de SRE aplicados
- Respuesta operativa: ambos incidentes se resolvieron dentro del mismo día hábil
- Post-mortems sin culpa: causas raíz documentadas, correcciones sistémicas implementadas
- Brechas de monitoreo cerradas: verificaciones de salud de dependencias externas agregadas después de cada incidente
Migración de Elastic Stack — De EC2 a Kubernetes a escala
2020–2021 · Observabilidad · Modernización de infraestructura
El diseño en Kubernetes separa los roles master, data e ingest con backups basados en snapshots.
Problema
- 2 clústeres heredados de Elastic Stack: Elasticsearch 5 en EC2 y Elasticsearch 6 en ECS, ambos vía docker-compose
- Sin separación de roles: cada nodo manejaba la elección de master, el almacenamiento de datos y el ingest simultáneamente
- Escalado manual, sin self-healing, puntos únicos de falla
- Cuello de botella de almacenamiento: sin snapshots en S3, sin políticas de retención automatizadas
Solución
- Consolidé ambos clústeres en 1 clúster EKS unificado con Elasticsearch 7.8
- Diseñé una arquitectura multinodo con roles dedicados: 3 master (8 GB), 3 data (16 GB, 50 TB), 3 ingest (16 GB)
- Imagen ECR personalizada con plugin de snapshots de S3 para backup y retención automatizados
- Desplegué mediante Helm Charts con rolling updates, PDB (maxUnavailable: 1) y anti-afinidad suave
- Construí 9 pipelines especializados de Logstash para distintas fuentes de logs (GELF, K8s, NiFi, PHP, portal, servicios, reportes)
- DaemonSet de Filebeat con enriquecimiento de metadatos de Kubernetes para la recolección de logs de contenedores
- Fluent Bit como colector alternativo ligero con filtrado a nivel de kernel
- Kibana con 3 réplicas y reportes CSV (1 GB máx.), APM Server para tracing y Metricbeat para la salud del clúster
Impacto en el negocio
- Consolidación histórica: reemplacé una flota heredada de dos clústeres por un pool de nodos EKS más pequeño
- Consolidación 2 → 1 clúster: eliminé toda la flota heredada de instancias y volúmenes, reemplazándola con un puñado de nodos EKS
- Actualización de versión v5/v6 → v7.8: salto de versión mayor, habilitando ILM, funciones de seguridad y gestión del ciclo de vida de índices
- Migración EBS GP2 → Standard: migré toda la flota de volúmenes en dos regiones de AWS, reduciendo los costos de almacenamiento
- Análisis de costos multirregión: los precios regionales informaron la decisión de consolidación
- Limpieza de S3: eliminé un bucket de S3 grande sin uso (decenas de TB) y automaticé la retención de snapshots mediante una imagen ECR personalizada con el plugin repository-s3
- 9 pipelines dedicados de Logstash: cada pipeline ajustado para su fuente específica, permitiendo escalado y diagnóstico independientes
- Infraestructura con self-healing: los StatefulSets de Kubernetes con PDB, rolling updates y recuperación automatizada reemplazaron la gestión manual de EC2
Event Streaming con Kafka — Pipeline en tiempo real hacia BI
2020–2021 · Ingeniería de datos · Arquitectura orientada a eventos
Los filtros de Logstash alimentan Elasticsearch y los topics de Kafka para los consumidores de BI aguas abajo.
Problema
- El equipo de business intelligence no tenía acceso en tiempo real a los datos de eventos de API y servicios
- Los datos de logs estaban aislados en Elasticsearch, inaccesibles para la analítica aguas abajo
- Múltiples fuentes de eventos (GELF, RabbitMQ, HTTP) necesitaban enrutamiento unificado hacia topics de Kafka
- Sin un pipeline estandarizado para transmitir eventos filtrados a los sistemas de analítica
Solución
- Diseñé pipelines de Logstash de salida dual: eventos indexados en Elasticsearch Y reenviados a topics de Kafka
- Integré con AWS MSK (Managed Streaming for Apache Kafka) con compresión gzip
- Construí enrutamiento condicional: eventos de API filtrados por nombre de servicio y reenviados a topics de Kafka dedicados para el consumo de BI
- Plugin de entrada de RabbitMQ para eventos de cola de mensajes junto con GELF y enrutamiento pipeline-a-pipeline
- Productor de Kafka configurado con seguimiento de client_id y estrategia de un topic por dominio
Impacto en el negocio
- Pipeline de BI en tiempo real: el equipo de business intelligence obtuvo acceso a eventos de API en vivo por primera vez, habilitando analítica en tiempo real
- Arquitectura de doble escritura: cada evento indexado en Elasticsearch para búsqueda operativa Y transmitido a Kafka para analítica aguas abajo, sin duplicación de datos en el origen
- Enrutamiento condicional: solo los eventos relevantes se reenvían a Kafka, reduciendo el ruido para los consumidores y el volumen de topics
- Integración con AWS MSK: Kafka gestionado con compresión gzip redujo los costos de red y simplificó las operaciones
- Unificación multifuente: entradas GELF, RabbitMQ, HTTP y pipeline-a-pipeline consolidadas en una sola capa de procesamiento
Integración de herramientas de IA — Productividad del equipo
2024–2025 · Adopción de IA · Experiencia de desarrollo
Adopción de herramientas y evaluación del flujo de revisión; las mejoras de productividad no se midieron aquí.
Solución
- Dic 2024: Habilité Claude AI para todo el equipo
- Ago 2024: Incorporé a los equipos de QA y desarrollo a GitHub Copilot
- Ago 2025: Evalué Claude Code para revisiones de PR automatizadas en pipelines de Bitbucket
- Creé guías de buenas prácticas para el desarrollo asistido por IA
Impacto en el negocio
- Adopción temprana de herramientas de IA: Claude AI en dic 2024, Copilot en ago 2024, antes que la mayoría de los equipos de la organización
- Revisiones de PR automatizadas con Claude Code; los revisores dedican tiempo a la lógica, no al estilo
- Los desarrolladores junior se incorporan más rápido: el desarrollo asistido por IA reduce la brecha entre seniors y juniors en las tareas rutinarias
Pokémon GO Friend Code — SaaS de suscripción
2025–2026 · Full-Stack · Next.js · GCP · Multipago ·
Producto personal: el estado del pago controla qué códigos de entrenador permanecen activos para el envío.
Qué hace
Un servicio de suscripción para que los jugadores de Pokémon GO tengan sus códigos de entrenador enviados automáticamente a los sitios de listados de la comunidad todos los días. Los usuarios eligen un plan, pagan y su código se envía cada día sin ninguna acción manual.
Cómo está construido
- Full-stack con Next.js 16 App Router con Server Components, Server Actions y build multi-stage de Docker desplegado en Cloud Run (escala a cero)
- Pasarela de pago dual: Mercado Pago para suscriptores PT/BRL, Stripe para EN+ES/USD; el mismo código base, enrutamiento según el idioma vía middleware
- i18n con subrutas
/pt,/en,/es; el middleware de Accept-Language redirige automáticamente en la primera visita - Máquina de estados de webhooks con procesamiento idempotente y la tabla
submission_logsque registra cada evento de pago - Cero credenciales estáticas: GCP Secret Manager en runtime, Workload Identity Federation para la autenticación de GitHub → GCP en CI
- Panel de administración (sesiones HMAC-SHA256 del lado del servidor) para la gestión de suscripciones y la inspección de webhooks
- Confirmaciones por correo vía Resend con plantillas de React Email · Migraciones de base de datos vía Drizzle ORM
Aspectos técnicos destacados
- Cloud Run southamerica-east1: autoescala, HTTPS vía dominio personalizado (pokemongofriendscode.com)
- Workload Identity Federation: sin claves de cuenta de servicio de larga duración en CI; GitHub Actions intercambia tokens OIDC con GCP
- Probado con Jest (unitario/integración) y Playwright (E2E)
Pokémon GO GCP — Motor de envío automatizado de códigos
2025–2026 · Automatización de backend · Cloud Run Jobs · Web Scraping ·
Un backend programado verifica las suscripciones activas, envía los códigos y confirma su aparición.
Qué hace
El backend de automatización del servicio de suscripción. Un Cloud Run Job programado que lee los códigos de entrenador activos desde Cloud SQL y los envía a dos sitios de la comunidad todos los días a las 15:00 BRT, totalmente headless y sin intervención manual.
Cómo está construido
- Dos scrapers independientes: Puppeteer + plugin stealth para pokemongofriendcodes.com, Playwright para pogocodes.com (formulario basado en React)
- Solución alternativa para componentes controlados de React en pogocodes.com; despacha eventos de input con
bubbles: truepara disparar los manejadores de eventos sintéticos - Paso de verificación después de cada envío: navega a la página de listados para confirmar que el código realmente aparece
- Procesamiento por lotes (3 códigos simultáneamente) con retrasos configurables por tipo de acción para evitar la limitación de tasa
- Basado en base de datos: los códigos provienen de la tabla
trainer_codesde Cloud SQL (única fuente de verdad, sincronizada desde los webhooks de pago) - IaC completa con Terraform para Cloud SQL, Cloud Run Jobs, Cloud Scheduler, Secret Manager e IAM
Aspectos técnicos destacados
- Modelo de ejecución: los jobs programados se reducen entre ejecuciones; el costo total del servicio también incluye sus otros recursos en la nube
- Detección de límite de tasa: pokemongofriendcodes.com bloquea los reenvíos dentro de 24h; el script lo detecta y se detiene de forma controlada
- Alertas de Cloud Monitoring ante un código de salida ≠ 0; la ejecución fallida del job notifica al responsable
AmigoSecreto — App Android (Google Play)
2024–2026 · Android · Kotlin · MVVM · Google Play ·
App Android nativa con reglas de exclusión, persistencia local y revelación segura del resultado.
Qué hace
Una app Android completa para organizar sorteos de amigo secreto. Admite múltiples grupos, reglas de exclusión, listas de deseos, revelación segura y compartir resultados vía WhatsApp, Telegram, SMS o correo. Disponible en Google Play.
Cómo está construido
- Migrada completamente a Kotlin (desde Java) con arquitectura MVVM: patrón AndroidViewModel + LiveData + Repository
- Hilt para inyección de dependencias · Coroutines para operaciones de base de datos asíncronas en el hilo de IO
- Room ORM con base de datos de doble capa (Room + DAOs heredados coexisten; la inicialización anticipada de Room asegura que las migraciones se completen primero)
- Algoritmo de sorteo con backtracking extraído a una función pura (
SorteioEngine.kt): testeable, sin efectos secundarios, maneja de forma controlada los escenarios con restricciones imposibles - Consultas por lotes con INNER JOIN para eliminar el problema N+1 en los conteos de listas de deseos · Todas las escrituras en la base de datos en transacciones atómicas
- Diseño Edge-to-Edge (Android 15), exportación a PDF (PDFKit), generación de códigos QR, notificaciones locales, backup/restauración como JSON
- CI/CD con GitHub Actions: push a master → track interno de Play; tag
v3.x→ track de producción
Aspectos técnicos destacados
-
297 pruebas unitarias + pruebas de integración con Espresso ·
UnconfinedTestDispatcherpara pruebas deterministas de coroutines - Min SDK 21 (Android 5.0+) · Target SDK 35 (Android 15) · minificación con R8 en los builds de release
- Protección anti-spoiler al compartir por WhatsApp: 30 líneas en blanco antes de la asignación para evitar que las vistas previas revelen el resultado
Secret Santa — App iOS (SwiftUI)
2025–2026 · iOS 17+ · Swift · SwiftUI · SwiftData ·
SwiftUI y SwiftData mantienen la interfaz, la persistencia y el flujo de sorteo dentro de frameworks nativos.
Qué hace
La contraparte en iOS de AmigoSecreto, el mismo concepto de producto reconstruido de forma nativa en Swift y SwiftUI para iPhone. Múltiples grupos, reglas de exclusión, listas de deseos, revelación segura, códigos QR, exportación a PDF y notificaciones locales. Cero dependencias externas.
Cómo está construido
- SwiftUI + SwiftData únicamente, sin paquetes de terceros; persistencia, UI, PDF, códigos QR y notificaciones, todo mediante frameworks nativos de Apple
- MVVM mediante
@Queryy@Environment(\.modelContext)de SwiftData, sin necesidad de clases ViewModel separadas - Solución alternativa de serialización JSON para relaciones muchos-a-muchos (limitación de SwiftData): las exclusiones y los pares del sorteo se almacenan como campos
Datacon decodificadores de propiedades computadas - Algoritmo de sorteo con backtracking y un límite de 200 intentos; la misma lógica que en Android, adaptada a Swift
-
SequentialShareView: solución alternativa para la limitación de iOS que impide abrir múltiples esquemas de URL simultáneamente; muestra botones secuenciales para WhatsApp, SMS y correo - Onboarding de 6 páginas, historial de sorteos, estadísticas, backup/restauración con compatibilidad futura de JSON
Aspectos técnicos destacados
-
30+ pruebas unitarias usando el framework Swift Testing (
@Suite,@Test) -
iOS 17+ mínimo: usa
ContentUnavailableView,@Bindabley otras APIs modernas en todo el proyecto - Generación de PDF mediante
UIGraphicsPDFRenderer· códigos QR medianteCIQRCodeGeneratorde Core Image · feedback háptico al revelar
Experiencia
Del desarrollo de software a la confiabilidad y las plataformas de ingeniería compartidas.
VerifyMy
Site Reliability Engineer
Jun 2021 – Actualidad · 5 años 4 meses
Platform engineering para seguridad en línea regulada.
- Construí y operé infraestructura en la nube, pipelines de entrega y monitoreo en múltiples entornos.
- Desarrollé un piloto de entornos de vista previa efímeros y probé la promoción de imágenes sin recompilaciones.
- Diagnostiqué fallas de la plataforma de CI compartida y reparé brechas de alertas introducidas por migraciones de runtime.
- Aporté controles de infraestructura, evidencia operativa y procedimientos de recuperación para auditorías de seguridad.
Intelipost
Site Reliability Engineer
Feb 2020 – Jun 2021
Confiabilidad y modernización de infraestructura para tecnología logística.
- Consolidé despliegues heredados de Elastic Stack en Kubernetes con roles de nodo dedicados y backups automatizados.
- Construí pipelines de logs especializados y event streaming para monitoreo operativo y business intelligence.
- Apoyé la planificación de capacidad y la preparación de infraestructura para los picos de demanda estacional.
Dasa
Site Reliability Engineer
Ene 2018 – Feb 2020
Operaciones en la nube en un gran entorno de salud.
- Aprovisioné entornos de Kubernetes y redes usando Terraform y pipelines de despliegue automatizados.
- Trabajé en Azure y AWS en observabilidad, automatización de infraestructura y respuesta a incidentes.
- Creé el descubrimiento de monitoreo y documentación operativa para mejorar la cobertura y la transferencia de conocimiento.
Trayectoria anterior · desarrollo de software y TI
- Dasa · Desarrollador de software
- Jul – Dic 2017
API Gateway e integración REST/SOAP. - PRÓPONTO · Desarrollador de software
- Ene – Jul 2017
Servicios web e integración continua. - Microdata Sistemas · Desarrollador Java
- Ene – Dic 2016
Servicios web en Java y e-commerce. - Microdata Sistemas · Analista de sistemas
- Nov 2014 – Dic 2015
Delphi, SQL Server y soporte empresarial. - GZ Sistemas · Analista junior de soporte de TI
- Mar 2013 – Jul 2014
Soporte al cliente, bases de datos, redes y Linux. - Coca-Cola FEMSA · Asistente administrativo y supervisor
- Feb 2012 – Mar 2013
Operaciones de entrega, reportes y cierre mensual.
La perspectiva de un operador.
El enfoque de un desarrollador.
Trabajo donde se encuentran la infraestructura, el software y la experiencia cotidiana del equipo de ingeniería.
Mi camino hacia la platform engineering comenzó en el soporte de TI y el desarrollo de software. Esa base hace que me importen ambos lados de una abstracción: cómo se comporta un sistema en producción y con qué facilidad otro ingeniero puede entenderlo y cambiarlo.
Mi mejor trabajo convierte una corrección puntual en una capacidad repetible: un flujo de despliegue, un enfoque de diagnóstico, una señal confiable o un procedimiento operativo documentado.
Capacidades, con evidencia
| Capacidad | Aplicado a | Evidencia |
|---|---|---|
| Platform y entrega | Kubernetes, Terraform, GitHub Actions, ArgoCD, Helm | Entornos de vista previa y promoción de imágenes |
| Confiabilidad y observabilidad | Jenkins, Prometheus, Grafana, Cloud Monitoring | Reparación de alertas consciente del runtime |
| Arquitectura en la nube | GCP, AWS, Azure; redes compartidas y entornos aislados | Terraform y Shared VPC |
| Operaciones de seguridad | Automatización de escaneos, enriquecimiento de métricas, controles operativos | Visibilidad de la postura de seguridad |
| Ingeniería de costos | Consolidación de recursos, asignación de costos, rutas de ingesta | Una reducción medida en la facturación de monitoreo |
| Infraestructura de IA | GPU serving, optimización de arranque, experimentos de failover | Serving de LLM multimodal y fallback operado |
Liderazgo técnico en la práctica
Tres ejemplos de convertir una investigación individual en algo que el equipo puede reutilizar. El alcance a continuación refleja el trabajo entregado; no se asume una adopción más amplia.
Hacer ejecutable un procedimiento de recuperación
Reparé defectos de bootstrap y teardown durante un ensayo completo del clúster, y luego reutilicé el proceso para reconstruir tres entornos. El ensayo restauró 35 aplicaciones de GitOps y adoptó 49 certificados sin reemitirlos.
Decisiones de recuperación y validación ↗Poner la corrección en la plataforma compartida
Aislé la sobrecarga de DNS, hice ajustable la configuración del resolver en el Helm chart compartido y verifiqué ocho combinaciones de aplicación/entorno antes del despliegue en producción.
Del diagnóstico a un ajuste reutilizable ↗Diseñar para el próximo ingeniero
Construí un piloto de vista previa en dos repositorios con una convención de entornos compartida, promoción de imágenes probadas y limpieza automática. El ciclo de vida hace que la creación y la eliminación sean parte de la misma capacidad.
El piloto y su límite de adopción ↗Demostración independiente del portafolio · Python
Lee la ruta de falla y luego ejecútala.
Un pequeño cliente de inferencia demuestra solicitudes autenticadas, timeouts por intento, lecturas de respuesta acotadas y resultados de fallback explícitos. Las pruebas de integración usan servidores HTTP locales reales; no se requiere GPU, suscripción a API ni descarga de modelos.
Este es un nuevo ejemplo educativo creado para este portafolio, separado del código del empleador. Ejercita el comportamiento del transporte con respuestas de modelo simuladas, no la calidad del modelo ni la capacidad de producción.
- Validar la configuración y autenticar
- Intentar el primario dentro de su timeout
- Recurrir al fallback ante una falla transitoria o una respuesta vacía
- Devolver una respuesta o una falla explícita
Cómo aporto más allá del código
- Acompaño a ingenieros en la respuesta a incidentes, los cambios de infraestructura y las revisiones de preparación para producción.
- Coordino migraciones y cambios de plataforma con los equipos de desarrollo, QA y seguridad.
- Documento decisiones, rutas de rollback y runbooks para que el trabajo siga siendo usable después del traspaso.
Educación
MBA, Ingeniería de Software
Wyden Educacional · 2015–2016
Análisis y Desarrollo de Sistemas
Anhanguera Educacional · 2012–2014
Idiomas
Portugués — nativo
Español — profesional pleno
Inglés — competencia profesional de trabajo
Cursos y formación continua
- Fundamentos de Google Cloud Platform: infraestructura esencial
- Logging, monitoreo y observabilidad en Google Cloud
- Desarrollo ágil avanzado con Java
- Programación en TypeScript y fundamentos de SQL
Hablemos de tu plataforma.
Me interesan los roles Senior y Staff en Platform Engineering y SRE, con foco en la entrega confiable, la infraestructura de IA y la eficiencia de costos en la nube.
Trabajar juntos a nivel internacional
- Roles
- Senior o Staff · Platform Engineering · Site Reliability Engineering
- Idiomas de trabajo
- Inglés — competencia profesional de trabajo
Portugués — nativo · Español — profesional pleno - Planear una conversación
- Incluye en tu mensaje la ubicación del rol, la superposición horaria requerida y la modalidad de contratación para que podamos conversar sobre el encaje, la autorización de trabajo y cualquier requisito de reubicación.
Los estudios de caso muestran cómo abordo los problemas. Si un desafío en particular te resulta familiar, inclúyelo en tu mensaje.