IT Operations エキスパート

IT インフラストラクチャ運用の管理、サービス信頼性の確保、監視およびアラート戦略の実装、インシデント管理、自動化とベストプラクティスを通じた運用上の優秀性の維持を実現する包括的なスキルです。

コア原則

1. サービス信頼性を最優先

• プロアクティブなモニタリング: インシデント発生前に包括的な可観測性を実装
• インシデント管理: 明確なエスカレーションパスを備えた構造化された対応プロセス
• SLA/SLO管理: ビジネスニーズに合わせたサービスレベル目標の定義と維持
• 継続的改善: 責任追及なしのポストモーテムを通じたインシデント分析

2. 手動プロセスより自動化を優先

• Infrastructure as Code: バージョン管理されたコードを通じたインフラ構成の管理
• ランブック自動化: 手動手順の自動化ワークフローへの変換
• 自己修復システム: 一般的な問題への自動修復の実装
• 構成管理: 環境全体の一貫性維持

3. ITIL サービス管理

• サービス戦略: IT サービスとビジネス目標のアライメント
• サービス設計: 耐性とスケーラビリティを備えたサービス設計
• サービス移行: 最小限の中断で変更を管理
• サービス運用: サービスの効果的な提供と支援
• 継続的サービス改善: サービス品質の段階的な強化

4. 運用上の優秀性

• ドキュメンテーション: 現在のランブック、手順、アーキテクチャ図の維持
• 知識管理: インシデント解決から検索可能なナレッジベースの構築
• キャパシティ計画: リソースのプロアクティブな予測とプロビジョニング
• コスト最適化: パフォーマンス要件とインフラ費用のバランス

コアワークフロー

インフラストラクチャ運用ワークフロー

1. モニタリングと可観測性
   ├─ 重要サービスの SLI/SLO/SLA を定義
   ├─ メトリクス収集を実装 (インフラ、アプリケーション、ビジネス)
   ├─ 適切なしきい値とエスカレーションでアラートを構成
   ├─ オーディエンス別にダッシュボードを構築 (運用、開発、経営)
   └─ オンコール体制とエスカレーション手順を確立

2. インシデント管理
   ├─ アラートまたはユーザーレポートを受信
   ├─ 重大度と影響を評価 (P1/P2/P3/P4)
   ├─ 適切な対応者を招集
   ├─ 根本原因の調査と診断
   ├─ 修正またはワークアラウンドを実装
   ├─ ステータスを関係者に報告
   ├─ ナレッジベースに解決策を記録
   └─ インシデント後のレビューを実施

3. 変更管理
   ├─ 影響評価付き変更要求を提出
   ├─ CAB (変更諮問委員会) による審査と承認
   ├─ 変更ウィンドウをスケジュール
   ├─ ロールバック計画を用意して変更を実行
   ├─ 成功基準を検証
   ├─ 実際と計画の結果を記録
   └─ 変更チケットを完了

4. キャパシティ計画
   ├─ リソース利用率のトレンドを収集
   ├─ 成長パターンを分析
   ├─ 将来の要件を予測
   ├─ 調達またはプロビジョニングを計画
   ├─ キャパシティ増強を実行
   └─ 効果を監視

5. 自動化と最適化
   ├─ 反復的な手動タスクを特定
   ├─ 現在のプロセスを文書化
   ├─ 自動化ソリューションを設計
   ├─ 自動化を実装と テスト
   ├─ 本番環境にデプロイ
   ├─ 時間とコストの削減を測定
   └─ 反復して改善

意思決定フレームワーク

アラート構成の決定マトリックス

シナリオ	アラート種別	しきい値	応答時間	エスカレーション
サービス完全停止	ページ	即座	5分以内	即座にオンコール
サービス劣化	ページ	2-3障害	15分以内	15分後にオンコール
リソース使用率高	警告	80%以上 継続	1時間以内	2時間後にチームリード
キャパシティ接近	情報	70%以上 トレンド	24時間以内	週次キャパシティレビュー
構成のドリフト	チケット	すべてのずれ	7日以内	月次レビュー

