Mejor accidente de administrador del sistema [cerrado]

Estoy buscando historias divertidas de accidentes de administradores de sistemas que haya tenido. Eliminar el correo electrónico del CEO, formatear el disco duro incorrecto, etc.

Agregaré mi propia historia como respuesta.

Me divertí descubriendo la diferencia entre el comando "killall" de linux (mata todos los procesos que coinciden con el nombre especificado, útil para detener zombies) y el comando "killall" de solaris (mata todos los procesos y detiene el sistema, útil para detener el servidor de producción en en la mitad de las horas pico y haciendo que todos tus compañeros de trabajo se rían de ti durante una semana).

Estaba a cargo de nuestro proxy web corporativo que en ese momento era el producto de Netscape. Mientras jugaba en los formularios de administración (era una interfaz basada en la web) había un gran botón (y juro que era rojo) que decía Eliminar base de datos del usuario . No hay problema, pensé. Veamos cuáles son las opciones que me da cuando golpeo eso. Seguramente habrá un mensaje de confirmación si no hay opciones.

Sí, no hay confirmación Sin opciones. No más usuarios.

Entonces, fui al Sr. Solaris Sysadmin y le dije que necesitaba desesperadamente una restauración de la cinta, a lo que él respondió: "No respaldo esa caja".

"Uh, ven de nuevo", le respondí.

"No respaldo esa caja. Está en mi lista de cosas para agregar a la rotación de respaldo, pero aún no la he logrado".

"¡Este servidor ha estado en producción durante casi 8 meses!" Grité.

encogiéndose de hombros , respondió. "Lo siento."

Hace muchos años, la compañía para la que trabajaba tenía un cliente que ejecutaba una copia de seguridad nocturna de su servidor NT 4.0 en una unidad Jaz (como un disco zip de alta capacidad).

Configuramos un archivo por lotes, que se ejecutó como un trabajo programado durante la noche. Todas las mañanas recogían el disco de las últimas noches de la unidad, y antes de irse por la tarde, insertaban el siguiente disco en la secuencia.

De todos modos, el archivo por lotes se parecía a esto (la unidad Jaz era unidad F:) ...

@echo off
F:
deltree /y *.*
xcopy <important files> F:

De todos modos, una noche se olvidaron de poner el disco. El cambio a la unidad F: falló (no hay disco en la unidad), y el archivo por lotes continuó ejecutándose. ¿El directorio de trabajo predeterminado para el archivo por lotes? C:. La primera vez que he visto una rutina de copia de seguridad destruir el servidor que estaba haciendo una copia de seguridad.

Ese día aprendí algo sobre la administración de sistemas (y el manejo de excepciones).

Jim

PD: ¿La solución? "deltree / y F: \ *. *".

root @ dbhost # find / -name core -exec rm -f {} \;

Yo: "¿No puedes entrar? OK. ¿Cuál es el nombre de DB?"

Cu: "Core".

Yo: "Oh".

Me encanta la forma en que todos califican su historia con "cuando era joven / verde" como si nunca lo volvieran a hacer. Los accidentes pueden suceder incluso a los profesionales más experimentados.

Mi peor momento es tan malo que todavía me dan palpitaciones al pensar en eso ...

Teníamos una SAN con datos de producción. Crítico para la empresa. Mi "mentor" decidió extender una partición para liberar espacio en el disco. ¿Puedes ver hacia dónde se dirige esto? Dijo que el software SAN podría hacer esto en vivo, en horas de producción y nadie se daría cuenta. Las campanas de alarma deberían haber comenzado a sonar, pero eran notablemente silenciosas. Dijo que lo había hecho "muchas veces antes" sin problemas. Pero aquí está la cosa: ¡me hizo hacer clic en el botón que decía "¿estás seguro?" Como era nuevo en la empresa, asumí que este tipo sabía de lo que estaba hablando. Gran error. La buena noticia fue que el LUN se extendió. La mala noticia fue ... bueno, sabía que había malas noticias cuando comencé a ver errores de escritura en el disco en el cuadro de Windows.

