Curso de DevOps: Automatización VIII. Componentes de una plataforma de automatización

Vamos a recordar los componentes de la plataforma de automatización, junto con las ventajas de utilizar una plataforma frente a un sistema de scripts aislados para tareas de administración del sistema. Hay diferentes enfoques que podemos adoptar para automatizar nuestros sistemas. Uno de ellos es adoptar la plataforma de automatización. El segundo es optar por el script de automatización. Intentemos comprender la arquitectura centrándonos en los componentes de esta.

 

Hay cuatro capas importantes. La primera capa es la base que proporciona la infraestructura. Puede ser NSX, vSphere o también puede ser vSAN. La segunda capa tiene que ver con operaciones en las que podemos utilizar componentes como vRealize Log Insight o incluso vRealize Operations Manager. Hay que seleccionar componentes que puedan gestionar las operaciones de nuestra plataforma de automatización. Después necesitamos una plataforma de gestión en la nube, que pueda funcionar con la automatización del orquestador. vRealize proporciona componentes como vRealize Orchestrator y vRealize Automation para administrar nuestra plataforma en la nube. Y, por último, es necesario identificar escenarios que representen qué modelos de negocio se pueden automatizar. Y eso se puede hacer utilizando vRealize Business o vRealize Hyperic. Existen varias herramientas externas diferentes que se pueden utilizar para crear escenarios.

 

Ahora, debemos centrarnos en utilizar un flujo de trabajo de automatización. Puede haber una desviación respecto a nuestro flujo de trabajo de automatización. Estamos adoptando un flujo de trabajo de automatización que se ha implementado prácticamente en varios escenarios. Para empezar, primero debemos utilizar un formato de diseño validado proporcionado por un proveedor. Por ejemplo, podemos tomar la base de VMware Validated Design. Esto nos ayudará a clasificar primero el tipo de implementación. Ahora hay tres posibilidades diferentes de tipo de implementación. La primera es una región única, la segunda es una región dual y la tercera es una región cruzada que utiliza UDLR. Necesitamos entender que una sola región siempre se preparará para una región particular, digamos, la región Y, como se indica en la ilustración. Podemos utilizar estas regiones para realizar la implementación de varios escenarios que están presentes en una región en particular. Podemos completar la región Z. Cuando tenemos una región dual, tenemos que realizar todas las tareas de una sola región y luego necesitaremos preparar la región X. En resumen, estamos preparando dos regiones diferentes y luego estas implementarán los escenarios. Cuando vayamos a una región cruzada con UDLR, realizaremos un escenario con UDLR. No realizaremos un escenario preparando un escenario explícito para regiones específicas.

 

Ahora bien, ¿cuales son las ventajas de utilizar una plataforma de automatización? En primer lugar, la alta disponibilidad de los componentes de gestión porque están debidamente probados. Proporciona copia de seguridad y restauración simplificada de los componentes de administración, monitoreo y alertas configurables y configuración basada en UI de recuperación ante desastres de los componentes de administración.

 

Finalmente, necesitamos clasificar los beneficios de la plataforma de scripts. El primer beneficio es la compatibilidad con el ritmo del ciclo de desarrollo. Costo de mantenimiento más económico y proporciona automatización de escala incorporada. También proporciona la capacidad de ampliar el alcance de la automatización. Y, por último, proporciona una adopción mejorada con automatización de pruebas sin código donde, en el caso de un script, es necesario escribir código. Depende de un intérprete particular para interpretar el código. También es necesario probarlo aplicando varios tipos diferentes de pruebas.

 

Curso de DevOps: Automatización VII. Atributos de los flujos de trabajo de automatización y DevOps

 La automatización es uno de los requisitos esenciales de la implementación de DevOps. Hay varias formas diferentes en las que podemos planificar el flujo de trabajo de automatización. Vamos a utilizar el marco de automatización API.

Hay tres unidades esenciales. Primero está el script de automatización, que puede contener archivos de características, datos de automatización o, a veces, repositorios de correo basura. Todo esto será utilizado por el marco de automatización API para automatizar la tarea. El marco de automatización API estará compuesto por un motor de ejecución de automatización, utilidades de automatización, utilidades de KPI para monitorear las tareas de automatización y ciertas utilidades comunes para integrar servicios externos al marco API existente. El resultado final serán informes y registros de automatización. Podemos utilizar varias herramientas diferentes en cada una de estas capas para asegurarnos de poder derivar un flujo de trabajo de automatización sólido para nuestro sistema existente utilizando marcos de automatización API.

