1
00:00:03,700 --> 00:00:06,900
Buenos días, Raquel y José Andrés.

2
00:00:08,580 --> 00:00:14,039
Hoy, día 21 de enero, a las 12 de la mañana,

3
00:00:14,699 --> 00:00:18,160
estamos convocados a través de Jefatura de Departamento

4
00:00:18,160 --> 00:00:23,719
para la defensa del módulo de proyecto del ciclo de asilo.

5
00:00:25,019 --> 00:00:29,379
Os informo de que esta grabación se usará en el entorno cerrado de EducaMadrid

6
00:00:29,379 --> 00:00:37,079
con fines educativos y sólo estará a disposición de los profesores en el aula virtual para llevar

7
00:00:37,079 --> 00:00:45,759
a cabo la evaluación y calificación de la defensa del proyecto. En el aula virtual de proyectos habéis

8
00:00:45,759 --> 00:00:52,420
sido informados de los criterios y de la rúbrica de calificación. El orden de la presentación del

9
00:00:52,420 --> 00:00:59,159
proyecto es el siguiente, 15 minutos máximo para defender el proyecto y 5 minutos para preguntas

10
00:00:59,159 --> 00:01:05,819
por parte del tribunal. Dicho esto, vuestro tiempo de exposición comienza a partir de este momento,

11
00:01:07,180 --> 00:01:14,659
que son las 12. Adelante y mucha suerte. A las 12 y 20. Tenemos que haber terminado todo a las 12 y cuarto,

12
00:01:14,780 --> 00:01:19,280
aproximadamente, vuestra parte de presentación. Adelante.

13
00:01:21,079 --> 00:01:28,060
Pues, bueno, buenos días. Mi nombre es Raquel y junto a mi compañero José Andrés vamos a presentar

14
00:01:28,060 --> 00:01:33,019
nuestro proyecto titulado automatización con ASIBLE. La primera parte la voy a hacer

15
00:01:33,019 --> 00:01:40,420
yo y luego la siguiente parte la hará mi compañero. Este proyecto nace de la necesidad

16
00:01:40,420 --> 00:01:49,079
de optimizar la administración de los sistemas. A través de la automatización abordamos

17
00:01:49,079 --> 00:01:57,439
problemas comunes reduciendo errores de configuración, eliminando tareas que son repetitivas y mejorando

18
00:01:57,439 --> 00:02:02,799
la consistencia. A lo largo de esta presentación vamos a explicar los motivos que nos han llevado

19
00:02:02,799 --> 00:02:08,080
a la realización de este proyecto, los objetivos, los métodos, las herramientas que hemos utilizado

20
00:02:08,080 --> 00:02:10,680
y los resultados que hemos obtenido.

21
00:02:13,500 --> 00:02:22,659
Vale, la necesidad de este proyecto surge por tres razones principales. La primera es

22
00:02:22,659 --> 00:02:29,240
las tareas repetitivas y tediosas para evitarlas porque los procesos manuales consumen

23
00:02:29,240 --> 00:02:33,939
mucho tiempo y aumenta la probabilidad de que haya errores y no escalan adecuadamente

24
00:02:33,939 --> 00:02:40,080
cuando las infraestructuras son mayores, van creciendo. La segunda sería las infraestructuras

25
00:02:40,080 --> 00:02:48,979
complejas, que con el incremento de los sistemas, mantenerlos de forma manual es complejo y

26
00:02:48,979 --> 00:02:55,560
no es eficaz y puede traer problemas. Y luego, el tercero sería la falta de consistencia,

27
00:02:55,560 --> 00:03:01,159
garantizando que todas las configuraciones sean

28
00:03:01,159 --> 00:03:05,060
iguales, sean homogéneas y las versiones estén actualizadas para que luego

29
00:03:05,060 --> 00:03:08,800
no haya problemas en producción. Ansible

30
00:03:08,800 --> 00:03:12,879
en este caso se presenta como una solución a estos problemas

31
00:03:12,879 --> 00:03:17,199
ya que permite automatizar estas tareas administrativas

32
00:03:17,199 --> 00:03:20,599
y gestionar servidores y aplicaciones de forma

33
00:03:20,599 --> 00:03:21,539
eficiente.

34
00:03:25,560 --> 00:03:40,719
Vale, objetivos. El objetivo general de este proyecto es implementar una solución de automatización con Ansible y luego tenemos cuatro objetivos específicos.