Me alegro de estar usando pantalones marrones.

Tuvimos que explicar por qué 1 TB de datos habían desaparecido a la hora del almuerzo. Ese fue un muy, muy mal día.

En realidad, es un buen principio: antes de hacer algo sobre lo que tenga dudas, imagine tener que explicarle a la gerencia si algo sale mal. Si no puede pensar en una buena respuesta para explicar sus acciones, no lo haga.

Nagios nos llamó la atención una mañana cuando el horario comercial comenzó a decir que no podía conectarse a un servidor no crítico. Ok, camina a la sala de servidores. Es un servidor antiguo, un Dell 1650 comprado en '02, y sabíamos que los 1650 habían tenido problemas de hardware. El PFY apuñala el botón de encendido. Nada. Golpee nuevamente y manténgalo presionado durante cinco segundos para 'forzar el encendido' ... lo que anula la protección contra errores del BMC, ya que sin un DRAC no hay forma de examinar los registros del BMC sin tener el chasis encendido.

La máquina inicia POST y luego muere nuevamente. Estoy de pie encima y digo: "Huelo humo". Sacamos el servidor de sus rieles y una de las fuentes de alimentación se siente caliente, por lo que el PFY lo tira y está a punto de cerrar la caja. Yo digo: "No, eso no es humo de la fuente de alimentación, es humo de la placa base".

Abrimos la caja nuevamente y buscamos la fuente del olor a quemado. Resulta que una bobina inductora y un condensador algo explotó del regulador de voltaje en la placa base, y roció cobre fundido y un condensador en todo, acortando un montón de cosas y básicamente haciendo un gran desastre.

La peor parte para mí fue reconocer que había fumado suficiente hardware para reconocer la diferencia entre el olor de una placa base quemada y una fuente de alimentación quemada.

Hace tres días (en serio), inicié sesión de forma remota en un servidor escolar, instalando el Service Pack 2 en un servidor de archivos de Windows Server 2008.

Decidí programar el reinicio necesario a altas horas de la noche, cuando los maestros no estarían conectados para terminar sus boletas de calificaciones de fin de año. Escribí algo como:

 a las 23:59 "apagado -r -t 0" 

... que podría haber funcionado bien.

Pero luego me adiviné a mí mismo. ¿Era correcta la sintaxis de 'apagado'? Traté de ver la ayuda de uso escribiendo

 apagado / h 

... e instantáneamente perdí mi conexión RDP. En pánico, busqué en Google la sintaxis. Una búsqueda rápida reveló que la versión de apagado de Server 2008 incluye un interruptor / h, que (como habrás adivinado) hiberna la máquina.

Los maestros comenzaron a llamarme en cuestión de minutos para informar que ya no podían abrir o guardar las boletas de calificaciones en las que habían estado trabajando. Como estaba fuera del sitio y la sala de servidores estaba cerrada, tuve que llamar al director de la escuela directamente y guiarla a través del proceso de volver a encender la máquina.

Hoy traje galletas caseras a todos como una forma de disculpa.

En un trabajo anterior, teníamos un excelente sistema de cosecha propia que registraba y archivaba cada pieza de correo que ingresaba, salía o permanecía dentro de la empresa.

¿Volaste todo tu buzón? ¡No hay problema! ¿Busca un correo que alguien le envió hace una semana / mes / año pero no recuerda quién lo envió o cuál fue el tema? ¡No hay problema! Volveremos a enviar todo desde febrero para usted a una carpeta especial.

En algún momento, surgió la necesidad de que el CEO de la compañía supervise el correo entre un competidor y un vendedor interno bajo sospecha. Así que configuramos un script que se ejecutaba todas las noches y entregaba el correo relevante del día anterior al CEO. ¡No hay problema!

Alrededor de un mes después, la noticia de un problema urgente doble más surgió de lo alto. Parece que mientras el CEO estaba leyendo la lista de correos enviados a $ OTHERCOMPANY, se encontró con este:

To: somebody@$OTHERCOMPANY
From: CEO
Subject: CEO has read your message (subject line here)

