 Tardes, mi nombre es Miguel Cáceres, soy ingeniero en Previret, tengo aproximadamente más de 15 años en lo que es el área de TI, hoy les vengo a hablar un poco de qué es Previret, en qué nos encontramos actualmente desarrollando, cómo nos ayudó esta nueva tecnología y otros temas o paradigmas, beneficios que hemos ido utilizando en el camino. Bueno, comenzamos. Para los que no conocen Previret, esto es una empresa tecnológica que se encarga de realizar la recaudación del sistema previsional. En otros países se conoce como el Seguro Social, es la empresa más importante y la que está generando la mayor recaudación de este tipo. Básicamente, esto consiste en que un pagador que puede ser una persona natural o una empresa realiza a través de una página de manera sencilla, rápida y eficiente el pago de esta previsión, y si ustedes ven los números que se ven en pantalla, existen aproximadamente 650 mil pagadores que realizan este pago a una cantidad de 7.814.000 trabajadores aproximados, esto es casi el 100% del parque en Chile de trabajadores. Bueno, en búsqueda de nuevos servicios, Previret con su visión de ser el socio estratégico más ágil y eficiente del sistema de seguridad social y con su misión de brindar nuevos servicios que entreguen innovación, seguridad y calidad. Y como mencioné recién, a través de su página Previret.com, nace este nuevo servicio llamado Sikuk, que es Sikuk, el sistema de cobranza judicial. Para que conozcan un poco el modelo actual de este sistema que existen Chile. El modelo actual de operación contempla que existen muchas instituciones previsionales que entregan información a cada estudio jurídico. ¿Qué información entregan toda la deuda existente en el sistema previsional de una persona? Cuando no se realiza algún pago o algo, ellos informan que existe esta deuda. Previret y la corporación del Poder Judicial se encargan de entregar a un nuevo estudio jurídico la información que está solicitando la institución y para esto ese estudio jurídico se encarga de realizar la cobranza de forma manual, se encarga de entregar el dinero a cada institución de vuelta cuando realiza esta cobranza y como ustedes pueden observar en este dibujo, existen muchas tareas manuales, muchos procesos que realizan de distintas formas cada institución, estudios jurídicos que poseen distintos sistemas. Todo este modelo actual es muy complejo y está generando problemas. Además que hay muchas personas que soportan o realizan esta operación, ya de eso podemos obtener una necesidad y un punto de mejora. Diminuir tiempo de desarrollo y documentación, mayoría de nuestros recursos están enfocados en llevar adelante las tareas pendientes, capacidad de satisfacer la demanda de proyectos, para innovar, exceso de tareas manuales y diminuir costa asociado. Si ustedes ven estos puntos cada uno de ellos tienen un punto de mejora importante a tener en cuenta cuando uno está desarrollando un nuevo proyecto. Nosotros de estos puntos logramos que con este nuevo sistema cambiar un poco el diseño. Si ustedes ven en la imagen superior está el modelo anterior lleno de líneas, tareas manuales. El nuevo modelo nos muestra que las mismas instituciones previsionales desarrollan a través de este nuevo servicio que está desarrollando e implementando previo red a través de su aplicación CQ, que un estudio jurídico realice toda la operación de forma electrónica. Esta operación la realice en conjunto con la corporación del Poder Judicial y le entrega esta información de forma electrónica a una entidad del estudio jurídico, la cual se encarga a través de un pago electrónico a través de nuestra página previrred.com de realizar toda la operación y nosotros como previo red hacer entrega de todo ese dinero que se va recaudando. ¿Cuál es la diferencia que previo red está entregando en este nuevo modelo? Que nosotros soportamos todo este nuevo diseño sobre la plataforma de OpenChiff. Bueno, a continuación ustedes pueden ver la arquitectura que estamos utilizando para esta implementación, la cual se basa básicamente en tres nodos master, tres nodos de infraestructuras y tenemos ocho nodos que corresponden al aplic hecho. Básicamente esto está distribuido en cuatro nodos que comparte el área de desarrollo y QA y cuatro nodos que se encargan de la parte productiva. Estos nodos se encuentran al lado por lo cual si ustedes ven el conjunto de servidores no corre el peligro de que desarrollo QA pueda haberlo de producción. Se usó esto básicamente ya que el área de producción requiere mayor recurso y se pudiera trabajar de forma autónoma. Adicionales nosotros contamos con una base que corresponde al sistema Cluster modelo Cluster. Esto es una tecnología que no entregó ReHAT que es para utilizar el almacenamiento persistente. Esa capa se encuentra en la parte inferior y nosotros la utilizamos tanto para almacenar o guardar todo el que OpenShift requiera y a su vez todo lo que la aplicación genere como dato persistente también sea almacenada de esta forma. En la parte superior también tenemos un nodo que corresponde a Ansible. Nosotros tenemos pensado y generamos tareas automatizadas a través de este nodo. Adicional a esto nosotros tenemos herramientas de integración en esta arquitectura la cual consiste en nuestro dispositivo de Satellite que se encarga de realizar como indica ahí nuestro docker register. El cual se encarga de descargar la imágenes directo del Access Network y posterior a esto hacer la entrega a través de algún despliegue sobre la plataforma. Junto a esto tenemos un producto que es el Jenkins como lo han mencionado varias personas que el que se encarga de orquestar nuestros procesos. Él está relacionado a través de otro aplicación que no aparece ahí pero corresponde a Bitback. Básicamente buscamos que un desarrollador genere esta implementación nueva, genere este tipo de código logatille dentro de Bitback y genere el comit y lance la tarea de forma automática dentro de Jenkins. Adicionalmente contamos con CloudForm para lo que es el monitoreo y se está implementando ahora último en paralelo a CloudForm la herramienta de enajos para entregar también un un plus adicional a lo que ya poseemos. Bueno de lo que revisamos recién nosotros sacamos los siguientes paradigmas que yo creo que son básicamente confiar en la decisión de realizar una Pog con Rehat y en la nueva tecnología yo creo que un punto fuerte en esto es pensar que lo que se está realizando está correcto y no no tiene opción a mejorar. Bueno para nosotros dar a conocer esto dentro de la empresa nuestro primer forma de convencer o adaptar a la gente fue indicar de que esta tecnología si bien nos veníamos haciendo las cosas de forma correcta nos podía entregar la ayuda que necesitábamos. Debido a la gran cantidad de nuevos servicios que Previrret está generando tenemos actualmente 75 servicios que entregamos este es un nuevo servicio adicional a lo que ya se entrega fue nuestro primer paradigma a romper dentro de la empresa. Lo siguiente entender que hay que enfocarse no solo en la tecnología yo creo que para poder generar este cambio dentro de Previrret tuvimos que también enseñar o aprender que este cambio también se basa en los procesos actuales que Previrret ha utilizado además de la necesidad de las personas más adelante van a entender un poco porque le indicó ese punto. Otra lesión aprendida fue que en este tipo de proyectos se debe afrontar en conjunto entre el área. Yo creo que cuando iniciamos esta implementación dentro de Previrret comenzamos sin tomar en cuenta las distintas áreas que conforman Previrret tanto el área de desarrollo, el área de QA, el área de operación o el cliente final pensando que nosotros desarrollamos este proyecto llegáramos al final de la etapa y ahí recién hacen los participes de eso. Yo creo que eso fue una lesión aprendida y que se debe tener en consideración cuando uno está implementando este tipo de herramienta. Finalmente otro de los paradigmas y cambios fuertes que se producen dentro de la empresa es el impacto en los procesos y de cómo se maneja el ciclo de vida de la aplicación y el modelo operacional. Como mencioné anteriormente en la búsqueda de poder generar de pliegue continuo la cantidad de servicios que Previrret entrega los contactes, cambios que tanto el país como la necesidad no está generando. Previrret adicionalmente a esto en su nueva metología de los procesos de la metología SCRAM que está utilizando necesitaba hacer un cambio también en un despliegue continuo, en un desarrollo ágil. Y este fue un dibujo que me entregó o utilizó el consultor que no acompañó en la implementación que yo creo que nos marcó un hito importante o un cambio en la mentalidad debido a que nosotros cuando comenzamos la implementación o este proyecto estábamos como el dibujo principal queriendo hacer todo de una vez, querer tener el auto como indica la imagen no considerando la necesidad o el estado del usuario final y yo creo que eso fue un punto importante que el consultor derreja de en este caso nos dio a entender que siguieramos como indica la sigla el mínimo producto viable desde el comienzo y que fuera el usuario requiere algo, nosotros estamos realizando una implementación hagamos un primer entregable que cumpla la necesidad o lo que la persona necesita. Continuemos con un siguiente producto pero vamos siempre entregando algo que podamos recibir algún feedback, recibir algo que podamos generar un cambio importante y que cuando lleguemos al final del producto esté contento el cliente final y también nosotros por desarrollar un trabajo de buena manera. Básicamente se puede considerar esos números como etapas o como meses dentro de un proyecto para poder generar de buena manera esto. ¿Qué esperamos nosotros con esta implementación? Integridad de las piezas, debido a la cantidad de servicios que posee previrred y los contantes de desarrollo, control de cambios que se están generando en la empresa. Al utilizar OpenShift nosotros buscamos que con este desarrollo continuo de implementación de generar a través de feedback un cambio en el código, después Yankee y Castille sobre OpenShift cada una de sus tareas, sepamos que lo que no entregó el desarrollador realizó CUA como prueba es lo que está implementado en producción. Muchas veces uno por más que tenga control es claro, tenga proceso, siempre tiene la duda si lo que realmente se está implementando producción es lo que ese comenzó a desarrollar y nos sufrió alguna alteración en el camino. Junto a esto, similar a lo que menciona anteriormente, la mejora de los controles de seguridad. Con esto nosotros evitamos que lo que salió de desarrollo, que se revisó, se generó una seguridad de por medio, fue validado por el área de CUA cuando llegue a producción llegue una pieza o una aplicación cambiada, que no cumpla lo que uno esperaba o traiga alguna otra modificación no deseada. Bueno, otro de los puntos o beneficio esperado con esta herramienta corresponda a la agilidad en el despliegue a producción. Como les mencioné, actualmente la cantidad de servicios que entrega previsto en el país nos está trayendo que a la semana estemos generando una cantidad aproximada de 30 controles de cambio, porque si juntamos cada servicio que ellos poseen. La diferencia de esto es que al generar este despliegue continuo, o esta forma de integración nosotros podemos primero poder cumplir estos pasos a producción en el tiempo que la empresa nos solicita y también cumplir cuando existen pasos de producción que el país nos solicita por algún cambio a nivel de normativa. Otro punto importante, el crecimiento elástico según necesidad. Actualmente los servicios que no están en esta plataforma cuando requieren un crecimiento elástico, yo creo que a Muto les debe ocurrir que requieren preparar un servidor, requieren preparar otros cambios de configuración, generar cambio a nivel de comunicaciones. Bueno, nosotros esperamos que al tener nuestros sistemas dentro de contenedores que nuestra primera aplicación corresponda en el sistema de cobranza judicial podamos tener este crecimiento elástico generando más pot, generando más contenedores y la ventaja que con este cambio nosotros también pudimos generar los microservicios. Bueno, el roadmap actual de previo red se encuentra en el servicio que les mencioné que corresponda al sistema de cobranza judicial, el cual se encuentra pronto a salir a producción. Existe una etapa que está actualmente implementada sobre la arquitectura que yo les mostré que ejecuta esta tarea de forma vacuum. Existe dentro yo creo de un mes aproximado el paso a producción hacia las personas para que pueda ser explotado y utilizado el sistema y nosotros buscamos que el resto de aplicaciones tanto previo red.com como otros servicios que encontramos se puedan generar también como microservicios, poder entregar de manera óptima lo que ya les mencioné. Quiero para finalizar y yo creo que como punto importante y para la gente que está intentando adaptarse o tomar esta tecnología, primero es confiar en estos nuevos productos. Nosotros como previo red pensábamos que estábamos haciendo bien las cosas, pero cuando Rehat se acercó a nosotros nos presentó esta nueva herramienta pudimos darnos cuenta que podíamos hacer las cosas bien y de forma más expedida, de mejor calidad, entregar un plus que antes no estábamos siendo capaces de mantener durante el tiempo. Otro punto importante de esto es cuando comiencen a implementar o busquen integrarse este tipo de tecnología, hagan participe a todas las áreas. Nosotros como les mencioné cometimos el error cuando se inicio el proyecto en tratar de nosotros tomar este proyecto, llegar, avanzar en el camino y no hacer participe a la gente que tiene el conocimiento de distinta forma, que fue básicamente el área de desarrollo, ver cómo podían ello adaptar su aplicación a este nuevo sistema, el área en que le impactaba este cambio y finalmente en producción. Y el último punto es lo que mencioné del MVP o el mínimo producto viable. Cuando comiencen con su implementación o continúen con su trabajo traten de no olvidar esta terminología porque es mejor tener al cliente final haciéndole un entregable y recibiendo un feedback de vuelta para ir generando un producto de calidad. Nosotros intentábamos o teníamos la visión de querer implementar esto, generar todo lo que deseamos de una forma de 1 a 100, pero no estábamos siendo capaces de leer o recibir el feedback por parte del usuario final. Y esto nos trajo al principio de mora en los tiempos, se nos estaban extendiendo mucho lo acuerdo, llegar a un punto común, leer realmente la necesidad del usuario, pero usando ese cambio pudimos lograr lo que necesitaba.