[{"content":"Comportamientos Clave para la Transformación DevOps: Rompiendo Silos y Adoptando el Cambio Introducción DevOps no se reduce a herramientas y metodologías. Es, sobre todo, un cambio en cómo los equipos trabajan, colaboran y toman decisiones. Las organizaciones que realmente adoptan DevOps lo hacen porque cambian comportamientos concretos, no porque instalan un pipeline de CI/CD.\nEn esta entrada reviso los comportamientos que marcan la diferencia: romper silos, gestionar el riesgo con cambios pequeños, construir infraestructura repetible, habilitar autoservicio y cerrar el ciclo con datos reales.\nRompiendo silos y promoviendo la colaboración Los silos organizacionales fragmentan a los equipos y multiplican las transferencias de tareas entre departamentos. Cada transferencia es un punto donde el proceso se ralentiza y la calidad se degrada.\nLa alternativa es una cultura de propiedad compartida: en DevOps no existe \u0026ldquo;tu parte del barco\u0026rdquo;. Si un área falla, el impacto lo sienten todos. Esa mentalidad —éxito o fracaso colectivo— es lo que sostiene la colaboración real, no un mural con la palabra \u0026ldquo;colaboración\u0026rdquo; en la sala de juntas.\nAdoptando el cambio y gestionando el riesgo El miedo al cambio frena más transformaciones que cualquier limitación técnica. Las organizaciones que lo superan no eliminan el riesgo: lo distribuyen.\nAhí está la lógica de DevOps: cambiar seguido, pero en pasos pequeños y controlados. Un cambio grande concentra el riesgo y genera resistencia natural del equipo. Una iteración pequeña se revierte en minutos si algo sale mal, y eso cambia por completo cómo la organización se relaciona con el riesgo.\nDe infraestructura única a infraestructura repetible Los snowflake servers —servidores configurados a mano, cada uno distinto— son difíciles de replicar y se convierten en puntos críticos de fallo. Nadie recuerda exactamente qué se instaló ni en qué orden.\nInfraestructura como Código (IaC) resuelve esto en la raíz: cada entorno se construye desde el mismo código, así que dos entornos con el mismo código son, por definición, iguales. Un contenedor Docker o una máquina virtual levantados desde el mismo manifiesto producen el mismo resultado, siempre. Eso es lo que hace posible escalar sin que cada entorno nuevo sea un experimento.\nAutomatización y autoservicio Las colas de tickets para aprovisionar recursos son, en la práctica, el opuesto de DevOps: dependencia de un tercero para algo que el equipo podría resolver solo. La nube expuso este problema con crudeza —muchas empresas migraron a la nube y luego reconstruyeron el mismo cuello de botella, restringiendo el acceso solo a TI.\nEl autoservicio automatizado elimina ese intermediario. Cuando un equipo puede aprovisionar y gestionar sus propios recursos, el tiempo de espera deja de ser el factor que determina la velocidad de desarrollo.\nCiclos de retroalimentación basados en datos El modelo tradicional —alarmas, escalaciones, llamadas de madrugada— reacciona tarde casi por diseño. DevOps lo reemplaza con circuitos de retroalimentación cortos, alimentados por datos en tiempo real.\nUn sistema de monitoreo bien configurado no solo avisa que algo falló: da contexto suficiente para actuar de inmediato, sin esperar a que alguien interprete manualmente qué pasó. Eso reduce el tiempo de resolución de incidentes de horas a minutos.\nConclusión DevOps se sostiene en comportamientos, no en herramientas. Romper silos, aceptar el riesgo en dosis pequeñas, construir infraestructura repetible, habilitar autoservicio y cerrar el ciclo con datos: ninguno de estos cambios requiere comprar software. Requieren decidir trabajar distinto.\n","permalink":"https://mauromejia.com/posts/comportamientos-transformacion-devops/","summary":"\u003ch1 id=\"comportamientos-clave-para-la-transformación-devops-rompiendo-silos-y-adoptando-el-cambio\"\u003eComportamientos Clave para la Transformación DevOps: Rompiendo Silos y Adoptando el Cambio\u003c/h1\u003e\n\u003ch2 id=\"introducción\"\u003eIntroducción\u003c/h2\u003e\n\u003cp\u003eDevOps no se reduce a herramientas y metodologías. Es, sobre todo, un cambio en cómo los equipos trabajan, colaboran y toman decisiones. Las organizaciones que realmente adoptan DevOps lo hacen porque cambian comportamientos concretos, no porque instalan un pipeline de CI/CD.\u003c/p\u003e\n\u003cp\u003eEn esta entrada reviso los comportamientos que marcan la diferencia: romper silos, gestionar el riesgo con cambios pequeños, construir infraestructura repetible, habilitar autoservicio y cerrar el ciclo con datos reales.\u003c/p\u003e","title":"Comportamientos Transformacion Devops"},{"content":"Introducción La velocidad ya no es un lujo para las empresas de software: es la diferencia entre liderar el mercado o quedarse atrás. Ahí entra DevOps, un enfoque que busca que los equipos experimenten más rápido y con menos riesgo, sin sacrificar calidad en cada despliegue.\nDevOps combina cambio cultural, prácticas de trabajo y herramientas tecnológicas. Ninguna de las tres piezas funciona sola. En este artículo repasamos sus características esenciales y cómo, juntas, cambian la forma en que las organizaciones operan.\nEl Contexto de DevOps El desarrollo de software pasó por varias etapas antes de llegar aquí. Empezó con el modelo Waterfall, pensado para aplicaciones monolíticas corriendo en servidores físicos. Después llegó el enfoque ágil, apoyado en arquitecturas orientadas a servicios. DevOps es el siguiente paso de esa evolución, y no llegó de un día para otro.\nTres pilares sostienen este enfoque: microservicios, contenedores e infraestructura inmutable. Los microservicios rompen una aplicación en piezas pequeñas e independientes que se comunican por API. Los contenedores le dan a esas piezas un entorno portable y efímero, fácil de desplegar y de recuperar cuando algo falla.\nCuando flexibilidad, resiliencia y velocidad se juntan, el resultado es lo que muchos llaman la \u0026ldquo;tormenta perfecta\u0026rdquo;: la combinación que permite llevar valor al mercado mucho más rápido que antes.\nLas Dimensiones de DevOps 1. Cultura Todo empieza por un cambio cultural. [CORRECCIÓN: la cita textual atribuida a Atlassian no aparece así en sus publicaciones; lo que reportan es que, según una encuesta propia, el 39% de los profesionales consultados identificó a las personas y la cultura —no a las herramientas— como el principal factor de éxito en DevOps. Fuente: Atlassian, \u0026ldquo;What\u0026rsquo;s the foundation of DevOps success?\u0026rdquo;] Atlassian respalda esta idea con datos: en una encuesta a 500 profesionales, casi cuatro de cada diez señalaron a la cultura, por encima de las herramientas, como el factor decisivo para el éxito de una transformación DevOps.\nConstruir esa cultura implica:\nApertura, transparencia y respeto: equipos multidisciplinares que trabajan con confianza mutua. Responsabilidad compartida: borrar la línea que separa desarrollo de operaciones. Retroalimentación constante: procesos que empujen la mejora continua, no que la frenen. Cambiar la cultura de una organización toma tiempo y no es trivial. Necesita liderazgo desde arriba y compromiso desde el resto del equipo. La clave está en redefinir qué se mide como éxito y construir una mentalidad de colaboración real, no solo declarada.\n2. Métodos Los métodos DevOps atacan cada etapa del ciclo de vida del software. Los más relevantes:\nPipelines automatizados: integración continua (CI) y despliegue continuo (CD) para no frenar el flujo de trabajo. Infraestructura como código (IaC): la infraestructura se gestiona y versiona como cualquier otro código. Desarrollo por lotes pequeños: cambios chicos y frecuentes en lugar de grandes releases riesgosos. Infraestructura inmutable: en vez de modificar un sistema en producción, se despliega una versión nueva. 3. Herramientas Las herramientas no son el corazón de DevOps, pero facilitan que todo lo anterior funcione en la práctica. Algunas de las más usadas:\nJenkins para integración continua. Docker y Kubernetes para gestionar contenedores. Terraform para implementar IaC. Sin gente y sin procesos claros, estas herramientas por sí solas no generan ningún beneficio.\n4. Midiendo el Progreso: el Framework CALMS Cultura, métodos y herramientas no viven en compartimentos separados — CALMS es el marco que junta los tres en una sola fórmula. El acrónimo lo acuñó Jez Humble, coautor de The DevOps Handbook, y sirve tanto para evaluar qué tan lista está una organización para adoptar DevOps como para medir su progreso una vez que ya arrancó la transformación.\nCALMS significa:\nCulture (Cultura): colaboración real entre desarrollo y operaciones, no solo en el papel. Automation (Automatización): pipelines, pruebas e infraestructura gestionados sin intervención manual constante. Lean: entregas en lotes pequeños, con foco en reducir desperdicio y tiempos de espera. Measurement (Medición): métricas que reflejan impacto real en el negocio, no solo actividad del equipo. Sharing (Compartir): conocimiento y responsabilidades distribuidos entre todo el equipo, sin silos de información. Usar CALMS como checklist ayuda a detectar en qué dimensión está fallando una transformación DevOps. Es común, por ejemplo, encontrar equipos con automatización sólida pero sin ningún cambio cultural real detrás — lo que termina en lo que algunos llaman \u0026ldquo;DevOps de fachada\u0026rdquo;.\nEl Impacto de DevOps: La Tormenta Perfecta Cuando DevOps se apoya en microservicios y contenedores, el resultado es una infraestructura rápida, estable y eficiente. Los contenedores están pensados para ser efímeros: si uno falla, simplemente se reemplaza en lugar de repararlo. Eso reduce el tiempo de inactividad y simplifica la operación día a día.\nEl diseño desacoplado de los microservicios suma a esto: permite hacer cambios pequeños sin tocar el sistema completo, lo que abre la puerta a innovar más seguido sin poner en riesgo la estabilidad general.\nConclusión DevOps no se \u0026ldquo;implementa\u0026rdquo; de una vez y se olvida: es una forma de trabajar que se ajusta todo el tiempo. La mezcla de cultura, métodos y herramientas que vimos aquí es lo que convierte a DevOps en un motor real de competitividad, no solo en una palabra de moda.\nAdoptarlo en serio implica algo más que instalar Jenkins o migrar a Kubernetes: pide abrir canales de comunicación, compartir responsabilidades y aceptar que la experimentación trae errores. Las organizaciones que lo logran no solo despliegan más rápido — cambian la forma en que construyen valor para sus usuarios.\n","permalink":"https://mauromejia.com/posts/caracteristicas-devops/","summary":"\u003ch2 id=\"introducción\"\u003eIntroducción\u003c/h2\u003e\n\u003cp\u003eLa velocidad ya no es un lujo para las empresas de software: es la diferencia entre liderar el mercado o quedarse atrás. Ahí entra DevOps, un enfoque que busca que los equipos experimenten más rápido y con menos riesgo, sin sacrificar calidad en cada despliegue.\u003c/p\u003e\n\u003cp\u003eDevOps combina cambio cultural, prácticas de trabajo y herramientas tecnológicas. Ninguna de las tres piezas funciona sola. En este artículo repasamos sus características esenciales y cómo, juntas, cambian la forma en que las organizaciones operan.\u003c/p\u003e","title":"Las Características Esenciales de DevOps: Cultura, Métodos y Herramientas"},{"content":"Introducción En la primera parte de esta serie vimos las prácticas generales de ciberseguridad en la nube: gestión de accesos, monitoreo, cifrado y auditorías. Esta segunda parte toma esos mismos pilares y los lleva al terreno: cómo se implementan específicamente en Google Cloud.\nMigrar a GCP no elimina los riesgos — los redistribuye. Bajo el modelo de responsabilidad compartida, Google asegura la infraestructura; tú aseguras todo lo que corre encima. Ransomware, credenciales comprometidas y misconfiguraciones siguen siendo los vectores dominantes, pero en GCP cada uno tiene un punto de entrada específico y una herramienta nativa para contenerlo.\n1. Gestión de identidades con IAM nativo de GCP El exceso de permisos sigue siendo el origen de la mayoría de los incidentes en la nube — el mismo problema que vimos en la Parte 1 al hablar de RBAC y MFA. En GCP, esto se resuelve con controles más granulares:\nWorkload Identity Federation: elimina la necesidad de service account keys en disco — el peor secreto que puede filtrarse en un repositorio. Principle of Least Privilege con IAM Recommender: GCP analiza el uso real de permisos y sugiere políticas más restrictivas automáticamente. Si un service account lleva 90 días sin usar storage.objects.delete, IAM Recommender te lo señala. Org Policies: aplica restricciones a nivel de organización, como bloquear recursos públicos o exigir que los recursos solo se creen en regiones específicas. MFA con Context-Aware Access (BeyondCorp): va más allá del segundo factor — evalúa el dispositivo, la ubicación y el comportamiento antes de autorizar acceso. 2. Detección de misconfiguraciones con Security Command Center Una de las mayores fuentes de incidentes en GCP no son los ataques sofisticados, sino buckets de Cloud Storage públicos o reglas de firewall abiertas al mundo.\nSecurity Command Center (SCC) es el CSPM nativo de GCP. En su tier Premium hace lo que hacen herramientas de terceros como Orca o Wiz, pero integrado directamente en la plataforma:\nDetecta buckets públicos, VMs con IPs externas innecesarias, claves de API expuestas. Genera findings mapeados al CIS Google Cloud Foundations Benchmark, el framework de referencia principal para hardening en GCP. Integra Web Security Scanner para detectar vulnerabilidades en apps expuestas en App Engine o GKE. El benchmark CIS GCP agrupa sus controles por dominio (IAM, Logging, Networking, VMs, Storage). Usarlo como checklist base es la forma más rápida de reducir la superficie de ataque desde el día uno.\n3. Monitoreo y respuesta con Cloud Logging + Chronicle Tener logs no sirve de nada si no los procesas. GCP centraliza la telemetría en Cloud Logging, pero el análisis real ocurre en otra capa — esta es la versión GCP del punto de monitoreo en tiempo real de la Parte 1.\nCloud Audit Logs registra cuatro tipos de eventos: Admin Activity (quién cambió qué), Data Access (quién leyó qué), System Event (eventos generados por el propio sistema, sin acción del usuario) y Policy Denied [CORRECCIÓN: el artículo original mencionaba solo tres tipos; Policy Denied es el cuarto, registra los accesos bloqueados por VPC Service Controls u otras políticas de seguridad, según la documentación oficial de Cloud Logging]. Activar Data Access logs en servicios sensibles (BigQuery, Secret Manager) es clave — no viene habilitado por defecto en todos los servicios. Chronicle SIEM (ahora parte de Google Security Operations) permite correlacionar eventos de Cloud Logging con inteligencia de amenazas a escala petabyte. Para equipos que ya trabajan con reglas YARA-L, la transición desde otros SIEMs es directa. Event Threat Detection dentro de SCC detecta patrones como brute force en SSH, exfiltración hacia IPs maliciosas o criptominería en VMs — sin configuración manual de reglas. 4. Cifrado y gestión de secretos GCP cifra todo en reposo por defecto con claves gestionadas por Google, pero para datos sensibles eso no es suficiente — el mismo principio de \u0026ldquo;cifrado en tránsito y en reposo\u0026rdquo; de la Parte 1, aquí con sus herramientas concretas:\nCloud KMS + CMEK (Customer-Managed Encryption Keys): te da control sobre el ciclo de vida de las claves. Si necesitas revocar acceso a datos de forma inmediata, destruyes la clave. Secret Manager: centraliza credenciales, API keys y certificados. Integra rotación automática y auditoría de acceso. Ningún secreto debería vivir en variables de entorno de Cloud Run o en archivos de configuración dentro de un repo. Certificate Authority Service: para equipos que gestionan TLS internamente dentro de una VPC o entre servicios en GKE. 5. Hardening de red con VPC y Zero Trust El modelo Zero Trust aplicado a GCP asume que ningún tráfico es confiable por defecto, ni el interno. Este es el pilar que la Parte 1 no cubría a fondo, y que en GCP toma forma con:\nVPC Service Controls: crea perímetros de seguridad alrededor de APIs de GCP (BigQuery, Cloud Storage, etc.) para prevenir exfiltración de datos incluso si una cuenta queda comprometida. Private Google Access + Private Service Connect: los servicios consumen APIs de Google sin salir a internet público. Firewall Rules + Hierarchical Firewall Policies: define reglas a nivel de organización que no pueden ser sobreescritas por equipos individuales — útil para garantizar que ningún proyecto abra el puerto 22 al mundo. Cloud Armor: WAF y protección DDoS para cargas en HTTP(S) Load Balancer. 6. Frameworks de referencia Tres frameworks que deberían estar en el radar de cualquier equipo trabajando en GCP, y que complementan las auditorías y evaluaciones continuas que mencionamos en la Parte 1:\nCIS Google Cloud Foundations Benchmark: el punto de partida para hardening. SCC Premium mapea sus findings directamente a estos controles. NIST CSF 2.0: framework de gestión de riesgo más amplio. Útil para estructurar el programa de seguridad más allá de los controles técnicos — cubre identificación, protección, detección, respuesta y recuperación. Zero Trust Architecture (NIST SP 800-207): define los principios para migrar de un modelo perimetral a uno basado en verificación continua de identidad y contexto. BeyondCorp Enterprise de Google es la implementación nativa de este modelo en GCP. Conclusión En la Parte 1 hablamos de principios generales; aquí los aterrizamos en GCP. La diferencia entre un entorno razonablemente seguro y uno que está a un misconfiguration de distancia de un incidente está en capas: IAM bien diseñado, SCC activo contra el CIS Benchmark, logs procesados y perímetros de red definidos explícitamente. Las herramientas están disponibles — el reto está en configurarlas correctamente y mantenerlas alineadas con las amenazas actuales.\n","permalink":"https://mauromejia.com/posts/ciberseguridad-practicas-empresariales-gcp/","summary":"\u003ch2 id=\"introducción\"\u003eIntroducción\u003c/h2\u003e\n\u003cp\u003eEn la primera parte de esta serie vimos las prácticas generales de ciberseguridad en la nube: gestión de accesos, monitoreo, cifrado y auditorías. Esta segunda parte toma esos mismos pilares y los lleva al terreno: cómo se implementan específicamente en Google Cloud.\u003c/p\u003e\n\u003cp\u003eMigrar a GCP no elimina los riesgos — los redistribuye. Bajo el modelo de responsabilidad compartida, Google asegura la infraestructura; tú aseguras todo lo que corre encima. Ransomware, credenciales comprometidas y misconfiguraciones siguen siendo los vectores dominantes, pero en GCP cada uno tiene un punto de entrada específico y una herramienta nativa para contenerlo.\u003c/p\u003e","title":"Ciberseguridad en la Nube con GCP (Parte 2): Prácticas Concretas para Equipos Técnicos"},{"content":"Introducción Mover datos y aplicaciones a la nube le da a las empresas flexibilidad y escalabilidad que antes no tenían. Pero ese cambio también abre la puerta a riesgos puntuales: ransomware, robo de credenciales, configuraciones de red mal hechas. Aquí repasamos las prácticas que de verdad marcan la diferencia para proteger datos empresariales en entornos cloud.\n1. Conoce las amenazas más comunes en la nube Antes de blindar nada, conviene saber contra qué te enfrentas. Estas son las amenazas que más se repiten:\nRansomware: secuestra datos críticos, normalmente a través de correos maliciosos o archivos infectados. Phishing y suplantación de identidad: roba credenciales y abre la puerta a filtraciones de datos. Configuraciones incorrectas: un bucket mal permisado o un security group abierto de más sigue siendo uno de los blancos favoritos de los atacantes. 2. Controla quién accede a qué El acceso descontrolado es uno de los puntos débiles más comunes. Dos prácticas reducen ese riesgo de forma directa:\nAutenticación Multifactor (MFA): exige más de un factor de verificación, así que una contraseña filtrada ya no basta para entrar. Control de acceso basado en roles (RBAC): cada usuario tiene solo los permisos que necesita para su trabajo, ni uno más. Si una cuenta se compromete, el daño queda contenido. 3. Monitorea en tiempo real Vigilar la actividad en la nube de forma constante te permite detectar comportamientos raros antes de que se conviertan en un incidente real.\nDetección y respuesta: sistemas que identifican patrones inusuales y disparan una alerta o una acción automática. Registro de accesos: llevar un log detallado de quién entró, cuándo y a qué, para poder reconstruir cualquier acceso sospechoso. 4. Cifra los datos en tránsito y en reposo El cifrado hace que, aunque alguien intercepte o robe los datos, no pueda leerlos sin la clave correspondiente.\nEn tránsito: protege la información mientras viaja entre dispositivos y servicios. En reposo: protege lo que está almacenado, incluso si alguien logra acceso físico o lógico al medio de almacenamiento. 5. Audita y evalúa la seguridad de forma continua Las amenazas cambian, así que la seguridad no puede ser algo que se configura una vez y se olvida.\nAuditorías de seguridad: detectan debilidades antes de que alguien más lo haga. Pruebas de penetración: simulan ataques reales para ver qué tan bien (o mal) resiste tu infraestructura. Revisión continua de configuraciones: ajusta tus controles a medida que aparecen nuevas amenazas o cambian las recomendaciones del proveedor cloud. Conclusión No hay una sola herramienta que resuelva la ciberseguridad en la nube. Es la combinación de control de accesos, cifrado, monitoreo y auditorías constantes la que realmente reduce el riesgo. Las amenazas no se quedan quietas, así que tampoco puede quedarse quieta tu estrategia de seguridad.\n","permalink":"https://mauromejia.com/posts/ciberseguridad-practicas-empresariales/","summary":"\u003ch2 id=\"introducción\"\u003eIntroducción\u003c/h2\u003e\n\u003cp\u003eMover datos y aplicaciones a la nube le da a las empresas flexibilidad y escalabilidad que antes no tenían. Pero ese cambio también abre la puerta a riesgos puntuales: ransomware, robo de credenciales, configuraciones de red mal hechas. Aquí repasamos las prácticas que de verdad marcan la diferencia para proteger datos empresariales en entornos cloud.\u003c/p\u003e\n\u003ch2 id=\"1-conoce-las-amenazas-más-comunes-en-la-nube\"\u003e1. Conoce las amenazas más comunes en la nube\u003c/h2\u003e\n\u003cp\u003eAntes de blindar nada, conviene saber contra qué te enfrentas. Estas son las amenazas que más se repiten:\u003c/p\u003e","title":"Ciberseguridad en la Nube: Mejores Prácticas para la Protección de Datos Empresariales"},{"content":"Sigo trabajando con instancias en Oracle Cloud Infrastructure (OCI), en mi caso instancias ARM (Ampere A1) dentro del Free Tier. Una de ellas quedó configurada así:\nSistema operativo: Oracle Linux CPU: 2 cores RAM: 12 GB Boot Volume: 100 GB Al revisar el sistema, el espacio disponible en disco era de apenas ~50 GB, aunque el volumen asignado era de 100 GB. En este artículo explico por qué pasa esto y cómo solucionarlo.\nVerificando el problema df -h Muestra solo los sistemas de archivos montados. El resultado solo refleja el espacio ya asignado al sistema (~50 GB).\nlsblk Muestra los discos y particiones existentes, estén montados o no. Aquí confirmas que el disco completo (100 GB) existe, pero no todo está asignado a una partición.\ncfdisk Muestra el espacio particionado y el libre dentro del disco. En este caso se veían unos 53 GB sin usar.\n¿Por qué pasa esto en OCI? Es un comportamiento normal, no un error. OCI no expande automáticamente la partición raíz aunque el volumen de disco sea mayor. Esto es intencional para:\nEvitar modificaciones automáticas sobre particiones críticas Dejar que tú definas tu propio esquema de particionado Facilitar escenarios empresariales (LVM, múltiples puntos de montaje, etc.) En la mayoría de los casos, Oracle Linux en OCI usa LVM, lo que simplifica bastante la solución.\nConfirmando el uso de LVM lsblk Salida típica en Oracle Linux sobre OCI:\nsda 100G\n├─sda1 100M /boot/efi\n├─sda2 2G /boot\n└─sda3 44.5G LVM (PV)\n├─ocivolume-root 24.5G /\n└─ocivolume-oled 20G /var/oled\nCon esto confirmas que:\nSolo 44.5 GB del disco están siendo usados por LVM El resto del disco no está particionado El filesystem raíz (/) no se ha extendido Solución manual con LVM Este procedimiento es seguro, se puede ejecutar en caliente y no requiere reinicio.\n1. Extender la partición del disco sudo growpart /dev/sda 3 Extiende sda3 para usar todo el espacio libre del disco.\n2. Redimensionar el Physical Volume (PV) sudo pvresize /dev/sda3 Ahora LVM puede \u0026ldquo;ver\u0026rdquo; el nuevo espacio disponible.\n3. Extender el Logical Volume raíz sudo lvextend -l +100%FREE /dev/mapper/ocivolume-root Asigna todo el espacio libre al volumen lógico raíz (/).\n4. Extender el filesystem (XFS) Oracle Linux usa XFS por defecto:\nsudo xfs_growfs / Tip: Oracle también ofrece una utilidad propia, oci-growfs (incluida en el paquete oci-utils, preinstalado en las imágenes estándar de Oracle Linux), que ejecuta estos cuatro pasos en uno solo:\nsudo /usr/libexec/oci-growfs -y Funciona bien para el caso típico de un único volumen físico (PV) en el volume group. Si tu setup es más particular —por ejemplo, varios PVs en el mismo VG— el método manual de arriba te da más control y entendimiento de qué está pasando en cada capa.\nVerificación final df -h El filesystem raíz (/) debería mostrar ahora un tamaño cercano a 80–90 GB, dependiendo del espacio reservado para swap y /var/oled.\nConclusiones y buenas prácticas Este comportamiento no es un error: es el diseño normal de OCI. Oracle Linux en OCI usa LVM por defecto. Revisa lsblk justo después de crear una instancia para saber si necesitas extender particiones. Si vas a aumentar el boot volume más adelante, repite el proceso (manual o con oci-growfs). Mantén intacto /var/oled: es el volumen reservado para diagnóstico (Oracle Linux Enhanced Diagnostics), usado por OCI y por el soporte de Oracle Linux para crash dumps y herramientas de diagnóstico. ","permalink":"https://mauromejia.com/posts/espacio-disco-oci/","summary":"\u003cp\u003eSigo trabajando con instancias en \u003cstrong\u003eOracle Cloud Infrastructure (OCI)\u003c/strong\u003e, en mi caso instancias \u003cstrong\u003eARM (Ampere A1)\u003c/strong\u003e dentro del \u003cem\u003eFree Tier\u003c/em\u003e. Una de ellas quedó configurada así:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eSistema operativo:\u003c/strong\u003e Oracle Linux\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCPU:\u003c/strong\u003e 2 cores\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRAM:\u003c/strong\u003e 12 GB\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eBoot Volume:\u003c/strong\u003e 100 GB\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAl revisar el sistema, el espacio disponible en disco era de apenas \u003cstrong\u003e~50 GB\u003c/strong\u003e, aunque el volumen asignado era de 100 GB. En este artículo explico por qué pasa esto y cómo solucionarlo.\u003c/p\u003e","title":"Por qué el espacio de tu instancia de Oracle Cloud (OCI) \"desaparece\""},{"content":"Cómo preparé mi entorno de nube en Colombia Hace poco di el paso de crear una nueva cuenta (tenant) en Oracle Cloud Infrastructure (OCI). Lo interesante es que, por primera vez, estoy desplegando recursos directamente en la región Colombia Central (Bogotá).\nMi objetivo no es migrar todo mi laboratorio a la nube —sigo siendo fiel a mi Home Lab local, mi Intel NUC—, sino apostar por un enfoque híbrido: la latencia mínima de tener la nube \u0026ldquo;en casa\u0026rdquo; combinada con la potencia de la infraestructura de Oracle.\nUna de las grandes motivaciones para usar OCI son sus instancias Always Free, especialmente las basadas en procesadores ARM (Ampere). Ofrecen hasta 4 OCPUs y 24 GB de RAM\n[NOTA: desde mediados de 2026 Oracle redujo este límite. La documentación oficial de Always Free Resources ahora indica 2 OCPUs y 12 GB de RAM en total para Ampere A1 (1.500 horas de OCPU y 9.000 GB-hora al mes), la mitad de lo que se ofrecía antes. Hay reportes de usuarios de pago (Pay As You Go) que siguen viendo 4 OCPUs/24 GB sin costo, pero la documentación vigente solo garantiza 2/12 GB para cuentas Always Free. Vale la pena que verifiques tu cupo actual en la consola antes de planear el tamaño de tu instancia].\nSin embargo, como consultor de seguridad sé que la nube no es segura por defecto: no se trata de lanzar una máquina virtual y empezar a instalar cosas sin más.\nAntes de desplegar mi primera instancia me obligué a frenar, leer la documentación oficial y estructurar el tenant correctamente. Aquí te comparto el resumen de los 6 pasos de preparación y seguridad que aplicué antes de tocar una sola máquina virtual.\n1. Define tu plan de organización (no uses el \u0026ldquo;root\u0026rdquo; para todo) La tentación de crear todo en el compartimento raíz (root compartment) es grande, pero es mala práctica. La documentación de Oracle es clara en esto: necesitas estructura.\nLo primero que hice fue definir una jerarquía de compartimentos. Piénsalos como carpetas lógicas para aislar recursos.\nMi estrategia: creé compartimentos separados según el propósito —por ejemplo, un \u0026ldquo;Sandbox\u0026rdquo; para pruebas destructivas y otro para servicios estables. ¿Por qué? Facilita la administración y, sobre todo, la seguridad. Si un script se vuelve loco en el entorno de pruebas, no toca los recursos estables. 2. Gestión de identidad (IAM): el principio de mínimo privilegio Aunque soy el dueño de la cuenta, operar siempre como \u0026ldquo;administrador supremo\u0026rdquo; es un riesgo innecesario.\nConfiguré el IAM (Identity and Access Management) siguiendo el principio de segregación de funciones:\nCreé grupos específicos (Administradores, Operadores de Red, Seguridad). Evité las políticas genéricas. En lugar de dar acceso a todo, diseñé políticas que permiten solo lo necesario. Consejo: nunca compartas usuarios. Incluso en un laboratorio personal, acostúmbrate a crear usuarios nominales y asignarlos a grupos, nunca a dar permisos directos al usuario.\n3. Redes y conectividad: planificando la VCN Antes de pensar en servidores hay que pensar en carreteras. En OCI eso es la VCN (Virtual Cloud Network).\nAl crear mi VCN en la región de Bogotá tuve que decidir el diseño de las subredes. Aunque es un laboratorio, separar lo público de lo privado es vital:\nSubredes públicas: para recursos que necesitan salir o recibir tráfico de internet (con sus respectivos Internet Gateways). Subredes privadas: para bases de datos o servicios internos que no deben quedar expuestos. Aquí también entran los Security Lists y los Network Security Groups (NSG). Configuré reglas de firewall estrictas desde el inicio —nada de 0.0.0.0/0 abierto al puerto 22 para todo el mundo.\n4. Etiquetas y gobernanza de costos (cuidado con la tarjeta) Aunque busquemos aprovechar la capa gratuita, las sorpresas en la facturación llegan si no tenemos cuidado: volúmenes de almacenamiento huérfanos, tráfico de salida que se nos pasa de la mano, etc.\nPara mitigar esto en mi nueva región:\nTagging: definí un esquema de etiquetas para saber qué recurso pertenece a qué proyecto (por ejemplo, Entorno: Pruebas). Budgets: configuré un presupuesto con alerta de consumo. Mi intención es gastar $0, pero quiero un correo si mi consumo proyectado supera los $10 USD. Mejor una alerta temprana que una factura inesperada a fin de mes. 5. Seguridad base y la cuenta \u0026ldquo;break-glass\u0026rdquo; Más allá de los firewalls, hay configuraciones a nivel de tenant que no se pueden ignorar:\nCloud Audit: verifiqué que el servicio de auditoría esté registrando los eventos. Necesito saber qué pasó, cuándo y quién lo hizo. Cuenta de emergencia (break-glass): siguiendo las guías de administración, configuré una cuenta de acceso de emergencia. Es un usuario con permisos máximos que se mantiene aislado, con una contraseña extremadamente compleja, para usar solo si pierdo el acceso a mi federación de identidad o a mis usuarios principales. 6. Revisión de límites de servicio (Service Limits) Finalmente, antes de emocionarme lanzando la VM, fui a la consola a revisar los Service Limits para la región de Bogotá.\nNo hay nada más frustrante que configurar toda la red y, al momento de crear la instancia, recibir un error de \u0026ldquo;límite excedido\u0026rdquo;. Verifiqué que mi tenancy tuviera capacidad disponible —cupo de CPUs ARM y memoria— para lo que planeaba desplegar.\n¿Qué sigue? Con estos 6 pasos, mi entorno en Oracle Cloud quedó listo, seguro y organizado. Ya no es un terreno baldío, sino una base sólida para empezar a construir.\nEn la próxima entrada paso a la acción: te muestro cómo desplegué mi primera máquina virtual, los comandos que usé para actualizar el sistema operativo y qué servicios base instalé para dejarla 100% operativa.\n¡Nos leemos en el siguiente post!\n","permalink":"https://mauromejia.com/posts/oci-aseguramiento-inicial/","summary":"\u003ch2 id=\"cómo-preparé-mi-entorno-de-nube-en-colombia\"\u003eCómo preparé mi entorno de nube en Colombia\u003c/h2\u003e\n\u003cp\u003eHace poco di el paso de crear una nueva cuenta (tenant) en Oracle Cloud Infrastructure (OCI). Lo interesante es que, por primera vez, estoy desplegando recursos directamente en la región Colombia Central (Bogotá).\u003c/p\u003e\n\u003cp\u003eMi objetivo no es migrar todo mi laboratorio a la nube —sigo siendo fiel a mi Home Lab local, mi Intel NUC—, sino apostar por un enfoque híbrido: la latencia mínima de tener la nube \u0026ldquo;en casa\u0026rdquo; combinada con la potencia de la infraestructura de Oracle.\u003c/p\u003e","title":"Estrenando la Región Bogotá en Oracle Cloud: Aseguramiento Inicial"}]