Seleccionar página

No es cloud todo lo que reluce

 

 

 

 

Nace www.top500.es

Ayer, tuve una participación en el evento Grandes infraestructuras tecnológicas en la nueva era digital: Eficientes energéticamente y sostenibles (una vez más enhorabuena a Óscar Azorín y su equipo por una organización perfecta). En concreto, participé en la primera sesión, que tenía por título Supercomputación: liderando la sostenibilidad en la nueva era digital. Mi participación la titulé Supercomputación, métricas y eficiencia.

En la primera parte de mi intervención, conté la iniciativa www.top500.es. El propósito es crear un portal con la lista de los 500 sistemas de cálculo más potentes de los países de habla hispana. Algunos os preguntaréis el por qué de esta iniciativa, que a surgido a raíz de un trabajo que he tenido que realizar en los últimos meses: ayudar a un Centro de Supercomputación a diseñar su estrategia, la arquitectura del nuevo sistema que van a adquirir y cuál es la mejor forma de reformar el datacenter para alojarlo.

Como es lógico, en un trabajo de consultoría de este tipo una parte importante para diseñar la estrategia es plasmar “la foto” del ecosistema español de supercomputación, y eso requiere saber qué es lo que hay. Evidentemente, conozco todos los sistemas que forman parte de la Red Española de Supercomputación, de cuyo Consejo formé parte hasta mediados de junio del año pasado. También conozco algunos otros sistemas. Pero la realidad es que, en España, hay una potencia de cálculo relevante  en sistemas departamentales y empresas privadas que no son conocidos. Es decir, que no sabemos el inventario que tenemos como país de una infraestructura cara y necesaria. Los superordenadores son obviamente caros, pero también son necesarios. En casi todos los campos es necesario “computar para competir”.

Esta carencia de información sobre cuántos sistemas de cálculo hay en España y cómo son la he comentado en ocasiones con otros directores de centros de supercomputación, así como la necesidad de conocerlos para optimizar mejor un recurso caro y escaso. Por eso, a raíz del trabajo de consultoría y del trabajo de investigación que tuve que hacer para realizarlo, se me ocurrió la idea de crear el equivalente a top500. La iniciativa fue muy bien acogida, y nos pusimos en marcha para crear www.top500.es.

La vocación de www.top500.es es ser el portal de referencia en supercomputación para los países de habla hispana. Los motivos que nos mueven son:

  1. Saber qué sistemas hay para que se puedan optimizar los recursos.
  2. Concienciar a los gobiernos de España y resto de países de hispanoamérica de la necesidad de invertir en supercomputación. La lista top500 de noviembre de 2018 debería sonrojarnos. En la lista aparecen 227 ordenadores de China, 109 de EEUU, 94 de Europa y 31 de Japón. A los 94 de Europa, España sólo aporta uno: el Mare Nostrum. La comparación con Francia (18 ordenadores en la lista) e Italia (6 ordenadores en la lista) debería sonrojarnos. Pero si miramos que en la misma lista Arabia Saudí (donde el Free Cooling no está muy fácil) tiene 3, se nos debería caer la cara de vergüenza como país. Por tamaño, España debería tener tres o cuatro ordenadores en la lista. ¿Por qué el CESGA, Scayle o Computaex no disponen del dinero necesario para entrar en la lista?.
  3. Generar conocimiento. La lista top 500 da muy poca información, Rpeak, Rmax, número de cores y, desde hace unos pocos años, energía. En top500.es pretendemos recabar mucha información de cada sistema para poder analizarla utilizando técnicas de machine learning y generar conocimiento con ella.

Os pido que apoyéis a www.top500.es, una iniciativa completamente sin ánimo de lucro, para apoyar y ayudar a la supercomputación en España y países de habla hispana. La supercomputación es una herramienta importantísima para el progreso de la ciencia y la tecnología.

 

OSDA – Open Standard for DataCenter Availability (II)

En el artículo anterior dijimos que los estándares de diseño que han imperado durante muchos años ya no dan respuesta a las necesidades de hoy en día, y en este artículo vamos a ver por qué. Así que tras un pequeño parón para cambio de servidor,  volvemos a la carga con el OSDA.

