Development × Operations

DevOps

DevOps は「早く・安全に・学び続ける」ための開発運用設計

DevOps は “特定ツール” の名前ではなく、開発と運用の分断を減らし、 自動化とフィードバックで継続的に価値を届けるための文化・プラクティス・仕組みの総称です。

CI/CD IaC Observability DevSecOps
このページで掴むこと
  • DevOps の全体像（文化・プロセス・技術）
  • 現場での流れ（PR→ビルド→テスト→デプロイ→監視）
  • 指標（DORA）と改善ポイント
※ まずは「始め方ロードマップ」だけ読んでもOK

DevOps = 文化 + 自動化 + 仕組み化

「速く出す」だけでなく「壊れにくく戻しやすい」を、チーム全体の設計として作る。

小さく・頻繁に・安全に

差分を小さくして、テストと段階デプロイでリスクを抑え、学習サイクルを速める。

運用は“後工程”ではなく“仕様”

監視・ログ・復旧手順・権限・コストまで、最初から設計対象にする。

目次

DevOps の概要

DevOps は、開発（Dev）と運用（Ops）の協働を前提にして、 リリース頻度と安定性を同時に上げるための考え方です。 重要なのは「担当の壁」ではなく、価値提供までの流れ全体（Value Stream）を最適化すること。

押さえるべき一言

「早く出す」ために運用を犠牲にするのではなく、早く安全に出せる構造を作る。

DevOps が扱う範囲

  • 開発：設計、実装、レビュー、テスト、自動化
  • リリース：CI/CD、段階デプロイ、ロールバック
  • 運用：監視、ログ、障害対応、オンコール、SLO
  • 改善：メトリクス、振り返り、負債返済

なぜ DevOps が必要？

ありがちな分断

  • 開発「動いたのでOK」→ 運用「夜間に落ちた」
  • 手順が属人化 → リリースが怖い
  • 環境差分が多い → 再現できない

DevOps が狙うこと

  • 小さい変更でリスクを下げる
  • 自動化で人為ミスを減らす
  • 観測性で「気づける」状態を作る

よくある誤解

  • 「DevOps = CI/CDツール導入」ではない（文化と運用設計が先）
  • 「スピード重視で雑になる」ではない（安全に速く出すための仕組み）

文化と原則

DevOps は “協力しよう” だけだと空中戦になりがちなので、 責務・仕組み・ルールを設計して「自然にうまく回る」形に落とします。

よく使われるキーワード

責任共有（You build it, you run it） 自動化（Automation） 継続的改善（Continuous Improvement） 透明性（Visibility） 小さく作って学ぶ

“責任共有” を成立させる条件

  • 監視・アラート・復旧手順が整っている
  • リリースが怖くない（ロールバック・段階リリース）
  • 本番に触る権限が整理され、監査可能

フィードバックループ

DevOps は「作る→出す」で終わらず、出した結果を次の改善に戻すことで効きます。

1

開発のフィードバック

PRレビュー、静的解析、テスト結果を早く返す（数分〜十数分を目標）。

2

運用のフィードバック

監視・ログ・トレースで「何が起きたか」を説明できる状態にする。

3

改善のフィードバック

振り返りで “仕組み” を直す（誰が悪いではなく、再発しない構造に）。

主要プラクティス

CI（継続的インテグレーション）

  • 小さく頻繁にマージ
  • 自動テストと静的解析
  • ビルド成果物を再利用（同じものを本番まで運ぶ）

CD（継続的デリバリー/デプロイ）

  • 安全なデプロイ（段階リリース、カナリア、Blue/Green）
  • 自動ロールバック / 迅速なロールフォワード
  • リリース手順のコード化（人の儀式を減らす）

その他

  • IaC（Terraform / CloudFormation など）
  • コンテナ（Docker）とオーケストレーション（Kubernetes）
  • 監視（メトリクス・ログ・トレース）

CI/CD の全体像

典型的な流れはこうです（規模や組織で変わります）。

パイプライン設計のコツ

  • 遅いテストは分離：PRで速いテスト、本番前に重いテスト
  • 成果物を固定：ステージングで通った成果物と同一を本番へ
  • 失敗を速く：最初にLint/型/ユニットを走らせる

サンプル（疑似 YAML）

pipeline.yml（例）
stages:
  - lint
  - test
  - build
  - deploy_staging
  - deploy_production

lint:
  run: npm run lint

test:
  run: npm test

build:
  run: npm run build
  artifacts: dist/

deploy_staging:
  run: deploy --env=staging --artifact=dist/

deploy_production:
  when: manual   # リスク次第で自動化も可
  run: deploy --env=prod --artifact=dist/

IaC（Infrastructure as Code）

サーバーやネットワーク設定を “手順書” ではなく コードとして管理します。 これにより、環境差分・属人化・再現性の問題が減ります。

