Private corporate batches, live online cohorts and 1-on-1 mentoring in running and modernising the estate — builds, identity, patching, backup, capacity, monitoring and the queue — 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 ITOps from the estate outward: standard builds and drift control with Ansible, identity and certificate operations that quietly cause most outages, patch campaigns with a real rollback path, restore testing rather than backup reporting, and capacity work grounded in measured utilisation. The modernisation half is taught the same way — converting a written run book into automation, deflecting a ticket category with self-service, and moving alerting from CPU thresholds to service-level signals — so attendees leave with a sequenced plan rather than an argument for a rewrite.
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 ITOps that means a trainer who has run it in production — running and modernising the estate — builds, identity, patching, backup, capacity, monitoring and the queue — 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 ITOps batchITOps is the function that keeps an organisation's existing IT services running. It owns the estate rather than a product: servers and hypervisors, directory and identity services, DNS, certificates, storage, backup, the network edge, the endpoint fleet, the monitoring stack and the queue of incidents and requests that arrives every morning. Where a product team ships features, ITOps is measured on availability, restore times, patch currency and how quickly the queue clears.
It is the least fashionable part of the field and the largest by headcount, and most estates are hybrid in a way conference talks rarely admit — a cloud footprint growing beside a Windows domain, a virtualisation platform, a decade of applications that were never designed to be redeployed, and a change process built around scheduled downtime. Teaching ITOps honestly means teaching that estate as it is: the operational fundamentals that keep it safe, and the modernisation path that gradually converts hand-run work into code.
That modernisation path is the second half of the subject. Standard builds replace snowflake servers, configuration management replaces the build document, run-book automation replaces the copy-and-paste procedure, self-service replaces a category of tickets entirely, and monitoring moves from CPU thresholds towards signals that indicate a service is actually degraded. Done well, ITOps ends up sharing most of its tooling with platform and site reliability engineering while still owning the parts of the estate nobody else will.
The workload has grown while the operating model has not. Most organisations added cloud accounts, containers, SaaS integrations and remote endpoints without retiring anything, so the same team now maintains more surface with the same headcount and a ticket queue that never empties. The gap gets filled by automation or by unmanaged risk, and the second option has become expensive.
Security is the sharpest driver. Ransomware turned patch currency, privileged access, directory hardening and — above all — tested restores into board-level questions, and they are answered by operations rather than by a security policy. Cyber insurance renewals now ask for evidence of exactly the things ITOps has historically done informally: an accurate asset list, a patch cadence, immutable backups and a proven recovery time.
Careers move the same way. Infrastructure teams are being asked to become platform teams, which means the traditional skill set has to be paired with configuration management, infrastructure as code, pipelines and a service-oriented view of what they run. Engineers who can do both — hold the estate together and systematically automate it away — are the ones organisations promote rather than outsource.
The shape of the function before the tooling. Services versus systems, the estate inventory, the daily queue, on-call and escalation, the relationship with service management and security, and metrics that describe outcomes rather than activity — availability, restore time, patch currency, change failure rate and backlog age.
Topics: Services, systems and the map between them · Asset and configuration data as the foundation of everything else · The operational day: queue, escalation, handover, on-call · Where ITOps meets service management, security and application teams · Outcome metrics: availability, MTTR, restore time, patch currency, change failure rate · Toil, interrupt load and why the backlog never clears · Run books, knowledge and the cost of undocumented work
The platform the services run on. Hypervisor and cloud compute operations, resource allocation and overcommit, storage tiers and their failure characteristics, filesystem and volume management, and the lifecycle work — provisioning, decommissioning and the zombie systems nobody switches off.
Topics: Hypervisor operations, clusters, resource pools and overcommit · Cloud compute alongside on-premises: the hybrid reality · Storage tiers, IOPS, latency and what actually causes application slowness · Volumes, filesystems, snapshots and reclaiming space · Provisioning workflow and decommissioning discipline · Hardware and lifecycle management, warranty and end-of-support tracking · Finding and removing zombie systems
Ending the snowflake server. Golden images and image pipelines, the baseline every system must meet, configuration management to enforce it, drift detection and remediation, and the practical migration from hand-built systems to managed ones without a big-bang rebuild.
Topics: Golden images and image build pipelines · Baseline definition: packages, users, agents, hardening, logging · Configuration management with Ansible against Linux and Windows · Drift detection, check mode and safe remediation · Bringing existing hand-built systems under management · Secrets and credentials in build automation · Windows and Linux baselines side by side
The services that cause outages out of proportion to the attention they get. Directory operations and privileged access, DNS and DHCP, and certificate lifecycle — where an expiry nobody tracked takes down a service that had nothing else wrong with it.
Topics: Directory services operations: Active Directory, Entra ID, LDAP · Privileged access, service accounts and tiered administration · Group policy, drift and the configuration that lives outside your tooling · DNS architecture, resolution failures and change safety · DHCP, addressing and the network dependencies operations owns · Certificate lifecycle: issuance, inventory, expiry monitoring, automated renewal · Time synchronisation and the failures it causes when wrong
Keeping the estate current without breaking it. Patch cadence and staged rings, maintenance windows and the negotiation around them, reboot orchestration for clustered services, emergency patching under a disclosed vulnerability, and the reporting that proves currency to security and audit.
Topics: Patch cadence, rings and pilot groups · Maintenance windows, freeze periods and negotiating both · Reboot orchestration for clusters and dependent services · Emergency patching and out-of-band change · Vulnerability scan output as an operations backlog · Exceptions, compensating controls and their expiry · Patch currency reporting that survives audit
The area most estates fail an honest test on. Designing backup from RPO and RTO rather than from a schedule, immutability and isolation against ransomware, restore testing that includes the application rather than the disk, and DR that has been exercised recently enough for the run book to be true.
Topics: RPO and RTO as design inputs, agreed with the business · Backup topologies, retention and the 3-2-1 principle in a cloud estate · Immutability, air gaps and credential separation for backup systems · Application-consistent backup for databases and clustered services · Restore testing: file, system, application and full-service levels · DR strategy, failover, failback and dependency ordering · Documenting and exercising a recovery plan that stays true
Making the estate observable and the alerts worth reading. Coverage across infrastructure, services and endpoints; moving from threshold alerts on machines towards signals about service health; event correlation and noise reduction; and capacity planning built from measured utilisation and growth rather than guesswork.
Topics: Coverage: infrastructure, services, dependencies and synthetic checks · From CPU thresholds to service-level signals · Alert design: actionability, ownership, routing and escalation · Event correlation, deduplication and maintenance suppression · Log collection and retention for operations rather than security · Dashboards for on-call versus dashboards for reporting · Capacity planning and trend-based forecasting · Performance troubleshooting method under time pressure
Turning the function into something that scales. Converting run books into automation, exposing safe operations as self-service so a ticket category disappears, infrastructure as code across cloud and on-premises, and sequencing a modernisation programme — including the honest transition towards platform and SRE practice and where it does not apply.
Topics: Choosing what to automate: frequency, risk and time saved · Run-book automation with Ansible and Rundeck-style execution · Self-service request fulfilment and ticket deflection · Infrastructure as code for cloud and virtualised on-premises estate · Version control, review and testing for operations code · Toil measurement and reinvesting the time saved · Migration and consolidation programmes without a freeze · The path from ITOps to platform and SRE practice, and its limits
We rebuild the agenda around the tools you actually run.
Request a custom agendaDefine a standard build, enforce it with configuration management across mixed Linux and Windows hosts, then introduce drift and prove detection and safe remediation.
Build a certificate and service-account inventory with expiry alerting, then simulate an expired certificate and follow the failure through DNS, load balancer and application layers.
Run a patch campaign across pilot and production rings with reboot orchestration for a clustered service, verification checks and a rollback you actually execute.
Recover a database-backed service into an isolated environment from backup, time the full restore, and record every undocumented step the run book was missing.
Rebuild alerting for one service around service-level signals, remove threshold noise, and prove with a failure injection that the real failure mode still pages someone.
Take the highest-volume recurring request, automate it end to end with self-service intake and audit trail, and measure the tickets that stop arriving.
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
Helped to understand more on overall DevOps concepts.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
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.
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.
| 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.