Año nuevo, hosting nuevo, dominio nuevo!!

Nos hemos movido al nuevo blog http://www.disgen.net/blog

Alguna vez te has presentado con la situación de actualizar el BIOS de tus equipos?

Digamos no se, que te llegó a tus manos el nuevo módulo de memoria RAM DDR2 667 MHz, pero te topas que es de otro fabricante al modulo que ya tienes instalado y que cuando las instalas simplemente tu windows se comporta errático o solo se colapsa. Entonces lees en algun blog o por recomendación de algún amigo o colega que actualices el BIOS. Oh sorpresa!!

Te armas de valor, vas al sitio del fabricante de tu motherboard, descargas la ultima versión del firmware y te das cuenta que hay un flasher (actualizador de BIOS) en Windows. Error!! Lo procedes a bajar.

Ya teniendo ambos archivos, tomas tu taza da café, le das un trago. La cafeina entra a tu organismo. Te armas de valor nuevamente. Abres el flasher, le indicas donde está la imagen binaria del nuevo firmware y presionas actualizar. Ves correr la barra de progreso, estas muy contento 1% 2% 3% …. 10%. Proximamente tendras tus fabulosos 2 GB de RAM para Windows Vista.

14% …. 14% ….. 14% (pasa el tiempo) 10 minutos, 20 minutos, 14% WTF!!! se congeló. Tu sistema no responde, el cursor del mouse no se mueve, te desesperas y maldices por aqui y por alla. No te queda de otra: Reiniciar el sistema oprimiendo el botón de reset.

Ohhh sorpresa nuevamente: TU SISTEMA TIENE EL BIOS CORRUPTO!!!! y no puede hacer nada más que ponerte leyenda técnicas que lo único que significan es que la regastes y estas en un callejon sin salida … bueno, casi.

Lo anterior son eventos que han sucedido frecuentemente y terminan por dejar inservible en ese momento las computadoras. En algunas motherboards, la solución a esos problemas consiste en bootear con un diskette 3 1/2 con la imagen del firmware y un flasher. Pero bueno esa es otra historia para otro post.

En un blog de ZDNet Adrian Kingsley-Hughes, habla sobre la cuestión de si actualizar o no actualizar el BIOS.

Demistifying BIOS Updates – The DOs and DO NOTs

Navegando me encontré con un sitio muy interesante de una organización sin fines de lucro ubicada en Silicon Valley dedicada a la preservación y celebración de la historia de la computación.

Si quieren pasar un rato agradable leyendo acerca de la maquina de Babbage, la historia de los semiconductores o la tan famosa Ley de Moore de Intel visite http://www.computerhistory.org/

Microsoft tiene en www.server-quest.com un juego estilo PC 386 con graficas EGA/VGA donde el juegador es un IT Pro como todos ustedes. Que tiempos aquellos de las 386/486

Recientemente me di a la tarea de buscar un indice de Podcasts realmente interesantes que trataran sobre los temas que competen a este blog, sin embargo no encontre alguno al momento por lo que el dia de hoy les pongo los que a un servidor les ha gustado por su contenido:

1. Byte Podcast (Divertidisimo y excelente podcast desde Mexico, DF con el buen David Ochoa y las paginas del Poncho)
2. Jambitz.com (Diversos podcast sobre tecnologia y gadgets, aqui esta la grandiosa Diana Molina de PC Magazine en Espanol)
3. WeDoIt4You.com (Desde New York con muy buen contenido)
4. CNET News Daily Podcast

Seguiremos actualizando esta lista.

Volviendo al tema de los acuerdos de nivel de servicios les pongo el siguiente ejemplo de una empresa dedicada a dar Web Hosting:

Garantia de la Red: MiEmpresa.com garantiza que la Red estara disponible el 100% del tiempo en un mes dado, excluyendo el mantenimiento programado. Al experimentar caidas, MiEmpresa.com reembolsara al cliente el 5% de los cargos mensuales por cada 30 minutos de caida (y hasta el 100% de los cargos mensuales realizados al cliente por los servidores afectados). El Uptime de la Red incluye el funcionamiento de toda la infraestructura de la red incluyendo ruteadores, switches y cableado, pero no incluye servicios o software corriendo en su servidor. La caida o downtime de la red ocurre cuando un cliente en particular no puede transmitir y recibir datos y MiEmpresa.com registrara tales fallas en el sistema de soporte. Las caidas de red son medidas de la siguiente forma: a partir del tiempo en que una solicitud de soporte en el sistema es abierto por un cliente, hasta el tiempo en el que el servidor pueda transmitir y recibir datos de nuevo.