El flujo de trabajo automatizado de DevOps también se basa en una canalización de componentes. La canalización de componentes comienza con la actividad de los desarrolladores de verificar la fuente. Una vez que se verifica la fuente y se compila, realizaremos pruebas de unidad y de sus componentes. En caso de que sea necesario revertir, revertiremos los cambios y una vez que estemos convencidos con el módulo probado, ensamblaremos los módulos. Cargaremos el módulo no controlado para su aprobación y finalmente, una vez aprobado, enviaremos una notificación. Las notificaciones pueden ser de dos tipos, puede ser una notificación de éxito o de error. Una vez que la carga de módulos no controlados se realice correctamente, el tipo de notificación será exitosa; de lo contrario, será una notificación de error.

Teniendo en cuenta el proceso de integración, comenzamos eligiendo la versión del componente. Una vez que hayamos seleccionado la versión del componente, debemos descargar todos los módulos dependientes. Después de descargar las dependencias, o módulos de los que depende nuestro componente, ensamblaremos y crearemos una unidad desplegable. Esas unidades desplegables se desplegarán utilizando varias estrategias de despliegue diferentes, como si se pudiera incrementar hasta la puesta en escena. Realizaremos una “prueba de humo” como resultado, podremos revertir la implementación y notificar la falla. Pero si la prueba  tiene éxito, comprobaremos el “sistema inmunológico”. Nuevamente, el resultado de la verificación, si no es satisfactorio, podemos revertir el despliegue, pero si tiene éxito, realizaremos la prueba de aceptación. Si la prueba de aceptación no tiene éxito, podemos revertir la implementación nuevamente. Pero si es así, si todo está bien, podemos retroceder la preparación, realizar una prueba de humo adecuada en la preparación, promocionar los módulos y luego desplegar la unidad. Y finalmente, una vez finalizada la implementación, notificar el éxito. Pero si la etapa de reversión no tiene éxito, notificaremos el error.

Finalmente, vemos el flujo de trabajo automatizado de DevOps, pero ahora desde la perspectiva de la implementación en producción. Planificaremos el incremento de implementación de lo que esté listo para la producción. Una vez que esté implementado, haremos una prueba y decidiremos si revertimos la implementación o no. Si seleccionamos la estrategia de implementación de reversión porque la prueba falle, debemos detectar una implementación incorrecta. Necesitamos notificar el fracaso. Pero sí, si pasa la prueba se realizará una prueba del sistema “inmunológico” y notificaremos el éxito.

 

Curso de DevOps: Automatización VI. Relaciones, dependencias y políticas

El objetivo de este post es identificar las relaciones, dependencias y las políticas de automatización que se utilizan para derivar un clúster de automatización de referencia, con componentes heterogéneos. Para crear una arquitectura de automatización de clústeres, debemos centrarnos en ciertos elementos esenciales.

La automatización de un clúster implica varios componentes diferentes, y cada componente tiene un papel esencial que desempeñar. El componente central es la sala de control, que asume la responsabilidad de la concesión de licencias y proporciona capacidades de visualización de conocimientos, almacenamiento en caché, mensajería, servicio de conocimientos y descubrimiento de servicios de conocimientos. Toda la configuración para la automatización del clúster se realiza en una base de datos persistente, que puede ser PostgreSQL o cualquier otra base de datos de nuestra elección, donde podremos almacenar la base de datos de metadatos del panel. La base de datos persistente puede funcionar con capacidades de Elasticsearch para proporcionar una búsqueda rápida que permita una mejor búsqueda. Podemos tener varios componentes conectados a la sala de control, que se gestionarán para la automatización del clúster. Uno de ellos es el servidor SQL, podemos optar por un servidor Oracle, que tendrá una base de datos de sala de control y una base de datos de análisis. Podremos tener un servidor de versiones, que será un componente opcional. Nuestra sala de control también deberá funcionar con archivos compartidos, que pueden ser SMB. Utilizando todos estos componentes, podemos crear capacidades de automatización de clústeres.

