https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/index.html Recent content in 4.3 業務設計 on JP1 Cloud Service 運用統合 利用ガイド Hugo -- gohugo.io ja https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/catalog_design/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/catalog_design/index.html サービスカタログの設計では、サービスカタログの作成を行います。 （表）サービスカタログ設計項目と概要 項目 定義手段 設計のポイント Catalog YAMLファイル 必要となるカタログアイテムを洗い出した上で、申請やデータレコード呼び出しなどのパターンで分類します。また、カタログアイテムの表示・非表示と、表示順を整理します。 サービスカタログは複数のカタログアイテムで構成されます。またカタログアイテムは、カテゴリーで分類されます。 ユーザーはカタログアイテムから、ワークフローを実行することができます。またワークフローからUIのYAMLファイルで定義した画面を表示し、データレコードなどの作成や編集が行えます。 このようにサービスカタログによって、ユーザーは任意のタスクを管理することができます。 カテゴリーやカタログアイテムはCatalogのYAMLファイルで定義します。詳細は「Catalog」を参照してください。 （図）サービスカタログの概要 （1）カテゴリーとカタログアイテムの表示設定 CatalogのYAMLファイルには、ファイルごとに複数のカテゴリーを設定できます。また、カテゴリーごとに複数のカタログアイテムを設定できます。 カテゴリーやカタログアイテムは、CatalogのYAMLファイルに記載された順に表示されます。 サービスカタログを複数のCatalogのYAMLファイルで設定している場合、YAMLファイルをGitアプリケーションに登録した順に表示されます。登録済のYAMLファイルを更新しても表示順に影響しません。 YAMLファイルを登録した順番以外で表示する場合は、表示の優先順位を設定します。詳細は「カテゴリーの表示順（YAMLファイル単位）の優先順位」を参照してください。 また、カタログの表示・非表示を顧客やグループごとに制限できます。詳細は「アクセス制御」を参照してください。 【カテゴリーの表示順（YAMLファイル単位）の優先順位】 カテゴリエリアでは、カテゴリーの表示順を以下の方法で指定することができます。 カテゴリーを複数のCatalogのYAMLファイルに分けて記載している場合、CatalogのYAMLファイルのラベル「order」で表示の優先順位を設定できます。同じ値を設定した場合は順不同に表示し、指定しない場合は指定した場合よりも後に表示されます。また、同一のYAMLファイルに記載されているカテゴリーの表示順は、CatalogのYAMLファイルの記載順に従います。 （図）カテゴリーとカタログアイテムの表示 【アクセス制御】 アクセス制御により、カタログアイテムを参照できるユーザーをCatalogのYAMLファイル単位で指定することができます。指定しない場合はすべてのユーザーが参照できます。 アクセス制御は、顧客別とグループ別の2種類の方法があります。顧客別アクセス制御とグループ別アクセス制御を同時に使用する場合は、両方の条件を満たしたユーザーが参照できます。 注意事項 カタログアイテムを参照できるユーザーの設定は本機能で行うため、CatalogのYAMLファイルで指定しますが、カタログアイテムにひもづくワークフローの申請、承認、およびタスク実行などの各アクティビティを実行できるユーザーの設定は、WorkflowのYAMLファイルで指定します。 顧客別のアクセス制御 顧客ユーザーに対して有効な制御です。顧客ユーザーの詳細については「ユーザー」を参照してください。 設定はCatalogのYAMLファイルのcustomersラベルで行います。customerラベルを設定すると、顧客ユーザー以外と、指定した顧客ユーザーに対して表示されます。設定しない場合は、すべてのユーザーに表示されます。詳細は「Catalog」を参照してください。 （表）顧客によるアクセス制御 ユーザー customersラベル 設定なし 顧客Aを指定 顧客ユーザー以外 表示 表示 顧客Aに所属する顧客ユーザー 表示 表示 顧客Bに所属する顧客ユーザー 表示 非表示 グループ別のアクセス制御 すべてのユーザーに対して有効な制御です。 設定はCatalogのYAMLファイルのgroupsラベルで行います。 groupsラベルを設定すると、指定したグループに対して表示されます。設定しない場合は、すべてのグループに表示されます。詳細は「Catalog」を参照してください。 （表）グループによるアクセス制御 ユーザー groupsラベル 設定なし グループAを指定 グループAに所属するユーザー 表示 表示 グループBに所属するユーザー 表示 非表示 登録したカタログアイテムをすべて参照できるのは、各YAMLファイルのgroupsラベルに指定したグループすべてに所属しているユーザーです。 【サービスカタログ情報の取得】 サービスカタログの情報を取得する場合、API「GET /api/v1/service-catalogs」を使用します。APIおよび実行するためのロールについての詳細は「APIとOps I上ロールの対応関係」および「JP1 Cloud Service 運用統合 APIリファレンス」の「APIリファレンス詳細＞標準提供API」を参照してください。 （2）ワークフロー実行パラメータの事前設定 カタログアイテムからワークフローを実行する際に、CatalogのYAMLファイルで設定したパラメータを、WorkflowのYAMLファイルやJavaScriptファイルから参照できます。 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/workflow_design/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/workflow_design/index.html ワークフローの設計では、それぞれの業務のワークフローを作成し、申請や承認、またはタスク実行などの各アクティビティの内容や順序、アクティビティを実行できるロールなどをYAMLファイルで定義します。 アクティビティにはさまざまな種類があり、申請内容の確認や承認、Playbookを使用した自動タスクなどがあります。また、任意のワークフローのステップごとにラベルをYAML定義することができます。ワークフロー一覧画面ではこのラベルごとに進捗度合が表示されます。 ワークフローの次のステップに遷移するには、各ステップの画面のアクションボタンをクリックします。アクションボタンにはOps Iで提供しているボタン（標準アクションボタン）とユーザーが独自に設定できるボタンがあります。また、UIバージョン1.1では、標準アクションボタンをカスタムして使用できます。詳細は「標準アクションボタンをカスタムしたい場合」を参照してください。 ワークフロー画面の構成については「ワークフロー」を、YAML定義については「Workflow」を参照してください。 また、ワークフロー一覧画面では、カラムの追加や表示順の入れ替えなどを行うことができます。詳細は「ワークフロー画面のカスタム」を参照してください。 （表）ワークフロー設計項目と概要 項目 定義手段 設計のポイント Workflow YAMLファイル 設計する業務に、どのような作業や承認ステップが必要か、また、その作業をどのユーザーがどのロールで実行するのかを検討します。 （図）ワークフローの概念図 ワークフローの設計は、対象の業務のステップとして必要なアクティビティを洗い出し、各アクティビティを実行できるロールの割り当てを行います。 注意事項 ワークフローの最初の画面はサービスカタログ画面から新規ワークフローを開いた時、または未開始のワークフローを開いた時に表示されます。作業項目管理機能からワークフローを実行した場合は、最初の画面のタスクはユーザー入力を待たず次のタスクに遷移します。したがって、最初の画面のタスクで指定したグループやロールの設定は、新規ワークフローまたは未開始のワークフローを開く場合に適用されます。 1つのワークフローの中で複数のUIを指定する場合、Workflow定義の中で使用するUIバージョンは同じにする必要があります。UIバージョンの詳細は「UIバージョン」を参照してください。 ワークフローの作成者が顧客ユーザーの場合、ワークフローの顧客は、作成した時点でのユーザーの顧客の設定が反映されます。作成後にユーザーの顧客の設定が変更されても、ワークフローの顧客の設定は変更されません。 以下はVM貸出申請を例としたワークフロー図で、アクティビティには申請や申請内容の確認などがあります。各アクティビティに必要なカラムはデータモデルにて定義します。 （図）VMの貸出を例としたワークフロー （表）VMの貸出を例としたワークフローのステップとロール一覧 作業名 ワークフローステップ 操作者 ロール UI 種別 名称 アクション 入力値の規則チェック VMの貸出 申請 申請者 Customer User 申請に必要な情報やカラムはデータモデルで定義し、各カラムに対するアクションなどはUIで定義します。 申請内容の確認 運用担当 Operation Management Office Agent VMの生成 （自動実行） - VMの生成の確認 運用担当 Operation Management Office Agent VMの生成の最終確認 運用管理者 Operation Management Office Manager なお、YAMLファイル定義において、ワークフローの起点となるステップへ、他のステップから遷移することはできません。申請内容の不備により、申請者に差し戻しを行う場合は、起点となるステップにガイダンス表示などのステップを作成しておくことで、ワークフローの起点となるステップが遷移先にならないよう設計してください。 （図）ワークフローの起点となるステップへの遷移に関する設計 データモデルの詳細については「データモデルの設計」、「Datamodel」を参照してください。 UIの詳細については「UI設計」、「UI」を参照してください。 ワークフローが失敗した場合、ワークフローのログを確認してください。詳細は「ワークフローの[実行ログ]画面」を参照してください。 その他、ユースケースに合わせて以下の機能を利用することができます。 運用に必要なスキルをもったユーザーを設定したい場合 並列処理を行いたい場合 標準アクションボタンをカスタムしたい場合 （1）運用に必要なスキルをもったユーザーを設定したい場合 YAMLファイル「Skill」、「Skillset」で定義したスキルを、YAMLファイル「Workflow」でアクティビティごとに必要なスキルセット（スキルの組み合わせ）として設定することができます。スキルセットに合わせたユーザーのアサインはワークフロータブのStepper画面から実施できます。ただし、UIバージョン1.1ではStepperコンポーネントは未サポートです。この機能を使用する場合は、UIバージョン1.0を使用してください。UIバージョンの詳細は「UIバージョン」を参照してください。 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/notice_design/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/notice_design/index.html Ops Iの通知機能には、ワークフローやスケジュール・作業項目の作成、変更または削除が行われたときに通知する方法（以下、「イベントによる通知」）と、ワークフローの定義で任意のタイミングで通知を行う方法（以下、「ワークフローからの通知」）があります。 通知の設計は、NotificationとNotifierの2つのタイプのYAML定義を行います。 （表）通知の設計項目と概要 項目 定義手段 設計のポイント ・Notification ・Notifier YAMLファイル ワークフローのステップごとに通知する担当者の割り当てや、申請完了時の申請者への通知を設定します。またスケジュールごとに通知する担当者の割り当てや設定をします。通知手段はGUIまたはメールで行います。 【イベントによる通知】 （図）Notification、Notifierの概念図（イベントによる通知） Ops Iではワークフローやスケジュール・作業項目を起点とした通知設定を定義できます。ここで起点とは、通知が行われるきっかけになるイベントを指します。YAMLファイルに通知を送るイベントの条件やメッセージ、宛先や送信手段などを定義することで、ユーザーが実行したいアクティビティの担当者に通知を送ったり、申請者が申請受理/完了の報告を受けたりできます。 ワークフローを起点とした通知については「ワークフローを起点にした場合の通知」を参照してください。 また、スケジュールの開始や完了の通知を送ったり、作業項目の更新によって通知を送ったりすることができます。 スケジュールが予定表に属している場合は、予定表の担当グループに所属するユーザーを宛先にしたり、予定表に関連したスケジュールに限定したりできます。その場合予定表の情報から通知の本文、タイトル、リンクを定義できます。 スケジュール・作業項目を起点とした通知については「スケジュール・作業項目を起点にした場合の通知」を参照してください。 【ワークフローからの通知】 ワークフローの中で通知を行いたいタイミングの位置に通知のタスクを追加します。ワークフローの任意のタイミングで通知を行いたい場合は、こちらの方法を使用します。 （1）通知の流れ イベントによる通知と、ワークフローからの通知のいずれの場合にも、事前にNotificationのYAMLファイルに、以下のラベルの設定が必要です。 event.resource：通知の監視対象のリソース（作成、更新など） event.type：イベント（作成、更新など）のタイプ conditions：通知する条件。"type"が"onDemand"の場合は設定が不要です。 【イベントによる通知】 "type"が"onDemand"以外で、eventで設定した対象がconditionsで設定した条件を満たすと、通知の送信元は通知オブジェクトを作成し、宛先に通知します。通知条件の例とそれらのYAMLの定義例は「スケジュール・作業項目起点の通知例」を参照してください。 【ワークフローからの通知】 "type"が"onDemand"で、conditionsの設定は行わず、Ops I提供部品「oi.notify」を使います。ワークフローで指定したタイミングで通知を行い、WorkflowのYAMLファイルで定義したパラメータを埋め込めます。YAMLの定義例は「通知を含めたワークフローの定義例」を参照してください。 通知オブジェクトとは、通知の宛先や、通知の送信手段、通知メッセージの情報を表し、NotificationのYAMLファイルのラベル「notifications」で設定します。通知の宛先は、Ops Iのユーザー、またはグループへの通知が選択できます。 通知の手段はNotifierのYAMLファイルによって管理されます。Ops IのGUIでの通知に加え、メールでの通知をすることもできます。 .GetValueを使用する場合、resourceに指定したリソースが起点となります。使用できる値は「（表）Notificationで使用可能なオブジェクト・フィールド」を参照してください。 宛先は、scheduleオブジェクトのassignedToに申請者などを設定することで指定できます。scheduleオブジェクトについては「（表）Notificationで使用可能なオブジェクト・フィールド」を参照してください。 どのイベントに通知設定をしたかは、ワークフローやスケジュールのGUI上ではわからないため、必要に応じて通知の定義をしたユーザーから関係者に周知する必要があります。 （図）通知の流れ NotificationとNotifierのYAML定義の詳細については「Notification、Notifier」を参照してください。 （2）スケジュール・作業項目を起点にした場合の通知 スケジュール機能には、予定表、予定表にひもづく作業項目、作業項目にひもづく個々のスケジュールや、ユーザーにひもづくスケジュールがあります。本機能では、作業項目とスケジュールを起点とした通知の設定ができます。以下に、スケジュールを起点にした通知例と、通知条件と通知の流れを示します。 （図）スケジュール起点の通知の流れ 注意事項 1つのYAMLファイルに1つのオブジェクトしか指定できないため、複数のオブジェクトについて設定をする場合は、複数のYAMLファイルに記載する必要があります。 通知条件の例とそれらのYAMLの定義例については「スケジュール・作業項目起点の通知例」を参照してください。 （3）ワークフローを起点にした場合の通知 以下に、ワークフローを起点にした通知例として、VM貸出業務を行った場合の各アクティビティに対する通知例を示します。 （図）VM貸出業務を行った場合の通知例 （表）VM貸出業務を行った場合の通知内容の一覧 作業名 ワークフロー ステップ 宛先 タイトル 本文 VM貸出 申請 運用担当者 [ワークフロー番号（直リンク）]VM貸出の申請通知 VM貸出の申請通知が到着しています。対応お願いします。 申請日時：申請日時 申請者：申請者 申請内容の確認 申請者 [ワークフロー番号（直リンク）]VM貸出の却下通知 VM貸出の却下通知が到着しています。申し送り事項を確認の上、対応お願いします。 申請日時：申請日時 申請者：申請者 VM生成の確認 申請者 [ワークフロー番号（直リンク）]VM貸出のキャンセル通知 VM貸出のキャンセル通知が到着しています。申し送り事項を確認の上、対応お願いします。 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/document_storage/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/document_storage/index.html ISOなどの規格を取得する場合、さまざまな運用の作業記録や証跡が必要です。 ドキュメントの保管方法では、エビデンスについてどのように格納するのかを設計する必要があります。 Ops IではAttachment定義でエビデンスをルールに基づいて管理するコンテナを作成します。 その後、Distribution定義で顧客やサービスごとにリポジトリを振り分けることが可能です。 コンテナについての詳細は、「コンテナ」を参照してください。 【Attachment】 Attachmentでは、コンテナ名/フォルダ名などの命名ルールを定義します。 タイムスタンプや識別子を入力することができます。 タイムゾーンについては、YAML定義で指定します。 なお、ワークフロー実行時のタイムスタンプは、実行ユーザーのユーザー設定時のタイムゾーンとなるため、フォルダ名のタイムゾーンと異なる時刻設定になることがあります。ユーザー設定時のタイムゾーンを指定しておくことを推奨します。 AttachmentのYAML定義については「Attachment」を参照してください。 （図）AttachmentとDistributionの概念図 【Distribution】 Distributionでは、配布先、リポジトリ、グループを定義します。 （図）Distributionの概念図 AttachmentとDistribution のYAML定義の詳細は「Attachment」および「Distribution」を参照してください。 注意事項 一度登録した配布ルールは削除しないでください。また、配布ルールを複数作成する場合は、別ファイルにして登録してください。 顧客ユーザー以外のユーザーがワークフローにファイルを添付した場合、DistributionのYAML定義でドキュメントの配布先グループのtypeに"customer"を設定している配布ルールは適用されません。 （表）ドキュメント管理設計項目と概要 項目 定義手段 設計のポイント ・Attachment ・Distribution YAMLファイル お客様のサービスを考慮して、ドキュメントを管理するリポジトリ構成、グループによる参照範囲、証跡などのファイル命名ルール、振り分け保管ルールを検討しておきます。 リポジトリやグループの考え方については、「ドキュメント」を参照してください。 （図）ドキュメント管理方法の概念図 以下の表は、VMの貸出を例としたドキュメントコンテナの設計項目の一覧になります。Distributionによって「vm/create/」や「vm/delete/」などのディレクトリパスでGitLabでの振り分け先などを定義します。例えば、VM生成時の実行ログの場合、「/vm/create/log」配下にエビデンスを配置します。 （表）VMの貸出を例としたドキュメントコンテナの設計 リポジトリ ファイル 関連するワークフロー 配布パス（配布先/コンテナ名/フォルダ名） 種別 ワークフロー/ステップ 配布先 コンテナ名 フォルダ名 サービス共通 VM生成時のチェックリストひな形 UI（参照） 2(1) VMの貸出 - VM生成の確認 /vm/create/ template - VM削除時のチェックリストひな形 UI（参照） 2(2) VMの削除 - VM削除の確認 /vm/delete/ template - 受注管理システム VM生成時の記入済みチェックリスト UI（保管） 2(1) VMの貸出 - VM生成の確認 /vm/create/ checklist 実施日時 VM削除時の記入済みチェックリスト UI（保管） 2(2) VMの削除 - VM削除の確認 /vm/delete/ checklist 実施日時 顧客管理システム ： ： ： ： ： ： 生産管理システム ： ： ： ： ： ： https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/user_acl/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/user_acl/index.html ユーザーとACL（Access Control List）の設計では、ユーザー、グループ、ロールの作成において、どのような権限が必要か検討しておく必要があります。ユーザーの操作権限は、直接またはグループや他のロールを介して間接的に割り当てられるロールのアクセス権によって決まります。 （表）ユーザーとACL設計項目と概要 項目 定義手段 設計のポイント ・User ・Group ・Role GUI ユーザー、グループ、ロールの作成と割り当てを実施しておきます。 ・ACL YAMLファイル ユーザー、グループ、ロールに対して、UI、アプリケーションなどへのアクセス範囲を検討しておきます。ACLはロールに対してのみ直接割り当てることができます。 ・GitRole GUI グループに割り当てられたユーザーに対して、リポジトリへのアクセス範囲を検討しておきます。 ・組織内のロール GUI ユーザーに対して、AWXの組織ごとにアクセス範囲を検討しておきます。 ユーザー管理設定の詳細は、「ユーザー管理」を参照してください。 VMの貸出を例として、必要なロールを以下に示します。各ステップに適したロールを割り当てる必要があります。 （図）VMの貸出を例としたワークフロー （表）VMの貸出を例としたロール一覧 作業名 ワークフローのステップ 操作者 Pre-Installedロール VMの貸出 申請 申請者 Customer User 申請内容の確認 運用担当者 Operation Management Office Agent VMの生成 （自動実行） - VMの生成の確認 運用担当者 Operation Management Office Agent VMの生成の最終確認 運用管理者 Operation Management Office Manager Ops I上の標準ロールとしてPre-InstalledロールとPrimitiveロールが提供されます。標準ロールの詳細は「Ops I上のロールとサポート機能の対応関係」を参照してください。 また、顧客ユーザーには、必ずPre-Installedロール「Customer Manager」または「Customer User」を設定します。 「Customer User」はPrimitiveロール「customer」が割り当てられており、所属する顧客に関連があるレコードのみ操作できるように制限することができます。 デフォルトで提供される標準ロールで対応ができない場合は、任意のカスタムACLを作成し、カスタムロールに適用することができます。また、標準ロールの権限を変更したい場合、Pre-Installedロールと差分の権限情報を記述したカスタムACLをカスタムロールに割り当てることで実現することができます。 詳細については「JP1 Cloud Service 運用統合 APIリファレンス」の「APIリファレンス概要＞APIの詳細と実行例＞ロールにカスタムACLを割り当てる、割り当てを解除する＞ロールにACLを割り当てる」を参照してください。 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/skill_manage/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/skill_manage/index.html Ops Iには、業務に適したユーザーをアサインできる、スキル管理機能があります。 スキル管理は、運用に必要なスキルをYAMLファイルで定義し、定義したスキルをOps I GUIでユーザーに付与することができます。また、ワークフローの各アクティビティにスキルセット（スキルの組み合わせ）をYAMLファイルで定義することで、各アクティビティに適切なユーザーをアサインすることができます。これらのYAMLファイルの定義や、スキルの付与などの詳細については以下を参照してください。 YAMLファイルの設定：「Workflow」、「Skill、Skillset」 スキルのユーザー付与：「リソース」 各アクティビティへユーザーをアサイン：「ワークフロー」 また、スキルやスキルセットを定義するために事前に運用に必要なスキルを整理する必要があります。詳細については「運用に必要なスキル」を参照してください。 （表）スキル管理項目と概要 項目 定義手段 設計のポイント Skill、Skillset YAMLファイル 運用に必要なスキルとスキルセットを設定できます。 Workflow YAMLファイル 各アクティビティに必要なスキルセットを指定することができます。 ユーザーへのスキル付与 GUI リソースタブからユーザーにスキルを付与することができます。付与したスキルによって、自動でスキルセットも付与されます。 各アクティビティへユーザーをアサイン GUI スキルセット要件との適合率、経験回数、スケジュールを確認しユーザーをアサインすることができます。 （図）スキル管理の流れ スキルの設定を行うには、グループ単位の関係設定が必要です。グループ間の管理関係設定は、システム管理画面のグループ設定から行うことができます。また、スキル設定を行うには、管理者および管理対象者ともにYAMLファイルが登録されているリポジトリのグループに属している必要があります。YAMLファイル登録先グループは複数設定することができ、ユーザーに設定できるスキルをグループごとに分離することができます。 （図）グループ管理関係 また、ユーザーへのスキル設定は、リソースタブから実行できます。 グループ間の管理関係設定の詳細は「ユーザー管理」、「グループ」を、スキル設定操作の詳細は「リソース」を参照してください。 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/design_auto/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/design_auto/index.html Ops Iでは、AnsibleのPlaybookを使用することにより運用業務の自動化を実現できます。また、既存システムなどの運用対象へのアクセスが必要な場合、Vaultを使用したシークレット管理機能により、IDやパスワードなどの管理を安全に行えます。PlaybookはGitLabで管理されています。 シークレットについては「シークレット管理」を参照してください。 （表）自動化の設計項目と概要 項目 定義手段 設計のポイント Playbook ・YAMLファイル ・GUI 随時作業のワークフローで、自動運用にするものと手動運用にするものを分類します。 初期導入を簡略化するには、自動運用は頻度が高いものに絞り、段階的に自動化を拡充します。 Vault ・GUI Playbookでアクセスする対象のクレデンシャル情報を事前に登録します。 （図）自動化の概念図 たとえば、VMの貸出業務でVMの生成のアクションをPlaybookにYAML定義しておくことで、ワークフローのステップで申請が承認された際に、申請内容に沿ってVMの生成が自動実行されます。 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/ticket_manage/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/ticket_manage/index.html Ops Iでは、運用時に発生するリクエストやインシデントなどの対応をチケットによって管理することで、効率よくITサービスの運用・管理を行うことができます。チケット管理は主にタスクアプリケーションまたはリクエストアプリケーションのチケットタブで、チケットの作成、確認、および更新を行います。また、チケット間の関連付けも行うことができます。 YAMLファイルの定義、API実行、およびITSMアプリケーションのOTOBOと連携することで、チケット画面のカスタムや、チケット操作にあわせたメールの通知や受信の設定をすることもできます。 （表）チケット管理の設計項目と概要 項目 定義手段 設計のポイント ロールによる表示と操作権限 GUI チケットの表示・操作範囲を、ユーザーまたはグループごとに整理し、割り当てるロールを検討します。 チケットのタイプ GUI チケット管理する事象や対応のプロセスによって、使用するチケットのタイプを整理します。 チケット画面のカスタム※1 YAMLファイル あらかじめ用意されているチケットのタイプに対する、フィールドの追加・削除やステータスの変更について検討します。 担当窓口の設計※2 GUI チケットを振り分ける担当窓口（キュー）を検討します。 チケットの監視者※3 GUI 担当者、担当グループ、および作成者以外でチケットの閲覧や通知受け取りが可能となる、チケット監視者について検討します。 通知※3 GUI、ITSMアプリケーション 通知方法、通知タイミング、宛先、メール通知の内容について検討します。 インポート、エクスポート GUI チケットのcsvエクスポートの要否、および他製品から移行する場合など、チケットのインポートの要否を検討します。 SLAの管理※4 ITSMアプリケーション インシデントチケットに対するSLAを検討します。 承認フロー※5 Rest API、GUI 承認フローを有効にするタイプ、承認を必要とするステータス、承認後および却下後のステータス遷移について検討します。 ※1：チケットのカスタムの詳細については「チケット画面のカスタム」を参照してください。 ※2：担当窓口の作成、編集方法の詳細については「JP1 Cloud Service 運用統合 利用ガイド（ITSM操作編）」の「[管理]＞担当窓口の作成・編集」を参照してください。 ※3：チケットの監視者、チケットの通知の詳細については「チケットの通知機能」を参照してください。 ※4：SLAの管理の詳細については「SLAの管理機能」を参照してください。 ※5：承認フローの詳細については「承認フロー」を参照してください。 （1）概要 チケット管理では、リクエストやインシデントなどITILのプロセスにしたがって、それぞれのタイプのチケットを作成し、チケット情報のステータスや担当者を遷移させてチケットの対応をします。また、各チケットの作業メモ画面を利用してユーザー同士でやりとりができます。 チケットは、その目的やプロセスが完了するとクローズします。たとえば、インシデントタイプのチケットの場合は、そのインシデントが解決するとクローズします。インシデントに対して作業メモで議論された内容や、チケット詳細情報の結論フィールドに調査結果や対処などを記録できます。これにより、また同様のインシデントが発生した場合などの参考情報として活用することもできます。 このように、多くのチケットの中から参考情報や関連するチケットを検索するため、高度なフィルタ機能とGUIによるチケット検索や確認を可能とするチケットブラウザー画面を提供します。詳細については「チケット」を参照してください。また、チャットパネル（Co-Operatorチャットパネル）からチケットを検索することができます。詳細は「AI拡張機能」を参照してください。 また、インシデントタイプのチケットはSLAの管理機能により、解決に向けた目標期限の遵守状況を確認できます。 （図）チケット管理の概念図 【チケット管理のユースケース】 お客様からの問合せがあり、問合せチケットを作成する 資料を添付ファイルでチケットにひもづける 関連情報を関連リンクでチケットにひもづける 問合せを確認し、インシデントチケットを作成する 作業メモを利用し、担当者で情報共有を行う SLAの管理機能で対応目標に対する遵守状況を監視する 障害復旧を行うために変更（障害復旧）チケットを作成する 一時的な対処の計画を立てる 計画が承認され、実行する 一時的な対処がされたことを確認する 原因の調査を行うため、問題チケットを作成する 必要に応じて作業ごとにタスクチケットを作成して対応する 根本原因の対応を行うため、変更（通常）チケットを作成する 変更の計画を立てる リスク調査をするためにタスクチケットを作成する 担当者がリスク調査をする 調査が完了する 調査結果を反映した計画を立てる 計画が承認され、実行する 関連チケットの完了後、お客様に確認の上、問合せチケットを完了する （2）チケット管理の基本知識 チケット管理をする上での基本知識を以下に示します。 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/schedule_manage/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/schedule_manage/index.html スケジュールの設計では、定常業務（非定期/定期）、随時業務ごとにスケジュールの作成、担当者の割り当て、および確認、更新を行います。 （表）スケジュール管理の設計項目と概要 項目 定義手段 設計ポイント 業務の設定内容 － 洗い出した業務に対して、担当グループや担当者、繰り返しのパターン、およびワークフローのひもづけの有無など設定内容を検討します。 スケジュールの追加方法 － 業務が定常業務か随時業務か、またはIT運用以外の業務かなど業務の種類にあわせて、業務起点またはユーザー起点のどちらでスケジュールを追加するか検討します。 スケジュールの追加 ・GUI ・YAMLファイル 業務起点でスケジュールを追加する場合は、スケジュールをGUIのみで追加するか、GUIと予定表テンプレート（YAML）を使用して追加するか検討します。 予定表テンプレート ・YAMLファイル 業務に必要な一連の作業内容を予定表テンプレートとしてYAML定義しておきます。頻発する業務に活用できます。 担当者情報などはGUIで設定します。 （1）概要 Ops Iでは、IT運用で発生する多くの業務のスケジュールを運用統合して管理できます。 スケジュールは、定常業務（非定期/定期）または随時業務で分類分けして登録が可能で、スケジュールの種類、進捗度、および状態などあらゆる情報が可視化されます。これにより、人を介す作業、人を介さない作業が混在していても、効率よく業務を管理することができます。 作業は繰り返し自動実行することができます。この繰り返し作業のうち、イレギュラーに対応するため特定の回の作業のみ内容を変更することも可能です。 また、スケジュール通知機能により、スケジュールに設定した作業の実行日時になると、自動的に担当者へ通知するなどの設定ができ、作業漏れを防止します。スケジュール通知の詳細については「通知の設計」、「Notification、Notifier」を参照してください。 （図）スケジュール管理の概要 Ops Iでのスケジュール管理では主に以下の機能を提供します。 （表）スケジュール管理の機能一覧 項目 説明 予定表管理機能 IT運用の業務のスケジュールをグループ化して管理できます。 作業項目管理機能 予定表の中の個々の業務のスケジュールの追加、編集、および確認ができます。 リソース別スケジュール機能 ユーザーごとに、IT運用およびIT運用以外の業務のスケジュールの追加、編集、および確認ができます。 （2）スケジュール管理の基本知識 スケジュールを管理する上での基本知識について説明します。 【スケジュール管理の主な要素】 スケジュール管理では、主に「予定表」、「作業項目」、および「スケジュール」によってスケジュールの作成、確認、および更新などを行います。以下に3つの要素の構成関係を示します。 （図）予定表、作業項目、およびスケジュールの構成関係 （表）予定表、作業項目、およびスケジュールの詳細 項目 説明 予定表 IT運用における 作業項目とそれらにひもづくスケジュールの集まりで構成されます。 IT運用は、バックアップ、保守、監査、およびメールチェックなど多くの作業があります。予定表は、これらの作業を分類分けしてグループ化することができるので、管理が容易になります。また、作業の実行担当や、作業を参照するのみのマネージャーや監査者など、複数のユーザーグループをひもづけることができます。 予定表は、GUIおよびYAMLファイルで定義可能な予定表テンプレートを使用して作成することができます。 作業項目 予定表を構成する要素で、スケジュールを定義するための箱です。 作業項目はGUIで追加できます。予定表テンプレートによって、作業項目を一括で登録することも可能です。 また、フォルダによってフォルダや作業をグループ化して管理することや、ワークフローを関連付けることが可能です。 スケジュール 作業項目の中の1つ（1回）の作業の実体であり、作業の進捗や実績を表します。 プログレスバーとしての機能をもち、進捗やステータスを色で確認できます。また、状態を表すアイコンにより、作業の情報を容易に確認することができます。 【作業項目のフォルダと作業】 作業項目はフォルダよって、フォルダや作業をグループ化して管理することができます。これにより、作業項目は階層構造をもつことができ、フォルダの配下にフォルダを作成することが可能です。作業の配下にフォルダや作業を作成することはできません。 （図）作業項目のフォルダと作業 【ロールによる表示と操作権限】 表示できる予定表、作業項目、スケジュールに対してロールによる操作制限は基本的にありません。ただし予定表を作成する場合は、Primitiveロール「calendar_user」が割り当てられている必要があります。 スケジュールタブを表示するために必要なロールについては「Ops I上のロールとサポート機能の対応関係」を参照してください。 ロール以外の表示や操作に関する条件については「（表）予定表管理機能画面の構成要素」、「（表）作業項目管理機能画面の構成要素」、「リソース別スケジュール機能」を参照してください。 （3）スケジュールとワークフローの関連付け スケジュール管理では、以下の2つの方法でスケジュールとワークフローを関連付けることができます。 【作業項目管理機能で設定】 「作業項目管理機能」の作業項目の追加画面または編集画面で、実行するワークフローを指定することができます。 作業項目にワークフローを関連付けることによって、設定した実行日時や繰り返しパターンにあわせてワークフローを自動実行することができます。また、ワークフローのパラメータやステップごとの担当者を設定することもできます。 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/site_manage/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/site_manage/index.html サイトアプリケーションではOSSのWordPressを使用することで、顧客や利用部門ごとにサービスポータルを作成して提供することができます。 WordPressを利用することで、直感的な操作でのサイト作成が可能です。また、サイト管理にあると便利な機能をプラグインによって提供します。WordPressのマニュアルおよびバージョン、エディションについては付録「OSSのバージョンおよびエディション、参照先のマニュアル」を参照してください。 以降、サイト管理において「サービスポータル」は「サイト」と表記します。 （表）サイト管理の設計項目と概要 項目 定義手段 設計のポイント ロールによる表示と操作権限 GUI サイトの管理画面の表示・操作範囲に合わせてユーザーごとに割り当てるロールを検討します。 サイトの構成 GUI 顧客や利用部門ごとに埋め込むOps Iの画面や、サイトの構成を検討します。 ACLとStatement GUI サイトへのアクセス制限のため、URI認可の設定を検討します。 サイトの公開と更新 GUI サイトの公開や更新のため、サイトのエクスポート/インポート時の環境を検討します。また、更新やメンテンナンス中は、サイトをメンテナンスモードにしてユーザーの利用の抑止を考慮します。 （1）概要 サイトにはOps Iの画面を埋め込むことができます。例えば、サービスカタログタブやチケットタブの画面などを埋め込むことで、顧客ユーザーはそのサイトから申請や問い合わせをすることができます。 サイトは複数作成することができるので、顧客ごとや利用部門ごとにサイトを提供することが可能です。 以下にサイト管理の概要図を示します。 （図）サイト管理の概要図 （2）ロールによる表示と操作権限 Ops Iロールによって、サイトの管理画面へのアクセスや操作権限を制御します。以下に、ロールと表示や操作権限の対応について示します。 （表）ロールと操作や表示権限の対応 ユーザーの種類 Ops Iロール （Primitiveロール） 説明 サイトネットワーク管理者 portal_network_admin 以下の操作が可能 サイトの管理（作成、更新、削除、コピー） テーマのインストール、アップデート、削除 サイトのインポート、エクスポート サイト管理者 portal_site_admin 以下の操作が可能 サイト内のコンテンツ（固定ページ、投稿、お知らせ）の管理 サイト内のテーマのカスタマイズ（インストール、アップデート、削除は不可） 投稿の管理者 portal_author 投稿の追加と公開が可能 投稿の作成者 portal_contributor 投稿の追加が可能（公開は不可） サイトの利用者 portal_subscriber サイトや投稿の閲覧、投稿へのコメントが可能 上表のOps Iロール（「portal_subscriber」を除く）が割り当てられているユーザーは、Ops I画面のメニューエリアのサイトアプリケーションから、サイトの管理画面（WordPressの画面）にアクセスすることができます。 Primitiveロール「portal_subscriber」の詳細について以下に示します。 ひもづくPre-Installedロールは以下で、顧客ユーザーとリクエスターユーザーに該当する Requester User Requester Manager Customer User Customer Manager サイトの管理画面の表示はできない テンプレートサイトへのアクセスはできない（テンプレートサイトの詳細は「メインサイト/テンプレートサイト」を参照） メモ https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/knowledge_manage/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/knowledge_manage/index.html ナレッジ機能により、障害対応や問合せ対応で得られた知見やノウハウをナレッジ記事として蓄積し、新たな問題の解決のため活用できます。 ナレッジ記事は、カテゴリーでの分類やナレッジ記事の有用性を評価するための格付け（レーティング）ができ、ナレッジ記事を効率よく利用できます。また、ナレッジ記事へのアクセス制御をすることで、特定のユーザーがアクセスできる情報の制限ができます。 ナレッジ機能の運用のため以下を検討する必要があります。 （表）ナレッジ管理の設計項目と概要 項目 定義手段 設計のポイント ・ロールによる表示と操作権限 GUI ナレッジ記事の操作に合わせてユーザーに割り当てるロールを検討します。 ・カテゴリーの管理 ・カテゴリーの有効/無効 （表示/非表示） ITSMアプリケーション ナレッジ記事の内容による分類や、アクセス制御に合わせたカテゴリーの構成について検討します。 カテゴリーの作成、編集、削除を行います。 カテゴリーをナレッジアプリケーションで表示させるかどうかを検討します。 ・ナレッジ記事の管理 ・ナレッジ記事の有効/無効 （表示/非表示） ・ナレッジ記事のステータス管理 ITSMアプリケーション ナレッジ記事の作成、編集、削除、添付ファイルの登録を行います。 ナレッジ記事をナレッジアプリケーションで表示させるかどうかを検討します。また、顧客ユーザー、リクエスターユーザーに公開するかどうかを検討します。 ・顧客によるアクセス制御 ・グループによるアクセス制御 ITSMアプリケーション カテゴリーに割り当てる顧客、グループを検討します。 ・インポート/エクスポート ITSMアプリケーション 検証環境から本番環境の移行など、ナレッジ記事やカテゴリーのインポート、エクスポートを行います。 （1）ナレッジ機能の概要 ナレッジ機能は行う操作によって、必要な権限と操作するアプリケーションなどが異なります。 ナレッジ機能の運用は主にITSMアプリケーションで行います。ITSMアプリケーションなどに対する操作（「（図）ユーザーの操作権限」赤色の矢印の操作）は、すべてのカテゴリーおよびナレッジ記事に対して行えます。 ナレッジ機能の運用者は、どのナレッジ記事を誰に公開するなどのアクセス制御の設定を、ITSMアプリケーションで実施します。アクセス制御の詳細については「ナレッジ記事へのアクセス制御」を参照してください。 カテゴリーやナレッジ記事の閲覧は主にナレッジアプリケーションで行います。ナレッジアプリケーションなどに対する操作（「（図）ユーザーの操作権限」青色、緑色の矢印の操作）は、閲覧するユーザーにアクセス権があるカテゴリーおよびナレッジ記事に対して行えます。 以下に各ユーザーとアプリケーションの関係を示します。 （図）ユーザーの操作権限 また、各ユーザーは以下を意味します。（）内はユーザーにひもづいているPre-Installedロールを示します。 リクエスターユーザー（Requester User）： 業務システムの利用者。Ops Iのサービスポータルやナレッジアプリケーションから申請や問合せを行います。 顧客ユーザー（Customer User）： 業務システムの顧客業務システムの利用者。Ops Iのサービスポータルやナレッジアプリケーションから申請や問合せを行います。同じ顧客のナレッジ記事のみ閲覧できます。 運用管理担当者（Operation Management Office Agent）： Ops Iのシステム管理者。申請や問合せの対応、ナレッジ記事の作成を行います。 サービスデスク担当者（Service Desk Agent）： サービスデスクの担当者。リクエスターユーザーや顧客ユーザーからの問合せに対応します。 Ops I担当者（System Administrator）： Ops Iの運用改善をする担当者。Ops Iのサイトアプリケーションからサービスポータルを作成します。 各アプリケーションへのアクセスに必要なロールは「Ops I上のロールとサポート機能の対応関係」を参照してください。また、 各操作に必要なPrimitiveロールは、ITSMアプリケーションの操作については「JP1 Cloud Service運用統合利用ガイド（ITSM操作編）」の「概要＞前提知識＞ロール（機能別）」を、サービスポータルの操作については「ロールごとの表示画面と項目」を参照してください。 ナレッジ管理の各操作を行うアプリケーションと、各アプリケーションに遷移できるパネル、および画面を以下に示します。操作の詳細は、詳細列から参照してください。 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/datamodel_design/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://itpfdoc.hitachi.co.jp/manuals/JCS/JCSM71029001/customer/work_design/datamodel_design/index.html データモデルの設計では、データモデルの定義を行います。 （表）データモデル設計項目と概要 項目 定義手段 設計のポイント Datamodel YAMLファイル 目的によりデータモデルの種類や構成を検討します。 また、管理しておくデータレコードを整理し、テーブル、カラムなどのデータモデルを設計します。 データモデルでは、1つのデータモデルの枠組みの中で複数のテーブルをまとめて管理できます。 データモデルで定義したテーブルは、UI（UIバージョン1.1）のYAML定義とひもづけることにより、ユーザーが作成するアプリケーションやワークフローの各ステップから参照できます。 UIのYAML定義の設定は以下で行います。 dataSourceラベル Formコンポーネントのfieldsのsourceラベル、またはTableコンポーネントのcolumnsのsourceラベル UIのYAML定義の詳細は「UI（UIバージョン1.1）」を参照してください。 また、ユーザーが定義したデータモデルと登録されたレコードは、データモデルアプリケーションから確認できます。詳細は「データモデルの管理」を参照してください。 （1）データモデルの種類 データモデルには以下の3種類があります。DatamodelのYAMLファイルで設定できます。DatamodelのYAML定義の詳細は「Datamodel」を参照してください。 カスタムテーブル：単一のテーブル tablesラベルで定義します。 カスタムビュー：複数のカスタムテーブルを結合した閲覧のみ可能なテーブル viewsラベルで定義します。 Schemaデータモデル：JSON Schemaファイルで設定 schemasラベルで定義します。 カスタムビューは、単一のカスタムテーブル、または結合した複数のカスタムテーブルにより構成されます。カスタムビューには以下の特徴があります。 閲覧のみ可能 カスタムテーブルと同様に任意のカラムで表示できる（columnsラベル） 単一のカスタムテーブルをひもづけることができる（fromラベル） 複数のカスタムテーブルを結合し、お互いの配置を選択できる（fromラベル、joinラベル） 結合するための条件を設定できる（conditionsラベル） 結合したカスタムテーブルの表示条件を設定できる（whereラベル） 定義例は「カスタムビューの定義例」を参照してください。 メモ カスタムビューはカスタムテーブルと結合できません。 デフォルトで用意されたuserテーブルとgroupテーブルをカスタムテーブルに結合できます。 例えば、カスタムテーブルにユーザーのIDしか表示されておらず、どのようなユーザーなのか一目でわからない場合などに使用します。その場合、カスタムテーブルのユーザーのIDとデフォルトで用意されたuserテーブルを結合し、ユーザー名や会社名などをカスタムテーブルに表示させることができます。 userテーブルについては「（表）userテーブル」を、groupテーブルについては「（表）groupテーブル」を参照してください。 【データモデルのレコードへのACL適用】 カスタムテーブルおよびカスタムビューのレコードに対してACLを適用できます。 ACLの定義は、GraphQL API（/api/v1/graphql）のObject認可のACLのYAMLファイルとStatementのYAMLファイルを定義することで行います。 StatementのYAMLファイルでGraphQLのObject名またはMutation Field名を指定する値（resources.graphqlQuery.value）に、ACLを適用するデータモデルの内部名が一致するように定義します。 これにより、GraphQLがレコードを操作する際の条件（resources.conditions）に合致するレコードに効果（resources.effect）が適用されます。 ここで（）内の記載は、StatementのYAMLファイルのラベル名を表します。ACL、StatementのYAML定義の詳細は「ACL、Statement」を参照してください。また、GraphQL APIの詳細は「JP1 Cloud Service 運用統合 APIリファレンス」の「APIリファレンス詳細＞標準提供API」を参照してください。 カスタムビューのデータに対しては、以下の順番でACLが適用されます。適用の過程でレコードに対して「allow」と「deny」と相反する効果が適用される場合は、明示的拒否になり「deny」が適用されます。 結合前のカスタムテーブルのレコードを操作するGraphQL APIに適合したACLが、結合前のレコードに適用される カスタムビュー自体のレコードを操作するGraphQL APIに適合したACLが、結合後のレコードに適用される 【データモデルのレコードの顧客分離】 データモデルのレコードには、レコードを作成したユーザーの顧客の設定が反映されます。また、カスタムテーブルについては、データモデルアプリケーションの[レコード詳細]画面から顧客の設定を変更できます。 カスタムビューのレコードには、カスタムビューに結合しているカスタムテーブルのレコードに設定されている顧客の中で、共通の顧客が設定されます。 （2）データモデルの管理 ユーザーが作成したデータモデルのうち、カスタムテーブルとカスタムビューは、データモデルアプリケーションで管理できます。 データモデルアプリケーションでは、以下が実施できます。 カスタムデータモデルの一覧の参照 カスタムテーブルのレコードの参照、追加、更新、削除 カスタムビューのレコードの参照 カスタムビューは参照のみ可能で、レコードの変更はできません。 また、ワークフローにひもづくデータモデルの変更はできません。 データモデルアプリケーションの操作の詳細については「カスタムデータモデル」を参照してください。 データモデルの定義を行うDatamodelのYAMLファイルの詳細は「Datamodel」を参照してください。