Pero ¿por qué tenemos que redefinir estas cosas? ¿No es reinventar la rueda? Pues no, y no lo es fundamentalmente por dos razones:

  • La primera es que las normas están diseñadas para un modelo IT clásico, es decir On Premise, en el que cada organización es dueña de sus infraestructuras y las explota. Es evidente que en este modelo de funcionamiento el DataCenter es una infraestructura crítica para la organización, sobre todo si hiciéramos una encuesta y nos diéramos cuenta que lo de tener un CDP de respaldo es menos frecuente de lo que pensamos y, en todo caso, más reciente de lo que pensamos. Es decir, hasta ahora ha imperado el paradigma Juan Palomo: la organización es propietaria de sus infraestructuras iT y se encarga de explotarlas, así que esas infraestructuras, al ser críticas, deben ser lo más fiables posible. Si puedo Tier 3, pues Tier 3. Y si el bolsillo me da para TIer 4, pues Tier 4. Y, el que podía, un CPD alternativo, pero esto último en empresas pequeñas y medianas se ha limitado en la mayoría de los casos a hacer copias de seguridad y llevarlas a casa. Puede parecer absurdo, pero puedo hacer una lista con más de 100 organizaciones que están todavía así. Organizaciones públicas y privadas, grandes y medianas empresas, comunidades autónomas, ayuntamientos de más de 100.000 habitantes (una de las peripecias de mi vida fue diseñar el rescate informático de un ayuntamiento al que se le quemó su único CPD), universidades, etc, etc. Las implicaciones son evidentes: como sólo tengo un coche, necesito que sea duro y fiable, así que no me importa que sea costoso y feo. Es el modelo Volvo aplicado a IT: si puedo, me compro un segundo coche por si las moscas. Si me puedo permitir dos Volvos, me compro dos Volvos. Y si el segundo es un Pandita, ni cabrá toda la familia, ni iremos igual de seguros ni llegaremos tan lejos, pero siempre será mejor que nada.
  • La segunda son los Dogmas de Fe que existen en el mundo IT, y el datacenter no sólo no es ajeno a tener dogmas sino que a durante años se ha quemado en la hoguera a los herejes que pensábamos que quizá mereciera la pena echarle una pensada a algunos conceptos, por si hubiera alguna forma diferente para hacer las cosas de una forma más eficiente. Podríamos citar muchos de estos dogmas de fe. Pero, por ejemplo: la electricidad es un servicio que se contrata a una compañía eléctrica, y si quieres que te diseñe un sistema fiable de suministro eléctrico para tu datacenter tendrás dos contratos de suministro con dos compañías diferentes y te tendrán que llegar dos líneas diferentes de dos subestaciones diferentes. Está claro que el que piensa así tiene acciones de las compañías eléctricas. Podríamos seguir con más dogmas sobre electricidad, refrigeración, etc. Por cierto, recuerdo que cuando hace diez años hicimos el CPD de Caléndula y contaba que utilizábamos intercambiadores de calor aire/agua en el CPD mucha gente me miraba con más repelús que a los extraterrestres de Men in Black. Ahora, las soluciones InRow aire/agua están a la orden del día. Muchas de las soluciones que aplicamos entonces y que fueron muy innovadoras ahora están a la orden del día. Eso si, diseñamos armarios capaces de albergar 40kW, y a día de hoy no he visto ningún otro CPD capaz de eso.

Si nos fijamos, ambos puntos encierran una gran contradicción: las Tecnologías de la Información y las Comunicaciones son muy innovadoras, y han sido la tecnología disruptiva que han provocado grandes cambios sociales y económicos en los últimos 50 años. Sin embargo, las TIC son reacias a la innovación. Es más, en el mundo del DataCenter no sólo no se ha fomentado la innovación sino que, en buena medida, se ha penalizado. Si nos fijamos, en las normas existentes no caben energías renovables, autoconsumo, otros modelos de refrigeración, etc. Es evidente que una norma no puede prever qué tecnologías van a aparecer en los próximos años, pero sí puede prever cómo incorporarlas.

Así que este es uno de los objetivos del OSDA: no sólo hay que utilizar la tecnología que hay disponible hoy en día, también es necesario fomentar la innovación e incorporarla al proceso. Y esto empieza por las definiciones de base. La primera es que si yo soy el CTO de mi organización debo diseñar infraestructuras para dar respuesta a las necesidades de disponibilidad de mi organización, y ese diseño debe ser global. Es decir, romper ese paradigma en el que un CPD es una mónada aislada del Universo. Por ejemplo, qué es mejor: ¿un único CPD a prueba de bombas o tener la carga en dos o tres CPD’s low cost en un modelo activo/activo? Como hemos dicho en artículos anteriores, tenemos que tener en cuenta que los Centros de Proceso de Datos existen para ejecutar aplicaciones, así que lo verdaderamente importante es que funcionen estas últimas.

