タグ付けされた質問 「metrics」

DevOpsは複雑で、文化やプロセスなどの多くの非決定論的な側面を伴います。 DevOpsイニシアチブの成功を測定するいくつかの方法は何ですか？ 彼らが行った投資が実際のドルを返す（または節約する）ことをどのようにビジネスに証明しますか？

24 metrics  roi 

The Phoenix Projectでは、工場見学の1つで、各ワークステーションが人、機械、測定、プロセスの組み合わせであると言われます。結局のところ、人、サーバー、KPI、および指示があります。 ただし、プロセス（サポートチケットのライフサイクルなど）をモデル化するたびに、これを考慮するのに苦労します。 私のワークフローの状態は通常次のとおりです。 ファーストラインアシスタンス Tech / Dev / Moreテクニカルチームアシスタンス コードレビュー テスト中 UAT 展開 これらの各状態のサイクルタイプ、スループット、およびキュー時間を非常に簡単に測定できますが、これがMan、Machine、Methodの概念に正しかったとは思いません。それはイライラして本で示唆されているが、拡張されていないアイデアです... 待機時間は使用率の関数であることがわかっているため、人とサーバー（限られたリソース）の混雑度を監視することが重要です。私の測定を単純な有限状態機械から本の人、機械、方法、プロセスのアイデアに拡張するための定義されたプロセスはありますか？

16 metrics  systems  the-phoenix-project 

私はこれをサポートするために、DevOps変換プログラム内で適切な行動をとろうとしています。 問題とインシデント管理 容量管理 変更およびリリース管理 明確にするために、これらは運用組織に属していた機能であり、現在はアジャイル/ DevOps組織が所有しています。悪い動作を引き起こす既存のKPIは次のとおりです。 根本原因分析までの時間の完了： 不完全なRCAを時間どおりにシステムに取り込むために駆動します。 テスト実行時間： ビジネス価値に関係なく、長時間実行されるテストを無効にします。 クラウドサービスの平均使用率： 計算リソースのオーバーコミットを奨励し、結果として応答時間が遅くなります DevOpsプログラムで適切な行動を促すために使用できる主要業績評価指標は何ですか？

13 culture  metrics  kpi 

Loggregator System Cloud Foundryのドキュメントの概要からFirehoseの定義を見つけました。 Firehoseは、Cloud FoundryデプロイメントからのすべてのイベントデータをストリーミングするWebSocketエンドポイントです。データストリームには、ログ、すべてのアプリケーションからのHTTPイベントとコンテナーメトリック、およびすべてのCloud Foundryシステムコンポーネントからのメトリックが含まれます。Cloud Controllerなどのシステムコンポーネントからのログはファイアホースに含まれず、通常はrsyslog構成を介してアクセスされます。 Firehoseからのデータには、アプリケーションログの顧客情報などの機密情報が含まれている可能性があるため、適切な権限を持つユーザーのみがFirehoseにアクセスできます。 この用語のルーツはどこにあり、なぜそのように呼ばれているのですか？コンセプトは他のクラウド製品やプラットフォームでも同じですか？ この用語を母国語に翻訳すると面白いです。

10 monitoring  metrics  logging 

TL; DR、開発、特に展開の自動化が変更の失敗率を改善することをどのように証明しますか？ 私たちは皆、現在の（主に手動の）手段を使用して、「デプロイメントの失敗」に関するメトリックをキャプチャしようとしています。残念ながら、「失敗」はめったに起こりませんよね？何かがうまくいかないとき、チームは一緒に（通常は英雄的に）問題を修正します（通常はアクセス許可、構成の欠落、ドリルを知っています）。だから...展開がどのように進んだかを尋ねると、答えは「うまくいった」です。 しかし、直感的には、それは良くないことです。2017年の開発状況レポートによると、約31〜45％の「変更失敗率」があります。それは直感的には正しいように聞こえますが、インシデントとして追跡されていますか？いや。通常は検証中にかなり迅速に修正されるためです。実際にデプロイメントをロールバックすることは、はるかにまれです。 したがって、故障率を正確に報告するには規律が必要です。私たちは物事が機能することを望んでおり、それを実現するために必要なことをしているので、そのように報告することに無関心です。 では、開発、特に展開の自動化が変更失敗率を改善することをどのように証明しますか？ （PSはこれに「＃devops-capability-model」のタグを付けようとしました）

9 metrics 

データをキャプチャして平均修復時間（MTTR）メトリックの測定を開始する最良の方法を理解しようとしています。「ロールバック」がMTTRにプラスまたはマイナスの影響を与える方法に頭を抱える必要があります。 シナリオ1 堅実な監視が行われていると仮定すると、インシデントを比較的迅速に検出する（MTTIが低い）コードがデプロイされます。識別の時点で、2つの主要な可能なパスがあります（そうです、私は議論の目的で過度に単純化しています）。 デプロイメントをロールバックし、安定性をすばやく戻しますが、本番環境では意図した機能はありません。 インシデントを解決し、意図された機能をライブに保つ追加の変更をロールフォワードします。 このscenaroでは、サイトの安定性がすぐに回復する可能性があるため、MTTRはかなり低くなっています。とはいえ、意図した変更の結果は有効ではないため、コード/機能/変更はまだ進行中です。目標が低いMTTRである場合、回復メカニズムとしてロールバックを奨励するように見えます。 シナリオ2 このシナリオでは、MTTRは、予想されるコード/機能/変更が本番環境で適切に機能するのにかかる時間によって厳密に測定されます。ロールバックしても、「修正済み」のコード変更が製品化されるまで、MTTRタイマーはまだ実行中です。この場合、MTTRは単なる「ちょっと、物事は安定している」のではなく、ビジネス結果の安定性に結びついているようです。 さて、答えはMTTRが真空での指標として使用されていないのと同じくらい簡単かもしれませんが、むしろ変更失敗率と組み合わせて-頻繁なロールバックによって引き起こされる超低MTTRは、非常に高い変更失敗率を指す可能性があります。とは言っても、MTTRの測定値をビジネスの成果から切り離すという考えでは、私には正しくないように思われることがあります。 私はこれをかなり考えすぎているかもしれませんが、他の人がどのようにMTTRを測定しているか、および「回復」の最終時点は何であるかについて知りたいです。それを単に安定性として使用していますか、それとも他の要因が「回復」の意味を決定するのに使用されていますか？

8 metrics