Naturalmente, siendo el CEO una persona importante y todo, estaba demasiado ocupado para hacer clic en todos los cuadros de diálogo "Enviar confirmación de lectura" en Outlook y había configurado a su cliente para que simplemente los enviara a todos. Uno de los mensajes capturados por el filtro de monitoreo tenía un conjunto de solicitud de recibo de lectura. ¿Adivina qué hizo Outlook? Ciertamente fastidió el monitoreo 'clandestino'.

Nuestra siguiente tarea: agregar reglas al filtro de correo para bloquear los recibos de lectura salientes del CEO a esa compañía. Sí, fue la forma más fácil. :)

Ahhh, la mía fue hace unos 10 años, cuando todavía me estaba mojando los pies. Tuve la alegría de instalar baterías de respaldo en todas las computadoras de los programadores. También querían que se cargara el software para advertir sobre un corte de energía y apagarse correctamente.

Así que lo configuré en mi computadora para probar todo primero, por supuesto, y asegurarme de que todo funcionó. Así que desconecto el cable de alimentación y aparece el mensaje en mi pantalla. "energía externa perdida, comenzando el apagado del sistema".

Entonces pensé, hey genial, funcionó. Pero por alguna extraña razón, ni siquiera recuerdo, envió ese mensaje como un mensaje de red, por lo que todas las más de 200 computadoras de la compañía recibieron ese mensaje, donde más de 100 usuarios fueron programadores.

¡Sí, hablamos de locura!

¡Mantuve mi cabeza baja en ese lugar por un tiempo!

A menudo usaba el comando "sys-unconfig" en máquinas Solaris para restablecer el servicio de Nombre de máquina, la dirección IP y la contraseña de root. Estaba en un sistema de usuarios e inicié sesión en el servidor de instalación del edificio y busqué algo (como root), luego olvidé que había iniciado sesión en otra máquina (mensaje "#" no descriptivo) Ejecuté el comando "sys-unconfig".

# sys-unconfig     
        WARNING

This program will unconfigure your system.  It will cause it
to revert to a "blank" system - it will not have a name or know
about other systems or networks.

This program will also halt the system.

Do you want to continue (y/n) ? y

Connection closed

#

Ese mensaje de "conexión cerrada" se convirtió lentamente en pánico ... en qué máquina estaba conectado cuando ejecuté ese comando.

La peor parte de esto no fue el mal momento que me dieron mis compañeros de trabajo, sino que hice lo mismo un mes después.

Tengo una muy buena. Es cierto que fue antes de mi tiempo como administrador de sistemas, pero todavía estaba relacionado con la tecnología, así que pensé que lo agregaría.

En el pasado, trabajaba como técnico de satcom / banda ancha para la USAF. Después de graduarme de la escuela técnica, me encontré estacionado en Corea del Sur. Poco después de llegar a la estación, surgió la oportunidad de viajar hacia el sur con los "grandes" que habían estado allí por un tiempo y trabajar realmente en algún equipo del mundo real (es decir, "producción").

Bajé con la tripulación y, como un joven y entusiasta técnico, estaba masticando un poco, muy emocionado ante la perspectiva de tener en mis manos un equipo real que estaba pasando tráfico de datos y voz militar EN VIVO.

Para comenzar lentamente, me entregaron un manual, pasaron a la sección de mantenimiento preventivo y me señalaron en la dirección de cuatro bastidores llenos de varios multiplexores digitales grandes. El equipo fue bastante fácil, cubrimos el mismo equipo en la escuela de tecnología.

Primera página del manual leído; "Aplique energía al multiplexor digital. Gire ambos interruptores traseros a la posición de ENCENDIDO y espere a que se encienda el equipo, luego comience las pruebas". ¡Miré hacia arriba y ya había energía APLICADA!

Estaba en un dilema seguro. Sin saber cómo proceder, disparé lo mejor que pude, 'Ummmm ... un poco perdido aquí' mira al senior.

