El peor accidente de SysAdmin [cerrado]

En línea con la pregunta sobre el mejor accidente de administrador de sistemas , ¿cuál es el peor accidente en el que ha estado involucrado? A diferencia de la pregunta anterior, quiero decir "peor" en el sentido de la mayoría de los daños al sistema o daños reales a las personas.

Comenzaré con el mío:

Tenemos dos armarios de cableado remoto que se encuentran al final de un corredor de 100 pies que tiene una rejilla metálica para el piso. Después de instalar el cable Cat6, los contratistas limpiaron todos los escombros que cayeron a través de la rejilla hasta el concreto a 3 pies por debajo. Un compañero de trabajo y yo entramos en el corredor para ver el progreso un día, pero estábamos distraídos y no nos dimos cuenta de que un pedazo de rejilla había sido apartado. Mi amigo salió al aire y su pecho se estrelló contra el travesaño de acero. Estaba sin aliento y lo suficientemente adolorido como para tomarse un par de días de descanso, pero afortunadamente la viga de acero tenía bordes redondeados y el tamaño de la abertura era tal que no golpeó su cabeza contra el piso de abajo.

Obviamente aprendimos que las áreas donde el piso se quita parcialmente deben marcarse.

Imagínese si vivirá en el sur de Florida durante el huracán Andrew (un poco antes de la locura 24X7). Todos sus servidores están encerrados de forma segura en un edificio que requiere su credencial y un área más segura que requiere un escaneo adicional de su credencial. Imagine un imbécil que no explica la necesidad de manijas reales en las puertas. Imagine un contrato de cuatro millones de dólares que requiere una entrega, la electricidad más cercana está a 230 millas al norte, el gas es escaso, las carreteras peligrosas y un generador que fue diseñado para proporcionar 48 horas de electricidad. Ríete si quieres en una colección de servidores que están en la parte trasera de un camión, atrapados en la autopista Mickey Mouse, estancados por falta de gasolina. Ríete si te apetece la falta total de una excusa de lo malo que fue todo desde un punto de vista logístico, de administrador de sistemas y operativo.

Cuando trabajaba para Cisco, solía tener clientes que habían comprado tarjetas inalámbricas de $ 30 y que estaban escupiendo chips cuando su controlador no se instalaba, o personas con el enrutador más básico y más barato que tenía Cisco que se quejaban por problemas de soporte.

Todo esto se puso en contexto un día, cuando recibí una llamada de uno de los proveedores de tarjetas más grandes del mundo (piense en Amex, Mastercard, Visa, Diners ... de hecho, era una de esas marcas, no sé si Agradecería que lo mencionara). Era el soporte de primera línea, mi único trabajo era evaluar el escenario, calificarlo y ponerlo en contacto con la división de soporte correspondiente. Este caso fue el único caso de Prioridad Uno que presenté.

Un hombre de la compañía de tarjetas llamó y declaró que su vínculo entre sus mainframes de la costa este y oeste de los EE. UU. Estaba desconectado. Si se creó una cuenta en un mainframe, la transacción siempre se procesó en ese mainframe. Lo cual estaba bien si su enlace más cercano siempre estaba cerca de ese mainframe. Pero en este día en particular, si tenía una cuenta en el servidor de la costa este, pero estaba en la costa oeste, la transacción sería denegada porque el enlace estaba desconectado.

La pregunta estándar al evaluar el daño fue "¿Cuánto le está costando a su negocio?" La respuesta, tranquila y serena, fue "Un millón de dólares cada 30 segundos".

Realmente lo pone en contexto la próxima vez que sienta la tentación de despotricar y entusiasmarse con la atención al cliente por encima de su tarjeta inalámbrica de $ 30.

(Cabe señalar que Cisco tenía su enlace en funcionamiento dentro de los 5 minutos posteriores a la transferencia)

Es muy común que los comandos alias como rm o mv agreguen la opción '-i' para evitar errores. Pero esto sucedió en mi empresa hace un tiempo. Alguien puso esta línea en el .bashrc de la raíz en uno de los servidores.

alias rm='rm -i'

Luego copió la línea y sustituyó rm por mv ... o eso pensó:

alias rm='rm -i'
alias mv='rm -i'

El resto es historia :)

Bueno, la cuestión es que cuando la pregunta "estás seguro" dice "eliminar" en lugar de "mover", pero aún así ...

Estábamos instalando un sistema masivo de punto de venta en un gran minorista (más de 1000 sucursales). El servidor de sondeo central era todo un código personalizado de HP-Unix, y la prueba para la migración de producción fue manejada por un solo individuo: el hijo del Director de TI.

Este tipo pasó 7.95 horas de su día leyendo novelas de fantasía, y los otros minutos ejecutando su trabajo por lotes para migrar las construcciones nocturnas a la producción. El sistema tardó 3 días en activarse en 150 de las sucursales (nuestro primer lanzamiento "real"). Todo estaba listo, y mi equipo acababa de terminar de probar las piezas finales de código. Comprometimos nuestros cambios y trasladamos nuestras imágenes del desarrollo a pruebas para que el hijo del Director de TI las recogiera a la mañana siguiente.

