今まで10以上近い現場で仕事をしてきましたが、どの現場でも絶対必要になる(かつどこもあまり対策が取られていない)技術としては
- 検証したい状態の復元がすぐにできる(テストデータ作成)
- ログの適切な設計
- エラーハンドリング
でしょうか。おそらくあと１０年たっても変わらないと思います。
いつもテストデータやエラーについては色々言っていたので、ログの設計に関して。
絶対入れる情報
時間ともし取得できればファイル行数
レベル分け
出すぎても、少なくすぎてもダメですね。
一般的にはざっくりDEBUG、INFO、WARN、ERRORぐらいに別れますかね。
個人的には下記のようにざっくり分けております。
DEBUG ・・一番詳細な情報。SQL、テキストエリアの文言、リクエストパラメーターなど全てだすと情報が多すぎて追い切れないところまで。詳細な調査をしたい時に見る情報。
INFO ・・メソッドの開始、終了など。処理がどこまで進んだか、どこで止まったかがわかるもの。開発時にはこれが指針となる。
WARN・・非推奨のメソッドやエラーではないが直しておきたい部分。
ERROR・・明らかにエラー、状態がおかしい時。
こんな風に分けてますが、実際に開発をしたり、運用をしていく上でレベルを調整していくのがいいかと思います。
個人的には開発時にはDEBUGとINFOの使い分けが大事で、運用時にはERRORの設計(漏れがないか)が大事だと思っています。
出す場所
開発時・・INFO以上を標準出力、運用時はWARN以上を標準出力にし、それ以下はファイル出力へ。
常時見る場所と、調査をしたい場所を使い分ける感じで。
参考URL
