Private corporate batches, live online cohorts and 1-on-1 mentoring in the operating system every pipeline, container and cloud instance actually runs on — 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 Linux as the diagnostic substrate under everything else — the boot and init path, systemd unit dependencies and journald, cgroups and namespaces as the actual mechanism behind containers, LVM and filesystem layout, and network state read with ip, ss and tcpdump rather than guessed at. Sessions run against live hosts that are deliberately broken: a full inode table, a service that starts before its mount, a port held by an invisible process, a permission denial that is SELinux rather than the mode bits.
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 Linux that means a trainer who has run it in production — the operating system every pipeline, container and cloud instance actually runs on — 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 Linux batchLinux is a Unix-like operating system kernel and the userspace built around it. It runs the overwhelming majority of servers, every mainstream container image, almost all Kubernetes nodes and the build agents behind most CI systems. Distributions — Ubuntu, Debian, RHEL, Rocky, Alma, Amazon Linux, SUSE — differ in packaging, init defaults, release cadence and support model, but they share the same kernel interfaces, the same filesystem layout and the same process model, which is why the skill transfers across all of them.
What makes Linux learnable is that its abstractions are visible. A process is a directory under /proc. A device is a file. A service is a systemd unit with a dependency graph you can print. Network state is queryable with ip and ss rather than hidden behind a control panel. Nothing about container isolation is magic either — namespaces and cgroups are kernel features you can inspect and create by hand, which is what makes the container layer above them comprehensible instead of mysterious.
For infrastructure work Linux is not an optional background subject. Every configuration management run, container build, deployment and incident eventually resolves to a question about a Linux system: which process holds the port, why the mount is read-only, where the disk went, why the service failed to start after a reboot, what SELinux denied. Engineers who can answer those questions from the command line resolve incidents in minutes; engineers who cannot escalate them.
The cloud did not remove Linux from the stack — it multiplied it. A team that once managed forty servers now manages thousands of ephemeral instances, container images, node pools and build agents, all of them Linux, and all of them failing in Linux-specific ways.
At the same time the layer of abstraction above has grown thick enough that many engineers have never worked below it. They can write a manifest but cannot read a journal, cannot find which process is holding a file handle, cannot tell whether the container is out of memory or the node is. That gap is where incidents lengthen from ten minutes to four hours, and it is why job specifications for platform engineering, SRE and cloud roles still list Linux fundamentals ahead of any specific tool.
The demand is for diagnostic ability rather than command recall. Anyone can look up a flag. The valuable skill is knowing which subsystem is lying to you, and having a repeatable path from symptom to cause across processes, memory, storage, networking and permissions.
How a Linux machine actually comes up, and where each layer's configuration lives. Firmware, bootloader, kernel, initramfs and the first userspace process, then the filesystem hierarchy and the kernel interfaces that make the running system inspectable.
Topics: Kernel and userspace — what belongs to which · Distribution families and what genuinely differs between them · The boot sequence: firmware, GRUB, kernel, initramfs, init · Filesystem hierarchy standard — where things live and why · /proc and /sys as interfaces, not directories · Recovering a host that will not boot: single-user and rescue modes
The working surface of the system. Navigation and file manipulation, links, globbing and quoting, then the text-processing toolchain that turns command output and log files into structured answers — the skill that separates engineers who search logs from engineers who query them.
Topics: Navigation, file manipulation, hard links and symlinks · Globbing, quoting and word splitting · Standard streams, pipes and redirection · grep and regular expressions · sed for stream editing · awk for field extraction and aggregation · find and xargs for bulk operations · Archiving and transfer — tar, rsync, scp
Who can do what, and why an operation was denied. Users, groups and the password and shadow files, standard mode bits and the special bits, umask, ACLs, sudo policy, SSH key-based access, and the mandatory access control layers that produce denials the mode bits cannot explain.
Topics: Users, groups, /etc/passwd, /etc/shadow and /etc/group · Mode bits, setuid, setgid and the sticky bit · umask and default permissions · POSIX ACLs and extended attributes · sudo policy and privilege escalation design · SSH keys, agents, config and hardening sshd · SELinux and AppArmor — contexts, modes and reading denials · PAM in outline: where authentication is actually decided
How software gets onto a host and how you keep an estate consistent. The two major packaging families, repository configuration and priorities, dependency resolution, version pinning and rollback, plus building a package and running an internal mirror for air-gapped or regulated environments.
Topics: dpkg and apt — packages, sources, pinning and holds · rpm and dnf/yum — repositories, modules and priorities · Dependency resolution and what to do when it fails · Version pinning, downgrades and rollback · Building a simple package from source · Internal mirrors and air-gapped patching · Patch management and unattended upgrades
The process model and the service manager built on top of it. Process states, parents and orphans, signals, file descriptors, then systemd units in depth — ordering versus requirement, restart policy, resource limits, targets, timers — and journald, which is where the answer usually is.
Topics: Process states, PIDs, parents, zombies and orphans · Signals and what each one actually does · File descriptors, lsof and fuser · systemd units: service, socket, mount, target · Requires, Wants, After, Before — ordering versus dependency · Restart policy, resource limits and hardening directives · systemd timers versus cron · journald — filtering, persistence and correlating with application logs
The subsystem that causes the most unplanned downtime. Block devices, partitioning, filesystem types and their trade-offs, mounting and fstab, LVM for volumes that can grow, plus the failure modes engineers meet in production: a full disk, an exhausted inode table, a read-only remount and a filesystem that will not fsck.
Topics: Block devices, partitions and device naming · Filesystems — ext4, XFS, and where each is the right choice · Mounting, fstab and mount options · LVM: physical volumes, volume groups, logical volumes, extending and snapshots · Swap, tmpfs and memory-backed filesystems · Disk full, inode exhaustion and read-only remounts · Network storage — NFS and object storage mounts · Monitoring capacity before it becomes an incident
Reading and changing network state, and localising a fault to the right layer. Interfaces, addressing and routing with the ip suite, socket state with ss, name resolution, firewalling with nftables and firewalld, and packet capture — because at some point the only honest answer comes from tcpdump.
Topics: Interfaces, addressing and the ip command suite · Routing tables, policy routing and default gateways · Socket state with ss — listening, established, and who owns the port · DNS resolution: resolv.conf, systemd-resolved, dig and drill-down · nftables, iptables and firewalld · NAT, port forwarding and container networking basics · Packet capture with tcpdump and reading the output · Localising a fault: DNS, routing, firewall, TLS or application
Working out what a slow system is actually waiting on, and reducing its attack surface. Load average and what it does not mean, memory accounting and the OOM killer, I/O and CPU saturation, cgroups and namespaces as the mechanism behind container limits, then baseline hardening and audit.
Topics: Load average, run queue and what load actually measures · Memory accounting, page cache, swap and the OOM killer · I/O and CPU saturation — vmstat, iostat, pidstat, top · Pressure stall information and cgroup v2 metrics · Namespaces and cgroups as the mechanism behind containers · Kernel tuning with sysctl · Baseline hardening: services, ports, SSH, file integrity · auditd and system logging for evidence
We rebuild the agenda around the tools you actually run.
Request a custom agendaCorrupt the bootloader and fstab on a lab host, then recover it from rescue mode and document each recovery step as a runbook.
Given a large unstructured log, answer questions about error rates, slow endpoints and client distribution using only grep, awk, sed and sort.
Debug a unit that fails after reboot because of dependency ordering, then rewrite it with correct After/Requires, restart policy and resource limits.
Extend an LVM volume and filesystem with no downtime, then recover a host with a full root filesystem and an exhausted inode table.
Work through connection failures caused variously by DNS, routing, firewall rules and TLS, using ip, ss, dig and tcpdump to identify each layer.
Build a host from base image to production-ready: partitioning and LVM, users and sudo policy, hardened SSH, systemd services, firewall rules and a performance baseline.
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
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
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.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
| 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.