会社情報
採用情報
お問い合わせ
Article

社内システムの定期メンテナンスチェックリスト

高田晃太郎
社内システムの定期メンテナンスチェックリスト

統計や事例が示すのは不都合な真実です。変更管理が甘いとき、重大障害の多くは人為的な設定変更や更新作業が引き金になります¹。各種調査でも、予定外停止の大きな割合が変更やセキュリティに起因し、証明書の失効やバックアップの未検証が上位要因として繰り返し挙がっています²⁴⁵。

平均的な障害コストは分単位で数千ドル規模とされ³、検知の遅れと復旧時間の積み上げが損失を拡大させます⁴。国内でも2019年のシステム障害件数が過去最多だったと報告され、運用起因の問題の重さが示されました⁷。

だからこそ、定例点検を単なる儀式にせず、SLO（サービス目標値）につながる運用品質の改善サイクルとして設計します⁶。実務で回せるチェックリストに落とし込めば、結果的に低いコストで可用性とセキュリティを引き上げられます。ここでは、月次と四半期の頻度設計、インフラからアプリ・データベース・証明書・バックアップまでの観点、そして自動化と可観測性による持続運用の作り方を、実行可能なコマンド例とともに整理します。

定期メンテをSLOに結びつける頻度設計

チェックリストは、SLOとエラー予算（許容できる失敗の余白）の消費傾向を前提に設計して初めて価値を生みます。月次と四半期の2つのリズムに織り込み、改善をSLA（対外的な合意）の予防線として機能させます⁶。月次はヘルスシグナルの健全性確認と軽微な予防保守に集中し、四半期はリスクの高い変更や構成更改、積み残した脆弱性修正を計画的に吸収します。

重要なのは、インシデントからの学習を必ず次のメンテ枠へ反映することです。事後検証で露見した監視の盲点や手順の曖昧さは、チェック項目として明文化し、次回の予防行動に転化します。

月次サイクルでは、可用性の直接指標と間接指標を分けて観察します。直接指標はリクエスト成功率、レイテンシのパーセンタイル、エラー率の移動平均。間接指標はディスクとinodeの余裕、証明書の有効期限、バックアップの成否と復元性、コンフィグのドリフト、ログの回転、時刻同期の状態などです。単発ではなく、過去3〜6か月のトレンドで見て、劣化が滲む箇所に時間を配分します。

四半期サイクルでは、OSやランタイムのマイナーバージョン更新、長期稼働プロセスの再起動計画、スキーマ変更やインデックス最適化といった重い作業を、閑散時間帯にまとめて実施します。変更凍結期間とロールバック計画を明確にし、エラー予算の消費が速い四半期は攻めの変更を控えます。逆に余裕がある四半期は技術的負債の返済に振り向け、運用と開発のキャパシティをSLOと連動させます⁶。

SLOの監視と月次レビューをつなぐため、可観測性基盤での簡潔なクエリを持っておくと会話がスムーズです。

sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
/
sum(rate(http_requests_total[5m])) by (service)

このようなエラー率の推移を月次で俯瞰し、しきい値に近づくサービスからメンテ対象の優先度を引き直すと、現場の納得感が高まります。

頻度と所要時間の目安を現実的に決める

理想のチェックリストは、現場で回り続けることが第一条件です。月次は90〜120分の短い確定窓を設定し、対象範囲を明確化します。四半期は2〜4時間の拡張窓を準備し、検証済みの自動化手順で成功確率を高めます。所要時間は人手作業の比率に依存します。まず観測と診断を自動化し、次に復旧系の反復手順をプレイブック化し、最後に変更系の自動化へ段階的に踏み込みます。

優先順位はリスク×影響×回避可能性で決める

全項目を毎回完璧に実施する必要はありません。発生確率と影響度に加え、回避可能性を掛け合わせたスコアで優先順位を付けます。例えば証明書の失効は影響が大きく、回避も容易なので常に上位です²⁵。逆に低頻度のハード故障は監視と予兆検知に留め、四半期の棚卸し対象にします。現実的な割り切りが、運用品質の継続的な底上げにつながります。

インフラ・OS・ネットワークの月次点検

サーバやネットワークの点検は、誤検知や情報過多に陥りがちです。目的は2つ。影響の大きい故障徴候の早期発見と、安全余裕の確認です。Linux系であれば、失敗中のユニット、カーネルレベルの異常、ディスク容量とinode、I/O遅延、時刻同期状態を定型的に確認します。以下のコマンドは日常の健診に相当し、出力の差分を残してトレンドを追うと効果が上がります。

