Adopción de la automatización como código: el paso de la infraestructura como código a la política como código

Las empresas han comenzado a utilizar las prácticas de la infraestructura como código (IaC) como base estratégica para automatizar los procesos de TI en todas las etapas del ciclo de vida operativo. Del mismo modo que la IaC permite estandarizar el diseño, la preparación y la implementación de la infraestructura, con las operaciones como código (OaC), los equipos de TI pueden codificar la gestión y el mantenimiento de los sistemas después de su implementación. Luego, este enfoque puede ampliarse a la política como código (PaC) a fin de automatizar los procesos de control, riesgo y cumplimiento de las aplicaciones y las soluciones.

Los equipos encargados de las aplicaciones y la infraestructura tienen como objetivo común automatizar los procesos para agilizar la distribución y mejorar la eficiencia; sin embargo, la mayoría de ellos sigue recurriendo a métodos manuales a la hora de llevar a cabo las tareas de control y las operaciones del día 2. Si bien la automatización puede aportar numerosas ventajas en estas áreas, para utilizarla en los procesos del día 2, los equipos consolidados deben aprender a emplear herramientas y métodos nuevos. Las operaciones y las políticas como código simplifican este cambio cultural, ya que parten de la estrategia de IaC ya establecida, lo cual permite que las empresas pongan en práctica en diversas tareas los conocimientos y las herramientas que ya emplean.

Si las empresas siguen los métodos de la IaC, pueden adoptar las OaC y las PaC para codificar las prácticas recomendadas y automatizar las tareas rutinarias de todos los procesos operativos, de manera tal que se pueda lograr una automatización integral. Gracias a estos enfoques de automatización como código, los procesos se ejecutan de manera uniforme y pueden ajustarse. Esto significa que los equipos pueden diseñar y mantener las aplicaciones, la infraestructura y las cargas de trabajo casi sin intervención manual, y que el cumplimiento normativo se mantiene de principio a fin.

Hasta ahora, el diseño y la gestión de la infraestructura de TI, como los servidores, las instancias de nube, los sistemas operativos, el almacenamiento, los equilibradores de carga y otros extremos, eran procesos manuales que llevaban mucho tiempo. No obstante, conforme la infraestructura se organiza en contenedores y en diversas plataformas (desde los centros de datos hasta los entornos multicloud y las ubicaciones en el extremo de la red), parte de ella se implementa como código, sobre todo en la nube.

Cuando la infraestructura se implementa como código, puede ponerse en marcha con mayor rapidez para hacer frente al rápido crecimiento de la demanda y a las necesidades de capacidad de ajuste. Si bien se trata de una ventaja, también ha provocado que la gestión de la infraestructura sea más compleja y urgente, por lo que las empresas suelen tener que prepararla, implementarla y desmontarla a diario. Para mantener el ritmo, los equipos de TI automatizan estos procesos mediante la IaC.

La IaC en detalle 

Este enfoque define, prepara y gestiona la infraestructura con un código que se ejecuta de forma automática. Para ello, se crean archivos de configuración que contienen todas las especificaciones que esta necesita, lo cual facilita la edición y la distribución de las infraestructuras y las instancias de nube que se hayan configurado de forma adecuada. Al codificar y documentar las especificaciones, los equipos evitan que falte documentación sobre los cambios y que estos se realicen de manera desigual, y garantizan que siempre se implemente el mismo entorno.

Si utiliza la IaC para automatizar la infraestructura, los desarrolladores no tendrán que preparar ni gestionar manualmente los elementos que la componen cada vez que desarrollen o implementen una aplicación, lo cual puede mejorar considerablemente la velocidad y la uniformidad y, al mismo tiempo, reducir el tiempo de inactividad y los errores humanos. Además, este enfoque permite que las empresas integren las prácticas recomendadas al código de automatización, de manera tal que cada tarea se ejecute en función de la experiencia compartida de los equipos.

Obtenga más información sobre la automatización de los flujos de trabajo de la infraestructura

Ampliación de la estrategia de la IaC

La transformación de la IaC suponía un desafío para la mayoría de las empresas, ya que llevaba tiempo desarrollar nuevas herramientas e implementar distintas metodologías de trabajo. Sin embargo, los equipos se beneficiaban de este proceso, ya que contaban con la flexibilidad necesaria para elegir las tareas en las que querían centrarse y con mayor agilidad a la hora de responder a los problemas. En la actualidad, existen muchas herramientas de automatización que permiten gestionar la IaC, y los equipos de TI han adoptado este cambio cultural y disfrutan de las numerosas ventajas que ofrece.

