mirror of
https://github.com/BagelHole/DevOps-Security-Agent-Skills.git
synced 2026-08-22 12:49:53 +02:00
.
This commit is contained in:
@@ -0,0 +1,86 @@
|
||||
---
|
||||
name: business-continuity
|
||||
description: Develop business continuity plans and impact analysis. Implement BCP testing and communication procedures. Use when building organizational resilience.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: devops-skills
|
||||
version: "1.0"
|
||||
---
|
||||
|
||||
# Business Continuity Planning
|
||||
|
||||
Develop and maintain business continuity capabilities.
|
||||
|
||||
## BCP Framework
|
||||
|
||||
```yaml
|
||||
bcp_phases:
|
||||
1_analysis:
|
||||
- Business Impact Analysis (BIA)
|
||||
- Risk assessment
|
||||
- Critical process identification
|
||||
|
||||
2_planning:
|
||||
- Recovery strategies
|
||||
- Resource requirements
|
||||
- Communication plans
|
||||
|
||||
3_implementation:
|
||||
- Procedure documentation
|
||||
- Training
|
||||
- Technology setup
|
||||
|
||||
4_testing:
|
||||
- Plan exercises
|
||||
- Gap identification
|
||||
- Continuous improvement
|
||||
```
|
||||
|
||||
## Business Impact Analysis
|
||||
|
||||
```yaml
|
||||
process_classification:
|
||||
critical:
|
||||
max_downtime: 4 hours
|
||||
examples: Payment processing, authentication
|
||||
|
||||
essential:
|
||||
max_downtime: 24 hours
|
||||
examples: Customer support, reporting
|
||||
|
||||
necessary:
|
||||
max_downtime: 72 hours
|
||||
examples: Internal tools, analytics
|
||||
|
||||
desirable:
|
||||
max_downtime: 7 days
|
||||
examples: Development environments
|
||||
```
|
||||
|
||||
## Communication Plan
|
||||
|
||||
```yaml
|
||||
communication:
|
||||
internal:
|
||||
- Executive notification
|
||||
- Team communication
|
||||
- Status updates
|
||||
|
||||
external:
|
||||
- Customer notification
|
||||
- Regulatory reporting
|
||||
- Media relations
|
||||
|
||||
channels:
|
||||
- Primary: Slack/Teams
|
||||
- Secondary: Email
|
||||
- Emergency: Phone tree
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Annual BIA updates
|
||||
- Regular plan testing
|
||||
- Clear roles and responsibilities
|
||||
- Multiple communication channels
|
||||
- Executive sponsorship
|
||||
@@ -0,0 +1,73 @@
|
||||
---
|
||||
name: disaster-recovery
|
||||
description: Implement disaster recovery strategies and runbooks. Configure RPO/RTO targets and failover procedures. Use when planning for business continuity.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: devops-skills
|
||||
version: "1.0"
|
||||
---
|
||||
|
||||
# Disaster Recovery
|
||||
|
||||
Implement disaster recovery strategies and procedures.
|
||||
|
||||
## DR Metrics
|
||||
|
||||
```yaml
|
||||
recovery_metrics:
|
||||
RTO: Recovery Time Objective
|
||||
- Maximum acceptable downtime
|
||||
- How long to restore service
|
||||
|
||||
RPO: Recovery Point Objective
|
||||
- Maximum acceptable data loss
|
||||
- How much data can be lost
|
||||
```
|
||||
|
||||
## DR Strategies
|
||||
|
||||
| Strategy | RTO | RPO | Cost |
|
||||
|----------|-----|-----|------|
|
||||
| Backup & Restore | Hours | Hours | $ |
|
||||
| Pilot Light | Minutes-Hours | Minutes | $$ |
|
||||
| Warm Standby | Minutes | Seconds | $$$ |
|
||||
| Multi-Site Active | Near-zero | Near-zero | $$$$ |
|
||||
|
||||
## AWS Multi-Region
|
||||
|
||||
```bash
|
||||
# Cross-region RDS replica
|
||||
aws rds create-db-instance-read-replica \
|
||||
--db-instance-identifier dr-replica \
|
||||
--source-db-instance-identifier prod-db \
|
||||
--source-region us-east-1 \
|
||||
--region us-west-2
|
||||
|
||||
# S3 cross-region replication
|
||||
aws s3api put-bucket-replication \
|
||||
--bucket source-bucket \
|
||||
--replication-configuration file://replication.json
|
||||
```
|
||||
|
||||
## DR Testing
|
||||
|
||||
```yaml
|
||||
dr_test_schedule:
|
||||
tabletop: Quarterly
|
||||
component_failover: Monthly
|
||||
full_failover: Annually
|
||||
|
||||
test_checklist:
|
||||
- [ ] Verify backup integrity
|
||||
- [ ] Test failover procedures
|
||||
- [ ] Validate data consistency
|
||||
- [ ] Measure actual RTO/RPO
|
||||
- [ ] Document lessons learned
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Regular DR testing
|
||||
- Automate failover where possible
|
||||
- Document all procedures
|
||||
- Update runbooks after tests
|
||||
@@ -0,0 +1,90 @@
|
||||
---
|
||||
name: incident-management
|
||||
description: Implement incident management processes and escalation procedures. Configure on-call schedules and post-incident reviews. Use when managing production incidents.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: devops-skills
|
||||
version: "1.0"
|
||||
---
|
||||
|
||||
# Incident Management
|
||||
|
||||
Implement effective incident management processes.
|
||||
|
||||
## Incident Severity
|
||||
|
||||
| Severity | Impact | Response | Example |
|
||||
|----------|--------|----------|---------|
|
||||
| SEV1 | Total outage | Immediate, all-hands | Site down |
|
||||
| SEV2 | Major degradation | Urgent, on-call | Feature broken |
|
||||
| SEV3 | Minor impact | Standard | Slow performance |
|
||||
| SEV4 | Minimal | Next business day | Cosmetic issue |
|
||||
|
||||
## Incident Process
|
||||
|
||||
```yaml
|
||||
incident_workflow:
|
||||
1_detect:
|
||||
- Alerting triggers
|
||||
- Customer reports
|
||||
- Monitoring anomalies
|
||||
|
||||
2_triage:
|
||||
- Severity assessment
|
||||
- Impact determination
|
||||
- Team notification
|
||||
|
||||
3_respond:
|
||||
- Incident commander assigned
|
||||
- Communication established
|
||||
- Mitigation started
|
||||
|
||||
4_resolve:
|
||||
- Root cause addressed
|
||||
- Service restored
|
||||
- Customer notified
|
||||
|
||||
5_review:
|
||||
- Timeline documented
|
||||
- Root cause analysis
|
||||
- Action items created
|
||||
```
|
||||
|
||||
## Incident Commander
|
||||
|
||||
```yaml
|
||||
ic_responsibilities:
|
||||
- Own incident resolution
|
||||
- Coordinate response teams
|
||||
- Manage communication
|
||||
- Make escalation decisions
|
||||
- Schedule post-mortem
|
||||
```
|
||||
|
||||
## Post-Incident Review
|
||||
|
||||
```markdown
|
||||
## Incident Summary
|
||||
- Duration:
|
||||
- Impact:
|
||||
- Severity:
|
||||
|
||||
## Timeline
|
||||
|
||||
## Root Cause
|
||||
|
||||
## What Went Well
|
||||
|
||||
## What Could Be Improved
|
||||
|
||||
## Action Items
|
||||
| Item | Owner | Due Date |
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Clear severity definitions
|
||||
- Defined escalation paths
|
||||
- Blameless post-mortems
|
||||
- Action item tracking
|
||||
- Regular training
|
||||
@@ -0,0 +1,96 @@
|
||||
---
|
||||
name: runbook-creation
|
||||
description: Create operational runbooks and standard operating procedures. Document troubleshooting guides and recovery procedures. Use when documenting operational knowledge.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: devops-skills
|
||||
version: "1.0"
|
||||
---
|
||||
|
||||
# Runbook Creation
|
||||
|
||||
Create effective operational runbooks and procedures.
|
||||
|
||||
## Runbook Structure
|
||||
|
||||
```markdown
|
||||
# Runbook: [Service/Process Name]
|
||||
|
||||
## Overview
|
||||
Brief description of the service and runbook purpose.
|
||||
|
||||
## Prerequisites
|
||||
- Required access
|
||||
- Tools needed
|
||||
- Knowledge required
|
||||
|
||||
## Procedure
|
||||
Step-by-step instructions with commands.
|
||||
|
||||
## Verification
|
||||
How to confirm success.
|
||||
|
||||
## Rollback
|
||||
Steps to undo if needed.
|
||||
|
||||
## Escalation
|
||||
When and how to escalate.
|
||||
|
||||
## Related Runbooks
|
||||
Links to related procedures.
|
||||
```
|
||||
|
||||
## Example Runbook
|
||||
|
||||
```markdown
|
||||
# Runbook: Database Failover
|
||||
|
||||
## Overview
|
||||
Procedure to failover PostgreSQL to replica.
|
||||
|
||||
## Prerequisites
|
||||
- [ ] DBA access to primary and replica
|
||||
- [ ] VPN connected
|
||||
- [ ] Slack channel #db-ops open
|
||||
|
||||
## Procedure
|
||||
|
||||
### 1. Verify Replica Status
|
||||
\`\`\`bash
|
||||
psql -h replica -c "SELECT pg_is_in_recovery();"
|
||||
# Should return 't'
|
||||
\`\`\`
|
||||
|
||||
### 2. Stop Application Writes
|
||||
\`\`\`bash
|
||||
kubectl scale deployment app --replicas=0
|
||||
\`\`\`
|
||||
|
||||
### 3. Promote Replica
|
||||
\`\`\`bash
|
||||
psql -h replica -c "SELECT pg_promote();"
|
||||
\`\`\`
|
||||
|
||||
### 4. Update DNS
|
||||
\`\`\`bash
|
||||
aws route53 change-resource-record-sets ...
|
||||
\`\`\`
|
||||
|
||||
## Verification
|
||||
- [ ] Application connects to new primary
|
||||
- [ ] No replication lag errors
|
||||
- [ ] Transactions completing
|
||||
|
||||
## Escalation
|
||||
If issues persist after 15 minutes, escalate to:
|
||||
- Primary: @dba-lead
|
||||
- Secondary: @platform-oncall
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Keep procedures simple and clear
|
||||
- Include verification steps
|
||||
- Test runbooks regularly
|
||||
- Version control runbooks
|
||||
- Include troubleshooting tips
|
||||
Reference in New Issue
Block a user