詳解システムパフォーマンスを読む⑬　メソドロジー続き

前回の続き

P.36あたりから

メソドロジ

　街灯のアンチメソッド、観察による分析

　　内容：自分の知っている範囲やツールのみを頼りにパフォーマンス分析を行う

　　　　　色々なツールがあるにもかかわらずそれらに触れていないとこうなる

　　※暗い中落とし物を探すときに、とりあえず点灯している街頭の下を探すところから

　ランダム変更アンチメソッド

　　内容：チューニング可能なパラメータを適当に選んで値を変えて良くなるか試す

　　　　　短期的に良くなったように見えるが、長期的に良いパラメータかは不明

　　　　　さらに、別起因で悪くなっていたパフォーマンスへ、その場しのぎの対処をしてしまうとその起因がなくなった後に変な変更のみが残ってしまう

　誰かのせいにするアンチメソッド

　　内容：自責とならないシステムやコンポーネントを選び、それがパフォーマンスの悪さを引き起こしていると仮定して調べさせる

　　　　　調べて違った場合、また別のシステムやコンポーネントで同じことをやる

　　　　　相手側からやられないように、クライテリアを求めるとよい

　アドホックチェックリストメソッド

　　内容：毎回チェックする内容をあらかじめチェックリスト化しておく

　　　　　例えば、XXXXコマンドを打って値がYYYならZZZZZが疑われる、など

　　　　　短期間では効果を発揮するが、長期的には不向きなのと、チェックリスト自体のケアが必要

　　　　　ランダムな変更にくらべ、一定の基準があるのがポイント

　問題の記述

　　内容：サポートスタッフが最初に聞くこと　あらかじめ箇条書きにしておく

　　　　　現場では問い合わせフォームにあらかじめ書くようなもの

　　　　例）　　

　　　　　パフォーマンスに問題があるのはなぜ？

　　　　　このシステムは、ちゃんと動いていた時期があったか？

　　　　　最近の変更は？SW？HW？他？

　　　　　その問題は、レイテンシや実行時間で表現できる？

　　　　　この問題の影響範囲は個人か、一部か、全体か？

　　　　　この環境のHW、SW、バージョン、環境などはどうなっているか？

以上　