mcpField
C
change-management

change-management

github.com/happy-technologies-llcクラウド・DevOps4142 回インストール3 日前に更新
リポジトリ

change-management について

ServiceNowの変更管理をITILに沿って進めるためのスキルです。変更管理担当者やCABメンバー向けに、RFC作成から承認、実施、リスク評価、実施後レビューまで、通常・標準・緊急変更の手順を扱います。

主な機能

  1. 01通常・標準・緊急変更の申請作成
  2. 02実施・ロールバック・テスト計画の記録
  3. 03CABレビューと承認の準備
  4. 04実施タスクと進捗の追跡
  5. 05実施後レビューの記録と申請のクローズ

活用シーン

  1. 01本番変更のRFCとリスク資料の準備
  2. 02CABレビューの予定設定と変更承認
  3. 03実施作業の記録と実施後レビューの完了

MCP 対応

ServiceNowのMCPツールによる変更申請やタスクの作成、照会、更新、承認方法を説明し、対応するREST API操作も示します。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/happy-technologies-llc/happy-platform-skills --skill change-management

インストール後、Claude Code で/change-managementを入力して読み込まれたか確認します。

詳細

変更管理のライフサイクル

概要

このスキルでは、ITIL のベストプラクティスに従って ServiceNow の変更を管理するための、エンドツーエンドのガイダンスを提供します。変更要求（RFC）の作成から実装後レビュー（PIR）までのライフサイクル全体を網羅します。

変更管理の目標：

  • サービス中断のリスクを最小限に抑える
  • 適切な承認と文書化を確実に行う
  • 変更の統制された実装を可能にする
  • PIR を通じて継続的な改善を促進する

対象となる変更タイプ：

  • 通常： 標準の承認ワークフロー、CAB レビュー
  • 標準： 事前承認済みで、リスクが低く、繰り返し実施できる変更
  • 緊急： 緊急の修正に対応する迅速なプロセス

前提条件

  • ロール： itil、change_manager、または cab_member
  • アクセス権： change_request テーブルと change_task テーブルへの読み取り／書き込み権限
  • 知識： 変更管理プロセス、CAB の手順
  • 関連スキル： itsm/problem-analysis（修正の実装用）

手順

フェーズ 1：RFC の作成
ステップ 1.1：通常変更要求の作成

MCP を使用する場合：

Tool: SN-Create-Record
Parameters:
  table_name: change_request
  data:
    short_description: "[Action] [CI/Service] - [Brief purpose]"
    description: |
      CHANGE OVERVIEW:
      [Detailed description of what will be changed]

      BUSINESS JUSTIFICATION:
      [Why this change is needed]

      SCOPE:
      - In Scope: [What is included]
      - Out of Scope: [What is explicitly excluded]

      AFFECTED SERVICES/CIS:
      - [Service/CI 1]
      - [Service/CI 2]

      DEPENDENCIES:
      - [Dependency 1]
      - [Dependency 2]
    type: normal
    category: [Hardware/Software/Network/Other]
    priority: 3
    risk: moderate
    impact: 2
    assignment_group: [implementation_team_sys_id]
    cmdb_ci: [affected_ci_sys_id]
    requested_by: [requester_sys_id]
    start_date: [planned_start]
    end_date: [planned_end]

REST API を使用する場合：

POST /api/now/table/change_request
Content-Type: application/json

{
  "short_description": "Upgrade Database Server - Production CRM",
  "description": "CHANGE OVERVIEW:\nUpgrade Oracle database from 19c to 21c...",
  "type": "normal",
  "category": "Software",
  "priority": "3",
  "risk": "moderate",
  "impact": "2",
  "assignment_group": "group_sys_id",
  "cmdb_ci": "ci_sys_id",
  "start_date": "2024-02-15 22:00:00",
  "end_date": "2024-02-16 02:00:00"
}
ステップ 1.2：標準変更要求の作成

まず、承認済みの標準変更テンプレートを検索します：

Tool: SN-Query-Table
Parameters:
  table_name: std_change_catalog
  query: active=true^namLIKE[keyword]
  fields: sys_id,name,short_description,template
  limit: 10

テンプレートから作成します：

