Conceptos

Prácticas DevOps

Conjunto de prácticas técnicas y culturales que implementan los principios DevOps — desde Infrastructure as Code hasta blameless post-mortems. El «cómo» detrás de la filosofía.

evergreen#devops#practices#automation#sre

Las prácticas DevOps son las implementaciones concretas de la filosofía DevOps. Mientras DevOps es el «qué» y el «por qué», estas prácticas son el «cómo».

Infrastructure as Code (IaC)

Definir y gestionar infraestructura mediante archivos de configuración versionados.

Herramientas principales

HerramientaEnfoqueLenguaje
TerraformMulti-cloud, declarativoHCL
PulumiMulti-cloud, imperativoTypeScript, Python, Go
AWS CDKAWS, imperativoTypeScript, Python, Java
CloudFormationAWS, declarativoYAML/JSON
AnsibleConfiguración, agentlessYAML

Ejemplo Terraform

resource "aws_s3_bucket" "data" {
  bucket = "my-data-bucket"
  
  versioning {
    enabled = true
  }
  
  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm = "AES256"
      }
    }
  }
}

Principios IaC

  • Idempotencia — aplicar múltiples veces produce el mismo resultado
  • Versionado — toda la infra en Git con historial completo
  • Review — cambios de infra pasan por PR como código
  • Módulos — reutilizar patrones comunes
  • State management — estado remoto compartido (S3, Terraform Cloud)

Configuration Management

Mantener servidores en un estado deseado de forma automatizada.

# Ansible playbook
- hosts: webservers
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present
    
    - name: Copy config
      template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: restart nginx
  
  handlers:
    - name: restart nginx
      service:
        name: nginx
        state: restarted

Containerization

Empaquetar aplicaciones con todas sus dependencias.

# Multi-stage build
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
 
FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
EXPOSE 3000
CMD ["node", "dist/index.js"]

Mejores prácticas Docker

  • Imágenes base mínimas (Alpine, distroless)
  • Multi-stage builds para reducir tamaño
  • Un proceso por contenedor
  • No correr como root
  • .dockerignore para excluir archivos innecesarios
  • Pinear versiones de imágenes base

GitOps

Usar Git como fuente de verdad para infraestructura y deployments.

Principios

  1. Declarativo — el estado deseado está en Git
  2. Versionado — Git es el historial de cambios
  3. Automático — agentes reconcilian el estado real con el deseado
  4. Auditable — cada cambio tiene autor, timestamp y razón

Herramientas

  • ArgoCD — Kubernetes GitOps controller
  • Flux — Kubernetes GitOps toolkit
  • Atlantis — Terraform pull request automation
# ArgoCD Application
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  source:
    repoURL: https://github.com/org/repo
    path: k8s/
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Feature Flags

Separar deployment de release — código en producción pero funcionalidad controlada.

// Ejemplo con LaunchDarkly / Unleash / custom
if (featureFlags.isEnabled('new-checkout', { userId })) {
  return <NewCheckout />;
}
return <LegacyCheckout />;

Casos de uso

  • Canary releases — habilitar para % de usuarios
  • Beta testing — habilitar para usuarios específicos
  • Kill switch — deshabilitar feature problemática sin deploy
  • A/B testing — comparar variantes
  • Trunk-based development — mergear código incompleto

Observability

Los tres pilares para entender sistemas en producción:

Logs

{
  "timestamp": "2024-01-15T10:30:00Z",
  "level": "error",
  "service": "api",
  "trace_id": "abc123",
  "message": "Payment failed",
  "user_id": "user_456",
  "error_code": "INSUFFICIENT_FUNDS"
}

Structured logging — JSON parseable, no texto libre.

Metrics

# Prometheus format
http_requests_total{method="GET", status="200"} 1234
http_request_duration_seconds{quantile="0.99"} 0.25

Tipos: counters, gauges, histograms, summaries.

Traces

Seguir una request a través de múltiples servicios:

[API Gateway] → [Auth Service] → [User Service] → [Database]
     2ms            5ms              3ms            10ms

Herramientas: Jaeger, Zipkin, AWS X-Ray, Datadog APM.

Incident Management

On-call

  • Rotaciones definidas (PagerDuty, Opsgenie)
  • Runbooks para incidentes comunes
  • Escalation paths claros
  • Compensación por on-call

Incident response

  1. Detect — alertas, usuarios, monitoring
  2. Triage — severidad, impacto, quién responde
  3. Mitigate — restaurar servicio (rollback, scale, failover)
  4. Resolve — fix permanente
  5. Learn — post-mortem

Severities

SevImpactoResponse timeEjemplo
1Servicio caídoInmediatoSitio no carga
2Degradación mayor< 30 minPagos fallan
3Degradación menor< 4 horasFeature secundaria rota
4Bajo impactoSiguiente día hábilBug cosmético

Chaos Engineering

Inyectar fallos controlados para descubrir debilidades.

Principios

  1. Definir «estado estable» (métricas normales)
  2. Hipótesis: el sistema tolera X fallo
  3. Introducir variables del mundo real (latencia, fallos, particiones)
  4. Intentar refutar la hipótesis
  5. Minimizar blast radius

Herramientas

  • Chaos Monkey — termina instancias aleatorias
  • Gremlin — plataforma de chaos engineering
  • Litmus — chaos engineering para Kubernetes
  • AWS Fault Injection Simulator — chaos nativo en AWS

Security Practices (DevSecOps)

Integrar seguridad en todo el pipeline:

Shift left

  • SAST — análisis estático de código (SonarQube, Semgrep)
  • SCA — análisis de dependencias (Snyk, Dependabot)
  • Secret scanning — detectar credenciales en código
  • Container scanning — vulnerabilidades en imágenes (Trivy)

Runtime

  • DAST — testing dinámico de aplicaciones
  • WAF — firewall de aplicaciones web
  • Runtime protection — detectar comportamiento anómalo

¿Por qué importa?

Estas prácticas no son opcionales para equipos que operan software en producción. Cada una reduce un tipo específico de riesgo: IaC elimina la configuración manual, los feature flags desacoplan deploy de release, la observabilidad convierte incidentes en aprendizaje. Adoptarlas incrementalmente es más efectivo que intentar implementar todo a la vez.

Referencias

Conceptos