運用の現場で用語があいまいだと、会議についていけなかったり、障害対応の通話で確認の往復が増えて復旧が遅れたりします。
報告やチケットが曖昧になれば、後続の作業が手戻りすることも。
つまり「用語を知っているかどうか」が、対応スピードや安心感に直結するのです。
この記事では、配属初日から3年目くらいまでに知らないと困る20語を厳選しました。
定義を覚えるよりも「どんな場面で使われるのか」を理解し、会話についていけるようになることを目的にしています。
目次
- 1 必修20語
- 1.1 可用性(Availability)
- 1.2 冗長化(Redundancy)
- 1.3 フェイルオーバー(Failover)
- 1.4 インシデント(Incident)
- 1.5 変更管理(Change Management)
- 1.6 リリース(Release)
- 1.7 ロールバック(Rollback)
- 1.8 MTTR(Mean Time to Repair)
- 1.9 アラート(Alert)
- 1.10 一次対応(First Response)
- 1.11 二次対応(Second Response)
- 1.12 エスカレーション(Escalation)
- 1.13 バックアップ(Backup)
- 1.14 スナップショット(Snapshot)
- 1.15 死活監視(Health Check)
- 1.16 キャパシティ計画(Capacity Planning)
- 1.17 スループット(Throughput)
- 1.18 サーバーログ(Log)
- 1.19 ジョブ(Job/Batch)
- 1.20 パッチ(Patch)
- 2 まとめ
必修20語
可用性(Availability)
システムがどれだけ止まらずに利用できるかを表す言葉。
「99.9%の可用性」なら、1か月に40分程度までの停止が許される計算になる。
計画停止を含むかどうかは契約やルールによるため、認識を合わせておく必要がある。
冗長化(Redundancy)
機器やサーバーを複数用意して、1台壊れてもサービスを止めない仕組み。
「片方が落ちてももう片方で動く」という考え方で、可用性を高めるために必須。
ただし設計や切替手順が甘いと結局止まるため、冗長化されている=安心ではない。
フェイルオーバー(Failover)
稼働中の機器が故障したときに、自動または手動で待機機に切り替えること。
冗長化とセットで語られることが多く、「切替に何秒かかるか」が現場では重要。
試験をしておかないと、いざという時に切替できず障害が長引くことがある。
インシデント(Incident)
サービスに悪影響を与える、または与える可能性がある出来事。
障害でシステムが止まるケースはもちろん、レスポンスが遅い、エラーが増えている、といった兆候も含まれる。
「障害」と「インシデント」を区別して話せると、報告や議論がスムーズになる。
変更管理(Change Management)
本番に変更を加えるときに、影響やリスクを整理して承認を得る仕組み。
勝手な変更で障害を起こさないためのルールであり、運用では必ず登場する。
「誰が承認するのか」「戻す条件は何か」を明確にしていないとトラブルにつながる。
リリース(Release)
変更や新機能を本番環境に反映すること。
単なるファイルの配置だけでなく、設定や確認まで含めてリリースと呼ぶ。
「どこまで終わったらリリース完了か」を共有しておかないと、チームで認識がズレやすい。
ロールバック(Rollback)
変更後に問題が起きたとき、元の状態に戻すこと。
設定やプログラムを直前の状態に戻すケースが多い。
ロールバック手順を事前に用意していないと、障害からの復旧が大幅に遅れてしまう。
MTTR(Mean Time to Repair)
障害が発生してから復旧までにかかる平均時間を示す指標。
「うちのMTTRは30分」といえば、平均で30分以内に復旧できているという意味。
短くするには監視の速さ、初動の切り分け、復旧の標準化など総合力が必要。
アラート(Alert)
監視システムが「人が対応すべき」と判断して通知するもの。
単なる記録(イベント)とは異なり、無視できないサイン。
アラートが多すぎると現場はパンクするため、適切なしきい値設定が大事になる。
一次対応(First Response)
障害を検知したときに最初に行う基本対応。
ログ確認、再起動、切り分けなどの初動を指す。
範囲が曖昧だとたらい回しになりやすく、手順書で明確にしておくことが多い。
二次対応(Second Response)
一次対応で解決できない場合に、専門知識を持つ人が引き継ぐ対応。
アプリの不具合調査やDBの復旧など、深い作業はこちらで行う。
呼び出しが遅れると復旧も遅れるため、エスカレーションとセットで語られる。
エスカレーション(Escalation)
自分で対応できないと判断したときに、上位担当者や別のチームに引き上げること。
「誰に・どのタイミングで・どの手段で伝えるか」をルール化している現場が多い。
ここが曖昧だと、重大障害で対応が遅れる最大の要因になる。
バックアップ(Backup)
データを消えたり壊れたりしないようにコピーを保存しておくこと。
「バックアップを取ってあるから安心」というのは誤解で、実際に戻せるかどうかが重要。
運用では「いつ・どこに保存しているか」を押さえておくだけでも会話がしやすい。
スナップショット(Snapshot)
ある時点の状態をそのまま保存する仕組み。
仮想マシンやデータベースでよく使われ、変更前に「今の状態」を残すのに便利。
ただし同じ環境に置かれることが多く、バックアップの代わりにはならない。
死活監視(Health Check)
システムが生きているかどうかを定期的に確認する仕組み。
PingやHTTP応答などが代表例。
ただし応答があっても正常動作とは限らないため、重要サービスでは機能確認も行う。
キャパシティ計画(Capacity Planning)
システムの利用が将来どれくらい増えるかを予測し、余裕を持って準備すること。
「年末商戦でアクセスが倍増しても落ちないように増強する」などが典型。
不足すれば障害につながり、積みすぎればコストが無駄になるのでバランスが重要。
スループット(Throughput)
システムが一定時間に処理できる量。
「1秒あたり100件処理できる」といった性能の指標。
遅延(レイテンシ)とセットで使われることが多く、ボトルネック調査で必須。
サーバーログ(Log)
システムの動作やエラーを記録したファイル。
アプリケーションログ、OSログ、DBログなどがあり、障害調査の第一手段になる。
「とりあえずログを見よう」という言葉が現場で頻繁に出る。
ジョブ(Job/Batch)
決まった時間や条件で自動的に実行される処理。
夜間に動くデータ集計や帳票出力のバッチが代表例。
遅延や失敗が業務全体に直結するため、運用現場では非常に重要。
パッチ(Patch)
ソフトやOSにあとから適用する修正プログラム。
セキュリティ対応や不具合修正のために提供される。
適用の有無でリスクが大きく変わるため、毎月の定例作業で必ず話題になる。
まとめ
運用保守の現場で飛び交う言葉は多くありますが、まずはこの20語を押さえておけば会話の迷子にならずに済みます。
完全に使いこなせなくても、意味がわかるだけで会議や障害対応でのストレスは大きく減ります。
今後はさらに「監視」「クラウド」「セキュリティ」などの領域別に用語を追加していく予定です。
コメント