Worst SysAdmin Accident [fermé]

Conformément à la question sur le meilleur accident d'administrateur système , quel est le pire accident dans lequel vous avez été impliqué? Contrairement à la question précédente, je veux dire «pire» dans le sens de la plupart des dommages au système ou des dommages réels aux personnes.

Je vais commencer par le mien:

Nous avons deux armoires de câblage à distance qui se trouvent au bout d'un couloir de 100 pieds qui a une grille métallique pour le plancher. Après avoir installé le câble Cat6, les entrepreneurs ont nettoyé tous les débris qui sont tombés à travers la grille jusqu'au béton 3 pieds plus bas. Un collègue et moi sommes entrés dans le couloir pour vérifier les progrès un jour, mais nous avons été distraits et n'avons pas remarqué qu'un morceau de grille avait été mis de côté. Mon copain est entré dans l'air et sa poitrine a claqué dans la barre transversale en acier. Il était suffisamment essoufflé et endolori pour prendre quelques jours de congé, mais heureusement, la poutre en acier avait des bords arrondis et la taille de l'ouverture était telle qu'il ne lui avait pas frappé la tête ni le sol en dessous.

De toute évidence, nous avons appris que les zones où le sol est partiellement retiré doivent être signalées.

Imaginez si vous vivrez dans le sud de la Floride pendant l'ouragan Andrew (légèrement avant l'engouement du 24X7). Tous vos serveurs sont verrouillés en toute sécurité dans un bâtiment qui nécessite votre badge et une zone plus sécurisée nécessitant une analyse supplémentaire de votre badge. Imaginez un imbécile qui ne rendait pas compte d'avoir besoin de poignées réelles sur les portes. Imaginez un contrat de quatre millions de dollars nécessitant une livraison, l'électricité la plus proche étant à 230 miles au nord, le gaz étant en pénurie, des routes dangereuses et un générateur conçu pour fournir 48 heures d'électricité. Riez si vous voulez à une collection de serveurs à l'arrière d'un camion, coincé sur le péage de Mickey Mouse, calé par manque d'essence. Riez si vous voulez l'absence totale d'excuse sur la gravité de tout cela d'un point de vue logistique, administrateur système et opérationnel.

Lorsque je travaillais pour Cisco, j'avais l'habitude d'obtenir des clients qui avaient acheté des cartes sans fil à 30 $ et qui crachaient des puces lorsque leur pilote ne s'installait pas, ou des personnes avec le routeur le plus basique le moins cher que Cisco avait qui se déchaînaient et s'extasiaient sur les problèmes de support.

