Google Cloud Innovators で学習と成長を加速できます。 今すぐ参加

Professional Cloud DevOps Engineer

認定試験ガイド

Professional Cloud DevOps Engineer は、サービスの信頼性の確保と迅速な配信との適度なバランスを保つために、開発プロセスの効率的な運用を目指します。また、Google Cloud を使用したソフトウェア デリバリー パイプラインの構築、サービスのデプロイとモニタリング、インシデントの管理、およびインシデントから知見を得ることに精通している必要があります。


セクション 1. サービスへのサイト信頼性エンジニアリングの原則の適用

1.1 サービスの変更、速度、信頼性確保の調整:

    a. SLI を検出する(例: 可用性、レイテンシ)

    b. SLO を定義し、SLA を理解する

    c. エラー バジェットを満たさないことによる結果を受け入れる

    d. 次に構築するものを決定するためのフィードバック ループを作成する

    e. 自動化により手間を省く

1.2 サービス ライフサイクルの管理:

    a. サービスを管理する(例: 新しいサービスの導入、デプロイ、保守、廃止)

    b. キャパシティを計画する(例: 割り当てと上限の管理)

1.3 運用のための健全なコミュニケーションとコラボレーションの確保:

    a. 心身の疲労を防ぐ(例: 心身の疲労を防ぐための自動化プロセスを設定する)

    b. 学習する文化を育む

    c. 誰かのせいにしない文化を育む

セクション 2. サービスの CI / CD パイプラインの構築および実装

2.1 CI / CD パイプラインの設計:

    a. Artifact Registry を使用した不変のアーティファクトの作成と保存

    b. Cloud Build、Spinnaker を使用したデプロイ戦略

    c. Anthos、Spinnaker、Kubernetes を使用したハイブリッドおよびマルチクラウド環境へのデプロイ

    d. Cloud Build、Artifact Registry を使用したアーティファクトのバージョニング戦略

    e. Cloud Source Repositories、外部 SCM、Pub/Sub を使用した CI / CD パイプライン トリガー

    f. Spinnaker を使用した新しいバージョンのテスト

    g. デプロイ プロセスの構成(例: 承認フロー)

2.2 CI / CD パイプラインの実装:

    a. Cloud Build を使用した CI

    b. Cloud Build を使用した CD

    c. オープンソース ツール(例: Jenkins、Spinnaker、GitLab、Concourse)

    d. デプロイの監査および追跡(例: CSR、Artifact Registry、Cloud Build、Cloud Audit Logs)

2.3 構成とシークレットの管理:

    a. 安全なストレージ方式

    b. シークレットのローテーションと構成変更

2.4 Infrastructure as Code の管理:

    a. Terraform

    b. インフラストラクチャ コードのバージョニング

    c. インフラストラクチャ変更の安全化

    d. 不変のアーキテクチャ

2.5 CI / CD ツールのデプロイ:

    a. 一元管理されたツールと複数のツール(単一テナントとマルチテナント)

    b. CI / CD ツールのセキュリティ

2.6 さまざまな開発環境の管理(例: ステージング環境、本番環境):

    a. 環境の数とその目的の決定

    b. GKE を使用した機能ブランチごとの動的な環境作成

    c. Docker、Cloud Code、Skaffold を使用したローカル開発環境

2.7 デプロイ パイプラインの保護:

    a. Artifact Registry を使用した脆弱性分析

    b. Binary Authorization

    c. 環境ごとの IAM ポリシー

セクション 3. サービスのモニタリング戦略の実装

3.1 アプリケーション ログの管理:

    a. Cloud Logging、Fluentd を使用して Compute Engine、GKE からログを収集する

    b. Cloud Logging、Fluentd を使用してサードパーティのログおよび構造化ログを収集する

    c. Cloud Logging API にアプリケーション ログを直接送信する

3.2 Cloud Monitoring を使用したアプリケーション指標の管理:

    a. Compute Engine から指標を収集する

    b. GKE や Kubernetes の指標を収集する

    c. アドホック指標分析に Metric Explorer を使用する

3.3 Cloud Monitoring プラットフォームの管理:

    a. モニタリング ダッシュボードを作成する

    b. ダッシュボードをフィルタおよび共有する

    c. Cloud Monitoring を使用してサードパーティのアラートを構成する(例: PagerDuty、Slack)

    d. Cloud Monitoring を使用して SLI に基づいてアラート ポリシーを定義する

    e. Terraform を使用してアラート ポリシー定義を自動化する

    f. Cloud Monitoring を使用して SLO モニタリングとアラートを実装する

    g. Cloud Monitoring との統合を理解する(例: Grafana、BigQuery)

    h. SIEM ツールを使用して監査ログとフローログを分析する(例: Splunk、Datadog)

    i. Cloud Monitoring の指標スコープを設計する