Ahora vamos a ver los componentes esenciales del clúster. El primer componente es el propio grupo de clústeres. Podemos considerar un grupo de clústeres como un grupo de servicios agrupados que conmutan juntos si hay un fallo en uno de ellos, pues estarán estrechamente acoplados entre sí. En segundo lugar está el host, es la máquina del clúster, que se requiere para alojar el servicio. El tercero es el nodo, es un término genérico que se usa para máquinas en un clúster. Los nodos pueden ser de dos tipos: nodo primario que contiene el servicio de base de datos activo y un nodo secundario que es el servicio duplicado pasivo o en espera. Y finalmente, tendremos un servidor, que se encarga de escuchar todas las solicitudes y gestionar y procesar las solicitudes.

Dentro de la tarea del clúster de automatización. Dependiendo de nuestras  necesidades, podemos configurar un clúster de automatización para brindarnos la posibilidad de administrar fallas de aplicaciones y servicios, administrar fallas de sitios en organizaciones de múltiples sitios y ocuparnos de fallas de sistemas y hardware. Aparte de eso, también debemos identificar las razones críticas por las que utilizar el clúster de automatización. La primera razón es que nos facilita la replicación. Esta replicación puede ser de varios tipos, puede ser replicación sincrónica o replicación asincrónica. El objetivo principal es garantizar que el nodo primario y el nodo secundario estén sincronizados. La segunda razón para utilizar un clúster de automatización es gestionar el tiempo de inactividad y la conmutación por recuperación. La recuperación por recuperación se considera un proceso de restauración de la aplicación en un estado de conmutación por error a su estado original, que es el que tenía antes del error. El tercer uso importante del clúster de automatización es gestionar de forma inteligente la conmutación por error. La conmutación por error en una arquitectura de alta disponibilidad,  significa la capacidad del sistema de cambiar servicios esenciales, como servicios de base de datos y servicios SVN, automáticamente a un servidor de base de datos en espera o, a veces, a un servidor SVN. Y, por último, se trata de gestionar la degradación y la redundancia elegantes. Cuando el proceso de degradación es elegante, permite que las dependencias del clúster funcionen correctamente en un nodo primario degradado, mientras que se utiliza la redundancia para evitar un punto único de falla.

Curso de DevOps: Automatización V. Sistemas de Automatización Multiplataforma

 Vamos a enumerar las características clave que deben tenerse en cuenta al configurar un sistema de automatización multiplataforma centrándonos en los componentes de gestión central y de extremo a extremo. Configurar la automatización en la que intervienen múltiples plataformas es un desafío. Necesitamos comprender ciertas características críticas de la automatización multiplataforma que nos ayudarán a adoptar el enfoque y el flujo de trabajo correctos para gestionarlo. La primera característica que obtenemos es la alta disponibilidad y el seguimiento de los recursos. En segundo lugar, deberíamos centrarnos en la automatización basada en políticas, porque tenemos múltiples sistemas cuyo impacto se reflejará en la automatización. También debemos planificar el reinicio automático de los recursos fallidos, porque cuando se tienen múltiples plataformas, monitorear y tomar medidas manualmente se vuelve difícil. Esta es la razón por la que necesitamos dotar a nuestro sistema de capacidad para proporcionar reinicio automático de recursos fallidos.

 

La automatización multiplataforma también proporciona la capacidad de gestionar la relación entre recursos en todo el clúster para ayudarnos a configurar la agrupación vertical y la agrupación horizontal para aprovechar los recursos disponibles. Y, por último, la automatización multiplataforma permite una verdadera automatización de aplicaciones empresariales.

 

Necesitamos un motor de automatización que interprete el script de automatización y lo ejecute en tiempo de ejecución. También necesitamos un administrador de automatización de un extremo a extremo para garantizar que se capture el estado de cada paso de la automatización. Una consola de operaciones para invocar la automatización o início rápido, que no están programadas pero necesitan ser disparadas. Necesitamos centrarnos en la automatización de la base de datos. También es necesario derivar una política adecuada para la automatización. Y, por último, es necesario tener un adaptador de automatización de un extremo a otro. Necesitamos un adaptador de automatización de un extremo a extremo para integrar dos plataformas diversificadas entre sí.

 