Me miró y se rió, "No, no, está bien. Puedes ignorar esa parte de la lista de verificación". Luego, cuando notó la expresión de mi cara, (dado que en la escuela nos enseñaron a NUNCA, NUNCA ignorar cualquier parte de una lista de verificación, y era una muerte y destrucción segura si se hiciera eso) puso una mirada seria en su rostro. y dijo: "¡Ignora SÓLO esa parte! ¡Sigue el resto al pie de la letra!"

Cuidadosamente, seguí las instrucciones de PM de varios pasos, feliz como una almeja y orgulloso de que dejaran que un técnico de tan bajo rango (aunque inteligente) hiciera este importante trabajo.

En algún lugar entre la quinta y sexta lista de verificación de mantenimiento preventivo en estos enormes multiplexores, comencé a notar un mayor nivel de actividad a mi alrededor. Los teléfonos sonaban, la gente se movía rápidamente. Miradas extravagantes estaban siendo intercambiadas.

Finalmente, un grupo de personas corrió hacia mí, encabezado por uno de los técnicos superiores que me había derribado.

"¡Oye! ¡Estamos viendo ENORMES interrupciones en el tráfico de datos, y hemos aislado / rastreado el camino de regreso a los bastidores en los que estás trabajando! ¿Estás viendo algo extraño ..."

(En ese momento, fue interrumpido por otro de los solucionadores de problemas que se dirigió al primer grupo de multiplexores en el que había estado realizando los PM).

"¡NUEVAS TUERCAS! ¡ESTÁN APAGADAS! ¡LAS HA APAGADO!"

En poco tiempo, observé mientras corrían apresuradamente a través del primer paso en el manual, "Gire ambos interruptores traseros a la posición de ENCENDIDO ..." Cuando el técnico superior terminó, se acercó a mí y me preguntó con incredulidad qué estaba pensando. de, apagando los equipos críticos.

Asustado de mi ingenio, le entregué la lista de verificación que había estado siguiendo, jurando que no me había desviado en absoluto. Que lo había seguido, "al pie de la letra" como él me había indicado.

Después de un rato se echó a reír y señaló dónde estaba el problema.

En el manual, el paso FINAL en la lista de verificación de mantenimiento preventivo fue:

"Registre la lectura final de la sonda, limpie el panel frontal, elimine todo el polvo y las partículas, luego coloque ambos interruptores de alimentación traseros en la posición de APAGADO".

:)

Es una especie de accidente de administrador de sistemas ... en la medida en que los administradores de sistemas ocasionalmente tienen que transportar físicamente un gran número de máquinas desde el punto A al punto B (donde A y B aparentemente siempre están separados por varios tramos de escaleras en un edificio sin ascensor). En el enésimo viaje del día, me detuve a tomar un respiro tres pisos más arriba del nivel de carga del sótano para conversar con alguien que bajaba, apoyé la torre de gran tamaño con la estación que estaba subiendo en el pasamanos interior de la escalera abierta y ... bueno, adivinaste ... perdí un poco mi control sobre eso. Se hundió infaliblemente por el pozo y cuando llegó al fondo, er ... ¡no tanto con la funcionalidad para ese! Total de piezas recuperables: dos palos de RAM, una unidad de disquete y una tarjeta ISDN (¡Dios bendiga a los ingenieros de Hermstedt!). Todo lo demás se rompió,

Por la gracia de Dios, nadie caminaba debajo, lo que, afortunadamente para mí, fue el primero de mi jefe, así que tuve que mantener mi trabajo. Sin embargo, me sentí muy enfermo durante una hora más o menos.

Moraleja: ¡la gravedad siempre gana!

Estaba recargando un sistema para alguien, y durante el proceso de copia de seguridad manual le hice la pregunta "¿Tiene algún otro programa que use?" y "¿Hay algo más importante que hagas en la computadora?"

Él dijo "no" VARIAS veces.

Estaba convencido y formateé el disco.

Unos 30 minutos después, dijo "oh, Dios mío" y se llevó las dos manos a la cabeza.

