アカウント名:
パスワード:
>リブート後には再現されない恐れがある。問題は解消され、かつ、二度とその問題が起こらないのであれば、リブートするのは極めて合理的な解決策である(キリッ
原因を特定できなければ、再発する恐れはあるので、「二度とその問題が起こらない」と果てして言えるかしら。
>原因を特定できなければ、再発する恐れはあるので、
原因を特定できないで、ずっと待っている羽目に陥る恐れがあるので、「原因究明してから再度動かせ」も、言えない面があるわけなんだな。
半年に一回壊れる、原因究明が出来ない、じゃ壊れてもよい様にしておけ..というのも、問題の解消ということになるんだな。
問題が問題なのは、害があること。つまり、問題の問題となっている害をなくせば、それなりに問題解決。
IT業界、不思議なところで、ダンプとってもログ読んでもわかんないこともある。結構な確率で調査は長期化する(ユーザにとっては1時間でも長期化と判断する)。
そして、まさに時間を失うことが「害」という局面がよくあることで、それを最小限にする、問題があっても時間を失わない様にするといったことも、原因究明より「手早くできる」ということなんだな。
# ライト付いてますか?にも、こんな感じの話があったよな。
>それを分かっているのに、100%確実に分かることを要求しているんですね、鬼だな。
そうなんだよね、率が悪いとかわかっていながら、解析しますという契約だしてくるってのが、鬼の様に馬鹿ですよね。そして、解析失敗続きなのに、なにも用意せずに同じことをやっている。ちゃんと「次はログが採れる様にします」「ログレベルを変えます」「事象発生前の挙動から、何かわかる様にします」といったことを言えばいいのにね。
>それを分かっているのに、ダンプとっている間にサービスが止まるようなシステムを組むわけだ。
なので、ダンプが意味がないということを、少なくともそのベンダーのについては証明されちゃったんだな。ダンプをできるだけ正確にとりたいので、結線とか換えるな,,クラスタが困るぞ..とかねなんというか、理屈に合わないことをやっているベンダーさんなんだよな。
>自分たちがやるべきことをやらずに、それで生じる損害を、社外の誰かのせいにしてるわけだね。
え?あのベンダーがどこかに丸投げしちゃっているんですかね?でも、糾弾の先はあそこなんだけどね。
>そんなクズな客を相手にしている、本質的には保険屋みたいな会社に構築から運用管理まで全部たのみなよ。
まぁ、ちゃんとサービス継続していますからねぇ。サービスとめて調べさせてくれ、無駄だったよね?何か改善したの?こちらは色々と別サーバへの移管を含めてやっているよ、ベンダー違うけど、そっちでは動いていたりするからね。でもって、そっちの方が迅速だったりするわけなんですな。
で、リブート以外の確実かつ迅速な方法を提案できないクズが何か言っても、全然無力だよ。リブートを含めて、迅速にやれないお方が何か言ったところでね、でもACちゃんだと無理だろうね。がんばって、無駄な調査したいんです!と言い続けるだけの自称エンジニアみたいな無駄で害悪になる糞は、できるだけシステムに近づけない方がよいという結論だな。
>ダンプを解析することで必ず原因を判明させるという契約なのか? あなたの誤解ではなくて?
はい、解明しますと営業さんは言っていて、それの議事録があるわけです。
>そりゃ口先だけで済むなら、言うだろうが、そうは言えない事情もあるのでしょう?
そうなの?低能ば馬鹿ベンダーの都合はどうでもいいからね。こちらは可用性をあげるというお仕事をしているので、嘘でたらめを言ったベンダーについては相手にしないことが多くなるという当たり前のことだったりします。
>じゃぁ、そのベンダーと、そのベンダーを選定した、あなたの会社の人間を切るべきだ。
はい、別部署に送られましたね。というか、人が結構異動するので、元が誰か?なんてことを調べる閑があったら、システムを改善しています。
>「自分たち」というのは、あなたと、あなたの会社のことだ。
じゃ、丸投げなんてことはしていませんな。解析業務をやって解明するという嘘をいったのを、その害悪を減らすという当たり前をやっているわけです。当然、その後も同じ状況なら営業さんごと切られますけどね。実際、ベンダーを切り替えられているのも結構あるからね。
だけど、なぜかOracle切らないのかなぁ..と不思議なんですが、これはわたしらがやっている分野とはちょっと違うので「またOracle暴れているよ、お客さんも怒っているよ、がんばってくださいね」とかね。
責任分担が明確だと、こういったことも出来るわけです。
>ま、原因がなかなか分からないこともあるさ。
そうなんだよね。で、解析して突き止めますとかで、ダンプ/ログ、サーバ外のネット系の状況ならDBサーバやら別のサーバとかも調べる。でも、わからないことがあるってのは、こちらも協力する。それがことごとく無駄になっているという状況に危機感がない馬鹿なベンダーさんが、馬鹿だから、解析します!時間をください!だけ。
判らないことがあるさ..で放置しておけるレベルの仕事しかしていない方もいらっしゃるのは、理解しています。特に低能というか技術者とは言えないレベルの方々がそういった仕事に従事されていらっしゃるということをね。
ほら、あなたも代案だせないじゃないですか?「こういう理由だったから判明できなかったと思われる、こういった事例もある」といったことを示す程度も出来ない方々は、あまりわたしの近辺にはおりませんが、たまに混じってくるので、困り者。つまり、その程度で技術云々しちゃうあなた程度のお方は、あまりサービス提供/維持といったお仕事はあっていない(無理とも言うかな?)ということなんでしょう。
次は、ACさん、がんばって代案だしてちょうだいね。代案ださないで、こっちがどうとか言っても、回しているからねぇ、サービスまわせない低能が騒ぐのは、面白いけどね。馬鹿の踊りを見て、ちょっと嗤う程度ですが...がんばって、次は提案どうぞ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
エンドユーザの視点 (スコア:1, 興味深い)
>リブート後には再現されない恐れがある。
問題は解消され、かつ、二度とその問題が起こらないのであれば、
リブートするのは極めて合理的な解決策である(キリッ
Re: (スコア:0)
原因を特定できなければ、再発する恐れはあるので、
「二度とその問題が起こらない」と果てして言えるかしら。
Re: (スコア:1)
>原因を特定できなければ、再発する恐れはあるので、
原因を特定できないで、ずっと待っている羽目に陥る恐れがあるので、
「原因究明してから再度動かせ」も、言えない面があるわけなんだな。
半年に一回壊れる、原因究明が出来ない、じゃ壊れてもよい様にしておけ..
というのも、問題の解消ということになるんだな。
問題が問題なのは、害があること。つまり、問題の問題となっている害をなくせば、それなりに問題解決。
IT業界、不思議なところで、ダンプとってもログ読んでもわかんないこともある。
結構な確率で調査は長期化する(ユーザにとっては1時間でも長期化と判断する)。
そして、まさに時間を失うことが「害」という局面がよくあることで、
それを最小限にする、問題があっても時間を失わない様にするといった
ことも、原因究明より「手早くできる」ということなんだな。
# ライト付いてますか?にも、こんな感じの話があったよな。
Re:エンドユーザの視点 (スコア:0)
それを分かっているのに、100%確実に分かることを要求しているんですね、鬼だな。
> 結構な確率で調査は長期化する(ユーザにとっては1時間でも長期化と判断する)。
それを分かっているのに、ダンプとっている間にサービスが止まるようなシステムを組むわけだ。
自分たちがやるべきことをやらずに、それで生じる損害を、社外の誰かのせいにしてるわけだね。
そういうやりかたしたいなら、そんなクズな客を相手にしている、本質的には保険屋みたいな会社に構築から運用管理まで全部たのみなよ。
Re:エンドユーザの視点 (スコア:1)
>それを分かっているのに、100%確実に分かることを要求しているんですね、鬼だな。
そうなんだよね、率が悪いとかわかっていながら、解析しますという契約だしてくるってのが、鬼の様に馬鹿ですよね。
そして、解析失敗続きなのに、なにも用意せずに同じことをやっている。
ちゃんと「次はログが採れる様にします」「ログレベルを変えます」「事象発生前の挙動から、何かわかる様にします」といったことを言えばいいのにね。
>それを分かっているのに、ダンプとっている間にサービスが止まるようなシステムを組むわけだ。
なので、ダンプが意味がないということを、少なくともそのベンダーのについては証明されちゃったんだな。
ダンプをできるだけ正確にとりたいので、結線とか換えるな,,クラスタが困るぞ..とかね
なんというか、理屈に合わないことをやっているベンダーさんなんだよな。
>自分たちがやるべきことをやらずに、それで生じる損害を、社外の誰かのせいにしてるわけだね。
え?あのベンダーがどこかに丸投げしちゃっているんですかね?
でも、糾弾の先はあそこなんだけどね。
>そんなクズな客を相手にしている、本質的には保険屋みたいな会社に構築から運用管理まで全部たのみなよ。
まぁ、ちゃんとサービス継続していますからねぇ。
サービスとめて調べさせてくれ、無駄だったよね?何か改善したの?
こちらは色々と別サーバへの移管を含めてやっているよ、ベンダー違うけど、そっちでは動いていたりするからね。
でもって、そっちの方が迅速だったりするわけなんですな。
で、リブート以外の確実かつ迅速な方法を提案できないクズが何か言っても、全然無力だよ。
リブートを含めて、迅速にやれないお方が何か言ったところでね、でもACちゃんだと無理だろうね。
がんばって、無駄な調査したいんです!と言い続けるだけの自称エンジニアみたいな無駄で害悪になる糞は、できるだけシステムに近づけない方がよいという結論だな。
Re: (スコア:0)
> そうなんだよね、率が悪いとかわかっていながら、解析しますという契約だしてくるってのが、鬼の様に馬鹿ですよね。
本当に、ダンプを解析することで必ず原因を判明させるという契約なのか? あなたの誤解ではなくて?
> そして、解析失敗続きなのに、なにも用意せずに同じことをやっている。
ま、原因がなかなか分からないこともあるさ。
> ちゃんと「次はログが採れる様にします」「ログレベルを変えます」「事象発生前の挙動から、何かわかる様にします」といったことを言えばいいのにね
Re:エンドユーザの視点 (スコア:1)
>ダンプを解析することで必ず原因を判明させるという契約なのか? あなたの誤解ではなくて?
はい、解明しますと営業さんは言っていて、それの議事録があるわけです。
>そりゃ口先だけで済むなら、言うだろうが、そうは言えない事情もあるのでしょう?
そうなの?低能ば馬鹿ベンダーの都合はどうでもいいからね。
こちらは可用性をあげるというお仕事をしているので、嘘でたらめ
を言ったベンダーについては相手にしないことが多くなるという
当たり前のことだったりします。
>じゃぁ、そのベンダーと、そのベンダーを選定した、あなたの会社の人間を切るべきだ。
はい、別部署に送られましたね。
というか、人が結構異動するので、元が誰か?なんてことを調べる閑があったら、システムを改善しています。
>「自分たち」というのは、あなたと、あなたの会社のことだ。
じゃ、丸投げなんてことはしていませんな。
解析業務をやって解明するという嘘をいったのを、その害悪を減らすという当たり前をやっているわけです。
当然、その後も同じ状況なら営業さんごと切られますけどね。
実際、ベンダーを切り替えられているのも結構あるからね。
だけど、なぜかOracle切らないのかなぁ..と不思議なんですが、
これはわたしらがやっている分野とはちょっと違うので「また
Oracle暴れているよ、お客さんも怒っているよ、がんばって
くださいね」とかね。
責任分担が明確だと、こういったことも出来るわけです。
Re:エンドユーザの視点 (スコア:1)
>ま、原因がなかなか分からないこともあるさ。
そうなんだよね。で、解析して突き止めますとかで、ダンプ/ログ、サーバ外のネット系の状況ならDBサーバやら別のサーバとかも調べる。
でも、わからないことがあるってのは、こちらも協力する。
それがことごとく無駄になっているという状況に危機感がない馬鹿なベンダーさんが、馬鹿だから、解析します!時間をください!だけ。
判らないことがあるさ..で放置しておけるレベルの仕事しかしていない方もいらっしゃるのは、理解しています。
特に低能というか技術者とは言えないレベルの方々がそういった仕事に従事されていらっしゃるということをね。
ほら、あなたも代案だせないじゃないですか?
「こういう理由だったから判明できなかったと思われる、こういった事例もある」といったことを示す程度も出来ない方々は、あまりわたしの近辺にはおりませんが、たまに混じってくるので、困り者。
つまり、その程度で技術云々しちゃうあなた程度のお方は、あまりサービス提供/維持といったお仕事はあっていない(無理とも言うかな?)ということなんでしょう。
次は、ACさん、がんばって代案だしてちょうだいね。
代案ださないで、こっちがどうとか言っても、回しているからねぇ、サービスまわせない低能が騒ぐのは、面白いけどね。
馬鹿の踊りを見て、ちょっと嗤う程度ですが...がんばって、次は提案どうぞ。