May 5, 2026 · 469 words · 3 min read

14. プロダクトとしての自動化#

チームの仕事に対する考え方を変えることになったその会話の6ヶ月前、ネットワークプラットフォームチームは本当に印象的な成果を上げていた。2年間の継続的な努力により、ブランチのオンボーディングをエンドツーエンドで処理するプロビジョニングプラットフォームが完成していた。サイトリクエスト用のセルフサービスインターフェース、デプロイ前に設定ミスを検出するクローズドループ検証ワークフロー、そして300拠点全体のサービス健全性を追跡する運用ダッシュボードが揃っていた。チームは24時間の変更ウィンドウから40分の自動デプロイへと進化させた。彼らはそれを誇りに思っていたし、誇りに思うべきだった。

そこへ事業開発チームが小売チェーンの買収を完了させた。120の新規店舗が6ヶ月以内にネットワーク接続を必要としていた。インフラ担当リードがシンプルなメールを送ってきた。「この件は自動化プラットフォームを頼りにしている。どうすれば開始できるか？」

ネットワークプラットフォームチームの最初の内部反応は自信に満ちていた。これは自動化できる。ワークフローがある。テンプレートがある。ツールは実績がある。

しかし、メールに返信しようとしたときの2回目の反応は自信を欠いていた。インフラ担当リードは自動化が技術的に可能かどうかを聞いているのではなかった。彼らは別の質問をしていた。店舗オンボーディングのSLAとは何か、つまりサイト情報が提出されてから店舗が接続を受けるまでのコミットメントは何か？デプロイが途中で失敗した場合のエスカレーションパスは誰か？インフラ担当リードのチームが、ネットワークチームに直接尋ねることなく監視できるステータスページやダッシュボードはあるか？プラットフォームのキャパシティはどうか、20件の同時デプロイを処理できるか、それともリクエストをバッチ処理する必要があるか？そして最も不快な質問：プラットフォームインシデント中にオンボードされた店舗はどうなるか、自動的に修復されるか、それとも誰かが各店舗を監査する必要があるか？

ネットワークチームには自動化があった。しかし答え（ビジネス/プロダクトの観点での）がなかった。

このギャップ、つまり「動く自動化を構築した」と「他のチームが依存して計画を立てられるサービスを提供する」との間の差が、本章のテーマである。

これは私が情熱を持っているトピックだ。Autocon3で行ったセッションでは、設計主導の自動化の観点からこれを扱っており、本章の補足参考資料となっている。

14.1 ケイパビリティからプロダクトへ#

第13章では、チームが自動化を組織的ケイパビリティとして構築するために、人材、役割、仕事の進め方をどのように変革するかを説明した。その変革は必要だ。しかしそれだけでは不十分だ。

ケイパビリティとはチームができることだ。プロダクトとは、他のチーム（またはいずれはサードパーティのエンティティ）が依存できるものだ。その違いは技術的な品質についてではない。小売チェーンオンボーディングプラットフォームは技術的に優秀だった。違いは、プロバイダーとコンシューマーの関係にある。ケイパビリティはその作者のために存在する。プロダクトはそのユーザーのために存在する。

ネットワークチームのアウトプットは変化した。自動化以前のアウトプットはデバイス設定だった。プロビジョニングされたルーター、拡張されたVLAN、適用されたACL。そのアウトプットのコンシューマーはデバイス自身であり、成功の証拠はpingが通ることや、アプリケーションが動作することだった。自動化によってアウトプットは変わる。ネットワークチームのプロダクトは、他のチームが消費するネットワークサービスになる。ネットワークとのすべてのインタラクション、ブランチサイトのプロビジョニング、新しいアプリケーション向けのセグメント拡張、セキュリティポリシーの適用、VLANへの会議用アクセスの一時付与、インターネットエクスチェンジでのピアリング接続の追加、これらはすべて変更チケットではなくサービスリクエストになる。デバイス設定は実装の詳細だ。サービスがアーティファクトだ。

これが**ネットワークサービスをプロダクトとして (Network Service as Product)**パターンだ。サービスがプライマリのアーティファクトであり、下層のネットワークは実装だ。これはソフトウェアエンジニアリングでは新しくない。APIはインフラを抽象化し、呼び出し元はどのサーバーがリクエストを処理するかを知らないし、気にしない。しかし、これは歴史的にデバイス、ベンダー、プロトコルを中心に仕事を整理してきたネットワークチームにとっては大きな転換だ。ルーター設定スキルにアイデンティティを定義してきたエンジニアが、今やサービスデリバリーケイパビリティにアイデンティティを定義するよう求められている。このリフレームは第13章セクション13.1の職人のジレンマに直結する。古いクラフトの専門家こそが、最も急いでリフレームを行う必要がある人物であり、それを完全に実行するエンジニアはより価値が下がるのではなく、より価値が上がる。

このプロダクトの技術的な拠点は、第8章で説明したプレゼンテーションブロックだ。セルフサービスインターフェース、APIサーフェス、Webhook統合、ロールベースのアクセスモデル、これらはサービス契約がコンシューマーに見える場所だ。第14章では、技術的なインターフェースを超えて、それを取り巻く組織的・ビジネスモデルにズームアウトする。インターフェースにはどんなコミットメントが伴うか？壊れたときは誰が所有するか？サービスはどのように進化するか？次に何をするかは誰が決めるか？

14.2 プロダクトの定義#

ネットワーク自動化をサービスに変えようとするチームに一貫して現れる2つの失敗モードがある。

1つ目は過剰露出だ。インターフェースが実装の詳細を露出させ、コンシューマーがそれを使うためにネットワークの内部を理解しなければならない。VLAN ID、サブネットマスク、OSPFエリア番号を要求するブランチプロビジョニングサービスはサービスではない。ウェブフォームを持つCLIだ。小売チェーンの設備コーディネーターは、OSPFエリアが何であるかを知らないし、知る必要もない。

2つ目は過剰制限だ。インターフェースがネットワークチームが想定した正確なユースケースしか処理できないほど制約されている。テンプレートから逸脱したリクエストには例外プロセスが必要だ。恒久的な小売拠点とは異なる接続要件を持つ期間限定のポップアップストアをプロビジョニングする必要がある設備コーディネーターは、セルフサービスできない。チケットを提出する。チケットはネットワークチームに届く。自動化のメリットがそのコンシューマーに届いていない。

**サービス契約パターン (Service Contract Pattern)**は、インターフェース定義を明示的、バージョン管理済み、意図的に境界設定することで、両方の失敗モードを解決する。サービス契約には3つのコンポーネントがある。