35
00:03:40,719 --> 00:03:56,219
El primero sería automatizar la configuración inicial de los servidores para simplificar su instalación y su preparación. El segundo sería gestionar el mantenimiento de los sistemas aplicando actualizaciones y parches de seguridad de forma centralizada.

36
00:03:56,219 --> 00:04:17,920
El tercero sería centralizar el despliegue de las aplicaciones para garantizar que todas las implementaciones sean uniformes y estandarizadas. Y el cuarto sería validar las configuraciones mediante pruebas en un entorno controlado, o sea, asegurando que las soluciones propuestas sean efectivas antes de llevarlo a un entorno real.

37
00:04:17,920 --> 00:04:27,300
El desarrollo de este proyecto se estructuró en cinco fases principalmente

38
00:04:27,300 --> 00:04:30,459
El primero era el análisis y la planificación

39
00:04:30,459 --> 00:04:36,120
En él se analizaron los requisitos en un entorno empresarial

40
00:04:36,120 --> 00:04:40,459
Se identificaron los procesos que requerían la automatización

41
00:04:40,459 --> 00:04:45,860
Y se definió un cronograma y los recursos necesarios para cada etapa

42
00:04:46,740 --> 00:05:06,860
El segundo sería el diseño. En él se elaboró una estrategia para implementar las soluciones, incluyendo lo que es la infraestructura de VirtualBox, las máquinas virtuales, y la planificación de los flujos de trabajo. También en este punto se empezaron a documentar las configuraciones que se han ido realizando.

43
00:05:06,860 --> 00:05:26,949
El tercero, la implementación. Se configuró el entorno simulado de cinco máquinas. Una de ellas iba a ser la máquina que controlara todo y las demás serían los clientes. Y se desarrollaron playbooks, que son listas de tareas repetitivas que se ejecutan automáticamente.

44
00:05:26,949 --> 00:05:44,050
Luego, la validación y evaluación sería el cuarto. Se realizaron unas configuraciones y pruebas en un entorno simulado para medir si era eficaz y para poder realizar configuraciones por si hubiera errores.

45
00:05:45,050 --> 00:05:58,889
Luego el cinco sería la documentación y cierre. Bueno, en él se consolidaron todos los resultados de los manuales técnicos y las guías de uso y se garantizó que el usuario, o sea, perdón, el proyecto sea replicable y sostenible a largo plazo.

46
00:05:59,889 --> 00:06:05,829
Lo último serían las herramientas, que eso lo vamos a pasar a explicar en la siguiente diapositiva.

47
00:06:05,829 --> 00:06:24,170
Vale, las herramientas y tecnologías que hemos utilizado, pues por una parte sería Ansible, que es nuestra plataforma principal de automatización, que permite escribir configuraciones reutilizables y gestionar diferentes servidores de forma eficiente.

48
00:06:24,170 --> 00:06:34,170
Luego, Debian 12 sería el sistema operativo que hemos utilizado, ¿vale? Debido a que es muy estable, de la compatibilidad que tiene y que tiene buen soporte.

49
00:06:35,529 --> 00:06:46,689
Luego, VirtualBox, que va a ser nuestro software de virtualización utilizado para crear todo el entorno, o sea, la réplica del entorno empresarial.

50
00:06:46,689 --> 00:07:02,709
Y luego hemos utilizado SSH, que es el protocolo de conexión remota seguro, y YAML, que es el lenguaje en el que se escriben los playbooks de Ansible, que es muy sencillo de usar y por eso lo hemos utilizado.

51
00:07:02,709 --> 00:07:28,509
Vale, luego, en el siguiente ya sería la estimación de recursos, lo hemos estructurado en cinco fases, todo ello distribuido en nueve semanas y bueno, aquí está lo que es el diagrama que hemos puesto de las semanas con el análisis, con las fases, ¿vale?

52
00:07:28,509 --> 00:07:39,649
En la primera fase, que es el análisis y diseño, nos llevó una semana, que era la identificación de las necesidades y seleccionar los procesos que íbamos a automatizar.

53
00:07:40,509 --> 00:07:49,970
El segundo es la preparación del entorno, que han sido dos semanas, instalación y configuración de servidores y la creación de un entorno simulado en VirtualBox.

54
00:07:50,430 --> 00:08:02,170
El tercero es el desarrollo, que es la escritura de los playbooks para la configuración, para los servidores, la gestión de actualizaciones y el despliegue de las diferentes aplicaciones que hemos ido utilizando.