Y ustedes tienen SLAs en sus empresas?

En algunas lecturas sobre ITIL he visto emplear mucho el termino SLA y el dia de hoy les platico lo que he encontrado al respecto.

SLA es la abreviatura de Service Level Agreement o Acuerdo de Nivel de Servicios y en Wikipedia encontramos lo siguiente: “SLA es una parte de un contrato de servicio donde el nivel de servicio es definido”. En la practica, el termino SLA es utilizado algunas veces para referirse al tiempo de entrega o performace contratado de un servicio.

Un SLA es un acuerdo formal entre dos entidades. Es un contrato entre un proveedor de servicios y sus clientes o entre los mismo proveedores.  Este acuerdo puede especificar por ejemplo, los niveles de disponibilidad, servicio, performance, operacion u otros atributos del servicio tales como la facturacion y mas aun, las penalizaciones en caso de violaciones al SLA.

Los departamentos de Tecnologia de la Informacion han adoptado estas ideas de Acuerdos de Niveles de Servicios con sus clientes y/o usuarios de otros departamentos de la misma empresa, con el fin de comparar la calidad del servicio prestado contra lo comprometido y acordado, para asi obtener las desviaciones a implementar y realizar las acciones correctivas en caso necesario, siempre buscando la mejora continua.

Las especificaciones tecnicas de un SLA estan contenidas en el documento Service Level Specification (SLS), mismo que define los lineamientos operacionales de la implementacion del servicio.

Los acuerdos de servicio pueden contener numerosas metricas del performance del servicio que corresponden con los objetivos de los mismos niveles de servicio. 

Por ejemplo, en un datacenter podemos encontrar las metricas de Uptime, Downtime, QoS en los anchos de banda, Network Uptime, power uptime, numero de mantenimientos planificados.

Muchas de estas organizaciones emplean los estandares de ITIL para darle seguimientos a estos SLAs.

Desde el sitio web de SUN Microsystems pueden encontrar un pdf titulado Service Level
Agreement in the Data Center

Un buen acuerdo de nivel de servicios debe contener al menos estos 5 puntos claves:

1. Lo que el provedor se compromete.
2. Como el proveedor entregara esos compromisos.
3. Quien va a medir esas entregas, y como lo va a hacer.
4. Que pasa si el proveedor falla ante su entrega prometida.
5. Como el SLA cambiara en el tiempo.

 

Interesante post me encontre en ZDNet donde Michael Krigsman habla sobre las diferentes perspectivas que existen entre los departamentos de TI y los departamentos restantes de una organizacion.

http://blogs.zdnet.com/projectfailures/?p=820

• Chief Executive Officer: Will it increase the value of the firm?
• Chief Financial Officer: Where’s the return on investment?
• Chief Operations Officer: Can we execute on this plan?
• Chief Information Officer: Will it run on our systems?
• Chief Marketing Officer: Can the world understand it?
• Chief Sales Officer: Will our customers buy it?

Actualmente estoy leyendo el libro Be a Successful Consultant de Susan Nash para tratar de entender la profesión de ser un consultor y poder aplicarlo al entorno de las TIs.

Susan Nash habla en un principio de lo vertiginoso que son los cambios en estas epocas, donde ya no hay relaciones lineales entre efecto y causa que condujeran anteriormente a las organizaciones a realizar/cometer sus empresas. Hoy en dia nos encontramos en un ambiente donde dichas relaciones son no- lineales al considerar multiples efectos y causas así como diferentes soluciones a los problemas.

La autora cita algunos ejemplo que nos pueden ayudar a reflexionar sobre nuestro entorno.

Sabias que …

• En promedio, ahora los individuos tienen hasta 8 carreras a lo largo de su vida de trabajo.
• En 1990 los autos tomaban 6 años para pasar de la fase de conceptualización a la fase de producción. Para 1997 este proceso solo tomaba 2 años.
• En 1984 el ciclo promedio de desarrollo de un producto duraba tres años. En 1990 cayó a 18 meses. En 1997 eran 6 meses y continuó bajando.
• La mayor parte de los ingresos de Hewlett Packard (www.hp.com) vinieron de productos que no existian 24 meses atrás.
• Antes solo tomaba de 7-14 años para que al menos la mitad de las habilidades de un trabajador fueran obsoletas. Ahora solo toma 3 años para que ese 50% sea obsoleto.

Causas:

• Competencia global.
• Avances Tecnológicos.
• Ciclos de vida de los productos mas cortos.
• Multiples canales de comunicación.
• Expectación de una alta disponibilidad de servicios en 24×7x365
• Eliminacion virtual de los “trabajos de por vida