インプットサーフェス: コンシューマーが提供するもの。ネットワーク用語ではなくビジネス用語で表現される（申し訳ないが、これは重要なことだ）。ブランチサイトリクエストは、ロケーション名、物理的な住所、サイト階層（標準、スモール、ポップアップ）、および有効化日を受け取る。VLAN IDは受け取らない。この契約はビジネスの意図をネットワークの実装に内部で変換し、その変換が自動化プラットフォームの責任だ。階層の定義は永続的ではない。一時的な小売キオスク向けに定義されたポップアップ階層は、異なる接続要件を持つポップアップイベントスペースには対応しない。インプットサーフェスは、コンシューマーチームと同じケイデンスでロードマップとともにレビューされなければならない。そうすることで、階層が最初に契約が書かれたときにネットワークチームが想定したユースケースではなく、実際のユースケースを反映するようになる。
アウトプットサーフェス: コンシューマーが観察するもの。成功した完了と失敗の両方を含む。適切に設計されたアウトプットサーフェスは「ステップ14のうち7番目でデプロイ失敗：gNMIプッシュがエラーコード400で拒否されました」を露出させない。「有効化失敗：このアドレスの物理回線がまだキャリアによってプロビジョニングされていません。予想完了日：[SoTからの日付]。あなた側のアクションは不要です。回線がオンラインになったときにシステムが自動的に再試行します」を露出させる。自動化は単に成功や失敗するだけでなく、コンシューマーが理解できる用語でオブザーバブルなライフサイクルイベントを発行する。
内部依存関係: サービスが内部で追跡するもの。コンシューマーには見せないが、チームは管理しなければならない。キャリアからの回線状態。このサービスとインフラを共有している隣接サービス。新しいサイトのSoTレコードと自動監視を駆動するインベントリレコードとの整合関係。回線がキャリアメンテナンスに入ったとき、ネットワークチームはどのサービスが影響を受けるか、それがどんなSLO露出を生み出すかを知る必要がある。コンシューマーはサービスへの影響を知る必要があるかもしれないが、それを引き起こした実装の詳細を知る必要はない。

flowchart LR
    classDef consumer fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef contract fill:#f5e8d9,stroke:#a57a4a,color:#1a2e3b
    classDef internal fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b

    subgraph Consumer["コンシューマーインターフェース"]
        IN["インプットサーフェス<br/>ロケーション、階層、日付<br/>ビジネスの意図"]
        OUT["アウトプットサーフェス<br/>ステータス、ライフサイクルイベント<br/>ビジネス言語"]
    end

    subgraph Contract["サービス契約"]
        TRANS["変換レイヤー<br/>意図から実装へ<br/>VLAN、サブネット、OSPFエリア"]
    end

    subgraph Internal["内部依存関係"]
        CIRC["回線状態"]
        SOT["SoT整合性"]
        NEIGHBOR["隣接サービス"]
    end

    IN --> TRANS
    TRANS --> OUT
    TRANS --> CIRC & SOT & NEIGHBOR
    CIRC & SOT & NEIGHBOR -.-> OUT

    class IN,OUT consumer
    class TRANS contract
    class CIRC,SOT,NEIGHBOR internal

サービス契約が定義されたら、次の問いはそれが時間とともにどうなるかだ。

ライフサイクルの問いは、多くのチームが投資不足となる部分だ。サービス契約はプロビジョニングの瞬間についてだけではない。下層インフラが変更されたとき、このサービスはどうなるか？スケジュールされたキャリアメンテナンスに入ろうとしている回線上で動作するブランチサイトには、予想されるSLO影響がある。その影響を誰が把握し、小売チェーンの運用チームに通知するかどうかを誰が決め、メンテナンスウィンドウが超過した場合の連絡を誰が所有するか？これらの問いは、サービスをSource of Truthにおけるファーストクラスのエンティティにすることを要求する。

第4章のSoTは、意図をネットワークがあるべき姿の権威ある記録として説明している。プロダクトモデルにおけるサービスは、その意図を上方に拡張する。ネットワーク要素がどのように見えるべきかだけでなく、それらの要素がどのようなビジネス機能を誰に提供しているかだ。デバイスと回線をモデル化するが、サービスをモデル化しないSoTは、「この回線メンテナンスでどの小売店舗が影響を受けるか？」という問いに答えられない。サービスアウェアな変更管理を可能にする依存関係マップを生成できない。第7章のオーケストレーションブロックは、修復を調整する際にこの依存グラフに依存する。回線障害に対応するクローズドループワークフローは、通知をルーティングし適切な回復シーケンスをトリガーする前に、どのサービスが影響を受けるかを知る必要がある。

これはまさに第4章セクション4.2.2が設計主導のビルディングブロックとして形式化した抽象化だ。オペレーターが高レベルの意図（「ブランチを追加する」）を提供すると、SoTがExcutorがデバイスに触る前に必要な50以上の技術オブジェクトに展開する。第14章のサービスモデルは、同じ原則をさらに1層高くまで拡張する。「どの技術オブジェクトが存在しなければならないか」から「それらのオブジェクトはどのようなビジネス機能を誰に提供しているか」へ。デバイス構文をオペレーターから抽象化するために設計されたSoTは、サービスがその中でファーストクラスのオブジェクトとしてモデル化されていれば、ネットワーク内部をサービスコンシューマーから同様に抽象化できる。

実際的な帰結として、サービスはSoTにその依存チェーンとともにモデル化されなければならない。ブランチサイトサービスは物理回線に依存し、物理回線はプロバイダーに依存し、プロバイダーにはメンテナンスウィンドウの履歴がある。ネットワークセグメントサービスはアクセススイッチのセットに依存する。インターネットエクスチェンジでのピアリングサービスはBGPセッションに依存し、BGPセッションは物理ポートに依存し、物理ポートは特定の施設にある。任意の依存関係が状態を変えると、サービスモデルが更新され、影響を受けるコンシューマーは彼らが理解できる用語で通知を受けることができる。

flowchart TB
    classDef service fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef infra fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b
    classDef external fill:#f5e8d9,stroke:#a57a4a,color:#1a2e3b

    S1["ブランチサイトサービス<br/>店舗847"]
    S2["アプリケーション接続サービス<br/>在庫システム"]

    C1["回線<br/>プロバイダーX、CID-44821"]
    SW1["アクセススイッチ<br/>bldg-b-sw-01"]
    BGP1["BGPセッション<br/>AS64501"]
    PORT1["物理ポート<br/>rack-14-u32"]

    S1 --> C1
    S2 --> SW1
    S2 --> BGP1
    BGP1 --> PORT1

    MAINT["キャリアメンテナンスウィンドウ<br/>2026-06-15 02:00 UTC"]
    C1 -.->|"影響を受ける"| MAINT

    class S1,S2 service
    class C1,SW1,BGP1,PORT1 infra
    class MAINT external

チームがこの方法でモデル化できるべきネットワークサービスには次のものがある。新規ブランチサイトの有効化、会議やポップアップイベント向けの一時的なネットワークアクセス、依存関係ルールを適用するACLを持つアプリケーション接続、エクスチェンジポイントでのインターネットピアリング拡張、新しいプロジェクトセグメント向けのVLAN拡張。これらはそれぞれ、ビジネスコンシューマー、ライフサイクル、依存関係、そして健全性と障害の意味ある定義を持っている。

このモデルを構築するほとんどのチームは、白紙から始めているわけではない。既存のネットワークにはすでに300のブランチサイト、数年間にわたって蓄積された設定変更、そしてデバイスと回線をモデル化するがサービスはモデル化しないSoTがある。それらの既存サイトがサービスモデルに参加できるようになる前に、実際の状態を発見してSoTが正しいと考えている内容と突き合わせる必要がある。SoTレコードからの実行中の設定がドリフトしているサイトは、そのドリフトが解消されるまで自動化ライフサイクル管理下に安全に置くことができない。自動化はSoTの意図の見解に基づいて設定をプッシュするが、その見解が誤っていると、プッシュは状況を悪化させる。デバイス状態を読み取り、SoTレコードと比較してギャップを特定・解消する発見と照合は、ブラウンフィールド環境の前提となるステップだ。この作業は地味で時間がかかるが、それをスキップすると、サービスモデルはプラットフォームが構築された後にプロビジョニングされたサイトにのみ有効となる。それは通常、ネットワーク全体のほんのわずかな割合だ。