Lo importante es diseñar infraestructuras que den respuesta adecuada a las necesidades. Y dar respuesta adecuada significa, como decíamos al principio, pensar sobre el problema que tenemos que resolver y cuál es la mejor forma de resolverlo, abstrayéndonos de dogmas. Incluso los que hoy en día defienden modelos On Premise -sigue habiendo mucha gente que se aferra a ellos- que sin darse cuenta han ido externalizando el correo amén de otras muchas cosas, así que tienen que asumir que los modelos de Cloud Híbrida están a la orden del día.

En el próximo artículo entraremos en materia del OSDA. Mientras tanto, ya sabéis: si queréis implantar metodologías y métricas en vuestro CPD, contactad conmigo.

 

OSDA – Open Standard for DataCenter Availability (I)

[bws_linkedin display=”share”]

Durante muchos años, los estándares de instituciones como el Uptime Institute, TIA y BICSI han sido ampliamente utilizados en diseño, construcción y operación de DataCenters. Son sencillos y relativamente fáciles de utilizar, y su primer objetivo es facilitarnos una clasificación básica sobre datacenters. Cada uno de ellos tiene sus peculiaridades, pero básicamente marcan los requisitos para tener cuatro categorías de centros de proceso de datos. Estas cuatro categorías tienen pequeñas diferencias entre unos estándares u otros, pero podríamos hacer una descripción somera de ellas así:

  1. Básico y no redundante: el nivel más básico no tiene elementos redundados, por lo que en caso de fallo de un componente crítico se producirá una parada. (el responsable de explotación no pega ojo)
  2. Básico redundante: los componentes críticos están redundados. (el responsable de explotación necesita una dosis fuerte de pastillas para dormir).
  3. Mantenimiento concurrente: se puede hacer mantenimiento de cualquier componente sin necesidad de parar o degradar servicios. (el responsable de explotación baja la dosis de pastillas en invierno)
  4. Tolerante a fallos: el CPD es completamente tolerante a fallos. (el responsable de explotación duerme a pierna suelta)

Los estándares marcan unos requisitos de diseño y constructivos para encuadrarse en cada una de las categorías y, si se cumplen, como consecuencia se tendrá una tasa de disponibilidad conocida de antemano. Si las políticas de explotación se adecúan a las buenas prácticas, estadísticamente deben cumplirse las tasas de disponibilidad especificadas en la norma. Durante años, estos estándares han sido muy útiles.

Pero ¿y hoy en día? ¿Son suficientes? Claramente no, y en este artículo vamos a ver por qué. Estos estándares están diseñados para un paradigma en el que cada organización tenía su centro de proceso de datos y, si la organización se lo podía permitir, uno alternativo. Es decir, estas normas asumen que una organización tiene un centro de proceso de datos propio, en el que tiene toda su producción. Como es evidente, este datacenter es crítico, y debe estar diseñado de forma robusta. Si me lo puedo permitir hago un datacenter que resista una bomba atómica, y si soy más pobretón con una o dos UPS me vale.

La informática es crítica para una organización. Si la informática se para entonces la organización se colapsa, así que tiene que funcionar sí o sí. Por eso, durante muchos años, por favor, me ponga usté un host mu caro o lo mejor que haiga y no repare en gastos. Los sistemas eran carísimos y el software tanto como el sistema o más: el coste de los mainframes y sus licencias convertían en irrisorio el coste de la electricidad, las UPS’s, las enfriadoras y demás martingalas necesarias.

Pero claro, para que funcione el host y su software, el router y todas esas puñetas hacen falta cosas básicas: electricidad y frío. Para esto las soluciones han permanecido invariables durante muchos años: en la electricidad un suministro de luz (o dos para los ricos) contratado a una compañía eléctrica. Por si falla el suministro, uno o más sistemas de alimentación ininterrumpida. Y para cuando se agoten las baterías, uno o varios generadores diesel. En el lado del frío, cacharros que generaban frío a base de compresores, se enfriaba el aire y ese aire frío se echa debajo del falso suelo. Por si las moscas, se ponen más cacharros de frío de los necesarios. Por cierto, que el viejo sistema de refrigeración por impulsión por falso suelo es un ejemplo del despilfarro energético que ha caracterizado al mundo del datacenter, porque hacerlo así es como encender el aire acondicionado del dormitorio para refrigerar el salón.

Por eso los estándares que hemos mencionado hablan explícitamente de este tipo de infraestructuras. Pero hoy en día las cosas son diferentes por muchos motivos. Uno de ellos es que tenemos un abanico de soluciones mucho mayor, y el otro es que desde hace tiempo el precio del kWh sube más que las angulas en navidad. Así que uno de los parámetros que hay que tener en cuenta en las tres fases del datacenter que hemos detallado al principio, esto es, el diseño, construcción y explotación, es el de la eficiencia, y el problema es que los estándares mencionados no contemplan para nada la Eficiencia (escrito así, con mayúsculas, como debe ser).

