最悪のSysAdmin事故
最高のシステム管理者の事故 についての質問に沿って、あなたが関わった中で最悪の事故は何ですか？前の質問とは異なり、私はほとんどのシステムの損傷または人々への実際の危害という意味で「最悪」を意味します。
私は私のものから始めましょう：
床用の金属格子がある100フィートの廊下の端にある2つのリモート配線クローゼットがあります。 Cat6ケーブルを設置した後、請負業者は、格子を通って3フィート下のコンクリートに落下したすべての破片を掃除しました。ある日、同僚と私は廊下に入って進行状況を確認しましたが、気が散って、格子が脇に移動していることに気づきませんでした。私の相棒は空中に足を踏み入れ、彼の胸は鋼鉄のクロスバーにぶつかった。彼は曲がりくねって数日休むのに十分なほど痛かったが、幸いなことに鋼の梁は丸い縁を持っていて、開口部の大きさは彼が頭や下の床を叩かないような大きさだった。
明らかに、床が部分的に削除されている領域にはフラグを立てる必要があることを学びました。
ハリケーンアンドリューの最中（24時間年中無休の流行の少し前）に南フロリダに住むと想像してみてください。すべてのサーバーは、バッジを必要とする建物と、バッジの追加スキャンを必要とするより安全なエリアに安全にロックされています。ドアに実際のハンドルが必要なことを考慮していないニトウィットを想像してみてください。配達が必要な400万ドルの契約を想像してみてください。最も近い電力は北に230マイル、ガスは不足しており、危険な道路、そして48時間の電力を供給するように設計された発電機です。トラックの後ろにあるサーバーのコレクションで、ミッキーマウスのターンパイクに引っかかって、ガスが不足しているために行き詰まっている場合は、笑ってください。ロジスティクス、システム管理、および運用の観点から、すべてがどれほどひどいものであったかについての言い訳がまったくない場合は、笑ってください。一番良かったのは、何百ものUPSユニットが命を与えるために同時に泣いているのを聞くことでした。
私がシスコで働いていたとき、30ドルのワイヤレスカードを購入し、ドライバがインストールされないときにチップを吐き出している顧客や、シスコが持っていた最も安価な最も基本的なルーターを持っている人々に、サポートの問題を怒鳴りつけて絶賛してもらいました。
ある日、世界最大のカードプロバイダー（Amex、Mastercard、Visa、Dinersなど）から電話がかかってきたとき、これはすべて状況に応じて行われました。実際、それはそれらのブランドの1つでしたが、それらかどうかはわかりません。言及していただければ幸いです）。私は最前線のサポートでした。私の唯一の仕事は、シナリオを評価し、評価し、適切なサポート部門に提出することでした。このケースは、私がこれまでに経験した唯一のPriorityOneケースでした。
カード会社の男性が電話をかけて、米国の東海岸と西海岸のメインフレーム間のリンクがダウンしていると述べました。アカウントが1つのメインフレームで作成された場合、トランザクションは常にそのメインフレームで処理されました。最も近いリンクが常にそのメインフレームの近くにある場合は、これで問題ありませんでした。しかし、この特定の日に、東海岸のサーバーにアカウントがあり、西海岸にいる場合、リンクがダウンしているため、トランザクションは拒否されます。
被害を評価する際の標準的な質問は、「これはあなたのビジネスにいくらかかりますか？」でした。落ち着いて集めた返事は「30秒ごとに約100万ドル」だった。
次回、30ドルのワイヤレスカードを使ってカスタマーサポートに怒鳴り、絶賛したいと思ったときに、それを実際にコンテキストに入れます。
（シスコは、転送されてから5分以内にリンクを起動して実行したことに注意してください）
間違いを避けるために、rmやmvなどのエイリアスコマンドに「-i」オプションを追加することは非常に一般的です。しかし、これは少し前に私の会社で起こりました。誰かがこの行をサーバーの1つにあるrootの.bashrcに入れました。
alias rm='rm -i'
次に、行をコピーして、mvの代わりにrmを使用します...またはそう彼は考えました：
alias rm='rm -i'
alias mv='rm -i'
残りは歴史です:)
さて、問題は、「移動」ではなく「削除」という質問が「確かに」を移動するときに、まだ...
大規模な小売店（1000以上の支店）に大規模なPOSシステムを設置していました。中央のポーリングサーバーはすべてカスタムHP-Unixコードであり、本番環境への移行のテストは、ITディレクターの息子である1人の男によって処理されました。
この男は、1日の7.95時間かけてファンタジー小説を読み、残りの数分間はバッチジョブを実行して、ナイトリービルドを本番環境に移行しました。このシステムは、150のブランチで稼働してから3日でした（最初の「実際の」ロールアウト）。すべてが設定され、私のチームはコードの最後の部分のテストを終えたところです。私たちは変更をコミットし、イメージを開発からテストに移して、翌朝ITディレクターの息子がピックアップできるようにしました。
私は午前8時にそこに着き、すべてが混乱しています。息子は、ファイルを本番環境にコピーした後、。/ changedフォルダーに移動して「rm-rf *」と入力するように指示されていたことが判明しました。はい、誰かが実際に彼にこれを言いました！もちろん、彼は誤って本番ルートドライブでこれを実行しました。このルートドライブには、トランザクションポーリングデータベースも格納されていました（当時、バックアップのためにオフラインでしたが、運が良かったです）。
結果：16のパイロットストアは、2日間、シガーボックスから（場合によっては文字通り）顧客にサービスを提供する必要がありました。 CIOの息子はサーバーウォッチャーに降格されました（彼は凍えるような冷たいサーバールームに座って、赤信号を監視することになっていた...しかし彼は何にも触れることを許されなかった...彼らは彼にコンピューターを与えず、彼のすべてのログイン/電子メールを取り消しました）。私たちの開発チームは、バックアップから失われたデータを再構築し、コードを再テスト/再送信するために一晩中引っ張りました。
幸運にも150ブランチのロールアウトを行いましたが、これは史上最悪のロールアウト体験でした。
Enterキーを押す前にすべてのコマンド文を終了することを学びました。
私が直面している少し似た状況は、コマンドについて確信が持てない場合です。ホームを押して、コマンドが認識されないようにいくつかのジャンク文字を入力します。
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
次に、必要に応じてゆっくりとオプションを再度確認します。他の誰かがそのようなことをしますか？もちろん、十分なジャンク文字（5+）を入力するようにしてください、それが別の有効なコマンドになり、予測できないダメージを与えるのを防ぐ必要があります。
（これには、私が理解していない基本的な欠陥がありますか、または5つ以上のジャンク文字が与えられた場合、通常は「asdfghjkl」キーで、予測できないことをしますか？）
マネージャーのためにラップトップのオペレーティングシステムを再インストールする際に、誰かがネットワークを介して/ tmp内のLinuxステーションにすべてのデータのコピーを作成しました。いくつか問題があり、1日以上かかりました。
... Linuxステーションは一日の終わりにシャットダウンされました...
翌日、マネージャーのデータを探しに行ったとき...
これが面白い答えになるかどうかはわかりませんが、私はコーダーでもあります。私は最後のWebサイトを完全に本番環境でコーディングし、PCにはバックアップをまったく作成しませんでした。 16時間の連続作業の後の悪い日、私はパーティションを空にする必要があり、それを行う最も速い方法はそれをフォーマットすることでした。実行しましたfdisk -lフォーマットする必要のあるパーティションの名前を確認しましたが、残念ながら間違った行を読み取ってフォーマットしました。
私は6ヶ月の仕事のように失った。
幸いなことに、同じことを2回目に行うと、その方法をすでに知っているので、より良く、より速く実行できます。これでウェブサイトが公開されました。そして私はバックアップを持っています：=）
私はSysAdminとして約7か月間働いていますが、最初のタスクの1つは、Squidプロキシサーバーを実行することでしたが、実際に機能しました。たとえば、2週間後、BackTrackを使用して、多くのツールをいじっていました。」 「ハッカーをプレイする」私は実際にサーバーをハッキングしましたが、それはちょっと良かったのですが、なんらかの奇妙な理由で侵入した後、/からrm -rfを実行し、OS（Debian linux）の一部をよく消去しました。
Enterキーを押す前に、すべてのコマンド文を終了することを学びました。
乾杯。
私のコロ施設には、しばらく前にダウンタイムがありました。
彼らはインターネットへのプライマリネットワークリンクを切断して、ルーターでソフトウェアメンテナンスを実行しました。
ただし、同時に、セカンダリリンクのアップストリームプロバイダーは、いくつかのテストを実行するためにそれをオフに切り替えました（明らかに、彼らは言われていましたが、データセンターで誤ったラベルが付けられていました）
これまでのところひどい...しかし、顧客はダウンタイムをプロバイダーの注意を引くために施設に行くのにいくらかの困難を抱えていました..プロバイダーはVoIP電話しか持っていませんでした。それは...まあ、あなたは推測できます。
私はあなたが私を信じないだろうと想像します、しかしそれは本当です、そして ブロゴスフィアの記録の問題 :)
私たちの顧客の1人が2005年12月24日にかなり珍しいXFSファイルシステムのバグに遭遇しました...それがもちろんLinuxカーネルのバグだとは知らなかった当時、私はそれが通常の容疑者のほんの一部だと思っていました（13TB RAID 8KBの空き容量、アレイ内のスプリアスドライブ障害など）。
最後に、ファイルシステムがマウントできないため、行のオペレーターにxfs_repair -n /dev/whateverを入力するように依頼しました。うーん、ログをクリアしたいのですが（FSはマウントできないので）、不吉なメッセージはありません。それで、xfs_repair /dev/whateverを探してください。
15分後、彼女はコールバックします：
ほとんどのファイルが表示されないのはなぜですか？
ホウオウ...怪我に侮辱を加えるために、xfsprogsはこの正確なケースで深刻な害を及ぼすいくつかのバージョンであったことが判明しました...痛い。 8TBのデータが実際に失われました。