SoTでサービスをモデル化することは必要だが十分ではない。チームはまた適切なレベルでサービスを観察する必要がある。第6章のオブザーバビリティブロックがループを閉じる。コンシューマーの観点からサービスが健全かどうかを追跡するサービスレベルのオブザーバビリティは、下層インフラが健全かどうかを追跡するデバイスレベルのオブザーバビリティとは異なる。両方が必要だ。すべての下層デバイスが健全と報告している間でも、サービスモデルが適切なレベルで計装されていなければ、コンシューマーにはサービスが劣化しているように見える可能性がある。

14.3 ビジネスとの整合#

ネットワーク自動化の伝統的な主張は、運用効率に焦点を当てる。チケットの減少、プロビジョニングの高速化、エラー率の低下。その主張は正しく、初期投資を正当化するために有用だ。しかし、時間をかけて戦略的投資を維持するためには不十分だ。

運用効率は現在のベースラインに対して測定される。手動プロビジョニング時間を4時間から40分に短縮したチームは、スループットの大幅な改善を示した。3年前に予算を承認したビジネスユニットリーダーは喜ぶが、戦略的には関与していない。ネットワークチームはより良く動いている、それは良いことだが、次の段階に投資する理由にはならない。

より強力な主張はケイパビリティだ。自動化は、そうでなければ不可能か法外に高価なビジネス成果を可能にする。小売チェーンの拡張は具体的な例だ。成熟した自動化プラットフォームがなければ、6ヶ月で120店舗をオンボードするには、6ヶ月間そのプロジェクト専任のネットワークエンジニアチームが必要だ。積極的な手動プロビジョニング率として1エンジニアあたり1日1店舗を仮定すると（接続タイプ、デバイス数、キャリア調整時間、サイト調査が完了しているかどうかによって大幅に異なる数字だが）、それは他の責任を一切持たない約8人のチームだ。成熟した自動化プラットフォームがあれば、同じ作業は既存のチームが自動化ワークフローを並行して実行することで処理される。ビジネス成果、6ヶ月以内に受け入れ可能なコストで完了した拡張、は自動化が存在するからこそ達成可能だ。これは効率性の主張ではない。ケイパビリティの主張だ。ビジネスの主張だ。

2つ目の例として、大規模AIモデルトレーニングを実行する組織は、インターコネクトプロビジョニングのレイテンシと信頼性に依存している。新しいトレーニングクラスターをオンラインにするのに2週間の手動ネットワークプロビジョニングが必要な場合、競争力のある速度でトレーニング実験を実行するビジネスの能力は、ネットワークチームのスループットによって制約される。プロビジョニングを2週間から48時間に短縮する自動化は、ビジネスユニットが戦略的と考えるビジネスケイパビリティへの直接的なインプットだ。その接続を明確にできないネットワークチームは影響力を残している。

3つ目の例として、エンジニアが新しいエンタープライズMPLS VPN契約ごとにPEルーター、VRFインスタンス、顧客CEデバイスとのBGPセッション、QoSポリシーを手動で設定するサービスプロバイダーは、注文受付からサービス開始まで4週間かかる。そのタイムラインは運用の問題ではない。営業の問題だ。同じプロビジョニングシーケンスを自動化した競合他社、サービスリクエストから一貫した設定を生成し、既存のトポロジーに対して検証し、テスト済みのワークフローを通じてプッシュする、はRFP回答で2週間のターンアップを約束する。エンジニアがどれほど優秀であっても、4週間のプロバイダーはそのコミットメントに匹敵できない。制約はスキルではなく、プロビジョニングプロセスの直列的・手動的な性質だからだ。ターンアップを4週間から3日に短縮する自動化は、営業チームが約束できることを変え、会社が勝てる契約を変える。これは効率性の主張ではない。収益の主張であり、自動化プラットフォームへの投資に関する会話に属する。

推論のシーケンスが重要だ。デバイス動作から上向きに設計された自動化、「ルーター設定について何を自動化できるか」から始めて「ビジネスはこれから何を得るか」に向かって進む設計、は多くの場合ビジネス価値を明確にできない。なぜならビジネス成果を提供するように設計されていなかったからだ。ビジネスケイパビリティから下向きに設計された自動化、「信頼できるネットワークサービスを必要とするビジネス成果は何か」から始めてサービス設計を通じてそれらのサービスを実装する自動化まで逆方向に進む設計、は最初の会話からビジネス優先事項にその作業を結びつけることができる。

**ビジネス主導サービスマップ (Business-Driven Service Map)**パターンはこの接続を明示的にする。ネットワークサービスがそれらが可能にするビジネスケイパビリティへのマッピングだ。各ネットワークサービスについて、マップは3つの問いに答える。どのビジネスプロセスがこのサービスに依存しているか、このサービスが劣化または利用不可能になった場合のビジネスインパクトは何か、そしてこのサービスがより高速、より信頼性が高く、またはセルフサービスになった場合にどのようなビジネスケイパビリティが可能になるか。これはネットワーク自動化プロダクトマネージャーが所有するドキュメントであり、自動化ロードマップをビジネス優先事項と整合させるための主要なツールだ。

flowchart TB
    classDef biz fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef svc fill:#f5e8d9,stroke:#a57a4a,color:#1a2e3b
    classDef auto fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b

    subgraph BIZ["ビジネスケイパビリティ"]
        B1["小売拡張"]
        B2["AIトレーニング速度"]
        B3["イベント運営"]
    end

    subgraph SVC["ネットワークサービス"]
        S1["ブランチ有効化"]
        S2["インターコネクトプロビジョニング"]
        S3["一時アクセス"]
    end

    subgraph AUTO["自動化"]
        A1["サイトオンボーディングワークフロー"]
        A2["回線とBGPプロビジョニング"]
        A3["会議VLANライフサイクル"]
    end

    B1 --> S1 --> A1
    B2 --> S2 --> A2
    B3 --> S3 --> A3

    class B1,B2,B3 biz
    class S1,S2,S3 svc
    class A1,A2,A3 auto

このリフレームは多くのネットワークチームにとって不快だ。なぜなら異なるものを測定する必要があるからだ。運用メトリクス（クローズされたチケット、変更成功率、Mean Time To Resolution (MTTR)）はチームのコントロール内にあり、計装しやすい。ビジネス成果メトリクス（新しい小売拠点を開くまでの時間、トレーニングスループットへのインプットとしてのインターコネクトプロビジョニングレイテンシ）は、他のビジネスユニットとのコラボレーションと、彼らが実際に何を測定しているかの理解を必要とする。このシフトを行うチーム、技術的卓越性の測定からビジネス貢献の測定へ、は予算会話で異なる問いに答えている。「今四半期、ネットワークをどれほど効率的に運営したか」ではなく、「今四半期、どのビジネス成果がネットワークプラットフォームに依存していたか、それなしで何が失敗していたか」だ。それは答えるのがより難しい問いだが、プラットフォームが次のフェーズに向けて資金調達されるかどうかを決定する問いだ。

**効率測定より影響測定を (Impact Measurement over Efficiency Measurement)**の原則が続く。ネットワークチームだけに重要な運用メトリクスよりも、ビジネスに重要な成果の測定を優先する。効率メトリクスはインプットだ。成果がビジネスの関心事だ。

このリフレームはまた、計画サイクルでチームが求めるものを変える。「MTTRを40%削減した」と発表するチームは自分自身のパフォーマンスを報告している。「オンボーディング自動化が手動介入なしに40件の同時有効化を処理できるため、小売拡張タイムラインは達成可能だ」と発表するチームはビジネスケイパビリティを報告している。両方の事実が真実かもしれない。小売拡張プロジェクトに人員配置するかどうかの決定に関連するのは一方だけだ。

