パスワードを忘れた? アカウント作成
933643 story
IT

そのデータセンター、メンテナンスしすぎではありませんか? 44

ストーリー by nabeshin
掃除のおばちゃん 部門より
capra 曰く、

データセンターの予防的メンテナンスは、本当に「予防」に功を奏しているだろうか? ダウンタイムが生じる原因のトップは人的エラーと言われており、頻繁なメンテナンススケジュールを組むことはかえってデータセンターの信頼性を損ねる恐れがあると指摘する専門家もいる(Data Center Knowledge本家)。
MTechnologyの「サイエンス・リスク」コンサルタントだというSteve Fairfaxもその一人であり、「過度のメンテナンスがデータセンターの信頼性に対する最たる脅威である」と断言する。
テストを行うほどコンポーネントの信頼性が増すと考えられがちであるが、必ずしもそうではなく、ドキュメントの不完全なメンテナンスは自動化されたシステムとコンフリクトを引き起こす可能性もある。また、最近開催された7x24 Exchangeカンファレンスでは、データセンターオペレーターに対し担当施設の理解と把握に焦点を当て、ベンダーからの提案を含め真に必要なメンテナンスプログラムを評価すべきと強く促したとのことだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by iwakuralain (33086) on 2011年11月30日 12時23分 (#2058526)

    確かにドキュメントは大事ですね。
    分かっている人が、分かっている人向けに書いたドキュメントとか見るとうんざりすることも多いです。
    分かっている人しか見ないなら別にいいんですけど・・・。

    • by jud (15801) on 2011年11月30日 12時53分 (#2058549) 日記

      せっかくわかるようにとマニュアル書いても
      『[F5]キーを押下と書いてあるからFキーと5キーを同時に押下したがだめだった』とか
      『[Enter]と書いてあるので"Enter"と入力したけど反応がない』とか
      『サーバラックの鍵がない』
      『(スクリーンセーバー効いてて)モニタの電源を入れても何も表示されない』

      …という苦情まで開発メンバーまで回ってきたらうんざりすることも多いです。
      ま、メンテ要員がメンテする段になってこういう状態が発覚する組織そのものがヤバイ気もするけどw

      親コメント
      • by Anonymous Coward

        こういうの見てて思うんだけど、海外でもそんな素人要員がメンテするようなところってあるんですかね?
        日本は(ド素人メンテ要員が生き残る)ガラパゴスのひとつになってるんじゃないかという気がするんだけど。

        • by Anonymous Coward

          ありますよ。
          むしろ仕事を細分化する事で、スキルの低い人を安く雇えるので、積極的だと思います。
          特に監視業務は、そうですね。
          監視はあくまでも監視。異常を発見したら報告するのだけが仕事です。
          何かあった時のために問題分析要員とか別途います。たいていはそれで十分。
          センターから離れたところに派遣する要員は部品を交換する技能があれば十分で、その他の細々は遠隔でやります。
          まぁ、それだけの技能を持った人間をすら、揃えるのに苦労する訳なんですけど。

    • by shesee (27226) on 2011年11月30日 12時41分 (#2058540) 日記
      誰にも分かるようにドキュメントを書けといっても難しいんですけどね
      親コメント
      • by Anonymous Coward

        グッドウィルでもできるようにする必要があるのか #odstudy

        • by Anonymous Coward

          odstudy#02に参加した人が補足しますよ。

          odstudy#02のグループディスカッションでは、
          誰が読むためのドキュメントを作るべきなのか。という議論がありました。

           1.仲間内で情報共有するためのドキュメント
           2.技術力があまりない人に知識を共有させるためのドキュメント

          という二通りの側面から議論がありました。

          外出し(アウトソース)する場合は、あまり技術力のない人が読むドキュメントも必要だな。
          ということで、アウトソースで有名なところといえば「グッドウィル」
          システム運用を外出しする時、グッドウィルから派遣された素人さんでも判るような資料が必要だね。
          ということで、その名が出たのです。

    • by Anonymous Coward on 2011年11月30日 13時27分 (#2058579)

      ふむ、分かっている人が、分かっている人向けに書いたドキュメントは非常に分かり易いけどね。
      分かってない人が、分かってない人向けに書いたドキュメントは意味不明。

      親コメント
      • by Anonymous Coward

        対象物に関して良く分かっていて、分からない人がどのぐらい分からないかも分かっている人が丁寧に書いたドキュメント → くどいけどほとんどの人に分かりやすい

        対象物に関してよく分かっている人が、よく分かっている人向けに書いたドキュメント → よく分かっている人には最適。よく分かっていない人には理解できない。

        対象物に関してよく分かっていない人が書いたドキュメント → ゴミ。場合によっては変な誤解を誘発するんで無いよりも悪い結果をもたらす。

        • by Anonymous Coward

          2番目はよく分かってる人(勉強してる人)には「最適」なんだから、
          よく分かってない人(勉強してない人)がそれに文句を言うのはお門違い。
          勉強しないで1番目を要求する人に限って本人が書くのは3番だったりする。

    • by miww (14929) on 2011年11月30日 15時00分 (#2058645) 日記

      だが待って欲しい。

      それはもしかすると

      「分かっていない人は触るな」

      という警告を含んでいるのではないだろうか。

      親コメント
      • by Anonymous Coward

        その通り。

        故に、ドキュメントの対象読者を指定します。で、何かと試験を実施し、合格者は対象読者の仲間入り、などという運用をします。
        あぁ、これを全てのケースに適用できればどんなに楽か。
        私の環境では、部分適用までですが、まぁ、それなりにいい感じです。

    • by Anonymous Coward

      分かっている人になる努力はしたくないということですね。

    • 特にルールの無い雑な会社で、ドキュメント作って!と丸投げされて悩みつつ書いてたことがありますが、どこに基準を置くかは難しいです。

      「ほんとーに何も分からない人」を想定すると、それこそ操作方法やコマンドを一言一句書かないといけないんでしょうが、そうするとOSやらブラウザやらをバージョンアップしただけで理解できなくなってしまいかねません。
      ちゃんと改版されるなら別にいいんですが、そういう会社では基本放置されがちなので、メンテは期待できません。

      分かってる人に読ませる前提なら、例えばFTPサーバーの情報はこれですんで、FTPで接続してください、と

      • by Anonymous Coward on 2011年11月30日 13時17分 (#2058571)

        作業を任せる対象の想定は本当に難しいですね。

        以前、

        ・A、Bの2台のサーバの両方で
        ・X、Yの2つの処理を実行する

        と書いた手順書を渡したら、AでXのみを、BでYのみを実行されてトラブった経験があります。
        実行担当者(UNIXサーバでroot権限での管理経験(年単位)がある)に確認したところ、
        「AとB」「XとY」と目に入ったので1対1の作業だと勘違いした、とのことで、最終的には

        ・AでXとYを実行する
        ・BでXとYを実行する

        と書かなかった私が悪い、という結論に落ち着きました。

        それ以降、どんな簡単なドキュメントでも、それを扱う可能性のある全員との読み合わせを
        必ず行い、こちらの意図を説明するようにしています。えらく大変ですけど、トラブるよりは
        マシと考えています。

        # 実体験なのでさすがにACで

        親コメント
      • by Anonymous Coward
        > FTPで接続してください、と書いておけば済みます。
        > 読む側としても、自分の使い慣れたFTPクライアントなりでやれば良くて、面倒がありません。
        最悪です。
        世の中にあるすべてのFTPクライアントがRFCの機能をすべて網羅していてバグがなければそれでいいのかもしれませんが、んなわけないので、あなたのドキュメントはあなたの仮定した(そして操作者は知らない)FTPクライアントを前提とした使えないドキュメントにしかなりません。
        きちんと動作検証したFTPクライアントについて逐一操作を記述するか、最悪Windows標準のFTP.exeコマンドに投入するコマンドをベタ書きするかしてください。
        • by Anonymous Coward

          URIとID、パスワードがあれば、トレーニングを受けたあるべき知識のある人なら接続できるんじゃないの?

          知識のないエンドユーザー相手ならわかるけど・・・。
          それとも、コの業界って、トレーニングもなしに保守の現場に放り込まれるの??

          • by Anonymous Coward

            同意。SFTPやあれやこれ細かい設定が必要な環境ならまだしも、FTPを普通に使うだけで、いちいち細かいことまで教えられないと駄目ってどうかと思う。

            例えば、ありがちな文字化けとかのトラブルだって、このサーバーの文字コードはEUC-JPです、とだけ伝えれば本来十分なはずでしょ?
            いちいちマニュアルに、FFFTPの使い方から、文字化けしないようにここはこのコンボボックスからEUC-JPを選んでください、程度まで書かなきゃいけないの?
            プロバイダーが会員に説明するようなマニュアルならともかく、データセンターやらでシステムの保守管理に使うようなマニュアルの話なのに?

            そんなレベルの素人を送り込むな、教育してからにしろ、新たに雇うならそんな奴雇うなと声を大にして言いたい。
            コストかけたくない?そんな会社、大きなトラブルでも起こして倒産しちまえ!

            • by Anonymous Coward
              FTPを普通に?
              マジありえません。というかFTPなんて前世紀に捨ててくるべきウンコです。ftp.exeでさえロクにRFCに従ってないバグ満載アプリなんですが、時間の限られたメンテ時にいちいちMSDN引いて障害の切り分けさせるんですか?それを通り一片の教育しかしてないオペレータに要求する?まさに正気を疑うとしか。
              • by Anonymous Coward

                それを通り一片の教育しかしてないオペレータに要求する?まさに正気を疑うとしか。

                そもそも、そんな人を配置することこそが、まさに正気を疑う行為だとしか言えませんね。
                ど素人を集めてなんとか出来るほど保守は甘くないですよ。

        • by Anonymous Coward

          逆だと思いますね
          あまり具体的なことを書きすぎるとあとで面倒なことが起きます
          指定ツールが公開止めたりしたら困るでしょう
          できるだけ抽象的に汎用性があったほうが良いですよ
          ぎちぎちに書いたドキュメントなどはちょっと手順が変更になっただけで使い物にならなくなるというのが良くあります

  • by alternative (23238) on 2011年11月30日 13時32分 (#2058582)

    http://www.atmarkit.co.jp/im/cits/serial/dilbert/229/01.html [atmarkit.co.jp]
    これを思い出したのです

  • 普段から触ってないといきなりハードモードなんてクリアできません
  • by Anonymous Coward on 2011年11月30日 12時11分 (#2058518)

    自動化されたシステムに任せ切りだと不安だからたまには操縦桿を握らないとな
    とか機長が言い出したらどうしますか?

  • by Anonymous Coward on 2011年11月30日 12時14分 (#2058519)

    人的+エスカレートするコストダウン

    一番多い原因でしょ。

    • by Anonymous Coward

      確かに。
      派遣する人のレベルにより価格を複数提示しても、
      大概は一番安い価格の人が選ばれるし。

      • by Anonymous Coward

        ある商品を並べる場合にB1つだけだと売れない場合、商品をA、B、Cと3種類用意して、
        Bの価格を売りたい物の価格をA〜Cの3つのうちの真ん中に来るように設定すると売れるという話を
        聞いたことがあります。

        買うほうは理解してて買うわけではないでしょうから、もしいつも一番下のが売れるとしたら、上に2つ高いものを作って
        一番下にオススメのレベルのものを載せて提示するってのはどうなんでしょうね。

        • by Anonymous Coward

          単に買う側は品質(この場合スキルですね)のことなんか考えずに、人月単価だけでスキルは不足してるけど安い人間を選ぶ、ってことじゃない?
          そしてトラブルが起きる・・・・・・・と。

        • by Anonymous Coward

          別の方の回答が全てを語ってくれています。 (#2058728)
          監視案件なんかだと「@30万で○○人集めてくれ。」なんてのもあります。
          よぽーどひどい人でなければ概ねokなんですが。イレギュラーな事態が発生
          すると何もできない。

  • by Anonymous Coward on 2011年11月30日 12時20分 (#2058523)

    理由のわからないトラブルを恐れるあまり、理由のわかるトラブルを軽視する。
    責任の発生を恐れるあまり、転嫁先のあるトラブルを軽視する。

  • by Anonymous Coward on 2011年11月30日 12時50分 (#2058547)

    デフラグをかけすぎてHDDを壊したなんて噂を思い出した。

    # この噂って本当なのだろうか?

    • by miww (14929) on 2011年11月30日 15時18分 (#2058662) 日記

      「HDDが壊れる」可能性には、ハードウェア故障以外にも、
      記録内容の論理構造がエラー等で破綻することで、
      正常に読み出せなくなるというものがあります。

      デフラグはこの論理構造を整理する動作であるため、
      論理構造の破綻が発生しているところに処理を行うと、
      正常に読み出せない状態になる可能性が通常の
      アクセスよりも高い操作となります。

      デフラグしていなければ1ファイル/フォルダの破損で
      済んでいた障害を、デフラグしたせいで致命的な
      状態にしてしまうことは実際にあります。

      あと、単純にデフラグは通常使用よりもアクセス量が
      多い動作であるため、毎日デフラグするような人だと、
      下手すると1日のアクセス量の9割以上がデフラグに
      よるものとなります。

      その状況下でHDDが壊れたとなれば、9割方デフラグの
      せいだと判定されてもおかしくないと思われます。

      親コメント
      • by wolf03 (39616) on 2011年11月30日 22時32分 (#2058895) 日記
        今のところ空き領域の所に表面がささくれていると、デフラグでそこをヘッドが通過し破損。
        そのヘッドが次々と表面破壊をとなる事も。
        一回やらかしましたよ。
        親コメント
  • by Anonymous Coward on 2011年11月30日 13時43分 (#2058588)
    確かに過度のメンテが障害を生む、ってのはわかりますが、メンテする必要性がわかってたのにやりませんでした、ってのが日本では一番叩かれる気がする。
    それよりは、障害を未然に防ぐためのメンテをやったけど、失敗して障害起こしましたのほうが救いがある。
    • メンテしたことがこれまで全くないから、パッチの適用レベルでもわかる人を探すのに一苦労なんてこともありますからね。ときどきは計画メンテナンスをやって自分たちの持っている手順が有効だということを確認しておくべき。
      --
      人生は七転び八起き、一日は早寝早起き
      親コメント
    • by saitoh (10803) on 2011年12月01日 15時23分 (#2059375)
      ハードウェアメンテだと非常に話が理解できるんですけどね。

      今はあまりやりませんが、1980年代までは、年に1~2回メーカーのCEが来て全部の基板をスロットから抜いて溜まった埃を吹き飛ばしてまた組み立て直す、なんて作業が保守契約の一環として行われていました。ハードウェアの欠陥が見つかっていた場合は、リビジョンアップも同時に行われます。
      ただ、組み立てをミスって動かないとかのトラブルが起きることもあり。年に1~2回で十分で、毎月やるのはやり過ぎ。

      親コメント
  • by Anonymous Coward on 2011年11月30日 16時17分 (#2058694)
  • by Anonymous Coward on 2011年11月30日 18時55分 (#2058774)

    # こういうのを見てにわかな経営者や素人が「動いてるものはつつくな」的考えになられても困るんだよねえ...

    危ういバランスで動いてるものとか、今後outdatedで更新の障害になりそうなコードとか、エラーチェックやデフラグの頻度とか適切にモニターして設定してやるのが管理者ってものじゃなかろうか。
    要はシステムの面倒を見ているわけで、過保護にならず放置もし過ぎず子供のようにかわいがるだけですよ。

typodupeerror

アレゲは一日にしてならず -- アレゲ見習い

読み込み中...