[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ER7GGKY2WCN7NPDD2HPCTT":3,"skill-same:01M6ER7GGKY2WCN7NPDD2HPCTT":101},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":53,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M6ER7GGKY2WCN7NPDD2HPCTT","it-operations",null,"Manages IT infrastructure, monitoring, incident response, and service reliability. Provides frameworks for ITIL service management, observability strategies, automation, backup\u002Frecovery, capacity planning, and operational excellence practices.","ComeOnOliver\u002Fskillshub","ComeOnOliver","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F43215937?v=4","01M6E5JNFECJAAVFE0W7SMWWD2","Haoran Shu","01M6E5JNNDQS7AJZDYFQ8TPZCK",66,"MIT","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Faiskillstore\u002Fmarketplace\u002Fdavila7\u002Fit-operations\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"it","it operations","operations","recovery","service","strategies","incident","frameworks","capacity planning","reliability","management","incident response","backup","monitoring","observability","planning","infrastructure","capacity","automation","2026-11-10 10:12:30",false,"---\nname: it-operations\ndescription: Manages IT infrastructure, monitoring, incident response, and service reliability. Provides frameworks for ITIL service management, observability strategies, automation, backup\u002Frecovery, capacity planning, and operational excellence practices.\n---\n\n# IT Operations Expert\n\nA comprehensive skill for managing IT infrastructure operations, ensuring service reliability, implementing monitoring and alerting strategies, managing incidents, and maintaining operational excellence through automation and best practices.\n\n## Core Principles\n\n### 1. Service Reliability First\n- **Proactive Monitoring**: Implement comprehensive observability before incidents occur\n- **Incident Management**: Structured response processes with clear escalation paths\n- **SLA\u002FSLO Management**: Define and maintain service level objectives aligned with business needs\n- **Continuous Improvement**: Learn from incidents through blameless post-mortems\n\n### 2. Automation Over Manual Processes\n- **Infrastructure as Code**: Manage infrastructure configuration through version-controlled code\n- **Runbook Automation**: Convert manual procedures into automated workflows\n- **Self-Healing Systems**: Implement automated remediation for common issues\n- **Configuration Management**: Maintain consistency across environments\n\n### 3. ITIL Service Management\n- **Service Strategy**: Align IT services with business objectives\n- **Service Design**: Design resilient, scalable services\n- **Service Transition**: Manage changes with minimal disruption\n- **Service Operation**: Deliver and support services effectively\n- **Continual Service Improvement**: Iteratively enhance service quality\n\n### 4. Operational Excellence\n- **Documentation**: Maintain current runbooks, procedures, and architecture diagrams\n- **Knowledge Management**: Build searchable knowledge bases from incident resolutions\n- **Capacity Planning**: Forecast and provision resources proactively\n- **Cost Optimization**: Balance performance requirements with infrastructure costs\n\n## Core Workflow\n\n### Infrastructure Operations Workflow\n\n```\n1. MONITORING & OBSERVABILITY\n   ├─ Define SLIs\u002FSLOs\u002FSLAs for critical services\n   ├─ Implement metrics collection (infrastructure, application, business)\n   ├─ Configure alerting with proper thresholds and escalation\n   ├─ Build dashboards for different audiences (ops, devs, executives)\n   └─ Establish on-call rotation and escalation procedures\n\n2. INCIDENT MANAGEMENT\n   ├─ Receive alert or user report\n   ├─ Assess severity and impact (P1\u002FP2\u002FP3\u002FP4)\n   ├─ Engage appropriate responders\n   ├─ Investigate and diagnose root cause\n   ├─ Implement fix or workaround\n   ├─ Communicate status to stakeholders\n   ├─ Document resolution in knowledge base\n   └─ Conduct post-incident review\n\n3. CHANGE MANAGEMENT\n   ├─ Submit change request with impact assessment\n   ├─ Review and approve through CAB (Change Advisory Board)\n   ├─ Schedule change window\n   ├─ Execute change with rollback plan ready\n   ├─ Validate success criteria\n   ├─ Document actual vs planned results\n   └─ Close change ticket\n\n4. CAPACITY PLANNING\n   ├─ Collect resource utilization trends\n   ├─ Analyze growth patterns\n   ├─ Forecast future requirements\n   ├─ Plan procurement or provisioning\n   ├─ Execute capacity additions\n   └─ Monitor effectiveness\n\n5. AUTOMATION & OPTIMIZATION\n   ├─ Identify repetitive manual tasks\n   ├─ Document current process\n   ├─ Design automated solution\n   ├─ Implement and test automation\n   ├─ Deploy to production\n   ├─ Measure time\u002Fcost savings\n   └─ Iterate and improve\n```\n\n## Decision Frameworks\n\n### Alert Configuration Decision Matrix\n\n| Scenario | Alert Type | Threshold | Response Time | Escalation |\n|----------|-----------|-----------|---------------|------------|\n| Service completely down | Page | Immediate | \u003C 5 min | Immediate to on-call |\n| Service degraded | Page | 2-3 failures | \u003C 15 min | After 15 min to on-call |\n| High resource usage | Warning | > 80% sustained | \u003C 1 hour | After 2 hours to team lead |\n| Approaching capacity | Info | > 70% trend | \u003C 24 hours | Weekly capacity review |\n| Configuration drift | Ticket | Any deviation | \u003C 7 days | Monthly review |\n\n### Incident Severity Classification\n\n**Priority 1 (Critical)**\n- Complete service outage affecting all users\n- Data loss or security breach\n- Financial impact > $10K\u002Fhour\n- Response: Immediate, 24\u002F7, all hands on deck\n\n**Priority 2 (High)**\n- Partial service outage affecting many users\n- Significant performance degradation\n- Financial impact $1K-$10K\u002Fhour\n- Response: \u003C 30 minutes during business hours\n\n**Priority 3 (Medium)**\n- Service degradation affecting some users\n- Non-critical functionality impaired\n- Workaround available\n- Response: \u003C 4 hours during business hours\n\n**Priority 4 (Low)**\n- Minor issues with minimal impact\n- Cosmetic problems\n- Enhancement requests\n- Response: Next business day\n\n### Change Management Risk Assessment\n\n```\nRisk Level = Impact × Likelihood × Complexity\n\nImpact (1-5):\n1 = Single user\n2 = Team\n3 = Department\n4 = Company-wide\n5 = Customer-facing\n\nLikelihood of Issues (1-5):\n1 = Routine, tested\n2 = Familiar, documented\n3 = Some uncertainty\n4 = New territory\n5 = Never done before\n\nComplexity (1-5):\n1 = Single component\n2 = Few components\n3 = Multiple systems\n4 = Cross-platform\n5 = Enterprise-wide\n\nRisk Score Interpretation:\n1-20: Standard change (pre-approved)\n21-50: Normal change (CAB review)\n51-75: High-risk change (extensive testing, senior approval)\n76-125: Emergency change only (executive approval)\n```\n\n### Monitoring Tool Selection\n\n| Requirement | Prometheus + Grafana | Datadog | New Relic | ELK Stack | Splunk |\n|-------------|---------------------|---------|-----------|-----------|---------|\n| Cost | Free (self-hosted) | $$$$ | $$$$ | Free-$$ | $$$$$ |\n| Metrics | Excellent | Excellent | Excellent | Good | Good |\n| Logs | Via Loki | Excellent | Excellent | Excellent | Excellent |\n| Traces | Via Tempo | Excellent | Excellent | Limited | Good |\n| Learning Curve | Steep | Moderate | Moderate | Steep | Steep |\n| Cloud-Native | Excellent | Excellent | Excellent | Good | Good |\n| On-Premises | Excellent | Good | Good | Excellent | Excellent |\n| APM | Via exporters | Excellent | Excellent | Limited | Good |\n\n## Common Operational Challenges\n\n### Challenge 1: Alert Fatigue\n**Problem**: Too many false positive alerts causing team burnout\n\n**Solution**:\n```yaml\nAlert Tuning Process:\n1. Measure baseline alert volume and false positive rate\n2. Categorize alerts by actionability:\n   - Actionable + Urgent = Keep as page\n   - Actionable + Not Urgent = Ticket\n   - Not Actionable = Remove or convert to dashboard metric\n3. Implement alert aggregation (group similar alerts)\n4. Add context to alerts (runbook links, relevant metrics)\n5. Regular review meetings (weekly) to tune thresholds\n6. Track metrics:\n   - MTTA (Mean Time to Acknowledge): \u003C 5 min target\n   - False Positive Rate: \u003C 20% target\n   - Alert Volume per Week: Trending down\n```\n\n### Challenge 2: Incident Documentation During Crisis\n**Problem**: Teams skip documentation during high-pressure incidents\n\n**Solution**:\n- Assign dedicated scribe role (not the incident commander)\n- Use incident management tools (PagerDuty, Opsgenie) with automatic timeline\n- Template-based incident reports with required fields\n- Post-incident review scheduled automatically (within 48 hours)\n- Gamify documentation (track and recognize thorough documentation)\n\n### Challenge 3: Knowledge Silos\n**Problem**: Critical knowledge trapped in individual team members' heads\n\n**Solution**:\n```yaml\nKnowledge Transfer Strategy:\n- Pair Programming\u002FShadowing: 20% of sprint capacity\n- Runbook Requirements: Every system must have runbook\n- Lunch & Learn Sessions: Weekly 30-min knowledge sharing\n- Cross-Training Matrix: Track who knows what, identify gaps\n- On-Call Rotation: Everyone rotates to spread knowledge\n- Post-Incident Reviews: Mandatory team sharing\n- Documentation Sprints: Quarterly focus on doc completion\n```\n\n### Challenge 4: Balancing Stability vs Innovation\n**Problem**: Operations team resists change to maintain stability\n\n**Solution**:\n- Implement change windows (planned maintenance periods)\n- Use blue-green or canary deployments for lower risk\n- Establish \"innovation time\" (Google 20% time model)\n- Create sandbox environments for experimentation\n- Measure and reward both stability AND improvement metrics\n- Include \"toil reduction\" as OKR target\n\n## Key Metrics & KPIs\n\n### Service Reliability Metrics\n```yaml\nAvailability:\n  Formula: (Total Time - Downtime) \u002F Total Time × 100\n  Target: 99.9% (43.8 min\u002Fmonth downtime)\n  Measurement: Per service, monthly\n\nMTTR (Mean Time to Recovery):\n  Formula: Sum of recovery times \u002F Number of incidents\n  Target: \u003C 30 minutes for P1, \u003C 4 hours for P2\n  Measurement: Per severity level, monthly\n\nMTBF (Mean Time Between Failures):\n  Formula: Total operational time \u002F Number of failures\n  Target: > 720 hours (30 days)\n  Measurement: Per service, quarterly\n\nMTTA (Mean Time to Acknowledge):\n  Formula: Sum of acknowledgment times \u002F Number of alerts\n  Target: \u003C 5 minutes for pages\n  Measurement: Per on-call engineer, weekly\n\nChange Success Rate:\n  Formula: Successful changes \u002F Total changes × 100\n  Target: > 95%\n  Measurement: Monthly\n\nIncident Recurrence Rate:\n  Formula: Repeat incidents \u002F Total incidents × 100\n  Target: \u003C 10%\n  Measurement: Quarterly (same root cause within 90 days)\n```\n\n### Operational Efficiency Metrics\n```yaml\nToil Percentage:\n  Definition: Time spent on manual, repetitive tasks\n  Target: \u003C 30% of team capacity\n  Measurement: Weekly time tracking\n\nAutomation Coverage:\n  Formula: Automated tasks \u002F Total repetitive tasks × 100\n  Target: > 70%\n  Measurement: Quarterly audit\n\nOn-Call Load:\n  Formula: Alerts per on-call shift\n  Target: \u003C 5 actionable alerts per shift\n  Measurement: Per engineer, weekly\n\nRunbook Coverage:\n  Formula: Services with runbooks \u002F Total services × 100\n  Target: 100%\n  Measurement: Monthly audit\n\nKnowledge Base Utilization:\n  Formula: Incidents resolved via KB \u002F Total incidents × 100\n  Target: > 40%\n  Measurement: Monthly\n```\n\n## Integration Points\n\n### With Development Teams\n- Participate in design reviews for operational requirements\n- Provide deployment automation and CI\u002FCD pipeline support\n- Share monitoring and logging requirements\n- Collaborate on incident response and post-mortems\n- Joint ownership of SLOs and error budgets\n\n### With Security Teams\n- Implement security monitoring and alerting\n- Manage access controls and authentication systems\n- Coordinate vulnerability patching and remediation\n- Conduct security incident response\n- Maintain compliance with security policies\n\n### With Business Stakeholders\n- Report on service availability and performance\n- Communicate planned maintenance windows\n- Provide capacity planning forecasts\n- Translate technical metrics to business impact\n- Participate in business continuity planning\n\n## Best Practices\n\n### 1. Blameless Post-Mortems\n```markdown\nPost-Incident Review Template:\n- Incident Summary (what happened, when, impact)\n- Timeline of Events (detailed chronology)\n- Root Cause Analysis (5 Whys or Fishbone)\n- What Went Well (strengths during response)\n- What Could Be Improved (opportunities)\n- Action Items (with owners and due dates)\n- Lessons Learned (shareable insights)\n\nRules:\n- No blame or punishment\n- Focus on systems and processes, not people\n- Everyone can speak freely\n- Action items must be tracked to completion\n```\n\n### 2. Runbook Standards\n```yaml\nRunbook Contents:\n  - Service Overview: Purpose, dependencies, architecture\n  - SLIs\u002FSLOs\u002FSLAs: Defined thresholds and targets\n  - Common Issues: Symptoms, causes, solutions\n  - Troubleshooting Steps: Step-by-step procedures\n  - Escalation Paths: Who to contact and when\n  - Useful Commands: Copy-paste ready commands\n  - Dashboard Links: Direct links to relevant dashboards\n  - Recent Changes: Link to change log\n  - Contact Information: Team, product owner, SMEs\n\nMaintenance:\n  - Review quarterly or after major incidents\n  - Test procedures during low-traffic periods\n  - Update after every significant change\n  - Track usage metrics (page views, helpfulness ratings)\n```\n\n### 3. On-Call Best Practices\n```yaml\nOn-Call Preparation:\n  - Laptop with VPN access\n  - Mobile device with notification apps\n  - Contact list (escalation paths)\n  - Access to all critical systems\n  - Runbooks bookmarked\n  - Backup on-call identified\n\nDuring On-Call:\n  - Acknowledge alerts within 5 minutes\n  - Update incident status regularly\n  - Follow escalation procedures\n  - Document all actions in incident ticket\n  - Handoff clearly to next on-call\n\nPost On-Call:\n  - Complete incident reports\n  - Submit toil reduction tickets\n  - Provide feedback on runbooks\n  - Update on-call documentation\n```\n\n### 4. Change Management Discipline\n```yaml\nStandard Change Process:\n  1. Create change request (RFC)\n  2. Document:\n     - What: Specific changes being made\n     - Why: Business justification\n     - When: Proposed date\u002Ftime\n     - Who: Change implementer and approver\n     - How: Step-by-step procedure\n     - Risk: Assessment and mitigation\n     - Rollback: Detailed rollback plan\n     - Testing: Validation steps\n  3. Submit for CAB review (7 days advance notice)\n  4. Implement during approved window\n  5. Validate success criteria\n  6. Close change with actual results\n  7. Post-implementation review if issues occurred\n\nEmergency Change Process:\n  - Executive approval required\n  - Implement with heightened monitoring\n  - Full team notification\n  - Complete documentation within 24 hours\n  - Mandatory post-change review\n```\n\n## Reference Files\n\nFor detailed technical guidance, see:\n- [reference\u002Fmonitoring.md](reference\u002Fmonitoring.md) - Observability, metrics, alerting, and dashboard design\n- [reference\u002Fincident-management.md](reference\u002Fincident-management.md) - Incident response, root cause analysis, post-mortems\n- [reference\u002Finfrastructure.md](reference\u002Finfrastructure.md) - Server management, network operations, capacity planning\n- [reference\u002Fautomation.md](reference\u002Fautomation.md) - Scripting, configuration management, orchestration tools\n- [reference\u002Fbackup-recovery.md](reference\u002Fbackup-recovery.md) - Backup strategies, disaster recovery, business continuity\n\n## Getting Started\n\n1. **For New Infrastructure**: Start with [reference\u002Finfrastructure.md](reference\u002Finfrastructure.md) for setup guidance\n2. **For Monitoring Setup**: Review [reference\u002Fmonitoring.md](reference\u002Fmonitoring.md) for observability strategy\n3. **For Incident Response**: See [reference\u002Fincident-management.md](reference\u002Fincident-management.md) for procedures\n4. **For Automation Projects**: Check [reference\u002Fautomation.md](reference\u002Fautomation.md) for tooling recommendations\n5. **For DR Planning**: Consult [reference\u002Fbackup-recovery.md](reference\u002Fbackup-recovery.md) for recovery strategies\n","# IT Operations Expert\n\nA comprehensive skill for managing IT infrastructure operations, ensuring service reliability, implementing monitoring and alerting strategies, managing incidents, and maintaining operational excellence through automation and best practices.\n\n## Core Principles\n\n### 1. Service Reliability First\n- **Proactive Monitoring**: Implement comprehensive observability before incidents occur\n- **Incident Management**: Structured response processes with clear escalation paths\n- **SLA\u002FSLO Management**: Define and maintain service level objectives aligned with business needs\n- **Continuous Improvement**: Learn from incidents through blameless post-mortems\n\n### 2. Automation Over Manual Processes\n- **Infrastructure as Code**: Manage infrastructure configuration through version-controlled code\n- **Runbook Automation**: Convert manual procedures into automated workflows\n- **Self-Healing Systems**: Implement automated remediation for common issues\n- **Configuration Management**: Maintain consistency across environments\n\n### 3. ITIL Service Management\n- **Service Strategy**: Align IT services with business objectives\n- **Service Design**: Design resilient, scalable services\n- **Service Transition**: Manage changes with minimal disruption\n- **Service Operation**: Deliver and support services effectively\n- **Continual Service Improvement**: Iteratively enhance service quality\n\n### 4. Operational Excellence\n- **Documentation**: Maintain current runbooks, procedures, and architecture diagrams\n- **Knowledge Management**: Build searchable knowledge bases from incident resolutions\n- **Capacity Planning**: Forecast and provision resources proactively\n- **Cost Optimization**: Balance performance requirements with infrastructure costs\n\n## Core Workflow\n\n### Infrastructure Operations Workflow\n\n```\n1. MONITORING & OBSERVABILITY\n   ├─ Define SLIs\u002FSLOs\u002FSLAs for critical services\n   ├─ Implement metrics collection (infrastructure, application, business)\n   ├─ Configure alerting with proper thresholds and escalation\n   ├─ Build dashboards for different audiences (ops, devs, executives)\n   └─ Establish on-call rotation and escalation procedures\n\n2. INCIDENT MANAGEMENT\n   ├─ Receive alert or user report\n   ├─ Assess severity and impact (P1\u002FP2\u002FP3\u002FP4)\n   ├─ Engage appropriate responders\n   ├─ Investigate and diagnose root cause\n   ├─ Implement fix or workaround\n   ├─ Communicate status to stakeholders\n   ├─ Document resolution in knowledge base\n   └─ Conduct post-incident review\n\n3. CHANGE MANAGEMENT\n   ├─ Submit change request with impact assessment\n   ├─ Review and approve through CAB (Change Advisory Board)\n   ├─ Schedule change window\n   ├─ Execute change with rollback plan ready\n   ├─ Validate success criteria\n   ├─ Document actual vs planned results\n   └─ Close change ticket\n\n4. CAPACITY PLANNING\n   ├─ Collect resource utilization trends\n   ├─ Analyze growth patterns\n   ├─ Forecast future requirements\n   ├─ Plan procurement or provisioning\n   ├─ Execute capacity additions\n   └─ Monitor effectiveness\n\n5. AUTOMATION & OPTIMIZATION\n   ├─ Identify repetitive manual tasks\n   ├─ Document current process\n   ├─ Design automated solution\n   ├─ Implement and test automation\n   ├─ Deploy to production\n   ├─ Measure time\u002Fcost savings\n   └─ Iterate and improve\n```\n\n## Decision Frameworks\n\n### Alert Configuration Decision Matrix\n\n| Scenario | Alert Type | Threshold | Response Time | Escalation |\n|----------|-----------|-----------|---------------|------------|\n| Service completely down | Page | Immediate | \u003C 5 min | Immediate to on-call |\n| Service degraded | Page | 2-3 failures | \u003C 15 min | After 15 min to on-call |\n| High resource usage | Warning | > 80% sustained | \u003C 1 hour | After 2 hours to team lead |\n| Approaching capacity | Info | > 70% trend | \u003C 24 hours | Weekly capacity review |\n| Configuration drift | Ticket | Any deviation | \u003C 7 days | Monthly review |\n\n### Incident Severity Classification\n\n**Priority 1 (Critical)**\n- Complete service outage affecting all users\n- Data loss or security breach\n- Financial impact > $10K\u002Fhour\n- Response: Immediate, 24\u002F7, all hands on deck\n\n**Priority 2 (High)**\n- Partial service outage affecting many users\n- Significant performance degradation\n- Financial impact $1K-$10K\u002Fhour\n- Response: \u003C 30 minutes during business hours\n\n**Priority 3 (Medium)**\n- Service degradation affecting some users\n- Non-critical functionality impaired\n- Workaround available\n- Response: \u003C 4 hours during business hours\n\n**Priority 4 (Low)**\n- Minor issues with minimal impact\n- Cosmetic problems\n- Enhancement requests\n- Response: Next business day\n\n### Change Management Risk Assessment\n\n```\nRisk Level = Impact × Likelihood × Complexity\n\nImpact (1-5):\n1 = Single user\n2 = Team\n3 = Department\n4 = Company-wide\n5 = Customer-facing\n\nLikelihood of Issues (1-5):\n1 = Routine, tested\n2 = Familiar, documented\n3 = Some uncertainty\n4 = New territory\n5 = Never done before\n\nComplexity (1-5):\n1 = Single component\n2 = Few components\n3 = Multiple systems\n4 = Cross-platform\n5 = Enterprise-wide\n\nRisk Score Interpretation:\n1-20: Standard change (pre-approved)\n21-50: Normal change (CAB review)\n51-75: High-risk change (extensive testing, senior approval)\n76-125: Emergency change only (executive approval)\n```\n\n### Monitoring Tool Selection\n\n| Requirement | Prometheus + Grafana | Datadog | New Relic | ELK Stack | Splunk |\n|-------------|---------------------|---------|-----------|-----------|---------|\n| Cost | Free (self-hosted) | $$$$ | $$$$ | Free-$$ | $$$$$ |\n| Metrics | Excellent | Excellent | Excellent | Good | Good |\n| Logs | Via Loki | Excellent | Excellent | Excellent | Excellent |\n| Traces | Via Tempo | Excellent | Excellent | Limited | Good |\n| Learning Curve | Steep | Moderate | Moderate | Steep | Steep |\n| Cloud-Native | Excellent | Excellent | Excellent | Good | Good |\n| On-Premises | Excellent | Good | Good | Excellent | Excellent |\n| APM | Via exporters | Excellent | Excellent | Limited | Good |\n\n## Common Operational Challenges\n\n### Challenge 1: Alert Fatigue\n**Problem**: Too many false positive alerts causing team burnout\n\n**Solution**:\n```yaml\nAlert Tuning Process:\n1. Measure baseline alert volume and false positive rate\n2. Categorize alerts by actionability:\n   - Actionable + Urgent = Keep as page\n   - Actionable + Not Urgent = Ticket\n   - Not Actionable = Remove or convert to dashboard metric\n3. Implement alert aggregation (group similar alerts)\n4. Add context to alerts (runbook links, relevant metrics)\n5. Regular review meetings (weekly) to tune thresholds\n6. Track metrics:\n   - MTTA (Mean Time to Acknowledge): \u003C 5 min target\n   - False Positive Rate: \u003C 20% target\n   - Alert Volume per Week: Trending down\n```\n\n### Challenge 2: Incident Documentation During Crisis\n**Problem**: Teams skip documentation during high-pressure incidents\n\n**Solution**:\n- Assign dedicated scribe role (not the incident commander)\n- Use incident management tools (PagerDuty, Opsgenie) with automatic timeline\n- Template-based incident reports with required fields\n- Post-incident review scheduled automatically (within 48 hours)\n- Gamify documentation (track and recognize thorough documentation)\n\n### Challenge 3: Knowledge Silos\n**Problem**: Critical knowledge trapped in individual team members' heads\n\n**Solution**:\n```yaml\nKnowledge Transfer Strategy:\n- Pair Programming\u002FShadowing: 20% of sprint capacity\n- Runbook Requirements: Every system must have runbook\n- Lunch & Learn Sessions: Weekly 30-min knowledge sharing\n- Cross-Training Matrix: Track who knows what, identify gaps\n- On-Call Rotation: Everyone rotates to spread knowledge\n- Post-Incident Reviews: Mandatory team sharing\n- Documentation Sprints: Quarterly focus on doc completion\n```\n\n### Challenge 4: Balancing Stability vs Innovation\n**Problem**: Operations team resists change to maintain stability\n\n**Solution**:\n- Implement change windows (planned maintenance periods)\n- Use blue-green or canary deployments for lower risk\n- Establish \"innovation time\" (Google 20% time model)\n- Create sandbox environments for experimentation\n- Measure and reward both stability AND improvement metrics\n- Include \"toil reduction\" as OKR target\n\n## Key Metrics & KPIs\n\n### Service Reliability Metrics\n```yaml\nAvailability:\n  Formula: (Total Time - Downtime) \u002F Total Time × 100\n  Target: 99.9% (43.8 min\u002Fmonth downtime)\n  Measurement: Per service, monthly\n\nMTTR (Mean Time to Recovery):\n  Formula: Sum of recovery times \u002F Number of incidents\n  Target: \u003C 30 minutes for P1, \u003C 4 hours for P2\n  Measurement: Per severity level, monthly\n\nMTBF (Mean Time Between Failures):\n  Formula: Total operational time \u002F Number of failures\n  Target: > 720 hours (30 days)\n  Measurement: Per service, quarterly\n\nMTTA (Mean Time to Acknowledge):\n  Formula: Sum of acknowledgment times \u002F Number of alerts\n  Target: \u003C 5 minutes for pages\n  Measurement: Per on-call engineer, weekly\n\nChange Success Rate:\n  Formula: Successful changes \u002F Total changes × 100\n  Target: > 95%\n  Measurement: Monthly\n\nIncident Recurrence Rate:\n  Formula: Repeat incidents \u002F Total incidents × 100\n  Target: \u003C 10%\n  Measurement: Quarterly (same root cause within 90 days)\n```\n\n### Operational Efficiency Metrics\n```yaml\nToil Percentage:\n  Definition: Time spent on manual, repetitive tasks\n  Target: \u003C 30% of team capacity\n  Measurement: Weekly time tracking\n\nAutomation Coverage:\n  Formula: Automated tasks \u002F Total repetitive tasks × 100\n  Target: > 70%\n  Measurement: Quarterly audit\n\nOn-Call Load:\n  Formula: Alerts per on-call shift\n  Target: \u003C 5 actionable alerts per shift\n  Measurement: Per engineer, weekly\n\nRunbook Coverage:\n  Formula: Services with runbooks \u002F Total services × 100\n  Target: 100%\n  Measurement: Monthly audit\n\nKnowledge Base Utilization:\n  Formula: Incidents resolved via KB \u002F Total incidents × 100\n  Target: > 40%\n  Measurement: Monthly\n```\n\n## Integration Points\n\n### With Development Teams\n- Participate in design reviews for operational requirements\n- Provide deployment automation and CI\u002FCD pipeline support\n- Share monitoring and logging requirements\n- Collaborate on incident response and post-mortems\n- Joint ownership of SLOs and error budgets\n\n### With Security Teams\n- Implement security monitoring and alerting\n- Manage access controls and authentication systems\n- Coordinate vulnerability patching and remediation\n- Conduct security incident response\n- Maintain compliance with security policies\n\n### With Business Stakeholders\n- Report on service availability and performance\n- Communicate planned maintenance windows\n- Provide capacity planning forecasts\n- Translate technical metrics to business impact\n- Participate in business continuity planning\n\n## Best Practices\n\n### 1. Blameless Post-Mortems\n```markdown\nPost-Incident Review Template:\n- Incident Summary (what happened, when, impact)\n- Timeline of Events (detailed chronology)\n- Root Cause Analysis (5 Whys or Fishbone)\n- What Went Well (strengths during response)\n- What Could Be Improved (opportunities)\n- Action Items (with owners and due dates)\n- Lessons Learned (shareable insights)\n\nRules:\n- No blame or punishment\n- Focus on systems and processes, not people\n- Everyone can speak freely\n- Action items must be tracked to completion\n```\n\n### 2. Runbook Standards\n```yaml\nRunbook Contents:\n  - Service Overview: Purpose, dependencies, architecture\n  - SLIs\u002FSLOs\u002FSLAs: Defined thresholds and targets\n  - Common Issues: Symptoms, causes, solutions\n  - Troubleshooting Steps: Step-by-step procedures\n  - Escalation Paths: Who to contact and when\n  - Useful Commands: Copy-paste ready commands\n  - Dashboard Links: Direct links to relevant dashboards\n  - Recent Changes: Link to change log\n  - Contact Information: Team, product owner, SMEs\n\nMaintenance:\n  - Review quarterly or after major incidents\n  - Test procedures during low-traffic periods\n  - Update after every significant change\n  - Track usage metrics (page views, helpfulness ratings)\n```\n\n### 3. On-Call Best Practices\n```yaml\nOn-Call Preparation:\n  - Laptop with VPN access\n  - Mobile device with notification apps\n  - Contact list (escalation paths)\n  - Access to all critical systems\n  - Runbooks bookmarked\n  - Backup on-call identified\n\nDuring On-Call:\n  - Acknowledge alerts within 5 minutes\n  - Update incident status regularly\n  - Follow escalation procedures\n  - Document all actions in incident ticket\n  - Handoff clearly to next on-call\n\nPost On-Call:\n  - Complete incident reports\n  - Submit toil reduction tickets\n  - Provide feedback on runbooks\n  - Update on-call documentation\n```\n\n### 4. Change Management Discipline\n```yaml\nStandard Change Process:\n  1. Create change request (RFC)\n  2. Document:\n     - What: Specific changes being made\n     - Why: Business justification\n     - When: Proposed date\u002Ftime\n     - Who: Change implementer and approver\n     - How: Step-by-step procedure\n     - Risk: Assessment and mitigation\n     - Rollback: Detailed rollback plan\n     - Testing: Validation steps\n  3. Submit for CAB review (7 days advance notice)\n  4. Implement during approved window\n  5. Validate success criteria\n  6. Close change with actual results\n  7. Post-implementation review if issues occurred\n\nEmergency Change Process:\n  - Executive approval required\n  - Implement with heightened monitoring\n  - Full team notification\n  - Complete documentation within 24 hours\n  - Mandatory post-change review\n```\n\n## Reference Files\n\nFor detailed technical guidance, see:\n- [reference\u002Fmonitoring.md](reference\u002Fmonitoring.md) - Observability, metrics, alerting, and dashboard design\n- [reference\u002Fincident-management.md](reference\u002Fincident-management.md) - Incident response, root cause analysis, post-mortems\n- [reference\u002Finfrastructure.md](reference\u002Finfrastructure.md) - Server management, network operations, capacity planning\n- [reference\u002Fautomation.md](reference\u002Fautomation.md) - Scripting, configuration management, orchestration tools\n- [reference\u002Fbackup-recovery.md](reference\u002Fbackup-recovery.md) - Backup strategies, disaster recovery, business continuity\n\n## Getting Started\n\n1. **For New Infrastructure**: Start with [reference\u002Finfrastructure.md](reference\u002Finfrastructure.md) for setup guidance\n2. **For Monitoring Setup**: Review [reference\u002Fmonitoring.md](reference\u002Fmonitoring.md) for observability strategy\n3. **For Incident Response**: See [reference\u002Fincident-management.md](reference\u002Fincident-management.md) for procedures\n4. **For Automation Projects**: Check [reference\u002Fautomation.md](reference\u002Fautomation.md) for tooling recommendations\n5. **For DR Planning**: Consult [reference\u002Fbackup-recovery.md](reference\u002Fbackup-recovery.md) for recovery strategies\n",{"name":5,"description":7},"main","def8531e65114c0fca8fb8551c1871ee0eed705c","skills\u002Faiskillstore\u002Fmarketplace\u002Fdavila7\u002Fit-operations",24,"https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub","https:\u002F\u002Fskillshub.wtf","https:\u002F\u002Fgithub.com\u002FComeOnOliver","AI & Blockchain Engineer\r\n","2026-06-24 22:07:19",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add ComeOnOliver\u002Fskillshub --skill it-operations",{"tool":63,"command":64},"bunx","bunx skills add ComeOnOliver\u002Fskillshub --skill it-operations",{"tool":66,"command":67},"pnpm","pnpm dlx skills add ComeOnOliver\u002Fskillshub --skill it-operations","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Faiskillstore\u002Fmarketplace\u002Fdavila7\u002Fit-operations\u002FSKILL.md",true,[71,77,81,85,89,93,97],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"README.md","REFERENCE","参考文档",9738,"https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Faiskillstore\u002Fmarketplace\u002Fdavila7\u002Fit-operations\u002FREADME.md",{"path":78,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":79,"sourceHtmlUrl":80},"reference\u002Fautomation.md",40343,"https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Faiskillstore\u002Fmarketplace\u002Fdavila7\u002Fit-operations\u002Freference\u002Fautomation.md",{"path":82,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":83,"sourceHtmlUrl":84},"reference\u002Fbackup-recovery.md",26233,"https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Faiskillstore\u002Fmarketplace\u002Fdavila7\u002Fit-operations\u002Freference\u002Fbackup-recovery.md",{"path":86,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":87,"sourceHtmlUrl":88},"reference\u002Fincident-management.md",46805,"https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Faiskillstore\u002Fmarketplace\u002Fdavila7\u002Fit-operations\u002Freference\u002Fincident-management.md",{"path":90,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":91,"sourceHtmlUrl":92},"reference\u002Finfrastructure.md",45301,"https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Faiskillstore\u002Fmarketplace\u002Fdavila7\u002Fit-operations\u002Freference\u002Finfrastructure.md",{"path":94,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":95,"sourceHtmlUrl":96},"reference\u002Fmonitoring.md",38260,"https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Faiskillstore\u002Fmarketplace\u002Fdavila7\u002Fit-operations\u002Freference\u002Fmonitoring.md",{"path":98,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":99,"sourceHtmlUrl":100},"skill-report.json",10402,"https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Faiskillstore\u002Fmarketplace\u002Fdavila7\u002Fit-operations\u002Fskill-report.json",[102,112,122,131,137,144],{"skillNo":103,"name":104,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":108,"publishedAt":43},"01M6FKJN13GMG4KY57J3QD8GY5","model-hierarchy-skill","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzscole\u002Fmodel-hierarchy-skill\u002Fmodel-hierarchy-skill\u002FSKILL.md",[107],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[109,110,111],"model","model hierarchy","model hierarchy skill",{"skillNo":113,"name":114,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":118,"publishedAt":43},"01M6FKJJJ6GCAMR4PPPRD12M5X","zoom-mcp","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fzoom-mcp\u002FSKILL.md",[117],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[119,120,121],"MCP","zoom","zoom mcp",{"skillNo":123,"name":124,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":43},"01M6FKJE3KYT3KPEZMEEHYKA6K","zoom-apps-sdk","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fzoom-apps-sdk\u002FSKILL.md",[],[128,129,130,120],"sdk","zoom apps sdk","apps",{"skillNo":132,"name":133,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":136,"publishedAt":43},"01M6FKJ9EDH9Q5VWDF8HAJRSP0","windows","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwindows\u002FSKILL.md",[],[133],{"skillNo":138,"name":139,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":143,"publishedAt":43},"01M6FKJ666BEEFC3AE9GJ72Q93","whiteboard","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwhiteboard\u002FSKILL.md",[142],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[139],{"skillNo":145,"name":146,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":149,"publishedAt":43},"01M6FKJ21WFCDGTJQ2Q91T9DVW","websockets","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwebsockets\u002FSKILL.md",[],[146]]