14.4 内部SLA#

他のチームが依存している自動化プラットフォームで、信頼性コミットメントがない場合は信頼の罠だ。壊れるまでは機能し、コンシューマーチームには計画を立てるデータがない。月曜日の朝に20件の同時ブランチ有効化リクエストをスケジュールする小売チェーンのインフラ担当リードは、月曜日の朝の前に、プラットフォームの動作を知る必要がある。各有効化にどのくらいの時間がかかるか、20件を並列で実行できるかそれともキューに入るか、1件がデプロイ途中で失敗した場合はどうなるか、そしてプラットフォームはその失敗をどのように伝えるか？

これらはSLAの問いだ。プロダクトモデルでは、すべての自動化サービスは明示的なSLAを持つ。法的な保護としてではなく、サービスを計画可能にする運用上の契約として。

自動化SLAには4つのコンポーネントがある。

可用性: サービスインターフェースが到達可能でリクエストを受け付けている時間の割合。月間99.5%の可用性を持つブランチ有効化サービスは、1ヶ月あたり約3時間半の許容ダウンタイムがある。その数字はコミットメントだ。サービスがダウンしているとき、チームは説明と回復タイムラインを負っている。
実行レイテンシ: サービスが提出から完了まで要求を満たすのにかかる時間。ブランチ有効化の場合、これは次のようになる。30秒以内の受信確認、5分以内にプロビジョニング開始、標準サイトで40分以内に完了。これらの数字は、サービスが到達可能かどうかだけでなく、「動作している」状態がどのように見えるかを定義する。
エラーバジェット: SLAを違反することなくサービスが失敗できる頻度。週あたり99%の成功完了を持つサービスには1%のエラーバジェットがある。1週間に1%以上の有効化が失敗した場合、何かがおかしく、チームはレビューを負っている。第13章セクション13.2で説明したNRE役割は、これらのバジェットを定義し守ることを所有する人物だ。SREの文献からのエラーバジェットモデルは直接適用される。エラーバジェットが消費されると、信頼性が回復されるまで新しい自動化デプロイが停止する。

SRE（サイト信頼性エンジニアリング）は、大規模ソフトウェア運用に由来する規律で、信頼性にエンジニアリング原則を適用する。サービスレベル目標の定義、エラーバジェットの測定、信頼性データを使った機能速度のガバナンス。NRE（ネットワーク信頼性エンジニア）役割はこれらの原則をネットワーク自動化プラットフォームに適応させる。両方の役割とネットワークチームへの適用は第13章セクション13.2で詳しく説明されている。

エスカレーションパス: サービスが失敗またはSLAを逃した場合、コンシューマーは誰に連絡し、期待される応答時間は何か。一般的なネットワークチームの受信箱にルーティングするエスカレーションパスはエスカレーションパスではない。それはチケットキューだ。プロダクトSLAは、定義された応答コミットメントを持つ名前付きまたはロールベースのエスカレーション連絡先を必要とする。

サポートモデルの問いが自然に続く。自動化が失敗したとき、誰がそれを所有するか？ほぼすべてのインシデントで3つの失敗モードが現れ、どれが活性かを混同することで、インシデントがチーム間で見落とされる。

失敗モード	症状	所有者
自動化バグ：ワークフローロジックが誤っている	同じ特定のインプットで一貫した失敗。他のインプットでは通過する	自動化開発者
プラットフォーム障害：実行エンジン、SoT、またはオブザーバビリティインフラが失敗した	複数の無関係なサービスにまたがる広範な同時失敗	プラットフォームチーム
ネットワーク障害：下層デバイスまたは回線が失敗した	自動化がエラーなしで完了したが、ネットワーク状態が収束しなかった	ネットワーク運用

これらのカテゴリ間の重複が、インシデントが見落とされる場所だ。gRPC Network Management Interface (gNMI)プッシュが拒否されたために失敗した自動化ワークフローは、自動化バグ（誤ったデータモデル）、プラットフォーム障害（gNMIコレクターがセッションを失った）、またはネットワーク障害（プッシュ中にデバイスが再起動した）のいずれかである可能性がある。インシデント対応プロセスは、コンシューマーチームがどれが活性かを理解する必要なしに、これらのカテゴリにわたってトリアージできるように設計されなければならない。小売チェーンの観点では、店舗が接続を得られなかった。誰がそれをいつ修正するかはプロバイダーの問題であり、彼らの問題ではない。

自動化障害のための実際的なトリアージシーケンスは3つのステップに従う。まず、自動化ログを確認する。ワークフローがエラーを報告したか、そのエラーは同じインプットの複数の実行にわたって一貫しているか、それとも1回に特定しているか？特定のインプットでの一貫した失敗は自動化バグを示す。ランダムまたは断続的な失敗は別の場所を示す。次に、プラットフォームの健全性を確認する。他の無関係なサービスが同時に失敗しているか、実行エンジン、SoT、オブザーバビリティスタックが健全と報告しているか？無関係なサービスにわたる広範な同時失敗は、ワークフローログが何と言っていても、プラットフォーム障害のシグネチャだ。3番目に、デバイス状態を確認する。ネットワーク要素は意図した設定を受信して適用したか、その現在の状態は自動化がプッシュしようとしたものと一致するか？ワークフローがエラーなしで完了したがネットワークが収束しなかった場合、障害はネットワーク層にある。このシーケンスは自動化ランブックの最初の3ステップとしてエンコードできる。そうすることで、オンコールエンジニアが最初から始めるのではなく、トリアージがすでに完了した状態でインシデントに到着する。

2番目の失敗モードのプラットフォームチームの参照は第10章に接続する。プラットフォームの信頼性はサービスSLAの前提条件だ。実行エンジンに信頼性目標がない場合、サービスは99.5%の可用性にコミットできない。第10章のプラットフォームエンジニアリングパターン、冗長性、健全性監視、自動回復、は自動化SLAを信頼できるものにするものだ。

インシデントが発生する前にエスカレーションパスを設計する。誰が何を所有していたかに関するインシデント後の会話は、明確な境界を確立したインシデント前の会話よりも常に難しい。

ブラスト半径は関連する設計上の懸念であり、同じインシデント前の会話に属する。手動プロビジョニングミスは1つのサイトに影響する。なぜならエンジニアは一度に1つのサイトを設定するからだ。自動化バグは、人間が何かが間違っていることに気づく前に、インプットパターンに一致するすべてのサイトに影響を与える可能性がある。これに対する応答は自動化を遅くすることではない。同時実行制限と段階的なロールアウトを、実装の詳細としてではなく意図的な安全の選択として、サービス契約に設計することだ。同時デプロイを5つのアクティブジョブに上限を設け、最初のデプロイが完了するまで検証し、失敗したジョブは人間がクリアするまで保留するブランチ有効化サービスは、遅いサービスではない。ブラスト半径が設計によって制限されたサービスだ。その制限は、可用性と実行レイテンシとともにサービス契約に表示されるべきであり、そうすることでコンシューマーチームはプラットフォームができることと、彼らを守るために拒否することの両方を理解する。壊れたテンプレートでさらに39のデプロイを完了するのではなく、最初の失敗の後に40店舗のロールアウトを一時停止することを理解する小売チェーンのインフラ担当リードは、プラットフォームをより信頼するようになる。

