各参加者は、会議のために、実装する価値があると思われる特定のメトリックのリストを準備しました。
Ivanはレポートを聞いて、提案されたメトリックの数を計算しようとしました。5.10、再び10、さらに約12個です。 何かで30になりました。
なんらかの理由で、人々はただグーグルで集まり、彼らにとって興味深いと思われる名前を書き出すというアイデアが突然生まれました。 どうやら、メトリックの本質について誰も考えなかったようです。
側面から見て、イヴァンは自分に質問をしました：なぜですか？ 正確にこれらのメトリックスを使用する理由 彼らはあなたに何を与えますか？ ミーティングは、メトリクスの本質についての本当の理解からほど遠い人々を集め、膨大な時間を失い、ゴミをゴミ箱に捨てることで、すべてが通常通り終了することを突然明らかにしました。
それは悲しくてin辱的になりました。 会社の時間とお金がどこにも行き渡らないのは残念だし、役に立つビジネスが終わらないのは残念だ。
Ivanは長い間測定基準を研究しており、このトピックは非常に深刻で複雑であり、いずれにしてもディンギー湾からアプローチすることは不可能であることを長い間理解してきました。
その日、会議はすべて終了し、何もありませんでした-彼らはすぐにすべてを実装することにしました（他の人がこれらのメトリックを必要とする理由を理解できなかったため、誰も拒否の責任を取りたくありませんでした）。
Ivanは、DevOpsメトリックのビジョンを準備し、各メトリックがその中で正当化され、特定の目的があり、有用で理解されていることを確認することにしました。
それは彼がやったことです...
何を管理しますか？
まず第一に、Ivanはメトリクスが作成される主な目標について考えることにしました。
リーンアナリティクスとタオトヨタプラクティスのよく読まれた本は、あなたがコントロールしたい数字をメインメトリックとして選択することを提案しました。 次に、メトリックとして影響を与えることができるこの数のコンポーネントを選択します。
前回の会議でのDevOpsの目標は「ソフトウェア品質」を宣言しましたが、品質の概念は非常にあいまいでした。 品質とは？ 1つの数字で表現する方法は？ どのコンポーネントが影響しますか？
残念ながら、ソフトウェアの品質を1つの数字で表すことはできません。
とにかく、品質は本当にDevOpsを使用する目的ですか？
数年前、Ivanは自分のソフトウェアを製造している小さな会社のITディレクターとして働いていました。そこで彼はDevOpsの立ち上げと使用に成功しました。 そして、このDevOpsの目的は、まったく品質ではありませんでした。 むしろ、品質も。 主な唯一の目標は、プロムでの展開中の手作業を排除することでした。
手作業を排除することで、彼はそのような加速とエラー数の削減を達成し、少なくとも1分間に1回改善をリリースできるようになりました。
したがって、 ターゲットメトリックDevOps自体がそれ自体を示唆していることが判明しました。
納期
管理職の意思決定の効果を示すのは、まさにその増減です。
納期（Time To Market、TTM）が増加しました-不十分です。 減少-すばらしい。
しかし、納期はタスクの量、テストの期間、および他の多くの要因に依存します！ はい、そうです。
そして、それが、Ivanが意図的にエンコードと分析の瞬間からではなく、アセンブリ（配布）が既に作成され、ストレージにあり、残っているすべてが産業環境（いわゆる連続配信、CDL）。
ここでは、コーディング、アセンブリ、およびその他のすべての開発手順もCDLステージと同様に配信時間に影響するため、最初に原則、概念、イヴァンが考えた他の未到達領域にさらに拡張することが重要です。 一方でそれをやってみましょう-もう一方でそれをします。
Ivanが働いていた大企業では、メトリックが不可欠でした。 何千人もの開発者がコードを見て、何百ものアセンブリが毎日作成されましたが、DevOpsにチームが実際にどれだけの時間を費やしているかは誰も知りませんでした。
あらゆる側面から苦情が寄せられました。DevOpsはゴミであり、機能しません。ひどく遅くなり、役に立たないのです。 しかし、誰も実際の数字を手にしておらず、チームの声明を証明または反論することは単に不可能でした。
チームがDevOpsに費やす時間、特にアセンブリの提供段階に費やす時間を計算することが、この目標でした。
Ivanは、DevOpsを一度起動してすぐに効果が得られた場合、これは不可能だと考えています。なぜここにないのでしょうか。
メトリックのシステムを作成することは、Ivanにとって名誉の問題となっています。
制御できるものを制御する
配達時間を管理する方法は？ これは可能ですか？ -イヴァンに尋ねた。
配信時間を数値として考えると、DevOpsプロセスにこの数値に大きな影響を与える場所があることが明らかになります。
Ivanの会社には標準がありました。プロムに行く前の各アセンブリは、ソフトウェアのさまざまな側面がテストされた3つのテストベンチを通過するはずでした。
当然、それらのアセンブリはエラーのために「落ち」、代わりに新しいアセンブリが作成されました。
スタンドが総配達時間の重要な要素であり、総時間に影響を与えて増加させるのはそれらであることが判明しました。
配達時間=スタンド1の時間+スタンド2の時間+スタンド3の時間
各スタンドでチームが費やす時間に影響を与えることにより、最終納期に影響を与えることが可能になります。
2つの簡単な質問が残りました。
- スタンド上のチームのコストを物理的に計算する方法と
- スタンド間のダウンタイムをどうするか（ダウンタイムも納期の要素です）？
IvanはJenkinsとNexus（CDLで使用されるソフトウェア）のジャングルに飛び込むしかありませんでした。
JenkinsとNexusのヘルプ
スタンド上の「ロール」アセンブリは、ジェンキンスを使用して実行されました。 実際、Jenkinsはcrontabのような通常のシェダーですが、高度な機能を備えています。
Jenkinsは実行中のすべてのジョブ（スタンドでアセンブリをローリングするためのタスク）のログをRSSの形式で表示する方法を知っており、開始時刻、終了時刻、特定のアセンブリへのリンクがあります。
イヴァンの自由裁量で、組立作業の開始と終了の正確な時間に関するデータが得られたことが判明しました。 スタンドでチームが費やした正味時間を計算するために、秒単位で簡単かつ正確に計算することができました。
また、すべてのスタンドからのデータが1つのデータベースにダンプされた場合、スタンド間のダウンタイムを計算できました。 すごかった！
Nexus（ネットワークファイルストレージ）から、Ivanはアセンブリ自体の作成日などを取得しようとしていました。 その出現の瞬間と基準点を決定します。
すべてが所定の位置に収まりました。 ほぼ。
-そして、これをどのように管理するか、イヴァンは考えましたか？..
継続する。 影響の対象