Soportado - No Soportado

Hola

Esto es algo que me ha tocado explicar con cierta frecuencia, y gracias a mis ex-compañeros de soporte que me han hecho llegar la definición actualizada, me animo a hacerlo aquí. Lo tenía pendiente desde hace tiempo pero el anuncio de la renovación del licenciamiento y las políticas de soporte de productos de Microsoft para entornos virtualizados y un post de mi amigo Josep amplificando lo que bajo mi punto de Vista no es mas que FUD sobre Hyper-V (y que no he podido dejar sin contestar).

Principalmente me preocupa el mal uso de los silogismos durante esas peleas tan entretenidas como estériles en las que nos solemos enzarzar al hablar de tecnología, para tratar de demostrar que "No Soportado = No funciona". Desafortunadamente utilizamos la misma palabra (Support/Soporte y Supported/Soportado) tanto para hablar de los límites técnicos de un producto, como para referirnos a cómo un fabricante se enfrenta al hecho de arreglar los problemas que puedan surgir en un producto o entorno funcionando dentro de sus límites técnicos.

Soportado, en el sentido de capacidades técnicas, es fácil de entender: Windows Server 2008 no soporta más de 2TB de memoria física y 64 procesadores (cada uno con sus cores) por mucho que nos empeñemos en pincharle 4TB y 128 procesadores (yo ya sabéis que lo hago a diario :-) ). Estar fuera e este tipo de límites significa automáticamente un imposible, e incluso es frecuente que si estamos cerca de los inferiores la experiencia sea nefasta. Generalmente, una pelea entre dos soluciones tecnológicas llevada a la mera comparación de este tipo de características técnicas una a una suele indicar que la historia de la parte que esgrime esos argumentos para resolver las necesidades del cliente/usuario flojea.

Soportado, en el sentido del servicio que ofrece el fabricante, significa que:

• El producto se encuentra dentro de su ciclo de vida de soporte.
• Se ha probado rigurosamente el producto o la solución, y puede confirmar que sus características y funcionalidades funcionan tal y como fueron diseñadas.
• Se trabajará para resolver los problemas que pudieran aparecer a través de los procedimientos habituales de resolución de problemas, basados en como el producto fue diseñado y probado.
• Se decidirá la creación de parches/hotfixes para las características y funcionalidades que entren dentro del diseño y hayan sido probadas (en este punto lo cierto es que hay una gran variedad de situaciones que se contemplan llegado el caso, como por ejemplo las peticiones de cambio de diseño, aunque eso es otra historia...).

Basta tener dos dedos de frente para darse cuenta que la definición de No Soportado no se construye simplemente colocando un operador NOT en todas y cada una de las sentencias anteriores, sino, estrictamente hablando, solamente en las dos primeras.

Cada uno de los grupos de producto tienen grupos bien diferenciados de personas, unos que tiran código unos para hacer la parte que les ha sido asignada y otros que se encargan de llevar a cabo las baterías de pruebas que han sido previamente definidas para comprobar la funcionalidad, seguridad, etc. que están contempladas en las especificaciones, y reportan o llevan las acciones correctivas que sean necesarias al código. Todas los fabricantes de software, y de tecnología en general, usan este tipo de metodologías y es lo que luego deriva en las políticas y garantías de soporte. No se puede garantizar lo que no se ha probado.

Sin embargo, las necesidades del mundo real, y por tanto el uso que los usuarios hacen de la tecnología, supera muy frecuentemente lo que el fabricante haya podido poner a prueba en el proceso de producción de un producto. He trabajado en muchas ocasiones con entornos "no soportados", y de hecho mis entornos de demos los son muy frecuentemente. Y siempre ha sido posible encontrar la solución a los problemas siguiendo las metodologías habituales. Un buen usuario/profesional se encargará de informarse acerca de las configuraciones soportadas (=recomendadas)  por el fabricante y tratará de ceñirse a ellas, pero ciertamente en ocasiones no le será posible. ¿Se quedará sin recibir ayuda del fabricante por ello?.

No debería. El comportamiento de los departamentos de soporte y atención al cliente en esas situaciones puede variar mucho e ir desde el portazo en las narices (bueno para el personal del departamento, muy malo para el cliente) hasta el punto de ignorar la política y dar el tratamiento habitual (no tan malo como parece para el personal y desde luego excelente para el cliente, siempre que se asuma que el "tratamiento habitual" es bueno). En este último caso, siempre será bueno fijar bien las expectativas. Si estamos en una situación de entorno "no soportado", se intentará hacer todo lo que este en nuestra mano dentro de unos límites razonables, pero podría darse el caso en que no se pueda encontrar una solución. Salvo para los casos de productos fuera de su ciclo de vida, cuyo caso más típico es NT 4.0) es así como Microsoft quiere que se comporten sus profesionales de soporte.

Resumiendo. Las políticas de soporte son importantes para clientes y fabricantes porque dan una idea exacta de lo que un fabricante recomienda, garantiza, de lo que se responsabiliza y de las tendencias por las que apuesta. Pero esto no implica en absoluto que usos al margen de esas políticas no nos vayan a dar igualmente los resultados deseados, y sobre todo, que no debamos implementar nuestros propios procedimientos para comprobar que el uso que vamos a hacer de la tecnología se ajusta exactamente a lo que esperamos de ella.

Saludos

David Cervigón

Comments

• Anonymous
  January 01, 2003
  Hola Pueden descargarse desde la web de Connect a través de este enlace, donde encontraremos versiones

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  August 23, 2008
  Buenas!! aquí el FUDero :-) Entiendo que los que hablamos fuera de la línea oficial de Microsoft hagamos chirriar un poco el discurso que se pretende imponer, pero al final un poco de sentido común basta. Microsoft siempre ha hecho lo mismo: ignorar a la competencia. Y le ha ido muy bien. Así el soporte de sistemas Linux se reduce a SUSE gracias al acuerdo comercial con Novell que, por cierto, está dándole vidilla porque se le veía bastante a punto de cerrar. La verdad es que al indicar que ESXi tenía un soporte mucho más amplio de sistemas operativos que Hyper-V y que éste último no soporta NT tampoco me paré ni a pensar si funcionaría o no. De hecho es lo de menos. Está claro que Microsoft sólo va a dar soporte a aquellos sistemas operativos virtualizados que considera oportunos y me parece totalmente correcto bajo la perspectiva de Microsoft, pero no así bajo la perspectiva del mercado. Fuera de Microsoft también hay vida y hay sistemas operativos Linux (mal que nos pese a muchos), Novell, Solaris y ahora Apple que muchas empresas querrán tener como parte de su CPD virtual. Bajo mi punto de vista ahí Microsoft simplemente se cierra puertas y VMware las deja bien abiertas teniendo una visión del mercado más real: esos sistemas operativos existen, nos guste o no. Que quede claro que ojalá Hyper-V acabe siendo una pasada de sistema de virtualización y le baje bien bajados los humos a VMware, aunque al paso que vamos yo no lo veo claro. Está bien el paso que se ha dado respecto a Virtual Server, pero aún falta bastante trecho para llegar al nivel de madurez de VI3.5. Ah! y me has copiao el nombre del post eh? ;-) Un abrazo Josep

• Anonymous
  August 26, 2008
  The comment has been removed