Private corporate batches, live online cohorts and 1-on-1 mentoring in telemetry correlation, anomaly detection, alert noise reduction and closed-loop remediation — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches AIOps from the data model up rather than from a vendor console: normalising metrics, logs, traces, events and topology into one schema, choosing detectors that match the signal, and measuring correlation quality with precision and recall instead of a marketing figure. Sessions cover the operational reality — event storms, seasonality, cardinality and cost, feedback loops from resolved incidents, and the guardrails that make automated remediation safe enough to enable.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For AIOps that means a trainer who has run it in production — telemetry correlation, anomaly detection, alert noise reduction and closed-loop remediation — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private AIOps batchAIOps applies statistics and machine learning to operational telemetry so that machines do the first pass of triage instead of people. The problem it addresses is arithmetic: a mid-sized estate emits millions of metric series, tens of terabytes of logs and thousands of events a day, and a single failure fans out into hundreds of alerts across every dependent service. No rota reads that. AIOps sits between raw telemetry and the on-call engineer, compressing event storms into a small number of ranked, enriched incidents.
A working AIOps capability has four layers. Ingestion and normalisation bring metrics, logs, traces, events, deployment records and topology into a common schema with reconciled timestamps and entity identifiers. Detection replaces static thresholds with baselines that understand seasonality and trend, so a Monday-morning spike is not an incident and a flat line at 3am is. Correlation groups related signals by time, topology and change, collapsing an event storm into one incident with a probable cause. Action closes the loop: enrichment into the ITSM and on-call systems, and where it is safe, automated remediation with guardrails.
AIOps is not a replacement for observability, and it is not a product you install. It is a data and operating-model problem. Correlation is only as good as the topology and change data feeding it, detectors need labelled feedback from the humans who resolve incidents, and any automated action needs the same review, testing and rollback discipline as production code.
Alert fatigue is now the dominant operational failure mode. Estates grew microservices, multi-cloud accounts and Kubernetes clusters faster than teams grew, and the monitoring that came with them was configured one threshold at a time. The result is a pager that fires constantly and gets ignored precisely when it matters.
At the same time, the tooling stopped being experimental. Anomaly detection, event correlation and change-impact analysis are shipping features in Dynatrace, Datadog, Splunk, Elastic and New Relic, and dedicated correlation platforms sit in front of them. That makes the scarce skill evaluation rather than novelty: knowing which detector suits which signal, how to measure noise reduction honestly, how to avoid a correlation engine that confidently groups unrelated failures, and when a deterministic rule is simply better than a model.
The commercial pressure is direct. MTTR, change failure rate and toil are reported metrics in most engineering organisations, and headcount is not growing to match incident volume. Teams that can reduce alert-to-incident ratio and automate the safe remediations get the time back; teams that buy a platform without owning the data model get an expensive second inbox.
The problem before the platform. Where alert volume comes from, why threshold tuning does not scale, and what actually consumes on-call time. AIOps positioned against monitoring, observability and event management, with an honest account of where machine learning helps operations and where a deterministic rule is better.
Topics: Alert fatigue, event storms and toil as measurable problems · AIOps vs monitoring vs observability vs event management · The capability model: observe, engage, act · Where ML helps operations and where it does not · Reactive, proactive and predictive use cases · Baseline metrics: MTTD, MTTA, MTTR, alert-to-incident ratio · Common failure patterns in AIOps adoption
Everything downstream depends on this module. Bringing metrics, logs, traces, events, deployment records and service topology into one schema with reconciled entity identifiers and timestamps, then dealing with the practical constraints: cardinality, sampling, retention and cost.
Topics: Signal types: metrics, logs, traces, events, topology · OpenTelemetry as a collection standard · A common event schema and entity resolution · Service maps, dependency graphs and CMDB data · Change and deployment feeds as first-class telemetry · Cardinality, sampling, retention and storage cost · Clock skew, late arrival and out-of-order data
Replacing fixed thresholds with detection that understands how a signal actually behaves. Seasonality and trend, baselining, statistical detectors and where model-based detection earns its keep — plus the tuning question every detector poses: how much noise you accept to catch how much signal.
Topics: Why static thresholds fail on seasonal workloads · Trend and seasonality decomposition · Moving averages, EWMA and Holt-Winters baselines · Forecast residuals and confidence bands · Outlier and multivariate detection · Precision, recall and the cost of a false positive at 3am · Capacity forecasting and predictive alerts · Detector selection per signal class
Turning volume into structure. Parsing and templating unstructured logs so patterns can be counted, clustering to surface rare and new messages, then correlation: deduplication, suppression, and grouping events by time, topology and change into a single incident.
Topics: Log parsing and template extraction · Clustering and rare-pattern detection · Deduplication and flap suppression · Time-window correlation · Topology-based correlation across dependencies · Change-based correlation · Incident grouping and alert-to-incident compression · Measuring noise reduction honestly
Getting the responder from page to cause. Using the dependency graph to find the origin of a fan-out failure, ranking probable causes against recent changes, estimating blast radius, and pushing all of that context into the tools the responder already has open.
Topics: Fan-out failures and locating the origin service · Change correlation: deploys, config, feature flags, infrastructure · Probable-cause ranking and evidence presentation · Blast radius and impacted-service estimation · Enrichment into ITSM: ServiceNow and Jira · On-call routing: PagerDuty and Opsgenie · Runbook linking and automatic context attachment · Post-incident feedback as training signal
Acting on the signal. Which failure classes are safe to remediate automatically and which are not, how to build actions that are idempotent and reversible, and the guardrails — rate limits, approvals, dry runs, circuit breakers — that keep automation from amplifying an incident.
Topics: Classifying failures by automation safety · Runbook automation and self-healing patterns · Idempotency, dry runs and rollback in remediation actions · Guardrails: rate limits, blast-radius caps, circuit breakers · Approval gates and human-in-the-loop actions · Auditing automated actions · Measuring toil removed and incidents auto-resolved · When automation makes an incident worse
Deciding what to buy, what to build and how to introduce it. Capability comparison across the main platforms against your own data rather than a demo dataset, the operating model that keeps detectors improving, governance of the models involved, and a staged adoption plan with metrics attached.
Topics: Platform capabilities: Dynatrace, Datadog, Splunk, Elastic, New Relic · Dedicated correlation and event-management platforms · Build vs buy and total cost of ownership · Running a proof of value on your own telemetry · Feedback and labelling loops from resolved incidents · Model governance, drift and periodic re-evaluation · KPIs and reporting to leadership · A 30/60/90 adoption roadmap
We rebuild the agenda around the tools you actually run.
Request a custom agendaNormalise metric alerts, log alerts, synthetic checks and deployment events into a single event schema with consistent entity identifiers and timestamps.
Take an alert that fires every Monday morning, replace it with a seasonal baseline, and prove it still catches the real regressions it was meant to catch.
Feed a recorded multi-service outage through deduplication, suppression and topology correlation, then measure the alert-to-incident compression ratio.
Join incident timelines against deployment and config-change feeds, rank probable causes, and check the ranking against what actually broke.
Automate a recurring remediation with dry-run, idempotency, rate limiting and an audit trail, then deliberately trigger the guardrails.
Deliver a working loop that detects an anomaly, groups the resulting events, enriches the incident with ownership and change context, and remediates safely.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.