アカウント名:
パスワード:
まさか、あそこのHDDだったんじゃ…。
あそこのHDDだとしても、今だととっくに交換済みでしょう。
しかもメインとバックアップの同時故障ってどういうことだと。さらにテープなどを使ったリモートバックアップも考慮すると、復旧できないし見通しも立たないというのはあり得ないと思うんだが。
＃技術力があればの話なので、技術のない会社ならありうる話。
>＃技術力があればの話なので、技術のない会社ならありうる話。
いえいえ、技術力があると表面的に思われている弊社でも、開発から初期運用時はそこそこの技術者が関わっていますが、下手に安定してしまうと他所に回されて、手順書の整備もされず、コマンドの訳もわからず叩く良く訓練されたサルが運用します。
ですから、技術力ある会社が作って安定してしまうシステムほど、いざと言う時にもろかったりするのでは無いかと察します。特に、ミッションクリティカルと程遠いブログシステム等尚更。マイクロソフトの「答えてねっとの件」 [srad.jp]もそういう感じだと思います。
問題は、それがその会社の裁量でコントロール出来るかどうかですよ。
安定運用に入った途端に「君らコスト高いから別の会社にするね、運用手順書だけくれれば良いから」なんて言われて切られた場合はどうします？
技術力の高い会社は、きちんとした運用手順書を用意してるでしょうね。技術力のある人向きの。しかし、それをサルに渡して同じ運用が出来ますかね？
>>>下手に安定してしまうと他所に回されて、手順書の整備もされず、
>>技術力のある会社はそんなことしない。
>そーかな。サルでもわかるマニュアル作るのは難しいと思うよ。>とくに障害が発生したときのヤツは。
元ＡＣですが、まさにそういうことですね。PJロールアウト直後は、それなりに整った手順書があるわけですが、サルが配置されると手順書のほかに必要な知識を使わず運用するので、「調子が悪い時は再起動だな」と、調査もせずにやらかすわけです。
そして二度と起動しなくなるとか、もうね。データセンターへタクシーで直行程度で済めばいいですが…（実際、私の知る範囲では今のところ、それで済んでいるようです）そうでなかった時のビジネス停止リスクが甘く見積もられているものだと、いっつもナアナアで処理されてしまう、運が悪かったね、と。責任追及はしないでいいから原因究明と対策をとろうよ…。
かといって、「UNIX入門」まで含めた詳細に記述したものを書くならそれなりに予算とか教育とか担保が必要だけど、そうはいかない。内部的ドキュメンテーションの必要さを解ってるベンダーなんて、一体どれくらいるでしょうかね。で、ミドルウェア一つとっても分厚いマニュアルが存在するケースがあったとして、それをどんな時にどこを見ればいいか解ってる人物を置いているのかっていう。
電子ベースで納品されて、索引と検索がしっかりしていればいいんだけど、そうなると既に一つのシステム構築費になってくるし・・・。
で、なんでそんな会社でも技術あると言われるかっていうと、顧客に見えるところを「安く」それなりに「安定して」作れるし親方日の丸的系列の力で我侭も聞いてくれて「安心」するからですね。要するに、発注した個人にとって傷がつくような仕事をしないオープンまで漕ぎ着ける「信頼」があるからです。つまり実は技術力より営業力に寄る所が大きいということ。
127(略)氏の「運用フェイズ」の信頼まで勝ち得ようとするベンダーは、現実の範囲で誠実に仕事を遂行してくれますが、発注者もシステムに関心を持ってくれるマニアックな担当者が居ないと理解してもらえません。運用フェイズにかかるコスト、技術力の蓄積に関心があるベンダーが普通なら、団塊世代の退職で慌てることなんかない訳ですよ。しかも、俗人化したおかげで団塊世代は未だに嘱託として働けてる訳ですからね。少なくとも日本の名だたるベンダーにおいては、隠匿こそ正義という文化が根付いていることは、127(略)氏の理想とは裏腹に、今そこにある現実なんですよね。
＃あーあ、冗談というか、茶化しで終わるつもりだったけど愚痴ってしまった
だから、技術力がある会社なら、サルは安定後の運用にも配置しないんだろう。
一人ぐらい現場に居ると、マニュアルの大切さがよく判りますえぇはじめてみた時はある意味カルチャーショックでしたよ
あれを基準にマニュアル作らないとダメなのかと愕然と(苦笑)
サル呼ばわりはないでしょう、いくらなんでも。表現が不快。
いちいち自分が不快だと言う事を表明するあなたが不快。
でも、なぜ不快になるかが興味ある。・自分が言われた側である(サル)・知り合いがサル・I love monkey!・祖先がサルだった
あとなんだろうなぁ・・・
対象がどういう人間だとして、見下したような呼称・表現をすることに強い不快感を表明することに、わたしは何ら恥じることはありません。ただし、逆に不快感を示されるのも結構です。見る角度が違えば違うとらえ方は生まれるものでしょうし。ただし、私の目からは、くだらない優越感を誇っているようにしか見えません。
・サルにサル呼ばわりされたから
手順書がないと何もできない人間をサル呼ばわりするのはサルに失礼?
でも、手順書どおりにやってくれる人間を頼んだつもりで手順書渡しても、手順書を無視してあれやこれややってくれるので、そういう人はサル以下だと思います。
> 下手に安定してしまうと他所に回されて、手順書の整備もされず、> コマンドの訳もわからず叩く良く訓練されたサルが運用します。
某衛星システムの運用にかかわっているんですけど、今まさにこの状態です。ウチだけじゃなかったんだと妙に関心しました。
絶対にAC
あそこって言うと韓国の★★★(←伏せ字)ですよね(違)
バッファローのRaid5外付けeSATAディスクに使われていたのですが、買ってから１年以内に壊れました。どうも壊れ方が微妙だったらしく、RAID5全体が使用不能になりかけて焦りました。結局１台ずつケーブル抜きで立ち上げて、故障していたユニットを外したところで縮退モードで立ち上がりました。緊急なので最近話題の方のあそこのBarracuda ES2を買ってきて、駄目ファームウェアを最新に書き換えて繋いだらゃんと動きました。念のためにエージングしてるから高信頼性との触れ込みの純正品を発注したら、WDのドライブでした。
・・・結構なんでもいいんだ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
ま、まさか (スコア:1, おもしろおかしい)
まさか、あそこのHDDだったんじゃ…。
Re: (スコア:0)
あそこのHDDだとしても、今だととっくに交換済みでしょう。
しかもメインとバックアップの同時故障ってどういうことだと。
さらにテープなどを使ったリモートバックアップも考慮すると、
復旧できないし見通しも立たないというのはあり得ないと思うんだが。
＃技術力があればの話なので、技術のない会社ならありうる話。
Re:ま、まさか (スコア:4, 参考になる)
>＃技術力があればの話なので、技術のない会社ならありうる話。
いえいえ、技術力があると表面的に思われている弊社でも、
開発から初期運用時はそこそこの技術者が関わっていますが、
下手に安定してしまうと他所に回されて、手順書の整備もされず、
コマンドの訳もわからず叩く良く訓練されたサルが運用します。
ですから、技術力ある会社が作って安定してしまうシステムほど、
いざと言う時にもろかったりするのでは無いかと察します。
特に、ミッションクリティカルと程遠いブログシステム等尚更。
マイクロソフトの「答えてねっとの件」 [srad.jp]もそういう感じだと思います。
Re:ま、まさか (スコア:5, すばらしい洞察)
技術力のある会社はそんなことしない。
>ですから、技術力ある会社が作って安定してしまうシステムほど、
>いざと言う時にもろかったりするのでは無いかと察します。
だからこれはない。
とだけ言うとフレームの元になりかねないので説明。
何をもって「技術力がある」と言うかの問題で、コーディングして
動かすところまではできるので「技術力があると表面的に思われている」
というような会社もあれば、運用面のことまできちんと整備する
会社もある、ってところでしょうが。
Re:ま、まさか (スコア:1, 興味深い)
問題は、それがその会社の裁量でコントロール出来るかどうかですよ。
安定運用に入った途端に「君らコスト高いから別の会社にするね、運用手順書だけくれれば良いから」
なんて言われて切られた場合はどうします？
技術力の高い会社は、きちんとした運用手順書を用意してるでしょうね。技術力のある人向きの。
しかし、それをサルに渡して同じ運用が出来ますかね？
Re:ま、まさか (スコア:2)
顧客に対して自分達が運用することのメリットをうまく説明したり納得させられないという
アピール力? プレゼン力? コミュニケーション力の不足ということが言えますし、
まともな話が通用しないレベルの顧客なら、そもそも最初にそういう顧客を捕まえてしまった
or拒否できない営業力・政治力の不足、バカな顧客を捕まえてしまった運のなさ、などが
あげられますね。
Re: (スコア:0)
> なんて言われて切られた場合はどうします？
御社向けに運用手順書を作成するには工数をいただかないとなりません。
また、しかるべき引き継ぎにも工数をいただかないとなりません。
工数なしなら、運用手順書なし、引き継ぎなしとなります。
これでOK。
Re: (スコア:0)
>技術力のある会社はそんなことしない。
そーかな。サルでもわかるマニュアル作るのは難しいと思うよ。
とくに障害が発生したときのヤツは。
Re:ま、まさか (スコア:3, 興味深い)
>>>下手に安定してしまうと他所に回されて、手順書の整備もされず、
>>技術力のある会社はそんなことしない。
>そーかな。サルでもわかるマニュアル作るのは難しいと思うよ。
>とくに障害が発生したときのヤツは。
元ＡＣですが、まさにそういうことですね。
PJロールアウト直後は、それなりに整った手順書があるわけですが、
サルが配置されると手順書のほかに必要な知識を使わず運用するので、
「調子が悪い時は再起動だな」と、調査もせずにやらかすわけです。
そして二度と起動しなくなるとか、もうね。
データセンターへタクシーで直行程度で済めばいいですが…
（実際、私の知る範囲では今のところ、それで済んでいるようです）
そうでなかった時のビジネス停止リスクが甘く見積もられているものだと、
いっつもナアナアで処理されてしまう、運が悪かったね、と。
責任追及はしないでいいから原因究明と対策をとろうよ…。
かといって、「UNIX入門」まで含めた詳細に記述したものを書くなら
それなりに予算とか教育とか担保が必要だけど、そうはいかない。
内部的ドキュメンテーションの必要さを解ってるベンダーなんて、
一体どれくらいるでしょうかね。
で、ミドルウェア一つとっても分厚いマニュアルが存在するケースが
あったとして、それをどんな時にどこを見ればいいか解ってる人物を
置いているのかっていう。
電子ベースで納品されて、索引と検索がしっかりしていればいいんだけど、
そうなると既に一つのシステム構築費になってくるし・・・。
で、なんでそんな会社でも技術あると言われるかっていうと、
顧客に見えるところを「安く」それなりに「安定して」作れるし
親方日の丸的系列の力で我侭も聞いてくれて「安心」するからですね。
要するに、発注した個人にとって傷がつくような仕事をしない
オープンまで漕ぎ着ける「信頼」があるからです。
つまり実は技術力より営業力に寄る所が大きいということ。
127(略)氏の「運用フェイズ」の信頼まで勝ち得ようとするベンダーは、
現実の範囲で誠実に仕事を遂行してくれますが、発注者もシステムに
関心を持ってくれるマニアックな担当者が居ないと理解してもらえません。
運用フェイズにかかるコスト、技術力の蓄積に関心があるベンダーが普通なら、
団塊世代の退職で慌てることなんかない訳ですよ。
しかも、俗人化したおかげで団塊世代は未だに嘱託として働けてる訳ですからね。
少なくとも日本の名だたるベンダーにおいては、隠匿こそ正義という文化が根付いていることは、
127(略)氏の理想とは裏腹に、今そこにある現実なんですよね。
＃あーあ、冗談というか、茶化しで終わるつもりだったけど愚痴ってしまった
Re:ま、まさか (スコア:1)
こっちが想定してる「最悪」が、実は一番easyな復旧だったりもする訳で。
# 全部壊した状態からスクリーンショットに赤丸付きで手順書作った所で
# それが運用してる人にとって分かりやすいものだとは限らず。
# 何のためのレビューなんだか。
Re: (スコア:0)
だから、技術力がある会社なら、
サルは安定後の運用にも配置しないんだろう。
Re: (スコア:0)
いくら技術力が高いスタッフが揃っていても効率的に運用できなければ
意味もあんまり無いし、そもそも技術力がある会社といっても
本当に技術力がある会社のパターンと、それまでにトラブルが表面化
しなかっただけってこともあるわけで・・・
以下チラシの裏
現実は適材適所の人事なんて殆ど無いよね・・。有能な人は引く手数多だから
すぐどこかにいっちゃう、後任は「それなりに」有能な人がつけばラッキー
でも現実は・・・
Re:ま、まさか (スコア:1)
一人ぐらい現場に居ると、マニュアルの大切さがよく判ります
えぇはじめてみた時はある意味カルチャーショックでしたよ
あれを基準にマニュアル作らないとダメなのかと愕然と(苦笑)
Re: (スコア:0)
アメリカ初の有人宇宙飛行マーキュリー計画の宇宙飛行士たちの物語なのですが、
NASAは本気でサルに訓練を施して、人間よりも先に、宇宙に飛ばしました。
それに対して、宇宙飛行士は座っているだけの余計なお荷物(文字どおり、最も厄介な荷物です。)ではないとして、彼らはプロジェクトに深く関わろうと努力していきます。
国家の威信をかけたプロジェクトと比較するのはアレですが、
運用を行う作業員に対して、手順書だけ渡して訓練を行わないというのは、どうかと思います。
深刻な事態に直面したとき、その手順のすべてが初めて触れる・やることだというのは、無謀です。
工数がないという現実的な話もありますが、せめて訓練くらいはやったほうがいいと思います。
バックアップからリストアしたら動かなかった、なんていうのも訓練すれば洗い出せますし、
手順書の内容が十分かどうかの試験や、向いていない人を排除する試験にもなりますし。
Re: (スコア:0)
サルが配置されると手順書のほかに必要な知識を使わず運用するので、
手順書の作り方がまず間違っています
Re: (スコア:0, オフトピック)
サル呼ばわりはないでしょう、いくらなんでも。
表現が不快。
Re: (スコア:0, おもしろおかしい)
いちいち自分が不快だと言う事を表明するあなたが不快。
でも、なぜ不快になるかが興味ある。
・自分が言われた側である(サル)
・知り合いがサル
・I love monkey!
・祖先がサルだった
あとなんだろうなぁ・・・
Re: (スコア:0)
同じアホなら踊らにゃ損
踊ろうぜ！サルサを！（やっぱ猿なのか？）
下らないので去る
Re: (スコア:0)
対象がどういう人間だとして、見下したような呼称・表現をすることに
強い不快感を表明することに、わたしは何ら恥じることはありません。
ただし、逆に不快感を示されるのも結構です。
見る角度が違えば違うとらえ方は生まれるものでしょうし。
ただし、私の目からは、くだらない優越感を誇っているようにしか見えません。
Re: (スコア:0)
・サルにサル呼ばわりされたから
Re: (スコア:0)
手順書がないと何もできない人間をサル呼ばわりするのは
サルに失礼?
でも、手順書どおりにやってくれる人間を頼んだつもりで
手順書渡しても、手順書を無視してあれやこれややって
くれるので、そういう人はサル以下だと思います。
Re: (スコア:0)
> 下手に安定してしまうと他所に回されて、手順書の整備もされず、
> コマンドの訳もわからず叩く良く訓練されたサルが運用します。
某衛星システムの運用にかかわっているんですけど、今まさにこの状態です。
ウチだけじゃなかったんだと妙に関心しました。
絶対にAC
Re: (スコア:0)
さすが！現場にいたサルはよく知ってるね。
Re: (スコア:0)
もしくは、関連記事にもある"バックアップにならないミラーリング"構成で、
構造が破壊された状態のデータベースを論理的に"バックアップ"したために復旧に使えなくなったとか…
#バックアップから復旧させようとしてバックアップに壊れたデータベース上書きしちゃいました、とかだったり…
#さすがにないか。
Re:ま、まさか (オフトピ) (スコア:0)
あそこって言うと韓国の★★★(←伏せ字)ですよね(違)
バッファローのRaid5外付けeSATAディスクに使われていたのですが、買ってから１年以内に壊れました。
どうも壊れ方が微妙だったらしく、RAID5全体が使用不能になりかけて焦りました。
結局１台ずつケーブル抜きで立ち上げて、故障していたユニットを外したところで縮退モードで立ち上がりました。
緊急なので最近話題の方のあそこのBarracuda ES2を買ってきて、駄目ファームウェアを最新に書き換えて繋いだらゃんと動きました。
念のためにエージングしてるから高信頼性との触れ込みの純正品を発注したら、WDのドライブでした。
・・・結構なんでもいいんだ。