Private corporate batches, live online cohorts and 1-on-1 mentoring in the three signals, service level objectives, and debugging failures nobody predicted — 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 observability as an engineering practice rather than a product tour: what each of the three signals can and cannot answer, how to instrument once with vendor-neutral libraries and route the output anywhere, and how to write service level objectives and burn-rate alerts that page a human only when users are actually affected. Sessions work through real debugging — starting from a symptom nobody predicted and narrowing it with traces, high-cardinality queries and correlated logs — alongside the part most courses skip entirely: the cardinality, retention and sampling decisions that determine what the whole thing costs.
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 Observability that means a trainer who has run it in production — the three signals, service level objectives, and debugging failures nobody predicted — 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 Observability batchObservability is the property of a system that lets an engineer answer new questions about its behaviour from the outside, without shipping code to answer each one. Monitoring tells you whether the things somebody already thought to check are healthy. Observability is what you need when production fails in a way nobody predicted and the only evidence available is whatever the system was already emitting. The distinction is not marketing — it changes what you instrument, how much detail you keep, and how you query it.
The practice rests on three signals. Metrics are cheap aggregated numbers over time: good for trends, thresholds and capacity, weak at explaining one failed request. Logs are discrete events carrying detail, expensive at volume, and only useful under pressure when they are structured and queryable rather than free-text. Traces follow a single request across every service it touches and are the only signal that answers where the latency actually went in a distributed call graph. None of the three is sufficient alone. The value comes from correlation — a trace identifier carried into log lines, an exemplar linking a latency histogram bucket to the trace that produced it, and consistent resource attributes so that a service name means the same thing in all three.
Above the signals sits the layer that decides whether any of it pays for itself: service level indicators and objectives that define what working means numerically, error budgets that turn reliability into a spending decision rather than an argument, alerts fired on user-visible symptoms instead of on every internal cause, and a deliberate cost model — because metric cardinality, log retention and span sampling are the three levers that make a telemetry bill grow faster than the traffic it describes.
Systems became harder to reason about faster than teams grew. A monolith on a known set of hosts could be understood from a load graph and a log file. A request that crosses a dozen services, a queue, a managed database and two third-party APIs cannot — and the failure modes that matter are increasingly partial: a degraded dependency, one bad pod, a single slow tenant, none of which trip a host-level threshold.
That is why observability is now a named engineering function rather than a side effect of owning monitoring tools. Organisations hire for it because the expensive part is not installing a collector. It is deciding what to instrument, agreeing objectives with the people who own the revenue, keeping instrumentation consistent across teams that deploy independently, and stopping telemetry spend from compounding without anyone noticing.
The skill is also portable in a way product knowledge is not. Vendors change, and most large estates run more than one backend anyway. Engineers who understand signals, cardinality, sampling and error budgets move between platforms without relearning the job; engineers who only know one query language start again every time procurement changes its mind.
The definition, its origin in control theory, and the practical difference from monitoring. Known-unknowns versus unknown-unknowns, why dashboards built after the last incident never catch the next one, and the vocabulary the rest of the course depends on: signal, cardinality, dimensionality, event, sample.
Topics: What is observability, and where the term comes from · Why observability matters — the failures monitoring misses · Monitoring versus observability: a real distinction, not a rebrand · Known-unknowns and unknown-unknowns · Key concepts and terminology: signals, events, cardinality, dimensionality · The three signals and what each one costs · Assessing the observability maturity of an existing estate
The signal every system already emits and almost nobody has under control. Structured versus unstructured logging, what belongs in a log line and what does not, the collection and aggregation path from process to store, and the search and visualisation patterns that make logs usable in the ninth minute of an incident rather than the ninetieth.
Topics: Overview of logging: what logs are good and bad at · Types of logs — application, access, audit, system, security · Structured logging and why free-text costs you an incident · Log collection and aggregation: agents, forwarders, buffering and backpressure · Log analysis and visualisation: search syntax, facets, patterns and aggregation · Log levels, sampling, and deciding what never to emit · Retention tiers, archives and the cost of indexed volume · Sensitive data in logs — redaction and compliance
Aggregated numbers over time: the cheapest signal and the easiest to design badly. Metric types and what each can express, collection models, storage and downsampling, and the query patterns that turn a wall of graphs into an answer. Cardinality is treated as a first-class design constraint from the first exercise.
Topics: Overview of metrics and their place among the signals · Types of metrics — counters, gauges, histograms, summaries · RED and USE method: choosing what to measure for services and resources · Metric collection and storage: pull versus push, scrape intervals, time-series databases · Labels, dimensions and cardinality — the cost model behind metrics · Metric analysis and visualisation: rate, aggregation, percentiles and what averages hide · Downsampling, retention and long-term storage · Naming conventions and metric governance across teams
The signal that answers where the time went. Spans, parents and context propagation across process boundaries, how traces are collected and stored, and how to read a waterfall and a flame graph to find the one call responsible for the tail latency. Then sampling, because keeping every trace at production volume is rarely affordable.
Topics: Overview of tracing and the questions only it can answer · Spans, span context, parents and the trace tree · Types of traces and span kinds — server, client, producer, consumer, internal · Context propagation across HTTP, gRPC and message queues · Trace collection and storage: collectors, pipelines, backends and retention · Trace analysis and visualisation: waterfalls, flame graphs, critical path and service maps · Head sampling versus tail sampling, and probability versus rate limiting · Broken traces: missing parents, orphan spans, and propagation failures
Signals in three separate systems are three separate investigations. This module wires them together: shared resource attributes, trace identifiers injected into log lines, exemplars linking a histogram bucket to a specific trace, and the semantic conventions that make service, environment and version mean the same thing everywhere.
Topics: Resource attributes and semantic conventions as the join key · Injecting trace and span identifiers into structured logs · Exemplars: from a latency bucket to the trace that produced it · Vendor-neutral instrumentation and why it decouples you from a backend · Auto-instrumentation versus manual instrumentation, and the gaps auto leaves · Baggage and propagating business context such as tenant or customer tier · Pivoting during an incident: metric to trace to log without leaving the question
The layer that turns telemetry into decisions. Choosing indicators that reflect user experience rather than server comfort, setting objectives that are achievable and meaningful, computing error budgets over rolling windows, and using budget burn to arbitrate between shipping features and fixing reliability.
Topics: Service level indicators: availability, latency, correctness, freshness · Choosing an SLI from the user's perspective, not the server's · Setting objectives — target, window, and why 100 percent is the wrong number · Error budgets and burn rate · Request-based versus time-based SLO computation · SLOs for asynchronous, batch and data pipelines · Reporting SLO status to engineering and to the business · SLO-driven prioritisation and the error budget policy
Most alerting estates are cause-based, noisy and quietly ignored. This module rebuilds the discipline: symptom-based alerts tied to objectives, multi-window multi-burn-rate rules, correct handling of no-data and flapping, routing and escalation, and what belongs on a page versus a ticket versus a dashboard.
Topics: Overview of alerting and why alert fatigue is a design failure · Types of alerts — threshold, rate of change, anomaly, absence, composite · Symptom-based alerting versus cause-based alerting · Alerting rules and thresholds: evaluation windows, for-durations and hysteresis · Multi-window multi-burn-rate alerting on error budgets · No-data, flapping and dependent alert suppression · Alert notification, routing, grouping and escalation policies · Silences and maintenance windows · Runbooks: what an alert must tell the person it wakes
The skill the whole practice exists for. Working from a vague symptom with no pre-built dashboard: forming and discarding hypotheses quickly, slicing high-cardinality data by attributes nobody thought to graph, isolating one tenant or one build, and knowing when to reach for continuous profiling instead of more telemetry.
Topics: Investigating from a symptom with no prior dashboard · High-cardinality, high-dimensionality querying and why pre-aggregation blocks it · Comparing populations: slow requests versus fast, this version versus last · Isolating by tenant, region, build, feature flag or dependency · Continuous profiling: CPU, memory and lock contention when traces run out · The incident workflow — detect, triage, mitigate, then diagnose · Blameless postmortems and turning findings back into instrumentation
Making it stick across an organisation. Rolling out instrumentation standards without a mandate nobody follows, an honest survey of the open-source and commercial landscape and what each is genuinely good at, build-versus-buy, multi-backend estates, and governing spend before finance does it for you.
Topics: Best practices for implementing observability across many teams · Instrumentation standards, golden paths and platform-provided defaults · Overview of popular observability tools and frameworks, open-source and commercial · Build versus buy, and running more than one backend without duplicating instrumentation · Cost governance: cardinality budgets, log sampling, span retention, tiered storage · Observability for Kubernetes, serverless and managed services you cannot instrument · Case studies: what successful and failed rollouts had in common · Open discussion and estate review
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstrument a running service with structured logs, RED metrics and traces, then answer the same question with each signal and record which one actually could.
Wire trace ID injection, exemplars and consistent resource attributes so a latency spike on a dashboard reaches the exact span and the exact log lines behind it.
Pick a user journey, define the SLI, set a target against real historical data, compute the budget, and add multi-window burn-rate alerts on top.
Audit an alerting configuration, replace cause-based rules with symptom-based ones, add no-data and dependency suppression, and prove coverage with a failure injection.
Investigate a seeded incident with no prebuilt dashboard: narrow it by attribute, isolate the affected population, and identify the responsible code path from telemetry alone.
Assess one production estate, define instrumentation standards, SLO coverage and alerting policy, and produce a staged rollout with a telemetry cost ceiling.
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.
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.
| 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.