¿Cuál fue la interrupción del servicio web más difícil de resolver y qué lecciones aprendió?

Era 1996, estaba ejecutando el segundo ISP más grande en Houston. Fue verano. Las cosas no iban bien. Los fundadores, un equipo de marido y mujer, se estaban divorciando, las ventas de vicepresidentes habían desaparecido repentina e inesperadamente, y la administración anterior había estado, bueno, digamos más interesada en jugar con cosas técnicas interesantes que proporcionar un material sólido como una roca. servicio … Aún así, tuvimos clientes, tuvimos crecimiento, tuvimos un flujo de caja positivo y estaba bastante seguro de que había un pony allí en alguna parte …

Era un perezoso domingo por la tarde a principios de julio, y recibí una llamada en casa del técnico de guardia. “Um, Stan, tenemos un problema. El correo electrónico no funciona”.

Las preguntas y respuestas siguen mientras me dirijo a la oficina de mi casa y enciendo una computadora y me conecto al backplane de administración. El servidor simplemente no está allí.

Le pido que regrese a la sala de máquinas y vea si la corriente está encendida, y lo está. Esto no está bien. No es competente para hacer mucho más, le pido que regrese a los teléfonos y que todos sepan que estamos trabajando en ello y que verifique si hay actualizaciones en el sitio web, edite rápidamente el estado en el sitio web para decir que el correo electrónico no funciona y empezar a conducir

Llego allí y me dirijo a la sala de máquinas, hace un poco más de calor de lo que debería ser. Conecte una consola al servidor de correo electrónico, presione regresar, nada. Esto no está bien.

Apreté reset y esperé a que se iniciara. Surgió, fsck’d los sistemas de archivos, que comenzaron a arrojar errores, no solo errores del sistema de archivos, sino también errores del sector. Al menos un disco iba mal.

Finalmente todo volvió a subir, sin pérdida de datos. Inicié una copia de seguridad completa de la tienda de respaldo de correo electrónico, por si acaso, y de alguna manera lo vigilé por el resto del día.

No hay más problemas para el resto de la semana. Para estar seguro, configuré un servidor de correo electrónico de respaldo “por si acaso”.

Efectivamente, un poco después del mediodía del domingo siguiente, recibo la misma llamada. Misma rutina. Toma un poco más de esfuerzo hacer que las cosas vuelvan a funcionar, y decido cambiar una de las unidades de disco que arroja muchos errores.

La próxima semana, mismo ejercicio, un poco más temprano en el día. Y el siguiente. Y el siguiente. Finalmente, unas semanas después, recibo llamadas el sábado por la mañana.

Qué. Los. Infierno.

Eventualmente, por pura casualidad, descubro que, por alguna razón, el edificio HVAC se está cerrando el viernes a las 6 p.m., y que a medida que el clima se calienta progresivamente, el intervalo de tiempo antes de que se establezca “demasiado caliente para funcionar” se está acortando.

El servidor de correo electrónico seguía cayendo porque tenía la configuración “más gorda” y lo estábamos llevando al límite. Los otros servidores ejecutaban menos carga, más pausados, y el calor adicional, aunque no era realmente bueno para ellos, no era fatal.

Solución: señale a la administración del edificio que tenemos un contrato para HVAC las 24 horas, los 7 días de la semana, y que si quieren ahorrar dinero al no ejecutar el sistema para el resto del edificio, eso es genial, pero necesitan arreglarlo por nosotros . Fue una batalla, pero finalmente lo hicieron.

Lecciones aprendidas: siempre, siempre controle los parámetros ambientales en su centro de datos y la infraestructura informática crítica, y envíe alarmas ANTES de estar fuera de especificaciones.

Si bien hice esta pregunta y estoy muy, muy interesado en escuchar las respuestas de otras personas, esta es mi respuesta. Le rogaría a cualquier profesional de Internet que cuente su propia historia, en lugar de solo leer la mía.

Mi historia:

