Private corporate batches, live online cohorts and 1-on-1 mentoring in processes, scheduling, virtual memory, filesystems and the I/O path — the layer every production incident eventually reaches — 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 operating systems as diagnostic equipment rather than as theory: the process and thread model and what a scheduler run queue means for tail latency, virtual memory and page cache behaviour under pressure including the out-of-memory killer, the storage path from write syscall through page cache and journal to device, interrupts and the I/O completion path, and the namespace, cgroup and capability primitives that containers are built from. Every concept is demonstrated by measurement on a live system with strace, perf, ftrace, /proc and the standard performance tools, then confirmed by deliberately inducing the failure it predicts.
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 Operating Systems that means a trainer who has run it in production — processes, scheduling, virtual memory, filesystems and the I/O path — the layer every production incident eventually reaches — 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 Operating Systems batchAn operating system is the program that owns the hardware and rents it out. It multiplexes a small number of processors across many runnable threads, gives every process a private address space that is larger than the memory actually installed, turns spinning or flash storage into named files with permissions, mediates every device through drivers, and exposes the whole arrangement to applications through a few hundred system calls. Between an application and the machine there is always an operating system deciding what actually happens.
The abstractions are what make the subject worth learning. A process is an address space plus one or more threads plus a set of open handles. A scheduler decides which thread runs next, and its policy determines whether a system feels fast or merely busy. Virtual memory, page tables and the memory management unit create the illusion of contiguous private memory, backed by demand paging, page cache and eviction. Filesystems layer naming, allocation, journalling and caching over block devices. Interrupts, DMA and device drivers move data without the processor copying every byte. Concurrency primitives — locks, semaphores, condition variables, atomics — exist because those shared resources are contended, and deadlock, priority inversion and lock convoys are the failure modes that follow.
All of it is directly operational. Operating systems knowledge is what turns "the server is slow" into a specific answer: a run queue that is saturated, a working set that no longer fits in memory, a filesystem journal flushing synchronously, a process blocked in uninterruptible sleep on a device that is not responding. Linux, Windows and the BSDs differ in implementation and terminology, but the concepts transfer, and containers and virtual machines are themselves nothing more than operating system mechanisms — namespaces and cgroups in one case, hardware-assisted privilege separation in the other.
Abstractions have moved upward and the failures have not. Engineers work in managed services, containers and frameworks, and then hit a problem that only makes sense one or two layers down — a container throttled by a cgroup quota, a pod killed by the out-of-memory killer, a database stalling on a synchronous write, a service whose tail latency is entirely scheduler queuing. Without operating systems fundamentals those look like mysteries; with them they are diagnosable in minutes.
The demand shows up in three roles particularly. Site reliability engineers are hired substantially on their ability to reason about system-level behaviour under load. Performance engineers work almost entirely at this layer. And platform engineers building on Kubernetes are, whether they describe it that way or not, configuring operating system primitives — namespaces, cgroups, capabilities, seccomp filters, page cache behaviour — through a YAML interface.
There is also a security argument. Privilege boundaries, isolation guarantees, capability models and the syscall surface are operating system concepts, and container escape, privilege escalation and side-channel issues are only comprehensible in those terms. Teams that cannot reason about the kernel boundary cannot reason about what their isolation actually guarantees.
The boundary and the contract. Kernel and user mode, privilege levels, the system call interface and its cost, monolithic versus microkernel design, and how Linux, Windows and the BSDs made different choices around the same problems.
Topics: Kernel mode, user mode and privilege levels · System calls: mechanism, cost and the libc wrapper · Monolithic, microkernel and hybrid designs · Kernel modules, drivers and extending the kernel · Linux, Windows and BSD compared on structure and terminology · The /proc and /sys interfaces as a window into the kernel · Tracing a system call with strace and understanding the output
How work gets onto a processor. Process creation and address spaces, threads and context switching, the run queue, scheduling classes and priorities, preemption, affinity and NUMA placement, and the direct relationship between queueing at the scheduler and tail latency in a service.
Topics: Process creation: fork, exec, clone and process trees · Threads, context switching and its measurable cost · Run queues, load average and what it actually measures · Scheduling classes: fair, real-time, deadline and batch · Priorities, nice values and preemption · CPU affinity, isolation and NUMA placement · Signals, process states and uninterruptible sleep · Connecting run queue latency to service tail latency
Why shared state is hard and how the operating system helps. Race conditions and atomicity, mutexes, spinlocks, semaphores and condition variables, the memory model and barriers, then the classic failure modes — deadlock, livelock, priority inversion and lock convoys — and how each appears in production.
Topics: Race conditions, critical sections and atomicity · Mutexes, spinlocks and when each is appropriate · Semaphores, condition variables and futexes · Reader-writer locks and lock granularity · Memory ordering and barriers · Deadlock: conditions, prevention, detection and recovery · Priority inversion, lock convoys and thundering herds · Diagnosing contention with profiling and lock statistics
The subsystem behind most production surprises. Address spaces and page tables, the memory management unit and translation lookaside buffer, demand paging and page faults, page cache and dirty writeback, swap, working sets, memory-mapped files, and the out-of-memory killer's selection logic.
Topics: Virtual address spaces, page tables and the MMU · TLB, huge pages and translation cost · Demand paging, minor and major page faults · Page cache, dirty pages and writeback · Swap, reclaim and pressure signals · Resident set, virtual size, shared pages and why totals never add up · Memory-mapped files and copy-on-write · The out-of-memory killer: scoring and what it chooses · Allocators, fragmentation and leaks
From a write call to durable bytes. The virtual filesystem layer and inodes, directory structure and links, allocation and extents, journalling and crash consistency, what fsync guarantees and what it costs, plus the layers below — logical volumes, RAID and the block scheduler.
Topics: The virtual filesystem layer, inodes and dentries · Hard links, symbolic links and file descriptors · Allocation, extents, fragmentation and free-space management · Journalling modes and crash consistency guarantees · fsync, fdatasync, write barriers and their real cost · Copy-on-write filesystems and snapshots · Volume management, RAID and the block layer · Block I/O schedulers and queue depth · Network and distributed filesystems, briefly
How data actually moves. Device drivers and the device model, interrupts, interrupt coalescing and softirqs, direct memory access, polling versus interrupt-driven I/O, blocking, non-blocking and asynchronous models, and the full network receive path from wire to application buffer.
Topics: Device model, drivers and hotplug · Interrupts, interrupt handlers, softirqs and bottom halves · Interrupt affinity, coalescing and the cost of interrupt storms · Direct memory access and zero-copy paths · Blocking, non-blocking, epoll and asynchronous I/O · The network receive path: NIC, ring buffer, softirq, socket buffer · Timers, clocks and timekeeping · Power management and its performance side effects
From power-on to a running service, and back down again. Firmware, bootloader and kernel handoff, initial ramdisk and root pivot, the init system and service supervision, dependency ordering, resource control at start, then shutdown, crash and recovery paths.
Topics: Firmware, UEFI, bootloader and kernel handoff · Kernel command line, initramfs and root filesystem pivot · Init systems and service supervision · Unit dependencies, ordering and target states · Service restart policy, watchdogs and failure handling · Logging from early boot onward · Kernel panics, crash dumps and post-mortem analysis · Single-user and rescue recovery paths
The mechanisms behind containers and virtual machines, treated as operating system features rather than as products. Namespaces per resource type, cgroup hierarchies and controllers, capabilities and seccomp filters, then hardware virtualization and where each boundary genuinely holds.
Topics: Namespaces: pid, mount, network, user, uts, ipc, cgroup · Building an isolated process by hand with unshare and clone · cgroup v2 hierarchies, controllers and delegation · CPU quota, throttling and why a container appears slow at low utilisation · Memory limits, reclaim and container out-of-memory kills · Capabilities, no-new-privileges and seccomp filters · Mandatory access control: SELinux and AppArmor · Hardware virtualization compared with kernel-level isolation · What each boundary resists, and what it does not
The payoff module. A systematic performance method rather than tool trivia, the USE and RED approaches, the standard toolset for CPU, memory, disk and network, tracing with strace, perf and ftrace, flame graphs, and a structured approach to a slow or hung system under real time pressure.
Topics: Systematic method: USE, RED and workload characterisation · CPU analysis: utilisation, saturation, profiling · Memory analysis: pressure, reclaim, faults, cache · Disk analysis: latency, queueing, utilisation · Network analysis: throughput, retransmits, buffer behaviour · strace, perf, ftrace and eBPF-based tooling · Flame graphs and interpreting a profile · Diagnosing a hung process and a hung system · The equivalent tooling on Windows
We rebuild the agenda around the tools you actually run.
Request a custom agendaTrace a real application from launch to serving traffic, explain every system call phase, and measure the cost difference between a call into the kernel and a plain function call.
Saturate the run queue under controlled load, correlate queue depth with request tail latency, then pin and isolate a latency-sensitive process and quantify the improvement.
Present one system exhibiting all three memory symptoms and separate them with evidence from /proc, page-fault counters and pressure signals — then trigger the out-of-memory killer on purpose.
Benchmark a write workload with and without fsync, then cut power mid-write and inspect exactly what the journal preserved and what it did not.
Construct an isolated process using only namespaces, cgroups and pivot_root, then reproduce CPU throttling under a quota and explain why utilisation looks low while latency is high.
Diagnose four systems degraded in CPU, memory, disk and network respectively, using a systematic method and producing evidence, root cause, fix and verification for each.
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
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.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
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.
| 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.