決まったタイミングでスクリプトや処理を自動実行する機能です。定型作業を人手から切り離し、対応漏れをなくします。
Scheduled Automationsの位置付け
NinjaOneには、処理を自動実行する仕組みが2つあります。
| 仕組み | 実行のきっかけ | 使いどころ |
|---|---|---|
| Scheduled Automations | 時刻やスケジュール | 定期的に必ず行う作業 |
| Conditionに紐づく実行 | 条件の成立 | 問題が起きたときの自動対応 |
「毎週日曜の深夜に一時ファイルを削除する」はScheduled Automations、「ディスク容量が逼迫したら一時ファイルを削除する」はConditionです。
両方を組み合わせると効果的です。定期的な予防処置で問題の発生自体を減らし、それでも起きた場合はConditionで自動対応します。
設定する場所
Policyの中で設定します。したがって、同じPolicyが適用されているデバイス群に一斉に効きます。
特定のデバイスだけで実行したい場合は、Policyを分けるか、デバイス操作（Actions）とWake-on-LANの手動実行を使ってください。
設定する項目
PolicyのScheduled Automationsから追加します。
指定するのは次の項目です。
| 項目 | 内容 |
|---|---|
Name | 用途が分かる名前 |
Description | 処理内容の説明 |
Schedule | 実行のタイミング |
Channel(s) | 結果を通知するチャネル |
Notify Technicians | 担当者へ通知するか |
Ticketing Rule | チケットを自動起票するか |
Automations | 実行する処理。右側のAddから追加する |
1つのScheduled Automationに複数の処理を登録できます。関連する処理をまとめておけば、実行の順序も管理できます。
Ticketing Ruleを有効にすると、実行結果がチケットとして残ります。失敗を確実に把握したい処理では設定しておいてください。
スケジュールの設定
実行のタイミングを指定します。
| 頻度 | 適した処理 |
|---|---|
| 毎日 | ログの収集、状態の点検 |
| 毎週 | 一時ファイルの削除、再起動 |
| 毎月 | 詳細な棚卸し、レポート用データの収集 |
実行時刻は業務時間外に設定するのが基本です。ただし次の点に注意してください。
【注意】 クライアント端末は業務時間外に電源が切れています。深夜に設定した処理は実行されません。クライアント向けの処理は、始業直後や昼休みなど、電源が入っている時間帯に設定してください。Wake-on-LANと組み合わせる方法もあります。
サーバーとクライアントで適切な時刻が異なるため、この点でもPolicyを分ける理由が生まれます。
実行対象の絞り込み
Policy内の設定なので、そのPolicyが当たっているデバイス全てが対象になります。さらに条件を付けて絞り込める場合もあります。
対象が広すぎないか、設定前に確認してください。そのPolicyが何台に適用されているかは、デバイス一覧をPolicyで絞り込めば分かります。
実行結果の確認
設定したら、実行されているかを確認してください。
| 確認する場所 | 分かること |
|---|---|
デバイス詳細画面のActivities | 個別のデバイスでの実行履歴と結果 |
ダッシュボードのActivitiesタブ | 全体の実行状況 |
| スクリプトの実行結果 | 成功したか、エラーが出ていないか |
実行されていないデバイスがある場合、原因は次のいずれかです。
- 実行時刻に電源が入っていなかった
- Offlineだった
- メンテナンスモードだった
- スクリプトがエラーで終了した
【運用のポイント】 設定した翌日に必ず結果を確認してください。設定しただけで動いていると思い込むのが、最も多い失敗です。特にクライアント端末では、実行率が想定より大幅に低いことがあります。
定番の自動化例
導入初期に効果が出やすい処理を挙げます。
| 処理 | 頻度 | 効果 |
|---|---|---|
| 一時ファイルとキャッシュの削除 | 週次 | ディスク容量の逼迫を予防する |
| 長期間再起動されていない端末の再起動 | 週次 | 更新の適用を確実にする |
| ディスクの状態確認 | 日次 | 故障の予兆を早期に把握する |
| 特定サービスの起動確認と再起動 | 日次 | 業務アプリの停止を防ぐ |
| 独自の点検スクリプトとCustom Fieldsへの記録 | 日次 | 標準では取れない情報を蓄積する |
最後の項目は応用範囲が広い使い方です。点検結果をCustom Fieldsに書き込んでおけば、その値をConditionの条件に使えます。詳細はCustom Fieldsの基礎と活用を参照してください。
導入時の進め方
いきなり全台に適用しないでください。次の順で広げます。
- 検証用のデバイス1台で手動実行し、結果を確認する
- 検証用のPolicyに設定し、数台で自動実行を確認する
- 翌日、実行結果を確認する
- 問題がなければ本番のPolicyに設定する
- 展開後、実行率を確認する
3番目と5番目を省かないでください。手動では動くが自動実行では動かない、という状況は珍しくありません。実行ユーザーの権限が異なることが主な原因です。