インシデント重大度分類

優先度 1 (Critical/重大)

• 全ユーザーに影響するサービス完全停止
• データ損失またはセキュリティ侵害
• 財務影響 > $10K/時間
• 対応: 即座、24/7、全力で対応

優先度 2 (High/高)

• 多数ユーザーに影響するサービス部分停止
• 顕著なパフォーマンス劣化
• 財務影響 $1K-$10K/時間
• 対応: 営業時間内 30分以内

優先度 3 (Medium/中)

• 一部ユーザーに影響するサービス劣化
• 重要でない機能の障害
• ワークアラウンド利用可能
• 対応: 営業時間内 4時間以内

優先度 4 (Low/低)

• 最小限の影響を伴う軽微な問題
• 見栄えの問題
• 拡張要求
• 対応: 翌営業日

変更管理リスク評価

リスク レベル = 影響度 × 発生可能性 × 複雑度

影響度 (1-5):
1 = 単一ユーザー
2 = チーム
3 = 部門
4 = 全社
5 = 顧客向け

問題発生可能性 (1-5):
1 = ルーチン、テスト済み
2 = 慣れている、文書化済み
3 = 若干の不確実性
4 = 新しい分野
5 = 未実施

複雑度 (1-5):
1 = 単一コンポーネント
2 = 数個のコンポーネント
3 = 複数システム
4 = クロスプラットフォーム
5 = エンタープライズ全体

リスクスコア解釈:
1-20: 標準変更 (事前承認)
21-50: 通常変更 (CAB レビュー)
51-75: 高リスク変更 (広範テスト、上級承認)
76-125: 緊急変更のみ (経営幹部承認)

監視ツール選定

要件	Prometheus + Grafana	Datadog	New Relic	ELK Stack	Splunk
コスト	無料 (自己ホスト)	$$$$	$$$$	無料-$$	$$$$$
メトリクス	優秀	優秀	優秀	良好	良好
ログ	Loki経由	優秀	優秀	優秀	優秀
トレース	Tempo経由	優秀	優秀	限定的	良好
学習曲線	急	中程度	中程度	急	急
クラウドネイティブ	優秀	優秀	優秀	良好	良好
オンプレミス	優秀	良好	良好	優秀	優秀
APM	エクスポーター経由	優秀	優秀	限定的	良好

一般的な運用上の課題

課題 1: アラート疲れ

問題: 誤検知が多すぎてチームの疲弊を招いている

解決策:

アラートチューニングプロセス:
1. ベースラインのアラート数と誤検知率を測定
2. アラートを実行可能性で分類:
   - 実行可能で緊急 = ページとして保持
   - 実行可能で非緊急 = チケット
   - 実行不可 = 削除またはダッシュボードメトリクスに変換
3. アラート集約を実装 (類似アラートをグループ化)
4. アラートに文脈を追加 (ランブックリンク、関連メトリクス)
5. 定期的なレビュー会議 (週次) でしきい値をチューニング
6. メトリクスを追跡:
   - MTTA (平均応答時間): 5分以下が目標
   - 誤検知率: 20%未満が目標
   - 週あたりのアラート数: 減少トレンド

課題 2: 危機中のインシデント記録

問題: チームが高圧力インシデント中に記録をスキップしている

解決策:

• 専任スクライブロールを割り当て (インシデント指揮官ではない)
• インシデント管理ツール (PagerDuty, Opsgenie) を自動タイムライン機能付きで使用
• テンプレートベースのインシデントレポートに必須フィールドを設定
• インシデント後のレビューを自動スケジュール (48時間以内)
• ドキュメンテーションをゲーム化 (徹底的なドキュメンテーション を追跡・表彰)

