server-management について
server-managementは、本番環境のサーバーを管理する運用担当者向けのスキルです。コマンド集ではなく、プロセス管理、監視、ログ、スケーリング、ヘルスチェック、セキュリティ、トラブルシューティングの判断原則をまとめています。
主な機能
- 01プロセス管理ツールの選定
- 02監視指標とアラートレベル
- 03ログローテーションと構造化ログ
- 04スケーリングとヘルスチェックの指針
- 05セキュリティと障害対応の原則
活用シーン
- 01アプリケーションのプロセスマネージャー選定
- 02監視とログ運用の計画
- 03サーバーの可用性や性能問題の調査
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/server-managementを入力して読み込まれたか確認します。
詳細
サーバー管理
本番環境の運用におけるサーバー管理の原則です。 コマンドを暗記するのではなく、考え方を身につけましょう。
1. プロセス管理の原則
ツールの選択
| シナリオ | ツール |
|---|---|
| Node.js アプリ | PM2（クラスタリング、リロード） |
| 任意のアプリ | systemd（Linux ネイティブ） |
| コンテナー | Docker/Podman |
| オーケストレーション | Kubernetes、Docker Swarm |
プロセス管理の目標
| 目標 | 意味 |
|---|---|
| クラッシュ時の再起動 | 自動復旧 |
| ダウンタイムなしのリロード | サービスを中断しません |
| クラスタリング | すべての CPU コアを使用 |
| 永続性 | サーバーの再起動後も稼働 |
2. 監視の原則
監視対象
| カテゴリー | 主なメトリクス |
|---|---|
| 可用性 | 稼働時間、ヘルスチェック |
| パフォーマンス | 応答時間、スループット |
| エラー | エラー率、種類 |
| リソース | CPU、メモリ、ディスク |
アラートの重要度別対応方針
| レベル | 対応 |
|---|---|
| クリティカル | 直ちに対応 |
| 警告 | 早めに調査 |
| 情報 | 毎日確認 |
監視ツールの選択
| ニーズ | 選択肢 |
|---|---|
| シンプル／無料 | PM2 メトリクス、htop |
| 包括的な可観測性 | Grafana、Datadog |
| エラートラッキング | Sentry |
| 稼働時間 | UptimeRobot、Pingdom |
3. ログ管理の原則
ログの方針
| ログの種類 | 目的 |
|---|---|
| アプリケーションログ | デバッグ、監査 |
| アクセスログ | トラフィック分析 |
| エラーログ | 問題の検出 |
ログの原則
- ログをローテーションすることで、ディスク容量の枯渇を防ぎます
- 構造化ログ（JSON）を使用して解析しやすくします
- 適切なログレベル（error/warn/info/debug）を使用します
- ログに機密データを含めません
4. スケーリングの判断
スケーリングするタイミング
| 症状 | 解決策 |
|---|---|
| CPU 使用率が高い | インスタンスを追加する（水平スケーリング） |
| メモリ使用量が多い | RAM を増やすか、メモリリークを修正する |
| 応答が遅い | まずプロファイリングし、その後スケーリングする |
| トラフィックが急増する | オートスケーリング |
スケーリング戦略
| 種類 | 使用するタイミング |
|---|---|
| 垂直スケーリング | 迅速な対処、単一インスタンス |
| 水平スケーリング | 持続可能、分散型 |
| 自動スケーリング | トラフィックが変動する場合 |
5. ヘルスチェックの原則
健全性の判断基準
| チェック | 意味 |
|---|---|
| HTTP 200 | サービスが応答している |
| データベース接続済み | データにアクセスできる |
| 依存関係が正常 | 外部サービスに到達できる |
| リソースが正常 | CPU／メモリが枯渇していない |
ヘルスチェックの実装
- ライブネス：プロセスが処理を進められることを確認します。共有依存関係が停止しているという理由だけで、失敗と判定しないでください。
- レディネス：トラフィックの処理に必要な依存関係を、タイムアウトを設けてチェックします。
- 静的な 200 応答だけでは、アプリケーションが健全であることは証明できません。診断の詳細は非公開にしてください。
6. セキュリティの原則
| 領域 | 原則 |
|---|---|
| アクセス | SSH キーのみを使用し、パスワードは使用しません |
| ファイアウォール | 必要なポートのみを開放します |
| 更新 | セキュリティパッチを定期的に適用します |
| シークレット | 承認済みのシークレットストア、または保護された実行時注入を使用します。認証情報をソースコードやログに含めないでください |
| 監査 | アクセスと変更をログに記録します |
7. トラブルシューティングの優先順位
問題が発生した場合：
- 実行中か確認する（プロセスの状態）
- ログを確認する（エラーメッセージ）
- リソースを確認する（ディスク、メモリ、CPU）
- ネットワークを確認する（ポート、DNS）
- 依存関係を確認する（データベース、API）
8. アンチパターン
| ❌ やってはいけないこと | ✅ 推奨すること |
|---|---|
| root で実行する | root 以外のユーザーを使用する |
| ログを無視する | ログローテーションを設定する |
| 監視を省略する | 初日から監視する |
| 手動で再起動する | 自動再起動を設定する |
| バックアップを取らない | 定期的なバックアップスケジュールを設定する |
覚えておきましょう： 適切に管理されたサーバーは、退屈なものです。それが目標です。
使用するタイミング
このスキルは、概要で説明されているワークフローやアクションを実行する際に役立ちます。
例
ユーザーリクエスト：
このタスクに @server-management を使用してください：サーバー管理の原則と意思決定。
制限事項
- このスキルは、タスクが上記のスコープに明確に一致する場合にのみ使用してください。
- 出力を、環境固有の検証、テスト、専門家によるレビューの代替として扱わないでください。
- 必要な入力、権限、安全境界、成功基準が欠けている場合は、作業を中断して確認を求めてください。
コメント
Markdown 対応