55
00:08:04,050 --> 00:08:12,449
Luego el cuatro son las pruebas y validación, que han sido dos semanas, y es probar que los playbooks y los procesos funcionen correctamente.

56
00:08:12,449 --> 00:08:24,410
Y luego ya por último la documentación y cierre, que ha sido una semana y en ella hemos elaborado los manuales técnicos y las guías para asegurar que el proyecto pueda continuar.

57
00:08:27,790 --> 00:08:40,509
Luego recursos mínimos serían un nodo de control con Python y SSH, un nodo que lo va a controlar. El coste ha sido cero, ya que el software que hemos utilizado ha sido todo libre.

58
00:08:40,509 --> 00:09:04,269
Y luego recursos humanos, pues dependería del tamaño y la complejidad del entorno ya real. Y nada, este cronograma nos ha permitido organizar el trabajo y asegurar el cumplimiento de todos los objetivos. Vale, la siguiente parte ya la hace mi compañero, entonces yo dejo de compartir y ya harás que él.

59
00:09:04,269 --> 00:09:06,269
Perfecto.

60
00:09:06,269 --> 00:09:09,929
vale, voy a compartir

61
00:09:09,929 --> 00:09:11,190
yo ahora entonces

62
00:09:11,190 --> 00:09:13,870
hasta aquí lo he compartido

63
00:09:13,870 --> 00:09:23,039
dentro no conozco

64
00:09:23,039 --> 00:09:25,200
en la que uso cosas, pero hasta allí sí

65
00:09:25,200 --> 00:09:28,960
abajo tiene un botón

66
00:09:28,960 --> 00:09:31,299
que es como una flecha

67
00:09:31,299 --> 00:09:32,720
así de reenviar o algo así

68
00:09:32,720 --> 00:09:35,440
sí, pero aquí tengo tres monitores

69
00:09:35,440 --> 00:09:36,759
y se me está volviendo loco

70
00:09:36,759 --> 00:09:39,080
pantalla

71
00:09:39,080 --> 00:09:52,509
No sé si se está viendo ahora.

72
00:09:54,269 --> 00:09:58,649
Vale, pues entonces vamos con la fase de análisis del proyecto.

73
00:10:00,230 --> 00:10:04,509
Vamos a empezar en la situación actual, que tenemos que...

74
00:10:08,730 --> 00:10:12,570
La gestión de infraestructuras presenta bastantes problemas críticos,

75
00:10:12,570 --> 00:10:20,710
que en un sumo de tiempo genera errores, es difícil de escalar, pues entonces por eso vamos a meternos en hacer uso de herramientas de automatización.

76
00:10:21,870 --> 00:10:31,289
Estuvimos estudiando opciones como Puppet o Gem, pero resultan más complejas, con una curva de aprendizaje más cruciante,

77
00:10:32,370 --> 00:10:40,070
entonces al final se opta por Ansible porque es más fácil de usar, no lleva agentes dedicados y usa Jamble,

78
00:10:40,070 --> 00:10:50,029
que es un lenguaje más sencillo de manejar, es más accesible. Entonces, damos todo esto con un VirtualBoss y unas Debian 12,

79
00:10:50,210 --> 00:11:02,230
que el sistema operativo es muy estable. Con el VirtualBoss simulamos un entorno empresarial y con todo esto tenemos una garantía de una compatibilidad a cualquier tema.

80
00:11:02,230 --> 00:11:21,470
Sobre el diseño, el objetivo principal es automatizar tareas críticas, con lo cual validamos las configuraciones antes de implementarlas, en producción va a eliminar bastantes errores.

81
00:11:21,470 --> 00:11:36,490
Entonces, para esto diseñamos un entorno virtual con un nodo controlador y cuatro nodos administrados que los simulamos con VirtualBox y con unas conexiones circulas entre estos equipos con SSH.

82
00:11:36,490 --> 00:11:59,190
El nodo controlador se prepara con unos inventarios y unos playbooks que definen las tareas específicas que vamos a realizar, por ejemplo, actualizaciones de sistema, despliegue de servicios. Con todo esto aseguramos una facilidad de replicación y de control del entorno.

83
00:11:59,190 --> 00:12:17,509
En el tema de despliegue y pruebas. Para esto hemos montado, hemos dicho sobre VirtualBox, cinco máquinas virtuales. Una actúa como nodo controlador y otros cuatro nodos administrados que vamos a dividir en dos servidores web y dos bases de datos.