Tout cela a été mis en contexte un jour, quand j'ai reçu un appel d'un des plus grands fournisseurs de cartes du monde (pensez Amex, Mastercard, Visa, Diners ... en fait, c'était une de ces marques, je ne sais pas si elles apprécierait que je le mentionne). J'étais un soutien de première ligne, mon seul travail consistait à évaluer le scénario, à le noter et à le transmettre à la division de support appropriée. Ce cas était le seul cas de priorité un que j'ai jamais traité.

Un homme de la compagnie de cartes a appelé et a déclaré que leur lien entre leurs ordinateurs centraux américains de la côte est et ouest était en panne. Si un compte a été créé sur un ordinateur central, la transaction a toujours été traitée sur cet ordinateur central. Ce qui était bien si votre lien le plus proche était toujours proche de cet ordinateur central. Mais ce jour-là, si vous aviez un compte sur le serveur de la côte est, mais que vous étiez sur la côte ouest, la transaction serait refusée car le lien était en panne.

La question standard lors de l'évaluation des dommages était "Combien cela coûte-t-il à votre entreprise?" La réponse, calme et recueillie, était "environ un million de dollars toutes les 30 secondes".

La place vraiment dans son contexte la prochaine fois que vous vous sentirez tenté de vous plaindre et de vous délecter du support client par rapport à votre carte sans fil de 30 $.

(il convient de noter que Cisco avait sa liaison opérationnelle dans les 5 minutes suivant son transfert)

Il est très courant pour les commandes d'alias comme rm ou mv d'ajouter l'option '-i' pour éviter les erreurs. Mais cela s'est produit dans mon entreprise il y a quelque temps. Quelqu'un a mis cette ligne dans le .bashrc de root sur l'un des serveurs.

alias rm='rm -i'

Puis il a copié la ligne et substitué rm à mv ... ou alors il a pensé:

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

Le reste appartient à l'histoire :)

Eh bien, le fait est que lorsque vous posez la question `` êtes-vous sûr '', dites `` supprimer '' au lieu de `` déplacer '', mais pourtant ...

Nous installions un énorme système de point de vente chez un grand détaillant (plus de 1 000 succursales). Le serveur d'interrogation central était entièrement composé de code HP-Unix personnalisé, et le test de migration de production était géré par un seul homme - le fils du directeur informatique.

Ce gars a passé 7,95 heures de sa journée à lire des romans fantastiques, et les autres minutes à exécuter son travail par lots pour migrer les versions nocturnes vers la production. Le système était à 3 jours de sa mise en service dans 150 succursales (notre premier "vrai" déploiement). Tout était réglé et mon équipe venait de terminer de tester les derniers morceaux de code. Nous avons validé nos modifications et déplacé nos images du développement au test pour qu'elles soient récupérées par le fils du directeur informatique le lendemain matin.

J'arrive à 8h00 et tout est dans le chaos. Il s'avère que le fils avait été informé qu'après avoir copié les fichiers en production, il était censé aller dans le dossier ./changed et taper "rm -rf *". Oui, quelqu'un lui a dit ça! Bien sûr, il l'a accidentellement fait sur le lecteur racine de production, qui hébergeait également notre base de données d'interrogation transactionnelle (qui se trouvait être hors ligne pour les sauvegardes à l'époque, juste notre chance).

Résultat: nos 16 magasins pilotes ont dû servir les clients hors des boîtes à cigares (dans certains cas, littéralement) pendant 2 jours. Le fils du CIO a été rétrogradé à Server Watcher (il était assis dans la salle des serveurs glaciale et était censé surveiller les feux rouges ... mais il n'était pas autorisé à toucher quoi que ce soit ... ils ne lui ont même pas donné d'ordinateur et révoqué toutes ses connexions / e-mail). Notre équipe de développement a tiré une nuit blanche pour reconstruire les données perdues à partir des sauvegardes et retester / resoumettre le code.

Heureusement, nous avons fait le déploiement de 150 succursales, mais c'était la pire expérience de déploiement JAMAIS.

J'ai appris à terminer chaque phrase de commande avant d'appuyer sur la touche Entrée.

Une situation légèrement similaire à laquelle je fais face est lorsque je ne suis pas sûr d'une commande, j'appuie sur Accueil et saisis des caractères indésirables afin que la commande ne soit pas reconnue.

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

Et puis je vérifie à nouveau les options, lentement si besoin est. Est-ce que quelqu'un d'autre fait une telle chose. Bien sûr, vous devez vous assurer que vous tapez suffisamment de caractères indésirables (5+) , pour éviter qu'elle ne devienne une autre commande valide et ne fasse plus de dégâts imprévisibles.

(Y a-t-il un défaut fondamental que je n'ai pas compris ou une situation où, étant donné plus de 5 caractères indésirables, généralement dans les clés "asdfghjkl", cela fait quelque chose d'imprévisible?)

En réinstallant le système d'exploitation d'un ordinateur portable pour un gestionnaire, quelqu'un a fait une copie de toutes ses données sur le réseau vers une station Linux dans / tmp. Il y a eu quelques problèmes et cela a pris plus d'une journée.

... la station linux a été arrêtée à la fin de la journée ...

Le lendemain, quand ils sont allés chercher les données du manager ...

Je travaille en tant que SysAdmin depuis environ 7 mois, l'une de mes premières tâches a été de faire fonctionner un serveur proxy Squid et je l'ai effectivement fait fonctionner, comme 2 semaines après que j'utilisais BackTrack et que je jouais avec beaucoup d'outils " Jouer au Hacker "j'ai en fait piraté le serveur, ce qui était plutôt bien, mais après être entré pour une raison étrange, j'ai fait un rm -rf de / et une partie bien effacée du système d'exploitation (Debian linux).

J'ai appris à terminer chaque phrase de commande avant d'appuyer sur la touche Entrée.

À votre santé.

Un de nos clients a rencontré un bogue de système de fichiers XFS assez rare le 24 décembre 2005 ... Eh bien, à l'époque, je ne savais pas que c'était un bogue du noyau Linux, bien sûr, je pensais que ce n'était que quelques-uns des suspects habituels (13 To RAID avec 8 Ko de panne de disque parasite libre dans la baie, etc.).

Enfin, comme le système de fichiers n'était pas montable, j'ai demandé à l'opérateur sur la ligne d'entrer xfs_repair -n /dev/whatever. Hmm, il veut effacer le journal (évidemment, car le FS n'est pas montable), mais pas de message trop inquiétant. Alors allez-y: xfs_repair /dev/whatever.

15 minutes plus tard, elle rappelle:

pourquoi ne puis-je pas voir la plupart des fichiers?

Hu oh ... Il s'avère que pour ajouter l'insulte à la blessure, les xfsprogs étaient d'une version qui ferait du mal dans ce cas précis ... Aïe. 8 To de données avaient disparu pour de vrai.

Mon installation de colo a eu quelques temps d'arrêt il y a quelque temps.

Ils ont supprimé leur lien réseau principal vers Internet pour effectuer une maintenance logicielle sur le routeur, ce qui est assez juste.

Cependant, en même temps, le fournisseur en amont de la liaison secondaire l'a désactivé pour effectuer certains tests (apparemment, on leur avait dit, mais il avait été mal étiqueté dans le centre de données)

Jusqu'ici tout va bien ... cependant, les clients ont eu du mal à se rendre dans l'établissement pour porter le temps d'arrêt à l'attention du fournisseur .. le fournisseur n'avait que des téléphones VoIP, qui étaient connectés via ... eh bien, vous pouvez le deviner.

J'imagine que vous ne me croiriez pas, mais c'est vrai, et une question d'enregistrement sur la blogosphère :)

Je ne suis pas sûr que cela puisse être une réponse intéressante, mais je suis également codeur. J'ai codé mon dernier site Web complètement sur une production de façon évidente, sans aucune sauvegarde sur mon PC. Une mauvaise journée après 16 heures de travail continu, j'ai dû empthy une partition, et le moyen le plus rapide de le faire était de le formater. J'ai couru fdisk -lpour vérifier quel était le nom de la partition que je devais formater, et malheureusement j'ai lu la mauvaise ligne et je l'ai formatée.

J'ai perdu environ 6 mois de travail.

Heureusement, la deuxième fois que vous faites la même chose, vous le faites mieux et plus rapidement, car vous savez déjà comment le faire. Maintenant, le site Web est en ligne. Et j'ai des sauvegardes: =)