A medida que utilizan los métodos y las herramientas establecidos y diseñados para la IaC, comienzan a aplicar el enfoque de automatización como código a otros procesos a lo largo de todo el ciclo de vida operativo, aparte de la preparación, la configuración y la implementación de las aplicaciones. Si bien no hay una definición única del ciclo de vida operativo, suele dividirse en los siguientes días:

• Día 0: Diseño. Se especifican las estructuras para diseñar, configurar y preparar la infraestructura. 
• Día 1: Implementación. Se instala, establece y configura la infraestructura.
• Día 2: Mantenimiento. Se gestionan, mantienen y actualizan los sistemas relacionados con la infraestructura que se implementó.

Mientras que la IaC ofrece una manera uniforme de diseñar y preparar la infraestructura el día 0 y el día 1, las operaciones como código aplican este enfoque a los procesos que tienen lugar el día 2, es decir, la gestión, el mantenimiento y la actualización de los sistemas, que se prolonga hasta que la aplicación o el servicio deban dejar de funcionar.

Tradicionalmente, las tareas del día 2, como supervisar el funcionamiento de los sistemas, instalar actualizaciones y solucionar problemas, se realizaban de forma manual. Si un servidor o una aplicación dejan de funcionar, los equipos de TI suelen recibir una alerta, pero esto no es más que una señal que se debe investigar. A partir de entonces, una persona se encarga de evaluar el problema, para lo cual debe entrar en el equipo físico, buscar la causa y recurrir a otros especialistas de TI para resolverlo. Aunque este tipo de problemas acaban resolviéndose, se trata de un proceso que lleva tiempo, sobre todo si consideramos el alcance que tienen las operaciones de una empresa.

Además, la complejidad de las operaciones del día 2 aumentó tanto como la de las tareas de infraestructura del día 0 y del día 1 y, pese a ello, la automatización no se ha utilizado de forma generalizada para los desafíos del día 2. Aunque muchas empresas adoptaron la IaC para automatizar los procesos del día 0 y del día 1, este mismo enfoque puede aplicarse ahora a las operaciones que abarcan desde los centros de datos y los entornos de nube hasta las implementaciones en el extremo de la red, para reducir el aumento descontrolado de la tecnología y liberar recursos.

Las operaciones como código en detalle

Las operaciones como código son la evolución natural de la IaC. Se basan en aprovechar los conocimientos y la experiencia que los equipos de infraestructura y operaciones adquirieron durante la resolución de problemas, y codificarlos mediante la automatización. De esta manera, el conocimiento sobre las operaciones deja de ser un recurso exclusivo de cada persona dentro de un equipo y se convierte en una herramienta al alcance de todos.

El enfoque de OaC es un proceso mediante el cual se estandariza, codifica y sistematiza el conocimiento operativo y práctico que tienen los equipos acerca de las operaciones del día 2. Para adoptar este enfoque, las empresas deben:

• Estandarizar el uso de una base de código común en toda la empresa para mejorar la uniformidad operativa.
• Codificar el conocimiento operativo e incorporar las prácticas recomendadas a los procesos automatizados. 
• Sistematizar las distintas herramientas y procesos en un enfoque integrado y completo.

El conocimiento práctico del día 2 se convierte en código, por tanto, se puede ejecutar de forma automática a medida que los sistemas se vuelven cada vez más inteligentes, complejos e interdependientes.

Como ocurre con todos los usos de la automatización, el objetivo de las operaciones como código no es remplazar a las personas, sino permitir que los equipos dejen de realizar tantas tareas manuales tediosas y centren su atención en proyectos innovadores. Dado que este método aúna los conocimientos de los equipos en enfoques compartidos, también favorece la colaboración entre diversos modelos operativos y estructuras de equipo.

La incorporación de los métodos de IaC y OaC a las tareas de control puede ayudar a los equipos de TI a prescindir de los procesos extensos y basados en solicitudes, en especial cuando se trata de aplicar políticas: reglas, condiciones o instrucciones cuya finalidad es garantizar que las operaciones se adhieran a los requisitos de cumplimiento, las prácticas recomendadas y las directivas empresariales. 

Una vez que la infraestructura y las operaciones se definen y gestionan como código, los equipos de seguridad y cumplimiento pueden emplear las mismas estrategias para aplicarle políticas y estandarizar la forma en que gestionan los procesos de control, con un enfoque de política como código.