Resulta que había estado trabajando en un guión de libro durante más de 10 AÑOS en un programa especializado. Esto fue cuando los programas solían guardar los datos del usuario en su directorio de archivos de programa y lo perdí.

Whhhooooops.

No estaba enojado conmigo, pero era un sentimiento aleccionador.

Mi favorito personal no es realmente el mío, y estoy MUY contento de ello. Echa un vistazo aquí.

Esto no me pasó a mí, pero ...

Estaba trabajando en una empresa que fabricaba software que se ejecutaba en máquinas Linux proporcionadas por el cliente. Esencialmente, nos haríamos cargo de las máquinas, las configuraríamos completamente según nuestras especificaciones y haríamos toda la gestión y supervisión. Esencialmente, éramos un equipo de 10-15 administradores de sistemas, administrando miles de servidores para cientos de clientes. Los errores estaban destinados a suceder.

Uno de nuestro equipo encontró algunos problemas en un servidor (una copia de seguridad, creo), y decidió que debería ejecutar fsck en él. Detuvo todos los servicios relevantes, se aseguró de que el sistema hubiera recibido copias de seguridad recientemente y luego ejecutó el fsck, pero se quejó de que el sistema de archivos estaba montado. Como éramos remotos y no teníamos acceso remoto (DRAC, OIT, etc.), no podía hacer el fsck, pero estaba bastante seguro de que era seguro hacerlo con el sistema de archivos montado, si tenía cuidado.

Decidió probarlo él mismo ejecutando fsck en su partición raíz, con resultados predecibles: corrompió su partición raíz y no pudo arrancar más.

Confundido, fue y habló con el líder de nuestro equipo. El líder dijo que estaba bastante seguro de que no se podía hacer eso, y el miembro del equipo dijo "¡Claro que sí!", Tomó el teclado del líder y le mostró que podía hacerlo, ejecutando fsck en la partición raíz del líder. Que corrompió por completo su partición raíz.

¿Resultado final? No se pierden datos de clientes, gracias a las pruebas realizadas por el miembro del equipo. Se perdieron dos días de productividad de los empleados, pero eso valía mucho, mucho menos que los datos en la máquina del cliente. ¿Y para el registro? Puede ejecutar fsck en una unidad montada, pero solo para verificar los datos. No para repararlo. Ese fue el error del miembro del equipo.

-

Para agregar mi propia historia, estaba trabajando en la misma compañía e intentaba restablecer una contraseña de usuario. Nuestro sistema se negó a permitirme establecer la contraseña que necesitaba, porque rastreó los hashes de contraseñas antiguas y se negó a permitirle duplicar la contraseña. El mecanismo era simple: validaba su contraseña contra el hash más reciente en la base de datos.

(Y para el registro, tenía que ser la contraseña anterior porque era una cuenta compartida, y asegurarse de que todos supieran que la nueva contraseña no era práctica)

Decidí ir a la base de datos de usuarios y eliminar los nuevos registros para que usara el anterior. Todo es solo SQL (ejecuta una versión antigua de Sybase), por lo que es fácil. Primero, tuve que encontrar los registros:

SELECT * FROM users_passwords WHERE username='someuser';

Encontré el viejo registro que quería mantener; Había dos más delante. Decidí ser inteligente y simplemente eliminar algo más nuevo que el registro anterior. Al observar el conjunto de resultados, vi que la contraseña anterior era ID # 28 en la base de datos, y las nuevas eran ID # varios miles (sistema muy ocupado). Eso es simple, todas las filas antiguas eran> 28, así que:

DELETE FROM users_passwords WHERE id > 28;

No hay nada peor que hacer una poda simple y ver '212,500 filas afectadas'. Afortunadamente, teníamos dos servidores de bases de datos maestros (con el ID de usuario), pero Sybase (al menos, nuestra versión) no admitía la replicación automática, por lo que no borró automáticamente los registros antiguos. Era un asunto trivial obtener un volcado de la tabla users_passwords y volver a importarlo. Aún así, un muy grande '¡oh f ** k!' momento.

