Private corporate batches delivered onsite across Mumbai, or live online in IST (UTC+5:30) — taught by a practitioner who runs DevOps 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 DevOps for change-window estates: release engineering around market hours and end-of-day batch, maker-checker approvals enforced inside the pipeline, scripted and rehearsed failover with recovery evidence, segmented pipelines for cardholder-data environments, and concurrency rehearsal for streaming-scale events. Mumbai batches run onsite at the client's own office or live online in IST, and each control is demonstrated by exercising it on a live system rather than describing it.
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 DevOps that means a trainer who has run it in production — release engineering around market hours — maker-checker change, rehearsed failover, cardholder-data pipelines and streaming-scale events — 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.
Onsite delivery in Mumbai runs at your own office, most often in Bandra Kurla Complex, Lower Parel, Andheri East and SEEPZ, Powai, Goregaon, or across the harbour in Airoli, Vashi and Thane; travel within the metropolitan region is included in the quote and outstation travel is itemised. You provide the room, network access and a screen, and the trainer brings the lab, materials, assessment and certificates. Live online delivery runs in IST (UTC+5:30). Batches run 8 to 30 engineers and are usually split into two blocks placed away from month-end, quarter-end and settlement-heavy days, with hands-on failover work kept out of a live change freeze. Quotes are issued in INR with GST applied and purchase orders supported, and the agenda is rebuilt around your change process, data-centre topology and regulatory drivers during a discovery call.
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 DevOps batchDevOps is the practice of making software delivery a continuous, owned flow rather than a hand-off between builders and operators. Mumbai tests that idea against a clock that nobody in engineering controls. Markets open and close at fixed times, settlement runs on a schedule, payment systems are expected to be available continuously, and a media platform's traffic is decided by a fixture list rather than a release plan.
So delivery here is organised around windows. What can be changed while the market is open, what must wait for the close, what has to be finished before an end-of-day batch begins, and what is simply not deployable on a settlement day. A rollback plan is not a formality; it is the thing that gets scrutinised, because the cost of a bad change is measured in transactions rather than page views.
The second characteristic is that the evidence burden is continuous rather than periodic. Financial and payment organisations here work with maker-checker approvals, recovery drills that must be demonstrated rather than asserted, cardholder-data controls that apply to the pipeline as much as to the application, and data-residency expectations that constrain where environments and backups may live. Effective DevOps in Mumbai means shipping frequently inside those constraints, not despite them — which is a design problem long before it is a tooling problem.
Mumbai concentrates the parts of Indian technology where downtime converts directly into money and regulatory attention: exchanges and brokerages, asset managers, private and public sector banks, insurers, payment processors and lending platforms, alongside the country's largest media and streaming operations.
Several pressures are compressing timelines at once. Shorter settlement cycles have reduced the slack in end-of-day processing. Digital payment volumes keep growing, which raises the cost of every minute of degradation. Supervisory expectations around resilience, recovery testing and outsourcing risk mean recovery capability must be demonstrated on a schedule rather than claimed. And streaming platforms now handle concurrency peaks during major sporting events that would have been implausible a few years ago.
The engineers this creates demand for are specific: people who can automate delivery inside change windows, script and rehearse a failover, produce approval and access evidence automatically, and prepare a platform for a concurrency spike with a rehearsed degradation path. That skill set is scarce, and in this city it is the difference between a platform team that ships weekly and one that ships quarterly with an incident each time.
Building a change calendar that reflects reality. Market hours, settlement cycles and end-of-day batch as hard constraints, classifying changes by deployability window, pre-open verification, and freeze periods that do not simply push risk into one weekend.
Topics: Mapping business windows to deployable change classes · Pre-open and post-close verification · End-of-day batch dependencies · Freeze periods and exception handling · Emergency change during a trading day · Communicating a release calendar to the business
Authorisation that the pipeline enforces. Separating who writes, who approves and who deploys, approval records tied to an artefact, emergency change with retrospective authorisation, and access that is time-bound and justified.
Topics: Enforced separation of author, approver and deployer · Approval records attached to an artefact · Emergency change and retrospective authorisation · Time-bound privileged access · Break-glass procedure and its evidence · Periodic access review from real data
Delivery where microseconds are a feature. Reproducible builds with pinned toolchains, host and kernel tuning captured as code, deployment methods that avoid jitter, warm-up and readiness before traffic, and verifying performance has not regressed.
Topics: Reproducible builds and pinned toolchains · Host and kernel tuning captured as code · Deployment strategies that avoid jitter · Warm-up and readiness before traffic · Performance regression testing in the pipeline · Rollback criteria based on latency rather than errors
Recovery treated as an engineering deliverable. Active-passive and active-active topologies, scripted failover and failback, database replication realities, recovery objectives measured rather than asserted, and evidence produced by the drill itself.
Topics: Active-passive and active-active topology trade-offs · Scripted failover and failback · Database replication lag and its consequences · Measuring recovery point and recovery time · What does not fail over cleanly · Evidence produced by a drill
Payments controls applied to delivery. Keeping scope bounded through segmentation, secrets and key handling, image and dependency scanning with documented triage, logging that never captures sensitive values, and evidence assembled for an assessor.
Topics: Segmentation and keeping scope bounded · Secrets, key management and rotation · Scanning with documented triage · Logging without sensitive data · Change and access evidence for an assessor · Separating in-scope and out-of-scope pipelines
Where data may live and what may be copied. Residency constraints on environments and backups, masking before data leaves production, synthetic data where masking is insufficient, environment parity, and refreshing test data on a schedule.
Topics: Residency constraints on environments and backups · Masking before extraction from production · Synthetic data generation where masking is insufficient · Environment parity with production · Scheduled test data refresh · Auditing who accessed production data
Telemetry for systems judged on the tail. Percentile-based objectives instead of averages, distributed tracing across payment and trading flows, reconciliation and business-level alerting, and dashboards designed for a live incident.
Topics: Percentile objectives and tail latency · Distributed tracing across transaction flows · Business-level and reconciliation alerting · Correlating application, network and infrastructure signals · Dashboards designed for incident use · Retention and cost of high-cardinality telemetry
The other Mumbai peak. Preparing for a fixture-driven concurrency spike: load modelling, origin and cache behaviour, autoscaling limits, connection and queue ceilings, degradation ladders agreed with the business, and rapid rollback during an event.
Topics: Modelling concurrency from previous events · Origin, cache and delivery-network behaviour · Autoscaling limits and warm capacity · Connection, queue and downstream ceilings · Degradation ladders agreed in advance · Rollback and pausing releases during an event
We rebuild the agenda around the tools you actually run.
Request a custom agendaClassify changes by deployable window, automate pre-open verification, and execute a release that must complete before the market opens — including the abort criteria.
Enforce approval separation in the pipeline, attempt to self-approve and be refused, then run a break-glass change and produce its full retrospective record.
Script a failover between two sites, execute it under time pressure, fail back, and record recovery point and recovery time as measured numbers rather than targets.
Segment an in-scope deployment path from an out-of-scope one, purge sensitive values from logs, and assemble the change and access evidence an assessor would request.
Replace a production data copy in a lower environment with masked and synthetic data, validate that the tests still mean something, and automate the refresh.
Rehearse a fixture-driven concurrency peak with a change freeze in force, hit a downstream ceiling, degrade in a planned sequence, and write the post-event review.
Mumbai's technology demand is dominated by organisations whose availability is a business and regulatory matter rather than an engineering preference. Exchanges, brokerages and asset managers around Bandra Kurla Complex, private and public sector banks, insurers, payment processors and lending platforms, the technology arms of large conglomerates, and the country's biggest media and streaming operations. Navi Mumbai and Thane add data-centre and back-office capacity, and Powai and Andheri hold a substantial share of product and platform engineering.
What that produces is a delivery problem defined by windows and evidence. Change has to fit around market hours, settlement and end-of-day batch. Approvals follow maker-checker separation, so the pipeline is expected to record who authorised what. Recovery capability is demonstrated on a schedule instead of asserted, which makes scripted, rehearsed failover a recurring engineering deliverable rather than an annual formality. Payment environments push segmentation and evidence requirements into the pipeline itself, and residency expectations constrain where environments, backups and test data may sit. On the media side, the constraint is different but equally unforgiving: a fixture list decides the concurrency peak, and a degradation ladder has to be agreed with the business before the event rather than improvised during it.
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.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
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.
| 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.