課題 3: 知識のサイロ化

問題: 重大な知識が個々のチームメンバーの頭の中に閉じ込められている

解決策:

知識移転戦略:
- ペアプログラミング/シャドーイング: スプリント容量の20%
- ランブック要件: すべてのシステムにランブックが必須
- ランチ&ラーニングセッション: 週次30分の知識共有
- クロストレーニングマトリックス: 誰が何を知っているかを追跡、ギャップを特定
- オンコール体制: 知識を広めるために誰もが交代制
- インシデント後のレビュー: 強制的なチーム共有
- ドキュメンテーションスプリント: 四半期ごとにドキュメンテーション完成に集中

課題 4: 安定性とイノベーションのバランス

問題: 運用チームが安定性維持のために変更に抵抗している

解決策:

• 変更ウィンドウ (計画メンテナンス期間) を実装
• ブルーグリーンまたはカナリアデプロイメントでリスク低減
• 「イノベーション時間」を確立 (Google 20%時間モデル)
• 実験用のサンドボックス環境を作成
• 安定性と改善の両方のメトリクスを測定・報酬
• 「手作業削減」を OKR ターゲットとして含める

主要メトリクスと KPI

サービス信頼性メトリクス

稼働率:
  計算式: (総時間 - ダウンタイム) / 総時間 × 100
  目標: 99.9% (月間43.8分のダウンタイム)
  測定: サービス別、月次

MTTR (平均復旧時間):
  計算式: 復旧時間の合計 / インシデント数
  目標: P1は30分以内、P2は4時間以内
  測定: 重大度別、月次

MTBF (平均故障間隔):
  計算式: 総運用時間 / 故障数
  目標: > 720時間 (30日)
  測定: サービス別、四半期

MTTA (平均応答時間):
  計算式: 応答時間の合計 / アラート数
  目標: ページは5分以内
  測定: オンコール担当者別、週次

変更成功率:
  計算式: 成功した変更 / 総変更数 × 100
  目標: > 95%
  測定: 月次

インシデント再発率:
  計算式: 繰り返しインシデント / 総インシデント数 × 100
  目標: < 10%
  測定: 四半期 (90日以内の同じ根本原因)

運用効率メトリクス

手作業比率:
  定義: 手動で反復的なタスクに費やす時間
  目標: チーム容量の30%未満
  測定: 週次時間追跡

自動化カバレッジ:
  計算式: 自動化されたタスク / 反復的タスク総数 × 100
  目標: > 70%
  測定: 四半期監査

オンコール負荷:
  計算式: オンコール当番あたりのアラート数
  目標: 当番あたり5件以下の実行可能なアラート
  測定: エンジニア別、週次

ランブックカバレッジ:
  計算式: ランブック付きサービス / 総サービス数 × 100
  目標: 100%
  測定: 月次監査

ナレッジベース利用率:
  計算式: KB経由で解決したインシデント / 総インシデント数 × 100
  目標: > 40%
  測定: 月次

統合ポイント

開発チームとの連携

• 運用要件のための設計レビューに参加
• デプロイメント自動化と CI/CD パイプラインサポートを提供
• 監視とロギング要件を共有
• インシデント対応とポストモーテムで協力
• SLO とエラー予算の共同所有

セキュリティチームとの連携

• セキュリティ監視とアラートを実装
• アクセス制御と認証システムを管理
• 脆弱性パッチと修復を調整
• セキュリティインシデント対応を実施
• セキュリティポリシーの遵守を維持

ビジネスステークホルダーとの連携

• サービス稼働率とパフォーマンスについて報告
• 計画メンテナンスウィンドウを通知
• キャパシティ計画の予測を提供
• 技術メトリクスをビジネス影響に変換
• ビジネス継続性計画に参加

ベストプラクティス

1. 責任追及なしのポストモーテム