No basta con automatizar los procesos para garantizar el cumplimiento y el control desde el primer momento; es necesario aplicar políticas uniformes para asegurarse de que la IaC y las OaC se ejecuten de forma adecuada en todas las etapas del ciclo de vida operativo. Por lo general, se utilizan los siguientes métodos de control:

• La incorporación de instancias de aprobación a los flujos de trabajo que dificultan la posibilidad de ofrecer soluciones específicas.
• La implementación de permisos de seguridad restrictivos a través del control de acceso basado en funciones (RBAC) o el control de acceso basado en atributos (ABAC), que especifican las personas autorizadas a modificar cada tecnología de una manera en particular, en determinadas condiciones o con una serie de características concretas.

Estos métodos manuales pueden dar lugar a errores y llevar mucho tiempo. Por ello, el objetivo de la política como código es automatizar estos procesos. Por ejemplo, es posible configurar la automatización para evitar que el personal de TI cree una instancia en la nube que no cumpla con los estándares de la empresa o que proporcione un código sin respetar los requisitos de cumplimiento. Aunque los mecanismos de RBAC y ABAC siguen siendo necesarios, las PaC permiten crear un proceso mucho más detallado y automatizado que determina las acciones que se pueden llevar a cabo y el momento en que se ejecutan.

Las políticas como código en detalle

Las estrategias de la PaC son similares a las de la IaC y las OaC. Estas consisten en codificar las políticas y los requisitos de seguridad para automatizar el cumplimiento, lo cual permite incorporar estándares a todos los procesos y aplicarlos de manera uniforme en todos los equipos. Al definir, actualizar, compartir y aplicar las políticas mediante código, el control se realiza desde un solo lugar, lo cual facilita la aplicación eficaz de las políticas a todas las acciones de la TI de forma documentada y uniforme.

Si se definen las políticas como código, es más sencillo aplicarlas a la infraestructura cuando se pone en marcha y se implementa, así como a las operaciones cuando se ejecutan tareas automatizadas. De este modo, se aplica un enfoque estándar independientemente del lugar o el momento en que se produzca la automatización. Por ejemplo, si un empleado ejecuta procesos automatizados para solucionar un problema en un host específico, las políticas codificadas en cada acción pueden impedir que esa persona haga algo que infrinja las reglas del equipo.

Además, las PaC adaptan los entornos y los recursos técnicos a las normas establecidas. Por ejemplo, los equipos podrían utilizar este enfoque para asegurarse de que los recursos informáticos confidenciales no tengan una ruta directa a Internet (lo que podría violar la política de seguridad) o para limitar sus puertos de servicio a HTTPS y SSH.

A medida que la inteligencia artificial avanza y amplía la capacidad de ajuste de una gran variedad de sistemas, impulsa las tecnologías de la información a límites insospechados, que escapan a nuestra capacidad y nuestro control. Si los equipos recurren a servicios con esta tecnología, como Red Hat® Ansible® Lightspeed with IBM watsonx Code Assistant, para acelerar el desarrollo de la automatización, pueden codificar las políticas e integrar las funciones de control al modelo de aprendizaje desde el primer momento. Por ejemplo, una vez que la herramienta de inteligencia artificial incorpora políticas a su modelo de aprendizaje, los creadores de contenido pueden escribir código que cumpla los requisitos obligatorios de manera automática.

Al automatizar el control con las PaC, se garantiza que la gestión impulsada por la inteligencia artificial pueda ofrecer un rendimiento innovador y, al mismo tiempo, mantener el control esperado, de modo que lo que se haga para los equipos de TI ya cumpla con las normas.

En resumen, todo proceso de transformación que involucre la automatización como código representa un desafío cultural. Los equipos de TI pueden aprovechar la experiencia adquirida en la automatización de la IaC y utilizar los mismos métodos y herramientas para adoptar un enfoque más eficiente y adaptable de las operaciones a lo largo de todo el ciclo de vida del desarrollo.

La implementación de DevOps supuso para las empresas diversas ventajas y dificultades, pero el esfuerzo generalizado demostró, al mismo tiempo, que es posible lograr un cambio cultural de tal magnitud. Aunque la automatización siempre implica cambiar el modo en que se realizan las tareas, la adopción de una estrategia unificada de automatización como código obliga a las empresas a transformar la forma en que colaboran los equipos y a compartir las prácticas en cada etapa de las operaciones. La IaC, las OaC y las PaC son los pilares fundamentales de esta iniciativa.