Otro de mis favoritos:

Al configurar una computadora y una impresora láser local en un sistema, tuve la brillante idea de conectarlos a ambos en el UPS de la computadora. ¿Alguna vez trató de imprimir en una impresora láser local cuando está conectada a una UPS de escritorio? Bueno, si no lo sabe, tiende a extraer todos los amplificadores ... Lo que reinicia la computadora ... ¡Y el trabajo de impresión nunca termina ...!

Alguna vez recibiste la llamada: ' Cada vez que imprimo, reinicia mi computadora y no se imprime. '?

Ooops!

JFV

Declaración DELETE sin una cláusula WHERE, en la base de datos de clientes en vivo de los clientes.

Escrito kill 1como root. inity todos sus hijos murieron. Y todos sus hijos. etc, etc. ¡Vaya!

Lo que quise escribir fue kill %1

Después de darme cuenta de lo que hice, corrí al panel de control de una gran máquina clasificadora de balas de lana y presioné el botón de parada de emergencia. Esto detuvo la máquina que se rompió en pedazos, ya que acababa de matar el software que lo controlaba.

Estábamos en medio de un corte de energía y vimos que el UPS estaba funcionando al 112% de su carga configurada. Esto no fue un gran problema ya que estábamos corriendo en el generador en ese momento.

Así que fuimos tirando de cables de alimentación de respaldo para reducir el uso de energía en ese UPS (teníamos dos, uno mucho más grande que el otro). Llegamos al conmutador de red que ejecutaba la sala de servidores (esta era la sala de servidores con todos los servidores internos de la empresa, con el cliente frente a los servidores en otra sala de servidores). El conmutador era un conmutador de clase empresarial grande con tres fuentes de alimentación. Los suministros eran N + 1, por lo que solo necesitábamos dos para ejecutar el cambio.

Cogimos un cable y lo sacamos. Desafortunadamente para nosotros, los otros dos estaban enchufados a una sola regleta de alimentación, que explotó rápidamente a medida que aumentaba la carga en las dos fuentes de alimentación que estaban conectadas a ella. El administrador del sistema entró en pánico y enchufó el tercer cable. El interruptor intentó encenderse, poniendo toda la carga del interruptor en la fuente de alimentación. En lugar de que la fuente de alimentación se apagara, explotó en una lluvia de chispas a menos de 12 pulgadas de mi cara y me hizo saltar de nuevo al estante de servidores.

Por instinto intenté saltar a un lado, pero desafortunadamente a mi izquierda había una pared, y dos a mi derecha era un tipo de instalaciones muy grande de 6'4 ". De alguna manera logré saltar sobre él, o posiblemente a través de él rebotando de los bastidores de Compaq (los que tienen los frentes de malla delgada) sin poner un todo en el bastidor y sin tocar el tipo de instalaciones.

En algún momento de mi carrera, una investigación legal en la empresa para la que trabajaba nos exigió que se mantuviera todo el correo electrónico desde "este día" en adelante, hasta que se indique lo contrario. Después de aproximadamente un año de almacenar copias de seguridad completas diarias de nuestro entorno de intercambio (1 TB por noche) comenzamos a quedarnos sin espacio.

Los administradores de intercambio sugirieron que solo guardemos cada 8a copia del correo electrónico. Para hacer esto, les pedimos que restauren un día de las bases de datos de intercambio, extraigan el correo electrónico que necesitaban (personas específicas marcadas para investigación) y lo vuelvan a archivar. Lo hicieron por cada octavo día de correo electrónico para todas nuestras copias de seguridad. Se eligió el octavo día porque el intercambio tenía un conjunto de parámetros donde los "elementos eliminados" se mantienen en la base de datos durante 8 días.

Después de que terminaran cada archivo, volvería a revisar y eliminaría cualquier copia de seguridad que fuera anterior a lo que habían archivado.

TSM no tiene una manera fácil de hacer esto, por lo que debe eliminar manualmente los objetos de la base de datos de respaldo.

