Buenas,

Dejo mi resolución del final de hoy, clave un 8, así que supongo que debe estar bien , si alguno sabe la respuesta oficial, bienvenido.

1-A. Falsa, si bien la planificación de los riesgos se hace el principio, es un proceso continuo, que se hace durante todo el ciclo de vida del proyecto, y el plan de mitigacion y contingencia debe mantenerse actualizado.

1-B. Falsa, si bien teniendo nuestro datacenter tenemos mayor control sobre los datos, no siempre va a convenir esa solución. Por ejemplo, si tenemos un pico de demanda en el servidor, una infraestructura cloud podría permitirnos manejar esa demanda.

2-A.
I- Falso, no siempre hay que usarlos. No me aseguran nada.
II- Verdadera, hay que planificar la replicacion de los servicios en una nueva infraestructura.
III- Falso, no se vuelve a hacer un rollback en el DC original, pq en ese datacenter ocurrio un desastre.

2-B.
I- Verdadero, Debemos definirle al cliente en caso de un accidente, cuanta data podria llegar a perder.
II- Verdadero, Debemos definirle al cliente en caso de un accidente, cuanto tiempo podria llegar a tardar en restablecer el servicio.
III- Falso, debemos definir un service level agreement para ofrecer el servicio.

3- (Subi la imagen)
Empece hablando de la cantidad de request http que la plataforma debe manejar, y definí de usar un balanceador de carga entre varios servidores, también debía manejar un gran volumen de información, por lo que mas se recomienda son las bases de datos NO SQL q operan en un cluster. Al usar bases de datos no distribuidas, tenemos el beneficio de:
- Alta disponibilidad: Por mas que un nodo se caiga, podemos ir a buscar la información a otro.
- Escalabilidad: Si queremos aumentar la capacidad de almacenamiento y procesamiento, podemos aumentar la cantidad de nodos, haciendo un escalamiento horizontal.
- Tolerancia a fallos: Por mas que se caiga una red de nodos, el sistema se mantiene operativo.
Al pedirnos que elaboremos una solución económica, lo mejor seria optar por montar la base de datos NO SQL en un cluster en la nube, en ves de proponer nuestro propio data center.
Al no definirme que tipo de plataforma se necesita, podemos implementar una WEB API para exponer los endpoints que se deben consumir desde el celular.
El balanceador de carga tambien nos provee alta disponibilidad y toleracion a fallos, porque en caso de que un servidor se caiga, iriamos al siguiente.

4- Tabla de pesos relativos/ valoracion de atributos: (attacheado)
Item
-BASE DE DATOS
. DB no relacional en memoria ( si / no )
- POST-VENTA
. Atención telefónica ( sin - 0% / [9hs, 18hs] - 50% / las 24 hs - 100% )
- FACTURACIÓN
. Tarifa plana mensual ( si/ no )
- COSTO

era mas fácil y corto que usualmente o me parece?

(12-12-2019 14:05)Ruben Maier Enzler escribió:  era mas fácil y corto que usualmente o me parece?

Es muy subjetivo esto, a mi me parecio facil (era mi 3er intento, jaja), pero hubo de todo, algunos se fueron, otros desaprobaron y muchos aprobaron pero me parece que el 6 reinaba.

Y uno se recibió ahi

No entendí la pregunta 2aIII
Planificar el rollback no es parte del plan de recuperación de desastres ? Está incluida en el RTO también creo