# 失敗中のサービスと直近エラーの把握
systemctl --failed
journalctl -p err -n 200 --no-pager

dmesg -T | egrep -i "error|fail|segfault|oom"

容量とI/Oの余裕はパフォーマンスの基礎体力です。余裕が小さくなると、突発的なピークで飽和しやすくなります。

# 容量・inode・I/O
df -h
(df -i || true)
iostat -x 1 3

時刻同期は監査や証明書検証に直結します。ドリフトが大きいホストは優先的に整えます。

# NTP/Chrony の状態
chronyc tracking

ログの回転が滞ると、ディスク枯渇や監査証跡の欠落につながります。設定変更前に乾式実行で安全性を確かめます。

# logrotate の検証
logrotate -d /etc/logrotate.conf

ネットワークは末端の輻輳や誤設定が起きやすい領域です。リッスンポートの棚卸しと到達性の診断を定期観点に含めます。

# リッスンポートと疎通
ss -tulpn | sort -k5
mtr -rwzc 50 <destination>

構成ドリフトの検知は、IaC（Infrastructure as Code）の健全性に直結します。毎月の計画実行で意図しない差分を可視化し、レビューの場に載せます。

# Terraform の計画差分
terraform init -upgrade
terraform plan -detailed-exitcode

Kubernetesを運用している場合、ノードとPodの健全性、CrashLoopBackOffの有無、イベントの異常頻度を短時間で洗い出せる定型を持っておきます。

# K8s の基本健診
kubectl get nodes -o wide
kubectl get pods -A --field-selector=status.phase!=Running
kubectl get events -A --sort-by=.lastTimestamp | tail -n 100

アプリ・DB・セキュリティと証明書・バックアップ

アプリ層では、エラー率やタイムアウトの上昇だけでなく、依存関係の脆弱性や設定の逸脱が品質を侵食します。依存ライブラリの更新は四半期を基本にしつつ、緊急のCVE（公開された脆弱性番号）は月次窓の前倒し適用で吸収します。コンテナを用いる場合は、イメージとランタイムの脆弱性スキャンを定常化し、重大度と可到達性（悪用され得るか）で優先度を付けます。

# コンテナイメージの脆弱性スキャン例
trivy image --ignore-unfixed --severity CRITICAL,HIGH <registry>/<image>:<tag>

データベースは可用性の要です。点検の質がサービスの体幹を決めます。PostgreSQLであれば、バキューム遅延やBloat、レプリケーション遅延を確認し、必要に応じてメンテ窓での再編成とインデックス最適化を検討します。

-- レプリケーション遅延（秒）
SELECT EXTRACT(EPOCH FROM now() - pg_last_xact_replay_timestamp()) AS replication_lag_s;

-- 自動バキューム遅延の兆候
SELECT relname, n_dead_tup FROM pg_stat_user_tables ORDER BY n_dead_tup DESC LIMIT 10;

バックアップは取得よりも復元性の実証が重要です。月次では小規模テーブルの部分復元、四半期ではフル復元の演習をサンドボックスで実施します。所要時間を記録し、復旧時間（RTO）の目安を更新します⁴。

# 代表テーブルの部分復元検証（PostgreSQL）
pg_restore -t public.orders -d restore_sandbox /backups/base.dump

TLS証明書の失効は、規模を問わず重大障害の常連です。有効期限の監視に加え、チェーンの健全性やホスト名検証、プロトコル設定の老朽化も機械的に確認します²⁵。

# サーバ証明書の有効期限とチェーン確認
printf "QUIT\n" | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null |
openssl x509 -noout -dates -issuer -subject

アプリ設定のドリフトや機密情報の取り扱いは、権限管理と監査証跡が鍵です。設定リポジトリの保護、シークレットのローテーション、監査ログの改ざん検知をメンテ枠に合わせて定期レビューします。依存サービスのSLAやレート制限、APIスキーマの変更予定も四半期ごとに棚卸しし、互換性の破壊が見込まれる場合は早めに代替案を用意します。

自動化と運用プロセスで“回る”チェックへ

継続運用の肝は、自動化と可観測性の接着です。人間の判断時間は価値が高く、反復作業は機械に任せます。まず観測系の収集と成形をコード化し、次に安全で可逆な作業から順に自動化します。AnsibleやPowerShell、GitHub Actionsといった標準的なツールで構築すれば、ドキュメントと同居させて属人性を削れます。

