システム運用の基本

2025年新卒研修資料

Transcript

1. システム運⽤の基本 2025年度 AI事業本部 新卒研修
2. 1.運⽤ってなんだろう 2.どんなシステムがある？ 3.モニタリング 4. 運営するためのプラクティス 5. 維持するためのプラクティス 6. 変化するためのプラクティス 7. クラウド運⽤のTips 8. 運⽤とエンジニアリング
3. ⾃⼰紹介 笹川 天⽃ Sasagawa Takato 株式会社サイバーエージェント AI事業本部 アドテク Div. SREグループ Embedded SRE / Enabling SRE
4. 運⽤ってなんだろう
5. ITサービスなしで⽣活できますか？
6. 今⽇使ったITサービスたち
7. ITサービスは社会インフラの時代 電気、ガス、上下⽔道、交通、通信などと同様に 当たり前に動き続けることを期待されている。
8. “当たり前に動く”の裏には？ ITサービスはアプリやウェブだけでは完結しない。 背後では数⼗〜数千台のサーバーが24/365で⽌まらず 動き続けている。 それを⽀えているのが、運⽤という仕事。
9. システムは勝⼿に⽌まるの？ “Everything fails, all the time” ーWerner Vogels. Amazon CTO 直感的には、プログラムは正しく書けば動き続ける。 → プログラムは論理的には壊れないが、 実⾏環境は常に壊れ得る。 ソフトは永遠に正しくても、 ハード‧通信‧⼈間はそうじゃない。 →だから「壊れる前提」で守る必要がある。
10. 運⽤するのは誰？ かつては「情報システム部」や「インフラチーム」 が担うことが多かった。 現在はクラウドとDevOps⽂化の浸透により役割の変化 →みんなで運⽤する時代へ 運⽤は「特定の誰かの仕事」ではなく、 サービスを提供する全員の責任
11. なぜリトライは指数バックオフ？ なぜステートレス？ なぜログを構造化？
12. 運⽤を知ると、設計の“なぜ”が⾒えてくる 障害対応の経験 → 障害を⽣みやすい設計や開発を知る キャパシティ設計‧負荷試験 → スケーラブルな設計や⾮同期処理の理解する アラート‧オンコール対応 → コードに観測性を持たせる意義がわかる etc.. 運⽤はエンジニアを成⻑させてくれる。
13. 良い運⽤を知る = 良い設計を知る
14. 運⽤に銀の弾丸はある？ 運⽤に“たったひとつの正解”はあるでしょうか？ → サービスの数‧組織の数だけ、運⽤の形がある。 正解はなくても、プラクティス（実践知）はある 先⼈の知恵を学び、組織に適⽤させる。 ゲーム ⾦融 ⼩規模アプリ ⼤規模システム スピード重視 安定重視 クラウド オンプレ 可⽤性 戦略 判断 設計
15. どんなシステムを運⽤するの？
16. 分散し複雑化していくアーキテクチャ IT初期（オンプレ中⼼‧モノリス） DevOps普及期（冗⻑構成、仮想マシン‧コンテナ） クラウドネイティブ時代（MSA、k8s、サーバーレス)
17. どんな分散がある？ ノードの分散 データの分散 地理的分散 クラウドの分散 機能的分散
18. なぜ分散させるのか 可⽤性向上（障害の局所化） → ⼀部のサービスが落ちても全体が⽌まらない スケーラビリティ（⽔平分散が可能） → ボトルネックとなる機能だけをスケールアウト 開発とデプロイの独⽴性 → チームごとに独⽴して開発‧リリースできる テクノロジー選択の⾃由度 → サービスごとに適切な⾔語‧DBなどを選択可能 変更のリスク最⼩化 → マイクロサービス単位でのロールバックやA/Bテスト 分散は複雑にすることではなく、複雑な世界に柔軟に適応するための選択肢。 → コスト‧複雑さは増すが、信頼性‧柔軟性‧スピードという価値が得られる。＝ トレードオフ
19. 複雑へ向き合う運⽤ システムが分散しているということは、監視‧障害対応‧構成管理などの運⽤もまた、分散化に対応する必要 がある。 「複雑になった世界」で、どうやってシステムを安定して動かし続けるか → 現代の運⽤が取り組む課題
20. モニタリング
21. なぜモニタリングが必要か
22. サポートデスク 「ユーザーからスマホアプリが使えないと問い合わせが来ています。」 「⾄急対応をお願いします。」 → あなたならまず、どこを⾒ますか？
23. モニタリングとは モニタリングとは システムに関する定量的なデータをリアルタイムで収集、処理、集約、表⽰すること モニタリングをしていなければ、サービスが動作しているかどうかさえ分からない。 → システム運⽤における最も重要かつ基礎 モニタリングの⽬的：気づくこと‧判断すること‧改善すること
24. 「気づく」（Detect）とは リアクティブ（事後検知） サービスに影響を与えた過去のイベントへの対応 アラートの発報：対応が必要な状態を⼈間に通知す る 障害の調査と診断：問題の原因を特定し、解決に導 く プロアクティブ（予兆検知） サービスに影響を与える将来のイベントへの対応 トレンド分析：リソース使⽤状況やサービスの健全 性の⻑期的な傾向を把握する ⽐較分析：変更前後や実験グループ間でのシステム 挙動の⽐較を⾏う モニタリングの第⼀の役割は、異常‧障害‧傾向に「気づく」こと。 「気づく」の2つのパターン
25. 何をモニタリングするのか
26. 代表的な3つのシグナルタイプ ログ タイムスタンプ付きのテキストレコー ド（構造化‧⾮構造化両⽅あり） - ⼈が読める - イベントの記録に適する - 検索‧フィルタしやすい エラーメッセージ、スタックトレー ス、ログインイベント → 出来事を追う メトリクス 実⾏時に取得される統計処理可能な数値 的な測定値 - 構造化 - 時系列データ - 集約‧⽐較しやすい CPU使⽤率、HTTPリクエスト数、DB接続 数、レイテンシ（p95など） → 状態を⾒る トレース 分散環境におけるリクエストの流れの 可視化 リクエスト単位での因果関係 - 遅延分析に最適 - 複雑な依存関係に強い ユーザーリクエスト→API→DBの処理 経路とレイテンシ → つながりを追う
27. 4つのゴールデンシグナル Googleは、分散システムの健全性を評価するために、以下の4つの主要な指標を提唱 ‧レイテンシ（Latencty） → リクエストの処理にかかる時間。遅延が⼤きいとユーザー体験を損ねる。使いづらさ ‧トラフィック（Traffic） → システムに流れるリクエストやデータの量（例：QPS、帯域幅など）。処理しきれなさ ‧エラー率（Errors） → 失敗したリクエストの割合（HTTP 5xxやアプリケーションエラーなど）。信⽤できなさ ‧飽和度（Saturation） →ステムが限界にどれだけ近づいているか（CPU使⽤率、キュー⻑など）。リソース逼迫の近さ “If you can only measure four metrics of your user-facing system, focus on these four.” （Google SRE Book, Chapter 6: Monitoring Distributed Systems） → 「もしあなたが4つしか監視できないとしたら、この4つを選べ」というくらい、優先度が⾼い。
28. ホワイトボックスとブラックボックス ホワイトボックス監視 システム内部のメトリクスを収集‧分析する⼿法 例：CPU, Memory, Disk, Network、エラーログ ブラックボックス監視 ユーザー視点でのシステムの挙動を監視する⼿法 例：HTTPレスポンスコード、ページの読み込み時 間
29. どうやってモニタリングするのか
30. メトリクス収集⼿法の違い Pull型 と Push型 メトリクスを「どのように収集するか」という仕組みの違いであり、設計⽅針‧スケーラビリティ‧セキュリティなどに影響を与え る 仕組み 主なツール例 データ形式 Pull型 収集側が対象サービスへ定期的にリクエストを送って取りに⾏く Prometheus, Zabbix (⼀部) 主にHTTPエンドポイント（例: /metrics）からテキストで Push型 アプリケーションやエージェントが、メトリクスを収集先に送信する StatsD, collectd, Cloud Monitoring, Datadog Agent 独⾃プロトコルまたはHTTP経由で送信 導⼊の容易さ セキュリティ エンドポイントを⽤意すればすぐ収集可能 エージェントやライブラリの組み込みが必要なことが多い 監視側からの通信が必要、FWやネットワーク設定が課題になることも アプリから外へ送信するため、ネットワークの制約が少ない スケーラビリティ 多数のターゲットをポーリングする負荷が収集側に集中 各サービスが分散して送信するためスケーラブルになりやすい 障害時の特性 監視対象が落ちていたらメトリクスが取れない（空⽩） メトリクスが送られなくなる → 収集側が気づかないこともある
31. アラート設計の原則：⾏動を促す通知 効果的なアラートは、以下の条件を満たす： ‧即時対応が必要なもの：ページャーなどで通知し、迅速な対応を促す ‧対応が必要だが緊急性が低いもの：チケットとして記録し、計画的に対応する ‧情報提供のみ：ログとして記録し、将来的な分析やトレンド把握に活⽤する
32. 運営するためのプラクティス
33. “Good intentions never work, you need good mechanisms to make anything happen” — Jeff Bezos. Amazon CEO 良い意図だけではうまくいかない。何かを成し遂げるには、良い仕組みが必要 だ
34. システムは⽇々、⾊々なことが起きる サーバのCPU使⽤率が急に上がったり、ログインエラーの問い合わせが来たり、 なんとなく不安定な状態が続いたり── システム運⽤の現場では、毎⽇のように「何か」が起きる。 すべて⼀括りに「トラブル」として扱ってしまうと、何を優先して対応すべきかが ⾒えづらくなり、チームの連携もうまくいかない。 → それぞれの出来事を「意味」に応じて分類し、仕組みのなかで取り扱う。 ここではサービスを運営するためのイベント、インシデント、プロブレム、サー ビスデスクのプラクティスを紹介する。
35. イベントとインシデントとプロブレム イベント インシデント プロブレム 異常検知 原因分析
36. Event: 状態の変化を取り扱う イベント インシデント プロブレム 異常検知 原因分析
37. システムの様々な状態の変化をイベントという形で記録し取り扱う。 → 変化を監視‧フィルタリングし、必要に応じてインシデントにエスカレーションすることで、組織で対応し やすい形にする。 イベントを分類する例 情報（Information） 状態‧結果の記録、対応不要（バックアップ成功、ユーザーのログイン） 警告（Warning） 状態の悪化、潜在的な問題の兆候、対応必要な場合がある（CPU使⽤率が80%に達した） 例外（Exception） 重要なエラー条件に該当している、対応必須（アプリケーションがダウン、ネットワーク切断） 状態の変化を記録し、分類する
38. イベントのライフサイクル 検知 記録 フィルタリングと逸脱 検知 分類と優先度付け 通知とエスカレーショ ン 対応‧記録‧クローズ イベントはモニタリングツールやエージェントなどから発⽣ イベントを記録（ログ）として保存 対応が必要かを判断 また複数のイベントを相関づけて1つの事象としてまとめる 情報‧警告‧例外のどれかに分類 イベントに応じて⾃動通知や⼿動エスカレーションを実施 例外イベントであればオンコールエンジニアにページング 対応内容を記録し、クローズ
39. イベントのライフサイクル 検知 記録 フィルタリングと逸脱 検知 分類と優先度付け 通知とエスカレーショ ン 対応‧記録‧クローズ イベントはモニタリングツールやエージェントなどから発⽣ イベントを記録（ログ）として保存 対応が必要かを判断 また複数のイベントを相関づけて1つの事象としてまとめる 情報‧警告‧例外のどれかに分類 イベントに応じて⾃動通知や⼿動エスカレーションを実施 例外イベントであればオンコールエンジニアにページング 対応内容を記録し、クローズ 運⽤が成熟したら⾃動化
40. イベントはエスカレーションするための土台 → 障害を管理するのはインシデント管理の役割へ
41. Incident: 障害を取り扱う イベント インシデント プロブレム 異常検知 原因分析
42. インシデントとは 通常のサービス提供を妨げる、またはその可能性のある事象 例）Webサーバが落ちてアクセス不能、認証サービスが異常でログイン不可、DB接続がタイムアウト インシデントを管理する⽬的 ‧サービスをできるだけ早く復旧させる ‧ビジネス影響を最⼩限に抑える ‧ユーザー満⾜度を維持する
43. インシデントのライフサイクル 検知と登録 分類と優先度判定 エスカレーション 調査と初動対応 解決と復旧 クローズ 監視‧問い合わせ/通報‧エンジニアの気づきやオペレーション時のエラー チケットの起票 分類やカテゴリ付け（ネットワーク障害 / ハードウェア / アプリケーション / 外部要因など） 優先度の決定（影響度 × 緊急度） 技術エスカレーション：解決不能‧不明 → 上位技術者、別チームへ 管理エスカレーション：重⼤度に応じてマネジメントや他部署へ通知 情報収集：ログ、監視データ、再現⽅法、直前の変更履歴など 回避策の検討：恒久対策が不明でも、⼀時的にサービスを回復させる⼿段 恒久対策があれば適⽤ 復旧の確認 通報者‧関係者に確認を取り、「解決済み」で合意
44. インシデントのライフサイクル 検知と登録 分類と優先度判定 エスカレーション 調査と初動対応 解決と復旧 クローズ 監視‧問い合わせ/通報‧エンジニアの気づきやオペレーション時のエラー チケットの起票 分類やカテゴリ付け（ネットワーク障害 / ハードウェア / アプリケーション / 外部要因など） 優先度の決定（影響度 × 緊急度） 技術エスカレーション：解決不能‧不明 → 上位技術者、別チームへ 管理エスカレーション：重⼤度に応じてマネジメントや他部署へ通知 情報収集：ログ、監視データ、再現⽅法、直前の変更履歴など 回避策の検討：恒久対策が不明でも、⼀時的にサービスを回復させる⼿段 恒久対策があれば適⽤ 復旧の確認 通報者‧関係者に確認を取り、「解決済み」で合意 調査を始める前に エスカレーション！ 初動は原因不明でも 復旧すれば良い！
45. イベントとアラートとページ Event Alert Page 📘 Event：システム内で発⽣した事象の記録（例: CPU使⽤率80%） → 発⽣条件：すべての状態変化 →対応必要性：モニタリングや分析⽤途。通常は対応不要 ⚠ Alert：事前に定義した条件に合致した通知（例: CPU使⽤率が90%以上） → 発⽣条件：SLI/SLO違反の兆候 →対応必要性：対応を検討する状態。⼈間への通知もあり 🚨 Page：重⼤なインシデント時に即時対応を求める通知（例: サービスダウ ン） → 発⽣条件：クリティカルな障害 →対応必要性：今すぐ⼈が対応すべき状態。On-callが起こされる
46. インシデントは最短で正常に戻すこと → 原因を深く追求するのはプロブレム管理の役割へ
47. Problem: 原因究明を取り扱う イベント インシデント プロブレム 異常検知 原因分析
48. 根本原因の特定と恒久的な解決策の実装 インシデントの根本原因を特定し、再発防⽌や影響の軽減を図るプロセス → 障害を「直す」ことではなく、「なぜ起きたのか」を突き⽌めて「⼆度と起こさない」ための活動 インシデント管理 ⽬的：サービスを素早く復旧させる 時間軸：今すぐ対応 優先順位：ビジネス影響の⼤きさ基準 プロブレム管理 ⽬的：原因を明らかにし、再発を防ぐ 時間軸：後からしっかり分析 優先順位：再発頻度や恒久性⽋如が基準
49. プロブレムのライフサイクル 識別 記録と分類 調査と診断 回避策の提供 既知のエラーの登録 恒久的な解決策の実装 インシデントの傾向や関係者からの報告や監視ツール、予防的分析を通じて問題を特定 問題チケットを作成し、影響度‧緊急度で優先順位を設定。 根本原因分析を実施。 恒久的な解決策がまだない場合は、 サービスの影響を緩和するために⼀時対応（暫定対応）を⽤意する。 原因が特定されたら既知のエラーとして管理。 修正案を変更管理のプロセスに提出し、正式に展開。 恒久対応完了後にクローズ
50. プロブレムのライフサイクル 識別 記録と分類 調査と診断 回避策の提供 既知のエラーの登録 恒久的な解決策の実装 インシデントの傾向や関係者からの報告や監視ツール、予防的分析を通じて問題を特定 問題チケットを作成し、影響度‧緊急度で優先順位を設定。 根本原因分析を実施。 恒久的な解決策がまだない場合は、 サービスの影響を緩和するために⼀時対応（暫定対応）を⽤意する。 原因が特定されたら既知のエラーとして管理。 修正案を変更管理のプロセスに提出し、正式に展開。 恒久対応完了後にクローズ 未知のエラー 既知のエラー
51. プロブレムの2つのタイプ プロブレムはインシデント起因（リアクティブ）のみではなく、 未発⽣（プロアクティブ）のものも同じライフサイクルで管理する。 リアクティブ問題管理：発⽣したインシデントをもとに問題を特定‧解決する。 プロアクティブ問題管理：インシデントが起きる前に傾向分析やリスク評価から問題を特定し、未然に防ぐ。
52. サービスデスクと問い合わせ対応 サービスデスクとはユーザーからの問い合わせの最初の窓⼝ インシデント リクエスト 「アカウントを作って下さい。」 「システムにアクセスできない。」 「メンテナンス時間を教えて。」 「こんな機能を追加して。」 「以前にも同じ障害が起きている。」 「このサービス最⾼です。」 プロブレム 問い合わせの返答や分類を⾏う
53. 維持するためのプラクティス
54. サービスを維持するためには サービスは様々な要因で継続困難な状況になる。 • ハードウェアが壊れる • ディスクフルでデータの書き込みができない • 地震‧⽕事‧⽔害などの⾃然災害が起きる • システムに侵⼊されて暗号化される → 故障や災害やクラッカーを無くすことはできないが予測し、備えることはできる。 ここではサービスを維持するための可⽤性、キャパシティ、災害復旧、セキュリティ のプラクティスを紹介する
55. 可⽤性
56. 可⽤性とは何か どれほど⾼機能で⾰新的なサービスであっても、それが「使える状態」になければ、ユーザーにとっては価値の ないになってしまう。 使える状態を評価するのが可⽤性（Availability） → 現代のシステム運⽤において最も基本的かつ重要な指標のひとつ。 可⽤性の定義やその測定⽅法、可⽤性を向上‧維持するためのアプローチについて解説する。
57. 可⽤性を稼働率から計算する 可⽤性(Availability)は、サービス提供時間における稼働時間(uptime)と停⽌時間(downtime)に基づく単純な計 算式(稼働率)で表されることが多い。 例）⽉に720時間サービスを提供する予定だったが、障害で3時間停⽌ → 可⽤性は(717/720) ×100 = 99.58% 障害の確率は0.42% またサービスが使⽤できないダウンしている確率(Failure)は、以下で計算できる。 出典：AWS Whitepapers「可用性について」より引用
58. よく使われる可⽤性⽬標の⽬安 可⽤性 年間停⽌時間 99.9% ("three nines") 99.99% ("four nines") 8.76 hour 99.999% ("five nines") 52.56 min 5.26 min ⽉間停⽌時間 43.2 min 4.32 min 25.9 sec サービス SaaS、クラウドサービス CRM、ERP、Multi-AZ 医療‧⾦融‧航空
59. 稼働時間、停⽌時間を測定する MTTR：Mean Time To Repair（平均修復時間） MTBF：Mean Time Between Failure（平均故障間隔）
60. よくある可⽤性の誤解 実際のシステムはサーバーが1つあるわけではなく、複数のコンポーネントが依存関係を持って機能（ワーク ロード）している。 この時のサービスAの可⽤性は...低い⽅に合わせて99.5%にしておけば良い？ Server Database Client 99.5% 99.9% サービスA 99.5%
61. 依存関係のある可⽤性 ワークロードの可⽤性は全ての依存関係の可⽤性(a)の積になる。 Server Database Client 99.5% 99.9% サービスA 99.4% × 従ってサービスAの理論上の最⼤可⽤性は(0.995 × 0.999) ×100 = 99.4% 誤って99.5%を⽬標にしてサービスを提供すると、絶対に達成できない可⽤性になってしまうので注意。
62. 冗⻑化し可⽤性を向上する Server Database Client 99.9975% 99.9% サービスA 99.8975% サービスAの可⽤性を上げる必要がある時、システムを冗⻑化する必要がある。 サーバーのスペアを1つ追加し、2つ並べた時の可⽤性 Server Server 99.5% Server 99.5% Servers 従ってサーバーの可⽤性 1 - (1-0.995)×(1-0.995) = 0.999975 サービスAの可⽤性は99.8975%と上げることができる。
63. 単⼀障害点を減らす Server Database Client 99.9975% 99.9% サービスA 99.8975% それが壊れるとシステム全体が停⽌してしまう構成要素を 単⼀障害点（SPOF, Single Point of Failure)という。 可⽤性設計におけるSPOFの放置は、あえて地雷の上にインフラ を築いているようなもの。 Server ❌ ❌ ❌ 🟢 ❌
64. 冗⻑化はコストとの相談 SPOFを減らすことで可⽤性を上げることができますが、冗⻑性を上げるとコストも増加するので注意 Server Database Client Server Database Client 99.9975% 99.9% サービスA 99.8975% Server 99.9975% 99.9999% サービスA 99.9986% Server Database サービスAでは年間で約8時間51分のダウンする可能性を削減できるが、DBのコストが２倍になる。 → ⾮機能要件としてビジネス⾯での判断が必要 ❌ ❌ ❌ ❌ 🟢 🟢 🟢 ❌ ❌ 🟢 🟢
65. 可⽤性と稼働率は同義？ 可⽤性と稼働率は同じ意味で使われることが多いが、厳密には同義ではない。 可⽤性（Availability）はユーザーが必要なときに使えるか 稼働率（Uptime）はシステムが動いていた時間の割合 ユーザー視点かシステム視点か →完全停⽌した時間以外でも障害、性能劣化、部分停⽌などでユーザー体験は損なわれる。 ユーザー体験や、サービスの価値提供を定量化する指標が必要。 → SLI/SLOへ
66. キャパシティ‧パフォーマンス
67. サービスの限界を把握する ITサービスにはユーザー数の拡⼤や、データ量の増加により 性能が劣化し始める限界点が存在する。 限界を知らずに運⽤をすると、 ‧遅い ‧繋がらない ‧落ちた と可⽤性を落とす結果となる。 →限界を管理し、予測を⽴て、対策を取る必要がある。 船にも積載量の限界がある
68. キャパシティとパフォーマンス キャパシティ：「どれだけの量を処理できるか」という上限値のこと。 ‧Webサーバーが1秒間に捌ける最⼤リクエスト数（例：2,000req/sec） ‧データベースが同時に処理可能な接続数（例：100 connections） ‧ストレージの残容量（例：80%使⽤中、残り20%） パフォーマンス：「実際にどの程度うまく処理できているか」という現在の動作状況のこと。 ‧平均レスポンスタイム（例：120ms） ‧CPU使⽤率（例：72%） ‧DBクエリの成功率、レイテンシ、エラー率（例：99.9%成功、平均300ms）
69. サービスの3つのキャパシティ ビジネスの将来計画のように事業に係るキャパシティ （例：ビジネス需要（売上計画、キャンペーンなど）） Business Capacity Service Capacity Component Capacity SLAを満たすことができるサービスの処理可能なキャパシティ （例：99.9% の可⽤性、平均レスポンスタイム < 200ms) インフラの各構成要素のキャパシティ （例：DB、CPU‧メモリ、ネットワークなど）
70. 限界を予測し⾒積もる Business Capacity Service Capacity Component Capacity 将来の必要なキャパシティを予測する ビジネス‧開発‧運⽤が恊働して取り組む必要がある → Capacity Planning
71. 限界を試験する 負荷試験を実施し、システムのキャパシティやパフォーマンスを確認する。 負荷試験の種類 ‧スモークテスト（Smoke Test） ‧通常負荷テスト（Average-load Test） ‧ストレステスト（Stress Test） ‧ソークテスト（Soak Test） ‧スパイクテスト（Spike Test） ‧ブレイクポイントテスト（Breakpoint Test） 出典：Grafana docs「Load test type」より図を引用
72. 災害復旧
73. サービスの継続と復旧を計画する サービスは通常利⽤によるキャパシティの限界以外にも、継続困難な状況になる可能性がある。 • 地震や洪⽔などの⾃然災害 • 停電やネットワーク接続などの技術的な障害 • 不注意による設定ミス、不正な/外部のアクセスや変更などの⼈為的⾏動 → これらをディザスタ、もしくは災害として扱い、復旧戦略を検討する必要がある。
74. 事業継続計画と災害復旧計画 BCP：Business Continuity Plan（事業継続計画）= ビジネス⾯での復旧計画 DRP：Disaster Recovery Plan（災害復旧計画）= システム⾯での復旧計画 内容 対象 例 BCP（事業継続計画） 災害‧障害時でも事業を⽌めないための総合的な計画 ⼈‧拠点‧通信‧物流‧システムなど広範囲 代替オフィスの確保、BC通話網の整備、⼿動業務への切替など DRP（災害復旧計画） システム障害などからITサービスを復旧させるための具体策 システム‧データ‧インフラに特化 バックアップポリシー、DRサイトへのフェイルオーバー → DRPはBCPという全体計画の⼀部であるべき。
75. サービスの復旧⼒を計測する 指標 RTO：Recovery Time Objective（⽬標復旧時間）＝復旧に要する時間 RPO：Recovery Point Objective（⽬標復旧時点）＝許容できるデータ損失期間 出典：AWS Whitepaper「事業継続計画 (BCP)」より図を引用
76. 対象 測定対象 単位 可⽤性（Availability） 通常運⽤中のサービスの状態 MTBF、MTTR 時間平均（例：1ヶ⽉、1年など） 災害復旧（Disaster Recovery) ⼀度限りのイベント（災害‧障害など） RTO、RPO 単発のインシデントに対する応答 ⽬的 例 常時にサービスを常に使える状態に保つこと 異常時にサービスを復旧すること 年間稼働率99.9%を維持する 災害後にバックアップから復旧する 可⽤性と災害復旧の違い どちらも回復⼒戦略の⼀部であるが可⽤性と災害復旧は測定、焦点、⽬的などが異なる。
77. 復旧戦略：Backup&Restore バックアップとリストア 概要: 最も基本的なDR戦略。定期的にデータをバックアッ プしておき、障害発⽣後にそれを使って復旧する。 メリット: コストが低い。 デメリット: 復旧に時間がかかる（RTOが⻑い）、定期バッ クアップ間のデータが失われる可能性あり（RPOも⻑ い）。 例: オンプレミスやS3などに定期的にDBダンプを保存し、 障害発⽣時に新しい環境に復元。 出典：AWS Whitepaper「クラウド内での災害対策オプション」より図を引用
78. 復旧戦略：Pilot Light パイロットライト 概要: 最⼩限のインフラ（DBや基本サービス）を常時稼働 させておき、障害時に必要なアプリケーションやフロント エンドをスケールアウトして復旧する戦略。 メリット: コストと可⽤性のバランスが取れている。 デメリット: 完全復旧までにやや時間がかかる。 例: 常時起動のRDS + 停⽌中のEC2群 → 障害発⽣時にEC2を 起動して復旧。 出典：AWS Whitepaper「クラウド内での災害対策オプション」より図を引用
79. 復旧戦略：Warm Standby ウォームスタンバイ 概要: サービスの簡易版を常にセカンダリサイトで稼働させ ておき、障害時には切り替えてトラフィックを流す戦略。 アプリは動いているが処理能⼒は制限されていることが多 い。 メリット: ⽐較的短いRTO/RPO。 デメリット: パイロットライトよりコスト⾼。 例: 東⻄2リージョンで⽚⽅にリードレプリカと縮⼩構成の アプリが常時待機。 出典：AWS Whitepaper「クラウド内での災害対策オプション」より図を引用
80. 復旧戦略：Multi-site Active/Active マルチサイト‧アクティブ/アクティブ 概要: 複数のサイトで本番トラフィックを常時処理してお り、⼀⽅に障害が発⽣しても即座にもう⼀⽅が処理を継続 できる戦略。 メリット: ⾼可⽤性‧短いRTO/RPO。 デメリット: ⾮常に⾼コスト、設計と整合性管理が難しい。 例: 東京‧⼤阪に同構成のシステムを配置し、DNSやロード バランサで分散。 出典：AWS Whitepaper「クラウド内での災害対策オプション」より図を引用
81. 待機系の扱い⽅の違い システムやサービスの冗⻑構成や災害復旧において、どのように待機系を扱うかを2つに分類する。 active/passive戦略 通常時：⼀⽅だけが稼働、もう⼀⽅は待機 障害時：待機系を起動‧切り替え（⼿動 or ⾃動） 構成例：メインDB＋レプリカ、アプリ待機ノードなど RTO：中程度（数分〜） コスト：低〜中（待機系の分だけ節約可能） 運⽤の複雑さ： 低〜中（シンプルな設計が可能） active/active戦略 通常時：両系が稼働し、負荷分散される 障害時：⽚系に⾃動でフェイルオーバー（処理継続） 構成例：マルチAZ構成で両⽅のサーバーがリクエストを処理 RTO：⾮常に短い（ほぼゼロ） コスト：⾼い（常時2系統動作） 運⽤の複雑さ：⾼い（整合性管理が難しい） →「待機系がいるかどうか」ではなく、「待機系が通常時に処理するかどうか」という観点
82. 災害復旧の戦略とコスト 出典：AWS Whitepapers「クラウド内での災害対策オプション」より図を引用 災害復旧のRTO‧RPO減らすほどコストがかかる。
83. セキュリティ
84. セキュリティ脅威の変化 かつての主な脅威はウイルスやマルウェアだったが、今はゼロデイ攻撃‧サプライチェーン攻撃‧ランサム ウェア‧内部不正などが常態化。 技術の進歩により「安全だったやり⽅」が急に無防備になる（例：TLS 1.0の⾮推奨）。 → セキュリティは「変わらない正解」ではなく「動的な最適解」を継続的に追う必要がある。
85. セキュリティを考える ITIL ISO/IEC 27001 NIST SP 800 シリーズ 基準/ フレームワーク 主な⽤途‧背景 ITサービス運⽤全体に対するフレームワーク 情報セキュリティ管理の国際標準（認証⽬的で採⽤されやすい） ⽶国政府‧軍向けのガイドライン、⺠間にも普及中 CIS Controls ゼロトラストモデル 実⽤的なセキュリティ対策のチェックリスト 境界防御を前提としない設計思想 SOC 2 OWASP SaaS企業がよく使う、内部統制レポート Webアプリケーションの脅威対策に特化 セキュリティのプラクティスは複数のフレームワークや基準が共存している → 分野‧業種‧国‧会社の規模によって「参照すべき基準」が異なる
86. セキュリティが「運⽤」から「設計」へシフト かつて： ウイルス対策ソフトを⼊れて、アクセス制限をしておけばよかった いま： • クラウドベースのゼロトラスト設計 • DevSecOpsとしてCI/CDパイプラインに組み込み • コードレベルで脆弱性スキャンやSBOM（ソフトウェア部品表）を管理 → 運⽤ルールだけでなく、開発⼯程そのものにセキュリティが組み込まれる。
87. CVEとは？ CVE（Common Vulnerabilities and Exposures） とは 既知の脆弱性に⼀意の識別番号を割り振ったデータベースのこと CVEの⽬的 • 世界中で報告されるソフトウェアやハードウェアの脆弱性を⼀元管理する • 各ベンダー‧セキュリティベンダー‧管理者の間で共通⾔語として使えるようにする • 脆弱性管理、リスク評価、⾃動スキャンツールとの連携を可能にする CVEの命名形式 CVE-年(脆弱性が登録された年)-番号(ユニークな通し番号) 例: CVE-2021-44228（Apache Log4j の深刻な脆弱性） この他にもCVSS、NLB、JVN、OSVなどや、ベンダー独⾃のデータベースがある。
88. 変化するためのプラクティス
89. 構築
90. 構築し、変更し、届ける 変更 デプロイ リリース 構築 サービスを提供するためには、システムが動く実⾏環境を構築する必要があります。 また1度構築したら終わりではなく、⽇々変化するビジネスの要求に合わせ変更していかな ければいけません。 → 変更を安全にユーザーまで届けるのは意外と難しい ここでは構築、変更、デプロイ、リリースのプラクティスを紹介していきます。
91. インフラを構築する サービスを動かすインフラは誰が構築するでしょう？ 多くのケースでは専任のインフラエンジニアやSREが⾏っています。 しかしDevOpsでは”構築した者が運⽤する”というアプローチがあります。 “You build it, you run it.” ーWerner Vogels. Amazon CTO 出典：Atrassian「Is ‘you build it, you run it’ living up to the hype?」より引用
92. ⼿作業でのインフラ構築は⼤変 サービスの実⾏環境であるインフラを構築するのは⼤変 従来はパラメーターシート‧作業⼿順書などを作成し、1つ1つ⼿動で構築していた 設計 ネットワーク設定 マシン設定 OS/MW設定 ランタイム設定 アーキテクチャ決定 命名規則作成 インフラ定義書作成 etc.. 仮想ネットワーク作成 セキュリティ設定 ルーティング設定 etc.. VM作成 ストレージ作成 ロードバランサー作成 etc.. OS設定 Kernel更新 ミドルウェア設定 etc… ランタイムのインストール 環境変数の設定 ログ設定 etc.. ‧複雑なシステムは⼿順が多く、構築に⽇数がかかる。 ‧⼈間はミスをする、担当者に属⼈化する。 ‧構築に時間がかかるというのは壊せないということ。→ 変更‧更新が困難。
93. コード化し、再現性と⼀貫性を担保 設計 ネットワーク設定 マシン設定 OS/MW設定 ランタイム設定 アーキテクチャ決定 命名規則作成 インフラ定義書作成 etc.. 仮想ネットワーク作成 セキュリティ設定 ルーティング設定 etc.. VM作成 ストレージ作成 ロードバランサー作成 etc.. OS設定 Kernel更新 ミドルウェア設定 etc… ランタイムのインストール 環境変数の設定 ログ設定 etc.. Terraform, CloudFormation, CDK, Pulumi Ansible, Chef, Docker, Puppet Vagrant, Packer IaC(Infrastructure as Code）によって、プログラムと同様にインフラ構成もコードによって管理する →ソースコード開発と同じ開発フローで設定や構築⽅法を管理できる。 ‧簡単に構築でき、簡単に破棄できる再現可能なインフラ環境を構築できる。 ‧構築の冪等性が担保され、標準化‧⾃動化できる。 ‧可読性‧レビュー可能性‧バージョン管理ができ、ロールバックができる。 → 変更‧更新が容易
94. コンテナ化 特徴： • アプリケーションとその依存関係をパッケージ化して移植性を⾼めたもの • 実⾏環境として Docker などを使⽤ • Kubernetes や ECS などでオーケストレーションされることが多い 代表例： Docker、Podman、Kubernetes 利点： • 開発環境と本番環境の差異を⼩さくできる • ⼤規模‧⻑時間稼働のアプリケーションに向いている • 複数のサービスをまとめてデプロイ‧管理できる 設計 ネットワーク設定 コンテナ設定 マシン設定
95. サーバーレス 特徴： • サーバー管理が不要（インフラはクラウド側が全⾃動で管理） • イベント駆動で動く（例：HTTPリクエスト、S3にファイルがアップロードされたなど） • 処理が完了すればリソースは解放され、使った分だけ課⾦される 代表例： AWS Lambda、Cloud Run Functions、Azure Functions 利点： • スケーリングが⾃動 • ⼩さな処理単位（マイクロ関数）に適している • 初期コストやオーバーヘッドが少ない 設計 サーバーレス設定
96. 変更
97. ITシステムは、インフラのパラメータ調整、OSやミドルウェアの更新、アプリケーションの機能追加やバグ修 正などを通じて、常に変化し続ける必要がある。 ⼀⽅で、変更はサービスの不具合や障害を引き起こすリスクを伴う。 リスクを適切に制御するには、変更を管理下に置く必要がある。 ただし、承認プロセスを過剰に増やすと、⼯数だけが膨らみ、ビジネススピードに追従できなくなる。 変更にはリスクがある ジョブ実⾏に社⻑の承認まで必要なっていく
98. 変更を分類し、プロセスを分ける すべてに⼀律のプロセスを適⽤のではなく、変更をリスクや緊急度によって分類し、レビューや承認のプロセ スを分ける。 ITILによる分類の例 標準変更（Standard Change） ：リスクが低く繰り返し発⽣する変更  事前承認や⾃動化が可能 通常変更（Normal Change） ：リスクの評価と承認が必要な変更  重⼤度や影響度に応じて承認レベルを変える 緊急変更（Emergency Change） ：サービス中断を避けるため、迅速に実施すべき変更 簡略化された承認プロセスや事後レビューで対応 セマンティックバージョニングやGit Flow, GitHub Flowなど
99. デプロイ
100. 安全にデプロイをする 変更は本番環境へ確実に反映することで、初めて価値を提供できる。 ⼀⽅で、デプロイはタイミングや⼿順を誤ると、サービス停⽌や障害につながるリスクを含む。変更そのもの の妥当性とは別に、「どのように、いつ、どこに展開するか」が運⽤の信頼性を左右する。 デプロイは、変更の内容を正しく反映し、必要に応じて迅速なロールバックが可能な状態を整えることで、 サービスの可⽤性と継続性を⽀える。
101. 段階的なデプロイ ステージング環境 本番に近い条件での検証 開発環境 機能開発や初期テスト 本番環境 ユーザーへのサービス提供 新機能の実装やバグ修正 単体テストやローカル確認 本番環境と同等の構成‧ データ（仮）で動作確認 統合テスト、受け⼊れテス ト、負荷試験 SLA/SLOを満たすか確認 本番環境に変更を最初からデプロイするのではなく、複数の環境を⽤いて試験を⾏い、段階的に適⽤していく。
102. 変更を⼩さく、早く、頻繁に届ける リスクの影響を⼩さくするためには、変更を⼩さく、早く、頻繁にデプロイしたい。 → ⼿動プロセスでは限界がある。変更‧デプロイ作業から⼿動作業の排除し、⼀貫性のある⾃動化をする。 これを実現するのが CI（継続的インテグレーション） および CD（継続的デリバリー / デプロイメント） 継続的インテグレーション(Continuous Integration) 継続的デリバリー/デプロイメント (Continuous Delivery/Deployment) BUILD TEST MERGE RELEASE TO REPOSITORY DEPLOY TO PRODUCTION 継続的インテグレーション 継続的デリバリー 継続的デプロイ 「誰でも‧いつでも‧安全にリリースできる」⽂化 → デリバリーの⺠主化
103. デプロイ戦略の紹介 停⽌ LB 旧version 新version 新version LB 旧version 新version ❌ ビックバンデプロイ ローリングデプロイ Blue-Greenデプロイ
104. ビックバンデプロイ 適⽤例：⼩規模アプリや緊急パッチ、夜間のメンテナンスなど 特徴：旧バージョンを停⽌し、新バージョンを同じ環境に⼀括適⽤する ダウンタイム：発⽣する可能性あり リスク：⾼い（障害が出たら即影響） 切り戻し：困難（元に戻すには旧バージョンを再デプロイ） コスト：低い 実装難度：低〜中 旧version 停⽌ 新version
105. ローリングデプロイ 適⽤例：KubernetesのDeploymentなどで広く採⽤ 特徴：インスタンス（Pod、VMなど）を順番に新バージョンへ置き換えていく ダウンタイム：基本ゼロ（同時に旧バージョンも稼働） リスク：中〜低（徐々に影響範囲が広がるため、早期検知可能） 切り戻し：途中で中⽌すれば残った旧バージョンが⽣きている∕もしくはロール バック戦略が必要 コスト：低い 実装難度：低い LB 旧version LB 旧version 新version LB 新version
106. Blue-Green デプロイ 適⽤例：ミッションクリティカルなサービス、⼤規模サービスの更新 特徴：旧バージョン（Blue）と新バージョン（Green）の2つの本番環境を⽤意し、 スイッチで切り替える ダウンタイム：ほぼゼロ リスク：低い（トラフィック切り替え後も旧環境は維持される） 切り戻し：容易（DNSやLBを旧環境に戻すだけ） コスト：⾼い 実装難度：低〜中 LB 旧version LB 旧version 新version LB 旧version 新version ❌
107. リリース
108. デプロイとリリースの違い デプロイ 意味：コードや構成を環境に配置する 主体：開発者‧インフラチーム‧CI/CD タイミング：技術的に配置された瞬間 例：機能は配置済だが⾮表⽰（Feature Flag OFF） リスク：サービスに即影響しない場合もある リリース 意味： 配置された機能をユーザーに公開する 主体：プロダクトオーナー‧サービスマネージャー タイミング：ビジネス都合に合わせて調整される 例：機能がUIに反映される、Feature Flagを有効化 リスク：ユーザーが使い始めるため影響が⼤きい ほぼ同じ意味に⾒えるが、なぜ分けるのか？
109. デプロイとリリースを分けて考える 配置と公開を分けることで、不具合が出ても公開前に検出できる リスク制御 段階的公開 ⾃動化対応 ⼀部ユーザーのみリリースするなど戦略的リリースが可能 デプロイはCI/CDで頻繁に実⾏、リリースは意図的に調整
110. Feature Flag ”Feature Toggles (often also referred to as Feature Flags) are a powerful technique, allowing teams to modify system behavior without changing code.” - Pete Hodgson フィーチャーフラグとは、コードを変更することなく システムの振る舞いを変えることができる強⼒なテクニックである 出典：Pete Hodgson「Feature Toggles (aka Feature Flags)」より引用
111. リリース戦略の紹介 LB 旧version 新version 90% 10% LB 旧version 新version トラフィックをコピー ❌ カナリアリリース ダークローンチ
112. カナリアリリース 適⽤例：ユーザー影響を最⼩限にしたいミッションクリティカルな更新、段階的 ロールアウトに対応したCD基盤で有効 特徴：新バージョンをまず⼀部のユーザーやトラフィックに限定して展開し、問題 がなければ段階的に全体へ広げる ダウンタイム：ゼロ リスク：最⼩（早期に問題を発⾒できる） 切り戻し：少量配信の段階で異常を検知すれば即座に停⽌‧巻き戻し可能 コスト：中 実装難度：⾼い LB 旧version LB 旧version 新version LB 新version 90% 10%
113. ダークローンチ 適⽤例：新機能の事前パフォーマンス検証や社内QA、Feature Toggleによる段階的 展開 特徴：新機能のコードは本番にすでにデプロイされているが、ユーザーには⾒せず に動作‧検証だけ⾏う。その応答は破棄。 ダウンタイム：ゼロ リスク：ゼロ（ユーザーに影響しない） 切り戻し：コードの露出がないため、機能レベルで容易に無効化できる（Feature Flag活⽤） コスト：中 実装難度：⾼い LB 旧version LB 旧version 新version トラフィックをコピー ❌
114. クラウド運⽤のTips
115. クラウドも落ちる 出典：ITmedia News「15日のAWS東京リージョン障害、原因は「主電源と2次電源の遮断」」より引用 出典：Publickey「Google Cloud、顧客のシステムを間違って全削除した大規模障害の原因を報告。プライベート ラウドの期間を1年と設定ミス」より引用
116. Tips:クラウドに移しても、すべての責任は移らない 出典：AWSブログ「GxP ソリューションへの AWS 共有責任モデルの適用」より引用 © Amazon Web Services, Inc. クラウドに移しても、全ての運⽤責任がなくなるわ けではない。 クラウドプロバイダーが出している責任共有モデル を確認し、クラウドの責任境界を理解した上でサー ビス提供をする必要がある。
117. Tips:運⽤の⼿間をプロバイダに任せられるサービス マネージドサービスを活⽤することで、運⽤をプロ バイダに移譲し、⼿間や負担、⼈件費を軽減し開発 に集中することができる。 しかし柔軟性の制限やベンダーロックイン、コスト 増加とトレードオフであることに注意 出典：AWSブログ「GxP ソリューションへの AWS 共有責任モデルの適用」より引用 © Amazon Web Services, Inc.
118. Tips:Well-Architected フレームワーク 出典：Google Cloud アーキテクチャセンター「セキュリティ：共有責任と共有運命」より引用 © Google LLC ⾼可⽤‧⾼信頼‧セキュア‧効率的などクラウ ドアーキテクチャを実現するためのベストプラ クティス集 ほとんどの設計はWell-Architectedに従って設計 することで、そのクラウドにとって最も最適な形 で設計ができるようになる。
119. Tips:多要素認証（MFA）でログインする クラウドは不正に侵⼊されると、⼀瞬で数千万円を消費できるため、ログインはセキュアに⾏う。 Microsoft Entra による実際の攻撃データに基づく最近の研究では、MFA が侵害のリスクを 99.2% 低減する。 Multi-Factor Authentication（MFA)：多要素認証 異なるカテゴリの認証要素を2つ以上組み合わせる認証⼿法 主な認証要素の3分類： 知識要素：知っているもの（例：パスワード、PIN） 所持要素：持っているもの（例：スマホ、セキュリティキー） ⽣体要素：⾝体的特徴（例：指紋、顔、声） 出典：Microsoft「2023 年 Microsoft デジタル防衛レポート」より引用 出典：akamai「クラウド MFA ソリューションでアプリケーションを保護」より引用
120. Tips:最⼩権限の原則を適⽤する 最⼩権限の原則：Principle of Least Privilege（PoLP） ユーザーやプロセスに「タスクの完了に必要な最⼩限の権限のみ」を付与する設計原則 ⽬的： セキュリティリスクの最⼩化 誤操作や障害範囲の局所化 インシデント時の影響分析を容易にする
121. 誤解 開発初期は広い権限でいい 管理者権限が楽 最⼩権限＝作業効率が落ちる 正しい理解 初期こそ境界を明確にするべき 楽＝危険、トラブル時に責任が集中 適切なRBAC設計で回避可能 ベストプラクティス • RBAC（ロールベースアクセス制御）を活⽤ • 権限の定期レビューと棚卸し • ⼀時的な権限昇格にはログと期限を必ず設定 • サービスアカウントと⼈間ユーザーを明確に区別 よくある誤解と対策
122. Tips:アカウントを分割する リスクを⼩さく、責任を明確にするため、アカウントは分割して管理する。 • 開発 / ステージング / 本番 環境ごとに • 組織や部署 ごとに • プロジェクト ごとに • アセットの性質（インフラ/ML/データ）ごとに 分割することで以下のようなメリットがある。 • 本番での操作ミスを未然に防ぎ、影響範囲を限定できる • 各アカウントに権限‧予算‧SLOを分離責任の所在が明確になる • プロジェクトや組織ごとのコスト集計が簡単になりコストの⾒える化が進む • アクセス制御やログの分離、ゼロトラストにも対応しやすくセキュリティの強化
123. Tips:未使⽤‧過剰なリソースの整理 クラウドリソースの「ムダ」を削減し、コスト最適化とシステムの健全性を両⽴する よくあるムダなリソース例 ‧停⽌中の仮想マシン（EBS料⾦だけ継続） ‧使われていないロードバランサやIPアドレス ‧古いスナップショット‧AMI‧バックアップ ‧過剰プロビジョニングされたインスタンスサイズ ‧不要なS3バケット‧未設定のライフサイクルルール
124. Tips:サポートを使うべきタイミング • ⾃⼒での調査が限界（公式ドキュメントにも解決策なし） • サービスのステータスは正常だが、⾃分の環境だけおかしい • 有償サポート契約をしている • SLA違反の疑いがある、課⾦トラブルが発⽣した → 「まずは調べる、でも抱え込まない」。正しい情報で早く相談すれば、回復も早い。 効率的な問い合わせのコツ • 正確な再現⼿順や時刻を記録（ログ‧リクエストIDなど） • 試したこと‧想定される原因も共有 • 影響範囲（本番/開発）と緊急度を明記 • スクリーンショットよりログや構成ファイルが有効
125. 運⽤とエンジニアリング
126. DevOps Engineering ⽬的: 開発と運⽤の連携を促進し、ソフトウェアのデリバリ速度と品質を向上させる。 主な特徴: • CI/CD パイプラインの構築‧運⽤ • Infrastructure as Code（IaC）の活⽤ • ⾃動化と監視による反復可能な運⽤ • 「開発チームが運⽤責任を持つ」⽂化の推進 代表ツール: GitHub Actions / Jenkins / Terraform / Ansible / Argo CD
127. Observability Engineering ⽬的: システムの内部状態を外部から把握可能にし、迅速なトラブルシュートと改善を⽀援する。 主な特徴: • メトリクス、ログ、トレースの収集と活⽤ • SLI/SLOの設計と運⽤ • ダッシュボードとアラート設計 • 根本原因分析（RCA）を⽀える基盤 代表ツール: Prometheus / Grafana / OpenTelemetry / Loki / Jaeger 出典：O'Reilly Japanより画像を引⽤
128. Chaos Engineering ⽬的: 障害を意図的に発⽣させることで、システムの回復⼒（Resilience）を評価‧強化する。 主な特徴: • 実環境またはステージング環境での実験実施 • 「仮説 → 実験 → 観測 → 学習」のサイクル • 依存関係‧障害ドメインの可視化 • SLOを維持できる範囲の⾒極め 代表ツール: Chaos Mesh / Gremlin / LitmusChaos / Steadybit 出典：O'Reilly Japanより画像を引⽤
129. Platform Engineering ⽬的: 開発者が⾃律的かつ安全にプロダクトを開発‧運⽤できる共通基盤を提供する。 主な特徴: • 内製 PaaS や Internal Developer Platform（IDP）の構築 • 標準化されたデプロイ‧モニタリング⼿法の提供 • セキュリティ‧ガバナンスの組み込み • 開発者体験（DevEx）の向上 代表ツール: Backstage / Crossplane / Kubernetes / Terraform / Argo CD
130. 運営するためのプラクティス 維持するためのプラクティス 変化するためのプラクティス Observability Engineering Chaos Engineering Platform Engineering DevOps Engineering 紹介したプラクティスとの関係 複数のエンジニアリングに似たような考え⽅が出てくる ※図はあくまでもイメージ より深くその領域を上⼿に扱いたい時、体系化された知識を得たい時、それぞれのエンジニアリングに⼊⾨するのが良い。
131. まとめ
132. 本講習のメッセージ 運⽤とは、単なる障害対応ではなく、サービスの信頼性を守り続ける技術と責任の実践である。 「地味な作業」ではなく、社会インフラを⽀える仕事である 正しく設計された運⽤は、開発と同じくらい創造的で挑戦的な領域 銀の弾丸はないが、先駆者のプラクティスを学び、⾃分の組織に最適化する。
133. みんなが安⼼してよく眠れるシステムはいいシステム！ “⽌められない”社会に適応する
134. ありがとうございました
135. おすすめ書籍群 出典：O'Reilly Japanより引⽤