今週、私はアトランタの顧客を訪問していません。つまり、飛行機や空港で多くの時間を過ごしています（特に今日、フライトがキャンセルされたため、6時間の遅延があります…）。つまり、多くの読書を意味します。 今回の旅行で読んだ本は リーンスタートアップのためのUX、LauraKleinによる。 よく読んで、良い常識的な戦略を提唱します。これを大まかに言い換えます。
- 顧客がUXをどのように使用し、使用できるかについてのいくつかの仮定が間違っているでしょう。 したがって、
- UXのMVPから始めます
- できるだけ早く（実装する前に）顧客のグループをテストするためにUXを示します。 彼らが問題を抱えている場所と彼らが好き/嫌いなものを見てください
- 顧客と一緒にUXを繰り返す
- 製品でリリースします。 使用状況とビジネスへの影響を測定する
- すすぎ、繰り返します。
これは、ある程度、スクラムのようなアジャイル手法の支持者から聞くのと同様のメッセージです。 DevOps、および一般的なリーンエンタープライズムーブメントから：共同作業。 頻繁にリリースします。 結果を測定します。
これはモニタリングとどのように関連していますか？
- 実稼働負荷の下でコードがどのように実行されるかについてのいくつかの仮定が間違っているでしょう。 したがって、
- 機能のMVPから始めます
- 限られた負荷で機能を実行します：ラボで、またはライブトラフィックの小さなセットで。 パフォーマンスの問題がどこにあるかを確認します。
- 開発者と一緒に機能とパフォーマンスのボトルネックを繰り返します
- 製品にリリースし、パフォーマンスと容量への影響を測定します
- すすぎ、繰り返します
UXを変更するのと同じように、パフォーマンスと容量の理由から、後でではなく早くコードを変更する方が簡単です。 フラットファイルを使用してすべての顧客のトランザクション履歴を保存する計画が5人の顧客ではうまく機能するが、5000人では機能しない場合は、5人の顧客がいるときにそれを見つける方がはるかに優れています。 （顧客にリリースする前に確認することをお勧めします。）それを見つけるには、5000人の顧客の負荷をシミュレートする必要がある場合がありますが、詳細な監視を行っている場合は、負荷の前に明らかになる可能性が高くなります。 。 フラットファイルの場合、ユーザー数が少ない場合でも、Linuxディスク要求の待ち時間が急増するのは簡単です。 MySQLを使用することを決定した時代錯誤の少ないアーキテクトがいる場合、ディスクレイテンシに問題は見られないかもしれませんが、テーブルスキャンが急増する可能性があります。 現在、実際の問題はありませんが、どこで痛みが増す可能性があるかを示しています。 Redis / Memcached / Cassandra / MongoDBを実行すると（できれば一度にすべてではない）、トランザクションでパフォーマンスの問題が発生しない場合がありますが、アプリケーションを実行するためのメモリが少ないため、スワッピングが開始される可能性があります。システムを分割します。
リーンUXでは、最初のステップは、ユーザーの小さなサブセットを定性的に観察して、最悪の問題を特定し、それを処理して繰り返すことです。 リーンモニタリングでは、最初から徹底的なモニタリングを展開する必要があります。経験のある人が、現在は問題ではないものの、より大きな負荷がかかっていることを示す可能性のある動作の変化と、それらに対処する方法を特定する必要があります。 （MysqlからNoSQLに変更しますか？インデックスを追加しますか？ハードウェアリソースを追加しますか？水平方向にスケーリングしますか？）傾向を適切にグラフィカルに表示して監視を行うほど、問題を早期に発見してスケーリングしてリリースできる可能性が高くなります。問題なく。
インフラストラクチャを実行していて、開発者と直接連携しない場合も、同じ原則が適用されます。 すべての機能をあるデータセンターから別のデータセンターに一度に移動するわけではありません（選択できる場合）。 新しいデータセンターで小さなアプリケーションセットを実行し、新しいデータセンターでできることをすべて監視し、見つかったエラーを修正してから、さらに負荷を移動します。 すすぎ、繰り返します。 新しいESXインフラストラクチャを導入しますか？ 重要でないVMを最初に移動します。 新しいExchangeクラスター？ テストせずにすべてのユーザーを一度に移動しないでください。
革命的なものはなく、人々が知らないものもありませんが、時々リマインダーを持っているのは良いことです。 すべての変更の鍵は、それらを小さく保ち、それらのがらくたを測定することです。