# Ansible: サービス健診とログ回転の検証例
- hosts: app_servers
  become: yes
  tasks:
    - name: Check failed units
      command: systemctl --failed
      register: failed_units
      changed_when: false
    - name: Dry-run logrotate
      command: logrotate -d /etc/logrotate.conf
      changed_when: false

メンテナンスの実行とレポーティングは、CIの定期ジョブに組み込むと形骸化を防げます。失敗時はSlackへ通知し、レポートはダッシュボードに集約します。

# GitHub Actions: 月次健診の定期実行例
name: monthly-maintenance
on:
  schedule:
    - cron: '0 2 1 * *'
jobs:
  healthcheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run health script
        run: ./scripts/healthcheck.sh

ヘルスチェック自体は短いスクリプトで十分です。終了コードで合否を表現し、機械が扱いやすいJSONで要約すると、アラートや可視化に直結します。

#!/usr/bin/env bash
set -euo pipefail
errs=()
if systemctl --failed | grep -q failed; then errs+=("systemd_failed") ; fi
if df -h | awk 'NR>1 {if ($5+0 > 80) exit 1}'; then :; else errs+=("disk_full") ; fi
if [ ${#errs[@]} -gt 0 ]; then
  jq -n --arg status FAIL --argjson issues "$(printf '%s\n' "${errs[@]}" | jq -R . | jq -s .)" '{status:$status, issues:$issues}'
  exit 1
else
  jq -n '{status:"OK", issues:[]}'
fi

変更は必ずロールバック可能に設計します。設定変更は二段階デプロイやカナリアで小さく流し、失敗時は即座に元へ戻せるよう、前状態の取得と復元を手順化します。データベース変更は後方互換を基本にし、カラム追加とアプリ適用、既存列の移行、不要列の削除と段階を分けます。各段階が独立にロールバックできることを確認します。スキーマ変更前には最新バックアップの復元演習を実施し、復元時間がSLO内に収まるか毎回確かめると、意思決定の安全度が高まります⁴。

最後に、チェックリストは運用チームだけの資産ではありません。SRE、アプリ開発、セキュリティ、ビジネスオーナーが同じ一枚絵を見られるよう、ダッシュボード化して透明性を上げます。エラー予算の消費、重要メトリクスのトレンド、保留中のリスクと対策計画を同じ場に載せれば、優先順位のすり合わせが容易になります。メンテ枠への全社的な理解と合意も得やすくなります⁶。

まとめ：明日から回せる最小構成で始める

定例点検をSLOに裏付けられた予防保全のルーチンとして設計すれば、短い時間投資で障害の芽を摘み取り、MTTRの短縮と費用の平準化を同時に狙えます。初手から完璧を目指す必要はありません。まずは月に一度の90分枠を確保し、サービスのエラー率とレイテンシのレビュー、サーバの基本健診、証明書とバックアップの確認という核だけを確実に回します。次に、観測と診断をコード化し、レポートを自動で可視化します。四半期の拡張枠では、技術的負債の返済やマイナーアップグレード、依存ライブラリの更新を計画的に進めます。

この小さなループを半年続けるだけで、障害の再発率と緊急対応の総工数は着実に下がっていきます。あなたのチームにとって最も痛かったインシデントは何だったのか。そして、それはどの観点のチェックで無力化できたのか。次のメンテ枠のアジェンダに、その一行を静かに追加するところから、持続可能な運用が動き始めます。チェックリストは儀式ではなく、学習を蓄積する仕組みです。今日の小さな改善が、明日の大規模障害を未然に防ぎます。

参考文献

  1. 451 Alliance Blog. Security issues remain top cause of outages. （参照日: 2024-08-30）
  2. Keyfactor Blog. Getting ahead of certificate-related outages with automation and visibility. （参照日: 2024-08-30）
  3. Facility Executive. Study Shows Significant Increase in Cost of Unplanned Data Center Outages. （参照日: 2024-08-30）
  4. 451 Research. Costly Outages Rise; Disaster Recovery Still Top Issue (2020). （参照日: 2024-08-30）
  5. CSC Press Release. Research finds enterprises at risk from SSL certificate expiration. （参照日: 2024-08-30）
  6. Google Cloud Blog. SRE: Error budgets and maintenance windows. （参照日: 2024-08-30）
  7. 日経クロステック（xTECH）. 2019年の国内システム障害が過去最多に（IPA調査）。 （参照日: 2024-08-30）