Private corporate batches delivered onsite across Pune, or live online in IST (UTC+5:30) — taught by a practitioner who runs Jira 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 Jira around the administration boundary rather than around the menus: which changes a project administrator genuinely owns, which need a global administrator, and how to write the request that gets approved instead of refused. The syllabus builds workflows with conditions, validators and post functions that enforce a process without blocking delivery, designs permission schemes and project roles so several supplier teams can share one board without seeing each other's work, and treats JQL as the reporting engine it is — operators, functions, historical predicates, saved filters, subscriptions and dashboards that replace a manually maintained spreadsheet. The service management half covers request types, queues, approvals and service level calendars aligned to a shift pattern, and the operational half covers directory authentication, search indexing, backup and restore, audit logging, performance and upgrade practice, backed by twenty years of delivery and platform engineering.
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 Jira that means a trainer who has run it in production — Jira administration, workflow and JQL for Pune's multi-vendor delivery programmes — 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 covers Hinjewadi, Kharadi, Magarpatta, Yerwada, Talawade, Baner and Hadapsar; you provide the room, a screen and network, we bring trainer, agenda, exercise projects, assessments and certificates. Hours are 09:30 to 17:30 IST, and Pune delivery teams normally book this at the start of a programme increment rather than mid-sprint, since the workflow and scheme changes designed in the room usually get applied straight afterwards. Labs need a sandbox project or a non-production instance the group can safely reconfigure — never your live programme instance — and if you have only the customer's production Jira we run the administration exercises on a free Atlassian trial instead and keep your own instance read-only for the reporting and JQL work. Where roles differ widely we split the group so administrators get scheme design while delivery leads get JQL, dashboards and reporting. Invoicing is in INR with GST against your purchase order from the Indian entity.
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 Jira batchJira is Atlassian's work tracking platform, and the fact that decides what you can get done inside one is that its configuration is split across two levels of ownership. Some things belong to a project and can be changed by whoever administers that project — the board, components, versions, project roles, a handful of settings. Others are global objects that several projects share: workflows, screens, custom fields and their contexts, permission schemes, notification schemes. Knowing which side of that line a request falls on is the difference between a change made in ten minutes and one that has to be argued to somebody else's administrator.
The workflow engine is where a process is enforced rather than merely described. Statuses and transitions define the path an issue may take; conditions decide who may make a transition, validators decide whether the data allows it, and post functions do the work that follows — assigning, stamping fields, firing the events other automation listens for. Because a workflow scheme is shared, one edit can land in every project using it, which is exactly why a board shared by three supplier teams needs its scheme design settled before anyone starts adding statuses. Permission schemes and project roles are what make that arrangement workable: roles are per-project and delegable, groups are global and administrative, and an issue security scheme restricts individual issues when one party must not see another's.
Reading Jira is a separate skill from configuring it. JQL turns the issue store into something queryable — operators, functions and historical predicates such as changed and was — and every saved filter, subscription, dashboard gadget and cross-project board is built on top of it. The same platform also carries Jira Service Management, where request types, portals, queues, approvals, service level calendars and automation rules turn a tracker into an intake system with response commitments attached.
The reason Pune teams book Jira training is rarely that people cannot raise a ticket. It is that a delivery or ER&D group in Hinjewadi, Talawade or Hadapsar is living in two instances at once — the customer's, where it holds project-level rights at best, and its own, where capacity, defects and internal milestones are tracked — and the two have to reconcile at the end of every sprint and every invoice cycle. That produces a very unusual skills profile: knowing precisely what project settings can achieve without an administrator, knowing how to write the change request that an administrator will actually approve, and being able to answer a status question with a query instead of a spreadsheet somebody maintains by hand.
The regulated captives around Kharadi, Yerwada and Magarpatta run the scaled version of the same problem. Programme-level boards span several projects, dependencies cross team boundaries, and audit expectations turn screen schemes, field configurations and issue-level security into design decisions with consequences rather than settings somebody clicks. Where three vendors share one board, permission and notification design stops being administrative housekeeping and becomes the thing that determines whether the board can be trusted at all.
The engineering and manufacturing organisations out towards Pimpri-Chinchwad and Chakan add the third pattern, using Jira Service Management as intake for plant and application support, where request types, queues, service level calendars aligned to shift patterns rather than office hours, and automation rules do most of the work. Locally, scrum master and delivery manager postings assume JQL fluency and some administration exposure far more often than they ask for a certificate, and that is the gap a private batch here is bought to close.
What Jira is beneath the board — an issue store with a workflow engine and a permission model in front of it. Deployment options and what each implies for who can change what, terminology used precisely, and the single most useful map in the course: which settings a project administrator owns and which are global objects shared with everybody else.
Topics: The data model: issues, fields, projects and the objects that bind them · Architecture: application, database, search index and attachment storage · Project-level settings against global configuration objects · Terminology used precisely, so requests are unambiguous · Deployment options and what each implies for administration rights · Use cases the platform handles well, and work it is genuinely bad at
Standing up an instance on both platforms teams run, connecting it to a real database rather than the evaluation one, and setting the things that are painful to change afterwards — base address, home directory, attachment and index location, and memory. Also the reason to keep a sandbox instance separate from the one that holds live work.
Topics: Installation and configuration on Linux · Installation and configuration on Windows · Connecting to an external database and why the bundled one is not enough · Home directory, attachment storage and index location · Memory settings and start-up tuning · Running as a service and sitting behind a reverse proxy · Licensing, first-run setup and keeping a sandbox alongside production
The day-to-day objects, and the four structuring tools most teams ignore until reporting becomes impossible: subtasks for breakdown, components for ownership routing, versions for release grouping, and issue links for dependency across projects. Plus bulk operations, attachments, comments and the history that makes an issue auditable.
Topics: Project types and what choosing one commits you to · Creating and working issues, and the fields that matter · Subtasks and when they help rather than clutter · Components as an ownership and routing mechanism · Versions, release grouping and the release report · Linking issues within and across projects for dependency tracking · Bulk change operations and the damage they can do · Attachments, comments and issue history as evidence
Running a board so it reflects reality rather than decorating it. Scrum and Kanban boards and what genuinely differs, backlog refinement, sprint planning and closure, estimation, columns, swimlanes, quick filters and work-in-progress limits, and the reports that tell you whether the process works — read with their limitations stated.
Topics: Scrum boards against Kanban boards, and choosing honestly · Backlog, epics and the epic panel · Sprint planning, execution, closure and carry-over · Estimation, story points and time tracking · Board configuration: columns, swimlanes, quick filters and work-in-progress limits · Burndown, velocity, cumulative flow and control charts · Boards spanning several projects for a programme view · Releases and version reporting
The configuration layer beneath an issue, and the place instances quietly become unmaintainable. Adding, editing and retiring issue types and custom fields, issue type schemes, and the context model that decides which projects and issue types a field applies to — plus the performance and reporting cost of field sprawl that nobody budgets for.
Topics: Adding, editing and deleting issue types safely · Issue type schemes and sharing them across projects · Custom field types and choosing the least expensive one that works · Field contexts, default values and per-project options · Field configurations: required, hidden and renamed fields · The real cost of custom field sprawl on search and reporting · Retiring a field that is still referenced somewhere · Deciding when to reuse a scheme and when to dedicate one
Where a field appears, and how to know what a change will break before making it. Screens for create, edit and view, screen schemes and issue type screen schemes, transition screens, and the habit that separates a competent administrator from a dangerous one: tracing every project affected by an object before touching it.
Topics: Screens and their three operations: create, edit and view · Screen schemes and issue type screen schemes · Transition screens and gathering data at the right moment · Why a field can be present but invisible, and how to diagnose that · Tracing which projects share a screen or scheme · Impact analysis before any shared object is edited · Naming conventions that make an instance readable
The engine that carries a real process. Statuses, steps and transitions, then the four extension points that make a workflow enforce anything: conditions on who may transition, validators on whether the data allows it, post functions on what happens next and the order they run in, and events other automation listens for. Drafts and safe publishing included.
Topics: Statuses, steps, transitions and the workflow designer · Conditions: controlling who may make a transition · Validators: refusing a transition when the data is insufficient · Post functions and the order in which they execute · Events fired by transitions and who consumes them · Applying several workflows within one project by issue type · Workflow schemes, drafts and publishing without disruption · Designing an approval step an internal reviewer accepts
Access control that scales past a single team. Authentication against the internal directory or a corporate directory, the distinction between global groups and per-project roles that most instances get wrong, how a permission scheme is evaluated, and issue security schemes for the case where one supplier must not see another supplier's issues.
Topics: Authentication against the internal directory and a corporate directory · Users, groups and the administrative rights groups carry · Project roles as the delegable, per-project alternative · Permission schemes and the order in which grants are evaluated · Issue security schemes for restricted issues · Debugging why somebody cannot see or edit an issue · Access design for several supplier teams on one board · Security practice for an instance holding customer data
The highest-return skill in the course. Basic search for everyday use, advanced search when it runs out, then JQL properly — operators, functions, ordering, and the historical predicates that answer questions about what changed and when. Saved filters, sharing, subscriptions, dashboard gadgets, and where a spreadsheet or a reporting tool is still the honest answer.
Topics: Basic and advanced search, and when each runs out · JQL syntax: fields, operators, keywords and ordering · Functions for dates, membership and sprints · Historical predicates: changed, was, during and after · Saving searches as filters and sharing them correctly · Filter subscriptions and scheduled delivery · Dashboards, gadgets and wallboards built from filters · Exporting, and where a reporting tool is genuinely the better answer
The two things that remove the most manual effort. Automation rules — triggers, conditions, actions, branching and the limits worth knowing — then Jira Service Management as an intake system: request types and portal, queues, approvals, service level calendars aligned to a shift pattern rather than office hours, and the knowledge base beside it.
Topics: Automation rules: triggers, conditions, actions and branching · Rules across projects, and where they cost more than they save · Service management projects: request types and the customer portal · Queues and how work is routed to the right team · Approvals and the record they leave · Service level calendars that follow a shift pattern, and the metrics behind them · Linking a support request to the delivery issue that fixes it · Notification design that avoids drowning the recipients
Everything left that keeps an instance trusted. Notification schemes and custom events, a mail handler that raises issues from email, integration with source control and continuous integration so an issue reflects pipeline reality, then operations: search indexing, backup and restore, audit logs, performance, upgrades and migration between Cloud and a self-managed deployment.
Topics: Notification schemes, recipients and custom events · Outgoing mail and email templates · A mail handler that creates issues and comments from email · Integration with source control, continuous integration and quality gates · Apps and add-ons, and how to assess the risk of one · The REST interface and command-line administration · Search indexing, reindex strategy and the performance complaints it causes · Backup, restore, audit log management and global settings · Upgrades, troubleshooting, and moving between Cloud and a self-managed deployment
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake five configuration needs in an instance where you hold project rights only, establish what each really requires, and write the change requests that get accepted rather than refused.
Design issue type, screen, permission and notification schemes so three vendor teams share a single board without seeing each other's issues or breaking each other's process.
Build a workflow where only a named role may transition, the move is refused without evidence attached, and a post function stamps the approver and fires an event automation consumes.
Take a real recurring status report, rebuild it as saved JQL filters with a shared dashboard and a subscription, and confirm the numbers reconcile with the original.
Configure a service management project with request types, portal, queues, approvals and a service level calendar aligned to a running shift pattern instead of office hours.
Back up a fully configured instance with attachments, destroy it, restore, reindex, and verify every scheme, board, filter, dashboard and automation rule still behaves.
Jira in Pune is usually not one Jira. A delivery or ER&D team in Hinjewadi, Talawade or Hadapsar works inside the customer's instance, where it holds project-level rights at best, while tracking its own capacity, defects and internal milestones in a second instance the customer never sees — and the two have to reconcile at the end of every sprint and every invoice cycle. That produces a very specific curriculum: what can genuinely be changed with project settings alone, when a request truly needs a Jira administrator, how to design a workflow and permission scheme that survives three vendors on one board, and how to get a status answer out with JQL and a dashboard instead of a spreadsheet somebody maintains by hand.
The regulated captives around Kharadi, Yerwada and Magarpatta run the scaled variant — programme-level boards, cross-project dependency tracking, and audit expectations that turn screen schemes, field configurations and issue-level security into real design decisions rather than settings. The engineering and manufacturing organisations near Pimpri-Chinchwad and Chakan use Jira and Jira Service Management as an intake system for plant and application support, where request types, queues, SLA calendars aligned to shift patterns and automation rules do most of the work. Locally, scrum master and delivery manager postings assume JQL fluency and some administration exposure far more often than they assume a certification, and that is the gap a private batch here is usually bought to close.
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
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.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
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.
| 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.