Escribí un script que eliminaría todas las copias de seguridad anteriores a alguna fecha, a través de un cálculo de fecha usando la diferencia entre hoy y la fecha en cuestión. Algún día tuve que eliminar aproximadamente un mes de copias de seguridad, excepto cuando hice el cálculo de la fecha, hice un error tipográfico e ingresé la fecha como 10/07/2007 en lugar de 10/06/2007, y ejecuté el script. Eliminé todo un mes adicional de datos, accidentalmente, lo cual fue parte de una demanda muy importante.

Después de eso, agregué algunos pasos al script para confirmar que quería eliminar los datos y mostrarle lo que iba a eliminar ...

Afortunadamente, nunca usaron ninguno de los datos que trabajamos tanto para preservar, y todavía tengo mi trabajo.

Después de un largo día o de rastrear el rendimiento y ajustar un gran mainframe (ya sabes las bestias que tardan un par de horas antes de que todos los sitios de respaldo en espera hayan acordado que realmente se reinició y se sincronizó por completo) Estiré los dedos, escribí apagado satisfecho -p ahora en el mensaje de mi computadora portátil, cerré la tapa, saqué el cable serial de la unidad central, con la anticipación de un buen vaso de cerveza fría.

De repente escucho el sonido ensordecedor de girar la computadora central mientras mi computadora portátil todavía mostraba felizmente X.

Mientras esperaba que la máquina volviera a estar completamente en línea, decidí que tenía tiempo para hacer que mi ACPI funcionara en mi computadora portátil, por lo que nunca tuve la tentación de apagar mi computadora portátil.

Este accidente no sucedió ... pero vale la pena mencionarlo:

Me enviaron a un centro de datos muy utilizado para realizar pruebas de ancho de banda en un nuevo circuito. Llegué a la sala de demarcación / IDF, encontré un lugar en uno de los bastidores para mi enrutador de prueba, hice mis conexiones y comencé las pruebas. Desafortunadamente, no noté por completo que el enrutador de borde en producción no solo estaba exactamente en el siguiente rack (casi al mismo nivel), sino que también era de la misma marca y modelo que mi enrutador de prueba.

Cuando se realizó la prueba, comencé a presionar el interruptor de encendido a la posición de apagado (... imagínelo en cámara lenta ...) y, lo juro, justo cuando estaba aplicando presión, me di cuenta de que el enrutador estaba cerca apagar fue el que estaba en producción. Mi corazón se detuvo y casi ... bueno, uso tu imaginación.

Dejé el MDF del centro de datos con aspecto aterrorizado y pálido, ¡pero al mismo tiempo contento de que todavía tuviera un trabajo!

Eliminé la cuenta de alguien por error, confundí los nombres con el que se suponía que debía eliminar. Opps

Lo bueno es que nunca supieron lo que pasó. Recibí la llamada que no podían iniciar sesión, el centavo cayó sobre la cuenta que eliminé.

Mientras hablaba con ellos por teléfono, rápidamente volví a crear su cuenta, volví a adjuntar su buzón anterior (afortunadamente, Exchange no elimina los buzones de inmediato) y lo apunté a sus viejos archivos de usuario.

Luego los culpé por olvidar su contraseña, que acababa de restablecer para ellos :)

Accidentalmente instalé un archivo tar.gz en mi caja Gentoo Linux en el lugar equivocado y dejó archivos por todas partes. Esto debe haber sido alrededor de 1999, 19 en ese momento (gracias por los comentarios a continuación)

Siendo el geek que soy, decidí tratar de hacer un script fuera del trabajo de revisar manualmente cada archivo.

Entonces intenté:

tar --list evilevilpackage.tar.gz | xargs rm -rf

No tardé mucho en darme cuenta de que tar también enumeraba todos los directorios que estaba usando el programa, los incluidos eran '' / usr, / var, / etc '' y algunos otros que realmente no quería que desaparecieran.

CTRL-C! CTRL-C! CTRL-C! ¡Demasiado tarde! Todo se fue, reinstala el tiempo. Afortunadamente, la caja no contenía nada importante.

