ほとんどのFinOpsストーリーは、使われていないインスタンスのヒートマップから始まり、「20％節約できました」という勝利の言葉で終わる。素晴らしい。
しかし、来月、"クイックウィン "でSLAが破られたり、運用チームが本番稼動中のすべてのコアがレッドライン化され、無意味な作業をしていることに気づいたりしたらどうなるだろうか？
現代のクラウド・コスト管理に共通する3つの盲点へようこそ：
- ブラントアックス（鈍い斧） - 高価そうなものは何でも、なぜそのような構造になっているのかを聞かずに斬りつける。
- 効率性の錯覚- 稼働率が高いのでワークロードは健全であると考えるが、その稼働率のほとんどは顧客価値を生み出していない。
- 局所最適の幻想
個々のコンポーネントを改善すれば、自動的にシステム全体が改善されると仮定する。複雑なシステムでは、局所的な最適選択が全体的な損失になることがある。実話：あるスプリントで、開発者専用のクラスタを月200万ドル削減したことがある。同じエンジニア工数で、月5万ドルの新規MRRが見込まれる機能を出荷できたはずだ。この最適化は「元は取れた」のだが、25倍の機会費用がかかった。
Intent-aware FinOpsはその両方に取り組んでいる。
インテント・アウェアFinOpsを一言で表すと？
各ドルがどの建築の約束を守るのかがわかるまでは、決してクラウド法案に手を出してはならない。
レイテンシー目標、リカバリ目標、コンプライアンスルール、市場投入までの時間はすべて約束事としてカウントされる。もし最適化がこれらのどれかを脅かしたり、よりROIの高い仕事から注意をそらしたりするなら、それは勝利ではない。
効率という幻想：忙しい＝価値があるとは限らない
高い稼働率はダッシュボード上では素晴らしく見えるが、膨大な無駄を覆い隠してしまう可能性がある。ここでは、私たちが実際に見た3つのケースと、ワークロードを修正することがどのようなインスタンスの微調整よりも優れているのかを紹介する：
Sparkのジョブが毎晩70 %のCPUで4時間止まっている
効率的に見えたのは、クラスタがノードを忙しくさせていたことだ。
現実：データの80％が1つの歪んだキーに固定され、はぐれタスクが永遠に実行されたままになっていた。
ワークロードを修正する：そのキーを再分割し、ソルト化する。この作業は3分の1のサイズのクラスタで45分で終了した。
85%のIOPSをプッシュするデータベース
効率的に見えたのは、RDSインスタンスが "フル活用 "されていたことだ。
現実：2つの重要なインデックスが欠落していたため、すべてのクエリがフルテーブルスキャンを行っていた。
ワークロードを修正：インデックスを追加。レイテンシは10倍に減少し、DBは2つのサイズをシフトダウンすることができた。
GPU推論フリート、稼働率60％で推移
効率的に見えたもの：値段の高いA100はいつも混んでいた。
現実：モデルは小さく、リクエストは一度に1つずつ処理され、呼び出しの間はGPUがアイドル状態になっていた。
ワークロードを修正：32リクエストをバッチ処理（またはCPUベースのInferentiaに移行）。予測単価が激減。
いずれのケースも、ライツサイジングだけでも請求額を少しは削減できただろうが、最初にワークロードを修正することで、より大きな節約とパフォーマンスの向上が実現した。
インテント・アウェアFinOpsの4つの柱
コンテキストをキャプチャする
すべてのコストラインを、ワークロード、オーナー、ビジネスKPI（リクエストあたりの収益、構築時間の短縮、コンプライアンス要件の達成）に結びつける。数字が重要なのは、意味のあるストーリーを語る場合だけだ。
意図を訊ねる
それぞれのリソースについて、こう尋ねる：これはどの約束を果たすのか？マルチAZレプリカは停止中の収益を保護します。完全忠実なログは5分間のMTTRを保証する。もし誰もその約束を覚えていなければ、そのリソースは本当にオプションなのかもしれない。
ワークロードを固定化し、次にライツサイズを行う
ポーリング・ループ、インデックスの欠落、おしゃべりなデバッグ・ログなど、設計の無駄を探しましょう。その無駄を取り除けば、通常はパフォーマンスが向上し、コストも下がる。その後で初めて、リサイズ、スケジューリング、廃止を行う。
安全に最適化し、文書化する
ガードレール（SLA、セキュリティ階層、コンプライアンス義務）の背後にある変更を自動化し、新しい意図を記録する。来四半期のFinOpsレビューはゼロから始めるべきでない。
実践的なプレイブック
- ビジネスKPIによるベースライン-コストと顧客向けの指標を追跡します。チェックアウトの待ち時間が安定している一方で、トランザクションあたりのコストが低下していれば、勝利です。
- APMトレース、クエリプラン、タスクレベルのメトリクスなど、あらゆるものを計測する。利用率だけでは設計の欠陥を明らかにすることはできない。
- ワークロード・レビューの実施- エンジニアとFinOpsの実務家をペアにする。尋ねるのだ：このジョブが半分の頻度で実行されたらどうなるか？ なぜこのサービスにGPUが必要なのか？
- 可逆的な変更の自動化- ツール（DoiT Cloud Intelligence™を含む）を使用して、ワンクリックでロールバックできるスケジュール、タグ付け、ポリシーの適用を行います。
- 書き留める- レポやWikiの短い「意図」メモは、部族的な記憶に勝る。将来のコストレビューには、その文脈が必要だ。
DoiT Cloud Intelligence™はどのようにIntent-Aware FinOpsをサポートしているのか？
私たちのプラットフォームは、支出、パフォーマンス、信頼性のシグナルを関連付け、「なぜ」を問うスペシャリストとペアリングします。私たちは共に
- 利用率グラフではなく、コストとアウトカムをリンクさせることで「効率の幻想」を暴く。
- ロードマップの速度に対するトレードオフを示すことで、「局所最適の幻想」にフラグを立てる。
- 最も重要な約束を保護または強化する場合にのみ、修正を自動化する。
お持ち帰り
低額な請求書も、顧客が離反したり、機能のベロシティが停滞すれば意味がない。インテントを意識したFinOpsは、目標を「支出を少なくする」から「約束を守る、あるいは成長させることにのみ支出する」に転換する。それは時に、ノイズの多いワークロードをリファクタリングしてからライトサイジングすることを意味する。
時には何もせず、次の顧客を獲得する機能を出荷することもある。難しいのはテコを選ぶことではなく、システム全体に役立つテコを選ぶことなのだ。
