メインコンテンツまでスキップ

業務プロセス — 誰が、いつ、何を

プラットフォームを組織でどう運用するかをまとめた文書です。画面の使い方ではなく、役割と 順序を扱います。

チュートリアルとは異なります

チュートリアルが「一人で初めてやってみる」であれば、この文書は 「複数人が継続的に運用する」です。担当が分かれ、引き継ぎが発生する地点に印を付けています。

役割は3つだけです​

役割画面表記担当
ADMINシステム管理者アカウント・セキュリティ・設備マスター・システム設定全般
APIAPI開発者外部システム連携。トークンでAPI呼び出し
USER一般ユーザー照会中心。変更権限なし
MANAGER 役割はありません

ソースに存在しません。「中間管理者に一部権限のみ」が必要な場合は、役割ではなく セキュリティポリシー(権限グループ) で対応します → セキュリティ管理。

役割別に表示されるメニューが異なります → ログインと画面構成。

ライフサイクル — 3つの段階​

全体を役割別レーンで見るとこのようになります。矢印がレーンを跨ぐところが引き継ぎポイントです。

1. 導入・コミッショニング — 一度だけ、ただし確実に​

順序作業内容担当成果物
1インストール構築起動したプラットフォーム → インストール
2デフォルトパスワード全量変更構築引き継ぎ文書 → 初期パスワード変更
3ID規則を確定構築 + 現場命名規則書 → ドメイン ID規則
4サイト → 設備 → タグを登録構築設備マスター
5Edge接続・収集を検証構築画面に値が表示される
6アラーム閾値を設定現場アラーム定義 → アラーム管理
7アカウント発行・役割を付与ADMINユーザー一覧 → ユーザー管理
8受け入れ点検現場受け入れ確認書
3番をスキップすると取り戻しにくくなります

ID は画面・API・レポート全般にそのまま記録されます。急いで付けた ID は長く残ります。 登録を開始する前に 規則を文書化してください。

2. 正常運用 — 定期的な作業​

周期作業内容担当
毎日アラーム確認・対応、収集断絶確認現場
週1回ディスク・リソース推移を確認 → モニタリングADMIN
月1回バックアップ復旧リハーサル、アカウント整理ADMIN
四半期パスワードローテーション → クレデンシャルローテーションADMIN
バックアップは「受け取ること」ではなく「復旧すること」です

受け取るだけで復旧をしたことがない状態が最も一般的な失敗です。ストレージが3つあるためなおさらです → データベースモデル。

3. 変更・拡張 — 設備が増えたり変わったりする場合​

作業内容順序
設備追加マスター登録 → タグ → 収集確認 → アラーム
タグ意味変更既存データと単位が混在しないか必ず確認
連携追加APIアカウント発行 → トークン → IP制限 → API マニュアル
タグを再利用しないでください

使用中のタグの意味を変えると、過去データと新データが同じ名前で混在します。 レポートは それを区別できません。新しいタグを作成してください。

引き継ぎポイント — ここで頻繁に断絶します​

引き継ぎ手渡すべき物
構築 → 現場アカウント一覧、変更したパスワードの保管位置、ID規則書、受け入れ確認書
現場 → システム管理者障害時連絡先、診断tarball生成方法(./doctor.sh)
担当者交代上記全て + 最近の変更履歴
パスワード値そのものを引き継ぎ文書に記載しないでください

どこに保管されているかを記載します。値は別途の秘密管理手段で受け渡します。

よくずれる地点​

症状大抵の原因
「誰がこれを変えたのかわからない」アカウントを共有して使用している — 人ごとにアカウントを作成してください
「アラームが多すぎて誰も見ない」導入時に閾値を決めたまま手を付けない。四半期ごとに再調整してください
「データが途中からない」収集断絶を毎日見ていない。日次点検に組み込んでください
「引き継ぎを受けたがパスワードがわからない」引き継ぎ文書に保管位置がない

関連文書​