Private corporate batches delivered onsite across Kolkata, 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 delivery and support organisations: measuring toil and automating the top sources of it, modernising overnight batch and file-transfer chains into observable, restartable workflows, making runbooks executable, and building an onboarding path that takes a new engineer from supervised work to ownership. Kolkata batches run onsite at the client's office or live online in IST, scheduled around shift rosters so night-support engineers are not excluded.
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 — turning support organisations into delivery organisations — batch modernisation, toil reduction and onboarding engineers at scale — 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 Kolkata runs at your own office, most often in Salt Lake Sector V, New Town and Rajarhat, the Bantala IT corridor, Bidhannagar or the Park Street and Camac Street offices, with travel within the city included in the quote and outstation travel itemised. You provide the room, network access and a screen; the trainer brings the lab, materials, assessment and certificates. Live online delivery runs in IST (UTC+5:30), and where a team covers client hours in other timezones we run a repeat sitting so night-support engineers are not excluded — two blocks across a fortnight is the usual shape. Batches run 8 to 30 engineers, quotes are issued in INR with GST applied and purchase orders supported, and the agenda is rebuilt around your supported systems, scheduler and client constraints 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 the building and the running of software a single accountable flow. Kolkata approaches that from an unusual starting point, because much of the engineering employment here sits in delivery and support organisations: application maintenance for clients elsewhere, back-office and batch systems for banks and insurers, state and public-sector programmes, and large graduate-hiring pipelines that add hundreds of new engineers a year.
In those organisations the work does not begin as a green-field pipeline. It begins as a queue. Tickets, scheduled jobs that fail overnight, file transfers that must complete before a cut-off, manual steps documented in a spreadsheet, and a shift roster covering clients in other timezones. DevOps here means converting that queue into engineering: identifying the toil, automating the top few sources of it, and shifting the team's identity from responding to owning.
The technical content is standard — version control, continuous integration, configuration as code, containers, monitoring and orchestration — but the framing is different. The highest-value work is usually modernising batch and file-based integration, making runbooks executable rather than descriptive, and building an onboarding path good enough that a new joiner is productive in weeks rather than quarters. Those changes are measurable, and they are what earns a delivery organisation the right to take on more valuable work.
Kolkata's technology employers are competing for work that no longer rewards headcount alone. Application-maintenance and back-office contracts are increasingly priced and reviewed on outcomes — throughput, stability, incident volume, automation coverage — rather than on the number of people assigned. Meanwhile the systems being supported are ageing: overnight batch chains, file-based interfaces, and integrations that predate the teams maintaining them.
That combination makes automation the survival skill rather than a career upgrade. A team that can turn its top five recurring tickets into automation, make a batch chain observable and restartable, and demonstrate the improvement in a client review is a team that keeps and grows the account.
The second driver is intake. The city's graduate-hiring pipeline is large, so organisations continually onboard engineers who need a paved path — a standard toolchain, a sandbox they can safely break, and a defined progression from supervised work to ownership. Building that path is itself an engineering problem, and it is the second most common reason a private batch gets booked here.
The transition that defines this work. Measuring toil, classifying tickets by cause rather than symptom, choosing what to automate first, and shifting a team from responding to incidents towards owning the systems that cause them.
Topics: Measuring toil and repetitive work · Classifying tickets by root cause · Selecting automation targets by return · Ownership models for supported systems · Making improvement work visible against ticket load · Setting expectations with the client or business
Bringing scripts, configuration and runbooks under control when the current practice is editing files directly on servers. Repository structure, review that adds value without stalling delivery, and migrating live scripts without breaking production.
Topics: Repository structure for operational code · Migrating scripts off servers into version control · Review practice for operational changes · Secrets accidentally committed, and their removal · Branching for a support team · Building reviewer capacity in a growing team
The work that pays for itself fastest here. Replacing scattered scheduled jobs with an orchestrator, making steps idempotent and restartable, managed file transfers with verification, dependency-aware scheduling, and cut-off times treated as service objectives.
Topics: From scattered cron jobs to an orchestrator · Idempotent, restartable job design · Dependency-aware scheduling and back-fill · File transfer with verification and retry · Cut-off times as service objectives · Alerting on a job that did not run at all
Turning documents into automation. Codifying recovery procedures, safety checks and confirmation prompts, automating the standard responses to known alerts, and keeping automation trustworthy when the system beneath it changes.
Topics: Codifying a recovery procedure · Safety checks, dry runs and confirmations · Automated response to known alerts · Keeping automation valid as systems change · Access control for operational automation · Recording what automation did and why
Working in an estate you do not own. Adapting to the client's CI system, access model and change process, keeping your own standards portable, negotiating what you can automate, and leaving artefacts the client can maintain after handover.
Topics: Adapting to a client-owned CI and change process · Portable automation across different toolchains · Access constraints and what they rule out · Negotiating automation scope with a client · Documentation the client will actually keep · Handover and knowledge transfer
Operations across timezones. Monitoring that separates expected failures from genuine incidents, routing by shift, structured handover between shifts, escalation to client teams, and incident review that changes something.
Topics: Signals that distinguish incident from noise · Alert routing across a shift roster · Structured shift handover · Escalation to client and vendor teams · Incident review and corrective actions · Tracking recurring incidents to elimination
The second half of this city's problem. A sandbox where new joiners can break things safely, a golden path from first commit to first supervised deployment, mentoring structure, and a readiness checkpoint that means something.
Topics: Sandbox environments for new joiners · A golden path from first commit to first deploy · Pairing and mentoring structure · Readiness checkpoints and what they assess · Common failure modes in large intakes · Keeping onboarding material current
Proving improvement to somebody sceptical. Baselining delivery and reliability metrics, automation coverage, tracking incident and toil reduction, presenting honestly including regressions, and avoiding measures that invite gaming.
Topics: Baselining delivery and reliability metrics · Automation coverage as a measure · Toil and incident reduction over time · Presenting regressions honestly · Metrics that invite gaming, and their replacements · Reporting cadence for a client review
We rebuild the agenda around the tools you actually run.
Request a custom agendaClassify a month of tickets by cause, pick the highest-volume repetitive task, automate it with safety checks, and measure the hours returned to the team.
Convert a set of scheduled jobs into an orchestrated workflow with dependencies, make a mid-chain failure restartable without duplication, and alert on a job that never started.
Take a written recovery runbook, codify it with dry-run and confirmation safeguards, then have someone unfamiliar with the system execute it successfully.
Build automation in one CI system, then port it to another with different access constraints, and write the handover documentation a client would keep.
Build a sandbox and a golden path, then run a new engineer through it end to end and time how long the first supervised deployment takes.
Take one supported system from baseline to measurable improvement: toil automated, batch chain modernised, alerts rationalised, and a review pack backed by data.
Engineering employment in Kolkata is concentrated in delivery and support organisations rather than product companies. Application-maintenance and infrastructure-support organisations serving clients in other timezones, back-office and batch processing for banks and insurers, state government and public-sector programmes, engineering and project-services firms, and a steady flow of graduate hires from the region's engineering colleges. The estates being supported skew older than in newer technology markets, which is precisely why the automation opportunity is large.
That shapes what a training engagement here is asked to achieve. The recurring requests are modernising overnight batch chains and file-based interfaces so they are observable and restartable, converting repetitive tickets into automation that a night-shift engineer can trust, introducing version control to teams that have historically edited scripts directly on servers, and building an onboarding path that takes a large intake of new engineers to productive ownership quickly. Because much of the work happens inside client-owned toolchains, portability matters more than tool preference: whatever is built has to survive a change of client CI system or a handover at contract end. Delivery scheduling has to accommodate shift rosters, and cost sensitivity is real, so the agenda is judged on what it demonstrably removes from the team's workload.
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.