(Dev)Opsでは、リリースはその最悪の効果と同じくらい良いだけです

あらゆる種類の新機能と改善を備えた新しいコードをリリースしました。 わーい!

さて、「実際に本番環境で機能するか」などの明らかな事柄の後、これは評価する時期でもあります。それは、インフラストラクチャのパフォーマンス(したがって、スケーラビリティ、したがってスケーリングコスト)に何らかの影響を及ぼしましたか。

これは、適切な監視と傾向分析が不可欠なもうXNUMXつの領域です。

例として、昨夜、サーバーの小さなセットでリリースを行いました。

それは私たちのスケーラビリティを助けたり傷つけたりしましたか?

同じワークロードでCPU負荷が低下しました(この改善が原因である特定のJavaアプリケーションを示す他のグラフがありますが、これはシステム全体のCPUを示しています)。

テーブルの開封率(テーブルの開封はかなり集中的です)など、さまざまなMySQLパフォーマンスメトリックが改善されました。

しかし…すべてが改善されたわけではありません。

全体的なディスクのパフォーマンスと使用率は同じですが、ワークロードははるかに急上昇します。 (2000秒あたり最大XNUMXの書き込み操作をどのように取得するのか疑問に思っている人のために– SSDは素晴らしいです。)

そしてもちろん、ピーク時のワークロードがサーバーの使用を制約します。このワークロードの変化により、60%の安定した使用率で実行されていたサーバーは、100%に急上昇し、システムの他の部分でキューイングにつながる可能性があります。一般的な悪いこと。

現状では、このワークロードの変化が見られ、コードリリースに明確に起因している可能性があります。 これで、運用に影響を与えた可能性のある、より負荷の高いサーバーに適用する前に修正できます。

これにより、運用チームは満足し、顧客も満足します。また、同じレベルの規模でハードウェアに多くのお金を費やす必要がないため、ビジネスマンも満足できます。

方法のちょうど別の図 包括的な監視 あなたが予測しなかったかもしれない方法であなたのビジネスを助けることができます。