Llego a las 8:00 am y todo está en caos. Resulta que el hijo había recibido instrucciones de que después de copiar archivos a producción, se suponía que debía ir a la carpeta ./changed y escribir "rm -rf *". ¡Sí, alguien realmente le dijo esto! Por supuesto, accidentalmente hizo esto en la unidad raíz de producción, que también albergaba nuestra base de datos de encuestas transaccionales (que en ese momento estaba fuera de línea para las copias de seguridad, solo nuestra suerte).

Resultado: Nuestras 16 tiendas piloto tuvieron que servir a los clientes en cajas de cigarros (en algunos casos, literalmente) durante 2 días. El hijo del CIO fue degradado a Server Watcher (se sentó en la fría sala de servidores y se suponía que debía vigilar las luces rojas ... pero no se le permitió tocar nada ... ni siquiera le dieron una computadora y revocó todos sus inicios de sesión / correo electrónico). Nuestro equipo de desarrollo sacó una noche entera reconstruyendo datos perdidos de las copias de seguridad y volviendo a probar / volver a enviar el código.

Afortunadamente, realizamos el despliegue de 150 sucursales, pero fue la peor experiencia de despliegue de la historia.

Aprendí a terminar cada oración de comando antes de presionar la tecla Enter.

Una situación ligeramente similar a la que me enfrento es cuando no estoy seguro acerca de un comando, presiono Inicio y escribo algunos caracteres basura para que el comando no sea reconocido.

me@mypc:~$ sdkjfhdsudo mv --too-many --switches-to-be --comfortable --working-with --while-running --an-important-command /here/this /there/that

bash: sdkjfhdsudo: command not found

Y luego verifico las opciones nuevamente, lentamente si es necesario. ¿Alguien más hace tal cosa? Por supuesto, debe asegurarse de escribir suficientes caracteres basura (5+) , para evitar que se convierta en otro comando válido y cause un daño más impredecible.

(¿Hay un defecto básico en esto que no he descubierto o una situación en la que, dados más de 5 caracteres basura, típicamente en las teclas "asdfghjkl", hace algo impredecible?)

Al volver a instalar el sistema operativo de una computadora portátil para un administrador, alguien hizo una copia de todos sus datos a través de la red a una estación de Linux en / tmp. Hubo algunos problemas y tomó más de un día.

... la estación de Linux se cerró al final del día ...

Al día siguiente, cuando fueron a buscar los datos del gerente ...

He estado trabajando como SysAdmin durante aproximadamente 7 meses, una de mis primeras tareas fue ejecutar un servidor proxy Squid y, de hecho, lo puse a trabajar, como 2 semanas después de eso, estaba usando BackTrack y jugando con muchas herramientas " Jugar al pirata informático "En realidad pirateé el servidor, lo cual fue bastante bueno, pero después de entrar por alguna extraña razón, hice un rm -rf de / y borré bien parte del sistema operativo (Debian Linux).

Aprendí a terminar cada oración de comando antes de presionar la tecla Enter.

Salud.

Uno de nuestros clientes encontró un error bastante raro en el sistema de archivos XFS el 24 de diciembre de 2005 ... Bueno, en ese momento no sabía que era un error del kernel de Linux, por supuesto, pensé que eran solo algunos de los sospechosos habituales (RAID de 13 TB) con 8 KB libres, fallas falsas de la unidad en la matriz, etc.

Finalmente, como el sistema de archivos no se podía montar, le pedí al operador en la línea que ingresara xfs_repair -n /dev/whatever. Hmm, quiere borrar el registro (obviamente, ya que el FS no se puede montar), pero no hay un mensaje demasiado siniestro. Así que ir a por ello: xfs_repair /dev/whatever.

15 minutos después, ella vuelve a llamar:

¿Por qué no puedo ver la mayoría de los archivos?

Hu oh ... Resulta que para agregar insulto a la lesión, los xfsprogs eran de alguna versión que haría un daño severo en este caso exacto ... Ouch. 8 TB de datos se han ido de verdad.

Mi instalación de colo tuvo un tiempo de inactividad hace un tiempo.

Quitaron su enlace de red principal a Internet para realizar un mantenimiento de software en el enrutador, lo suficientemente justo.

Sin embargo, al mismo tiempo, el proveedor ascendente del enlace secundario lo apagó para realizar algunas pruebas (aparentemente se les había dicho, pero se había etiquetado incorrectamente en el centro de datos)

Hasta ahora todo mal ... sin embargo, los clientes tuvieron algunas dificultades para llegar a las instalaciones para llamar la atención del proveedor sobre el tiempo de inactividad ... el proveedor solo tenía teléfonos VoIP, que estaban conectados a través ... bueno, se puede adivinar.

Me imagino que no me creerías, pero es cierto, y es una cuestión de registro en la blogosfera :)

No estoy seguro de que esta pueda ser una respuesta interesante, pero también soy un programador. Codifiqué mi último sitio web por completo en un evoirement de producción, sin copias de seguridad en mi PC. Un mal día después de 16 horas de trabajo continuo, tuve que vaciar una partición, y la forma más rápida de hacerlo fue formatearla. Corrí fdisk -lpara verificar cuál era el nombre de la partición que tenía que formatear, y desafortunadamente leí la línea incorrecta y la formateé.

Perdí como 6 meses de trabajo.

Afortunadamente, la segunda vez que haces lo mismo lo haces mejor y más rápido, ya que ya sabes cómo hacerlo. Ahora el sitio web está en vivo. Y tengo copias de seguridad: =)