SUPPORT HACK
どんなにテストしても、動作検証してもバグは絶対に出ますよね。
絶対に人は間違うし、すべての環境なんてテストできないよね。
だったら、運用中にバグがでることを見越したハックがあってもいいんぢゃないかなーと。
- 1. 自己診断モードを作ろう
家電製品などはメンテナンスをしやすいように、サービス要因向けのメンテナンスモードがある。
これをソフトウェアに導入しない手はない。
自己チェックルーチンを作ろう。
自己チェックルーチンは、自分の状態が間違っていないか確認する。
自分自身のリソースや、ファイルが壊れていないか診断を行う。
間違っていたら、dumpログを作るとか、アプリケーションログに書いて報告したりする。
もしかしたら、プロセスを再起動させてくれてもいいだろう。
長期間動作するプログラムを作っているなら(サーバとか)、自己チェックモードをぜひ実装しよう。
- 2. アプリケーションログを吐こう
アプリケーション内部でログを吐こう。
もちろん、高速に処理したい場合や、何百億と呼び出される部分は別だけど。
アプリケーションログは、アプリケーションに問題が発生したときの貴重なヒントになる。
すべてのエラー分岐にはログを吐かせたいところだ。
APIの失敗時には、 errno や GetLastError 値を忘れずにログに書こう。
さらに、課金やファイル更新等のクリティカルな処理の前には、処理を開始します。しました。のログを吐かせよう。
もし、フレームワークを作っているなら、絶対にログもフレームワークに含めよう。
気軽に呼び出せるようなロガーにしよう。
printf みたいな構文が渡せるロガーだと気軽に使えるだろう。
- 3. 可能であればASSERTを消さないでおこう。
ASSERTは 最小単位の自己診断モードだ。
普通はリリース時にはすべて取り除いてしまうが、可能であれば、リリースした後も有効になるような仕掛けを作ろう。
たとえば、デバッグオプションつきで実行すると有効になるとかの仕掛けを残そう。
#もちろん、パフォーマンスが要求されれば別だけど。
Webアプリにも ASSERTを仕掛けよう。
ASSERTのコストなんて SQLのコストと比べるとたいしたことない。
常に変更される可能性があるWebアプリにこそ、ASSERTが一番似合う。
どんどんASSERTを仕掛けよう。
リリース時のASSERTで何か問題が発生したら、アプリケーションログに書き込んで core等を作るか何かの動作をしよう。
アプリケーションログにはサポートする重大なヒントが格納される。
- 4. core dumpしよう
windowsだったら、 Minidumpで簡単に core を作ることができる。
webアプリでも phpなら debug_backtrace や _REQUEST _SESSIONあたりをファイルに書き出しておこう。
core はデバッグする上での大変重要な値になる。
絶対取得しよう。
- 5.異常を通知しよう
異常があれば、メールで関係者に通知するような機能を作ろう。
#社内で運用しているソフトにしか使えないだろうが。
異常の早期発見こそが、早期解決につながるし、ぶちきれる人を少なくすることができる唯一の道だ。
windowsのVC++ では、リリースしたバージョンの .pdb .map 等を保存していれば、クラッシュしたアドレスからソースの行数を追跡することが可能になる。
ソフトをリリースするときは、ソースコードと一緒に、これらのファイルもDVDに焼くなりしてちゃんと管理しよう。
- 7. バックアップを取ろう
よくないことは必ずおきるのでデータのバックアップは必ず取ろう。
データ破損からの回復には、バックアップが唯一の道だ。
- 8. ログ回収ツールを作ろう
お客様から動作不良が指摘されたときに、いち早く情報を収集するかが大切になる。
OS/CPU/メモリ/機種/core/アプリケーションログ/システムログ/etc... これらすべての情報が必要になるだろう。
お客様から電話で聞きだすのはかなり大変だし、ログファイルをいちいちお客様に集めてもらうのは非常に大変だ。
ボタン一発でこれらを集めてzip等にするスクリプトやソフトを作っておこう。
お客様がトラブルを報告したくなったら、このソフトを起動するだけで、聞き出したい情報がすべて収集できるようになる。
あとは、それを頼りにバグ再現の始まりだ。
- 9. 運用ルールを定められるようにしよう。
サーバ系のソフトウェアだったら、munin等の各種監視ソフトにソフトウェアの情報を提供できるようにしよう。
これらはシステム運用者に重要なシグナルを送ることができるはずだ。
ウェブサービスならば、apacheのログに %T や %B を設定し、応答速度を監視させよう。
異常に遅い処理の発見や、サーバのリソース監視指数の一つになるだろう。
- 10. このプログラムは、多分バグって落ちると思って設計しよう
この世に絶対はない。
あなたのコードはも絶対バグはあるし、クラッシュする。
だから、クラッシュすることを想定した設計にしよう。
クラッシュしても、データが守られたり、サービス全体がとまらないようにしよう。
- まとめ
バグ解決にはフローがあって、大体こんなフローをたどります。
どこでバグるのか？
バグを再現させる。再現できないバグが一番厄介。
↓
なぜバグるのか？
再現できれば、比較的楽。
ただし、スレッドの同期やメモリ破壊などを除くw
↓
修正
↓
検証
↓
リリース
↓
残務処理
バグによって壊れたデータを復旧させたり、ごめんなさいしたり。
バグが早くわかればわかるほど、誤る人の数は減る。
SUPPORT HACKでは、どこでバグるのか？と残務処理をいかに簡単にするかが目的です。
