Infrafin

基準

私たちは各チームができるだけ効率的であることを望んでいますが、個々のサーバーや少数のサーバーを立ち上げている各担当者と話し合うことは、スケーラブルでも現実的でもありません。そのため、個々の担当者が自分のリソースを価格見積もりできるよう学習リソースを提供し、infrafin ボードの一部と見なすための以下の最低要件を定義しています。Issue が以下の基準のいずれかを満たし、かつ私たちの管理範囲内（可視化できる中央請求の一部）にある場合、潜在的な infrafin Issue として追加できます。

• Issue の影響（現在または近い将来）が四半期当たり $10K 以上
• Issue が現四半期の OKR の一部である
• 四半期当たりのコストが $10K 未満であっても、特定のチームやサービスで前月比コストが不明または計画外の理由で 2 倍になっている場合

優先度付け

infrafin Issue の重み付けは RICE フレームワークに似た方法で行いますが、以下の 4 つの要因を重み付けの一部として考慮します。重みを合計した後、4 で割ることで全重みを 0〜10 に正規化します（10 が最も重要または影響力が大きい）。

重み要因

コスト削減

四半期ベースで Issue を解決した結果として得られる削減額の指標です。この指標は、GCP プロジェクト間およびベンダー間で一貫した重み付けを維持するため、常に割引前の金額で計算してください。

顧客への影響

アプリケーションへの本番変更が必要な場合の変更による潜在的な悪影響を捉えるための要因です。infrafin Issue が顧客にとって有益な影響をもたらす場合もありますが、これは悪影響のみを捉えることを目的としているため、大きくても有益な顧客への影響は低い顧客影響として重み付けしてください。

将来の潜在的コスト影響

Issue を解決するために何も行わない場合に発生する将来のコストの指標です。この指標は、GCP プロジェクト間およびベンダー間で一貫した重み付けを維持するため、常に割引前の金額で計算してください。この指標は通常かなり投機的ですが、コストの増加や、不要なサーバーの場合にはこれらの問題に対処しないことの将来のコストを捉えることを目的としています。

必要な工数

この要因は、Issue を解決するために必要な時間と労力の一般的なタイムラインを捉えます。

Infrafin ボード

短期節約イニシアティブのプロセス

一部の節約イニシアティブは、緊急性のためか、またはインフラ部門内のみで実装を処理できるためか、はるかに短い時間軸で実現できます。これらの例としては、GCP の CUD 購入、または AWS Savings Plan の購入による全社的なサーバーコストの最適化、あるいは時間の経過とともに見られる特定の請求異常の調査と修正などがあります。

1. 初期データ探索

このシナリオでは、Issue はすでに判明しています（以前のデータ探索やその他の作業により判明している可能性があります）が、これらの Issue をより深く理解するためのデータ探索が通常まだ必要です。

2. 初期コスト影響分析

当該 Issue の影響を定量化します。

3. SME の特定とパートナーシップ

その分野の SME（Subject Matter Expert）と協力して、Issue をどのように解決できるかを見つけます。SME が不明な場合は、infra analyst が Infra PM と協力して適切な人物を特定します。

4. Issue の解決

短期イニシアティブとしてカテゴリーされる性質上、これらは比較的低工数で高インパクトなイニシアティブであるべきであり、一般的にはできるだけ早く完了させる必要があります。これらの Issue の重みは自動的に 7 に設定されます。

5. フォローアップ

変更が行われた後、数値が期待値に近いことを確認します。

長期節約イニシアティブのプロセス

これらは、クロスチームコラボレーションとサービスやインフラの大規模な変更が必要なイニシアティブです。例としては、オンラインレジストリのガベージコレクションの実装、内部 CI 使用量の最適化、主要サービスのマシンタイプやストレージタイプの変更などがあります。

1. 初期データ探索

問題領域がよく理解されていない場合、これらのイニシアティブの一つを発見するための最初のステップは、インフラのマクロビューを取って、現在どこに最も多くのお金を使っているか、それがどの程度速く増加しているか、そして将来どこにより多くのお金を使うことになるかを理解することです。 これは利用可能なツールを使用して行うことができますが、現在は主に様々なベンダーの請求コンソールに入って支出がどこに向かっているかをより深く理解することで行われています。

イニシアティブがすでによく理解されている場合は、ステップ 1〜2 をスキップしてステップ 3 に直接進むことができます。

2. フォーカス領域の決定

取り組む Issue を決定する際に考慮すべき多くの要因がありますが、私たちの重み付けシステムと一致する主な要因を重要度の高い順に示すと:

• コスト
• 将来の潜在的コスト
• 顧客への影響
• 必要な工数

このデータを比較しやすくするためにまとめる方法があります。例えば、特定のディメンションに関する加重 MoM（月次）成長指標を使用して、支出額が高く急速に増加し続けている領域を確認するなどです。

3. 初期コスト見積もり

フォーカスする領域が選択されたら、コストを最適化するための変更や実装についての提案を作成し、その費用見積もりを作成できます。これが四半期節約ラベルとなり、これは Infra Analyst として行う主なステップであり、財務部門と PM がどのように Issue を優先付けしたいかを理解するための良い基礎を提供します。

Infra Analyst は SME と協力して、前提条件が明確に定義されており、前提条件を踏まえた見積もりが妥当であることを確認してください。

4. SME による工数と顧客影響の見積もり

分析中のサービス/領域の SME が、この解決策の実装がどれほど困難で時間がかかるか、および何人の顧客に影響を与えるかを決定します。SME は必要に応じて infra analyst と協力してこれらの見積もりを作成できます。

SME が特定できない場合は、Infra Analyst が infra PM と協力して適切な人物を特定できます。

5. 優先度決定

Infra PM が Issue を受け取り、infrafin 項目のコンテキストにおける優先度に応じて、他のチームのロードマップやマイルストーンのどこに位置付けるかを決定します。

Issue の重みが 7 を超えている場合（かつ短期イニシアティブではない場合）、infra PM はプロジェクトのエグゼクティブスポンサーを取得することも検討してください。

6. フォローアップ

完了後、変更の実際の影響と今後の期待値を分析します。

Infrafin イニシアティブと FP&A

一部の infrafin イニシアティブは財務計画に含まれる場合があります。この例はベンダーローリング予測スプレッドシートの節約タブで確認できます。これに含まれるイニシアティブの基準は非常に厳格で、比較的正確な節約数値を持って期限通りに完了することが期待されます。ready_for_plan_ ラベルは infra analyst がイニシアティブの承認が得られ、次の予測に含める準備ができていることを指定するために使用でき、in_plan は実際に予測の一部として含まれた場合に使用できます。

予測に含まれるための基準

• infra PM と必要に応じて関連する stage PM の両方から承認を得た確固たる期日が設定されている
• 節約数値への信頼度が 50% 超
• Issue に ready_for_plan ラベルが付いており、推定実際節約額が記載されている。これは関連する割引と予測にすでに含まれている重複する節約をもたらす可能性のある他のイニシアティブを考慮した数値であることを意味します

ラベル付け

• infrafin

infrafin ボードに Issue を追加するために使用します

• Savings-Estimate

イニシアティブの四半期節約の見積もりです。節約ラベルは割引が適用される前、および数値に影響を与える可能性のある他のイニシアティブを無視した状態であるべきです。これにより、優先度付けのために各イニシアティブの一貫した独立した節約見積もりラベルが得られます

• ready_for_plan

Issue が上記の基準を通過し、予測に見直しおよび追加する準備ができたら使用します

• in_plan

イニシアティブが予測に含まれたら使用します

ページのソースコードを見る - ページの編集 - please contribute.