Vamos a ver la  arquitectura de automatización multiplataforma. Para ello tomaremos como ejemplo un servidor de aplicaciones que se utiliza para la implementación de aplicaciones. Tendremos un navegador cliente, este necesita una consola de solución integrada, que también se denomina consola de operaciones. Necesitamos un administrador de automatización, que asuma la responsabilidad de la automatización de un extremo a otro comunicándose con un adaptador de automatización de extremo a extremo, que ayuda a integrar todas las herramientas de terceros al servidor de aplicaciones existente, donde tenemos nuestra aplicación, que puede necesitar sistemas externos.

El servidor de aplicaciones se comunicará con el motor de automatización. Y el motor de automatización leerá la política de automatización y ejecutará el script de automatización para garantizar que cualquier tarea que se suponía automatizada lo esté. La base de datos capturará los detalles esenciales que se requieren para la automatización.

  

Finalmente, veremos el caso de automatización multiplataforma. El usuario utilizará la consola de operaciones para comunicarse con el dominio de automatización, que contiene componentes como el administrador de automatización de un extremo a otro, el motor de automatización y el adaptador de recursos. Tendremos políticas de automatización y pasos de automatización que también formarán parte del dominio de automatización. El uso del adaptador de recursos se comunicará con multiplataformas, que se representan en la exhibición en forma de Nodo A, Nodo B y Nodo N, donde cada nodo tendrá un adaptador de automatización de extremo a extremo para comunicarse con el adaptador de automatización que está presente en el dominio de automatización.  El nodo B también tendrá los mismos componentes que se encuentran en el nodo A. Pero sí, todos se comunicarán entre sí en forma de un clúster para brindar facilidad de conmutación por error y equilibrio de carga.

 

 

Curso de DevOps: Automatización IV. Identificar el alcance de la automatización

 Vamos a reconocer el papel de la automatización de procesos, y la automatización de servicios en la creación de flujos de valor para la entrega de proyectos IT empresariales. Hay diferentes aspectos de la automatización. El primer aspecto crítico es el proceso. Luego necesitamos conocer el alcance de la automatización de procesos robóticos, junto con la automatización de servicios. Para obtener el flujo de valor correcto de la automatización, podemos seguir un proceso.

 

Como podemos ver en la imagen superior, comenzamos con la planificación, eso es lo que se llama idear. Una vez realizada la planificación, debemos crear el producto, y eso lo hacemos en la fase de creación. Seguimos un enfoque de ingeniería estándar para crear el producto. Y luego llega el momento del lanzamiento, donde también debemos probar la automatización de este. Finalmente, tenemos operaciones, donde intentamos identificar operaciones de monitoreo de soporte que pueden automatizarse. Y finalmente, tenemos el usuario final, donde podemos descubrir todas las funciones que contiene. Que se pueden utilizar para facilitar al usuario final el flujo de valor de idear, crear, lanzar y operar en un producto en particular. Necesitamos comprender que todo el proceso de idear, crear, lanzar y operar debe adoptar los principios ágiles y DevOps. Cuando adoptamos los principios Agile y DevOps, nos brinda beneficios en términos de tiempo de obtención de valor. Y ese tiempo para generar valor nos proporciona un tiempo de entrega de un extremo a otro que nos ayuda a estimar los beneficios de la automatización.

 

A continuación vamos a examinar uno de los paradigmas más  populares de automatización, que se llama RPA. Empezamos siempre por aprender, donde clasificamos qué es RPA y qué no se puede considerar como RPA. Una vez que aprendemos y definimos el alcance, pasamos al segundo paso, la fase de identificación, donde identificamos posibles oportunidades de RPA. Una vez que lo hemos identificado, pasamos a la fase de selección, donde derivamos el caso de uso inicial e intentamos definir criterios de éxito. Una vez que hayamos identificado el caso de uso inicial y estemos listos con los criterios de éxito, haremos una prueba piloto. Es decir, crearemos una solución para el caso de uso inicial que seleccionamos en la etapa anterior. Una vez que el piloto esté listo, debemos analizar el resultado. Y ese análisis se realiza manteniendo las medidas correctas en el lugar correcto en el piloto. Finalmente, la medida nos dará un documento de lección aprendida. Que se utilizará para la expansión, que es la última fase de la implementación actual de RPA para realizar el flujo de valor. Expandir proporcionará un margen para pasar al siguiente caso de uso y repetir todo el proceso de selección, prueba piloto y medición. Todo este proceso puede ser de naturaleza iterativa, dependiendo de la cantidad de casos de uso que hayan seleccionado. Y para lo cual hemos definido los criterios de éxito para derivar el flujo de valor.

 

