Portada
mis comunidades
otras secciones
#3:
Cuando yo trabajaba para AT&T me pasó un caso curioso:
Tenía un cliente que sufría cortes intermitentes en su línea de datos pero con la salvedad de que los cortes solamente ocurrían durante las horas laborables y siempre durante un par de minutosy 2-3 veces al día.
Hice todo tipo de pruebas - siempre fuera de horas de oficina - como dejar un bucle tras el modem del cliente y enviar un patrón de test con un analizador sin obtener ningún error o corte.
Finalmente, tras hacerme el pesado con Telefónica, enviaron a un técnico para "pasar la curva": ponen un analizador que envía tonos de distinta frecuencia y miden la atenuación del par de cobre desde el modem hasta la central más próxima.
Estos equipos se oyen mientras trabajan, es decir, oyes los tonos que va mandando y los que va recibiendo.
En estas que charlando con el técnico de Telefónica que estaba pasando la curva se oye el ruido característico que hace un fax cuando intenta conectarse y el técnico me dice:
"Te están mandando un fax"
Yo: "No tengo fax en la sala de datos".
Ambos:
Lo que estaba pasando es que había un cruce entre el par de cobre con la linea de datos y alguien que tenía un fax. Por eso los cortes intermitentes de un par de minutos solamente en horario laboral.
Tenía un cliente que sufría cortes intermitentes en su línea de datos pero con la salvedad de que los cortes solamente ocurrían durante las horas laborables y siempre durante un par de minutosy 2-3 veces al día.
Hice todo tipo de pruebas - siempre fuera de horas de oficina - como dejar un bucle tras el modem del cliente y enviar un patrón de test con un analizador sin obtener ningún error o corte.
Finalmente, tras hacerme el pesado con Telefónica, enviaron a un técnico para "pasar la curva": ponen un analizador que envía tonos de distinta frecuencia y miden la atenuación del par de cobre desde el modem hasta la central más próxima.
Estos equipos se oyen mientras trabajan, es decir, oyes los tonos que va mandando y los que va recibiendo.
En estas que charlando con el técnico de Telefónica que estaba pasando la curva se oye el ruido característico que hace un fax cuando intenta conectarse y el técnico me dice:
"Te están mandando un fax"
Yo: "No tengo fax en la sala de datos".
Ambos:
Lo que estaba pasando es que había un cruce entre el par de cobre con la linea de datos y alguien que tenía un fax. Por eso los cortes intermitentes de un par de minutos solamente en horario laboral.
#10:
A mi me contaron el caso de una máquina que caia sin motivo aparente. Reboots inesperados y sin motivo aparente. Despues de mucho mirar, meses de trabajo, parece ser que alguien se da cuenta de que el único patrón que respetaban estas caidas escrupulosamente eran los ciclos lunares.
Pues bién, parece ser que las mareas, hacian elevarse una boya del Támesis la distancia necesaria, para que
la señal de radio de la misma interfiriera en la máquina de las narices situada en el edificio próximo al río.
No se si será cierto, nos lo contaron dentro de un curso de una metodología de troubleshooting analítica, para ver las posibilidades de la misma, pero yo la cuento y quedo como dios
Pues bién, parece ser que las mareas, hacian elevarse una boya del Támesis la distancia necesaria, para que
la señal de radio de la misma interfiriera en la máquina de las narices situada en el edificio próximo al río.
No se si será cierto, nos lo contaron dentro de un curso de una metodología de troubleshooting analítica, para ver las posibilidades de la misma, pero yo la cuento y quedo como dios
#17:
Alguna vez me contaron la historia de un cajero automático (ATM para los que no hablan colombiano) que fallaba siempre a las 3 de la tarde. Nunca habían tenido problemas con ese modelo, ni fallaba ningún otro cajero en la ciudad, ni siquiera el otro cajero que había en la misma oficina. Solo fallaba ese a las 3 PM y no todos los días.
Al igual que en esta historia llamaron al experto, y el experto observó un día, dos días, tres días sin que fallara. Al cuarto día el equipo falló a las 3 PM. Como era un día caluroso el experto se aventuró a suponer que era por el calor. Cambiaron el sistema de refrigeración y esperaron al día siguiente cuando volvió a fallar a la misma hora, y ni siquiera estaba haciendo calor, pero por un momento había brillado el sol. El experto se dio cuenta que el sol entraba por una de las rendijas de ventilación y saturaba un sensor óptico haciendo que todo el mecanismo de lectura de tarjetas fallara. Pusieron una tira de papel para tapar parcialmente la rendija, y el equipo nunca volvió a fallar.
Al igual que en esta historia llamaron al experto, y el experto observó un día, dos días, tres días sin que fallara. Al cuarto día el equipo falló a las 3 PM. Como era un día caluroso el experto se aventuró a suponer que era por el calor. Cambiaron el sistema de refrigeración y esperaron al día siguiente cuando volvió a fallar a la misma hora, y ni siquiera estaba haciendo calor, pero por un momento había brillado el sol. El experto se dio cuenta que el sol entraba por una de las rendijas de ventilación y saturaba un sensor óptico haciendo que todo el mecanismo de lectura de tarjetas fallara. Pusieron una tira de papel para tapar parcialmente la rendija, y el equipo nunca volvió a fallar.
#32:
Mi jefe tenía guardada esta historia de la lista de Sage en el 2002, espero que la disfruteis
De: trey@sage.org Fri Nov 29 18:00:49 2002
Fecha: Sun, 24 Nov 2002 21:03:02 -0500 (EST)
Desde: Trey Harris
Para: sage-members@sage.org
Asunto: El caso del email de las 500 millas
He aqui un problema que parecía imposible… Casi me arrepiento de postear esta historia a una audiencia tan amplia, porque es una historia genial para contarla tomando compar en una conferencia
La historia está alterada ligeramente con el fin de proteger al culpable, evitar detalles irrelevantes y aburridos, y en general para hacerla más entretenida.
Estaba trabajando administrando el sistema de correo del campus hace algunos años, cuando recibí una llamada del Director del Departamento de Estadística.
- "Tenemos problemas para enviar correo fuera del Departamento"
- "¿Cual es el problema?" Pregunté
- "No podemos enviar un correo a más de 500 millas", explicó el director. Casi me ahogo con el café.
- "¿Puede repetirme eso?"
- "No podemos enviar correo a más de 500 millas de donde estamos", repitió. "Para ser más concreto, digamos que a 520, pero no más allá".
- "Uhm… el correo electrónico no funciona así" respondí, tratando de evitar la tensión al hablar. Uno no puede demostrar tensión cuando se habla con el Director de un departamento, y menos cuando se trata de uno como es Estadística.
"¿Que le hace pensar que no puede enviar un email a más de 500 millas?"
- "No es algo que piense" contestó el Director. "Verá, hace un par de días que nos dimos cuenta de esto"
- "¿Que esperaron un par de DIAS?" le interrumpí. "¿Y no han podido enviar correo todo este tiempo?"
- "Podíamos mandar correos, pero no a más de…"
- "…500 millas, si". Terminé la frase por él. "Me hago a la idea. Pero ¿porqué no llamó antes?"
- "Verá, es que no habíamos podido recopilar información suficiente para estar seguros de lo que pasa hasta ahora"
Perfecto, se notaba que era el Director del Departamento de Estadística.
- "En cualquier caso, le pedí a una de los geoestadísticos que le diera un vistazo"
- "Geoestadísticos…"
-"Si, y nos hizo un mapa que mostraba el radio dentro del cual podemos enviar correo, al ser ligeramente inferior a las 500 millas. De todos modos, hay algunos destinos dentro de ese radio que no se alcanzan o que lo hacen esporádicamente, pero en ningún caso podemos hacerlo más allá del radio".
-" Ya veo…" y en ese momento me eché las manos a la cabeza.
"¿Cuando empezó a suceder esto? Antes me dijo que un par de días antes, pero… ¿ha cambiado algo es sus sistemas en ese tiempo?"
- "Bueno, el técnico vino, parcheó nuestro servidor y luego lo reinició. Pero le llamé y me dijo que no había tocado el servicio de correo".
- "Bien, déjeme darle un vistazo y le llamaré", le dije pensando que me estaba gastando una broma.
Pero no era el Día de los Inocentes. Intenté recordar si alguien me estaba devolviendo una broma.
Así, entré en el servidor departamental y envié unos correos de prueba. Probé dentro del triágulo de Carolina del Norte; incluso envié alguno a mi cuenta son mayores problemas.
Lo mismo ocurrió con los que envié a Richmond, Atlanta y Washington.
Envié otro a Princeton (a 400 millas) y funcionó.
Pero cuando intenté enviar un correo a Memphis, a 600 millas, falló.
Boston, falló.
Detroit, falló.
Abrí la libreta de direcciones y comencé a concentrarme en el asunto.
Nueva York, a 420 millas, funcionó.
Providence, a 580 millas, falló.
Estaba empezando a pensar que había perdido la cabeza.
Intenté enviar un correo a un amigo que vivía en Carolina del Norte, pero que tenía su ISP en Seattle. Afortunadamente, falló.
Si el problema hubiese tenido que ver con la localización geográfica del receptor, y no con su servidor de correo, seguramente me habría puesto a llorar desconsoladamente.
Habiendo establecido que, increiblemente, el problema era cierto y reproducible, le di un vistazo al archivo de configuración del servidor de correo Sendmail.
Parecía completamente normal, y hasta me resultaba familiar. Así que hice un diff con el archivo sendmail.cf que tenia en mi directorio personal para encontrar diferencias: no había ninguna. Era la configuración que yo había escrito, y estaba bastante seguro de no haber activado la opción "ERROR_DE_CORREO_A_MAS_DE_500_MILLAS".
Entonces me decidí a hacer un telnet al puerto SMTP (25) del servidor. Este me respondió con el banner de Sendmail para SunOS.
Un segundo… ¿un banner de sendmail SunOS? En esa fecha Sun todavía instalaba Sendmail 5 en su sistema operativo, cuando Sendmail 8 ya era bastante veterano.
Personalmente, como buen administrador de sistemas, había estandarizado todos los servidores a Sendmail 8. Incluso había escrito un archivo de configuración utilizando las opciones de auto-documentación y las variables que ya estaban disponibles en Sendmail 8 en lugar de las complejas opciones que se usaban en Sendmail 5. El puzzle empezaba a encajar, y de nuevo casi me atraganto con los restos de mi café, ya frío.
Cuando el técnico "parcheó el servidor", aparentemente actualizó la versión de SunOS a una superior y al hacerlo bajó la versión de Sendmail.
La actualización, por suerte, había dejado el archivo de configuración. Lo que sucedía era que Sendmail 5, o al menos la versión distribuida por Sun que tenía algunas modificaciones y mejoras, podía interpretar la configuración de la versión 8 excepto por las nuevas opciones, que se interpretaban como basura y por tanto se ponian a cero.
Una de esas opciones que estaban a cero, era el tiempo de espera para conectarse a un servidor SMTP remoto. Después de algunos experimentos, pude establecer que un timeout=0 abortaría una conexión en 3 milisegundos. En aquella época, el campus de la universidad donde trabajaba era de los primeros que trabajaba con switches, así que un paquete saliente no comenzaría a contabilizar el tiempo de espera hasta que llegase al router del destinatario.
De esa forma, para conectarse con un servidor remoto, sin carga, en una red cercana estaría más afectado por la velocidad de la luz, que por algún retraso ocasional del router.
En resumen: en esos 3 milisegundos, el correo alcanzaría 500 millas, más o menos.
Trey Harris
De: trey@sage.org Fri Nov 29 18:00:49 2002
Fecha: Sun, 24 Nov 2002 21:03:02 -0500 (EST)
Desde: Trey Harris
Para: sage-members@sage.org
Asunto: El caso del email de las 500 millas
He aqui un problema que parecía imposible… Casi me arrepiento de postear esta historia a una audiencia tan amplia, porque es una historia genial para contarla tomando compar en una conferencia
La historia está alterada ligeramente con el fin de proteger al culpable, evitar detalles irrelevantes y aburridos, y en general para hacerla más entretenida.
Estaba trabajando administrando el sistema de correo del campus hace algunos años, cuando recibí una llamada del Director del Departamento de Estadística.
- "Tenemos problemas para enviar correo fuera del Departamento"
- "¿Cual es el problema?" Pregunté
- "No podemos enviar un correo a más de 500 millas", explicó el director. Casi me ahogo con el café.
- "¿Puede repetirme eso?"
- "No podemos enviar correo a más de 500 millas de donde estamos", repitió. "Para ser más concreto, digamos que a 520, pero no más allá".
- "Uhm… el correo electrónico no funciona así" respondí, tratando de evitar la tensión al hablar. Uno no puede demostrar tensión cuando se habla con el Director de un departamento, y menos cuando se trata de uno como es Estadística.
"¿Que le hace pensar que no puede enviar un email a más de 500 millas?"
- "No es algo que piense" contestó el Director. "Verá, hace un par de días que nos dimos cuenta de esto"
- "¿Que esperaron un par de DIAS?" le interrumpí. "¿Y no han podido enviar correo todo este tiempo?"
- "Podíamos mandar correos, pero no a más de…"
- "…500 millas, si". Terminé la frase por él. "Me hago a la idea. Pero ¿porqué no llamó antes?"
- "Verá, es que no habíamos podido recopilar información suficiente para estar seguros de lo que pasa hasta ahora"
Perfecto, se notaba que era el Director del Departamento de Estadística.
- "En cualquier caso, le pedí a una de los geoestadísticos que le diera un vistazo"
- "Geoestadísticos…"
-"Si, y nos hizo un mapa que mostraba el radio dentro del cual podemos enviar correo, al ser ligeramente inferior a las 500 millas. De todos modos, hay algunos destinos dentro de ese radio que no se alcanzan o que lo hacen esporádicamente, pero en ningún caso podemos hacerlo más allá del radio".
-" Ya veo…" y en ese momento me eché las manos a la cabeza.
"¿Cuando empezó a suceder esto? Antes me dijo que un par de días antes, pero… ¿ha cambiado algo es sus sistemas en ese tiempo?"
- "Bueno, el técnico vino, parcheó nuestro servidor y luego lo reinició. Pero le llamé y me dijo que no había tocado el servicio de correo".
- "Bien, déjeme darle un vistazo y le llamaré", le dije pensando que me estaba gastando una broma.
Pero no era el Día de los Inocentes. Intenté recordar si alguien me estaba devolviendo una broma.
Así, entré en el servidor departamental y envié unos correos de prueba. Probé dentro del triágulo de Carolina del Norte; incluso envié alguno a mi cuenta son mayores problemas.
Lo mismo ocurrió con los que envié a Richmond, Atlanta y Washington.
Envié otro a Princeton (a 400 millas) y funcionó.
Pero cuando intenté enviar un correo a Memphis, a 600 millas, falló.
Boston, falló.
Detroit, falló.
Abrí la libreta de direcciones y comencé a concentrarme en el asunto.
Nueva York, a 420 millas, funcionó.
Providence, a 580 millas, falló.
Estaba empezando a pensar que había perdido la cabeza.
Intenté enviar un correo a un amigo que vivía en Carolina del Norte, pero que tenía su ISP en Seattle. Afortunadamente, falló.
Si el problema hubiese tenido que ver con la localización geográfica del receptor, y no con su servidor de correo, seguramente me habría puesto a llorar desconsoladamente.
Habiendo establecido que, increiblemente, el problema era cierto y reproducible, le di un vistazo al archivo de configuración del servidor de correo Sendmail.
Parecía completamente normal, y hasta me resultaba familiar. Así que hice un diff con el archivo sendmail.cf que tenia en mi directorio personal para encontrar diferencias: no había ninguna. Era la configuración que yo había escrito, y estaba bastante seguro de no haber activado la opción "ERROR_DE_CORREO_A_MAS_DE_500_MILLAS".
Entonces me decidí a hacer un telnet al puerto SMTP (25) del servidor. Este me respondió con el banner de Sendmail para SunOS.
Un segundo… ¿un banner de sendmail SunOS? En esa fecha Sun todavía instalaba Sendmail 5 en su sistema operativo, cuando Sendmail 8 ya era bastante veterano.
Personalmente, como buen administrador de sistemas, había estandarizado todos los servidores a Sendmail 8. Incluso había escrito un archivo de configuración utilizando las opciones de auto-documentación y las variables que ya estaban disponibles en Sendmail 8 en lugar de las complejas opciones que se usaban en Sendmail 5. El puzzle empezaba a encajar, y de nuevo casi me atraganto con los restos de mi café, ya frío.
Cuando el técnico "parcheó el servidor", aparentemente actualizó la versión de SunOS a una superior y al hacerlo bajó la versión de Sendmail.
La actualización, por suerte, había dejado el archivo de configuración. Lo que sucedía era que Sendmail 5, o al menos la versión distribuida por Sun que tenía algunas modificaciones y mejoras, podía interpretar la configuración de la versión 8 excepto por las nuevas opciones, que se interpretaban como basura y por tanto se ponian a cero.
Una de esas opciones que estaban a cero, era el tiempo de espera para conectarse a un servidor SMTP remoto. Después de algunos experimentos, pude establecer que un timeout=0 abortaría una conexión en 3 milisegundos. En aquella época, el campus de la universidad donde trabajaba era de los primeros que trabajaba con switches, así que un paquete saliente no comenzaría a contabilizar el tiempo de espera hasta que llegase al router del destinatario.
De esa forma, para conectarse con un servidor remoto, sin carga, en una red cercana estaría más afectado por la velocidad de la luz, que por algún retraso ocasional del router.
En resumen: en esos 3 milisegundos, el correo alcanzaría 500 millas, más o menos.
Trey Harris
#12:
Esto me recuerda...
El programador del Príncipe Wang estaba codificando. Sus dedos bailaban sobre el teclado. El programa compiló sin un mensaje de error, y el programa corrió como viento ligero.
"¡Excelente!," exclamó el Príncipe, "¡Tu técnica no tiene fallas!"
"¿Técnica?," dijo el programador, girándose hacia su terminal, "Lo que yo sigo es el Tao -- mas allá de toda técnica. Cuando al principio empecé a programar yo podía ver el programa completo en un bloque. Después de tres años ya nunca más vi ese bloque. En vez de eso, usé subrutinas. Pero ahora no veo nada. Todo mi ser existe en un vacío sin forma. Mi sentidos estan ociosos. Mi espíritu, libre para trabajar sin un plan, sigue su propio instinto. En resúmen, mi programa se escribe así mismo. Es verdad, a veces hay problemas y dificultades. Las veo venir, me freno, observo silenciosamente. Entonces cambio una sola linea de código y las dificultades se desvanecen como nubes de humo. Entonces compilo el programa. Me siento erguido y dejo que el gozo del trabajo llene mi ser. Cierro mis ojos por un momento y entonces cierro mi sesión."
El Príncipe Wang dijo, "¡Ojalá todos mis programadores fueran tan sabios!"
El programador del Príncipe Wang estaba codificando. Sus dedos bailaban sobre el teclado. El programa compiló sin un mensaje de error, y el programa corrió como viento ligero.
"¡Excelente!," exclamó el Príncipe, "¡Tu técnica no tiene fallas!"
"¿Técnica?," dijo el programador, girándose hacia su terminal, "Lo que yo sigo es el Tao -- mas allá de toda técnica. Cuando al principio empecé a programar yo podía ver el programa completo en un bloque. Después de tres años ya nunca más vi ese bloque. En vez de eso, usé subrutinas. Pero ahora no veo nada. Todo mi ser existe en un vacío sin forma. Mi sentidos estan ociosos. Mi espíritu, libre para trabajar sin un plan, sigue su propio instinto. En resúmen, mi programa se escribe así mismo. Es verdad, a veces hay problemas y dificultades. Las veo venir, me freno, observo silenciosamente. Entonces cambio una sola linea de código y las dificultades se desvanecen como nubes de humo. Entonces compilo el programa. Me siento erguido y dejo que el gozo del trabajo llene mi ser. Cierro mis ojos por un momento y entonces cierro mi sesión."
El Príncipe Wang dijo, "¡Ojalá todos mis programadores fueran tan sabios!"
Comentarios
Cuando yo trabajaba para AT&T me pasó un caso curioso:
Tenía un cliente que sufría cortes intermitentes en su línea de datos pero con la salvedad de que los cortes solamente ocurrían durante las horas laborables y siempre durante un par de minutosy 2-3 veces al día.
Hice todo tipo de pruebas - siempre fuera de horas de oficina - como dejar un bucle tras el modem del cliente y enviar un patrón de test con un analizador sin obtener ningún error o corte.
Finalmente, tras hacerme el pesado con Telefónica, enviaron a un técnico para "pasar la curva": ponen un analizador que envía tonos de distinta frecuencia y miden la atenuación del par de cobre desde el modem hasta la central más próxima.
Estos equipos se oyen mientras trabajan, es decir, oyes los tonos que va mandando y los que va recibiendo.
En estas que charlando con el técnico de Telefónica que estaba pasando la curva se oye el ruido característico que hace un fax cuando intenta conectarse y el técnico me dice:
"Te están mandando un fax"
Yo: "No tengo fax en la sala de datos".
Ambos:
Lo que estaba pasando es que había un cruce entre el par de cobre con la linea de datos y alguien que tenía un fax. Por eso los cortes intermitentes de un par de minutos solamente en horario laboral.
#3 Lo del cruce de pares es muy mítico aquí en españa, viendo el estado de las mangueras que van desde la central hasta los usuarios finales...
A mi me contaron el caso de una máquina que caia sin motivo aparente. Reboots inesperados y sin motivo aparente. Despues de mucho mirar, meses de trabajo, parece ser que alguien se da cuenta de que el único patrón que respetaban estas caidas escrupulosamente eran los ciclos lunares.
Pues bién, parece ser que las mareas, hacian elevarse una boya del Támesis la distancia necesaria, para que
la señal de radio de la misma interfiriera en la máquina de las narices situada en el edificio próximo al río.
No se si será cierto, nos lo contaron dentro de un curso de una metodología de troubleshooting analítica, para ver las posibilidades de la misma, pero yo la cuento y quedo como dios
Alguna vez me contaron la historia de un cajero automático (ATM para los que no hablan colombiano) que fallaba siempre a las 3 de la tarde. Nunca habían tenido problemas con ese modelo, ni fallaba ningún otro cajero en la ciudad, ni siquiera el otro cajero que había en la misma oficina. Solo fallaba ese a las 3 PM y no todos los días.
Al igual que en esta historia llamaron al experto, y el experto observó un día, dos días, tres días sin que fallara. Al cuarto día el equipo falló a las 3 PM. Como era un día caluroso el experto se aventuró a suponer que era por el calor. Cambiaron el sistema de refrigeración y esperaron al día siguiente cuando volvió a fallar a la misma hora, y ni siquiera estaba haciendo calor, pero por un momento había brillado el sol. El experto se dio cuenta que el sol entraba por una de las rendijas de ventilación y saturaba un sensor óptico haciendo que todo el mecanismo de lectura de tarjetas fallara. Pusieron una tira de papel para tapar parcialmente la rendija, y el equipo nunca volvió a fallar.
Mi jefe tenía guardada esta historia de la lista de Sage en el 2002, espero que la disfruteis
De: trey@sage.org Fri Nov 29 18:00:49 2002
Fecha: Sun, 24 Nov 2002 21:03:02 -0500 (EST)
Desde: Trey Harris
Para: sage-members@sage.org
Asunto: El caso del email de las 500 millas
He aqui un problema que parecía imposible… Casi me arrepiento de postear esta historia a una audiencia tan amplia, porque es una historia genial para contarla tomando compar en una conferencia
La historia está alterada ligeramente con el fin de proteger al culpable, evitar detalles irrelevantes y aburridos, y en general para hacerla más entretenida.
Estaba trabajando administrando el sistema de correo del campus hace algunos años, cuando recibí una llamada del Director del Departamento de Estadística.
- "Tenemos problemas para enviar correo fuera del Departamento"
- "¿Cual es el problema?" Pregunté
- "No podemos enviar un correo a más de 500 millas", explicó el director. Casi me ahogo con el café.
- "¿Puede repetirme eso?"
- "No podemos enviar correo a más de 500 millas de donde estamos", repitió. "Para ser más concreto, digamos que a 520, pero no más allá".
- "Uhm… el correo electrónico no funciona así" respondí, tratando de evitar la tensión al hablar. Uno no puede demostrar tensión cuando se habla con el Director de un departamento, y menos cuando se trata de uno como es Estadística.
"¿Que le hace pensar que no puede enviar un email a más de 500 millas?"
- "No es algo que piense" contestó el Director. "Verá, hace un par de días que nos dimos cuenta de esto"
- "¿Que esperaron un par de DIAS?" le interrumpí. "¿Y no han podido enviar correo todo este tiempo?"
- "Podíamos mandar correos, pero no a más de…"
- "…500 millas, si". Terminé la frase por él. "Me hago a la idea. Pero ¿porqué no llamó antes?"
- "Verá, es que no habíamos podido recopilar información suficiente para estar seguros de lo que pasa hasta ahora"
Perfecto, se notaba que era el Director del Departamento de Estadística.
- "En cualquier caso, le pedí a una de los geoestadísticos que le diera un vistazo"
- "Geoestadísticos…"
-"Si, y nos hizo un mapa que mostraba el radio dentro del cual podemos enviar correo, al ser ligeramente inferior a las 500 millas. De todos modos, hay algunos destinos dentro de ese radio que no se alcanzan o que lo hacen esporádicamente, pero en ningún caso podemos hacerlo más allá del radio".
-" Ya veo…" y en ese momento me eché las manos a la cabeza.
"¿Cuando empezó a suceder esto? Antes me dijo que un par de días antes, pero… ¿ha cambiado algo es sus sistemas en ese tiempo?"
- "Bueno, el técnico vino, parcheó nuestro servidor y luego lo reinició. Pero le llamé y me dijo que no había tocado el servicio de correo".
- "Bien, déjeme darle un vistazo y le llamaré", le dije pensando que me estaba gastando una broma.
Pero no era el Día de los Inocentes. Intenté recordar si alguien me estaba devolviendo una broma.
Así, entré en el servidor departamental y envié unos correos de prueba. Probé dentro del triágulo de Carolina del Norte; incluso envié alguno a mi cuenta son mayores problemas.
Lo mismo ocurrió con los que envié a Richmond, Atlanta y Washington.
Envié otro a Princeton (a 400 millas) y funcionó.
Pero cuando intenté enviar un correo a Memphis, a 600 millas, falló.
Boston, falló.
Detroit, falló.
Abrí la libreta de direcciones y comencé a concentrarme en el asunto.
Nueva York, a 420 millas, funcionó.
Providence, a 580 millas, falló.
Estaba empezando a pensar que había perdido la cabeza.
Intenté enviar un correo a un amigo que vivía en Carolina del Norte, pero que tenía su ISP en Seattle. Afortunadamente, falló.
Si el problema hubiese tenido que ver con la localización geográfica del receptor, y no con su servidor de correo, seguramente me habría puesto a llorar desconsoladamente.
Habiendo establecido que, increiblemente, el problema era cierto y reproducible, le di un vistazo al archivo de configuración del servidor de correo Sendmail.
Parecía completamente normal, y hasta me resultaba familiar. Así que hice un diff con el archivo sendmail.cf que tenia en mi directorio personal para encontrar diferencias: no había ninguna. Era la configuración que yo había escrito, y estaba bastante seguro de no haber activado la opción "ERROR_DE_CORREO_A_MAS_DE_500_MILLAS".
Entonces me decidí a hacer un telnet al puerto SMTP (25) del servidor. Este me respondió con el banner de Sendmail para SunOS.
Un segundo… ¿un banner de sendmail SunOS? En esa fecha Sun todavía instalaba Sendmail 5 en su sistema operativo, cuando Sendmail 8 ya era bastante veterano.
Personalmente, como buen administrador de sistemas, había estandarizado todos los servidores a Sendmail 8. Incluso había escrito un archivo de configuración utilizando las opciones de auto-documentación y las variables que ya estaban disponibles en Sendmail 8 en lugar de las complejas opciones que se usaban en Sendmail 5. El puzzle empezaba a encajar, y de nuevo casi me atraganto con los restos de mi café, ya frío.
Cuando el técnico "parcheó el servidor", aparentemente actualizó la versión de SunOS a una superior y al hacerlo bajó la versión de Sendmail.
La actualización, por suerte, había dejado el archivo de configuración. Lo que sucedía era que Sendmail 5, o al menos la versión distribuida por Sun que tenía algunas modificaciones y mejoras, podía interpretar la configuración de la versión 8 excepto por las nuevas opciones, que se interpretaban como basura y por tanto se ponian a cero.
Una de esas opciones que estaban a cero, era el tiempo de espera para conectarse a un servidor SMTP remoto. Después de algunos experimentos, pude establecer que un timeout=0 abortaría una conexión en 3 milisegundos. En aquella época, el campus de la universidad donde trabajaba era de los primeros que trabajaba con switches, así que un paquete saliente no comenzaría a contabilizar el tiempo de espera hasta que llegase al router del destinatario.
De esa forma, para conectarse con un servidor remoto, sin carga, en una red cercana estaría más afectado por la velocidad de la luz, que por algún retraso ocasional del router.
En resumen: en esos 3 milisegundos, el correo alcanzaría 500 millas, más o menos.
Trey Harris
Esto me recuerda...
El programador del Príncipe Wang estaba codificando. Sus dedos bailaban sobre el teclado. El programa compiló sin un mensaje de error, y el programa corrió como viento ligero.
"¡Excelente!," exclamó el Príncipe, "¡Tu técnica no tiene fallas!"
"¿Técnica?," dijo el programador, girándose hacia su terminal, "Lo que yo sigo es el Tao -- mas allá de toda técnica. Cuando al principio empecé a programar yo podía ver el programa completo en un bloque. Después de tres años ya nunca más vi ese bloque. En vez de eso, usé subrutinas. Pero ahora no veo nada. Todo mi ser existe en un vacío sin forma. Mi sentidos estan ociosos. Mi espíritu, libre para trabajar sin un plan, sigue su propio instinto. En resúmen, mi programa se escribe así mismo. Es verdad, a veces hay problemas y dificultades. Las veo venir, me freno, observo silenciosamente. Entonces cambio una sola linea de código y las dificultades se desvanecen como nubes de humo. Entonces compilo el programa. Me siento erguido y dejo que el gozo del trabajo llene mi ser. Cierro mis ojos por un momento y entonces cierro mi sesión."
El Príncipe Wang dijo, "¡Ojalá todos mis programadores fueran tan sabios!"
Para el debug, hace falta tener un poco mentalidad retorcida, me explico para el que no sea experto en estas lindes del F7 y F8 y del breakpoint.
Van un químico, un físico, un matemático y un informático en un tren por Irlanda. En uno de los parajes, el químico observa una oveja negra pastando y dice señalándola:
"Mirad!! Las ovejas de Irlanda son negras"
El físico (fijo que trabajaba en el CERN) i tenia casi a punto de descubrir el bosson Higgs le corrije:
"ALGUNAS ovejas de Irlanda son negras".
Luego el matemático rie...recuerda cuando le dieron la medalla Fields...y con jactancia dice:
"Lo único que sabemos seguro, es que en Irlanda hay AL MENOS UNA oveja negra".
Por último, el informático de turno, que el pobre trabaja en un Ikea en sus ratos libres les certifica:
"Lo que sí sabemos seguro es que EXISTE UNA oveja en Irlanda, que por uno de sus lados ES NEGRA".
Esa es la moraleja de debugging
Hombre, la conclusión que yo saco es que cuando tienes un problema hay que pararse a examinarlo. Eso y que un verdadero experto no es una persona muy versada en un tema puntual, sino alguien que sabe manejarse para resolver un problema.
Años 90, Hospital Universitario de Jaen, me mandan desde Barcelona debido a que el jefe del laboratorio brama que el autoanalizador de SIDA y hepatitis del banco de sangre contamina las muestras y salen todos los resultados positivos. La maquina costaba una gillonada y estaba en garantia asi que el jefe me dice "Huronea, hurga, encuentra, solventa".
Llego a las 8 am al complejo y pregunto por el capo del laboratorio, no esta, me indican la cafeteria por ser ese su lugar habitual de trabajo. Localizo al señor doctor y me dice que sin prisas, que primero el desayuno (yo flipando). Subimos al laboratorio y me indica el autoanalizador que, segun ellos, contamina y no es fiable. Pido muestras de sangre sobrantes para realizar pruebas, me alargan varias gradillas de tubos rezumantes y e indican son las muestras de la prision provincial, llenito de virus (guantes hasta el codo) y comienzo la prueba de control a mano y a maquina (soy el rey de las pipetas Eppendorf).
Realizo toda la prueba con 90 muestras y 6 controles (dan unos valores conocidos), dos horas y media de nada, y leo los resultador de la placa de microtitulacion, todo contaminado, tanto lo hecho a mano como lo mecanizado, sospechoso, muy sospechoso ¿Que punto de la cadena de analisis es comun en ambos metodos? El lavador de placas microtitter (microtitulacion), el aparato mas cutre y barato de la cadena puesto que es un peine de 12 puntas que inyecta detergente en los pocillos de la placa para retirar la muestra (las paredes de plastico recubierto ya se han impregnado de lo que se esta buscando). Analizo el agua del lavador, positivo a SIDA y hepatitis. Le digo al medico "Oiga ¿Cada cuanto limpian y desinfectan el lavador?", contestacion "Ah ... ¿Hay que lavarlos de tanto en tanto?"
Yo le entregue mi informe y supongo que la empresa para la que trabajaba les entrego una gruesa y jugosa factura por desplazamiento de "experto" dietas y gastos de viaje
Moraleja: Un titulo universitario solo garantiza que encontraste la manera de convencer a tus profesores para que te aprobasen.
El experto en inglés, que lo traduzca entero.
#1 no hombre que si no se pierde la gracia de la historia
#1 Te lo resumo
Se vió que el error era que al pasar sobre una baldosa concreta, los cables que había debajo producían un cortocircuito
#6 Menudo dominio del inglés
#8 Que había dicho que resumía
#8 tu me dirás http://box.jisko.net/i/1cff13.jpeg
#6 en realidad no. La baldosa no quedaba bien ajustada y al pisarla rozaba contra las otras, provocando chispas que producían interferencias electromagnéticas en la RAM (que antaño no estaba tan blindada para interferencias EM) y mandando todo al garete.
Esto me recuerda a una incidencia de una usuaria que entro en un curro en el que yo estaba (yo no me dedicaba a soporte, pero pululaba por ahi cerca).
La descripción era bastante escueta: Una secretaria puede ver los correos que envia su jefe.
En un principio no parecía muy serio, muchas secretarias tienen acceso al buzón de correo de su jefe, pero comprobando los permisos del buzón vemos que no tiene acceso a el. Curioso.
Pedimos algo mas de información, como que hace la usuaria para ver el correo del jefe, a ver si ha encontrado un fallo de seguridad como una catedral en el sistema de correo. Pero la usuaria lo tiene claro, ella no hace nada, simplemente ve en su pantalla cuando el jefe escribe un correo. Como en toda organización grande, existen herramientas que permiten a los administradores ver las pantallas de los usuarios (o los pobres tendrían que estar de viaje dia si, dia también), asi que imaginamos que algún administrador paso fisicamente por la oficina y dejo viendo el monitor del jefe en la ventana de la usuaria, pero lo comprobamos y vemos que el software esta desconectado en ambos equipos. Sabiendo que los usuarios pasan casi todo el tiempo utilizando la herramienta de gestión interna, totalmente desvinculada del correo, asi que volvemos a ponernos en contacto con la usuaria a ver que esta haciendo exactamente.
La respuesta: Normalmente estoy en la herramienta de gestión, pero si me salgo un rato y abro el Word para escribir un documento y dejo de escribir un rato, este empieza a escribir por mi y lo que escribe son los correos que envia mi jefe en ese momento desde su despacho.
Mosqueante, pero de solución barata y sencilla, un teclado nuevo que usara cables
No recuerdo del todo como era la historia, pero me suena al de la habitación de hospital maldita en la que todos los que se estaban recuperando de pronto de un día para otro morían inexplicablemente, hasta que descubrieron que la señora de la limpieza desenchufaba la máquina de respiración automática para enchufar el aspirador, y cuando terminaba dejaba todo como estaba, menos el enfermo que había fallecido sofocado ...
Otra historia parecida: The case of the 500-mile email (http://www.ibiblio.org/harris/500milemail.html)
#22 Esa es muchísimo mejor que la de la historia de hoy. Aquí en español http://www.microsiervos.com/archivo/ordenadores/email-500-millas.html
"Soy el Señor Lobo: soluciono problemas"
¿Os habéis fijado en el título del blog?
Me mandaron al domicilio de un cliente, diciendo que cada vez que tira de la cadena del WC, se reinicia el PC.
Increiblemente, compruebo como al tirar de la cadena, a los 5 segundos efectivamente se reinicia el PC.
Cambio el PC a un enchufe de otra habitación, y el problema desaparece.
Empiezo a bajar térmicos, hasta que encuentro a qué linea corresponde dicho circuito. Que curioso, ¿25A para una línea de enchufes?
Se me enciende la bombilla, voy al cuarto de baño, abro la tapa de la cisterna y... calentito calentito.
El fontanero debió confundir las tuberías, y cada vez que se tiraba de la cadena, se encendía el calentador de agua, bajando la tensión y reiniciándose el PC
Y en otra ocasión, en un colegio, me avisaron porque cada noche, se apaga el SAI con los servidores, y tras varios cambios de SAI, el problema persiste.
De día, puede estar durante horas, que funciona sin problemas. Es llegar la noche, y no hay forma de encenderlo. Polímetro en mano, dí con la solución. El trafo estaba bastante alto, y había 260V.
De día, con los equipos de las aulas, calefacción, alumbrado, etc, la tensión caía hasta los 240v, y funcionaba perfecto. De noche, al desaparecer la carga, la tensión subía a 260v, saltando la protección del SAI
Yo tuve un caso parecido. Si pisaba una baldosa debajo de la mesa se reiniciaba el ordenador de la mesa de enfrente.
Sí, el cable de la luz pasaba por debajo y estaba pelado.
Uno de mis mejores debuggings en el trabajo, hace ya diez añitos :
Motivo de la incidencia : 'No le funciona el password al usuario para entrar en red.'
Resolución de la incidencia : 'El teclado estaba desconectado.'
Ya te digo, el experto vería que todo era debido a un garrafal error de programación y se inventó la historia de la baldosa para que la culpa recayese en el cliente y no en la propia Storage Technology.
Pues que resulta que las baldosas del suelo, que eran de aluminio, hacian chispas al pisarlas que a su vez interferían en la RAM y se jodia el invento.
Lo unico raro es ver al técnico horas y horas sentado tocandoselos a dos manos mientras esperaba el crash.
Sigo buscandole la gracia o lo realmente curisoso a la historia...
#2 Supongo que la supuesta gracia está en que un error aparentemente de software fuera creado por hechos tan físicos como pisar una baldosa.
Supongo que tanto meneo habrá gente a quien le sorprendan estas cosas, no sé.
Me ha recordado a la serie de Historia de un Viejo Informatico, del que salió algun capitulo por aquí hace tiempo:
http://eltamiz.com/elcedazo/2009/03/09/historia-de-un-viejo-informatico-el-metodo-de-trabajo-en-los-ochenta/
Llamaron a los expertos, se sentaron en una habitación y mandaron repetir el proceso 3 veces hasta dar con la tecla. A la vieja usanza. ¡¡Brillante!!
para mi lo sorprendente es que el tio tenga fotos que parecen hechas ayer...
#19 Se las mandó el Experto. Estuvo 6 horas esperando en una silla mientras el modem de 600 baudios las enviaba.
Lo he leído vía reddit, buenísimo
. El tío se pego como 18 horas averiguando que coño pasaba. Y yo pensando...¿le pagarían horas extra? jajaja
Creo que lo más lol que he tenido fue cuando al tocar mi monitor de tubo descalzo apagaba el PC. Sí, tiene lógica eléctrica, pero me quedé a cuadros cuando averigué de que era, y ya me veía convertido en Dr. Manhattan.
La historia del mel que aparece en el jargonfile es mucho mejor. Está también en inglés y se comenta en reddit: http://www.jargon.net/jargonfile/t/TheStoryofMel.html
En otra ocasión recuerdo que fui a reparar una fuente de alimentación del PC de un usuario y descubrí que le fallaba también la disquetera. Lo curioso es que la siguiente reparación que hice ese mismo día fue un cambio de disquetera y al reiniciar el PC se quemó la fuente de alimentación. Un fallo en Matrix???
tengo 32 años, hace 24 me circuncidaron(no soy semita), y despues de tantas historias, empiezo a figurarme la clase debugging que debio haber hecho mi abuela al notar los alrededores del inodoro orinado para teminar en esa intervención quirurjica...
Para mi la mejor historia es la de un servidor que se apagaba misteriosamente todos los viernes a la misma hora. Tuvo que ir un experto a la sala de servidores y sentarse allí para ver cómo sucedía: llegaba la limpiadora y para conectar la aspiradora desenchufaba el enchufe que más cerca tenía.
Ooops... kernel panic!
Estas cosas nos las encontramos a diario los pobres desgraciados que vamos de oficina en oficina, ayer sin ir más lejos, cliente que se cambia de compañía ADSL, aprovechan el mismo router e intentan cambiar los parámetros de conexión al nuevo ISP, no había forma, cada vez que los cambiaban aparecía el temporizador de cuenta atrás en blanco, ni siquiera se podía resetear el router a los parámetros de fábrica, después de buscar y buscar durante una hora ya casi había llegado a la conclusión que el router estaba averiado, cuando se me encendió la bombilla, el lenguaje de la interface estaba en español, lo puse en inglés y a funcionar.
muy muy curioso
Yo recuerdo haber leido el caso del programa que fallaba solo un dia determinado. Si no mal recuerdo el problema era que no reservaba suficiente memoria para almacenar los caracteres del día, y se desbordaba. En concreto recuerdo que era al intentar almacenar WEDNESDAY. Si alguien recuerda la historia que ponga el enlace.