ケイパビリティ
私たちは、コミットから本番までの経路を設計します。ビルド、テスト、セキュリティ分析、アーティファクト管理、環境間の昇格、段階的なロールアウトがその対象です。セキュリティチェックはこの経路の中で実行されるため、リリースは、それを出荷するのと同じ仕組みによって検証されます。
DevOpsとは、デリバリーの仕組みそのもののエンジニアリングです。コードベース、パイプライン、環境、フィードバックループは、本番で動くソフトウェアを出力する一つの機械を構成しており、その機械の設計には良し悪しがあります。うまく設計された機械は、小さな変更を1日に何度も、低い失敗率でリリースします。設計のまずい機械は、数週間分の作業を一つのリリースにまとめ、変更作業の時間枠と、誰も信用していないロールバック計画を必要とします。
DevSecOpsは、同じ考え方をセキュリティに広げたものです。最後にレビューの関門を置くのではなく、セキュリティ管理策を自動化し、最も低コストで対処できる場所に配置します。プルリクエストでの静的解析、ビルドでの依存関係とコンテナのスキャン、アドミッション時の署名検証、インフラ変更へのポリシー適用です。開発者は、普段使っているツールの中で、文脈がまだ頭に残っているうちに、数分で検出結果を受け取れます。
私たちは、パイプライン、環境定義、ポリシーを本番のソフトウェアとして扱います。バージョン管理し、レビューし、テストし、オーナーを定めます。私たちが目指すのは、監査人が読み解くことができ、エンジニアが筋道を立てて理解でき、新しいチームが一から作り直すことなく採用できるデリバリープロセスです。
エンジニアリング領域
パイプラインは、コストとフィードバックの速さの順に並べた品質ゲートの連なりです。高速で決定的なチェックを先頭に置き、独立して実行できるものは並列化し、積極的にキャッシュすることで、通常のケースが数分で完了するようにします。パイプラインは再利用可能なテンプレートとして定義し、各サービスがYAMLをコピーするのではなく組織の標準を継承するようにします。
ブランチ戦略は、変更のバッチサイズを決めます。私たちは、短命なブランチとフィーチャーフラグを用いたトランクベース開発を推奨します。長命なブランチは、統合のリスクを最悪のタイミングまで先送りするためです。ビルドは再現可能とし、イミュータブルでバージョン管理された単一のアーティファクトを生成して、内容を変えずにすべての環境へ昇格させます。
環境は本番前の不確実性を減らすためにあり、プログレッシブデリバリーは本番の中でそれをさらに減らします。環境は同じインフラコードから構築して差異を設定だけに限定し、同じアーティファクトを環境間で昇格させます。本番では、カナリアやブルー/グリーンのロールアウトによって変更を一部のトラフィックにだけ公開し、エラー率とレイテンシをベースラインと比較してから先へ進めます。
GitOpsモデルでは、すべての環境のあるべき状態をGitに置き、クラスター内のコントローラーが実際の状態をそれに一致させ続けます。これにより完全な監査証跡が得られ、CIシステムにクラスターの認証情報を持たせる必要がなくなり、ロールバックはrevertで済みます。同じ規律を、planレビューとポリシーチェックを備えたTerraformパイプラインを通じてクラウドリソースにも適用します。
脆弱性の大半は、チームが書いたコードか、取り込んだコードから入り込みます。私たちは、その両方について、信頼できるシグナルが得られる最も早い段階で検出を自動化し、検出結果が無視されず対処できるものになるよう各ツールを調整します。さらにビルドは証拠を生成します。ソフトウェア部品表（SBOM）、署名、そして何を、どのソースから、どのパイプラインでビルドしたかを示す来歴情報です。
文書に書かれたルールは守られ方にばらつきが出ますが、コードに書かれたルールは毎回必ず適用されます。私たちは、セキュリティと運用のポリシーをOpen Policy AgentまたはKyvernoで表現し、Terraformのplan、Kubernetesマニフェスト、パイプライン定義に対して評価します。その周囲にゴールデンパスを構築します。ポリシーに準拠した方法でサービスを作成・運用することが最も簡単な方法になるようにする、テンプレートとセルフサービスのツール群です。
デプロイとは、新しいコードを本番に送り込むことです。リリースとは、新しい振る舞いをユーザーに公開することです。両者を一つの出来事として扱うと、すべてのデプロイが事業上のリスクを負うことになり、変更作業の時間枠、リリーストレイン、大きなバッチにつながります。両者を分離すれば、コードを継続的に出荷しながら、公開の範囲を独立して制御できます。
振る舞いについてはフィーチャーフラグが、ランタイムのリスクについてはカナリアとブルー/グリーンの戦略が、この分離を実現します。カナリアロールアウトでは、わずかな割合のトラフィックを新バージョンに送り、定められた時間にわたってそのメトリクスを安定バージョンと比較します。エラー率やレイテンシがしきい値を超えて悪化した場合、トラフィックは自動的に安定バージョンへ戻ります。ブルー/グリーンは完全な環境を2つ保持してトラフィックを一度に切り替える方式で、バージョンを混在させて提供できないリリースに適しています。
どちらも、データ層が2つのアプリケーションバージョンを同時に許容できることが前提です。そのためスキーマ変更は、expand-and-contractの手順に従います。新しい構造を追加し、両方に書き込むコードをデプロイし、データを移行し、読み取りを切り替え、その後のリリースで古い構造を削除します。この手順を省くことが、ロールバックが失敗する最も多い原因です。
アーキテクチャ
ビルドと検証
コミット
mainブランチへのレビュー済みマージ
ビルド
再現可能、依存関係はバージョン固定
テスト
単体・結合・コントラクトテスト
SAST・依存関係スキャン
静的解析と依存関係の監査
イメージスキャンと署名
レイヤーをスキャンし署名、SBOMを添付
リリース
ステージング
同一アーティファクト、本番相当のデータ
カナリア
一部のトラフィックでシグナルを監視
本番
ゲート付きの段階的ロールアウト
モニタリング
SLOで昇格かロールバックかを判断
現代のサービスは、その大部分がサードパーティのコードです。オープンソースのライブラリ、ベースイメージ、ビルドツール、CIのアクションがこれにあたります。そのどれもが、攻撃者がアプリケーション自身のソースに触れることなく本番に到達できる経路になります。サプライチェーンセキュリティとは、アーティファクトに何が入っているかを把握し、ソースから実行環境までの間に改ざんされていないことを証明する取り組みです。
管理策は一本の鎖を成します。依存関係はバージョンとハッシュで固定し、更新はレビューを経るプルリクエストとして届きます。ビルドは、常設の認証情報を持たない、隔離されたエフェメラルランナーで実行します。各ビルドがSBOMを出力するため、新たな脆弱性が公表されたときに、影響を受けるサービスをクエリで特定できます。アーティファクトには署名し、来歴アテステーションに、それを生成したソースのコミットとパイプラインを記録します。デプロイ時には、署名のないイメージや、信頼されたパイプラインの外でビルドされたイメージを、アドミッションポリシーが拒否します。
4つのDORAメトリクスは、デリバリーの仕組みを2つの側面から表します。デプロイ頻度と変更のリードタイムはスループットを測ります。チームがどれだけの頻度で出荷し、コミットが本番に届くまでにどれだけかかるかです。変更失敗率とサービス復旧時間は安定性を測ります。リリースがどれだけの頻度でインシデントを引き起こし、サービスがどれだけ早く復旧するかです。これらのメトリクスの基になった研究は、スループットと安定性がともに向上することを示しています。どちらも、小さなバッチと速いフィードバックから生まれるためです。
私たちは、これらをパイプラインのイベント、デプロイの記録、インシデントのデータから計測し、人が報告するのではなく仕組みが算出するようにします。メトリクスは、遅いテストステージや数日の遅れを生む手動承認といった制約を特定し、プロセスへの変更が意図した効果を上げたかを検証するために使います。これはチームのための診断ツールであり、個人の目標に変えた途端に機能しなくなります。
組織が数チームの規模を超えると、各チームがパイプライン、オブザーバビリティ、デプロイを個別に解決することは、コストがかさみ、一貫性も失われます。プラットフォームエンジニアリングは、社内プラットフォームを提供することでこの問題に対処します。社内プラットフォームとは、ほかのエンジニアをユーザーとするチームが保守する、厳選されたテンプレート、パイプライン、セルフサービス機能の集合です。
ゴールデンパスとは、よくある作業のためにサポートされた経路です。たとえば新しいサービスを、リポジトリ、パイプライン、デプロイマニフェスト、ダッシュボード、アラートがあらかじめ接続された状態で作成する、といったものです。これは意図して任意としています。特殊な要件を持つチームはこの経路を外れることができますが、その場合は、経路が担っていたはずの運用責任を自ら負うことになります。自前で構築するより速いという理由でエンジニアが選ぶようになったとき、プラットフォームは成功しています。
エンジニアリングの進め方
最も大きな制約から順に取り除くようにデリバリーの仕組みを改善し、変更のたびにその前後を計測します。
一つの変更をコミットから本番まで追跡し、すべてのステージ、待ち時間、手作業の工程を、ベースラインとなるDORAメトリクスとともに記録します。これにより、どこで時間が失われ、どこで不具合が持ち込まれているかが分かります。
ビルドを再現可能にし、不安定なテストを隔離して修正し、フィードバックが速くなるようパイプラインを再構成します。エンジニアが信頼しないパイプラインは迂回されるため、新しい機能よりも信頼性を優先します。
各サービスはイミュータブルなアーティファクトを一つビルドし、同じコードで定義された環境を順に昇格させます。設定とシークレットは、デプロイ時にマネージドストアから注入します。
SAST、依存関係、コンテナ、シークレットの各スキャンを、調整したルールと合意した重大度のしきい値とともに追加します。SBOM生成、署名、アドミッションポリシーは、ビルドが安定した後に続けて導入します。
デプロイをGitからのリコンサイルに移行し、カナリアまたはブルー/グリーンの戦略と、サービスのメトリクスに連動した自動ロールバックを組み合わせます。フィーチャーフラグによって、リリースの判断をデプロイから切り離します。
機能しているパターンを、ほかのチームが採用できるテンプレートとセルフサービスのツールにまとめます。次の改善の指針とするため、メトリクスの収集は継続します。
トレードオフ
アーキテクチャを確定する前に、お客様のチームとともに検討する問いです。
本番対応
パイプラインは、保存されたキーを一切使わず、OIDCフェデレーションと短命なトークンでクラウドプロバイダーに認証し、ジョブごとに最小権限を付与したエフェメラルランナーで実行します。ブランチ保護、必須レビュー、署名付きコミットがソースを守り、署名と来歴の検証が本番へ向かうアーティファクトを守ります。
パイプラインのキャパシティは、オートスケールするランナー、リモートビルドキャッシュ、テストシャーディングによってスケールするため、コードベースが大きくなってもビルド時間は横ばいを保ちます。再利用可能なテンプレートにより、サービス数が増えてもパイプラインの保守負担が同じ割合で増えることはありません。
すべてのデプロイをイベントとして記録し、サービスのダッシュボードに重ねて表示するため、性能や品質の悪化を、その原因となった変更に結び付けることができます。パイプラインの所要時間、キュー待ち時間、失敗の原因、DORAメトリクスを、第一級の運用データとして追跡します。
イミュータブルな単一のアーティファクトを、各ステージでの自動チェックを伴うプルリクエストによって環境間で昇格させ、本番では段階的にロールアウトします。ロールバックはGitでのrevertまたは自動的なトラフィックの切り替えであり、あらかじめリハーサルしておきます。
パイプラインは、APIとWebhookを通じて、課題管理システム、チャット、アーティファクトレジストリ、シークレットストア、脆弱性管理、変更管理の各システムと連携します。正式な変更承認が求められる場合は、手作業の工程を追加するのではなく、パイプラインが証跡を自動的に提出します。
ワークロードとお客様の既存環境に合わせて選定します。
ゼロから本番へ
アイデア
ディスカバリー
システムアーキテクチャ
UX・プロダクトデザイン
アプリケーション開発
AI・データレイヤー
クラウドインフラ
セキュリティ
QA・パフォーマンス
デプロイ
オブザーバビリティ
継続的な進化
FAQ
DevOpsは開発と運用を統合し、自動化された再現可能なパイプラインを通じてソフトウェアを届けます。DevSecOpsは、その同じパイプラインの中にセキュリティ管理策を配置します。コード解析、依存関係とイメージのスキャン、シークレット検出、署名、ポリシー適用が、すべての変更に対して自動的に実行されます。実際には、うまく構築されたデリバリーの仕組みは両方を備えており、違いは重点の置き方にあります。
適切に設計すれば、大きく遅くなることはありません。差分に対する静的解析とシークレット検出はプルリクエスト上で数秒で完了し、重いスキャンはテストと並列に、またはスケジュールで実行します。より大きなリスクはノイズです。そのため、検出結果が対処できるだけの具体性を持つようになるまで、ルールセットとしきい値を調整します。
はい。原則はツールに依存せず、また、機能しているCIシステムを置き換えることが最も価値の高い変更であることはまれです。現在お使いのツールの中で構成、速度、セキュリティを改善し、移行を推奨するのは、現行のプラットフォームが必要な機能の妨げになっている場合に限ります。
リコンサイル用コントローラーを使う形のGitOpsはKubernetesネイティブのものですが、その根底にあるプラクティスはどこにでも適用できます。あるべき状態をGitに置き、変更はプルリクエストで行い、適用を自動化し、ドリフトを検出するというものです。クラウドリソース向けのTerraformパイプラインやサーバーレスのデプロイも、クラスターなしで同じモデルに従うことができます。
パイプラインとインシデントのデータから取得した4つのDORAメトリクスを、開始時に記録したベースラインと比較します。あわせて、パイプラインの所要時間、不安定なテストの割合、エンジニアが環境を待つ時間も追跡します。これらが、主要なメトリクスが動く理由を説明するためです。
