正直に言うと、イワンは監視部門の同僚たちの無駄な努力をよく笑いました。 彼らは、会社の経営陣から達成するように命じられた指標を実装するために多大な努力をしました。 彼らはとても忙しかったので、他の人に何もしてほしくありませんでした。
しかし、経営陣にとってはそれだけでは十分ではありませんでした。彼らは常に新しい指標をどんどん注文し、以前に行われていた指標の使用をすぐにやめてしまいました。
最近、ビジネス機能を提供する時間であるリードタイムについて誰もが話題にしています。 この指標は、200 つのタスクを完了するのに XNUMX 日というとんでもない数字を示しました。 なんと誰もが「ああ」と歓声を上げ、空に手を上げたのです！
しばらくすると、ノイズは徐々に静まり、経営陣は別の指標を作成するよう命令を受けました。
新しい指標もまた、暗い隅っこで静かに消えていくだろうということは、イヴァンにとって完全に明らかでした。
確かに、その数字を知っても誰にも何も伝わらない、とイワンは思いました。 200日か2日かは違いはありません。数字で理由を判断し、それが良いか悪いかを理解することは不可能だからです。
これは計量の典型的な罠です。新しい計量が存在の本質を伝え、何らかの秘密を説明するように思えます。 誰もがこれを非常に期待していますが、何らかの理由で何も起こりません。 はい、秘密はメトリクスに見つかるべきではないからです。
イワンにとって、これは通過した段階でした。 彼はそれを理解しました 測定のために、そしてすべての秘密を探さなければなりません 、つまりこの指標が形成されるということです。
オンライン ストアの場合、影響力の対象となるのは資金をもたらしてくれる顧客であり、DevOps の場合、パイプラインを使用してディストリビューションを作成および展開するチームになります。
ある日、Ivan は、ホールの快適な椅子に座って、影響の対象がチームであるという事実を考慮して、DevOps メトリクスをどのように確認したいかを慎重に考えることにしました。
DevOps メトリクスの目的
誰もが納期の短縮を望んでいることは明らかです。 200日ではもちろんダメです。
しかし、どうやって、それが問題なのでしょうか？
同社は数百のチームを雇用しており、毎日数千のディストリビューションが DevOps パイプラインを通過します。 実際の納期は分布として表示されます。 各チームには独自の時間と独自の特徴があります。 この混乱の中からどうやって何かを見つけることができるでしょうか？
答えは自然に生まれました。問題のあるチームを見つけて、何が起こっているのか、なぜこれほど時間がかかるのかを解明し、すべてを迅速に行う方法を「良い」チームから学ぶ必要があります。 これを行うには、各 DevOps スタンドでチームが費やした時間を測定する必要があります。
「このシステムの目的は、チームがスタンドを通過する時間に基づいてチームを選択することです。 その結果、数値ではなく、選択した時間を含むコマンドのリストが取得されるはずです。
スタンドで合計どれくらいの時間が費やされ、スタンド間の休憩にどれだけの時間が費やされたのかが分かれば、チームを見つけて電話をかけ、より詳細に理由を理解してチームを排除できる」とイワン氏は考えた。
DevOps の納期を計算する方法
これを計算するには、DevOps プロセスとその本質を掘り下げる必要がありました。
会社が使用しているシステムの数は限られており、情報はそこからのみ入手でき、他の場所からは入手できません。
社内のタスクはすべてJiraに登録されていました。 タスクが引き受けられると、そのタスク用にブランチが作成され、実装後に BitBucket と Pull Request へのコミットが行われました。 PR (プルリクエスト) が受け入れられると、ディストリビューションが自動的に作成され、Nexus リポジトリに保存されます。
次に、Jenkins を使用してディストリビューションをいくつかのスタンドに展開し、ロールアウトの正確性、自動および手動テストをチェックしました。
Ivan は、スタンドでのタイムを計算するためにどのシステムからどのような情報を取得できるかを説明しました。
- Nexus から – ディストリビューションの作成時刻とコマンド コードを含むフォルダーの名前
- Jenkins から – 各ジョブの開始時刻、期間と結果、スタンド名 (ジョブ パラメーター内)、ステージ (ジョブ ステップ)、Nexus のディストリビューションへのリンク。
- Ivan は、Jira と BitBucket をパイプラインに含めないことを決定しました。 それらは開発段階に関連しており、完成した配布物をスタンドで展開することには関係していませんでした。
入手可能な情報に基づいて、次の図が作成されました。
ディストリビューションの作成にかかる時間と、ディストリビューションのそれぞれに費やされる時間がわかれば、DevOps パイプライン全体 (フル サイクル) の総コストを簡単に計算できます。
Ivan が最終的に得た DevOps 指標は次のとおりです。
- 作成されたディストリビューションの数
- スタンドに「来た」分配金とスタンドを「渡した」分配金の割合
- スタンドに費やした時間（スタンドサイクル）
- フルサイクル (すべてのスタンドの合計時間)
- ジョブ期間
- スタンド間の休憩時間
- 同じスタンドでのジョブ起動間のダウンタイム
メトリクスは、時間の観点から DevOps パイプラインを非常によく特徴付ける一方で、非常に単純であると考えられていました。
仕事の出来に満足したイワンはプレゼンテーションを作成し、経営陣に提出しに行きました。
彼は暗い表情で両手を下げて戻ってきた。
「これは大失敗だよ、兄弟」皮肉な同僚は微笑んだ...
詳細は記事をご覧ください。'。
出所： habr.com