Finalmente necesitamos entender cómo derivar el alcance de la automatización.

Existen varios criterios diferentes según los cuales mediremos la automatización. Esos criterios se pueden definir sobre la base de cuatro clasificaciones importantes. El primero es estático, el segundo es dinámico, el tercero es altamente personalizado y el cuarto es estandarizado. Hay dos elementos importantes que debemos considerar dentro de un flujo de trabajo, es decir, la automatización de tareas o actividades y la automatización del flujo de trabajo. Pero cuando pasamos a tener una visión empresarial más amplia, se hace más dinámico y altamente personalizado. Nos centraremos en la automatización de procesos y la automatización centrada en decisiones.

 

Curso de DevOps: Automatización III. Descubriendo la necesidad de automatización

 Vamos a es especificar los métodos que pueden ayudar a encontrar procesos comerciales clave que son candidatos valiosos para la automatización de IT. Una de las tareas esenciales del ingeniero de soporte de automatización es identificar el método de búsqueda de procesos de automatización. Podemos utilizar uno o una combinación de varios métodos diferentes para obtener más detalles sobre el sistema actual que puede automatizarse.

En primer lugar estaría la identificación de procesos, es decir debemos identificar dichos procesos. En segundo lugar está la implementación del proceso, es necesario encontrar en qué consistirá la implementación de la automatización del proceso. Pero antes de implementarlo es necesario realizar un análisis adecuado, lo que conduce a múltiples alternativas diferentes que pueden utilizarse para implementarlo. El descubrimiento de procesos es también una de las técnicas que se pueden aplicar para su automatización. A veces encontraremos que es necesario rediseñar algunas de las automatizaciones que ya se han realizado. Para lo cual es necesario ajustar el proceso rediseñándolo. Y, por último, debemos asegurarnos de poder utilizar la capacidad de seguimiento y control de procesos. Esto genera gran cantidad de datos que nos proporcionan una buena comprensión de la automatización actual, que nos permitirá aplicar técnicas para futuras necesidades de automatización.

Ahora nos vamos a centrar en el enfoque que podemos adoptar para identificar procesos de automatización.

Siempre debemos comenzar por identificar los tipos de casos. Para cada caso tendremos ciertas funciones, ese es el segundo paso que tenemos que identificar. A continuación, debemos derivar una matriz de casos y funciones que nos ayude a comprender qué parte de la funcionalidad se puede automatizar y qué parte de la funcionalidad no se puede automatizar. Cualquiera que sea el resultado de las métricas, lo recogeremos  y comenzaremos a gestionar el proceso de automatización. Para ello, adoptaremos las mejores prácticas para dividir procesos, con la ayuda de las pautas prescritas por el arquitecto de automatización.

A continuación nos centraremos en la gestión de la automatización de procesos de negocio,

los procesos de negocio son propensos a cambios. Por lo tanto, siempre debemos idear un enfoque sólido y ágil para gestionar la automatización de los procesos de negocio. Es necesario adoptar el ciclo de vida adecuado para la mejora de los procesos de negocio, que incluya pasos como descubrir, analizar, rediseñar, implementar y monitorear. El ciclo de vida de mejora de los procesos de negocio proporcionará resultados que podemos utilizar para comenzar una nueva fase de gestión de la automatización de procesos comerciales, que se denomina ciclo de vida de realización comercial, donde se obtienen los resultados del ciclo de vida del proceso comercial. Siempre comenzamos con identificar. Luego debemos medir utilizando varias métricas diferentes que nos ayuden a identificar el costo de ejecución correcto del proceso. En tercer lugar, tenemos ejecutar. Y finalmente necesitamos identificar los KPI correctos que nos ayuden a sostener el proceso.