IaC のメリット

  • 再現性：同じ定義から同じ環境を作れる
  • レビュー可能：変更がPRで見える
  • 監査・履歴：誰がいつ何を変えたか追える

考え方のコツ

  • 「設定値（パラメータ）」と「構造（リソース）」を分ける
  • 秘密情報はコードに埋めない（Secrets管理へ）
  • 差分適用（plan/apply）の運用ルールを決める

監視・運用（Observability）

DevOps では、障害をゼロにするよりも「早く気づき、早く戻す」が重要になりがちです。 そのために、メトリクス・ログ・トレースを揃えます。

メトリクス

数値で傾向を見る（CPU、レイテンシ、エラー率…）

  • SLI/SLO を決める
  • アラートは “行動できる条件” に絞る

ログ / トレース

原因を説明できる（何が起きた？どこで？）

  • 相関ID（requestId）で追跡
  • 構造化ログ（JSON）で検索しやすく

オンコールを成立させる工夫

  • 一次対応の手順（Runbook）を整備
  • 夜間の誤爆を減らす（通知設計）
  • 障害後に “仕組み” を改善する時間を確保

DevSecOps の考え方

セキュリティを “最後の審査” にすると遅くなりがちなので、 パイプラインに組み込んで自動化します（可能な範囲で）。

よくある組み込みポイント

  • 依存関係スキャン（脆弱性）
  • シークレット検出（キーの混入防止）
  • コンテナイメージスキャン
  • 権限の最小化（Least Privilege）
ポイント

重要なのは「止める」より「早く気づいて直せる」運用設計。 例外ルール（緊急リリース時の扱い）も決めておくと破綻しにくいです。

指標（DORAなど）

DevOps の改善は “気合” ではなく、測って直すが基本です。 代表例として DORA の4指標がよく参照されます。

指標 意味 改善の方向
デプロイ頻度 どれくらい頻繁に本番へ出せるか 小さく・安全に・自動化
変更のリードタイム コミット→本番反映までの時間 CI高速化、待ち時間削減
変更失敗率 デプロイが障害/ロールバックにつながる割合 テスト、段階リリース
復旧時間（MTTR） 壊れた後に戻すまでの時間 監視、ロールバック、Runbook

※ 指標は “評価” ではなく “改善” のために使うのがコツ（数字のための数字にしない）。

よくある失敗

ツール導入だけで終わる

CI/CDを入れたのに、運用が属人化のままで怖くて結局使われない。

アラートが多すぎる

通知疲れで誰も見ない。行動できる条件に絞る（SLOベースなど）。

本番の再現ができない

環境差分が多い。IaC、コンテナ、設定管理で差を減らす。

責任共有が口約束

オンコール・Runbook・権限設計が無いまま “よろしく” で燃える。

始め方ロードマップ

Step 1：今の流れを見える化

  • リリースまでの手順（人・待ち時間・承認）を列挙
  • 失敗しやすい点、属人化点を洗い出す

Step 2：CI を“最速で”回す

  • PRで自動テスト（ユニット＋Lint/型）
  • 失敗を速く返す（まず最初に軽いチェック）

Step 3：リリースを怖くなくする

  • ロールバック手順を固定
  • 段階デプロイ（カナリア / Blue-Green）
  • ステージングと本番の差を減らす

Step 4：運用を設計に組み込む

  • 監視（メトリクス・ログ・トレース）
  • Runbook整備
  • SLO設定（守るべき品質の定義）
現場で効くコツ

“全部やる” ではなく、いちばん痛いボトルネックを1つ潰すのを繰り返すと、 DevOps が現実的に回り始めます。

用語ミニ辞典

CI
コード変更を継続的に統合し、テスト・ビルドを自動で回す。
CD
デリバリー：本番に出せる状態まで自動化 / デプロイ：本番反映まで自動化。
IaC
インフラをコードで定義し、再現性・レビュー可能性を高める。
SLO / SLI
サービス品質の目標（SLO）と、その測定値（SLI）。アラート設計に効く。
MTTR
復旧時間。障害が起きた後、どれくらいで戻せるか。

代表的なツール例

ここは製品名の暗記ではなく、「何を自動化したいか」に応じて選ぶのがコツです。

  • CI/CD：:contentReference[oaicite:0]{index=0} / :contentReference[oaicite:1]{index=1} / :contentReference[oaicite:2]{index=2} / :contentReference[oaicite:3]{index=3}
  • IaC：:contentReference[oaicite:4]{index=4} / :contentReference[oaicite:5]{index=5}
  • 監視：:contentReference[oaicite:6]{index=6} / :contentReference[oaicite:7]{index=7}
  • コンテナ：:contentReference[oaicite:8]{index=8} / :contentReference[oaicite:9]{index=9}