[bws_linkedin display=»share»]
En el artículo anterior vimos que podemos abordar la disponibilidad en tres momentos distintos. Ahora hay que hablar del de qué. Es decir, tenemos que definir muy claramente a qué recurso nos referimos cuando decimos la disponiblidad es 99,998%. Ya lo hemos dicho anteriormente, dependerá de quién seamos y qué hagamos: un DataCenter que preste servicios de housing querrá demostrar que es capaz de mantener los racks en condiciones operativas un determinado porcentaje de tiempo. Esto es muy importante en función de cuál sea el alcance de la responsabilidad de cada uno: el rack puede estar perfecto, pero si la aplicación está colgada hay un problema. Hay que tener en cuenta que en el mundo cloud moderno, la pila IT puede tener diversos responsables: uno para las infraestructuras de datacenter, otro para la plataforma hardware y networking, otro para el software, etc. Para cada uno de ellos, el concepto disponibilidad tendrá un alcance diferente en función de cuál sea el recurso en cuestión.
Por esta razón es muy importante que cuando hablemos de disponibilidad delimitemos bien su alcance, es decir, el de qué. Pero, también hay que definir con precisión disponible, o lo que es lo mismo, cómo vamos a medir la disponibilidad. Como la mayoría de los técnicos de sistemas saben, una de las herramientas más utilizadas para monitorizar disponibilidades ha sido Nagios. Es software libre y fácil de utilizar, aunque sus ficheros de configuración son farragosos. Nagios ha tenido la gran virtud de extender la monitorización, y muchos sitios se han empezado a monitorizar gracias a Nagios (o lo que es lo mismo, sin Nagios no se hubieran monitorizado, lo que es terrible). Pero Nagios está muy orientado a monitorizar utilizando «pings», con un algoritmo muy sencillo: si responde, está vivo. Este es el método que muchos utilizan para comprobar la disponibilidad, pero no tienen en cuenta que vivo no es lo mismo que disponible. Muchas veces los dispositivos responden al ping, pero no están disponibles. Le hago ping al servidor web y el servidor responde, pero eso no significa que el servidor esté bien.
Por eso hay que definir con precisión qué significa estar disponible, y esto es la letra pequeña del SLA. Si seguimos con el ejemplo del servidor web, podríamos decir algo como: se comprueba mediante un comando HTTP GET que el servidor responde, que devuelve la página principal comprobando con el patrón que no ha sido modificada por un hacker y que la respuesta se produce en menos de x milisegundos. Aquí podemos ser tan barrocos como queramos, comprobando todo el árbol web o no, controlando desde el tiempo de respuesta a la introducción de datos en formularios, etc.
Bien, pues esto hay que hacerlo independientemente del alcance. Traslademos el ejemplo del web a un prestador de servicios de housing. En este caso, el SLA hará mención de las infraestructuras: Cada rack dispondrá de alimentación de 220V con una capacidad de 32A (o 16, o 64, o 96 o lo que corresponda), con una temperatura inferior o igual a…, etc., etc.
En resumidas cuentas, cuando medimos disponibilidades tenemos que leer la letra pequeña del SLA a que nos hayamos comprometido y adoptar las medidas técnicas para poder demostrar fehacientemente con medidas que estamos cumpliendo nuestra parte. En este punto, hay quienes optan por SLA’s poco claros en los que no se explicita con precisión el alcance del servicio que se presta. Bien, esto es un gran error estratégico: si lo hacemos así en cuanto haya discrepancias no podremos demostrar que estamos cumpliendo y, como el cliente o el usuario siempre tienen la razón, tendremos problemas.
En resumen, el problema de la disponibilidad lo debemos abordar en tres momentos:
- Al establecer el Acuerdo de Nivel de Servicio (SLA) que prestaremos a nuestros clientes y/o usuarios: ya dijimos que siempre debemos tener explicitado el SLA aunque trabajemos para nuestra propia organización.
- Al diseñar las infraestructuras y sistemas que utilizaremos para prestar los servicios.
- Una vez que están los servicios en producción deberemos realizar medidas reales para poder corroborar con datos que estamos cumpliendo nuestra parte del trato.
Transversalmente a estas etapas debemos dejar clara la definición de recurso y la definición de disponible, pues juntas forman el alcance de los servicios que vamos a prestar.
¿Es esto todo? ¡No, se escapa un pequeño detalle! Este detalle es el concepto novedoso del que os hablaba en el artículo anterior y que explicaré con profundidad en el próximo artículo.
