[:es]Es muy probable que hayas experimentado un sistema caído, ya sea una aplicación en la que has trabajado o algún servicio que consumes. Le ha pasado a Amazon, Netflix, Microsoft, Salesforce, etc. ¿Cuánto tuviste que esperar? o ¿cuánto tus usuarios?
Si al estar construyendo una aplicación le preguntas a tu jefe (o cliente) qué porcentaje de tiempo la aplicación debe estar disponible, lo más seguro es que recibas respuestas como “siempre” o “100% (o más)”.
Aunque no queremos que pasen cosas malas, pasarán: bugs, ataques, fallas de corriente, desastres naturales, etc., son escenarios que pueden afectar un sistema. Esperar que no pases es ingenuo; es mejor pensar en y planear para los fallos, ya que son inevitables.
Disponibilidad (availability) es la capacidad de una aplicación de estar disponible después y a pesar de que un problema ocurre. Repito, no estamos diciendo que no habrá problemas, sino que tan efectivamente podrá recuperarse. Esto significa que tenemos que a) identificar los puntos de falla potenciales y b) crear una estrategia para prevenir que el error se convierta en una falla afectando al usuario (un árbol que cae en el bosque cuando no hay nadie, no hace ruido).
Regresando a la pregunta acerca del nivel que la aplicación necesita estar disponible, es importante enteder como se traduce a tiempos:
| Disponibilidad | Tiempo sin funcionar |
|---|---|
| 99% | 3d 15h 36m |
| 99.9% | 8h 0m 45s |
| 99.99% | 52m 36s |
| 99.999% | 5m 15s |
Esto significa que si tu meta es 99.99% necesitas poder recuperarte en menos de una hora si tienes sólo un incidente durante el año, menos de 30 min si tienes dos, y así sucesivamente. Es importate notar que los valores de downtime no incluyen bajas planeadas, como cuando se actualiza la aplicación, se parcha el sistema operativo, migración de base de datos, etc.
Contrato de nivel de servicio
Teniendo una meta de disponibilidad (%) lleva a preguntar, ¿qué pasa si no se alcanza? Aqui es cuando los contratos de nivel de servicio (Service Level Agreements, en inglés) entran en juego. Son contratos o acuerdos entre dos partes que declaran el tiempo de disponibilidad prometido y cual será la penalización aplicada si no se cumple. Por ejemplo Microsoft declara en SLA for Azure App Services que podrías ser elegible por un crédito del 10% si no mantienen un nivel de disponibilidad de al menos 99.95% y de 25% si no mantienen al menos 99%.
Estrategias
Lo más “fácil” del problema es manejar las excepciones de manera apropiada (a algunos nos tocó el típico OnError Resume Next), pero hay muchas otras amenazas que pueden afectar la disponibilidad de tu aplicación:
- Ataques de DDoS tumbando tu servidor.
- SQL injection, eliminando todo el contenido de tu base de datos.
- Inundaciones, huracanes y otros desastres naturales provocando fallas de energía masivas.
Incluso cuando son eventos externos o de seguridad producen el mismo resultado: que la aplicación no esté disponible. A los usuarios no les interesa el porqué, pero a tí sí; necesitas pensar en maneras para evitar que esto pase. Hay muchas estrategias posibles a utilizar, pero pueden ser organizadas principalmente en:
- Prevención: Asegurar que se está pensando en los errores potenciales antes de que aparezcan; esto significa manejar las excepciones de manera apropiada, identificar los puntos de fallo únicos, usar árboles de fallo para identificar potenciales cadenas de errores, eliminar elementos que puedan causar un problema, etc.
- Detección: Asegurar que se está al tanto del error en el momento adecuado; herramientas de monitoreo como Nagios son un buen ejemplo.
- Corrección: Una vez que el problema sucede, necesita resolverse: restaurar un respaldo, moverse a diferente servidor, encender una planta de emergencia, etc.
(Si estas trabajando con Microsoft Azure, Security Center te ayuda a identificar amenazas en las tres categorías)
Backups always succeed, it’s Restores that fail. Test them. http://t.co/nzoti3LSur
— Scott Hanselman (@shanselman) July 3, 2014
Como puede verse, esto significa que se tiene que pensar en más cosas que sólamente tu código. Por ejemplo, ¿qué pasa si tu aplicación maneja las excepciones correctamente pero hay una falla de hardware en tu servidor o data center? o si alguien que tiene las credenciales de la base de datos de producción ejecuta delete from table sin filtro. Parecen casos extremos, pero los he visto suceder en el pasado.
Costos
Como he mencionado en otros posts, arquitectura es balance, y esto no es la excepción. Apuntar a una meta de disponibilidad implica aplicar estrategias que potencialmente resultan en un costo. Por ejemplo, alta disponibilidad significa generalmente cinco nueves (99.999%) y con ello implica un poco más de cinco minutos de downtime total durante un año. Esto implica establecer varias estrategias que pueden incrementar el costo del proyecto. También está el hecho de ceder; no puedes buscar alta disponibilidad sin impactar otros atributos de calidad como modificabilidad o mantenibilidad.
No cualquier sistema require ese nivel de disponibilidad, yo creo que muchos pueden sobrevivir con dos o tres nueves. También está el tema del ambiente; no es lo mismo que un sistema de nómina falle en día de pago que en cualquier otro día.
Así que la vez que estés discutiendo con un cliente acerca de disponibilidad, asegúrate de preguntar “¿Cuántos nueves?”.
Buen artículo. Y agregaría la importancia de un assessment de posibilidades ante amenazas para que el estudio sea realmente efectivo. Seguridad un sistema para su disponibilidad es uno de los principios a proteger en el área, pero el invertir en seguridad para amenazas de poca probabilidad puede llegar a ser un hoyo más en el saco de papas.
Saludos!
Muy cierto, seguridad y disponibilidad van completamente de la mano.
Gracias!