インシデント後レビューテンプレート:
- インシデント概要 (発生内容、発生時刻、影響)
- イベント時系列 (詳細な年表)
- 根本原因分析 (5段階なぜなぜ分析またはフィッシュボーン図)
- 対応中にうまくいったこと (対応力)
- 改善の余地がある点 (機会)
- アクション項目 (責任者と期日付き)
- 得られた教訓 (共有可能な洞察)

ルール:
- 非難や処罰なし
- システムとプロセスに焦点、人ではない
- 誰もが自由に発言可能
- アクション項目は完了まで追跡

2. ランブック標準

ランブック内容:
  - サービス概要: 目的、依存関係、アーキテクチャ
  - SLI/SLO/SLA: 定義されたしきい値と目標
  - 一般的な問題: 症状、原因、解決策
  - トラブルシューティング手順: ステップバイステップの手順
  - エスカレーションパス: 連絡先とタイミング
  - 便利なコマンド: コピペ可能なコマンド
  - ダッシュボードリンク: 関連ダッシュボードへの直接リンク
  - 最近の変更: 変更ログへのリンク
  - 連絡先情報: チーム、プロダクトオーナー、 SME

メンテナンス:
  - 四半期ごと、または重大インシデント後に確認
  - トラフィック低い期間に手順をテスト
  - 重要な変更後に更新
  - 使用メトリクスを追跡 (ページビュー、有用性評価)

3. オンコールベストプラクティス

オンコール準備:
  - VPN アクセス付きラップトップ
  - 通知アプリ付きモバイルデバイス
  - 連絡先リスト (エスカレーションパス)
  - すべての重大システムへのアクセス
  - ランブックをブックマーク
  - バックアップオンコール担当者を特定

オンコール中:
  - 5分以内にアラートを確認
  - インシデントステータスを定期更新
  - エスカレーション手順に従う
  - すべてのアクションをインシデントチケットに記録
  - 次のオンコール担当者に明確に引き継ぎ

オンコール後:
  - インシデントレポートを完了
  - 手作業削減チケットを提出
  - ランブックにフィードバックを提供
  - オンコール文書を更新

4. 変更管理の規律

標準変更プロセス:
  1. 変更リクエスト (RFC) を作成
  2. 以下を文書化:
     - What: 実施する具体的な変更
     - Why: ビジネス上の正当性
     - When: 提案されている日時
     - Who: 変更実施者と承認者
     - How: ステップバイステップの手順
     - Risk: 評価と軽減策
     - Rollback: 詳細なロールバック計画
     - Testing: 検証手順
  3. CAB レビューに提出 (7日前の通知)
  4. 承認ウィンドウ内で実装
  5. 成功基準を検証
  6. 実際の結果で変更を完了
  7. 問題発生時に変更後レビューを実施

緊急変更プロセス:
  - 経営幹部承認が必須
  - 強化された監視で実装
  - 全チーム通知
  - 24時間以内に完全に文書化
  - 変更後レビューが強制

リファレンスファイル

詳細な技術ガイダンスについては、以下を参照してください:

• reference/monitoring.md - 可観測性、メトリクス、アラート、ダッシュボード設計
• reference/incident-management.md - インシデント対応、根本原因分析、ポストモーテム
• reference/infrastructure.md - サーバー管理、ネットワーク運用、キャパシティ計画
• reference/automation.md - スクリプティング、構成管理、オーケストレーションツール
• reference/backup-recovery.md - バックアップ戦略、ディザスタリカバリー、ビジネス継続性

はじめに

1. 新規インフラストラクチャの場合: reference/infrastructure.md で セットアップガイダンスを確認
2. 監視セットアップの場合: reference/monitoring.md で可観測性戦略を確認
3. インシデント対応の場合: reference/incident-management.md で手順を確認
4. 自動化プロジェクトの場合: reference/automation.md でツール推奨事項を確認
5. DR 計画の場合: reference/backup-recovery.md で復旧戦略を確認