Course Outline
Day 1 — Foundations: ITIL-Aligned Operations & Advanced OS Troubleshooting
Banking scenario thread: A branch-facing application is intermittently slow during peak teller hours; helpdesk tickets are rising but no single team can explain why.
Module 1.1 — ITIL-Aligned Operational Support in Banking (Theory + Workshop)
- Incident, problem, change, and event management in a regulated environment: roles, SLAs/OLAs, escalation paths, major incident management (P1/P2 process, bridge calls, communication cadence)
- Distinguishing incident vs. problem vs. known error; building a proper Root Cause Analysis (RCA) / Post-Incident Review (PIR) document
- Change and release considerations for banking systems: change freezes, CAB, rollback planning, segregation of duties
- Workshop: Participants run a mock major-incident bridge call using a scripted banking outage; produce a PIR using a bank-style template
Module 1.2 — Advanced Linux Troubleshooting
- Systematic troubleshooting methodology (USE method: Utilization, Saturation, Errors)
- CPU, memory, disk I/O, and network diagnostics: top/htop, vmstat, iostat, sar, pidstat, ss/netstat, strace/ltrace, perf
- Systemd service failures, boot issues, and kernel log analysis (journalctl, dmesg)
- Filesystem and storage troubleshooting: inode exhaustion, LVM issues, disk latency
Lab 1.2: Diagnose a simulated Linux application server exhibiting high load average with low CPU usage (I/O wait / disk contention scenario) using a provided broken VM
Module 1.3 — Advanced Windows Server Troubleshooting
- Event Viewer deep-dive, Performance Monitor (PerfMon) counters, Resource Monitor
- Service and process troubleshooting, WMI queries, Get-WinEvent/PowerShell diagnostics
- Common enterprise issues: DNS/AD authentication failures, disk queue length, memory leaks, scheduled task failures
Lab 1.3: Root-cause a Windows application server experiencing periodic slowdowns tied to a runaway process and disk queuing, using PerfMon + Event Viewer + PowerShell
- Combined Linux + Windows + ITIL scenario: participants triage a multi-tier banking app incident, classify it correctly (incident vs. problem), gather evidence from both OS layers, and produce an initial incident timeline.
Day 2 — Database Troubleshooting & Performance Analysis (Oracle & MySQL)
Banking scenario thread: End-of-day (EOD) batch processing is overrunning its window, risking downstream reconciliation and regulatory reporting deadlines.
Module 2.1 — Oracle Troubleshooting & Performance Analysis
- Oracle architecture refresher for troubleshooting purposes (SGA/PGA, redo, undo, listener)
- Diagnosing performance issues using AWR, ASH, and ADDM reports; identifying top wait events
- Lock contention, blocking sessions, and deadlock analysis (v$session, v$lock, v$sql)
- Tablespace, redo log, and archiver issues; alert log analysis
- Query tuning fundamentals: execution plans, indexing strategy, stats gathering
Lab 2.1: Given an AWR report and a blocked-session scenario from a simulated core banking schema, identify the top wait event and blocking session, and propose a fix
Module 2.2 — MySQL Troubleshooting & Performance Analysis
- MySQL architecture for troubleshooting (InnoDB buffer pool, redo log, replication threads)
- Performance Schema and sys schema for diagnosis; slow query log analysis
- EXPLAIN/EXPLAIN ANALYZE, index strategy, and query optimization
- Replication lag diagnosis and common failure modes (master/replica) relevant to reporting/DR databases
- Lock contention and deadlock diagnosis (SHOW ENGINE INNODB STATUS)
Lab 2.2: Diagnose a MySQL replica lagging behind primary during a simulated batch load, using Performance Schema and replication status commands
Module 2.3 — Cross-Layer Performance Analysis Workshop
- Connecting OS-level symptoms (Day 1) to database-level root causes: disk I/O bottlenecks manifesting as slow queries, memory pressure causing swap and DB instability
- Structured performance triage checklist for banking transaction processing systems
Lab 2.3: End-to-end diagnosis of the EOD batch overrun scenario — participants trace the issue from application logs → OS resource contention → Oracle/MySQL wait events, and document findings in an RCA format
Day 3 — Monitoring, Observability, Log & Event Correlation
Banking scenario thread: A card payment switch experiences elevated transaction failures for 12 minutes; multiple monitoring tools fired hundreds of alerts, but nobody detected the true root cause quickly.
Module 3.1 — From Monitoring to Observability
- Monitoring vs. observability vs. AIOps — where each fits in a banking operations model
- The three pillars: metrics, logs, and traces; when to use each
- SRE fundamentals: SLIs, SLOs, error budgets, and how they apply to banking transaction platforms (e.g. availability of a payments API)
- Designing meaningful dashboards and alerts (avoiding alert fatigue) — golden signals: latency, traffic, errors, saturation
Module 3.2 — Metrics & Dashboards Lab (Prometheus + Grafana)
- Instrumenting/collecting OS, application, and database metrics
- Building SLO-based dashboards and multi-window burn-rate alerts
Lab 3.2: Build a Grafana dashboard exposing golden signals for a simulated payments service, and configure an alert that avoids false positives during normal batch spikes
Module 3.3 — Log Aggregation & Event Correlation (ELK/OpenSearch or Splunk)
- Centralised logging architecture for hybrid Linux/Windows/DB estates
- Structuring and correlating logs across application, OS, and database tiers using correlation IDs and timestamps
- Event correlation techniques: deduplication, suppression, topology-based correlation
Lab 3.3: Given raw logs from application, OS, and database layers for the card payment switch incident, correlate events by timestamp/transaction ID to reconstruct the failure sequence
- Participants receive a flood of ~50 simulated alerts from the payment switch incident and must use correlation techniques (manual, then AIOps-assisted in Day 5 for comparison) to identify the true root cause versus noise.
Day 4 — Automation for Operations & SRE Practices
Banking scenario thread: Repetitive manual health-checks and restarts are consuming L2 support capacity; audit requires evidence that changes/remediations are consistent and logged.
Module 4.1 — Automation Foundations for SysAdmins
- Scripting for diagnostics and remediation: Bash and PowerShell patterns for health checks, log collection, and safe auto-remediation
- Idempotency, error handling, and safe rollback in automation — critical for banking change control
- Introduction to configuration management and orchestration with Ansible: playbooks, roles, inventory for mixed Linux/Windows estates
Module 4.2 — Building Runbooks & Auto-Remediation
- Converting tribal knowledge into automated, auditable runbooks
- Triggered remediation patterns: restart-with-guardrails, self-healing scripts, safe circuit-breakers
- Integrating automation with ITSM (auto-ticket creation/update, approval gates for regulated changes)
Lab 4.1: Write an Ansible playbook that detects a specific service failure condition (from Day 1/2 scenarios) across a fleet of Linux and Windows hosts, applies a safe remediation, and logs the action for audit purposes
Module 4.3 — Toward Self-Service & ChatOps
- ChatOps concepts for banking operations (approval-gated automation triggered from chat/ITSM)
- Reporting automation: auto-generating incident timelines and RCA drafts from logs/metrics
Lab 4.2: Automate generation of a basic incident timeline report from correlated log data (from Day 3 lab) using a script
Day 5 — AIOps: Anomaly Detection, AI-Assisted RCA & Proactive Operations
Banking scenario thread: Full capstone — a multi-layered incident (network + OS + database + application) unfolds during a simulated banking peak period (e.g. month-end salary run), and teams must use AIOps tooling to detect it before customers are impacted.
Module 5.1 — AIOps Concepts & Landscape
- What AIOps actually does: anomaly detection, event correlation/noise reduction, causal/topology-based RCA, predictive capacity/performance analysis
- Machine learning basics relevant to ops: baselining "normal" behaviour, seasonality (e.g. month-end banking spikes), and detecting deviation without static thresholds
- Where AIOps fits alongside traditional monitoring and ITSM — augmenting, not replacing, human judgement
- Data quality and governance considerations for AI in a banking environment (explainability, auditability, model bias, data residency)
Module 5.2 — Anomaly Detection & Noise Reduction Lab
- Configuring anomaly detection on key metrics (transaction latency, error rate, batch duration) instead of static thresholds
- Alert correlation and de-duplication using an AIOps-capable platform to collapse hundreds of alerts into a single actionable incident
Lab 5.1: Re-run the Day 3 "alert flood" scenario through an AIOps correlation engine and compare time-to-identify-root-cause vs. the manual approach
Module 5.3 — AI-Assisted Root Cause Analysis
- Using topology/dependency mapping plus AI correlation to pinpoint probable root cause across app/OS/DB layers
- Using generative AI assistants to summarise logs, draft RCA narratives, and suggest remediation options (with human validation as a control)
- Practical guardrails: keeping a human-in-the-loop for any customer-impacting or regulatory-relevant decision
Lab 5.2: Given the capstone multi-layer incident, use the AIOps platform's correlation/RCA view plus an AI assistant to draft a full incident report in under 30 minutes
Module 5.4 — Proactive Operations & Measuring Efficiency
- From reactive to proactive: predictive alerting, capacity trend analysis, and pre-emptive remediation
- Metrics that matter to management/audit: MTTD, MTTR, alert-to-incident ratio, automation coverage, SLO attainment
- Building a roadmap: how this team embeds observability + AIOps into existing ITIL processes going forward
Requirements
Working knowledge of Linux and Windows administration, basic SQL, and exposure to an ITSM tool (ServiceNow, BMC Remedy, etc.)