84
00:12:17,509 --> 00:12:34,029
Todos los equipos van con Debian 12 montado y con esto empezamos a especificar, simular un pequeño, con limitaciones de potencia de las máquinas que tenemos, un entorno empresarial.

85
00:12:34,029 --> 00:12:47,669
Entonces, se crean playbooks para automatizar las tareas clave. En primer lugar, hacemos unas actualizaciones del sistema, con lo cual garantizamos que todos los nodos están al día en cuanto a actualizaciones.

86
00:12:47,669 --> 00:13:05,710
Todo esto va desde los playbooks. Como vamos a usar dos nodos como servidores web y dos nodos como servidores de base de datos, le hacemos un despliegue a un par de ellos de Apache y a los otros dos de MariaDB.

87
00:13:06,710 --> 00:13:17,389
Con lo cual así automatizamos toda la configuración de los servidores. Si en algún momento tenemos que hacer algún cambio, algún volcado de un servidor a otro, todos van a estar homogéneos.

88
00:13:17,669 --> 00:13:33,850
Todo esto pues tuvo unos resultados positivos porque unas tareas que haciéndolas manualmente nos van a requerir horas, esto son cuestión de minutos, simplemente teniendo el playbook preparado es lanzarlo y es casi inmediato.

89
00:13:33,850 --> 00:13:48,929
Las configuraciones van a ser uniformes en todos los nodos, esto nos lo garantizamos al utilizar este sistema, con lo cual no hay diferencias que pueden generar luego problemas y horas perdidas buscando dónde está el error.

90
00:13:50,090 --> 00:13:54,350
Con esto demostramos que el enfoque de automatización es efectivo.

91
00:13:56,610 --> 00:14:02,789
En cuanto al contexto laboral, la asociación tiene aplicaciones en muchos sectores.

92
00:14:02,789 --> 00:14:24,690
En los centros de datos, por supuesto, porque manejan muchos servers que tienen que estar a veces sincronizados, tienen que tener las mismas configuraciones, con todo esto, mejoramos la automatización en las empresas de desarrollo, pues es lo mismo, podemos incluso escalar, como se verá más adelante,

93
00:14:24,690 --> 00:14:27,149
el test de sistema

94
00:14:27,149 --> 00:14:28,710
incluso en los despliegues

95
00:14:28,710 --> 00:14:30,730
con lo cual se ha producido

96
00:14:30,730 --> 00:14:32,830
un entorno de desarrollo

97
00:14:32,830 --> 00:14:34,669
y pruebas mucho más ágil donde se podrá

98
00:14:34,669 --> 00:14:35,929
desplegar automáticamente

99
00:14:35,929 --> 00:14:37,629
los cambios

100
00:14:37,629 --> 00:14:40,629
en cuanto a la producción

101
00:14:40,629 --> 00:14:45,509
gestionar aplicaciones

102
00:14:45,509 --> 00:14:47,450
y redes de forma mucho más

103
00:14:47,450 --> 00:14:47,929
eficiente

104
00:14:47,929 --> 00:14:51,470
en caso de empresas pequeñas con recursos

105
00:14:51,470 --> 00:14:53,509
limitados pues también

106
00:14:53,509 --> 00:14:54,490
es una opción muy útil

107
00:14:54,490 --> 00:14:57,190
porque simplifica las tareas complejas

108
00:14:57,190 --> 00:14:58,309
que ahorra mucho tiempo.

109
00:15:00,870 --> 00:15:08,169
Ya como una opción a futuro, una ampliación de todas estas cosas, podemos integrar este sistema,

110
00:15:08,490 --> 00:15:17,629
pues por un lado con Grafana y Frometeus para llevar una estadística, un control de todas las acciones

111
00:15:17,629 --> 00:15:26,409
que se están realizando. Con Genkis y JIT nos permite automatizar el ciclo de desarrollo y despliegue

112
00:15:26,409 --> 00:15:29,990
podemos

113
00:15:29,990 --> 00:15:32,230
ampliar esto a soluciones híbridas

114
00:15:32,230 --> 00:15:33,529
cuando hay algunas

115
00:15:33,529 --> 00:15:36,389
empresas con una parte

116
00:15:36,389 --> 00:15:38,029
física y una parte de una nube

117
00:15:38,029 --> 00:15:40,129
en torno a los distribuidos, también se puede