Tool: SN-Create-Record
Parameters:
  table_name: change_request
  data:
    short_description: "[Standard change description]"
    description: |
      STANDARD CHANGE EXECUTION:
      Template: [Template name]

      SPECIFIC DETAILS FOR THIS INSTANCE:
      - Target System: [system]
      - Scheduled Date: [date]
      - Requestor: [name]
    type: standard
    std_change_producer_version: [template_sys_id]
    category: [from template]
    assignment_group: [implementation_team]
    cmdb_ci: [target_ci]
    start_date: [planned_start]
    end_date: [planned_end]
ステップ 1.3：緊急変更要求の作成

緊急変更は通常の CAB を省略しますが、文書化は必要です：

Tool: SN-Create-Record
Parameters:
  table_name: change_request
  data:
    short_description: "[EMERGENCY] [Brief description of urgent fix]"
    description: |
      === EMERGENCY CHANGE REQUEST ===

      EMERGENCY JUSTIFICATION:
      [Why this cannot wait for normal change process]

      INCIDENT REFERENCE:
      [Related incident number if applicable]

      IMMEDIATE RISK IF NOT IMPLEMENTED:
      - [Risk 1]
      - [Risk 2]

      PROPOSED CHANGE:
      [What will be done]

      MINIMAL TESTING PERFORMED:
      [Testing done given time constraints]

      VERBAL APPROVAL:
      - Approved by: [name]
      - Time: [timestamp]
      - Method: [phone/in-person]
    type: emergency
    category: [category]
    priority: 1
    risk: high
    impact: 1
    assignment_group: [implementation_team]
    cmdb_ci: [affected_ci]
    reason: |
      EMERGENCY REASON:
      [Detailed reason for emergency classification]
    start_date: [immediate]
    end_date: [expected_completion]
フェーズ 2：変更の文書化
ステップ 2.1：実装計画

詳細な実装計画を追加します：

Tool: SN-Update-Record
Parameters:
  table_name: change_request
  sys_id: [change_sys_id]
  data:
    implementation_plan: |
      === IMPLEMENTATION PLAN ===

      PRE-IMPLEMENTATION:
      Time: [start] - [time]

      1. [ ] Notify stakeholders of maintenance window
         Responsible: [name]

      2. [ ] Verify backup completion
         Responsible: [name]

      3. [ ] Confirm rollback resources available
         Responsible: [name]

      4. [ ] Place system in maintenance mode
         Responsible: [name]

      IMPLEMENTATION:
      Time: [time] - [time]

      5. [ ] [Step 5 description]
         Command/Action: [specific command or action]
         Expected Duration: [X minutes]
         Success Criteria: [how to verify]

      6. [ ] [Step 6 description]
         Command/Action: [specific command or action]
         Expected Duration: [X minutes]
         Success Criteria: [how to verify]

      7. [ ] [Step 7 description]
         Command/Action: [specific command or action]
         Expected Duration: [X minutes]
         Success Criteria: [how to verify]

      VERIFICATION:
      Time: [time] - [time]

      8. [ ] Run verification tests
         Test Script: [location]
         Expected Results: [description]

      9. [ ] Confirm user access
         Test Users: [list]

      10. [ ] Monitor system for 30 minutes
          Metrics to watch: [list]

      POST-IMPLEMENTATION:
      Time: [time] - [end]

      11. [ ] Remove maintenance mode

      12. [ ] Send completion notification

      13. [ ] Update documentation
ステップ 2.2：バックアウト／ロールバック計画
Tool: SN-Update-Record
Parameters:
  table_name: change_request
  sys_id: [change_sys_id]
  data:
    backout_plan: |
      === BACKOUT/ROLLBACK PLAN ===

      ROLLBACK DECISION CRITERIA:
      Initiate rollback if ANY of the following occur:
      - [ ] Implementation step fails and cannot be resolved in [X] minutes
      - [ ] Verification tests fail
      - [ ] Service degradation exceeds [threshold]
      - [ ] Unexpected errors in logs
      - [ ] [Other criteria]

      ROLLBACK POINT OF NO RETURN:
      After step [X], rollback becomes significantly more complex.
      Decision to proceed or rollback must be made by: [time]

      ROLLBACK PROCEDURE:
      Estimated Duration: [X minutes]

      1. [ ] Stop current implementation
         Action: [specific action]

      2. [ ] Restore from backup
         Backup Location: [location]
         Restore Command: [command]
         Expected Duration: [X minutes]

      3. [ ] Verify service restoration
         Test: [test procedure]

      4. [ ] Remove maintenance mode

      5. [ ] Notify stakeholders of rollback
         Communication: [template/channel]

      ROLLBACK VERIFICATION:
      - [ ] Service accessible
      - [ ] User authentication working
      - [ ] Core functions verified
      - [ ] No data loss confirmed

      POST-ROLLBACK:
      - Document reason for rollback
      - Create problem ticket if root cause unknown
      - Schedule re-attempt after analysis