Debemos comprender que obtendremos suficiente información del seguimiento del ciclo de vida de mejora de los procesos de negocio que nos ayudará a identificar y crear informes de KPI para su sostenibilidad.

Finalmente, dividiremos el mecanismo de automatización de procesos de negocio en dos partes diferentes, tal como se muestra en la imagen superior. Tenemos la automatización de procesos de negocio, donde nuestro enfoque estará en la implementación para derivar la solución, que incluye actividades como el desarrollo de software y la integración de sistemas. En segundo lugar está el análisis y la optimización, que incluye la toma de decisiones, como comprar o desarrollar. Derivar el diseño y la arquitectura de la solución adecuada y preparar una documentación sólida del proceso.

 

Curso de DevOps: Automatización II. Tareas y procesos clave para automatizar

Vamos a ver los pasos para identificar tareas y procesos clave que pueden automatizarse para obtener valor en nuestro negocio. El modelado de negocios es una tarea crítica. Necesitamos entender el negocio desde varias perspectivas diferentes; hablar con las partes interesadas de las empresas,  identificar a los consumidores. Y finalmente adoptar una hoja de ruta particular para poder implementar un plan de automatización del modelo de negocio que nuestro equipo de TI pueda llevar a cabo. 

 

Para empezar, debemos adoptar siempre el modelado de procesos de negocio como un campo interdisciplinario. El segundo objetivo importante es cubrir todo el ciclo de vida del proceso empresarial. Y eso sólo se puede hacer si somos capaces de identificar todas las entidades comerciales involucradas y saber cómo se realizan realmente las transiciones en los procesos comerciales. El tercer objetivo es derivar una práctica que siga un enfoque paso a paso para el modelado. Y el cuarto objetivo es que el modelado de negocios depende en gran medida de un enfoque de modelado de procesos maduro y estandarizado. 

Por lo tanto, primero debemos identificar los estándares que vamos a seguir y luego aplicar esos estándares mientras realizamos el modelado de negocios. Vamos a ver varios elementos críticos diferentes de los procesos comerciales. Necesitamos entender que el proceso de negocio siempre conducirá a algún resultado. Los procesos de negocio, contienen tres elementos importantes. El primero es el elemento empresarial. En segundo lugar está la actividad que realiza la empresa, y en tercer lugar está el punto de decisión en el que tenemos que decidir. 

 

El proceso de negocio es un objeto que se crea internamente. Ese objeto tendrá impacto sobre el resultado. Ese resultado es un elemento de apoyo que representa al usuario en el sistema. Como resultado del proceso empresarial, obtendremos algún resultado que puede ser negativo o positivo. Y dependiendo del resultado, iniciará la acción adecuada y se informará al usuario. Luego hemos de preguntarnos, para poder hacer modelos de negocios, ¿cuáles son las tareas y procesos clave que debemos seguir? Siempre comenzamos con la identificación del proceso que nos brinde la arquitectura y nos ayude a descubrir varios componentes diferentes de este. 

Una vez lo tengamos, analizaremos dicho proceso. Analizar el proceso significa comprender el proceso, crear un documento de resultado de análisis elaborado que pueda usarse como información para rediseñar o diseñar. Una vez que el diseño esté listo, indicaremos que es un proceso que se implementará pronto. Y se llevará a otra fase que es la fase de implementación. La fase de implementación, es decir cuando los procesos están listos para ejecutarse cada vez que se realiza una solicitud. Finalmente la ejecución de nuestros procesos producirá datos que se pueden utilizar para monitorear procesos e improvisar procesos para un mejor control. 

El primer beneficio de la automatización del modelado de procesos de negocio es que permite una implementación sistemática, que puede documentarse y utilizarse como aprendizaje. Aumenta la capacidad para obtener un mejor control del proceso. En otras palabras, podrá derivar un mecanismo que proporcione un mejor control del proceso. El tercer beneficio de la automatización BPM es que automatiza los procesos mediante la coordinación y ejecución del modelo de procesos de negocio. Una vez que se dispone del modelo, nos proporcionará un tema para la automatización. Y, por último, también simplifica la implementación del flujo de trabajo, lo que nos ayuda a representar el flujo de trabajo empresarial correcto, que puede transformarse en un proceso de TI utilizando el modelo de negocio.