Para suplir esta carencia The Green Grid ha propuesto el Open Standard for DataCenter Availability (OSDA). Tal como el propio TGG indica, uno de los objetivos al proponer el OSDA es fomentar la innovación, teniendo como metas la sostenibilidad y la Eficiencia Energética. En esta serie de artículos veremos los principios básicos del OSDA y cómo utilizarlo. Y ya sabéis, si tenéis dudas o queréis averiguar el estado real de vuestro datacenter, contactad conmigo.

 

Disponibilidad y lógica difusa

[bws_linkedin display=”share”]

En el artículo anterior dijimos que es imprescindible controlar la disponibilidad, y que es imprescindible hacerlo para poder demostrar de forma fehaciente que estamos cumpliendo el Acuerdo de Nivel de Servicio que tenemos comprometido. Esto, independientemente de que su comprobación sea muy sofisticado o no, es, en principio, binario. O es sí o es no. Mejor dicho, como la carga de la prueba recae siempre por el lado del prestador del servicio, si no es sí tenemos un problema. Es decir, que si no podemos demostrar que estemos cumpliendo, da igual que en realidad lo estemos haciendo: si no podemos demostrarlo tenemos un problema.

Supongamos que estamos midiendo nuestra disponibilidad tal como hemos dicho y que somos capaces de demostrar que estamos cumpliendo ¿Es esto todo o deberíamos ir un poco más allá? En mi opinión, esto no es bastante. Si queremos conservar nuestro cuello, es necesario que sepamos a qué distancia estamos del desastre.

Como uno es persona de ideas peregrinas, a veces cuando voy en un avión sentado al lado de la ventanilla pienso aquí se va muy cómodo (con el espacio entre asientos de hoy en día, es un decir) pero si estuviera un metro más allá... Vale, quizá el ejemplo no es muy bueno, está el fuselaje en medio. Pero la idea se entiende: a veces nos separa muy, muy poquito del desastre, y para que no suceda ese desastre lo ideal es saber a qué distancia nos encontramos de él.

Si uno se sube a la azotea de un edificio de 50 plantas siempre se corre el riesgo de caerse. Corremos riesgos al estar en alturas, al ir en coche y, prácticamente, en cualquier actividad que hagamos: la vida es riesgo. Pero sigamos con el ejemplo de la altura, porque de la misma forma que a la mayoría de las personas les dan vértigo las alturas, a la mayoría de los técnicos de sistemas les da vértigo una caída grave de servicio en la que los teléfonos echan humo.

Supongamos que mi vida es la disponibilidad, que cumplo mi SLA humano si estoy vivo. Salgo a la azotea y me quedo en el centro, lejos del borde. Hombre, en principio parece bastante seguro. Puede suceder que venga una racha huracanada de viento, arrastre mis casi cien kilos y me tire por el borde de la azotea. Puede suceder, pero es altamente improbable. Sin embargo, si voy caminando por la azotea el riesgo de caer por el borde es cada vez mayor. A menos de un metro el riesgo de tropezar y caer por la barandilla es mayor que si estoy a diez metros. Y si me subo al borde de la barandilla, mientras esté ahí estaré vivo. Pero la probabilidad de que un resbalón o una pequeña ráfaga de viendo me hagan caer es enorme, y si eso sucede, adiós a mi disponibilidad, y en este caso, para siempre.

Para prevenir esto deberíamos utilizar un sistema de lógica difusa: cuanto más cerca estoy del borde menos disponibilidad tengo. Mientras esté en la azotea, perteneceré al conjunto de los disponibles, pero si me quedo en el centro perteneceré más que si me acerco al borde, y si me caigo por el borde dejaré de pertenecer al conjunto de los disponbiles. Como veis, son los conceptos básicos de lógica difusa.