ステップ 2.3：テスト計画
Tool: SN-Update-Record
Parameters:
  table_name: change_request
  sys_id: [change_sys_id]
  data:
    test_plan: |
      === TEST PLAN ===

      PRE-CHANGE BASELINE:
      Capture current state for comparison
      - [ ] System performance metrics: [specific metrics]
      - [ ] Current version info: [how to capture]
      - [ ] User count/active sessions: [query/tool]

      SMOKE TESTS:
      Quick tests to verify basic functionality

      | Test | Action | Expected Result | Pass/Fail |
      |------|--------|-----------------|-----------|
      | Login | Admin login | Dashboard loads | |
      | Core Function | [action] | [expected] | |
      | API | [endpoint] | 200 OK | |
      | Database | [query] | [expected] | |

      FUNCTIONAL TESTS:
      Detailed functionality verification

      | Test ID | Test Case | Steps | Expected | Actual | Pass/Fail |
      |---------|-----------|-------|----------|--------|-----------|
      | FT-001 | [name] | [steps] | [expected] | | |
      | FT-002 | [name] | [steps] | [expected] | | |
      | FT-003 | [name] | [steps] | [expected] | | |

      PERFORMANCE TESTS:
      Compare against baseline

      | Metric | Baseline | Post-Change | Threshold | Pass/Fail |
      |--------|----------|-------------|-----------|-----------|
      | Response Time | [X]ms | | <[Y]ms | |
      | CPU Usage | [X]% | | <[Y]% | |
      | Memory | [X]GB | | <[Y]GB | |

      USER ACCEPTANCE:
      - Test User: [name]
      - Test Scenario: [description]
      - Sign-off Required: Yes/No
フェーズ 3：CAB の準備とスケジュール設定
ステップ 3.1：CAB レビューのスケジュール設定

CAB 用に変更を更新します：

Tool: SN-Update-Record
Parameters:
  table_name: change_request
  sys_id: [change_sys_id]
  data:
    state: -4  # Assess
    cab_required: true
    cab_date: [cab_meeting_date]
    work_notes: |
      === CAB SUBMISSION ===

      Submitted for CAB Review: [date]
      Target CAB Meeting: [date/time]

      CAB Preparation Checklist:
      - [x] Implementation plan complete
      - [x] Backout plan complete
      - [x] Test plan complete
      - [x] Risk assessment complete
      - [x] Stakeholders identified
      - [x] Communication plan ready

      Additional Materials:
      - [Link to supporting documentation]
      - [Architecture diagram reference]