Como una parte más pequeña de mi vida anterior, administré el servidor de archivos de la compañía, un cuadro de netware 4:11. Casi NUNCA necesitó ninguna entrada, pero si lo hizo, abrió una ventana de consola remota.

Acostumbrado a usar DOS todo el tiempo, cuando terminaba, naturalmente escribía "Salir". Para Netware, "salir" es el comando para apagar el sistema operativo. Afortunadamente, no le permitirá apagarlo a menos que primero "apague" el servidor (haga que no esté disponible para la red / clientes). Por lo tanto, cuando escribe "Salir" en la consola, dice útilmente: "Primero debe escribir" Abajo "antes de que puedas salir"

Pregúnteme cuántas veces 1: escribí "salir" en la sesión de consola y 2: escribí obedientemente "Abajo" y luego "Salir" para poder "terminar lo que estaba tratando de hacer"

Y luego el teléfono comienza a sonar .....

Jajaja

Otra historia que no sucedió (uf):

Estábamos haciendo copias de seguridad incrementales religiosamente todos los días en una unidad de cinta.

Por casualidad escribimos una cinta que contenía datos para enviar a otra persona. Dijeron 'no podemos leer tu cinta'. De hecho, nosotros tampoco. O cualquier cinta de hecho.

Compramos otra unidad de cinta y contuvimos la respiración hasta que la instalamos.

Moraleja de la historia. Siempre asegúrese de probar sus copias de seguridad.

El último lugar donde trabajé, mi compañero de trabajo tenía a sus hijos con él en la sala de servidores (¿por qué? ¡NO TENGO IDEA!).

Se aseguró de que estuvieran lejos de los servidores y le explicó a su hijo de 5 años que no debía tocar CUALQUIERA de los servidores y ESPECIALMENTE ninguno de los interruptores de alimentación.

De hecho, los tenía cerca de la puerta ... (¿puedes ver a dónde va esto ...?)

El chico no tocó ninguno de los botones de encendido del servidor ... No, eso sería demasiado fácil de explicar. En su lugar, presionó el BOTÓN ROJO GRANDE que estaba cerca de la puerta ... ¡¡¡El botón que apaga la alimentación de TODA LA SALA DEL SERVIDOR !!!

Las líneas telefónicas comenzaron a encenderse inmediatamente preguntándose por qué Exchange, servidores de archivos, etc. no estaban disponibles ... ¡Imagínese tratando de explicar ESO al CEO!

-JFV

Una vez tuve una pelea con el software de monitoreo APC UPS. Al ser una empresa pequeña, teníamos un par de UPS pequeños y se configuraron varios servidores para monitorearlos. La mayoría de los servidores eran Linux, pero algunos ejecutaban Windows, por lo que fueron los que se usaron porque el software APC es solo Windows.

Sin embargo, el software de APC en ese momento estaba codificado para asumir que el UPS con el que está hablando también está encendiendo la PC. Este no fue el caso para este servidor, pero descubrí que es demasiado tarde para decirle que se detenga. También desafortunadamente, el programador principal estaba demostrando el producto de la compañía a un socio: era una aplicación basada en la web, que se ejecutaba en el mismo servidor que no quería que el software APC cerrara ...

Le estaba dando a un nuevo administrador de sistemas un recorrido por una aplicación de Service Manager. Le dije "si alguna vez necesitara detener este servicio, haría clic en este botón, pero nunca debería hacerlo durante el día". ¡Nunca creerías lo sensible que era el botón de su mouse!

Dos minutos después, el servicio había comenzado de nuevo y nadie parecía darse cuenta.

Tropezar con un servidor de torre que estaba encajado detrás de un bastidor y golpear mi cabeza en la parte posterior del enrutador principal de Cisco en mi camino hacia abajo. Por lo tanto, revela cuán holgadamente los cables de alimentación estaban realmente asentados en las fuentes de alimentación en la parte frontal del Catalyst 6500 .

Sí. Ahora tenemos un casco enganchado en la sala de servidores. Con mi nombre en el.