Construyendo un Toolkit de IT

Como técnico de soporte, mi objetivo es simple: resolver problemas de forma rápida, eficiente y documentada. Los scripts sueltos no eran suficientes. Necesitaba un sistema cohesivo y profesional. Este es el desglose técnico de cómo construí IT-Support-Scripts desde cero.

Filosofía Central: Modularidad y Reportes Profesionales

Desde el inicio, establecí dos pilares no negociables para la arquitectura del proyecto:

1. Modularidad Absoluta: Cada script debía ser una herramienta autónoma y especializada. Un diagnostico_red.ps1 para la red, un inventario_hw_sw.ps1 para el hardware. Esto permite ejecutar solo lo necesario y facilita el mantenimiento y la expansión del código.

2. El Reporte es el Producto Final: La salida en consola es para mí, pero el reporte HTML es para el cliente (o para mi yo del futuro). Por eso, HTMLTemplate.ps1 se convirtió en el componente central. Su función es desacoplar la lógica de diagnóstico de la presentación, garantizando que todos los scripts generen un output estandarizado, profesional y, sobre todo, útil.

Decisiones de Arquitectura Clave

El Orquestador: master_script.ps1

No quería una simple colección de archivos, sino un sistema integrado. master_script.ps1 funciona como el orquestador principal.

• Punto de Entrada Único: Ofrece un menú interactivo que sirve como una API humana para todo el toolkit. Esto elimina la necesidad de memorizar nombres de archivos y parámetros.
• Gestión de Entorno: Se encarga de la configuración crítica, como ajustar la política de ejecución de PowerShell (Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass), un obstáculo común en entornos de cliente.
• Verificación de Dependencias: Antes de mostrar el menú, valida que todos los scripts necesarios existan, previniendo fallos en tiempo de ejecución.

Gestión de Errores Robusta: ErrorHandler.ps1

Un script que falla silenciosamente es inútil. Implementé un manejador de errores centralizado en ErrorHandler.ps1 para garantizar la resiliencia del sistema.

• Invoke-SafeExecution: Este es el núcleo del manejo de errores. Es una función wrapper que ejecuta bloques de código en un try/catch. Si una operación (como una consulta WMI) falla, el error se captura, se registra en un log global y el script principal continúa su ejecución en lugar de detenerse.
• Clasificación de Severidad: Los errores se categorizan como Info, Warning, Error o Critical. Esto es crucial para priorizar problemas en el reporte HTML final, permitiendo al técnico enfocarse inmediatamente en lo más importante.

El Producto Final: Reportes HTML Dinámicos

El objetivo era simple: un técnico ejecuta un script y obtiene un reporte diagnostico_completo_2025-08-17_21-35-30.html listo para ser analizado o enviado.

• CSS Unificado: Todo el estilo reside en la plantilla. Esto significa que puedo cambiar el diseño de todos los reportes modificando un solo archivo.
• Resúmenes Visuales: La parte superior de cada reporte muestra contadores de problemas (goodCount, warningCount, criticalCount). Estos se rellenan mediante un pequeño bloque de JavaScript que se inyecta al final del HTML, ofreciendo un resumen visual inmediato del estado del sistema.
• Clasificación por Colores: Las clases CSS .good, .warning, y .critical se aplican dinámicamente a las filas y secciones del reporte, traduciendo datos técnicos en un sistema de alertas visual e intuitivo.

La Visión a Futuro: Un Toolkit Universal

PowerShell en Windows fue el punto de partida, pero la meta es mucho más ambiciosa. El ROADMAP.md lo deja claro: evolucionar hacia una solución verdaderamente multiplataforma y portable.

La estrategia implica migrar la lógica a un core en Node.js y WebAssembly, empaquetado con Electron.js. Esto permitirá ejecutar el mismo toolkit desde una USB en Windows, macOS o Linux, sin dependencias ni instalación.

Este proyecto es la materialización de mi filosofía como técnico: las herramientas no solo deben ser funcionales, sino también rápidas, confiables y profesionales.