SLAコミットメント、ブラスト半径コントロール、トリアージフレームワークの存在は、変更ガバナンスとの異なる関係のための条件を作り出す。従来の変更管理の下でまだ運用している組織では、自動化されたものを含むすべてのネットワーク変更が、事前承認のために変更諮問委員会（CAB）を通じてルーティングされるかもしれない。そのプロセスは、各変更がユニークで手作りで予測不可能な世界のために設計されていた。人間のエンジニアによる手動変更をレビューする適切な人物は、人間の判断が変わるため真のリスク軽減を追加する。設計され、プレプロダクション環境でテストされ、SoTに対して検証され、ブラスト半径制限によって制約され、本番環境で何十回も正常に実行された自動化ワークフローに適用された同じロジックは、リスク軽減を追加しない。それは最初に本番環境で実行される前に確立されたリスクプロファイルを持つ操作にレイテンシを追加するだけだ。

**事前承認済み自動化パターン (Pre-Approved Automation Pattern)**はこれを解決する。変更承認はワークフロー設計に1回適用され、そのワークフローの各実行に繰り返し適用されない。ブランチ有効化ワークフローが検証ステージを通過し、関連するエンジニアリングおよび運用の利害関係者によってレビューおよび承認され、安全制約が有効な状態で本番環境にデプロイされると、そのワークフローのその後の各実行は、新しい承認を必要とする新しい変更ではない。それはすでに承認された、制限された操作のインスタンスだ。適切なガバナンスの問いは「この実行は承認されたエンベロープ内か？」であり、「この実行を行うべきか？」ではない。クラウドプロバイダーは各仮想ネットワーク作成リクエストを人間が承認することを要求しない。サービスは適切な制約で設計され、徹底的にテストされ、サービスとして承認された。そのサービス境界内の個々の顧客リクエストは、レビューを必要とする変更イベントではない。サービス呼び出しだ。ネットワーク自動化サービスは、適切に設計され承認されると、同じように動作すべきだ。この信頼を正当化する作業は、まさにセクション14.2から14.4が説明するものだ。明示的なサービス契約、オブザーバブルなアウトプット、制限されたブラスト半径、そして何かがうまくいかないときの定義されたトリアージパス。その作業が変更承認であり、適切な瞬間に1回行われる。

14.5 パフォーマンス、コスト、ROI#

自動化にはコストがかかる。実行エンジン、オーケストレーター、オブザーバビリティスタックのためのコンピュートインフラ。SoTレコード、ジョブ履歴、テレメトリのストレージ。自動化コードのビルド、テスト、メンテナンスのためのエンジニアリング時間（およびそれをサポートするAIコーディングトークン）。プラットフォームの商用コンポーネントのツールライセンス。コンシューマーが問題を提出したり新しいケイパビリティをリクエストしたりするときのサポート負担。これらのコストは実際のものであり、継続的だ。

ROIの問いも実際のものであり、それを避けるネットワークチームは予算決定を財務および調達チームに譲り渡す。彼らはそれをより不正確に答えるだろう。フレームワークには3つのコンポーネントがある。

自動化のコスト: プラットフォームの構築と運用の完全なロードコスト。プラットフォーム開発と保守に割り当てられたエンジニアリング給与、インフラコスト（自動化インフラ自体のコンピュート、ストレージ、ネットワーク）、ツールライセンス、運用オーバーヘッド。この数字は知ることができ、チームはそれを知るべきだ。
手動作業の同等コスト: 自動化なしに同じサービスを提供するコスト。ブランチ有効化の場合、これはサイトあたりのエンジニアリング時間に、それを行うエンジニアの時間コストを掛けたもの、さらにエラーのコスト（手動プロビジョニングミスによって引き起こされたインシデント。Mean Time To Resolution (MTTR)と影響を受けたサービスで測定される）を加えたものだ。小売チェーン拡張の場合、手動コストは自動化投資が明らかに正当化されるほど大きい。年2回プロビジョニングされる低ボリュームのサービスの場合、計算は異なる。
アンロックされたケイパビリティの価値: 自動化なしでは不可能なビジネス成果。これは定量化が最も難しいコンポーネントであり、最も高い価値を持つ主張だ。6ヶ月で120店舗は効率性の問題ではない。バイナリのケイパビリティだ。自動化なしでは、エンジニアリング予算に関係なく、そのタイムラインでは起こらない。「小売拡張タイムラインは自動化プラットフォームに依存している」と明確に述べられるネットワークチームは、予算交渉ではなく戦略的な会話に参加している。

3つの軸が任意の自動化サービスのデザインスペースを定義し、それぞれはプロダクトモデルが表面化させるトレードオフを表す。

スピード: リクエスト提出から完了までサービスはどのくらい速いか？
安全性: 検証、ドライランステージ、ロールバックパスを通じて、サービスはどの程度確実に状況を悪化させることを回避するか？
利用率: 劣化なしにプラットフォームは何件の同時リクエストを処理できるか？

これらの軸は緊張関係にある。広範な検証と監督された実行ステージを通じて安全性を最大化するとレイテンシが増加する。より安全なワークフローは通常より遅い。検証ステージを削減することでスピードを最大化するとリスクが増加する。同時利用率を最大化するにはインフラへの投資が必要だが、実際のリクエストボリュームでは正当化されないかもしれない。

プロダクトのフレーミングはこれらのトレードオフをサービス契約において明示的にすることを強制する。小売チェーンのインフラ担当リードが20件の同時デプロイが安全かどうかを尋ねたとき、答えは「テストでは動作する」ではない。答えはプラットフォームの設計に関する具体的な声明だ。同時デプロイキャパシティは24のアクティブジョブに制限されており、各デプロイには独立したロールバックパスがあり、オブザーバビリティシステムはジョブを完了とマークする前に成功した状態収束を確認する。これらの声明は、エンジニアリング実装の詳細としてではなく、プロダクト設計上の決定としてトレードオフについて考えたチームから来る。

ROI測定は優先順位付けに直接フィードバックされる。次に何を自動化するかは、どのビジネス成果がネットワーク制限によって最も制約されているかによって判断されるべきだ。最も多くのエンジニアリング時間を消費する手動リクエスト、手動プロビジョニング中に最も高い失敗率を持つサービス、ネットワークスループットによってブロックされているビジネスケイパビリティを追跡するチームは、ビジネスが評価できる優先順位付けの主張を行うためのデータを持っている。そのデータを持たないチームは技術的に興味深いものに基づいて優先順位付けの主張を行い、それらの主張はインパクトを定量化したチームに対して予算サイクルで負ける。

14.6 優先順位付けとロードマップ#

2つの問いがすべてのネットワーク自動化チームに一貫して直面し、正式には答えられることはほとんどない。次に何を自動化するか、そしていつリクエストを断るか。プロダクトモデルは両方に正式な答えを必要とする。これらが優先順位付けのカテゴリだ。

ビジネスインパクト: 自動化されたとき、どのサービスが最も高い価値のビジネスケイパビリティを可能にするか？セクション14.3のビジネス主導サービスマップがこの問いへのインプットだ。自動化されたとき戦略的なビジネスイニシアティブをアンブロックするサービスは、自動化されたとき年間12時間のエンジニアリング時間を節約するサービスより上位に来る。
頻度×工数: このタスクは手動でどのくらいの頻度で行われるか、各発生にどれほどのエンジニアリング時間がかかるか？毎日行われて毎回4時間かかるタスクは、毎週行われて30分かかるタスクより200倍のROIを持つ。各発生あたり重大な工数を伴う高頻度の手動タスクは、自動化の最も明確なケースだ。
リスク削減: 一部のタスクは頻度が低くても自動化する価値がある。なぜなら人間のエラーのコストが壊滅的だからだ。設定ミスが数百の顧客に影響するルートリークを引き起こす可能性がある手動BGPピアリング変更は、年に6回しか発生しなくても自動化する価値がある。自動化はスループットではなく、受け入れがたい結果を持つエラーモードを排除することによって正当化される。
コンシューマー需要: 他のチームが積極的にリクエストしているものは何か？コンシューマー需要は不完全なシグナルだ。なぜならチームは最も価値があるものよりも、可能と知っているものをリクエストすることが多いからだ。しかし、同じチームから同じケイパビリティへの一貫したリクエストは、サービスインターフェースが実際のユースケースに合っていない場所について意味のあるデータだ。

