Modulo 01. Mentalidad de automatizacion y tipos de tareas

Objetivo del modulo

Aprender a decidir que tareas conviene automatizar, con que alcance y bajo que controles para no convertir un problema manual pequeno en un problema automatico mucho mayor.

Resultados esperados

• Identificar tareas repetitivas, manuales o propensas a error.
• Diferenciar automatizacion puntual, recurrente e integrada.
• Entender idempotencia, seguridad y observabilidad en scripts.
• Aplicar criterio antes de escribir codigo.

Desarrollo teorico

Automatizar no es simplemente ahorrar tiempo. Una automatizacion bien elegida reduce errores, acelera operaciones y libera capacidad humana para tareas de mayor valor. Una automatizacion mal elegida replica el error manual a gran velocidad o anade riesgo sobre sistemas sensibles. Por eso el primer paso no es elegir Bash o PowerShell, sino clasificar la tarea.

Clasificacion de tareas candidatas. Las tareas candidatas claras para automatizacion son las que cumplen varias de estas caracteristicas:

• Repetitivas: Se ejecutan con frecuencia (diaria, semanal, ante eventos).
• Pasos estables: El procedimiento no cambia significativamente entre ejecuciones.
• Datos estructurados: La entrada y salida son predecibles y parseables.
• Resultado verificable: Se puede confirmar exito o fallo de forma objetiva.
• Bajo riesgo de daño irreversible: O se puede mitigar con simulacion y confirmacion.

Menos apropiadas para automatizacion inmediata son las tareas altamente ambiguas, con decisiones humanas complejas que requieren juicio contextual, o con impacto destructivo si falla una suposicion no validada.

Ejemplos concretos por categoria:

BUENAS CANDIDATAS:
- Renombrar cientos de archivos segun patron
- Consultar estado de servicios en N servidores
- Validar configuraciones contra una baseline
- Desplegar un paquete en entornos de test
- Recoger inventario de software instalado
- Limpiar logs antiguos segun politica de retencion

CANDIDATAS CON PRECAUCION:
- Reiniciar servicios en produccion
- Modificar configuraciones de red
- Crear/eliminar cuentas de usuario
- Aplicar parches en servidores criticos

MALAS CANDIDATAS (sin mas contexto):
- Diagnosticar incidentes no tipificados
- Aprobar cambios que requieren juicio de negocio
- Tareas que cambian completamente cada vez

Los tres niveles de automatizacion.

1. Script ad-hoc: Se escribe para resolver una necesidad puntual. Se ejecuta una vez (o pocas) y puede no mantenerse. Es el primer nivel y el mas fragil. Ejemplo: un script Bash para migrar ficheros de un directorio a otro durante una migracion.

2. Automatizacion recurrente: Script o tarea programada que se ejecuta periodicamente. Requiere mas robustez: validacion de entradas, manejo de errores, logging, idempotencia. Ejemplo: un cron job que limpia logs mayores de 30 dias.

3. Automatizacion integrada: Forma parte de un flujo mayor (pipeline CI/CD, orquestador, runbook de incidentes). Requiere contratos claros de entrada/salida, observabilidad, versionado y testing. Ejemplo: un script que forma parte del deploy automatizado en un pipeline.

Idempotencia. Un script idempotente produce el mismo resultado si se ejecuta una vez o multiples veces. Esto es critico para automatizacion recurrente. Si un script crea un directorio sin verificar si existe, falla en la segunda ejecucion. Si un script anade una linea a un fichero sin comprobar si ya esta, duplica contenido.

# NO idempotente: falla si el directorio ya existe
mkdir /opt/app/logs

# Idempotente: crea solo si no existe
mkdir -p /opt/app/logs

# NO idempotente: anade duplicados
Add-Content -Path config.txt -Value "MaxRetries=3"

# Idempotente: solo anade si no existe
$contenido = Get-Content config.txt
if ($contenido -notcontains "MaxRetries=3") {
    Add-Content -Path config.txt -Value "MaxRetries=3"
}

