it-operations

IT運用エキスパート

ITインフラの運用管理、サービスの信頼性確保、監視とアラート戦略の実装、インシデント管理、そして自動化とベストプラクティスによる運用品質の維持を行うための包括的なスキルです。

基本原則

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

• プロアクティブな監視: インシデントが発生する前に、包括的なオブザーバビリティを実装します
• インシデント管理: 明確なエスカレーションパスを備えた体系的な対応プロセスを用います
• SLA/SLO管理: ビジネスニーズに沿ったサービスレベル目標を定義し、維持します
• 継続的改善: 非難のないポストモーテムを通じて、インシデントから学びます

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

• Infrastructure as Code: バージョン管理されたコードを通じてインフラ構成を管理します
• ランブックの自動化: 手動の手順を自動化されたワークフローに変換します
• 自己修復システム: 一般的な問題に対する自動修復を実装します
• 構成管理: 環境間で一貫性を保ちます

3. ITIL によるサービス管理

• サービス戦略: ITサービスをビジネス目標に合わせます
• サービス設計: 回復力と拡張性のあるサービスを設計します
• サービストランジション: 影響を最小限に抑えて変更を管理します
• サービスオペレーション: サービスを効果的に提供し、サポートします
• 継続的サービス改善: サービス品質を反復的に向上させます

4. 運用品質の追求

• ドキュメント: 最新のランブック、手順書、アーキテクチャ図を維持します
• ナレッジマネジメント: インシデントの解決事例から検索可能なナレッジベースを構築します
• キャパシティプランニング: リソースを予測し、先回りして確保します
• コスト最適化: パフォーマンス要件とインフラコストのバランスを取ります

コアワークフロー

インフラ運用ワークフロー

1. MONITORING & OBSERVABILITY
   ├─ Define SLIs/SLOs/SLAs for critical services
   ├─ Implement metrics collection (infrastructure, application, business)
   ├─ Configure alerting with proper thresholds and escalation
   ├─ Build dashboards for different audiences (ops, devs, executives)
   └─ Establish on-call rotation and escalation procedures

2. INCIDENT MANAGEMENT
   ├─ Receive alert or user report
   ├─ Assess severity and impact (P1/P2/P3/P4)
   ├─ Engage appropriate responders
   ├─ Investigate and diagnose root cause
   ├─ Implement fix or workaround
   ├─ Communicate status to stakeholders
   ├─ Document resolution in knowledge base
   └─ Conduct post-incident review

3. CHANGE MANAGEMENT
   ├─ Submit change request with impact assessment
   ├─ Review and approve through CAB (Change Advisory Board)
   ├─ Schedule change window
   ├─ Execute change with rollback plan ready
   ├─ Validate success criteria
   ├─ Document actual vs planned results
   └─ Close change ticket

4. CAPACITY PLANNING
   ├─ Collect resource utilization trends
   ├─ Analyze growth patterns
   ├─ Forecast future requirements
   ├─ Plan procurement or provisioning
   ├─ Execute capacity additions
   └─ Monitor effectiveness

5. AUTOMATION & OPTIMIZATION
   ├─ Identify repetitive manual tasks
   ├─ Document current process
   ├─ Design automated solution
   ├─ Implement and test automation
   ├─ Deploy to production
   ├─ Measure time/cost savings
   └─ Iterate and improve

意思決定フレームワーク

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

シナリオ	アラートタイプ	しきい値	対応時間	エスカレーション
サービスが完全に停止	ページ	即時	5分未満	オンコール担当者へ即時
サービスの性能低下	ページ	2〜3回の失敗	15分未満	15分後にオンコール担当者へ
高いリソース使用率	警告	80%超が継続	1時間未満	2時間後にチームリーダーへ
キャパシティ上限への接近	情報	70%超のトレンド	24時間未満	週次のキャパシティレビュー
構成のドリフト	チケット	任意の逸脱	7日未満	月次レビュー

インシデントの重大度分類

優先度1（重大）

• すべてのユーザーに影響する完全なサービス停止
• データ損失またはセキュリティ侵害
• 財務的影響が1時間あたり1万ドル超
• 対応: 即時、24時間365日、全員で対応

優先度2（高）

• 多くのユーザーに影響する部分的なサービス停止
• 著しいパフォーマンス低下
• 財務的影響が1時間あたり1,000〜1万ドル
• 対応: 営業時間中は30分未満

