En verano se suele tener más tiempo de dedicarse un poco a probar y a tratar de innovar. Yo he intentado dotar a mi Unidad de Evangelismo Móvil (U.E.M) de alta disponibilidad, tal y como podéis comprobar en estas instantáneas obtenidas furtivamente por mi compañero y amigo David Salgado:
A los interesados en copiarme la idea, he de advertirles de un par de cosas. El failover en caso de un fallo en la dirección lleva más tiempo del deseado y tiene un incómodo "efecto espejo", ya que te vas justo al lado que no quieres, lo que dificulta las operaciones normales de la solución. En el caso del sistema de aceleración y freno es todavía peor, ya que cuando se accionan dejan los dos sistemas de dirección redundados completamente invalidados, con resultados fáciles de prever. Una posible solución sería montar el sistema redundante delante, pero eso impediría repostar, y lo que es peor, arañaría el depósito.
Creo que voy a abandonar esta vía de desarrollo, y me quedo con la versión actual (U.E.M 1.0), tal y como está ahora mismo en producción:
NOTA: Lo que se ve al fondo es un lugar muy curioso
Con esta configuración soporta:
Debería actualizar el troley de TechNet a una maleta oficial, pero a parte de costar un pasta gansa no alcanzaría la escalabilidad y flexibilidad deseadas. Los pulpos son de los "todo a 1 €". Aun así, la solución puede escalar aun más, ya que la maleta izquierda va vacía.
Saludos
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:
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.
David Cervigón
Durante los meses de verano una de nuestras principales ocupaciones es planificar parte de las actividades que haremos durante el curso y preparar el contenido de las mismas. Giras, eventos, webcasts, screencasts, guías, etc. Los ciclos de vida de los productos y lanzamientos marcan una buena parte de dicho contenido, pero tampoco es extraño que a lo largo del año la gente nos solicite más o menos cosas de determinadas tecnologías que no se habían previsto a priori.
Lo que tenemos en la cabeza para este año es, principalmente:
Sin embargo, como cualquier idea es siempre bienvenida, me gustaría que propusierais lo que se os ocurra como contenido de este tipo de actividades.
Simplemente dejad un comentario aquí o mandadme un correo dándole al botoncito de "email" de arriba a la izquierda. A las mejores ideas/propuestas ya les enviaré algo (camisetas, copias pata negra de Windows Vista, o le que vaya pillando de los almacenes de los de marketing). Y a los que se animen a llevarse el premio gordo y quieran a participar como ponentes y/o creadores de contenido, los recibiremos con los brazos abiertos.