**自動化バックログ (Automation Backlog)**パターンは、自動化されていないタスクをプロダクトチームがフィーチャーバックログを扱うのと同じように扱う。優先順位付けされ、推定され、「完了」の意味について明確な受け入れ基準を持つ。完了とは「自動化がラボで正常に実行された」ではない。完了とは「自動化が第13章セクション13.5.2で説明した信頼ラダー (Confidence Ladder)のステージを通過し、文書化され、関連するコンシューマーチームによるセルフサービス利用に利用可能」だ。バックログは利害関係者に可視化されており、彼らは何が来るかを見て、それに応じて計画を立てることができる。

ロードマップのコミュニケーションはロードマップ自体より重要だ。四半期ごとに依存するチームと共有されるネットワーク自動化ロードマップは信頼のシグナルだ。自動化チームの仕事をビジネスに対して読み取れるものにする。コンシューマーチームが、プラットフォームが次の四半期にできることとできないことを中心に自分たちの仕事を計画できるようにする。コンシューマーチームがネットワークチームが知らなかった要件を表面化するフィードバックの機会を作り出す。

コンシューマー/利害関係者からのフィードバックループはロードマップ決定への最も価値あるインプットだ。どのチームが最も多くの例外を提出しているか？どの自動化アウトプットは、コンシューマーがそれに基づいて行動できる前に手動の解釈を必要とするか？現在のサービスインターフェースはどこでコンシューマーにネットワーク用語ではなくビジネス用語でリクエストを提出することを強いているか？これらはプロダクトフィードバックシグナルであり、それらを体系的に収集することが、実際のコンシューマーニーズを反映するロードマップと、自動化チームがコンシューマーが欲しいと思うものを反映するロードマップを分ける。

利害関係者ミーティングのケイデンスは明示的に名付ける価値がある。四半期ごとのロードマップレビュー（ほとんどのプラットフォームでは四半期ごと、積極的に開発中のプラットフォームでは月ごと）、コンシューマーフィードバックの収集、今後の変更のコミュニケーションを行う定期的なミーティングは、ステータスミーティングではない。それは自動化プラットフォームがそのユーザーの話を聞くプロダクトのように振る舞うメカニズムだ。このステップをスキップするチームは、今年の予算を消費しながら昨年の問題を解決する自動化を構築する。

第13章セクション13.4.1の3つの抵抗パターンはプロダクトの会話にも現れる。凍りついた専門家は、プロダクトのフレーミングが自分の専門性を実装の詳細として再定義するため、それに抵抗する。不可視のROIパターンは、何も変わらないと思ってコンシューマーが問題の報告を止めるとして現れる。ブラックボックスパターンは、正常に完了するが何が起きたかの可視性を提供しないサービスとして現れ、コンシューマーが手動確認なしにアウトプットを信頼できなくなる。応答は同じだ。専門家をサービス契約の設計者にし、明示的なメトリクスで成功を可視化し、サービスアウトプットに透明性を組み込む。

14.6.1 プロダクトマネジメント機能#

すべてのチームが専任のプロダクトマネージャーを必要とするわけではない。すべての成熟した自動化プログラムは、プロダクトマネジメント機能を行う誰かを必要とする。

小さなチームサイズでは、ネットワークアーキテクトまたはシニアNREが技術的な仕事と並行してプロダクトマネジメント機能を吸収できる。バックログを維持し、利害関係者ミーティングを運営し、ビジネス整合会話を所有する。このスケールでは、機能を維持するために週に数時間で十分だ。

プラットフォームが成長するにつれて、外部の利害関係者と内部エンジニアリングの間の変換作業は実質的になる。本番稼働中の30のサービスと競合する優先事項にわたる交渉を必要とする四半期ロードマップを持つ10のコンシューマーチームにサービスを提供するプラットフォームは、週に数時間でプロダクト管理できない。この機能はフルタイムの役割になる。

**ネットワーク自動化プロダクトマネージャー (Network Automation Product Manager)**の役割は、成熟した自動化プログラムを持つ組織で生まれつつある。その責任は次の通りだ。

プラットフォームを代表して利害関係者との関係を所有する。コンシューマーチームの主要な連絡先として、彼らのニーズをサービス要件に変換する責任を持つ。
ビジネスインパクトとエンジニアリングの現実の両方を反映した優先順位付けで、ビジネス主導サービスマップと自動化バックログを維持する。
ロードマップを外部にコミュニケーションし、優先事項が変わったときの期待値管理を行う。
ビジネスインパクトメトリクスを定義・追跡し、ビジネス成果へのプラットフォームの貢献をリーダーシップに可視化する。
チームの優先順位付け議論においてコンシューマーフィードバックを代表し、エンジニアリングの優先事項が内部の技術的好みではなく実際のユーザーニーズを反映するようにする。

この役割は深いネットワーク専門知識を必要としない。ネットワークチームが提供できるもの、ビジネスが必要とするもの、そしてこれらの2つが整合しているところと整合していないところを理解する能力を必要とする。ネットワーク自動化プロダクトマネージャーと第13章セクション13.2の技術的な役割との間のコラボレーションモデルは、ソフトウェアプロダクト組織からのおなじみのパターンに従う。プロダクトマネージャーは何を作るかとなぜを所有し、ネットワークプラットフォームエンジニアと自動化開発者はどのように作るかを所有し、NREはそれが本番環境でどのように健全に保たれるかを所有する。これらのグループ間の対立はモデルの欠陥ではなく機能だ。PMはコンシューマーニーズのために押し、エンジニアはプラットフォームの持続可能性のために押し、それらの間の緊張がいずれかが単独で達成するよりも良い決定を生み出す。

ネットワーク自動化プロダクトマネージャーの役割は、技術に焦点を当てたチーム構造に非技術的な役割を導入するため、一部のネットワーク組織で物議を醸す。懸念は妥当だ。十分な技術的基盤を持たないPMは、エンジニアリングチームが実現できないコミットメントを行い、実装が簡単なリクエストと基本的なプラットフォーム変更を必要とするリクエストを区別するのに苦労する。解決策は役割を避けることではなく、コラボレーションの境界を具体化することだ。2つのガードレールは交渉不可能だ。PMは範囲とタイムラインについてエンジニアリングリードからの明示的なサインオフなしに外部の利害関係者に納期を約束できない。そしてエンジニアリングリードは、まだ設計または推定されていないプラットフォーム変更を必要とするコミットメントに対する拒否権を持つ。これらのガードレールがなければ、PM役割は新しい失敗モードを作り出す。外部の利害関係者がエンジニアリングチームが事後に知る約束を受け取り、信頼性のダメージはPMではなくプラットフォームに落ちる。

