そのデータセンター、メンテナンスしすぎではありませんか? 44
ストーリー by nabeshin
掃除のおばちゃん 部門より
掃除のおばちゃん 部門より
capra 曰く、
データセンターの予防的メンテナンスは、本当に「予防」に功を奏しているだろうか? ダウンタイムが生じる原因のトップは人的エラーと言われており、頻繁なメンテナンススケジュールを組むことはかえってデータセンターの信頼性を損ねる恐れがあると指摘する専門家もいる(Data Center Knowledge、本家)。
MTechnologyの「サイエンス・リスク」コンサルタントだというSteve Fairfaxもその一人であり、「過度のメンテナンスがデータセンターの信頼性に対する最たる脅威である」と断言する。
テストを行うほどコンポーネントの信頼性が増すと考えられがちであるが、必ずしもそうではなく、ドキュメントの不完全なメンテナンスは自動化されたシステムとコンフリクトを引き起こす可能性もある。また、最近開催された7x24 Exchangeカンファレンスでは、データセンターオペレーターに対し担当施設の理解と把握に焦点を当て、ベンダーからの提案を含め真に必要なメンテナンスプログラムを評価すべきと強く促したとのことだ。
複雑化 (スコア:2)
確かにドキュメントは大事ですね。
分かっている人が、分かっている人向けに書いたドキュメントとか見るとうんざりすることも多いです。
分かっている人しか見ないなら別にいいんですけど・・・。
Re:複雑化 (スコア:2)
せっかくわかるようにとマニュアル書いても
『[F5]キーを押下と書いてあるからFキーと5キーを同時に押下したがだめだった』とか
『[Enter]と書いてあるので"Enter"と入力したけど反応がない』とか
『サーバラックの鍵がない』
『(スクリーンセーバー効いてて)モニタの電源を入れても何も表示されない』
…という苦情まで開発メンバーまで回ってきたらうんざりすることも多いです。
ま、メンテ要員がメンテする段になってこういう状態が発覚する組織そのものがヤバイ気もするけどw
Re: (スコア:0)
こういうの見てて思うんだけど、海外でもそんな素人要員がメンテするようなところってあるんですかね?
日本は(ド素人メンテ要員が生き残る)ガラパゴスのひとつになってるんじゃないかという気がするんだけど。
Re: (スコア:0)
ありますよ。
むしろ仕事を細分化する事で、スキルの低い人を安く雇えるので、積極的だと思います。
特に監視業務は、そうですね。
監視はあくまでも監視。異常を発見したら報告するのだけが仕事です。
何かあった時のために問題分析要員とか別途います。たいていはそれで十分。
センターから離れたところに派遣する要員は部品を交換する技能があれば十分で、その他の細々は遠隔でやります。
まぁ、それだけの技能を持った人間をすら、揃えるのに苦労する訳なんですけど。
Re:複雑化 (スコア:1)
Re: (スコア:0)
グッドウィルでもできるようにする必要があるのか #odstudy
Re: (スコア:0)
odstudy#02に参加した人が補足しますよ。
odstudy#02のグループディスカッションでは、
誰が読むためのドキュメントを作るべきなのか。という議論がありました。
1.仲間内で情報共有するためのドキュメント
2.技術力があまりない人に知識を共有させるためのドキュメント
という二通りの側面から議論がありました。
外出し(アウトソース)する場合は、あまり技術力のない人が読むドキュメントも必要だな。
ということで、アウトソースで有名なところといえば「グッドウィル」
システム運用を外出しする時、グッドウィルから派遣された素人さんでも判るような資料が必要だね。
ということで、その名が出たのです。
Re:複雑化 (スコア:1)
ふむ、分かっている人が、分かっている人向けに書いたドキュメントは非常に分かり易いけどね。
分かってない人が、分かってない人向けに書いたドキュメントは意味不明。
Re: (スコア:0)
対象物に関して良く分かっていて、分からない人がどのぐらい分からないかも分かっている人が丁寧に書いたドキュメント → くどいけどほとんどの人に分かりやすい
対象物に関してよく分かっている人が、よく分かっている人向けに書いたドキュメント → よく分かっている人には最適。よく分かっていない人には理解できない。
対象物に関してよく分かっていない人が書いたドキュメント → ゴミ。場合によっては変な誤解を誘発するんで無いよりも悪い結果をもたらす。
Re: (スコア:0)
2番目はよく分かってる人(勉強してる人)には「最適」なんだから、
よく分かってない人(勉強してない人)がそれに文句を言うのはお門違い。
勉強しないで1番目を要求する人に限って本人が書くのは3番だったりする。
Re:複雑化 (スコア:1)
だが待って欲しい。
それはもしかすると
「分かっていない人は触るな」
という警告を含んでいるのではないだろうか。
Re: (スコア:0)
その通り。
故に、ドキュメントの対象読者を指定します。で、何かと試験を実施し、合格者は対象読者の仲間入り、などという運用をします。
あぁ、これを全てのケースに適用できればどんなに楽か。
私の環境では、部分適用までですが、まぁ、それなりにいい感じです。
Re: (スコア:0)
分かっている人になる努力はしたくないということですね。
Re:複雑化 (スコア:2)
なるほど
そういう考えもあるけど、緊急時に常に全てがわかっている人だけがいるわけじゃないからね~。
難しいところです。
分からない人向けドキュメントは難しい (スコア:0)
特にルールの無い雑な会社で、ドキュメント作って!と丸投げされて悩みつつ書いてたことがありますが、どこに基準を置くかは難しいです。
「ほんとーに何も分からない人」を想定すると、それこそ操作方法やコマンドを一言一句書かないといけないんでしょうが、そうするとOSやらブラウザやらをバージョンアップしただけで理解できなくなってしまいかねません。
ちゃんと改版されるなら別にいいんですが、そういう会社では基本放置されがちなので、メンテは期待できません。
分かってる人に読ませる前提なら、例えばFTPサーバーの情報はこれですんで、FTPで接続してください、と
Re:分からない人向けドキュメントは難しい (スコア:1)
作業を任せる対象の想定は本当に難しいですね。
以前、
・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で
Re: (スコア:0)
> 読む側としても、自分の使い慣れたFTPクライアントなりでやれば良くて、面倒がありません。
最悪です。
世の中にあるすべてのFTPクライアントがRFCの機能をすべて網羅していてバグがなければそれでいいのかもしれませんが、んなわけないので、あなたのドキュメントはあなたの仮定した(そして操作者は知らない)FTPクライアントを前提とした使えないドキュメントにしかなりません。
きちんと動作検証したFTPクライアントについて逐一操作を記述するか、最悪Windows標準のFTP.exeコマンドに投入するコマンドをベタ書きするかしてください。
Re: (スコア:0)
URIとID、パスワードがあれば、トレーニングを受けたあるべき知識のある人なら接続できるんじゃないの?
知識のないエンドユーザー相手ならわかるけど・・・。
それとも、コの業界って、トレーニングもなしに保守の現場に放り込まれるの??
Re: (スコア:0)
同意。SFTPやあれやこれ細かい設定が必要な環境ならまだしも、FTPを普通に使うだけで、いちいち細かいことまで教えられないと駄目ってどうかと思う。
例えば、ありがちな文字化けとかのトラブルだって、このサーバーの文字コードはEUC-JPです、とだけ伝えれば本来十分なはずでしょ?
いちいちマニュアルに、FFFTPの使い方から、文字化けしないようにここはこのコンボボックスからEUC-JPを選んでください、程度まで書かなきゃいけないの?
プロバイダーが会員に説明するようなマニュアルならともかく、データセンターやらでシステムの保守管理に使うようなマニュアルの話なのに?
そんなレベルの素人を送り込むな、教育してからにしろ、新たに雇うならそんな奴雇うなと声を大にして言いたい。
コストかけたくない?そんな会社、大きなトラブルでも起こして倒産しちまえ!
Re: (スコア:0)
マジありえません。というかFTPなんて前世紀に捨ててくるべきウンコです。ftp.exeでさえロクにRFCに従ってないバグ満載アプリなんですが、時間の限られたメンテ時にいちいちMSDN引いて障害の切り分けさせるんですか?それを通り一片の教育しかしてないオペレータに要求する?まさに正気を疑うとしか。
Re: (スコア:0)
それを通り一片の教育しかしてないオペレータに要求する?まさに正気を疑うとしか。
そもそも、そんな人を配置することこそが、まさに正気を疑う行為だとしか言えませんね。
ど素人を集めてなんとか出来るほど保守は甘くないですよ。
Re: (スコア:0)
逆だと思いますね
あまり具体的なことを書きすぎるとあとで面倒なことが起きます
指定ツールが公開止めたりしたら困るでしょう
できるだけ抽象的に汎用性があったほうが良いですよ
ぎちぎちに書いたドキュメントなどはちょっと手順が変更になっただけで使い物にならなくなるというのが良くあります
なんか (スコア:1)
http://www.atmarkit.co.jp/im/cits/serial/dilbert/229/01.html [atmarkit.co.jp]
これを思い出したのです
頻繁なメンテナンスはトレーニングですよ (スコア:1)
飛行機の場合 (スコア:0)
自動化されたシステムに任せ切りだと不安だからたまには操縦桿を握らないとな
とか機長が言い出したらどうしますか?
Re:飛行機の場合 (スコア:1)
ドアの開け閉めすら間違えるのだから、副操縦士の操縦桿を握ってしまうかもしれないな。
Re:飛行機の場合 (スコア:3)
Re: (スコア:0)
Re: (スコア:0)
常に晴天で、カテゴリーIIIのILSの整備された空港ばかり往来するわけじゃあるまいし、
離着陸の時だの、積乱雲通過時には機長が操縦するでしょうよ。
とマジレス
そのとおり! (スコア:0)
人的+エスカレートするコストダウン
一番多い原因でしょ。
Re: (スコア:0)
確かに。
派遣する人のレベルにより価格を複数提示しても、
大概は一番安い価格の人が選ばれるし。
Re: (スコア:0)
ある商品を並べる場合にB1つだけだと売れない場合、商品をA、B、Cと3種類用意して、
Bの価格を売りたい物の価格をA〜Cの3つのうちの真ん中に来るように設定すると売れるという話を
聞いたことがあります。
買うほうは理解してて買うわけではないでしょうから、もしいつも一番下のが売れるとしたら、上に2つ高いものを作って
一番下にオススメのレベルのものを載せて提示するってのはどうなんでしょうね。
Re: (スコア:0)
単に買う側は品質(この場合スキルですね)のことなんか考えずに、人月単価だけでスキルは不足してるけど安い人間を選ぶ、ってことじゃない?
そしてトラブルが起きる・・・・・・・と。
Re: (スコア:0)
別の方の回答が全てを語ってくれています。 (#2058728)
監視案件なんかだと「@30万で○○人集めてくれ。」なんてのもあります。
よぽーどひどい人でなければ概ねokなんですが。イレギュラーな事態が発生
すると何もできない。
恐怖能もしくは責任脳 (スコア:0)
理由のわからないトラブルを恐れるあまり、理由のわかるトラブルを軽視する。
責任の発生を恐れるあまり、転嫁先のあるトラブルを軽視する。
デフラグ (スコア:0)
デフラグをかけすぎてHDDを壊したなんて噂を思い出した。
# この噂って本当なのだろうか?
Re:デフラグ (スコア:1)
「HDDが壊れる」可能性には、ハードウェア故障以外にも、
記録内容の論理構造がエラー等で破綻することで、
正常に読み出せなくなるというものがあります。
デフラグはこの論理構造を整理する動作であるため、
論理構造の破綻が発生しているところに処理を行うと、
正常に読み出せない状態になる可能性が通常の
アクセスよりも高い操作となります。
デフラグしていなければ1ファイル/フォルダの破損で
済んでいた障害を、デフラグしたせいで致命的な
状態にしてしまうことは実際にあります。
あと、単純にデフラグは通常使用よりもアクセス量が
多い動作であるため、毎日デフラグするような人だと、
下手すると1日のアクセス量の9割以上がデフラグに
よるものとなります。
その状況下でHDDが壊れたとなれば、9割方デフラグの
せいだと判定されてもおかしくないと思われます。
Re:デフラグ (スコア:1)
そのヘッドが次々と表面破壊をとなる事も。
一回やらかしましたよ。
それでもメンテは大事 (スコア:0)
それよりは、障害を未然に防ぐためのメンテをやったけど、失敗して障害起こしましたのほうが救いがある。
Re:それでもメンテは大事 (スコア:2)
人生は七転び八起き、一日は早寝早起き
Re:それでもメンテは大事 (スコア:1)
ここらへんが落し所ですかねぇ。
結局どういう運用でリスクマネジメントするのか、が不透明だったり適当なのがよくないので。
# 本当に大切ならバックアップの復元確認にテスト機とかあっていいはずだし、パッチ検証環境とかも...
適切に技術や手順の確認できるかどうかも運用の範疇だとおもいますし。
M-FalconSky (暑いか寒い)
Re:それでもメンテは大事 (スコア:2)
今はあまりやりませんが、1980年代までは、年に1~2回メーカーのCEが来て全部の基板をスロットから抜いて溜まった埃を吹き飛ばしてまた組み立て直す、なんて作業が保守契約の一環として行われていました。ハードウェアの欠陥が見つかっていた場合は、リビジョンアップも同時に行われます。
ただ、組み立てをミスって動かないとかのトラブルが起きることもあり。年に1~2回で十分で、毎月やるのはやり過ぎ。
関連リンク? (スコア:0)
てっきりMMORPG「M2」、サーバーの不具合修正に失敗して突然サービス終了 [srad.jp]のことかと
おわしますがごとくに (スコア:0)
# こういうのを見てにわかな経営者や素人が「動いてるものはつつくな」的考えになられても困るんだよねえ...
危ういバランスで動いてるものとか、今後outdatedで更新の障害になりそうなコードとか、エラーチェックやデフラグの頻度とか適切にモニターして設定してやるのが管理者ってものじゃなかろうか。
要はシステムの面倒を見ているわけで、過保護にならず放置もし過ぎず子供のようにかわいがるだけですよ。