118
00:15:40,129 --> 00:15:41,870
aplicar en todo este tema

119
00:15:41,870 --> 00:15:43,610
entonces resumiendo

120
00:15:43,610 --> 00:15:48,289
no solo es aplicable

121
00:15:48,289 --> 00:15:49,929
a pequeñas estructuras sino que es

122
00:15:49,929 --> 00:15:51,409
muy fácil de escalar

123
00:15:51,409 --> 00:15:53,610
y prepara unas infraestructuras

124
00:15:53,610 --> 00:15:55,830
más seguras y

125
00:15:55,830 --> 00:15:57,149
fácilmente escalables.

126
00:15:59,230 --> 00:16:00,389
Como conclusión,

127
00:16:00,549 --> 00:16:01,990
pues tenemos claro eso, que hay

128
00:16:01,990 --> 00:16:03,649
una reducción de errores humanos,

129
00:16:03,870 --> 00:16:05,870
de tareas manuales, con lo cual ahorramos tiempo

130
00:16:05,870 --> 00:16:06,370
y recursos.

131
00:16:07,590 --> 00:16:09,809
Las configuraciones que vayamos a aplicar van a

132
00:16:09,809 --> 00:16:11,169
tener una consistencia

133
00:16:11,169 --> 00:16:13,970
y se pueden

134
00:16:13,970 --> 00:16:15,610
minimizar los riesgos antes de la

135
00:16:15,610 --> 00:16:17,590
implementación con unos entornos simulados.

136
00:16:18,450 --> 00:16:19,590
Entonces, esto creemos que hace

137
00:16:19,590 --> 00:16:21,129
de Ansible una solución

138
00:16:21,129 --> 00:16:23,570
buena para una gestión de infraestructuras

139
00:16:23,570 --> 00:16:25,669
modernas. Y con esto

140
00:16:25,669 --> 00:16:28,090
terminamos, que creo que vamos justo de tiempo

141
00:16:28,090 --> 00:16:32,000
y hasta aquí ha estado

142
00:16:32,000 --> 00:16:33,200
la presentación

143
00:16:33,200 --> 00:16:37,759
Voy a hacer

144
00:16:37,759 --> 00:16:39,759
unas preguntas para

145
00:16:39,759 --> 00:16:42,519
ver un poquito

146
00:16:42,519 --> 00:16:43,600
la autoría, nada más

147
00:16:43,600 --> 00:16:46,419
entonces ocupan aproximadamente 5 minutos

148
00:16:46,419 --> 00:16:48,539
voy a hacer 5 preguntas

149
00:16:48,539 --> 00:16:49,539
para que respondáis

150
00:16:49,539 --> 00:16:51,779
una en cada minuto aproximadamente

151
00:16:51,779 --> 00:16:54,659
sobre la justificación

152
00:16:54,659 --> 00:16:57,179
para Raquel

153
00:16:57,179 --> 00:17:04,200
¿Por qué elegisteis Ansible en lugar de otras herramientas de automatización como Puppet o Chef?

154
00:17:04,599 --> 00:17:16,220
Elegimos esta herramienta porque era fácil de manejar y era fácil de aprender y bueno, también porque era gratuita.

155
00:17:16,220 --> 00:17:25,279
Entonces es una herramienta que haciendo las pruebas que hicimos vimos que era fácil de utilizar sobre todo

156
00:17:25,279 --> 00:17:42,720
Y eso que era, o sea, poniéndolo en un entorno real sí que podría ser útil porque haciendo pruebas vimos que, por ejemplo, ahorraba mucho tiempo a la hora de lanzar actualizaciones en diferentes equipos y eso.

157
00:17:42,720 --> 00:18:03,200
Para José Andrés, sobre la implementación, ¿cómo aseguras que las configuraciones aplicadas a los nodos sean consistentes y no generen errores?

158
00:18:03,200 --> 00:18:07,900
Bueno, eso viene implícito

159
00:18:07,900 --> 00:18:08,740
En el propio sistema

160
00:18:08,740 --> 00:18:10,220
Si tenemos un playbook

161
00:18:10,220 --> 00:18:12,960
Que gestiona unas configuraciones

162
00:18:12,960 --> 00:18:15,759
Cuando lo lanzas

163
00:18:15,759 --> 00:18:16,579
Tienes un log

164
00:18:16,579 --> 00:18:17,519
Si no hay un error

165
00:18:17,519 --> 00:18:20,619
Se entiende que las configuraciones

