Ivan が DevOps メトリクスをどのように行ったか。 影響の対象

Ivan が最初に DevOps メトリクスについて考え、彼らの助けがあれば製品の納期を管理する必要があることに気づいてから XNUMX 週間が経過しました (市場投入までの時間)。

週末であっても、彼は指標について考えていました。 それは私に何を与えてくれるでしょうか?

実際、時間の知識は何をもたらすのでしょうか? 配達に5日かかるとしましょう。 それで、次は何でしょうか? 良いのか悪いのか? たとえそれが悪いことであっても、この時間を何とか短縮する必要があります。 しかし、どうやって?
こうした考えが彼を悩ませましたが、解決策は見つかりませんでした。

イワンは自分が本質に到達したことを理解しました。 彼は、これまでに見た無数のメトリクスのグラフから、標準的なアプローチは機能せず、単にプロットしただけでは機能しないと確信していました (たとえそれが集団であっても)、役に立たないでしょう。

どうなるか?…

メトリクスは通常の木製の定規のようなものです。 このツールを使って測定しても、その理由は分かりません。 理由 測定されている物体はまさに彼女が示した長さです。 定規はそのサイズを表示するだけで、それ以上は何も表示されません。 彼女は賢者の石ではなく、単に測定するための木の板です。

彼のお気に入りの作家ハリー・ハリスンの「ステンレス鋼のネズミ」はいつもこう言っていました。思考は脳の底に到達してそこに横たわる必要があります。それで、無駄に数日間苦しんだ後、イワンは別の仕事に取り組むことにしました...

数日後、オンライン ストアに関する記事を読んでいたアイヴァンは、オンライン ストアが受け取る金額はサイト訪問者の行動によって決まることに突然気づきました。 店にお金を与え、その源となるのは彼ら、つまり訪問者/顧客です。 店舗が受け取る最終的な現金は、他のものではなく、顧客の行動の変化によって影響されます。

測定値を変更するには、この値を形成する人々、つまり、測定値を変更する必要があることが判明しました。 オンライン ストアの金額を変更するには、このストアの顧客の行動に影響を与える必要があり、DevOps で配送時間を変更するには、今回「作成」するチーム、つまり、 仕事で DevOps を使用します。

Ivan は、DevOps メトリクスをグラフで表すべきではないことに気づきました。 彼らは自分自身を表現しなければなりません 検索ツール 最終的な納期を決める「優秀な」チーム。

特定のチームがディストリビューションを提供するのに長い時間がかかった理由を示す指標は決してありません、と Ivan 氏は考えました。なぜなら、現実には XNUMX 万人と小さなカートが存在する可能性があり、それらはおそらく技術的なものではなく、組織的なものである可能性があるからです。 それらの。 メトリクスから得られる最大の期待は、チームとその結果を示すことですが、それでもやはり、これらのチームを自分の足で追い、チームの何が問題なのかを見つけ出す必要があります。

一方、イヴァンの会社には、すべてのチームが複数のベンチでアセンブリをテストすることを要求する基準がありました。 チームは前のスタンドが完了するまで次のスタンドに移動できませんでした。 DevOps プロセスをスタンドを通過する一連のプロセスとして想像すると、指標はチームがスタンドで費やした時間を示すことができることがわかりました。 チームの立場と時間を知っているので、その理由についてより具体的に話すことができました。

Ivan はためらうことなく電話を手に取り、DevOps の隅々まで精通している人物の番号にダイヤルしました。

— デニス、教えてください、チームがこのスタンドまたはそのスタンドを通過したことをどういうわけか理解することはできますか?
- 確かに。 ベンチ上でビルドが正常にロールアウトされた (テストに合格した) 場合、Jenkins はフラグを破棄します。
- 素晴らしい。 旗とは何ですか?
- これは、「stand_OK」または「stand_FAIL」のような通常のテキスト ファイルで、アセンブリがスタンドに合格したか失敗したかを示します。 まあ、わかりますよね?
-そうですね、そうですね。 アセンブリが配置されているリポジトリ内の同じフォルダーに書き込まれますか?
- はい
— アセンブリがテストベンチに合格しなかった場合はどうなりますか? 新しいビルドを行う必要がありますか?
- うん
- そうですね、ありがとう。 そしてもう XNUMX つの質問: 旗の作成日をスタンドの日付として使用できることを正しく理解していますか?
- 絶対に!
- 素晴らしい!

インスピレーションを得たイワンは電話を切り、すべてがうまくいったことに気づきました。 ビルド ファイルの作成日とフラッグの作成日がわかれば、チームが各スタンドに費やす時間を秒単位で計算し、どこに最も多くの時間を費やすかを理解することができました。

「どこに最も多くの時間が費やされているかを把握し、チームを特定し、そこに行き、問題を掘り下げます。」 イワンは微笑んだ。

明日のために、彼は描画中のシステムのアーキテクチャをスケッチするという課題を自分に課しました。

継続するには...

出所: habr.com

コメントを追加します