3.4 Cloud Logging プラットフォームの管理:

    a. データアクセス ログを有効化する(Cloud Audit Logs)

    b. VPC フローログを有効化する

    c. Google Cloud Console にログを表示する

    d. 基本ロギング フィルタと高度なロギング フィルタを使用する

    e. ログベースの指標を実装する

    f. ロギング除外とロギング エクスポートを理解する

    g. ロギング エクスポートのオプションを選択する

    h. プロジェクト レベルや組織レベルのエクスポートを実装する

    i. Cloud Storage と BigQuery でエクスポート ログを表示する

    j. 外部ロギング プラットフォームへログを送信する

3.5 ロギングとモニタリングのアクセス制御の実装

    a. IAM、Cloud Logging を使用して監査ログへのアクセスを制限する ACL を設定する

    b. IAM、Cloud Logging を使用してエクスポート構成を制限する ACL を設定する

    c. IAM、Cloud Monitoring を使用してカスタム指標の指標書き込みを許可する ACL を設定する

セクション 4. サービス パフォーマンスの最適化

4.1 サービス パフォーマンスの問題の特定:

    a. ユーザーへの影響を評価および把握する

    b. Google Cloud のオペレーション スイートを使用してクラウド リソースの使用率を特定する

    c. Cloud Trace と Cloud Profiler を使用してパフォーマンス特性をプロファイルする

    d. サービス メッシュ テレメトリーを解釈する

    e. イメージや OS に関する問題をトラブルシューティングする

    f. ネットワークの問題をトラブルシューティングする(VPC フローログ、ファイアウォール ログ、レイテンシ、ネットワークの詳細の表示など)

4.2 アプリケーション コードのデバッグ:

    a. アプリケーション インストルメンテーション

    b. Cloud デバッガ

    c. Cloud Logging

    d. Cloud Trace

    e. 分散アプリケーションのデバッグ

    f. App Engine ローカル開発用サーバー

    g. エラーレポート

    h. Cloud Profiler

4.3 リソース使用率の最適化:

    a. リソース費用を特定する

    b. リソース使用率レベルを特定する

    c. 費用が増大している領域または使用率が低い領域を最適化するための計画を策定する

    d. プリエンプティブル VM を管理する

    e. 確約利用割引を利用する(該当する場合)

    f. TCO について検討する(例: セキュリティ、ロギング、ネットワーキング)

    g. ネットワークの料金を考慮する

セクション 5. サービス インシデントの管理

5.1 サービス インシデント時の職務の調整と通信チャネルの実装:

    a. 職務を定義する(インシデント コマンダー、コミュニケーション リード、オペレーション リード)

    b. 影響評価のリクエストを処理する

    c. 内部および外部で定期的なステータス更新を提供する

    d. インシデント状態の主要な変化を記録する(軽減されたのはいつか、問題が解決したのはいつかなど)

    e. 通信チャネルを確立する(例: メール、IRC、ハングアウト、Slack、スマートフォン)

    f. 対応チームを選定して委任する

    g. 極度の疲労や燃え尽きを避ける

    h. 職務のローテーションや引き継ぎを行う

    i. ステークホルダー間の関係を管理する

5.2 ユーザーに影響を与えるインシデントの症状の調査:

    a. サービス障害の考えられる原因を特定する

    b. 考えられる原因に対する症状を評価する(実際の動作に基づいた原因の可能性のランク付け)

    c. 最も可能性が高い原因を突き止めるための調査を実施する

    d. 問題を軽減するための代替案を特定する

5.3 ユーザーに対するインシデントの影響の軽減:

    a. リリースをロールバック

    b. トラフィックをドレイン / リダイレクトする

    c. テストをオフにする

    d. 容量を追加する

5.4 デプロイの問題の解決(例: Cloud Build、Jenkins):

    a. コード変更、バグ修正を行う

    b. 修正を確認する

    c. 問題解決を宣言する

5.5 事後調査で問題をドキュメント化する:

    a. 根本原因をドキュメント化する

    b. アクション アイテムを作成して優先順位を付ける

    c. 事後調査の結果をステークホルダーに伝える