Dry run y simulacion. Antes de ejecutar una accion destructiva o masiva, un script bien disenado ofrece un modo de simulacion que muestra lo que haria sin hacerlo:

#!/usr/bin/env bash
set -euo pipefail

DRY_RUN="${DRY_RUN:-true}"

eliminar_logs_antiguos() {
    local directorio="$1"
    local dias="$2"

    find "$directorio" -name "*.log" -mtime +"$dias" -print |
    while IFS= read -r archivo; do
        if [[ "$DRY_RUN" == "true" ]]; then
            echo "[DRY RUN] Eliminaria: $archivo"
        else
            rm "$archivo"
            echo "[OK] Eliminado: $archivo"
        fi
    done
}

eliminar_logs_antiguos "/var/log/app" 30

Observabilidad. Todo script operativo debe dejar rastro de lo que hizo. Eso significa: logging a fichero o a stdout/stderr con timestamps, codigos de salida correctos (0 = exito, distinto de 0 = fallo), y opcionalmente metricas o notificaciones. Un script que ejecuta acciones silenciosamente es imposible de auditar y de diagnosticar cuando falla.

Control de errores. Los scripts robustos anticipan fallos y los manejan de forma explicita:

# Si falla la conexion, notificar y salir
if ! ping -c1 -W3 "$servidor" >/dev/null 2>&1; then
    echo "ERROR: $servidor no alcanzable" >&2
    exit 1
fi

try {
    $resultado = Invoke-Command -ComputerName $servidor -ScriptBlock { Get-Service }
} catch {
    Write-Error "No se pudo conectar a $servidor: $_"
    exit 1
}

Matriz de decision. Antes de automatizar, responde estas preguntas:

Contenido ampliado

Puntos clave

• No toda tarea repetitiva merece automatizacion inmediata; hay que evaluar riesgo y estabilidad.
• El riesgo operativo importa tanto como el ahorro de tiempo.
• Una automatizacion segura necesita validacion, simulacion y control de errores.
• Repetibilidad e idempotencia son atributos centrales de un script maduro.
• Los tres niveles (ad-hoc, recurrente, integrado) tienen requisitos de robustez diferentes.
• La observabilidad no es opcional: un script silencioso es un script peligroso.

Checklist operativa

• Definir entrada, salida y criterios de exito antes de escribir codigo.
• Evaluar impacto si el script falla o se repite accidentalmente.
• Decidir si hace falta modo dry run o simulacion.
• Implementar logging con timestamps y codigos de salida correctos.
• Validar parametros de entrada al inicio del script.
• Documentar prerequisitos y dependencias del script.

Errores frecuentes

• Automatizar sin entender del todo el proceso manual subyacente.
• No validar parametros de entrada y asumir datos perfectos.
• Hacer scripts destructivos sin confirmacion ni simulacion previa.
• Confundir velocidad con calidad operativa.
• No dejar registro (logging) de lo ejecutado.
• Crear scripts ad-hoc y tratarlos como automatizacion permanente sin refactorizar.

Practica sugerida

Selecciona tres tareas reales de tu dia a dia y clasificalas en una tabla con columnas: tarea, frecuencia, estabilidad de pasos, riesgo si falla, nivel de automatizacion recomendado (ad-hoc / recurrente / integrado). Para la tarea mas adecuada, escribe el pseudocodigo de un script que incluya validacion de entrada, dry run, ejecucion, logging y codigo de salida.

Preguntas de autoevaluacion

• Que caracteristicas hacen a una tarea buena candidata para automatizacion.
• Por que la idempotencia cambia la confianza en un script recurrente.
• Cuando conviene implementar dry run y que valor aporta.
• Que diferencia hay entre un script ad-hoc y una automatizacion integrada.
• Por que un script que ejecuta acciones sin logging es un riesgo operativo.

Cierre

