アカウント名:
パスワード:
>リブート後には再現されない恐れがある。問題は解消され、かつ、二度とその問題が起こらないのであれば、リブートするのは極めて合理的な解決策である(キリッ
原因を特定できなければ、再発する恐れはあるので、「二度とその問題が起こらない」と果てして言えるかしら。
>原因を特定できなければ、再発する恐れはあるので、
原因を特定できないで、ずっと待っている羽目に陥る恐れがあるので、「原因究明してから再度動かせ」も、言えない面があるわけなんだな。
半年に一回壊れる、原因究明が出来ない、じゃ壊れてもよい様にしておけ..というのも、問題の解消ということになるんだな。
問題が問題なのは、害があること。つまり、問題の問題となっている害をなくせば、それなりに問題解決。
IT業界、不思議なところで、ダンプとってもログ読んでもわかんないこともある。結構な確率で調査は長期化する(ユーザにとっては1時間でも長期化と判断する)。
そして、まさに時間を失うことが「害」という局面がよくあることで、それを最小限にする、問題があっても時間を失わない様にするといったことも、原因究明より「手早くできる」ということなんだな。
# ライト付いてますか?にも、こんな感じの話があったよな。
>それを分かっているのに、100%確実に分かることを要求しているんですね、鬼だな。
そうなんだよね、率が悪いとかわかっていながら、解析しますという契約だしてくるってのが、鬼の様に馬鹿ですよね。そして、解析失敗続きなのに、なにも用意せずに同じことをやっている。ちゃんと「次はログが採れる様にします」「ログレベルを変えます」「事象発生前の挙動から、何かわかる様にします」といったことを言えばいいのにね。
>それを分かっているのに、ダンプとっている間にサービスが止まるようなシステムを組むわけだ。
なので、ダンプが意味がないということを、少なくともそのベン
>ダンプを解析することで必ず原因を判明させるという契約なのか? あなたの誤解ではなくて?
はい、解明しますと営業さんは言っていて、それの議事録があるわけです。
>そりゃ口先だけで済むなら、言うだろうが、そうは言えない事情もあるのでしょう?
そうなの?低能ば馬鹿ベンダーの都合はどうでもいいからね。こちらは可用性をあげるというお仕事をしているので、嘘でたらめを言ったベンダーについては相手にしないことが多くなるという当たり前のことだったりします。
>じゃぁ、そのベンダーと、そのベンダーを選定した、あなたの会社の人間を切るべきだ。
はい、別部署に送られましたね。というか、人が結構異動するので、元が誰か?なんてことを調べる閑があったら、システムを改善しています。
>「自分たち」というのは、あなたと、あなたの会社のことだ。
じゃ、丸投げなんてことはしていませんな。解析業務をやって解明するという嘘をいったのを、その害悪を減らすという当たり前をやっているわけです。当然、その後も同じ状況なら営業さんごと切られますけどね。実際、ベンダーを切り替えられているのも結構あるからね。
だけど、なぜかOracle切らないのかなぁ..と不思議なんですが、これはわたしらがやっている分野とはちょっと違うので「またOracle暴れているよ、お客さんも怒っているよ、がんばってくださいね」とかね。
責任分担が明確だと、こういったことも出来るわけです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
エンドユーザの視点 (スコア:1, 興味深い)
>リブート後には再現されない恐れがある。
問題は解消され、かつ、二度とその問題が起こらないのであれば、
リブートするのは極めて合理的な解決策である(キリッ
Re: (スコア:0)
原因を特定できなければ、再発する恐れはあるので、
「二度とその問題が起こらない」と果てして言えるかしら。
Re: (スコア:1)
>原因を特定できなければ、再発する恐れはあるので、
原因を特定できないで、ずっと待っている羽目に陥る恐れがあるので、
「原因究明してから再度動かせ」も、言えない面があるわけなんだな。
半年に一回壊れる、原因究明が出来ない、じゃ壊れてもよい様にしておけ..
というのも、問題の解消ということになるんだな。
問題が問題なのは、害があること。つまり、問題の問題となっている害をなくせば、それなりに問題解決。
IT業界、不思議なところで、ダンプとってもログ読んでもわかんないこともある。
結構な確率で調査は長期化する(ユーザにとっては1時間でも長期化と判断する)。
そして、まさに時間を失うことが「害」という局面がよくあることで、
それを最小限にする、問題があっても時間を失わない様にするといった
ことも、原因究明より「手早くできる」ということなんだな。
# ライト付いてますか?にも、こんな感じの話があったよな。
Re: (スコア:0)
それを分かっているのに、100%確実に分かることを要求しているんですね、鬼だな。
> 結構な確率で調査は長期化する(ユーザにとっては1時間でも長期化と判断する)。
それを分かっているのに、ダンプとっている間にサービスが止まるようなシステムを組むわけだ。
自分たちがやるべきことをやらずに、それで生じる損害を、社外の誰かのせいにしてるわけだね。
そういうやりかたしたいなら、そんなクズな客を相手にしている、本質的には保険屋みたいな会社に構築から運用管理まで全部たのみなよ。
Re: (スコア:1)
>それを分かっているのに、100%確実に分かることを要求しているんですね、鬼だな。
そうなんだよね、率が悪いとかわかっていながら、解析しますという契約だしてくるってのが、鬼の様に馬鹿ですよね。
そして、解析失敗続きなのに、なにも用意せずに同じことをやっている。
ちゃんと「次はログが採れる様にします」「ログレベルを変えます」「事象発生前の挙動から、何かわかる様にします」といったことを言えばいいのにね。
>それを分かっているのに、ダンプとっている間にサービスが止まるようなシステムを組むわけだ。
なので、ダンプが意味がないということを、少なくともそのベン
Re: (スコア:0)
> そうなんだよね、率が悪いとかわかっていながら、解析しますという契約だしてくるってのが、鬼の様に馬鹿ですよね。
本当に、ダンプを解析することで必ず原因を判明させるという契約なのか? あなたの誤解ではなくて?
> そして、解析失敗続きなのに、なにも用意せずに同じことをやっている。
ま、原因がなかなか分からないこともあるさ。
> ちゃんと「次はログが採れる様にします」「ログレベルを変えます」「事象発生前の挙動から、何かわかる様にします」といったことを言えばいいのにね
Re:エンドユーザの視点 (スコア:1)
>ダンプを解析することで必ず原因を判明させるという契約なのか? あなたの誤解ではなくて?
はい、解明しますと営業さんは言っていて、それの議事録があるわけです。
>そりゃ口先だけで済むなら、言うだろうが、そうは言えない事情もあるのでしょう?
そうなの?低能ば馬鹿ベンダーの都合はどうでもいいからね。
こちらは可用性をあげるというお仕事をしているので、嘘でたらめ
を言ったベンダーについては相手にしないことが多くなるという
当たり前のことだったりします。
>じゃぁ、そのベンダーと、そのベンダーを選定した、あなたの会社の人間を切るべきだ。
はい、別部署に送られましたね。
というか、人が結構異動するので、元が誰か?なんてことを調べる閑があったら、システムを改善しています。
>「自分たち」というのは、あなたと、あなたの会社のことだ。
じゃ、丸投げなんてことはしていませんな。
解析業務をやって解明するという嘘をいったのを、その害悪を減らすという当たり前をやっているわけです。
当然、その後も同じ状況なら営業さんごと切られますけどね。
実際、ベンダーを切り替えられているのも結構あるからね。
だけど、なぜかOracle切らないのかなぁ..と不思議なんですが、
これはわたしらがやっている分野とはちょっと違うので「また
Oracle暴れているよ、お客さんも怒っているよ、がんばって
くださいね」とかね。
責任分担が明確だと、こういったことも出来るわけです。