Todo plan de recuperaci\u00f3n se apoya en dos n\u00fameros. El RTO, que es el tiempo m\u00e1ximo aceptable entre la ca\u00edda y el regreso del servicio, y el RPO, que es la p\u00e9rdida m\u00e1xima de datos aceptable, medida en tiempo. Casi toda empresa mediana o grande tiene esos dos n\u00fameros escritos en alg\u00fan documento.<\/p>\n\n\n\n
Lo que casi ninguna puede mostrar es c\u00f3mo lleg\u00f3 a ellos.<\/p>\n\n\n\n
La diferencia importa porque un n\u00famero sin m\u00e9todo no sobrevive al primer incidente. Se defini\u00f3 en una reuni\u00f3n, por consenso, y el d\u00eda de la crisis se descubre que la arquitectura nunca se dimension\u00f3 para cumplirlo, o que el plazo prometido no inclu\u00eda la mitad del trabajo que exige la vuelta a la operaci\u00f3n. Este art\u00edculo trata del m\u00e9todo: de d\u00f3nde sale cada n\u00famero, qui\u00e9n responde por \u00e9l y c\u00f3mo verificar que tiene sentido antes de convertirse en compromiso.<\/p>\n\n\n\n
Si la duda todav\u00eda est\u00e1 un paso atr\u00e1s, en qu\u00e9 es un plan de recuperaci\u00f3n y qu\u00e9 entra en \u00e9l, el art\u00edculo sobre DRP<\/a> cubre esa capa.<\/p>\n\n\n\n Este es el error m\u00e1s com\u00fan, y no parece un error.<\/p>\n\n\n\n TI le pregunta al negocio cu\u00e1nto tiempo aguanta la operaci\u00f3n sin el sistema. El negocio responde 72 horas. TI anota un RTO de 72 horas. Todos salen conformes de la reuni\u00f3n.<\/p>\n\n\n\n El n\u00famero que acaban de definir no es el RTO. Es el MTD.<\/p>\n\n\n\n El NIST SP 800-34 Rev. 1<\/a>, gu\u00eda de planificaci\u00f3n de contingencia del instituto de est\u00e1ndares estadounidense, separa los dos con claridad. El MTD, Maximum Tolerable Downtime, es el tiempo total de indisponibilidad que el responsable del sistema est\u00e1 dispuesto a aceptar, con todos los impactos considerados. El RTO es el tiempo m\u00e1ximo que un recurso puede quedar indisponible antes de que haya un impacto inaceptable sobre los dem\u00e1s recursos, sobre los procesos de negocio y sobre el propio MTD.<\/p>\n\n\n\n La frase del documento que resuelve la confusi\u00f3n es esta: como el RTO tiene que garantizar que el MTD no se exceda, el RTO normalmente debe ser m\u00e1s corto que el MTD.<\/p>\n\n\n\n El motivo es pr\u00e1ctico. Entre que el sistema vuelve a responder y la operaci\u00f3n vuelve a funcionar hay trabajo. Los registros hechos a mano durante la ca\u00edda hay que digitarlos. Las integraciones que quedaron detenidas tienen que procesar la cola acumulada. Alguien tiene que verificar que los saldos cierren antes de liberar la facturaci\u00f3n. Ese tiempo no es de TI, pero consume el mismo reloj.<\/p>\n\n\n\n Entonces, si el negocio aguanta 72 horas y la conciliaci\u00f3n lleva 24, el RTO es de 48 horas. El ejemplo que el propio NIST usa en su plantilla de an\u00e1lisis de impacto es exactamente ese: proceso de pago a proveedor con MTD de 72 horas, RTO de 48 horas y RPO de 12 horas.<\/p>\n\n\n\n La cuenta es simple. Hacerla en el orden equivocado es lo que produce planes que fallan dentro del plazo prometido.<\/p>\n\n\n\n Lo segundo que atrasa el trabajo es preguntar cu\u00e1l es el RTO del ERP.<\/p>\n\n\n\n Nadie sabe responder eso, y quien responde est\u00e1 adivinando. El ERP sostiene facturar, comprar, pagar, cerrar el mes y consultar hist\u00f3ricos, y esos cinco procesos tienen tolerancias completamente distintas. Facturar no espera un d\u00eda. Consultar hist\u00f3ricos espera una semana sin que nadie lo note.<\/p>\n\n\n\n El NIST organiza el an\u00e1lisis de impacto en tres pasos, y el primero es determinar los procesos de negocio y la criticidad de la recuperaci\u00f3n. La unidad de an\u00e1lisis es el proceso, no el servidor. Solo despu\u00e9s vienen los recursos que cada proceso consume, y por \u00faltimo el orden de recuperaci\u00f3n de esos recursos.<\/p>\n\n\n\n En la pr\u00e1ctica esto invierte la conversaci\u00f3n. En lugar de listar sistemas y preguntar cu\u00e1nto aguanta cada uno, se lista lo que la empresa hace, se descubre cu\u00e1nto aguanta cada actividad, y reci\u00e9n ah\u00ed se mapea de qu\u00e9 sistemas depende cada una. El RTO de un servidor pasa a ser consecuencia: es el plazo m\u00e1s ajustado entre los procesos que dependen de \u00e9l.<\/p>\n\n\n\n El efecto colateral es bienvenido. Cuando el n\u00famero sale del proceso, deja de ser opini\u00f3n de TI y pasa a tener due\u00f1o en el \u00e1rea de negocio.<\/p>\n\n\n\n En la primera ronda, todo es cr\u00edtico. Eso no es mala voluntad, es falta de escala. Sin una vara com\u00fan, \"cr\u00edtico\" es la \u00fanica palabra disponible para decir \"es importante para m\u00ed\".<\/p>\n\n\n\n El NIST lo resuelve pidiendo que la organizaci\u00f3n cree categor\u00edas de impacto y les asigne valores, de modo que se pueda medir el nivel de severidad que causar\u00eda una ca\u00edda. El ejemplo del documento usa el costo como categor\u00eda, con tres rangos: severo, cuando las horas extra, la contrataci\u00f3n temporal y las multas pasan de un mill\u00f3n de d\u00f3lares; moderado, en el orden de los quinientos cincuenta mil; y m\u00ednimo, en el orden de los setenta y cinco mil. La gu\u00eda es expl\u00edcita al decir que esas cifras son solo un ejemplo y deben revisarse para reflejar la realidad de cada organizaci\u00f3n.<\/p>\n\n\n\n El valor de esa vara no est\u00e1 en la precisi\u00f3n. Est\u00e1 en obligar a comparar. Cuando dos \u00e1reas tienen que ubicar su propio proceso en la misma escala de dinero, la lista de prioridades aparece sola.<\/p>\n\n\n\n Tres preguntas que funcionan mejor que \"es cr\u00edtico\":<\/p>\n\n\n\n \u00bfQu\u00e9 pasa en la cuarta hora?<\/strong> La pregunta gen\u00e9rica recibe una respuesta gen\u00e9rica. La pregunta con hora marcada recibe un escenario: en la cuarta hora el transportista se va sin cargar, y la entrega se atrasa un d\u00eda.<\/p>\n\n\n\n \u00bfExiste una forma manual de seguir?<\/strong> Si existe, el MTD es m\u00e1s largo de lo que parec\u00eda. Si no existe, es m\u00e1s corto. El NIST pide esa informaci\u00f3n de forma expl\u00edcita en el relevamiento, y es la respuesta que m\u00e1s mueve los n\u00fameros.<\/p>\n\n\n\n \u00bfCu\u00e1nto tiempo aguanta la forma manual?<\/strong> Un cuaderno y una planilla funcionan por algunas horas. Despu\u00e9s de eso, la cola de digitaci\u00f3n pasa a ser el nuevo problema, y ese tiempo se descuenta del MTD.<\/p>\n\n\n\n El RPO suele tratarse como un par\u00e1metro t\u00e9cnico de la rutina de copia. No lo es.<\/p>\n\n\n\n El NIST es directo en dos puntos. El primero: el RPO representa el punto en el tiempo, anterior a la ca\u00edda, hasta el cual los datos del proceso deben recuperarse, considerando la copia m\u00e1s reciente disponible. El segundo, que casi siempre pasa inadvertido: a diferencia del RTO, el RPO no se considera parte del MTD. Es un factor aparte, de cu\u00e1nta p\u00e9rdida de datos tolera el proceso.<\/p>\n\n\n\n Eso tiene una consecuencia pr\u00e1ctica. Quien responde el RPO no es quien administra el backup, es quien va a redigitar. La pregunta correcta es cu\u00e1ntas horas de registros puede rehacer el equipo a mano sin frenar el resto del trabajo, y con qu\u00e9 riesgo de error.<\/p>\n\n\n\n Y hay una prueba de honestidad que conviene hacer antes de publicar el n\u00famero. El RPO no puede ser menor que el intervalo entre las copias. Un RPO de quince minutos con backup nocturno es una intenci\u00f3n, no una capacidad. Si el n\u00famero que el negocio necesita es m\u00e1s corto que la ventana actual, la conversaci\u00f3n dej\u00f3 de ser sobre el n\u00famero y pas\u00f3 a ser sobre cambiar la tecnolog\u00eda de copia, que es lo que detalla el art\u00edculo sobre backup en la nube<\/a> .<\/p>\n\n\n\n Definido el MTD por proceso, derivado el RTO y acordado el RPO, falta la parte que el negocio no tiene c\u00f3mo saber solo: cu\u00e1nto cuesta cada rango.<\/p>\n\n\n\n El NIST describe esto como un balance de costos. Cuanto m\u00e1s larga la ca\u00edda, m\u00e1s caro el perjuicio. Cuanto m\u00e1s corto el RTO, m\u00e1s caras las soluciones de recuperaci\u00f3n. El documento observa que el punto de equilibrio entre esas dos curvas es distinto para cada organizaci\u00f3n y cada sistema, porque depende de las restricciones financieras y de los requisitos de operaci\u00f3n.<\/p>\n\n\n\n Para convertir eso en orden de magnitud, la documentaci\u00f3n de arquitectura de AWS publica los rangos que cubre cada estrategia en REL13-BP02<\/a>:<\/p>\n\n\n\n Esos rangos sirven como verificaci\u00f3n, no como cat\u00e1logo. Si el negocio pidi\u00f3 un RTO de diez minutos y la arquitectura actual es backup y restauraci\u00f3n, la distancia no se cubre con esfuerzo el d\u00eda del incidente. Se cubre con inversi\u00f3n, o el n\u00famero cambia.<\/p>\n\n\n\n Vale registrar tambi\u00e9n lo que los proveedores no garantizan. Microsoft afirma en la documentaci\u00f3n de su framework de arquitectura que publica garant\u00edas de RTO y RPO solo para algunos productos. Para el resto, el n\u00famero es responsabilidad de quien dise\u00f1\u00f3 la soluci\u00f3n, y no del contrato de servicio.<\/p>\n\n\n\n \u00bfY cu\u00e1ndo no se puede? El NIST prev\u00e9 el caso: cuando no es viable cumplir el RTO de inmediato y el MTD es inflexible, la situaci\u00f3n debe documentarse formalmente, con un plan de acci\u00f3n e hitos para corregirla. Registrar la brecha es una decisi\u00f3n defendible. Escribir un n\u00famero que nadie puede cumplir no lo es.<\/p>\n\n\n\n Existe una contradicci\u00f3n que aparece en casi todo documento de requisitos y casi nunca se nota, porque los dos n\u00fameros viven en p\u00e1ginas distintas.<\/p>\n\n\n\n En una p\u00e1gina est\u00e1 la meta de disponibilidad, normalmente 99,9%. En la otra est\u00e1 el RTO, normalmente algunas horas.<\/p>\n\n\n\n La tabla de objetivos de nivel de servicio del framework de arquitectura de Microsoft<\/a> muestra lo que permite 99,9%: 43,20 minutos de indisponibilidad por mes, u 8,76 horas por a\u00f1o.<\/p>\n\n\n\n Compare con el RTO. Un solo incidente que consuma un RTO de cuatro horas ya gasta casi la mitad del presupuesto anual de indisponibilidad de una meta de 99,9%. Dos incidentes as\u00ed en el a\u00f1o revientan la meta, aunque los dos se hayan atendido exactamente dentro del plazo acordado.<\/p>\n\n\n\n No es que uno de los n\u00fameros est\u00e9 equivocado. Es que falt\u00f3 el tercero: cu\u00e1ntos incidentes por a\u00f1o supone la meta. Sin \u00e9l, los dos primeros no se hablan, y la empresa cumple el RTO e incumple la meta en el mismo incidente.<\/p>\n\n\n\n En la definici\u00f3n del NIST, el MTD es el tiempo que el responsable del sistema est\u00e1 dispuesto a aceptar. Est\u00e1 dispuesto, en singular. Es una persona, no un comit\u00e9.<\/p>\n\n\n\n Eso tiene efecto pr\u00e1ctico en tres momentos. En la definici\u00f3n, porque alguien tiene que bancar la elecci\u00f3n cuando aparece el costo de la arquitectura. En el incidente, porque es quien autoriza el regreso a la operaci\u00f3n normal. Y en la revisi\u00f3n, porque el n\u00famero envejece: un proceso que cambi\u00f3 de volumen, un sistema que gan\u00f3 una integraci\u00f3n nueva, una operaci\u00f3n que pas\u00f3 a atender otro huso horario.<\/p>\n\n\n\n Por eso la planilla de criticidad necesita tres columnas que suelen faltar: el nombre de quien respondi\u00f3, la fecha de la respuesta y qu\u00e9 dispara una nueva revisi\u00f3n.<\/p>\n\n\n\n Empezamos por el relevamiento con las \u00e1reas de negocio, proceso por proceso, con la vara de impacto armada antes de la primera reuni\u00f3n. De esa etapa sale el MTD de cada proceso, con due\u00f1o y fecha.<\/p>\n\n\n\n Despu\u00e9s mapeamos las dependencias de cada proceso y derivamos el RTO por recurso, descontando el tiempo de reprocesamiento y verificaci\u00f3n. El RPO se acuerda con quien hace la carga de datos, y se verifica contra la ventana real de las copias.<\/p>\n\n\n\n Con los n\u00fameros cerrados, presentamos lo que cada rango exige de arquitectura y de inversi\u00f3n, y d\u00f3nde hay brecha entre lo que se pidi\u00f3 y lo que la infraestructura actual entrega. El resultado es una tabla corta, de proceso, MTD, RTO, RPO y estrategia, que cabe en una p\u00e1gina y sirve de base para el plan de recuperaci\u00f3n.<\/p>\n\n\n\n Si su empresa ya tiene RTO y RPO definidos, vale una prueba r\u00e1pida: tome el n\u00famero de un proceso e intente responder qui\u00e9n lo defini\u00f3, en qu\u00e9 fecha, y si descuenta el tiempo de reprocesamiento. Si las tres respuestas no aparecen, el n\u00famero necesita revisi\u00f3n antes de cualquier inversi\u00f3n en arquitectura.<\/p>\n\n\n\n Para entender d\u00f3nde entran estos n\u00fameros en el plan completo, el art\u00edculo sobre DRP<\/a> trata la estructura del documento y la frecuencia de prueba. Para la capa de copias, que es donde el RPO se cumple o no, el art\u00edculo sobre backup en la nube<\/a> cubre la retenci\u00f3n y la regla 3-2-1.<\/p>\n\n\n\nPrimero viene el MTD, y no es el RTO<\/h2>\n\n\n\n
La pregunta no es sobre el sistema, es sobre el proceso<\/h2>\n\n\n\n
C\u00f3mo convertir \"es cr\u00edtico\" en un n\u00famero comparable<\/h2>\n\n\n\n
El RPO es una pregunta sobre retrabajo, no sobre backup<\/h2>\n\n\n\n
La prueba de realidad: \u00bfel n\u00famero cabe en la tecnolog\u00eda y en el presupuesto?<\/h2>\n\n\n\n
\n\n
El RTO y la meta de disponibilidad tienen que cerrar<\/h2>\n\n\n\n
Qui\u00e9n firma el n\u00famero<\/h2>\n\n\n\n
C\u00f3mo conduce Integrity-UX este trabajo<\/h2>\n\n\n\n
Pr\u00f3ximos pasos<\/h2>\n\n\n\n