Private corporate batches, live online cohorts and 1-on-1 mentoring in framing, feature engineering, forecasting, classification, calibration and deploying models that change a decision — 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 predictive analytics as an engineering discipline with a business obligation: start from the decision the model will change, define the target and prediction window before touching an algorithm, and treat leakage as the default failure mode rather than an edge case. Sessions cover the parts that decide whether a model survives contact with production — time-based validation instead of random splits, calibration so a probability means what it says, threshold selection from the cost of a false positive against a false negative, SHAP-based explanation for stakeholders and reviewers, and drift monitoring with a retraining trigger. Every technique is demonstrated on a realistic dataset with the failure modes deliberately reproduced.
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 Predictive Analytics that means a trainer who has run it in production — framing, feature engineering, forecasting, classification, calibration and deploying models that change a decision — 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 Predictive Analytics batchPredictive analytics is the practice of using historical data to estimate what will happen next, and — critically — of connecting that estimate to a decision someone will actually make. It sits between descriptive reporting, which tells you what happened, and prescriptive optimisation, which tells you what to do. A churn model that scores customers is only useful if a retention team acts on the score; a demand forecast is only useful if it changes a purchasing or staffing decision. The discipline is therefore as much about problem framing, target definition and threshold selection as it is about algorithms.
Technically it draws on regression, classification, time-series forecasting and survival analysis. In practice most business problems reduce to a handful of shapes: will this customer leave, will this transaction be fraudulent, how much will we sell next quarter, which lead is worth calling, when will this machine fail. The modelling method matters less than getting the target definition, the prediction window and the training data right — and than avoiding leakage, where information that would not exist at prediction time creeps into the features and produces a model that looks excellent in testing and fails immediately in production.
The modern practice of predictive analytics also includes everything after the model. Calibration so a predicted probability means what it says, threshold selection driven by the cost of a false positive versus a false negative, interpretability so a stakeholder or regulator can be given a reason, deployment as batch scoring or a real-time service, and monitoring for the data and concept drift that quietly degrades every deployed model over time.
Most organisations have finished the reporting phase. Dashboards exist, warehouses exist, and the obvious backward-looking questions are answered. The next increment of value comes from forward-looking questions — which customers to keep, how much to buy, which claim to review — and that requires a different skill set from the one that built the dashboards.
The tooling has also become accessible enough that the bottleneck moved. Gradient boosting libraries, notebook environments and managed platforms mean fitting a model is no longer the hard part. The hard parts are defining the target correctly, building features without leakage, evaluating with a metric that reflects business cost rather than academic convention, and getting the output into a system where it changes behaviour.
There is also a governance dimension that did not exist a few years ago. Models that affect credit, employment, insurance or healthcare decisions increasingly require documented reasoning, bias testing and human oversight. Organisations need practitioners who can build a model and also explain it, defend it and monitor it — not just report an accuracy number.
The module that determines whether the project is worth doing. CRISP-DM as a working structure, translating a business question into a prediction target, the prediction window and the point in time at which the decision is made. The cost matrix — what a false positive and a false negative are actually worth — and how to identify a problem that should not be a model at all.
Topics: CRISP-DM and the analytics lifecycle · From business question to prediction target · Defining the target label unambiguously · Prediction window and decision point · Baseline: what does the business do today? · The cost matrix and expected value of a decision · Success criteria agreed before modelling starts · When a rule, a report or a process change beats a model
Constructing the modelling table. Joining across sources at the right grain, time-aware aggregation windows, and the discipline of only using information that would genuinely exist at prediction time. Missingness as signal versus missingness as noise, encoding strategies for categoricals, scaling, outliers, and the leakage patterns that ruin more projects than any modelling mistake.
Topics: Joining and aggregating to a modelling grain · Time-windowed features and as-of joins · Target leakage: the common patterns and how to detect them · Missing data: mechanisms, imputation and missingness indicators · Encoding categoricals: one-hot, ordinal, target and hashing · Scaling, transformation and skew · Outlier handling and winsorisation · Feature selection and multicollinearity · Class imbalance and sampling approaches · Reproducible pipelines and avoiding train/serve skew
Predicting a number. Linear regression and its assumptions, regularisation with ridge, lasso and elastic net, and residual analysis that tells you what the model is failing to capture. Then time series proper: decomposition, stationarity, ARIMA and exponential smoothing, and machine-learning approaches with lag and rolling features — with backtesting rather than a random split.
Topics: Linear regression and its assumptions · Ridge, lasso and elastic net regularisation · Residual analysis and diagnostics · Regression metrics: RMSE, MAE, MAPE and their pitfalls · Time-series decomposition: trend, seasonality, residual · Stationarity and differencing · ARIMA and SARIMA · Exponential smoothing and state-space models · Lag, rolling and calendar features for tree-based forecasting · Hierarchical forecasting and reconciliation · Backtesting with rolling origin evaluation · Prediction intervals and communicating uncertainty
Predicting a category. Logistic regression as the interpretable baseline that is frequently good enough, decision trees and why they overfit, then the ensembles that dominate tabular problems — random forests and gradient boosting. Hyperparameter search done properly with cross-validation, and time-based splits when the data has an ordering.
Topics: Logistic regression and reading coefficients as odds · Decision trees, depth and overfitting · Random forests and bagging · Gradient boosting: XGBoost, LightGBM and CatBoost · Handling categorical features natively · Cross-validation strategies and time-based splits · Hyperparameter search: grid, random and Bayesian · Early stopping and validation sets · Handling imbalance: class weights, resampling, threshold moving · When a simple baseline wins and how to prove it
The module that connects modelling to money. Why accuracy is usually the wrong metric, the confusion matrix and the family of metrics derived from it, ROC versus precision-recall for imbalanced problems, and lift and gain charts that business stakeholders can read. Then calibration — making a predicted probability mean what it says — and choosing an operating threshold from expected value.
Topics: Confusion matrix and derived metrics · Precision, recall, F1 and when each matters · ROC-AUC versus PR-AUC on imbalanced data · Lift, gain and cumulative response charts · KS statistic and separation · Probability calibration: Platt scaling and isotonic regression · Reliability diagrams and Brier score · Choosing a threshold from the cost matrix · Expected value of a deployed model · Segment-level evaluation and hidden underperformance · Comparing against the current business process, not against zero
Being able to explain and defend the model. Global versus local explanation, permutation importance, partial dependence and SHAP values — including their limits and how they are commonly misread. Then fairness: measuring disparate performance across groups, the trade-offs between fairness definitions, and the documentation and human-oversight expectations that increasingly come with regulated decisions.
Topics: Global versus local interpretability · Permutation importance and its correlation caveat · Partial dependence and accumulated local effects · SHAP values: how to read them and how they are misread · Surrogate models and interpretable-by-design alternatives · Fairness metrics and their incompatibilities · Testing for disparate performance across groups · Proxy variables and indirect discrimination · Model cards and documentation · Human oversight, appeal and recourse · Regulatory expectations in credit, insurance, employment and health
Getting the model into the decision and keeping it working. Batch scoring versus real-time serving and how to choose; packaging and versioning the model and the feature logic together; and the train/serve skew that arises when they diverge. Then monitoring: data drift, concept drift, performance decay, retraining triggers, and measuring whether the model actually changed the outcome.
Topics: Batch scoring versus real-time serving · Packaging a model with its preprocessing · Feature stores and consistent feature computation · Model registry, versioning and lineage with MLflow · Shadow deployment and champion/challenger · Data drift and concept drift detection · Performance monitoring when labels arrive late · Retraining triggers and automated pipelines · Rollback and failure handling · Measuring incremental impact with a holdout or A/B test · Handover to the team that will operate it
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a genuine business question, define the target, prediction window and decision point, build a cost matrix from real numbers, and agree success criteria before any modelling.
Work with a dataset containing a deliberate target leak, build a model that scores suspiciously well, locate the leak with as-of reasoning, and quantify the true performance.
Forecast a real seasonal series with a classical model and a gradient-boosted model, compare rolling-origin backtests, and report prediction intervals.
Build a churn classifier from raw event data, beat a logistic baseline, calibrate the probabilities, and choose an operating threshold from retention economics.
Produce global and local SHAP explanations, test for disparate performance across groups, and write the model card a governance reviewer would accept.
Package a model with its feature logic, deploy it as a scoring job, wire drift and performance monitoring, define the retraining trigger, and design the holdout that proves it changed the outcome.
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.
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.