La mejor automatizacion empieza antes del codigo: entendiendo el proceso, evaluando el riesgo y definiendo la evidencia que confirmara que el resultado es correcto. Solo entonces tiene sentido elegir la herramienta y escribir la primera linea.

Modulo 02. Bash: comandos, variables y flujo

Objetivo del modulo

Usar Bash para encadenar comandos, trabajar con variables, condicionales y bucles, y automatizar tareas comunes en entornos Unix/Linux.

Resultados esperados

• Escribir scripts Bash simples y ejecutables.
• Usar variables, argumentos y expansion de shell.
• Aplicar if, case, for y while.
• Entender el pipeline textual y los codigos de salida.

Desarrollo teorico

Bash es una shell orientada a composicion de comandos y manipulacion de texto. Su fortaleza no es modelar objetos complejos sino orquestar utilidades del sistema como grep, awk, sed, find, cut, sort o xargs. Precisamente por eso resulta tan potente en automatizacion operativa: aprovecha herramientas pequenas que hacen bien una tarea concreta y las compone mediante pipes.

Estructura basica de un script. Todo script Bash serio comienza con un shebang y opcionalmente con opciones de endurecimiento:

#!/usr/bin/env bash
set -euo pipefail

# -e: salir si un comando falla
# -u: error si se usa variable no definida
# -o pipefail: el pipe falla si cualquier comando falla

set -euo pipefail es la primera linea de defensa contra scripts fragiles. Sin ella, un comando que falle silenciosamente deja al script continuar con datos corruptos o incompletos. En automatizacion operativa, un fallo silencioso es mucho peor que un fallo ruidoso.

Variables y argumentos. Las variables en Bash se asignan sin espacios y se referencian con $:

nombre="servidor-web-01"
entorno="produccion"
echo "Desplegando en $nombre ($entorno)"

Los argumentos posicionales son $1, $2, etc. $@ representa todos los argumentos, $# el numero de argumentos y $? el codigo de salida del ultimo comando:

#!/usr/bin/env bash
set -euo pipefail

if [ $# -lt 1 ]; then
    echo "Uso: $0 <directorio>" >&2
    exit 1
fi

directorio="$1"
echo "Procesando: $directorio"

El quoting es critico en Bash. Las comillas dobles permiten expansion de variables pero protegen contra word splitting. Sin comillas, un nombre de archivo con espacios rompe el script:

# MAL: falla si $archivo contiene espacios
cat $archivo

# BIEN: protege contra word splitting
cat "$archivo"

Condicionales. Bash ofrece if, elif, else y case. Para comparar cadenas se usa [[ ]] (preferible a [ ] por ser mas robusto):

#!/usr/bin/env bash
set -euo pipefail

estado=$(systemctl is-active nginx)

if [[ "$estado" == "active" ]]; then
    echo "Nginx esta activo"
elif [[ "$estado" == "inactive" ]]; then
    echo "Nginx esta detenido, arrancando..."
    systemctl start nginx
else
    echo "Estado desconocido: $estado" >&2
    exit 1
fi

Para comparar numeros se usan -eq, -ne, -lt, -gt, -le, -ge:

if [[ $# -lt 2 ]]; then
    echo "Se requieren al menos 2 argumentos"
    exit 1
fi

case es util para multiples opciones:

case "$1" in
    start)  systemctl start "$servicio" ;;
    stop)   systemctl stop "$servicio" ;;
    status) systemctl status "$servicio" ;;
    *)      echo "Uso: $0 {start|stop|status}" >&2; exit 1 ;;
esac

Bucles. for itera sobre listas y while repite mientras se cumpla una condicion:

