Private corporate batches, live online cohorts and 1-on-1 mentoring in service level objectives, error budgets, toil reduction and incident response for production systems — 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 SRE around the two mechanisms that actually change behaviour — service level objectives and error budgets — rather than as a tour of monitoring tools. Sessions cover choosing indicators that reflect user experience, setting objectives that survive contact with a product team, deriving burn-rate alerts that fire early without waking people for nothing, measuring toil so reduction is provable, and running incidents with real command roles and a postmortem that produces owned actions. Twenty years across DevOps, SRE and Security, and 10,000+ engineers trained, inform the operational judgement in the harder modules: what to do when the SLO is unmeetable, and when reliability work is the wrong investment.
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 SRE that means a trainer who has run it in production — service level objectives, error budgets, toil reduction and incident response for production systems — 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 SRE batchSite Reliability Engineering is the practice of running production systems by applying software engineering to operations problems. Instead of staffing reliability with more people doing manual work, an SRE team treats operations as a software problem: if a task is repetitive, manual, automatable and scales linearly with traffic, it is toil, and the response is to engineer it away rather than to schedule it.
The defining mechanism of SRE is the service level objective. A team picks service level indicators that reflect what users actually experience — request success rate, latency at a percentile, freshness of data — sets an objective against each, and derives an error budget from the gap between that objective and one hundred percent. The budget is not a metric to admire; it is a decision rule. While budget remains, the team ships. When it is exhausted, work shifts to reliability until it recovers. That single mechanism converts an argument about whether to release into an arithmetic question.
Around those two ideas sits the rest of the discipline: alerting on symptoms and burn rate rather than on causes, structured incident response with clear command roles, blameless postmortems that produce action items someone owns, capacity planning, release engineering, and deliberate experiments that verify a system fails the way its designers believe it does. SRE overlaps heavily with DevOps but is narrower and more prescriptive — it is one concrete implementation of the same goals, with measurable rules attached.
Availability expectations rose faster than operations headcount. Systems that used to be one application on a handful of servers are now dozens of services with their own dependencies, deploy schedules and failure modes, and the traditional response — hire more operators, add more alerts, add more approval steps — makes reliability worse, not better, because it increases the amount of manual work in the critical path.
SRE is the practice organisations reach for when they realise the problem is structural. It gives them a defensible way to answer questions that otherwise become political: how reliable should this service be, who decides when we stop shipping features, what counts as an incident, and which of the four hundred alerts should ever wake a human. Those answers are what buyers are actually purchasing when they hire an SRE.
The hiring signal is specific. Job specifications ask for engineers who can define SLIs and SLOs from scratch, instrument a service properly, run an incident as commander, write a postmortem that changes something, and cut toil measurably. Very few candidates can do all five, and almost none can do the first without help — which is why the SLO module is where most of this course's value sits.
The origin and the argument. Why applying software engineering to operations produces different outcomes from staffing operations with more people, what the key tenets commit a team to, and an honest comparison with traditional operations and with DevOps — including where SRE is the wrong organisational answer.
Topics: Course overview and objectives · Introducing Site Reliability Engineering · Comparing traditional operations and SRE · Comparing DevOps and SRE · Exploring the key tenets of SRE · Understanding why SRE works · The growth of SRE and its adoption models
Toil has a definition, and it is not 'work I dislike'. Manual, repetitive, automatable, tactical, devoid of enduring value and scaling linearly with service growth. This module makes toil measurable, sets the fifty percent ceiling, and turns reduction into a prioritised engineering backlog rather than an aspiration.
Topics: Understanding toil and its precise definition · Restricting toil to 50% of team time · Identifying and measuring toil · Engineering away toil · Prioritising toil-reduction projects by cost and frequency · Dealing with the remaining toil · The theoretical minimum toil for a service
The core of the discipline. Choosing indicators that reflect what a user experiences rather than what is easy to measure, setting objectives that are neither aspirational nor meaningless, and deriving the error budget that turns reliability into a shared, arithmetic decision.
Topics: Defining service level indicators from user journeys · Availability, latency, throughput, correctness and freshness as SLI classes · Setting service level objectives that survive negotiation · Understanding error budgets and how they are consumed · Percentiles versus averages, and why the mean lies · SLAs versus SLOs versus SLIs · SLO improvement over time
How to page a human only when a human is needed. Monitoring service level indicators, alerting on burn rate rather than on threshold breaches, the difference between symptom and cause alerts, and the alert review practice that keeps a rotation survivable.
Topics: Monitoring service level indicators · Alerting on service level objectives · Multi-window, multi-burn-rate alerts · Symptom-based versus cause-based alerting · The four golden signals; RED and USE methods · Alert fatigue, ticket alerts and pager hygiene · Dashboards that support diagnosis rather than decoration
Instrumentation that answers questions you had not thought to ask. Metrics, logs and traces and what each is genuinely good for, instrumenting a service with OpenTelemetry, and the practical constraints — cardinality, retention and cost — that decide what you can actually keep.
Topics: Metrics, logs and traces: strengths and limits of each · Instrumenting services with OpenTelemetry · Prometheus data model, recording rules and query patterns · Distributed tracing and latency attribution · Cardinality, retention and cost control · Structured logging and correlation identifiers · Exemplars and linking a metric to a trace
Incidents are a process problem more often than a technical one. Command roles and why separating command from hands-on debugging matters, severity definitions, escalation paths, stakeholder communication, and designing an on-call rotation people can sustain for years.
Topics: Incident command roles: commander, operations lead, communications lead · Severity classification and declaration criteria · Escalation paths and paging policy · Stakeholder and customer communication during an incident · Runbooks that are usable at three in the morning · On-call rotation design, compensation and handover · Managing a long-running or multi-team incident
The output of an incident is not a fix, it is a change in the system that produced it. Blameless postmortem practice, building an accurate timeline, distinguishing contributing factors from a single root cause, and writing action items that get done rather than filed.
Topics: Blameless postmortem culture and why blame destroys data · Constructing an accurate incident timeline · Contributing factors versus root cause thinking · Writing action items with owners, dates and acceptance criteria · Incident review meetings that people attend voluntarily · Tracking action-item completion and closing the loop · Aggregate incident analysis across a quarter
Reliability is mostly decided before production. The patterns that determine how a system degrades — retries, timeouts, circuit breakers, load shedding, graceful degradation — plus capacity planning and the release engineering practices that keep change from being the leading cause of incidents.
Topics: Timeouts, retries with exponential backoff and jitter · Circuit breakers and bulkheads · Load shedding and graceful degradation · Capacity planning and demand forecasting · Release engineering: canaries, progressive rollout and rollback · Change as the dominant cause of incidents · Dependency and failure domain analysis
Verifying beliefs about failure, and building the organisational structure that keeps reliability work funded. Chaos experiments and game days, production readiness reviews as an entry gate, and the choice between embedded, central and consulting SRE models — with the error-budget policy that gives the function authority.
Topics: Chaos engineering: hypothesis, blast radius and abort criteria · Running game days and disaster recovery exercises · Production readiness reviews and onboarding criteria · Embedded, centralised and consulting SRE models · Error-budget policy and its enforcement · Handing a service back when it does not meet standards · Measuring the SRE function itself
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a running service, trace one user journey end to end, choose indicators that reflect it, set objectives and compute the resulting error budget in both minutes and failed requests.
Replace a set of threshold alerts with multi-window burn-rate alerts, then replay historical traffic to check what each configuration would have paged for and what it would have missed.
Inventory and classify a team's operational work, quantify hours per week, automate the highest-cost item and prove the reduction with the same measurement.
Run a simulated multi-service outage with assigned command, operations and communications roles, real timers, escalation and stakeholder updates — then debrief on what the process cost.
Design a chaos experiment with a hypothesis and abort criteria, inject dependency latency and failure, and record where the system degraded gracefully and where it collapsed.
Deliver SLIs, SLOs, error-budget policy, alerting rules, dashboards, runbook and production readiness review for a single service, and defend each choice.
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
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Good discussion, helped us to understand different tools in SRE.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
| 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.