166
00:18:20,619 --> 00:18:21,519
Que tú has lanzado

167
00:18:21,519 --> 00:18:23,099
Se están aplicando en todos los nodos

168
00:18:23,099 --> 00:18:24,319
Perfecto

169
00:18:24,319 --> 00:18:25,819
Eso es lo que me estás preguntando

170
00:18:25,819 --> 00:18:26,819
No he entendido muy bien

171
00:18:26,819 --> 00:18:27,799
Sí, sí

172
00:18:27,799 --> 00:18:30,740
Cómo asegurar que no tienen errores

173
00:18:30,740 --> 00:18:31,779
Y que todo funcione

174
00:18:31,779 --> 00:18:42,900
Realmente se comprueba, claro, Ansible, pues incluso puedes configurar unas alarmas que te envían un correo cuando se produce un problema. Entonces en ese momento sabes que hay alguna configuración que se ha quedado mal.

175
00:18:44,059 --> 00:18:51,259
Pero realmente el mismo sistema lleva implícito que las configuraciones son consistentes porque se las está aplicando igual a todos los equipos.

176
00:18:51,259 --> 00:19:03,740
Perfecto. Sobre la planificación, para Raquel. ¿Qué estrategias habéis seguido para planificar las tareas automatizadas y minimizar el impacto en la infraestructura?

177
00:19:06,599 --> 00:19:09,420
¿Qué estrategias? No entiendo la pregunta.

178
00:19:10,140 --> 00:19:12,279
Sí, estrategias de qué forma.

179
00:19:14,279 --> 00:19:15,900
No te oigo, perdona.

180
00:19:16,039 --> 00:19:16,940
Se te va la voz.

181
00:19:17,180 --> 00:19:18,039
¿Ahora? ¿Mejor?

182
00:19:18,240 --> 00:19:19,220
Ahora sí, sí.

183
00:19:19,220 --> 00:19:26,740
Para planificar tareas automatizadas, ¿qué es lo que habéis hecho?

184
00:19:26,740 --> 00:19:46,880
Para planificarla, pues lo que pensamos era un entorno de pruebas, entonces lo que pensamos fue en hacer diferentes pruebas, en ellas pues era actualización de equipos, instalación de Apache e instalación de una base de datos.

185
00:19:46,880 --> 00:19:55,059
Entonces, pues montamos lo que son los playbooks y hicimos pruebas con eso. Es que no sé si esa es la pregunta.

186
00:19:55,319 --> 00:20:05,700
Sí, sí. Para José Andrés, sobre la escalabilidad. ¿Cómo se podría adaptar este proyecto a un entorno empresarial más grande?

187
00:20:08,019 --> 00:20:16,660
Bueno, depende exactamente de qué se quiera conseguir. La escalabilidad en cuanto a número de máquinas simplemente es añadir en el inventario máquinas.

188
00:20:16,880 --> 00:20:46,859
Se va a desplegar máquinas cañadas en el inventario, lo que comentábamos, opciones de que se quieran implementar otro tipo de cosas como grafana para gestionar, para vigilar el rendimiento de los equipos o que quiera integrar un gibla para despliegues, pero en principio la estabilidad no aplica, no tiene más limitaciones que la capacidad del nodo que hace la instalación.

189
00:20:46,880 --> 00:20:50,960
gestiones que se podría ampliar hasta que se delimite.

190
00:20:51,180 --> 00:21:05,680
Perfecto. Y en cuanto a la última pregunta, en cuanto a la validación, ¿qué métricas habéis utilizado para evaluar el rendimiento de la automatización?

191
00:21:05,680 --> 00:21:13,519
¿Habéis utilizado alguna métrica en concreto para evaluar el rendimiento para cualquiera de los dos, como es la última y quinta?

192
00:21:13,519 --> 00:21:40,339
En principio no hemos usado ningún tipo de métrica estandarizada. Simplemente es una cuestión de tiempos y de lógicas. Se puede ver que el tiempo que llevaría a gestionar cualquier configuración a mano, en este caso es un entorno pequeño y solo son cuatro servidores, pero si se llama un entorno más lógico de una empresa pequeña con 20 o 30 máquinas, a lanzar un playbook.

193
00:21:40,339 --> 00:21:42,700
Hace falta una métrica aquí.

194
00:21:44,400 --> 00:21:50,460
Vale. Bueno, pues con esto quedaría terminada la presentación del proyecto.