Curso de DevOps: Automatización I. Ciclos de entrega de IT automatizados

Vamos a describir el ciclo automatizado de entrega de IT y su impacto en la gestión y el monitoreo de IT. Las herramientas de supervisión y gestión de IT automatizan tareas repetitivas específicamente para profesionales de IT. El ciclo de entrega de IT comienza con la planificación, donde debemos planificar cuáles son todas las actividades comerciales o actividades de soporte que deben automatizarse. La planificación nos brinda una manera de aprovisionar y configurar. Lo que nos da la oportunidad de identificar el componente de la aplicación, el de la infraestructura y el del servicio que se pueden aprovisionar y configurar para admitir la automatización.

El tercer paso es recopilar datos operativos, porque eso nos ayudará a probar nuestra estrategia de automatización. Una vez que hayamos recopilado datos operativos de su implementación, podemos utilizar esos datos para el seguimiento. Y el monitoreo nos permite el análisis e información adecuados que el equipo de operaciones puede utilizar para improvisar aún más la automatización.

Así es como se puede implementar IT automatizada. A continuación, intentaremos comprender los impactos de la automatización de IT en la gestión.

 

Hay impactos positivos, también hay impactos negativos, esto depende de varios factores diferentes. Veremos son los impactos críticos de la automatización de IT en la gestión. En primer lugar, se basa en herramientas de software para definir el alcance de la automatización. Ese es uno de los impactos de la automatización de IT en la gestión, donde se depende mucho de las herramientas. En segundo lugar, reemplaza una serie de acciones entre los administradores y el entorno de IT, eliminando todas las tareas manuales que deben realizarse. El tercer impacto es que el sistema se vuelve capaz de desencadenar acciones de gestión automatizadas dependiendo de ciertas condiciones configuradas. En cuarto lugar, no requiere intervención manual para la conmutación por error si ha adoptado soporte de conmutación por error automatizado. También debemos comprender que la automatización de IT permite una gestión automatizada de la escala. Que se basa en condiciones y eventos prescritos, que pueden iniciar actividades de ampliación o reducción de escala. Y, por último, permite activadores automatizados de limpieza basados en reglas. Donde podemos definir varias reglas y esas reglas invocarán acciones para administrar los recursos para optimizarlos.

Es necesario entender el papel de los ingenieros de automatización en nuestra empresa. El ingeniero de automatización es un rol que garantiza que se facilite la creación de prácticas de automatización.

También se encargan de monitorear o controlar la producción y la entrega general, que pueden automatizarse. Son responsables de documentar todas las especificaciones de diseño relevantes para la automatización. Y aparte de eso, también desempeñan un papel importante a la hora de respaldar y ofrecer la automatización. El ingeniero de automatización también desempeña un papel esencial en la identificación de la causa raíz que les ayuda a solucionar errores de automatización. Como ingenieros de soporte, debemos tener una visión de administración para comprender el ciclo de vida del error. Siempre que se identifiquemos un nuevo error, como ingeniero de soporte lo escribiremos como un nuevo error. Después, debemos asignarlo al ingeniero de soporte que se supone debe manejarlo.

 

Y el estado de ese error ahora cambia de error nuevo a error asignado. Una vez asignado el error, pude tomar dos estados diferentes: el primero rechazado y el segundo abierto. Se rechaza porque al ingeniero de soporte al que se le asignó ese error en particular ya se le asignó anteriormente el mismo error, lo que significa que está duplicado. Otro motivo de rechazo es que se aplace porque depende de algún otro error. Además de rechazado, tiene los estados abierto y reabierto. El ingeniero de soporte revisa el error abierto, le aplica las correcciones correctas y cambia el estado a solucionado. Hecho esto, se prueba, y si todo está bien, se cierra. Pero sí, después de solucionarlo, si el impacto aún persiste, pasa a un estado llamado reapertura. Así es como podemos ajustar los estados de del error según nuestras necesidades. Para derivar el ciclo de vida de gestión de errores adecuado para nuestra aplicación o empresa.