Private corporate batches, live online cohorts and 1-on-1 mentoring in service value system, management practices and change enablement for IT service delivery — 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 ITIL as an operating model rather than a glossary: the service value chain and the four dimensions, then the practices that carry real operational weight — incident, problem, change enablement, release, configuration and service level management — worked through against systems that deploy continuously. Twenty years across DevOps, SRE and Security and 10,000+ engineers trained mean the hardest sessions are the honest ones: how to make change enablement work at deployment speed, what a configuration management database can realistically hold in a cloud estate, and where ITIL practice and SRE practice describe the same thing in different words.
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 ITIL that means a trainer who has run it in production — service value system, management practices and change enablement for IT service delivery — 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 ITIL batchITIL is a framework for IT service management — the set of practices an organisation uses to plan, deliver, operate and improve IT services. Its central claim is that IT does not deliver technology, it delivers services, and a service is only valuable when it produces an outcome the consumer wants without imposing costs and risks they have to manage themselves. Everything else in the framework follows from that definition.
The current version, ITIL 4, is organised around a service value system. Demand and opportunity enter, the service value chain converts them into value through six activities — plan, improve, engage, design and transition, obtain and build, deliver and support — and thirty-four management practices supply the specific capabilities those activities draw on. Seven guiding principles cut across all of it, of which 'start where you are', 'progress iteratively with feedback' and 'keep it simple and practical' are the ones most often ignored in implementation. Four dimensions — organisations and people, information and technology, partners and suppliers, and value streams and processes — have to be considered together, because a change to one that ignores the others is how ITIL programmes fail.
In practice most organisations use a working subset: incident, problem and service request management at the service desk; change enablement, release and deployment for controlled delivery; configuration and asset management for knowing what exists; and service level management for defining what good looks like. ITIL 4 differs from earlier versions in explicitly accommodating high-velocity delivery, which is why it appears alongside DevOps and Agile rather than in opposition to them.
Most enterprises run both a service management function and a DevOps delivery pipeline, and the friction between them is expensive. A change advisory board that meets weekly cannot approve twenty deployments a day, so teams either wait or route around the control — and the organisation ends up with worse governance than if the process had been designed honestly in the first place.
That is the live problem. ITIL 4 was written with it in mind: standard changes that are pre-authorised, change enablement rather than change control, and evidence produced by the pipeline rather than by a form. Applying that properly requires someone who understands both sides, and organisations are hiring for exactly that intersection.
There is also a durable operational reason. Incidents, service requests, problems, configuration data and service levels do not disappear because delivery got faster; they get more numerous. Teams that cannot classify an incident, run a problem investigation to a known error, or keep a configuration management database that anyone trusts spend their time re-learning the same outage. ITIL supplies the vocabulary and structure for that work, and it is the vocabulary most large enterprises, auditors and outsourcing contracts already use.
What a service actually is, and why the definition matters commercially. Value, outcomes, costs and risks; the service relationship between provider and consumer; the four dimensions that must be considered together; and the shape of the ITIL 4 service value system and certification scheme.
Topics: Services, products and value co-creation · Outcomes, costs and risks as the definition of value · Service relationships: provider, consumer, sponsor, user · The four dimensions of service management · The ITIL 4 service value system in outline · Utility and warranty · The ITIL 4 certification scheme and where this training sits
The seven guiding principles as decision rules rather than posters, the continual improvement model as a repeatable method, and governance — who decides, who is accountable, and how improvement gets funded when it competes with delivery.
Topics: Focus on value; start where you are; progress iteratively with feedback · Collaborate and promote visibility; think and work holistically · Keep it simple and practical; optimise and automate · The continual improvement model, step by step · The continual improvement register and prioritisation · Governance: direction, monitoring and evaluation · Measurement and reporting that drives behaviour
How demand becomes value. The six value chain activities and how they connect, then value stream mapping applied to real flows — a new service request, an incident, and a code change — to expose hand-offs, queues and rework that no single practice owns.
Topics: Plan, improve and engage · Design and transition; obtain and build; deliver and support · Constructing value streams from the value chain · Mapping a request-to-fulfilment value stream · Mapping an incident-to-resolution value stream · Identifying waste, hand-offs and queues · Where practices attach to value chain activities
The practices that carry daily load. Incident management with real classification and prioritisation, major incident handling, problem management as a distinct discipline that produces known errors and permanent fixes, service request fulfilment, and the service desk as the engagement point rather than a ticket queue.
Topics: Incident management: detection, classification, prioritisation, resolution · Impact and urgency matrices that reflect real business effect · Major incident procedure, escalation and communication · Problem management: investigation, known error, workaround, permanent fix · Proactive problem management from incident trends · Service request management and the request catalogue · Service desk practice, knowledge management and self-service · Monitoring and event management feeding incident records
The control practices, taught for an environment that deploys frequently. Change enablement with standard, normal and emergency paths; the distinction between release and deployment that most organisations conflate; service configuration management; and IT asset management, including what a configuration management database can realistically hold in a cloud estate.
Topics: Change enablement versus old-style change control · Standard, normal and emergency changes; pre-authorisation · Change authority models and replacing the CAB bottleneck · Change schedules, freezes and risk assessment · Release management versus deployment management · Service configuration management and the CMDB · IT asset management and discovery · Keeping configuration data accurate through automation
Defining and defending what good looks like. Service level management and writing agreements on measures customers actually recognise, then availability, capacity and performance management, and service continuity — recovery objectives, testing, and what a plan is worth if it has never been exercised.
Topics: Service level management and the SLA lifecycle · Choosing measures customers recognise, not component metrics · Watermelon reporting and how to avoid it · Availability management and measurement · Capacity and performance management, demand forecasting · Service continuity: RTO, RPO and recovery strategy · Testing continuity plans and recording the result · Supplier management and back-to-back agreements
The integration module, and the one most attendees come for. High-velocity IT, satisfying change governance with pipeline evidence rather than paperwork, mapping ITIL practices onto CI/CD and monitoring tooling, and the substantial overlap between ITIL practice and SRE — SLAs and SLOs, problem management and postmortems.
Topics: High-velocity IT and what ITIL 4 changed · Pre-authorised standard changes for pipeline deployments · Producing audit evidence from pipeline and version control data · Mapping practices to tooling: ServiceNow, Jira Service Management, CI/CD systems · ITIL and SRE: SLA versus SLO, problem management versus postmortems · Incident response: ITIL major incident and SRE incident command compared · Building an operating model that both auditors and engineers accept
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a technical system and rewrite it as a service with outcomes, costs, risks, users and sponsors — then test the definition on someone outside IT.
Map a real incident resolution path across teams and tools, mark every hand-off and queue with its actual wait time, and identify the two changes that would cut the total most.
Replace a technical severity scale with an impact and urgency matrix tied to business effect, then classify twenty real historical tickets against both and compare the results.
Design standard, normal and emergency change paths for a service that deploys daily, define pre-authorisation criteria, and produce the audit evidence automatically from the pipeline.
Analyse a set of recurring incidents, run a structured problem investigation, document the known error and workaround, and build the case for the permanent fix.
Deliver a complete service management design for a single real service: definition, value streams, incident and problem workflows, change model, CMDB scope, SLA and continuity objectives.
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 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.
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 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.