プラットフォーム移行から2年後、第13章で紹介されたチームの手動運用から自動化プラットフォームへの移行を主導したネットワークアーキテクトのJordiは、小売チェーン統合プロジェクトのミーティングに参加するよう求められた。ビジネスチームリードはオンボーディングタイムラインを説明し、40店舗が同時に稼働開始する必要がある6週間の期間を指差して尋ねた。「プラットフォームはそれに対応できるか？」Jordiには答えがあった。プラットフォームは技術的にはそれを処理できるが、新たに有効化されたサイトの監視カバレッジには、完全なテレメトリが取り込まれるまで12時間の遅延があった。40件の同時有効化は、40のサイトが半日間、観測性カバレッジが低下した状態で動作することを意味する。彼はそれを直接言い、リスクを名指しし、全体のタイムラインを延長することなく有効化を3日間にわたって分散させるオンボーディングシーケンスの修正を提案した。ビジネスチームはそれを受け入れた。その会話は15分で起きた。なぜならJordiは技術的な制約とそのビジネス上の結果の両方を理解していたからだ。その変換、プラットフォームが何をするかとビジネスが何を経験するかの間、は誰が肩書きを持つかに関係なく、プロダクトマネジメント機能だ。

14.6.2 サービスライフサイクルの管理#

セクション14.6.1のPM役割の説明は責任を名付けている。このセクションでは、それらの責任がすべてのネットワークサービスが通過する4つのステージ、定義、デリバリー、運用、進化にわたってどのように機能するかを示す。

flowchart LR
    classDef def fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
    classDef del fill:#f5e8d9,stroke:#a57a4a,color:#1a2e3b
    classDef ops fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b
    classDef evo fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b

    DEF["定義<br/>サービス契約<br/>ビジネス上の正当性"]
    DEL["デリバリー<br/>バックログ管理<br/>受け入れ基準"]
    OPS["運用<br/>SLA監視<br/>コンシューマーコミュニケーション"]
    EVO["進化<br/>バージョン管理<br/>廃止"]

    DEF --> DEL --> OPS --> EVO
    EVO -->|"次のバージョン"| DEF

    class DEF def
    class DEL del
    class OPS ops
    class EVO evo

定義

PMが新しいサービスに最初に関与するのは、エンジニアリングチームが自動化コードを1行書く前だ。コンシューマーチームがリクエストを持って来る。「店舗のオンボーディングをより速くする必要がある」、または「アプリケーションチームはチケットを提出せずにネットワークセグメントをプロビジョニングできない」。この段階でのPMの仕事は、セクション14.2の3コンポーネント構造を使用してそのリクエストを制限されたサービス契約に変換することだ。コンシューマーが何を提供するか（インプットサーフェス）、何を観察するか（アウトプットサーフェス）、そしてコンシューマーが理解する必要がないがチームが管理しなければならない内部依存関係は何か？その変換はエンジニアリングに渡す要件ドキュメントではない。それはコンシューマーが必要とするものとプラットフォームが提供できるものの間の交渉であり、PMとエンジニアリングリードの両方が部屋にいる。

PMは「コンシューマーの観点から完了はどのように見えるか」という問いを所有する。エンジニアリングリードは「プラットフォームの観点から完了はどのように見えるか」を所有する。定義が完了する前に両方の問いに答えなければならない。なぜなら、コンシューマーを満たすがプラットフォーム制約を無視するサービス契約はデリバリー中に手戻りを生じさせ、プラットフォームを満たすがコンシューマーを満たさない契約はリリース後に使われなくなるからだ。

定義が閉じる前に、PMは新しいサービスをセクション14.3のビジネス主導サービスマップに配置する。このステップは、サービスが明示的なビジネス上の正当性を持ち、他の自動化バックログ項目との相対的な優先度を一貫した基準で評価できることを保証する。マップに配置できないサービス、それが可能にするビジネスケイパビリティや、その不在のインパクトを誰も明確にできないため、は定義の準備ができていない。それはエンジニアリングを開始するのではなく、コンシューマー会話に戻るシグナルだ。

デリバリー

サービス契約が合意されると、PMは対応する自動化バックログエントリを開発を通じて管理する。受け入れ基準はコンシューマーの用語で書かれる。「gNMIがPEルーターへのプッシュがエラーなしで完了する」ではなく、「標準ブランチ有効化は提出から40分以内に完了し、各ステージでライフサイクルイベントが発行される」。この違いは重要だ。なぜなら実装の用語で書かれた受け入れ基準はコンシューマー体験が失敗しながらも通過できるからだ。プッシュは完了したが、コンシューマーは通知を受けず、店舗がアクティブかどうかを確認できない。

デリバリー中、PMはタイムラインと範囲に関するすべての外部コミュニケーションを所有する。エンジニアリングリードは内部の技術的な決定を所有する。この分業はエンジニアリングチームを、ほとんどの自動化プロジェクトを脱線させるパターンから守る。サービス契約が合意された後に到着する範囲の追加だ。契約締結後のすべての新しい要件は、現在のデリバリーへの修正ではなく、独自の優先順位付けを持つ新しい自動化バックログ項目だ。PMの仕事は、コンシューマーチームとのその境界を守ることだ。なぜならエンジニアリングチームはコンシューマー関係を損なうことなくそれを行えないからだ。任意の利害関係者がいつでも拡張できるデリバリー範囲は、決して完了しないデリバリーだ。

運用

サービスが稼働すると、PMの役割はデリバリーから信頼の維持へと移行する。セクション14.4の内部SLAは、サービスがコミットするものを定義する。可用性、実行レイテンシ、エラーバジェット、エスカレーションパス。PMはこれらのメトリクスを監視するが、障害を診断するためではなく（それはNREの責任）、しきい値が近づくか違反されたときにコンシューマー向けのコミュニケーションを所有するためだ。監視するよう告知されていないダッシュボードを読むことで、サービスがSLAの外で動作していたことを発見したコンシューマーチームは、SLAを受けていない。彼らはメトリクスを受けたが関係がない。PMが関係だ。

PMはまた運用フィードバック収集プロセスを運営する。どのコンシューマーチームが最も多くの例外リクエストを提出しているか？どのサービスアウトプットはコンシューマーがそれに基づいて行動できる前に手動の解釈を必要とするか？現在のインプットサーフェスはどこでコンシューマーにネットワーク用語ではなくビジネス用語でリクエストを提出することを強いているか？これらのシグナルは不満ではない。それらはプロダクトデータであり、PMの仕事はエンジニアリングチームが対応できる十分な具体性でそれらを体系的に集約してロードマップの会話に持ち込むことだ。「コンシューマーはブランチ有効化に不満だ」として届くフィードバックは実行可能ではない。「最後の12件の例外リクエストのうち7件は、どの定義済み階層にも一致しないポップアップサイト向けであり、7件すべてでネットワークチームの直接関与が必要だった」として届くフィードバックは実行可能だ。インプットサーフェスのギャップを名指しし、その運用コストを定量化している。

進化

進化を止めたサービスは、設計で処理するように意図されたものと、コンシューマーが実際に必要とするものとのミスマッチを蓄積する。PMはサービスがいつどのように進化するかの決定を所有する。前のステージで収集された運用フィードバックとビジネス主導サービスマップの変化するエントリによって情報を受ける。

すべての進化が同じ運用上の結果を持つわけではない。新しいオプションの入力フィールドを追加するかより豊かな出力イベントを発行する変更は付加的だ。既存のコンシューマーは影響を受けず、新しいケイパビリティの採用はオプトインだ。必須フィールドの名前を変更するか出力イベントを削除するかSLAコミットメントを変更する変更は、それに依存するすべてのコンシューマーの既存の契約を壊す。PMはどの進化が始まる前にもこれらの2つのカテゴリを区別しなければならない。なぜなら、異なるプロセスを必要とするからだ。付加的な変更はマイナーアップデートとして提供できるが、破壊的な変更はバージョンインクリメント、移行パス、そして変更が出荷される前にコンシューマーチームに伝達される廃止タイムラインを必要とする。