# Iterar sobre archivos .log
for archivo in /var/log/*.log; do
    lineas=$(wc -l < "$archivo")
    echo "$archivo: $lineas lineas"
done

# Leer linea a linea
while IFS= read -r linea; do
    echo "Procesando: $linea"
done < entrada.txt

Pipeline textual. El pipe (|) conecta la salida de un comando con la entrada del siguiente. Cada comando transforma el flujo de texto:

# Buscar procesos de nginx, contar y mostrar
ps aux | grep nginx | grep -v grep | wc -l

# Encontrar los 10 directorios mas grandes
du -sh /var/* 2>/dev/null | sort -rh | head -10

# Extraer IPs unicas de un log de acceso
awk '{print $1}' /var/log/nginx/access.log | sort -u | head -20

Codigos de salida. Todo comando en Unix devuelve un codigo de salida: 0 es exito, cualquier otro valor es error. Los codigos de salida son parte del contrato operativo del script. Un script bien disenado devuelve 0 al terminar correctamente y un codigo distinto de 0 al fallar:

#!/usr/bin/env bash
set -euo pipefail

verificar_servicio() {
    local servicio="$1"
    if systemctl is-active --quiet "$servicio"; then
        echo "OK: $servicio activo"
        return 0
    else
        echo "ERROR: $servicio no esta activo" >&2
        return 1
    fi
}

verificar_servicio nginx
verificar_servicio postgresql
echo "Todos los servicios verificados"

Redireccion. > redirige stdout a un fichero (sobreescribe), >> anade, 2> redirige stderr, 2>&1 combina stderr con stdout, /dev/null descarta salida:

# Log de errores separado
comando_importante 2>errores.log

# Descartar salida, solo interesa el codigo de retorno
ping -c1 servidor.local >/dev/null 2>&1 && echo "Alcanzable" || echo "No alcanzable"

Contenido ampliado

Puntos clave

• Bash brilla en tareas de sistema y composicion de comandos pequenos.
• El pipeline mueve texto; eso exige cuidar quoting y parsing de formatos.
• Los codigos de salida son parte del contrato operativo del script.
• set -euo pipefail es obligatorio en scripts serios de automatizacion.
• Un shell script robusto valida argumentos y falla de forma comprensible.
• Las comillas dobles alrededor de variables previenen la mayoria de bugs sutiles.

Checklist operativa

• Anadir shebang correcto y set -euo pipefail.
• Citar variables entre comillas dobles cuando proceda.
• Validar numero y tipo de argumentos al inicio del script.
• Revisar codigos de salida criticos de comandos encadenados.
• Probar con nombres de archivo que contengan espacios y caracteres especiales.
• Incluir mensajes de error descriptivos dirigidos a stderr.

Errores frecuentes

• No citar variables y sufrir errores con nombres que contienen espacios.
• Parsear salida humana inestable de comandos en vez de opciones de formato maquina.
• Ignorar el valor de $? y no verificar si un comando critico fallo.
• Usar bucles complejos donde una utilidad como awk, xargs o find -exec resolveria mejor.
• No usar set -euo pipefail y dejar que fallos pasen desapercibidos.
• Redirigir mensajes de error a stdout en vez de a stderr.

Practica sugerida

Crea un script Bash llamado resumen_logs.sh que reciba una carpeta como argumento, localice todos los archivos .log, cuente las lineas de cada uno, genere un resumen ordenado por tamano (de mayor a menor) y exporte el resultado a un fichero CSV. El script debe validar que el argumento es un directorio existente, usar set -euo pipefail y devolver un codigo de salida apropiado.

Preguntas de autoevaluacion

• Que diferencia hay entre el pipeline textual de Bash y el pipeline de objetos de PowerShell.
• Por que las comillas dobles importan tanto en Bash y que pasa si se omiten.
• Que problema ayuda a evitar set -euo pipefail y por que cada flag es necesaria.
• Cuando conviene usar case en lugar de multiples if/elif.
• Por que un codigo de salida distinto de 0 es parte del contrato del script.

Cierre

Bash es extremadamente util cuando se respeta su modelo: comandos pequenos que hacen una cosa bien, texto controlado con quoting adecuado y errores que se detectan y comunican de forma explicita.