優先度3（中）

• 一部のユーザーに影響するサービスの性能低下
• 重要度の低い機能の障害
• 回避策が利用可能
• 対応: 営業時間中は4時間未満

優先度4（低）

• 影響が最小限の軽微な問題
• 見た目の問題
• 機能改善の要望
• 対応: 次の営業日

変更管理のリスク評価

Risk Level = Impact × Likelihood × Complexity

Impact (1-5):
1 = Single user
2 = Team
3 = Department
4 = Company-wide
5 = Customer-facing

Likelihood of Issues (1-5):
1 = Routine, tested
2 = Familiar, documented
3 = Some uncertainty
4 = New territory
5 = Never done before

Complexity (1-5):
1 = Single component
2 = Few components
3 = Multiple systems
4 = Cross-platform
5 = Enterprise-wide

Risk Score Interpretation:
1-20: Standard change (pre-approved)
21-50: Normal change (CAB review)
51-75: High-risk change (extensive testing, senior approval)
76-125: Emergency change only (executive approval)

監視ツールの選定

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

一般的な運用上の課題

課題 1: アラート疲れ

問題: 誤検知のアラートが多すぎて、チームが燃え尽きてしまう

解決策:

Alert Tuning Process:
1. Measure baseline alert volume and false positive rate
2. Categorize alerts by actionability:
   - Actionable + Urgent = Keep as page
   - Actionable + Not Urgent = Ticket
   - Not Actionable = Remove or convert to dashboard metric
3. Implement alert aggregation (group similar alerts)
4. Add context to alerts (runbook links, relevant metrics)
5. Regular review meetings (weekly) to tune thresholds
6. Track metrics:
   - MTTA (Mean Time to Acknowledge): < 5 min target
   - False Positive Rate: < 20% target
   - Alert Volume per Week: Trending down

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

問題: 高プレッシャーのインシデント対応中に、チームが記録を省略してしまう

解決策:

• 専任の記録担当（スクライブ）の役割を割り当てる（インシデントコマンダーとは別に）
• 自動タイムライン機能を備えたインシデント管理ツール（PagerDuty、Opsgenie）を使用する
• 必須項目を含むテンプレートベースのインシデントレポートを用いる
• 事後レビューを自動的にスケジュールする（48 時間以内）
• 記録をゲーム化する（丁寧な記録を追跡して評価する）

課題 3: ナレッジのサイロ化

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

解決策:

Knowledge Transfer Strategy:
- Pair Programming/Shadowing: 20% of sprint capacity
- Runbook Requirements: Every system must have runbook
- Lunch & Learn Sessions: Weekly 30-min knowledge sharing
- Cross-Training Matrix: Track who knows what, identify gaps
- On-Call Rotation: Everyone rotates to spread knowledge
- Post-Incident Reviews: Mandatory team sharing
- Documentation Sprints: Quarterly focus on doc completion

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

問題: 運用チームが安定性を維持するために変更に抵抗する

解決策:

• 変更ウィンドウ（計画的なメンテナンス期間）を導入する
• リスクを下げるために、ブルーグリーンデプロイまたはカナリアデプロイを使用する
• 「イノベーションタイム」を設ける（Google の 20% ルールモデル）
• 実験用のサンドボックス環境を作成する
• 安定性と改善の両方の指標を測定し、評価する
• 「トイル削減」を OKR の目標に含める

主要なメトリクスと KPI

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

Availability:
  Formula: (Total Time - Downtime) / Total Time × 100
  Target: 99.9% (43.8 min/month downtime)
  Measurement: Per service, monthly

MTTR (Mean Time to Recovery):
  Formula: Sum of recovery times / Number of incidents
  Target: < 30 minutes for P1, < 4 hours for P2
  Measurement: Per severity level, monthly

MTBF (Mean Time Between Failures):
  Formula: Total operational time / Number of failures
  Target: > 720 hours (30 days)
  Measurement: Per service, quarterly

MTTA (Mean Time to Acknowledge):
  Formula: Sum of acknowledgment times / Number of alerts
  Target: < 5 minutes for pages
  Measurement: Per on-call engineer, weekly

Change Success Rate:
  Formula: Successful changes / Total changes × 100
  Target: > 95%
  Measurement: Monthly