廃止タイムラインは多くのチームが失敗する場所だ。エンジニアリングチームは自然に新しいバージョンが安定したらすぐに古いバージョンを削除したがる。コンシューマーチームは自然に移行のキャパシティができるまで依存しているバージョンに留まりたがる。PMはその2つの立場の間のウィンドウを交渉し、両側にコミットする。古いバージョンがサポートされなくなる特定の日付。コンシューマーチームが移行を計画できるほど早く伝達される。このプロセスなしに進化するサービスは、サービス契約が構築するよう設計された信頼を侵食する。本番環境で破壊的変更を発見したコンシューマーチームは、技術的な失敗を経験したのではない。関係の失敗を経験したのであり、それは回復するのがより難しい。

14.7 まとめ#

本章に4つのテーマが固定されている。

スクリプトではなくサービス: プロダクトシフトは、実行する自動化を構築することから、他が依存するサービスを提供することへだ。ネットワークサービスをプロダクトとしてパターンはこのリフレームを名付ける。サービスがプライマリのアーティファクトであり、下層のネットワークは実装の詳細だ。サービス契約パターンはこれを具体化するアーティファクトだ。コンシューマーが提供する必要があるものとコンシューマーが観察できるものを制限する、インプットサーフェス、アウトプットサーフェス、内部依存関係の明示的なバージョン管理された定義。コンシューマーが理解する必要のないネットワーク実装の詳細を露出させることなく。

ビジネス整合は構造的だ: ビジネスインパクトを測定するには、デバイス動作からではなくビジネス成果から下向きに自動化を設計する必要がある。ビジネス主導サービスマップがそのツールだ。ネットワークサービスが可能にするビジネスケイパビリティと、劣化や利用不可能の場合のビジネスインパクトの明示的なマッピング。このマッピングを流暢に行えるチームは、他のビジネスユニットが新しいことを計画しているときに連絡してくるチームだ。なぜなら、それらのチームはすでに「ネットワークが可能にするものは何か」という問いに答えているからだ。できないチームは、タイムラインが設定された後に新しいイニシアティブについて聞き、ネットワークが間に合わない理由を説明するだけだ。自動化バックログは同じロジックを優先順位付けに適用する。次に何を構築するかは、どのビジネス成果がネットワーク制限によって最も制約されているかによって決定されるべきであり、技術的に最も興味深い自動化によってではない。

SLAとサポートモデルは必要になる前に: 信頼性コミットメント、エスカレーションパス、障害の所有権を最初の主要インシデントの前に定義することが、プラットフォームをスクリプトのコレクションから分けるものだ。内部SLA、その可用性、実行レイテンシ、エラーバジェット、エスカレーションパスの4つのコンポーネントを持つ、は信頼を明示的にするツールだ。3つの失敗モードのタクソノミー（自動化バグ、プラットフォーム障害、ネットワーク障害）は、インシデントがチーム間で見落とされるのを防ぐトリアージフレームワークだ。事前承認済み自動化パターンはこれを拡張する。ワークフローが設計、テスト、安全制約が有効な状態で承認されると、個々の実行は承認された操作のインスタンスであり、再承認を必要とする新しい変更ではない。SLAモデルとガバナンスモデルの両方は、最初のインシデントの前に確立されなければならない。後ではない。

サービスライフサイクルにわたるプロダクトマネジメント機能: すべてのネットワークサービスは4つのステージ、定義、デリバリー、運用、進化を経て、プロダクトマネジメント機能はすべての4つにわたる継続性を所有する。定義では、PMはエンジニアリングが始まる前にコンシューマーリクエストを制限されたサービス契約に変換する。デリバリーでは、PMは範囲の境界を保持し、外部コミュニケーションを所有する。運用では、PMはコンシューマー向けのSLAコミュニケーションを所有し、フィードバックを実行可能なプロダクトデータに集約する。進化では、PMは付加的な変更と破壊的な変更を区別し、バージョン管理の決定を所有し、エンジニアリングとコンシューマーチームの両方と廃止タイムラインを交渉する。この機能がなければ、サービスは場当たり的に定義され、受け入れ基準なしに提供され、コンシューマー関係なしに運用され、予告なく進化する。この機能があれば、プラットフォームはユーザーの話を聞き、時間をかけて信頼を獲得するプロダクトのように振る舞う。

本章で説明したプロダクト規律は、パート5が説明するものの前提条件だ。クローズドループ自動化はリアルタイムの修復決定を行う。自己修復ネットワークは人間の介入なしに障害に対応する。自律ネットワークはコンシューマーを代表してルーティングとプロビジョニングの決定を行う。これらのそれぞれは、プラットフォームがコンシューマーが依存するアクションを、その特定のアクションに対する直接的な人間の承認なしに実行することを表す。定義されたサービス境界、オブザーバブルな状態、信頼性コミットメント、しきい値が超過されたときの明確なエスカレーションなしでは、自律的な運用はプロダクトではない。それは契約なしに行動する予測不可能なシステムだ。本章の作業は、自律的な運用が信頼できるものになることを可能にするものであり、それがパート5が基盤とするものだ。

参考文献とさらなる読書#

Continuous Delivery, Jez Humble, Dave Farley (Addison-Wesley, 2010). ソフトウェアデリバリーライフサイクルの基礎テキスト。リリースを確実で低リスクな操作にするデプロイメントパイプラインの構築方法。本章のサービスライフサイクルパターン、開発から本番稼働まで、はネットワーク自動化に適用されたこれらの原則から引き出している。
The Art of SLOs, Google SRE Workbook (sre.google で入手可能). サービスレベル目標、エラーバジェット、および信頼性コミットメントと機能速度の関係を定義するための実用的なガイド。セクション14.4の内部SLAモデルは、内部コンシューマーにサービスを提供する自動化プラットフォームにこれらの原則を適用する。
Empowered, Marty Cagan (Wiley, 2020). 技術組織のためのプロダクトマネジメントフレームワーク。機能ではなく成果を中心にチームを整理する方法、プロダクトチームにとって「完了」の意味を定義する方法、エンジニアリング作業とビジネス優先事項の間の戦略的整合を維持する方法。セクション14.6.1で説明したネットワーク自動化プロダクトマネージャーの役割はこのフレームワークから引き出している。
Team Topologies, Matthew Skelton, Manuel Pais (IT Revolution Press, 2019). 第13章で参照されており、ここでも引き続き関連する。プラットフォームチームモデル、自動化プラットフォームが内部コンシューマーとしてストリームアラインドチームにサービスを提供する、は本章のプロダクトモデルが支援するように設計された組織構造だ。
Accelerate: The Science of Lean Software and DevOps, Nicole Forsgren, Jez Humble, Gene Kim (IT Revolution Press, 2018). 高パフォーマンス技術組織と低パフォーマンス組織を分けるものに関する実証的な研究。セクション14.4に関連する。データは変更承認委員会がより良い安定性成果と相関していないが、より遅いデリバリーと強く相関していることを示す。事前承認済み自動化パターンの背後にある証拠基盤と、変更ガバナンスが各実行のときではなくワークフロー設計時に属するという主張だ。

💬 Found something to improve? Send feedback for this chapter