Para contribuir al cambio cultural necesario para la adopción de estrategias de automatización como código, los equipos deben:

• Pensar como desarrolladores de software: utilice git u otros repositorios y, al mismo tiempo, fomente una cultura de desarrollo e implementación modernos que abarque todos los ámbitos de la empresa.
• Desarrollar una mentalidad que priorice la automatización: al momento de diseñar o encarar un proyecto nuevo, piense primero en la manera en la que aplicará la automatización. Para ello, comience con proyectos de automatización más sencillos y amplíelos a medida que vaya avanzando. 
• Partir de las habilidades y la experiencia del personal: para solucionar el problema relacionado con la falta de personal capacitado, incorpore los conocimientos de todos los miembros de su empresa al proyecto de automatización, de modo que los equipos puedan compartir los contenidos y su experiencia.

La automatización como código puede tener éxito si se inculca esta filosofía a todos y cada uno de los equipos, desde los encargados de diseñar los sistemas hasta quienes los gestionan. Este tipo de enfoque no consiste en automatizar ocasionalmente las tareas de algunos equipos y esperar que sean compatibles con el resto, sino en dotar a todo el personal de una estrategia y una disciplina común a la que puedan dar forma juntos.

Para poner en marcha esta estrategia, los equipos también deben abandonar las soluciones específicas que solo funcionan para algunos casos prácticos y en áreas concretas. Además, cuando las empresas emplean varias herramientas para impulsar el proceso, la IaC y las DevOps pueden volverse excesivamente complejas y generar deuda técnica. Si se cuenta con una plataforma de automatización unificada, el mismo lenguaje de automatización que se emplea en las tareas de configuración, redes, infraestructura y nube puede utilizarse en las funciones operativas de las diversas áreas, lo cual permite que los equipos de TI gestionen el ciclo de vida completo de forma integral.

Red Hat Ansible Automation Platform incluye todas las herramientas que se necesitan para implementar la automatización en la empresa, lo cual incluye Event-Driven Ansible, sistemas de análisis, más seguridad y un amplio ecosistema de contenido certificado y validado para poner en marcha las nuevas iniciativas de automatización. Además, utiliza YAML, un lenguaje comprensible para las personas, a fin de que los usuarios con distintos niveles de conocimiento puedan compartir, examinar y gestionar el contenido de automatización en toda la empresa. 

Gracias a Ansible Automation Platform, su empresa puede codificar la experiencia de los equipos de operaciones, infraestructura y aplicaciones en Ansible Playbooks y Ansible Rulebooks basados en YAML. Estos pueden utilizarse para incorporar patrones de solución conocidos a los enfoques de automatización como código, mientras que Event-Driven Ansible puede activar esa automatización cuando tenga lugar un evento específico.

Al incorporar los conocimientos a los playbooks y los rulebooks, los equipos pueden automatizar las respuestas de TI para limitar los cambios en la configuración, reducir los problemas de mantenimiento a largo plazo y mejorar el tiempo promedio hasta la resolución (MTTR). Gracias al diseño modular de Event-Driven Ansible, podrá automatizar las acciones de la TI en el momento y el lugar en que lo necesite, en distintas áreas y para casos prácticos de todas las etapas del ciclo de vida operativo.

Obtenga más información sobre Event-Driven Ansible

Red Hat Ansible Lightspeed with IBM watsonx Code Assistant permite que los enfoques de automatización como código sean aún más accesibles; además, le ayuda a convertir la experiencia adquirida en código YAML confiable para todos los equipos y las áreas. Los usuarios pueden realizar una solicitud de tarea en lenguaje natural, y Ansible Lightspeed interactuará con los modelos base de IBM watsonx para generar recomendaciones de código que luego se utilizarán para crear playbooks de Ansible. Gracias a este servicio, los miembros del equipo con distintos niveles de experiencia son más productivos, eficaces y precisos, lo cual se traduce en procesos de automatización más uniformes para toda la empresa.

Red Hat ofrece laboratorios interactivos en un entorno de Ansible Automation Platform previamente configurado. Puede aprovechar estos laboratorios para realizar experimentos; poner en práctica sus conocimientos; y aprender a crear, gestionar y ajustar con eficiencia las prácticas de la TI, tales como el desarrollo y la implementación ágiles, las operaciones y los análisis simplificados, y las experiencias uniformes de los usuarios.