運用・保守
// OPS & MAINTENANCE — 日次/週次/月次点検 + 変更ルール / 最終更新: 2026-05-14
運用中 日次/週次/月次の点検チェックリスト。 監視が拾ってくれない部分を人手で見る
監視で 99% カバー: R640 perc-watch / wp-katuocloud-db-backup / cert-watch + maguro supermicro-watch / mdadm-watch / raid-watch / cert-watch は Telegram に飛ぶ。 ここに書く点検は「機械では拾えない、 でも見ておきたい」項目。
1. 日次確認項目
// R640 (katuo) — DMZ Web フロント
ssh katuo@192.168.20.21 sudo systemctl --failed sudo wg show # 出ない (R640 は WG 退役済) のが正常 ip route sudo docker ps # WP は systemd nginx + php-fpm + mariadb (Docker 不使用) df -h ls -lt /mnt/data/backup/wp/katuocloud_wp/ | head -3 # 当日 02:30 の dump があるか curl -sI https://katuocloud.com/ | head -3 curl -ksI https://127.0.0.1:8443/ | head -3 # inner WP
// maguro (Supermicro) — ストレージ + NC + Portal + WG
ssh maguro@192.168.70.30 sudo systemctl --failed sudo docker ps # nextcloud-stack + mikyun-portal + db sudo wg show wg-clients latest-handshakes df -h /srv/storage cat /proc/mdstat | head -5 lsblk -f | head -30 curl -sI https://cloud.k2-o.net/status.php | head -3
// hirame — Collabora
ssh hirame@192.168.10.40 sudo systemctl --failed sudo docker ps | grep collabora curl -s http://173.0.0.10:9980/hosting/discovery | grep urlsrc | head -1
2. 週次点検
- WG peer 状態確認: maguro で
sudo wg show、 顧客 peer の latest-handshake が極端に古くないか - 契約 / 端末数の棚卸し: mikyun-portal の admin UI で contracts / devices 数の妥当性確認
- admin_logs の異常操作確認: 不審な操作履歴が無いか
- ストレージ残量確認:
/srv/storageの使用率推移 (週単位で見て急増していないか) - Switch uplink / LACP エラー確認: 12XS / T48 で
show interfaces counters errors - UPS 状態確認: 物理 LED + ログ (1ヶ月以内に停電あった場合はバッテリ寿命確認)
- Collabora 動作確認: 適当な .docx を NC で開けるか実際に試す
3. 月次点検
- OS アップデート: 「運用 switch コマンド (id:313)」の手順で全ホスト apt update
- Nextcloud / Portal / WP DB バックアップ復元テスト: 月1で実際にリストア試行 (本番に影響しない検証環境で)
- 証明書期限確認:
sudo certbot certificatesで残日数を全件目視 (cert-watch が拾うが念のため) - ストレージ増設余力確認: SAS ベイ空き数、 NVMe slot 空き、 LUKS 暗号領域の予約
- RTX1300 設定の git 退避:
show config出力を保管 - iDRAC 状態確認: R640 iDRAC の WebUI を一度開いて生存確認 (Console Redirection は無効化予定)
4. 変更作業ルール
本番系を触るときの鉄則: 5つの作業ルールを守る。 「過去に痛い目に遭った経験」から導かれたルールなので、 例外なし。
- 変更前に必ずバックアップ: 設定ファイルは
cp -p file file.bak.YYYYMMDD-HHMM、 DB は dump、 nginx はcp -r /etc/nginx /etc/nginx.bak.* - ネットワーク変更は CORE → ACCESS → Host の順: 上位から確認しながら降りる (逆順だと迷子になる)
- DB 変更は DDL 前に dump:
mysqldump --single-transactionで取ってから ALTER - WG 設定変更は peer 一覧退避後:
wg showconf wg-clients > /tmp/wg-clients-$(date +%F).conf - 変更ログを残す: 何を / なぜ / どう戻すか を SSH log もしくはこのドキュメントに追記
5. 監視一覧 (機械が拾う部分)
| ホスト | unit / cron | 周期 | 監視内容 |
|---|---|---|---|
| maguro | supermicro-watch.timer | 5min | md0 / storage 90%+ / NFS / ATAエラー / LUKS×5 |
| maguro | mdadm-watch.timer | 5min | /proc/mdstat md0 状態変化 |
| maguro | raid-watch.timer | 5min | IPMI SEL (Drive Fault / Rebuild) |
| maguro | cert-watch (cron) | 06:30 | LE 全証明書 <14日警告 / 失効通知 |
| R640 | perc-watch.timer | 5min | SAS×8 + NVMe×2 (megaraid smartctl) + megaraid kernel事件 |
| R640 | cert-watch (cron) | 06:30 | LE 全証明書 |
| R640 | wp-katuocloud-db-backup (cron) | 02:30 | dump 失敗 + サイズ異常 |
全アラートは Telegram 通知。 詳細は「cron ジョブ・自動化タスク (id:818)」「Telegram 通知システム (id:956)」参照。
6. バックアップ方針 (3-2-1 を意識)
- WP DB: R640 daily 02:30 →
/mnt/data/backup/wp/katuocloud_wp/*.sql.gz(14日保持) - NC DB + データ: maguro daily → 同ホスト内 + (検討) オフサイト Backblaze B2 / wasabi
- mikyun-portal DB: Docker MariaDB に統合済、 NC バックアップに同梱
- 設定ファイル: 月次で git に push (RTX1300 + nginx + netplan + systemd unit)
- 物理: R640 HW RAID10 (PERC) + maguro SW RAID + LUKS + bcache (storage-cache)
3-2-1 の現状: オンサイト 2コピーは満たしてるが、 オフサイトはまだ未実装。 これが残作業の最大ポイント。
7. 障害時の判断フロー
Telegram alert 受信
↓
内容を 60秒で読む
↓
┌─────────┴─────────┐
│ どこか? どの種別?│
└─────────┬─────────┘
↓
┌──────────┼──────────┐
↓ ↓ ↓
Hardware ストレージ ネット
(PERC, (LUKS, md, (nginx,
IPMI) NFS) wg, cert)
↓ ↓ ↓
smartctl cryptsetup systemctl
ipmi-sel mdadm journalctl
↓
原因特定 / 一次対応
↓
恒久対応 + 記録
↓
「障害・トラブル (id:19)」に追記
8. 想定外シナリオへの備え
// R640 が落ちた場合
- katuocloud.com (WP) は閲覧不可
- cloud.k2-o.net (NC) は SNI 経由が落ちるが、 内部LAN + WG クライアントは fabric / 内部VLAN経由で生存
- Collabora は fabric 直結化のため R640 経由を不要、 NC⇄Collabora は継続稼働
// maguro が落ちた場合
- cloud.k2-o.net (NC) 全停止
- WG 全顧客接続不可
- katuocloud.com (R640 内 WP) は継続稼働
// 固定IP が変わった場合
- 業務用フレッツなので原則変わらない
- 万一の時は Cloudflare DNS A レコード更新でカバー
- RTX NAT は内部IP指定なので影響なし
関連ページ: 「障害・トラブル (id:19)」 / 「運用 switch コマンド (id:313)」 / 「cron ジョブ・自動化タスク (id:818)」 / 「最近の作業履歴 (id:850)」