En 2002, eBay tuvo una interrupción de 10 horas por parte del cliente de la funcionalidad de misión crítica. Eso es un gran problema, porque esas subastas terminaron de manera inadecuada, millones de dólares en ingresos perdidos y una gran buena voluntad perdida para todos los clientes.

Después de tomar los pasos habituales de reversión y recuperación, nada funcionaba y las razones de la interrupción aún no estaban claras.

Los ejecutivos comenzaron a entrar en modo de pánico completo, discutiendo soluciones radicales como, descartar 100 años-hombre de trabajo de ingeniería y volver a una de las primeras versiones del software que ejecutaba el sitio de eBay.

Entonces alguien preguntó gentilmente: “Oye, ¿qué estabas diciendo antes sobre reemplazar un enrutador?” El equipo de operaciones se miró y gimió.

Resulta que … uno de los enrutadores clave había sido cambiado esa misma tarde, y las reglas no se habían vuelto a cargar correctamente en el nuevo hardware ni se había probado nada.

No estábamos enrutando el tráfico, porque no estábamos enrutando el tráfico.

Ugh – horrible recuerdo.

Fui con un ISP que costaba $ 80 al año (esto fue 2002) – excelente precio.
Fueron muy profesionales con la transferencia de nombres de dominio, ofrecieron muchos servicios (scripts de perl, toneladas de correo electrónico, toneladas de espacio, etc.): estos eran los días en que GoDaddy aún no estaba sucediendo.

Las cosas fueron geniales: creé tres sitios web usándolos. Hablé con ellos, tuve una gran relación, y me mostraron fotos de su sala de servidores, fue agradable.

… Entonces, una mañana, simplemente desaparecieron . En el aire.
… Lecciones aprendidas: siempre tenga una copia de seguridad y sea capaz de lidiar con un ISP que acaba de desaparecer; No creo que GoDaddy se vaya nunca, pero no confío en NINGÚN ISP después de esa experiencia.

Tenía copias de seguridad de todos los scripts e imágenes CGI, pero fue una de las peores experiencias de la historia.

Publicar anon para cubrir a los verdaderamente estúpidos. Tuvimos una falla de hardware en nuestro NAS, un controlador falló y necesitábamos sacar la unidad de nuestro colo. Este dispositivo transportaba todos nuestros archivos cargados por el usuario y necesitábamos la extracción de datos, por lo que hicimos los arreglos necesarios para enviarlos para la recuperación de datos. Mi gerente hizo los arreglos para que tiraran del color y lo dejó así. El personal de colo sacó el servidor de la base de datos principal fuera de línea y lo envió. Llevé a cabo toda la operación durante tres días mientras avanzábamos a los servidores db en su lugar, restauramos las copias de seguridad, etc.

Lecciones aprendidas: mire el sistema cada vez que alguien lo modifique. Nos costó $ 25k recuperarse de

Trabajé en un lugar de comercio de opciones cuando Nasdaq se congeló. No es exactamente una “interrupción del servicio web”, pero se sintió bastante similar.

Lección aprendida: nuestro sistema financiero funciona con software janky.

Estaba trabajando para MySpace en ese momento y alguien había eliminado la entrada DNS para el prefijo ” nosotros .myspace” porque pensaban que no se estaba utilizando. Sin embargo, nuestro tráfico cayó un 40% después de que el TTL de 86.400 segundos expiró en un momento en que supuestamente éramos el 10% del tráfico de Internet en todo el mundo. Tenga en cuenta que publicamos todos los videos que YouTube hizo en ese momento debido a una asociación con Google y esto fue antes de que Facebook tuviera su gran aumento. Además, si el sitio se desconectaba durante las horas pico, costaba $ 100K en ingresos por publicidad cada 6 minutos más o menos, nos dijeron.

Ingresé el prefijo nuevamente en nuestro DNS, luego las personas que conocían a la gente tuvieron que llamar a algunos ISP grandes para que empujaran manualmente la entrada al mundo.

Aprendí que a menos que sepas cuáles serán los resultados esperados, o que no serán demasiado dañinos, no te metas con eso. es decir, si no está roto, no lo arregles.