Server Incident Ranking: Frequency vs Severity Weighted Score
Intermediate
60 min
0 views
0 solutions
Overview
NexGenIT's NOC team tracks incidents per server but ranks servers by total incident count — which over-penalizes servers with many minor issues and ignores servers with few but catastrophic failures. The IT manager must design a weighted severity scoring algorithm and manually rank 8 servers before the quarterly review.
Case Details
# Aplly.xyz Case Study Submission
## Title
Server Incident Ranking: Frequency vs Severity Weighted Score
## Type
Technology/IT
## Difficulty
Intermediate
## Estimated Time
60 minutes
## Overview
NexGenIT's NOC team tracks incidents per server but ranks servers by total incident count — which over-penalizes servers with many minor issues and ignores servers with few but catastrophic failures. The IT manager must design a weighted severity scoring algorithm and manually rank 8 servers before the quarterly review.
## Case Details
Function Focus: Weighted scoring algorithm design, severity-based ranking, tie-breaking rule design, ranking sensitivity to weight choice
Scenario:
The current quarterly report ranks servers by "total incidents." Server WEB-03 leads with 22 incidents — but most are minor warnings. Server DB-01 has only 5 incidents, all of which were Critical (production outages). The IT manager argues that WEB-03 looks worse than it is while DB-01's true risk is hidden. She proposes a weighted severity score: Critical incidents weighted highest, High next, Medium lowest. She must design the scoring algorithm, apply it to 8 servers manually, and produce a new ranking that reflects true operational risk. The NOC wants to see both rankings side by side before accepting the change.
Scoring Algorithm (Draft):
- Incident Weight: Critical = 5, High = 3, Medium = 1
- Server Score = (Critical Count × 5) + (High Count × 3) + (Medium Count × 1)
- Ranking: highest score = most critical (rank 1)
- Tie rule: if scores are equal, the server with more Critical incidents ranks higher
Tasks:
1. Before scoring, read the draft algorithm and identify at least 1 limitation (e.g., what if a server has many Medium incidents that collectively cause more downtime than a single Critical? is the 5:3:1 ratio defensible?)
2. Compute the raw incident ranking (sort by total incidents descending) and the weighted severity ranking using the draft algorithm — produce both rankings side by side for all 8 servers
3. Identify which servers move up or down the most between the two rankings — for the biggest mover, explain why the shift happened and whether the new position is more accurate
4. Perform a sensitivity check: re-rank using an alternative weighting (Critical = 10, High = 4, Medium = 1) — does the top 3 change? Which servers are most sensitive to the weight choice?
5. Only after completing your manual analysis, re-run all rankings in a spreadsheet or AI tool and report any discrepancies — then recommend a final weight set and state why
Expected Output:
A ranking design memo containing: (a) critique of the draft algorithm, (b) side-by-side ranking table (raw vs weighted), (c) identification and explanation of the biggest mover, (d) sensitivity analysis with alternative weights, (e) final weight recommendation with justification, and (f) a round-trip discrepancy note.
Evaluation Criteria:
Correct computation of both rankings across all 8 servers, correct identification of the biggest mover with a clear explanation, meaningful sensitivity analysis (not just recalculating but interpreting the change), a defensible final weight recommendation, and honest discrepancy reporting.
## Data Sources
Q3 Incident Data by Server:
| Server ID | Role | Critical Incidents | High Incidents | Medium Incidents | Total Incidents |
|---|---|---|---|---|---|
| WEB-01 | Web Server | 1 | 5 | 14 | 20 |
| WEB-02 | Web Server | 0 | 3 | 12 | 15 |
| WEB-03 | Web Server | 2 | 8 | 12 | 22 |
| WEB-04 | Web Server | 0 | 6 | 10 | 16 |
| APP-01 | App Server | 3 | 4 | 6 | 13 |
| APP-02 | App Server | 1 | 2 | 8 | 11 |
| DB-01 | Database Primary | 4 | 1 | 0 | 5 |
| DB-02 | Database Replica | 1 | 1 | 2 | 4 |
Severity Definitions:
| Level | Definition | Example | SLA Impact |
|---|---|---|---|
| Critical | Production outage, data loss, security breach | Service down, database corruption | Yes, counts toward SLA breach |
| High | Severe degradation, partial feature loss | API latency > 5s, checkout failures | May count if cumulative |
| Medium | Minor issue, no user-facing impact | Background job failure, cosmetic bug | No |
Context:
- Current ranking method: sort by Total Incidents descending
- Current #1 (worst): WEB-03 with 22 total incidents
- Current #8 (best): DB-02 with 4 total incidents
- NOC manager wants the board to see both rankings before changing the metric
## Solution Frameworks
Weighted scoring algorithm, severity-based ranking, tie-breaking rules, ranking sensitivity analysis, metric redesign
## Solver Guidance & Tutorials
Link to: "Severity-Weighted Incident Prioritization" tutorial
## What You'll Learn
- Designing a weighted severity score for operational risk
- Comparing raw-frequency vs weighted-severity rankings
- Testing whether your ranking is robust to weight changes
- Building consensus around a metric change by showing both old and new rankings
## Tags
incident ranking, severity scoring, IT operations, weighted metrics, risk prioritization
## Registration Links
- Register as Solver
- Register as Evaluator
## Title
Server Incident Ranking: Frequency vs Severity Weighted Score
## Type
Technology/IT
## Difficulty
Intermediate
## Estimated Time
60 minutes
## Overview
NexGenIT's NOC team tracks incidents per server but ranks servers by total incident count — which over-penalizes servers with many minor issues and ignores servers with few but catastrophic failures. The IT manager must design a weighted severity scoring algorithm and manually rank 8 servers before the quarterly review.
## Case Details
Function Focus: Weighted scoring algorithm design, severity-based ranking, tie-breaking rule design, ranking sensitivity to weight choice
Scenario:
The current quarterly report ranks servers by "total incidents." Server WEB-03 leads with 22 incidents — but most are minor warnings. Server DB-01 has only 5 incidents, all of which were Critical (production outages). The IT manager argues that WEB-03 looks worse than it is while DB-01's true risk is hidden. She proposes a weighted severity score: Critical incidents weighted highest, High next, Medium lowest. She must design the scoring algorithm, apply it to 8 servers manually, and produce a new ranking that reflects true operational risk. The NOC wants to see both rankings side by side before accepting the change.
Scoring Algorithm (Draft):
- Incident Weight: Critical = 5, High = 3, Medium = 1
- Server Score = (Critical Count × 5) + (High Count × 3) + (Medium Count × 1)
- Ranking: highest score = most critical (rank 1)
- Tie rule: if scores are equal, the server with more Critical incidents ranks higher
Tasks:
1. Before scoring, read the draft algorithm and identify at least 1 limitation (e.g., what if a server has many Medium incidents that collectively cause more downtime than a single Critical? is the 5:3:1 ratio defensible?)
2. Compute the raw incident ranking (sort by total incidents descending) and the weighted severity ranking using the draft algorithm — produce both rankings side by side for all 8 servers
3. Identify which servers move up or down the most between the two rankings — for the biggest mover, explain why the shift happened and whether the new position is more accurate
4. Perform a sensitivity check: re-rank using an alternative weighting (Critical = 10, High = 4, Medium = 1) — does the top 3 change? Which servers are most sensitive to the weight choice?
5. Only after completing your manual analysis, re-run all rankings in a spreadsheet or AI tool and report any discrepancies — then recommend a final weight set and state why
Expected Output:
A ranking design memo containing: (a) critique of the draft algorithm, (b) side-by-side ranking table (raw vs weighted), (c) identification and explanation of the biggest mover, (d) sensitivity analysis with alternative weights, (e) final weight recommendation with justification, and (f) a round-trip discrepancy note.
Evaluation Criteria:
Correct computation of both rankings across all 8 servers, correct identification of the biggest mover with a clear explanation, meaningful sensitivity analysis (not just recalculating but interpreting the change), a defensible final weight recommendation, and honest discrepancy reporting.
## Data Sources
Q3 Incident Data by Server:
| Server ID | Role | Critical Incidents | High Incidents | Medium Incidents | Total Incidents |
|---|---|---|---|---|---|
| WEB-01 | Web Server | 1 | 5 | 14 | 20 |
| WEB-02 | Web Server | 0 | 3 | 12 | 15 |
| WEB-03 | Web Server | 2 | 8 | 12 | 22 |
| WEB-04 | Web Server | 0 | 6 | 10 | 16 |
| APP-01 | App Server | 3 | 4 | 6 | 13 |
| APP-02 | App Server | 1 | 2 | 8 | 11 |
| DB-01 | Database Primary | 4 | 1 | 0 | 5 |
| DB-02 | Database Replica | 1 | 1 | 2 | 4 |
Severity Definitions:
| Level | Definition | Example | SLA Impact |
|---|---|---|---|
| Critical | Production outage, data loss, security breach | Service down, database corruption | Yes, counts toward SLA breach |
| High | Severe degradation, partial feature loss | API latency > 5s, checkout failures | May count if cumulative |
| Medium | Minor issue, no user-facing impact | Background job failure, cosmetic bug | No |
Context:
- Current ranking method: sort by Total Incidents descending
- Current #1 (worst): WEB-03 with 22 total incidents
- Current #8 (best): DB-02 with 4 total incidents
- NOC manager wants the board to see both rankings before changing the metric
## Solution Frameworks
Weighted scoring algorithm, severity-based ranking, tie-breaking rules, ranking sensitivity analysis, metric redesign
## Solver Guidance & Tutorials
Link to: "Severity-Weighted Incident Prioritization" tutorial
## What You'll Learn
- Designing a weighted severity score for operational risk
- Comparing raw-frequency vs weighted-severity rankings
- Testing whether your ranking is robust to weight changes
- Building consensus around a metric change by showing both old and new rankings
## Tags
incident ranking, severity scoring, IT operations, weighted metrics, risk prioritization
## Registration Links
- Register as Solver
- Register as Evaluator
Data Sources
Q3 Incident Data by Server:
| Server ID | Role | Critical Incidents | High Incidents | Medium Incidents | Total Incidents |
|---|---|---|---|---|---|
| WEB-01 | Web Server | 1 | 5 | 14 | 20 |
| WEB-02 | Web Server | 0 | 3 | 12 | 15 |
| WEB-03 | Web Server | 2 | 8 | 12 | 22 |
| WEB-04 | Web Server | 0 | 6 | 10 | 16 |
| APP-01 | App Server | 3 | 4 | 6 | 13 |
| APP-02 | App Server | 1 | 2 | 8 | 11 |
| DB-01 | Database Primary | 4 | 1 | 0 | 5 |
| DB-02 | Database Replica | 1 | 1 | 2 | 4 |
Severity Definitions:
| Level | Definition | Example | SLA Impact |
|---|---|---|---|
| Critical | Production outage, data loss, security breach | Service down, database corruption | Yes, counts toward SLA breach |
| High | Severe degradation, partial feature loss | API latency > 5s, checkout failures | May count if cumulative |
| Medium | Minor issue, no user-facing impact | Background job failure, cosmetic bug | No |
Context:
- Current ranking method: sort by Total Incidents descending
- Current #1 (worst): WEB-03 with 22 total incidents
- Current #8 (best): DB-02 with 4 total incidents
- NOC manager wants the board to see both rankings before changing the metric
| Server ID | Role | Critical Incidents | High Incidents | Medium Incidents | Total Incidents |
|---|---|---|---|---|---|
| WEB-01 | Web Server | 1 | 5 | 14 | 20 |
| WEB-02 | Web Server | 0 | 3 | 12 | 15 |
| WEB-03 | Web Server | 2 | 8 | 12 | 22 |
| WEB-04 | Web Server | 0 | 6 | 10 | 16 |
| APP-01 | App Server | 3 | 4 | 6 | 13 |
| APP-02 | App Server | 1 | 2 | 8 | 11 |
| DB-01 | Database Primary | 4 | 1 | 0 | 5 |
| DB-02 | Database Replica | 1 | 1 | 2 | 4 |
Severity Definitions:
| Level | Definition | Example | SLA Impact |
|---|---|---|---|
| Critical | Production outage, data loss, security breach | Service down, database corruption | Yes, counts toward SLA breach |
| High | Severe degradation, partial feature loss | API latency > 5s, checkout failures | May count if cumulative |
| Medium | Minor issue, no user-facing impact | Background job failure, cosmetic bug | No |
Context:
- Current ranking method: sort by Total Incidents descending
- Current #1 (worst): WEB-03 with 22 total incidents
- Current #8 (best): DB-02 with 4 total incidents
- NOC manager wants the board to see both rankings before changing the metric
Solution Frameworks
Weighted scoring algorithm, severity-based ranking, tie-breaking rules, ranking sensitivity analysis, metric redesign
Solver Guidance & Tutorials
Link to: "Severity-Weighted Incident Prioritization" tutorial
What You'll Learn
- Problem-solving and analytical thinking
- Data-driven decision making
- Business strategy development
- Professional report writing
0
Solutions Submitted
Difficulty
Intermediate
Estimated Time
60 minutes
Relevance
Fresh
Source
case-studies-in