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