¿Cómo aplicamos todo esto a nuestro servicio IT? Bueno, pues el concepto es sencillo. Ponerlo en marcha no lo es tanto. Supongamos que tenemos un servicio. Uno y sólo uno, que no es cosa de cansarse, pero es un servicio que es crítico y nos han puesto un SLA exigente. El servicio no requiere mucha carga computacional, pero es crítico (por ejemplo, el DNS: consume poco, pero cuando no funciona arde Troya. Así que nos curamos en salud y lo ponemos todo redundado: dos servidores con dos fuentes de alimentación cada uno, dos sistemas de almacenamiento don dos controladoras cada uno, dos switches, dos sistemas de alimentación ininterrumpida, dos enfriadoras, dos técnicos de sistemas, dos cafés, etc, etc. Todo redundado por si las moscas.

Supongamos que tengo un sistema para medir el SLA que comprueba que el DNS está en marcha, responde, lo hace dentro de la latencia especificada, etc, así que queda registro de Si, está disponible. Y ahora se van produciendo averías hardware. Empezamos por una avería en una fuente de alimentación de uno de los servidores. Una pequeña minucia, pues los dos servidores siguen en marcha y, por supuesto, nuestro monitorizador del SLA ni se inmuta. Se avería otra fuente del otro servidor, se avería una enfriadora… el monitorizador del SLA sigue diciendo que todo está ok, pero la cosa cada vez pinta peor. Con los sistemas de monitorización binarios saltarán las alarmas de las averías, pero sigo sin saber lo cerca que estoy del desastre.

Al final, sólo queda uno de cada cosa: sólo queda en marcha un servidor con una única fuente de alimentación que se comunica con el mundo a través de un único switch, etc, etc. Es decir, una incidencia más y desastre seguro. Hombre, Antonio, has roto muchas cosas a la vez… si, pues rompo sólo dos: rompo los dos switches y hala, se acabó. Se paró el servicio.

Pero si utilizamos un sistema de control con lógica difusa, podemos parametrizar los valores que asignamos a estos componentes para controlar el grado de pertenencia al conjunto de los disponibles. Esto hay que hacerlo en dos formas: controlando la distancia en número de eventos que estamos del desastre y asignando probablilidades a los eventos. En el caso que hemos mencionado, la distancia mínima al desastre es dos: como hemos dicho antes, basta que fallen los dos switches. Si falla un switch no pasa nada si también falla un servidor, pero es obvio que si ha fallado un switch y un servidor es más probable el fallo total que si sólo ha fallado uno (o switch o servidor).

Esto hay que hacerlo bien, controlando todos los elementos que intervienen en cada servicio, comenzando por el cuadro eléctrico y terminando en el último componente de software. Y si con sólo un servicio y la pila de componentes que han intervenido os parece un lío, imaginad en un datacenter grande con cientos o miles de servidores y decenas de miles de servicios.

Supongamos que parametrizo mi disponibilidad difusa entre 1 y 2, en el que 2 significa disponible, riesgo mínimo y 2 significa 1, riesgo extremo. Sé que el teléfono no va a echar humo hasta que la disponibilidad baje de 1, pero seguro que mi comportamiento no va a ser igual si veo en el monitor un 1,001 que si veo un 1,999.

Análogamente, Podemos controlar los incumplimientos con lógica difusa. No es lo mismo que dos de cada diez peticiones se respondan con un tiempo de latencia un poquitín superior al especificado a que el servicio no responda. Incluso cuando nos van a dar collejas es necesario tener las herramientas pera intentar minimizar el número y fuerza de las mismas.

Si os fijáis, esto es una ampliación de los conceptos utilizados en en Thermal Resilience a todos los componentes y servicios del datacenter. Como lo estamos midiendo en positivo, estamos hablando de disponiblidad, pero no deja de ser una forma de medir en tiempo real el riesgo asociado a los servicios: el inverso de la disponibilidad es el riesgo tal como lo trata la ISO 27001.

Cualquier servicio es crítico una vez transgredido el acuerdo de nivel de servicio, así que a cualquier CTO le encantaría saber si las collejas están lejos o cerca, y esto, en el fondo, es un mero problema de probabilidades. Eso sí, un CTO tiene que ser consciente de que  los sucesos improbables también ocurren. Tienes dos ases en la mano, y en la mesa ves un as, dos cuatros, un nueve y un tres. Te ves feliz con tu trío pensando que te has ganado un dinero fácil cuando resulta que el que tenía cara de pardillo tenía otros dos cuatros en la mano, enseña su póker y te deja con cara de memo.

Si, la Ley de Murphy es inexorable. Por eso, cuánto más lo tengamos todo bajo control, mejor. Por eso la disponibilidad es mayor cuando se está sentado confortablemente en el salón que cuando se está como el de la imagen. Así que no lo dudéis, implantad un sistema de gestión de disponibilidad/riesgo así. Si no sabéis como, consultadme!

 

Conceptos básicos de disponibilidad (II)

[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:

  1. 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.
  2. Al diseñar las infraestructuras y sistemas que utilizaremos para prestar los servicios.
  3. 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.

 

 

 

diciembre 2018
L M X J V S D
« Nov    
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Archivos