ステップ 3.2：CAB 発表用の概要を作成
Tool: SN-Add-Work-Notes
Parameters:
  sys_id: [change_sys_id]
  work_notes: |
    === CAB PRESENTATION SUMMARY ===

    CHANGE: [CHG#]
    TITLE: [Short description]
    REQUESTOR: [Name/Team]

    WHAT:
    [One paragraph summary of the change]

    WHY:
    [Business justification in 2-3 sentences]

    WHEN:
    - Proposed Start: [date/time]
    - Proposed End: [date/time]
    - Duration: [X hours]
    - Maintenance Window: [Yes/No - description]

    WHO IS AFFECTED:
    - Users: [groups/count]
    - Services: [list]
    - Regions: [if applicable]

    RISK ASSESSMENT:
    - Risk Level: [Low/Moderate/High]
    - Impact if Fails: [description]
    - Likelihood of Failure: [Low/Medium/High]

    MITIGATION:
    - [Key mitigation 1]
    - [Key mitigation 2]

    ROLLBACK:
    - Rollback possible: [Yes/No]
    - Rollback time: [X minutes/hours]
    - Point of no return: [time/step]

    DEPENDENCIES:
    - [Other changes/freezes/events]

    APPROVAL REQUESTED:
    [Standard/Expedited approval request]
ステップ 3.3：CAB で予定されている変更の照会

CAB で予定されているすべての変更を検索します：

Tool: SN-Query-Table
Parameters:
  table_name: change_request
  query: cab_required=true^cab_date>=javascript:gs.beginningOfToday()^cab_dateONThis week@javascript:gs.beginningOfThisWeek()@javascript:gs.endOfThisWeek()^state=-4
  fields: number,short_description,cab_date,requested_by,assignment_group,risk,priority
  order_by: cab_date
フェーズ 4：変更の承認
ステップ 4.1：承認ステータスの確認
Tool: SN-Query-Table
Parameters:
  table_name: sysapproval_approver
  query: document_id=[change_sys_id]
  fields: sys_id,approver,state,comments,sys_updated_on
ステップ 4.2：変更の承認（承認者として）

MCP を使用する場合：

Tool: SN-Approve-Change
Parameters:
  sys_id: [change_sys_id]
  approval_state: approved
  comments: |
    Approved based on:
    - Risk assessment reviewed and acceptable
    - Implementation plan verified complete
    - Rollback plan adequate
    - Testing plan comprehensive
    - Change window appropriate

    Conditions:
    - [Any conditions for approval]

REST API を使用する場合：

PATCH /api/now/table/sysapproval_approver/{approver_sys_id}
Content-Type: application/json

{
  "state": "approved",
  "comments": "Approved based on:\n- Risk assessment reviewed..."
}

変更を却下する場合：

Tool: SN-Approve-Change
Parameters:
  sys_id: [change_sys_id]
  approval_state: rejected
  comments: |
    Change rejected for the following reasons:

    1. [Reason 1]
    2. [Reason 2]

    Required remediation before resubmission:
    - [Action 1]
    - [Action 2]

    Please address these concerns and resubmit.
ステップ 4.3：スケジュール済み状態への移行

承認後：

Tool: SN-Update-Record
Parameters:
  table_name: change_request
  sys_id: [change_sys_id]
  data:
    state: -1  # Scheduled
    work_notes: |
      === CHANGE APPROVED AND SCHEDULED ===

      Approval Received: [date]
      Approved By: [names]

      Implementation Window:
      Start: [date/time]
      End: [date/time]

      Pre-Implementation Meeting: [date/time if scheduled]

      Go/No-Go Decision Time: [time before start]
フェーズ 5：実装
ステップ 5.1：実装タスクの作成

MCP を使用する場合：

Tool: SN-Create-Record
Parameters:
  table_name: change_task
  data:
    parent: [change_sys_id]
    change_task_type: planning
    short_description: "Pre-Implementation: [Task description]"
    description: |
      PRE-IMPLEMENTATION TASK

      Objective: [What needs to be done]

      Steps:
      1. [Step 1]
      2. [Step 2]

      Deliverables:
      - [Deliverable 1]

      Completion Criteria:
      - [How to know it's done]
    assignment_group: [team]
    assigned_to: [person]
    planned_start_date: [start]
    planned_end_date: [end]

標準的なタスクタイプ：

  • planning - 実装前の準備
  • implementation - 実際の変更の実行
  • testing - 検証とテスト
  • review - 実装後レビュー
ステップ 5.2：実装の開始

変更を実装状態に更新します：

Tool: SN-Update-Record
Parameters:
  table_name: change_request
  sys_id: [change_sys_id]
  data:
    state: -2  # Implement
    work_notes: |
      === IMPLEMENTATION STARTED ===

      Time: [timestamp]
      Implementation Lead: [name]

      Go Decision Made By: [name]
      Go Criteria Met:
      - [x] Backup verified
      - [x] Rollback team on standby
      - [x] Stakeholders notified
      - [x] Maintenance mode active

      Starting implementation step 1...
ステップ 5.3：実装の進捗を文書化
Tool: SN-Add-Work-Notes
Parameters:
  sys_id: [change_sys_id]
  work_notes: |
    === IMPLEMENTATION LOG ===

    [HH:MM] - Step [X]: [Description]
    Status: COMPLETE
    Notes: [Any observations]

    [HH:MM] - Step [X+1]: [Description]
    Status: IN PROGRESS

    Current Overall Status: ON TRACK / DELAYED / AT RISK

    Issues Encountered:
    - [Issue if any, or "None"]

    Next Milestone: [Description] at [time]
ステップ 5.4：実装の完了
Tool: SN-Update-Record
Parameters:
  table_name: change_request
  sys_id: [change_sys_id]
  data:
    state: 0  # Review
    work_notes: |
      === IMPLEMENTATION COMPLETE ===

      Completion Time: [timestamp]

      IMPLEMENTATION SUMMARY:
      - All steps executed successfully: [Yes/No]
      - Deviations from plan: [None/Description]
      - Issues encountered: [None/Description]

      VERIFICATION RESULTS:
      - Smoke tests: PASS/FAIL
      - Functional tests: PASS/FAIL
      - Performance tests: PASS/FAIL

      POST-IMPLEMENTATION STATUS:
      - Service operational: Yes
      - Users notified: Yes
      - Monitoring active: Yes

      Ready for PIR: Yes
フェーズ 6：実装後レビュー（PIR）
ステップ 6.1：PIR のスケジュール設定
Tool: SN-Create-Record
Parameters:
  table_name: change_task
  data:
    parent: [change_sys_id]
    change_task_type: review
    short_description: "Post-Implementation Review - [CHG#]"
    description: |
      POST-IMPLEMENTATION REVIEW

      Meeting Details:
      Date: [date]
      Time: [time]
      Location/Call: [details]

      Required Attendees:
      - Change Owner
      - Implementation Team
      - Technical Approvers
      - Service Owner (optional)

      Agenda:
      1. Change summary (5 min)
      2. Implementation review (10 min)
      3. What went well (10 min)
      4. What could improve (10 min)
      5. Action items (10 min)
      6. Lessons learned (5 min)
    assigned_to: [change_owner]
    planned_start_date: [pir_date]
ステップ 6.2：PIR の結果を文書化
Tool: SN-Add-Work-Notes
Parameters:
  sys_id: [change_sys_id]
  work_notes: |
    === POST-IMPLEMENTATION REVIEW ===

    PIR Date: [date]
    Attendees: [list]

    CHANGE OUTCOME: [Successful/Successful with Issues/Partial/Failed/Rolled Back]

    METRICS:
    - Planned Duration: [X hours]
    - Actual Duration: [Y hours]
    - Variance: [+/- Z hours]
    - User Impact: [None/Minimal/Moderate/Significant]

    WHAT WENT WELL:
    1. [Positive outcome 1]
    2. [Positive outcome 2]
    3. [Positive outcome 3]

    WHAT COULD BE IMPROVED:
    1. [Improvement area 1]
    2. [Improvement area 2]
    3. [Improvement area 3]

    DEVIATIONS FROM PLAN:
    - [Deviation 1 and why]
    - [Deviation 2 and why]

    ACTION ITEMS:
    1. [Action] - Owner: [name] - Due: [date]
    2. [Action] - Owner: [name] - Due: [date]

    LESSONS LEARNED:
    - [Lesson that should be shared]
    - [Process improvement suggestion]

    PIR STATUS: Complete
ステップ 6.3：変更要求をクローズ
Tool: SN-Update-Record
Parameters:
  table_name: change_request
  sys_id: [change_sys_id]
  data:
    state: 3  # Closed
    close_code: successful
    close_notes: |
      CHANGE CLOSURE SUMMARY

      Change: [CHG#]
      Title: [Short description]

      Result: SUCCESSFUL

      Implementation Date: [date]
      Implementation Duration: [X hours]

      Benefits Realized:
      - [Benefit 1]
      - [Benefit 2]

      Documentation Updated:
      - [ ] CMDB updated
      - [ ] Knowledge base updated
      - [ ] Runbooks updated

      PIR Complete: Yes
      PIR Date: [date]

      No outstanding issues.

クローズコードの選択肢：

  • successful - 計画どおりに変更を実装
  • successful_issues - 軽微な問題があったものの実装
  • unsuccessful - 変更に失敗、またはロールバック

変更状態のフロー

┌────────────┐    ┌──────────┐    ┌───────────┐    ┌───────────┐
│    New     │───►│  Assess  │───►│ Authorize │───►│ Scheduled │
│   (-5)     │    │   (-4)   │    │   (-3)    │    │   (-1)    │
└────────────┘    └──────────┘    └───────────┘    └─────┬─────┘
                                                         │
┌────────────┐    ┌──────────┐    ┌───────────┐         │
│   Closed   │◄───│  Review  │◄───│ Implement │◄────────┘
│    (3)     │    │   (0)    │    │   (-2)    │
└────────────┘    └──────────┘    └───────────┘
                        │
                        └───────► Canceled (4)

リスク評価マトリックス

リスクレベル影響発生確率承認テスト
低軽微低い自動／マネージャー最小限
中程度重大あり得るCAB標準
高大きい高いCAB ＋ 経営幹部広範囲
重大深刻ほぼ確実取締役会レベル完全な回帰テスト

ツールの使用概要

MCP ツール
ツール目的フェーズ
SN-List-ChangeRequests条件に基づいて変更を一覧表示すべて
SN-Create-Record変更、タスクの作成1、5、6
SN-Update-Record変更ステータス、計画の更新2～6
SN-Add-Work-Notesすべてのアクティビティを文書化すべて
SN-Add-Change-Comment関係者とのコミュニケーション3、5
SN-Assign-Changeチーム／個人への割り当て1、5
SN-Approve-Change変更の承認／却下4
SN-Query-Table承認、タスクの照会すべて
REST API エンドポイント
エンドポイントメソッド目的
/api/now/table/change_requestGET変更を一覧表示
/api/now/table/change_requestPOST変更を作成
/api/now/table/change_request/{sys_id}PATCH変更を更新
/api/now/table/change_taskPOSTタスクを作成
/api/now/table/sysapproval_approverGET承認状況を確認
/api/now/table/sysapproval_approver/{sys_id}PATCH承認／却下
/api/now/table/std_change_catalogGET標準変更を一覧表示

ベストプラクティス

  • 十分に計画する： CAB の前に、実装計画とロールバック計画を完成させます
  • 変更の規模を適切にする： 関連のない変更をまとめないでください
  • 下位環境でテストする： 本番環境に適用する前に必ずテストします
  • コミュニケーションが重要： 関係者には必要以上に情報を共有します
  • すべてを記録する： 将来の自分が今の自分に感謝するでしょう
  • PIR から学ぶ： PIR の対応項目を実際に実施します
  • 標準変更を活用する： 繰り返し可能でリスクの低い変更は事前承認します
  • 緊急変更でも記録は必要： 緊急変更にも記録が必要です
  • ITIL に準拠する： 変更イネーブルメントのプラクティスに従います

トラブルシューティング

「変更が Assess で止まっている」

原因： 必須フィールドまたはドキュメントが不足しています
解決策： 必須フィールドがすべて入力されていることを確認し、検証ルールを確認します

「承認に時間がかかりすぎている」

原因： 承認者が不在、または通知を受信していません
解決策： 承認者に直接連絡し、通知ログを確認して、委任を利用します

「CAB が変更を却下した」

原因： ドキュメント不足、リスクへの懸念、またはスケジュールの競合があります
解決策： CAB のフィードバックに対応し、改善を加えて再提出します

「実装に失敗した」

原因： テスト不足や予期しない状況など、さまざまな原因が考えられます
解決策： ロールバック計画を実行し、失敗を記録して、問題チケットを作成し、再スケジュールします

「変更をクローズできない」

原因： 未完了のタスク、PIR の不足、またはクローズ用フィールドの未入力があります
解決策： すべてのタスクを完了し、PIR を記録して、必須のクローズ用フィールドを入力します

変更テンプレート

通常変更クイックリファレンス
Type: Normal
CAB Required: Yes (typically)
Lead Time: 5-10 business days
Approval: CAB + Manager
Testing: Full cycle
標準変更クイックリファレンス
Type: Standard
CAB Required: No (pre-approved)
Lead Time: 1-3 business days
Approval: Automatic
Testing: As per template
緊急変更クイックリファレンス
Type: Emergency
CAB Required: Yes (post-implementation ECAB)
Lead Time: Immediate
Approval: Emergency approver (verbal OK, documented later)
Testing: Minimal (risk accepted)

関連スキル

  • itsm/incident-lifecycle - 関連するインシデント用
  • itsm/major-incident - 重大インシデント中の緊急変更用
  • itsm/problem-analysis - 恒久的な修正のための変更用
  • admin/deployment-workflow - リリース調整用
  • admin/update-set-management - CMDB の更新用

参考資料

コメント

Markdown 対応