アカウント名:
パスワード:
子犬の画像や色つきのダイアログを出すというのは要するにそういう機能を実装するという話。それならみっちりログを記録できる仕組みを実装した方が遥かに有益。
何かを読ませるというのは不毛な努力だな。連中は何が表示されたかはもちろん、自分が何をしたかすら一切覚えることができない障害者のようなものだ。
私の会社でも意味が通じないエラーメッセージを表示するより、ログをしっかりと記録するようにしていますね。桁数オーバーとか入力値エラーなんかは都度表示するようにはしていますが、プログラム作成者やシステム管理者でなければわからないエラーの場合は即座に私のところに通知がくるように、指定されたメールアドレスに直近の操作やエラー内容が送信されるようにし、ユーザーへのメッセージとしては「解決不能なエラーが発生したのでシステム管理者に自動で連絡を行いました。緊急の場合は内線xxxまで連絡をしてください」といった内容を表示するようにしました。これなら対応は迅速に行えますし、ネットワーク障害でメールすら送れなかった場合でも内線で連絡が来た後にローカルへ保存された当該システムのエラーログを見れば原因がすぐわかりますし、対処も楽に。
様はユーザーにエラー内容を覚えろ/教えてっていうのが無理な話なんですよね。
ログが最強だと思う。
開発者はアプリケーションログにもっと力を入れればいいとおもうんね。少なくともすべての異常分岐にログをしかけるぐらいやりたい。(エラーは予期しない分岐ともいえるはず)できれば、操作系のします、しましたのログもほしい。coreやdmpでは場所が特定できても、履歴がないからどうしてそうなった?系の対応は難しい。アプリケーションのパフォーマンス上、許されるのであれば、ガシガシログを出力したい。
コマンドライン系のツールでは --debug とかで詳細なログをどんどんはいてくれるものが多いが、GUI系だとなかなかないよねぇ。
後はログを回収する手法を考えることになるんだけど。
フレームの元かもしれませんが、断片化と原因追求に難があること以外は、設計に問題があるように思えます。システム要件の見積り甘いんじゃないでしょうか。情報漏洩うんぬんも秘密保持契約の締結やらログ解析の依頼などやはり事前検討のレベルの話かと。
#サーバに関してだけですが
> ・ログが情報漏洩に繋がるから止めてくれと言われる仕方ないのでSEがログの中の顧客秘密情報を手作業で削除/置き換えしたので資料到着が遅れた上に置換ミスで意味不明になる。
> ・CPU時間やHDDアクセスの半分以上をログが消費している並行処理する複数のスレッドから同一ログファイルに書き込みを行なうせいでロック待ちでシステムがスローダウン/ハングアップする。
ほぼ同意です。
人間の記憶に頼ろうとしてはいけません。ユーザーが何を操作して何を表示したかを全てログに取っていれば、相手のユーザー名がわかるだけでいいはず。
そうではなく、エラーメッセージの内容から、ユーザーにエラーからの回復をさせたい場合は……サポートを有償にすれば大抵は自助努力で解決してくれます。
そう思う。うちのやり方はすべての操作のログを常に取れるだけとっておいて、なにかあったときはワンタッチでログが送られるようにしてある。操作ログなどはシステムの改良にも役に立つ。
有償にした側からみれば、自分のところへの(無茶な)サポート依頼が減って、ユーザが自分で探した何らかの方法(例えば無料のサポーター利用)で問題を解決してくれるわけですから、自助努力と言って差し支えないのでは?
そうだ!クズはクビにしよう!
>サポートを有償にすれば大抵は自助努力で解決してくれます。何もしていないのに(ウソ)エラーになった、そっちのせいだから無償で直せ、とゴネられて面倒なのは一緒だったりします
組み込み機器とかだと大変だよ?
組み込み機器のエラー表示をエンドユーザが見るかどうか? ってことでしょ. 通常はそれなりのスキルがある保守担当者が対応するでしょうし, 最近の(いや物によっては昔からか)組み込み機器ならフラッシュメモリにログを書き込んでおいて, 保守担当者がそれを回収ってパターンもありますし.
それに組み込み機器でもネットワーク接続が確立しているのなら, ネットワーク経由でログをログサーバに送信して保存しておくなんて極一般的な運用だと思いますけど. ネットワーク機器なんかでsyslogプロトコルでログを集中管理するなんていうのもその一例ですけど.
普通は自動的にメールするようにしとくものだと思うけど、それが無理ならUSBメモリとかにレポート吐くようにしとけば?で、メール送れるマシンに差し替えて送ってもらう。
#もしそれでもブッ殺されるというなら、キミは為すべきことを避けて甘ったれた仕事をしてるとしか思えない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
ログを取れ (スコア:1, すばらしい洞察)
子犬の画像や色つきのダイアログを出すというのは要するにそういう機能を実装するという話。
それならみっちりログを記録できる仕組みを実装した方が遥かに有益。
何かを読ませるというのは不毛な努力だな。
連中は何が表示されたかはもちろん、自分が何をしたかすら一切覚えることができない障害者のようなものだ。
Re:ログを取れ (スコア:2, 参考になる)
私の会社でも意味が通じないエラーメッセージを表示するより、ログをしっかりと記録するようにしていますね。
桁数オーバーとか入力値エラーなんかは都度表示するようにはしていますが、プログラム作成者やシステム管理者でなければわからないエラーの場合は即座に私のところに通知がくるように、指定されたメールアドレスに直近の操作やエラー内容が送信されるようにし、ユーザーへのメッセージとしては
「解決不能なエラーが発生したのでシステム管理者に自動で連絡を行いました。緊急の場合は内線xxxまで連絡をしてください」
といった内容を表示するようにしました。
これなら対応は迅速に行えますし、ネットワーク障害でメールすら送れなかった場合でも内線で連絡が来た後にローカルへ保存された当該システムのエラーログを見れば原因がすぐわかりますし、対処も楽に。
様はユーザーにエラー内容を覚えろ/教えてっていうのが無理な話なんですよね。
Re:ログを取れ (スコア:2, 興味深い)
ログが最強だと思う。
開発者はアプリケーションログにもっと力を入れればいいとおもうんね。
少なくともすべての異常分岐にログをしかけるぐらいやりたい。(エラーは予期しない分岐ともいえるはず)
できれば、操作系のします、しましたのログもほしい。
coreやdmpでは場所が特定できても、履歴がないからどうしてそうなった?系の対応は難しい。
アプリケーションのパフォーマンス上、許されるのであれば、ガシガシログを出力したい。
コマンドライン系のツールでは --debug とかで詳細なログをどんどんはいてくれるものが多いが、GUI系だとなかなかないよねぇ。
後はログを回収する手法を考えることになるんだけど。
by rti.
Re: (スコア:0)
・ログを見せてくれというと、サイズが大きすぎて渡せないと言われる
・ログが情報漏洩に繋がるから止めてくれと言われる
・ログでCドライブが溢れた。(そして、空き容量がゼロになると設定ファイルが破損するような実装の人たちが悲鳴をあげる)
・ちょろちょろとログを書き込むのでファイルシステムの断片化が激しい
・CPU時間やHDDアクセスの半分以上をログが消費している
・それだけログを出していても、原因がわからない。
Re:ログを取れ (スコア:1)
フレームの元かもしれませんが、
断片化と原因追求に難があること以外は、設計に問題があるように思えます。
システム要件の見積り甘いんじゃないでしょうか。
情報漏洩うんぬんも秘密保持契約の締結やらログ解析の依頼など
やはり事前検討のレベルの話かと。
#サーバに関してだけですが
☆大きい羊は美しい☆
Re: (スコア:0)
> ・ログが情報漏洩に繋がるから止めてくれと言われる
仕方ないのでSEがログの中の顧客秘密情報を手作業で削除/置き換えしたので
資料到着が遅れた上に置換ミスで意味不明になる。
> ・CPU時間やHDDアクセスの半分以上をログが消費している
並行処理する複数のスレッドから同一ログファイルに書き込みを行なうせいで
ロック待ちでシステムがスローダウン/ハングアップする。
Re:ログを取れ (スコア:1)
何かあれば、端末IDからリモートでログを取得しての追跡調査をしていた。
憶えていないor勘違いも全部分かるので重宝した。
操作ログだから再現性があるかどうかも分かるしね。
Re: (スコア:0)
ほぼ同意です。
人間の記憶に頼ろうとしてはいけません。
ユーザーが何を操作して何を表示したかを全てログに取っていれば、相手のユーザー名がわかるだけでいいはず。
そうではなく、エラーメッセージの内容から、ユーザーにエラーからの回復をさせたい場合は……
サポートを有償にすれば大抵は自助努力で解決してくれます。
Re: (スコア:0)
そう思う。
うちのやり方はすべての操作のログを常に取れるだけとっておいて、なにかあったときは
ワンタッチでログが送られるようにしてある。操作ログなどはシステムの改良にも役に立つ。
自助努力ねぇ… (スコア:0)
エラーメッセージの内容を理解しようと試みことすらしない人間に「自助努力」なんてものがあると考えるほうがどうかしていると思います。
サポートを有料にした所で他力本願な人は「無料の」サポートに移るだけです。
隣の席の人とか、課内のパソコンに詳しそうな人とか、自助努力をする人におんぶしに行くだけです。
「大抵」解決してくれちゃうなんてそれどんな夢の国?
Re:自助努力ねぇ… (スコア:1)
有償にした側からみれば、自分のところへの(無茶な)サポート依頼が減って、
ユーザが自分で探した何らかの方法(例えば無料のサポーター利用)で問題を
解決してくれるわけですから、自助努力と言って差し支えないのでは?
Re: (スコア:0)
そうだ!クズはクビにしよう!
Re: (スコア:0)
>サポートを有償にすれば大抵は自助努力で解決してくれます。
何もしていないのに(ウソ)エラーになった、そっちのせいだから無償で直せ、とゴネられて面倒なのは一緒だったりします
Re: (スコア:0)
ITは部門は看護婦のようなものですからね。
彼らが健常者になってしまったら商売上がったりです。
Re: (スコア:0)
看護師ほど自浄努力の働かない職種はない
# 奴らは患者の状態を医者に伝えるだけのアラームだと認識しておくと入院生活が楽になります
Re: (スコア:0)
ろくにlogも読まずに医者(2nd levelか開発者か)にエスカレート。
Re: (スコア:0, 興味深い)
ログをどうやって回収するかについても考えなきゃ。
組み込み機器とかだと大変だよ?
みっちりとったログは読み上げさせるわけにも行かないだろうし、
メールに打ち直してなんて言ったらブッ殺される。
Re:ログを取れ (スコア:1)
組み込み機器のエラー表示をエンドユーザが見るかどうか? ってことでしょ. 通常はそれなりのスキルがある保守担当者が対応するでしょうし, 最近の(いや物によっては昔からか)組み込み機器ならフラッシュメモリにログを書き込んでおいて, 保守担当者がそれを回収ってパターンもありますし.
それに組み込み機器でもネットワーク接続が確立しているのなら, ネットワーク経由でログをログサーバに送信して保存しておくなんて極一般的な運用だと思いますけど. ネットワーク機器なんかでsyslogプロトコルでログを集中管理するなんていうのもその一例ですけど.
Re: (スコア:0)
Re: (スコア:0)
普通は自動的にメールするようにしとくものだと思うけど、
それが無理ならUSBメモリとかにレポート吐くようにしとけば?
で、メール送れるマシンに差し替えて送ってもらう。
#もしそれでもブッ殺されるというなら、キミは為すべきことを避けて甘ったれた仕事をしてるとしか思えない。
ステルスファイターの法則 (スコア:0)
画面には出てんだよ!