Private corporate batches, live online cohorts and 1-on-1 mentoring in problem framing, approach selection, foundation-model systems, evaluation and AI governance — 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 AI as an engineering discipline rather than a survey: framing a problem so it has a measurable success criterion, choosing honestly between a rule, a classical model and a hosted foundation model, and building the retrieval, tool-calling and guardrail layers around it. Sessions spend as much time on evaluation and failure — hallucination, groundedness, prompt injection, cost per call, regression suites — as on building, because that is what decides whether an AI system survives its first month in production.
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 AI that means a trainer who has run it in production — problem framing, approach selection, foundation-model systems, evaluation and AI governance — 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 AI batchAI is the field concerned with building systems that perform tasks normally associated with human cognition — perceiving, predicting, reasoning over language, generating content and making decisions. It is not one technique. Symbolic systems and search dominated its first decades, statistical learning replaced hand-written rules from the 1990s, deep neural networks made perception and language tractable from the 2010s, and large pretrained foundation models turned much of the field into an integration discipline rather than a training one.
That history matters because it explains what the job looks like now. Most teams building AI today are not training models from scratch. They are choosing between a rule, a classical model, a fine-tuned network and a hosted foundation model; wiring retrieval, tools and structured outputs around it; measuring whether the result is good enough; and deciding what happens when it is confidently wrong. The scarce skill is judgement about which problems are AI problems at all, followed by the engineering to make a probabilistic component behave acceptably inside a deterministic system.
An applied AI practice therefore has three parts that sit outside the model itself. Framing — turning a business objective into a task with a measurable success criterion and a known cost for a wrong answer. Evaluation — offline test sets, human review protocols, groundedness and regression suites, because a demo proves nothing about the tail. And governance — bias, privacy, prompt injection, explainability, documentation and the audit trail that regulation increasingly expects. Those three decide whether an AI project reaches production far more often than the model choice does.
AI moved from research budget to line-of-business budget in the space of a couple of years, and almost every engineering organisation now has projects in flight. The failure rate is high, and the failures cluster in predictable places: a problem that never needed a model, a system with no evaluation harness, a pilot that cannot be costed at scale, or a deployment blocked late by privacy and compliance review.
What has changed technically is the barrier to entry. Capable models are available behind an API, which means the differentiating work has shifted to everything around them — retrieval quality, structured outputs, tool integration, guardrails, evaluation and cost control. Those are ordinary engineering skills applied to an unfamiliar component, which is why platform and application engineers are now the people being asked to deliver AI features.
Regulation has arrived at the same time. Risk-tiered obligations, documentation duties, and the expectation that an organisation can explain and evidence what a system does are now design inputs rather than afterthoughts. Teams that treat governance as an engineering requirement ship; teams that treat it as paperwork stall in review.
A working map of the field so later decisions are informed rather than fashionable. The eras and what each contributed, the difference between AI, machine learning, deep learning and generative AI as terms people misuse daily, and a capability map of what current systems do reliably, unreliably and not at all.
Topics: Symbolic AI, search and expert systems: what survived · Statistical learning and the shift from rules to data · Deep learning and why perception and language became tractable · Foundation models and the shift from training to integration · AI vs ML vs deep learning vs generative AI · A capability map: perception, language, prediction, generation, decisioning · What current systems do reliably and what they do not
The module that prevents most wasted projects. Converting a business objective into a task with a defined input, output, success metric and failure cost; screening for feasibility before any build; establishing the non-AI baseline that must be beaten; and recognising the cases where a rule or a better interface wins.
Topics: From business objective to a solvable task definition · Feasibility screening: data, labels, latency, tolerance for error · Baselines: the rule or heuristic the model must beat · Success metrics and the cost of a wrong answer · Data availability, labelling cost and cold start · Human-in-the-loop as a design choice, not a fallback · When not to use AI
The decision that determines cost, latency and maintenance for the life of the system. Classical models against deep learning against hosted foundation models; prompt, retrieve, fine-tune or train; and the constraints that usually decide it — latency budget, cost per call, data residency, privacy and the skills of the team that will own it.
Topics: Classical ML vs deep learning vs foundation models · Prompting vs retrieval vs fine-tuning vs training from scratch · Hosted API vs self-hosted open-weight models · Latency budgets and throughput requirements · Cost per call and cost at projected volume · Privacy, residency and vendor constraints · Team skills and long-term ownership · A decision framework you can defend in review
The engineering layer around a hosted model. Tokens, context windows and what they cost; prompting patterns that generalise; forcing structured output so downstream code can rely on it; tool and function calling; and retrieval-augmented generation, which is where most real systems spend their effort.
Topics: Tokens, context windows and cost accounting · Prompting patterns: instructions, examples, decomposition · Structured output and schema-constrained generation · Tool and function calling · Embeddings and vector search · Chunking, indexing and retrieval quality · Reranking and grounding answers in sources · Agents, multi-step workflows and their failure modes · Caching, batching and latency management
The discipline that separates a demo from a product. Building an evaluation set that reflects real traffic including the tail; automated scoring and its limits; human review protocols with measurable agreement; and regression suites so a prompt or model change cannot silently degrade quality.
Topics: Building an evaluation set that includes the tail · Task metrics: exact match, similarity, rubric scoring · Model-graded evaluation and its blind spots · Human review protocols and inter-rater agreement · Measuring hallucination and groundedness · Retrieval evaluation separately from generation · Regression suites for prompt and model changes · Online metrics, A/B tests and shadow traffic · Red-teaming and adversarial evaluation
The controls that keep a system deployable. Bias and fairness measured rather than asserted; explainability appropriate to the audience; privacy and personal data handling; the security surface unique to AI systems; and the documentation and approval trail that regulators and internal risk functions now expect.
Topics: Bias and fairness: measuring rather than asserting · Explainability for users, reviewers and regulators · Privacy, personal data and training-data provenance · Prompt injection and indirect prompt injection · Data exfiltration through model outputs and tools · Content safety, abuse and misuse handling · Risk tiers, model cards and system documentation · Risk frameworks and emerging regulatory obligations · Approval workflows and audit evidence
From working prototype to owned service. A reference architecture for AI features, cost and capacity modelling, guardrails and rate limits at the boundary, production monitoring for quality and abuse, the handoff into MLOps, and how to sequence a portfolio so early wins fund the rest.
Topics: Reference architecture for an AI feature · Gateway patterns: routing, fallback, rate limiting, key management · Cost and capacity modelling: API spend vs GPU capacity · Guardrails at input and output boundaries · Production monitoring for quality, drift and abuse · Feedback capture and continuous improvement · The handoff to MLOps for lifecycle ownership · Portfolio sequencing and stakeholder expectations · Team structure and ownership models
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake three proposed AI use cases, build a non-AI baseline for each, and produce evidence for committing to one and stopping the other two.
Build retrieval-augmented generation end to end — chunking, embeddings, vector search, reranking and citation — then measure retrieval and generation quality separately.
Force schema-constrained output, wire tool calling with validation, and handle malformed responses, timeouts and refusals without breaking the caller.
Build a scored evaluation set, add automated and human review, then block a deliberately worse prompt from merging.
Run direct and indirect prompt injection against a tool-enabled assistant, exfiltrate something you should not be able to, then mitigate and retest.
Deliver one AI capability with architecture, gateway and guardrails, evaluation in CI, monitoring, cost model and a system card for governance review.
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.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
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 Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
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.