Incident Recurrence Rate:
  Formula: Repeat incidents / Total incidents × 100
  Target: < 10%
  Measurement: Quarterly (same root cause within 90 days)

運用効率メトリクス

Toil Percentage:
  Definition: Time spent on manual, repetitive tasks
  Target: < 30% of team capacity
  Measurement: Weekly time tracking

Automation Coverage:
  Formula: Automated tasks / Total repetitive tasks × 100
  Target: > 70%
  Measurement: Quarterly audit

On-Call Load:
  Formula: Alerts per on-call shift
  Target: < 5 actionable alerts per shift
  Measurement: Per engineer, weekly

Runbook Coverage:
  Formula: Services with runbooks / Total services × 100
  Target: 100%
  Measurement: Monthly audit

Knowledge Base Utilization:
  Formula: Incidents resolved via KB / Total incidents × 100
  Target: > 40%
  Measurement: Monthly

連携ポイント

開発チームとの連携

• 運用要件を扱う設計レビューに参加する
• デプロイの自動化と CI/CD パイプラインの支援を提供する
• モニタリングとロギングの要件を共有する
• インシデント対応と事後検証（ポストモーテム）で協力する
• SLO とエラーバジェットを共同で管理する

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

• セキュリティ監視とアラートを実装する
• アクセス制御と認証システムを管理する
• 脆弱性へのパッチ適用と是正を調整する
• セキュリティインシデント対応を実施する
• セキュリティポリシーへの準拠を維持する

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

• サービスの可用性とパフォーマンスについて報告する
• 計画メンテナンスの期間を周知する
• キャパシティプランニングの予測を提供する
• 技術的なメトリクスをビジネスへの影響に翻訳する
• 事業継続計画の策定に参加する

ベストプラクティス

1. 非難しない事後検証（ブレームレス・ポストモーテム）

Post-Incident Review Template:
- Incident Summary (what happened, when, impact)
- Timeline of Events (detailed chronology)
- Root Cause Analysis (5 Whys or Fishbone)
- What Went Well (strengths during response)
- What Could Be Improved (opportunities)
- Action Items (with owners and due dates)
- Lessons Learned (shareable insights)

Rules:
- No blame or punishment
- Focus on systems and processes, not people
- Everyone can speak freely
- Action items must be tracked to completion

2. ランブックの標準

Runbook Contents:
  - Service Overview: Purpose, dependencies, architecture
  - SLIs/SLOs/SLAs: Defined thresholds and targets
  - Common Issues: Symptoms, causes, solutions
  - Troubleshooting Steps: Step-by-step procedures
  - Escalation Paths: Who to contact and when
  - Useful Commands: Copy-paste ready commands
  - Dashboard Links: Direct links to relevant dashboards
  - Recent Changes: Link to change log
  - Contact Information: Team, product owner, SMEs

Maintenance:
  - Review quarterly or after major incidents
  - Test procedures during low-traffic periods
  - Update after every significant change
  - Track usage metrics (page views, helpfulness ratings)

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

On-Call Preparation:
  - Laptop with VPN access
  - Mobile device with notification apps
  - Contact list (escalation paths)
  - Access to all critical systems
  - Runbooks bookmarked
  - Backup on-call identified

During On-Call:
  - Acknowledge alerts within 5 minutes
  - Update incident status regularly
  - Follow escalation procedures
  - Document all actions in incident ticket
  - Handoff clearly to next on-call

Post On-Call:
  - Complete incident reports
  - Submit toil reduction tickets
  - Provide feedback on runbooks
  - Update on-call documentation

4. 変更管理の規律

Standard Change Process:
  1. Create change request (RFC)
  2. Document:
     - What: Specific changes being made
     - Why: Business justification
     - When: Proposed date/time
     - Who: Change implementer and approver
     - How: Step-by-step procedure
     - Risk: Assessment and mitigation
     - Rollback: Detailed rollback plan
     - Testing: Validation steps
  3. Submit for CAB review (7 days advance notice)
  4. Implement during approved window
  5. Validate success criteria
  6. Close change with actual results
  7. Post-implementation review if issues occurred

Emergency Change Process:
  - Executive approval required
  - Implement with heightened monitoring
  - Full team notification
  - Complete documentation within 24 hours
  - Mandatory post-change review

参照ファイル

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

• 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 を参照してください