Technology Maintenance Project

The esports lab works today. So we're done? Not close. Station 03's headset cuts out sometimes. Station 05 has only 8 GB of free storage. Station 06 hasn't received the newest game update. One spare mouse is already in use. The broadcast computer hasn't been backed up recently. A cable near Station 02 is starting to fray. Everything technically still works — mostly. Do we wait for something to completely fail? That's the maintenance problem.

Availability

Availability means the system or resource is ready when people need to use it. A PC can exist and still not be available — the game doesn't launch, the headset exists but the microphone fails, the network exists but the required service can't be reached. The equipment being physically present isn't the same as the function actually being available.

Maintenance is bigger than repair

Repair is part of maintenance, but maintenance can also happen before complete failure. Three situations: preventive (still working, but you act to reduce future risk — replacing a visibly damaged cable before competition), corrective (something has already failed — replacing a mouse that no longer registers input), and condition-based (evidence that attention may be needed, even though nothing has fully failed — a headset microphone that cuts out intermittently).

You can't maintain everything at once

A lab full of computers, monitors, headsets, keyboards, mice, switches, a router, a broadcast computer, software, accounts, cables, and spares adds up to a lot — and you have limited time, limited people, and limited money. Maintenance becomes a priority problem, and priority depends on the system: what function does this support, how many people or systems depend on it, is it already failing, is it getting worse, is there a backup, how difficult is the response, and when is the system actually needed?

Maintenance is proportional, not panicked

"Storage is getting low" doesn't mean shut down the whole lab — it means inspect the issue, maybe delete approved temporary files, move old recordings, schedule cleanup, and document the condition. And maintenance includes information: if a fix isn't recorded — what failed, what changed, what was replaced, whether it was verified — the next person who sees that station starts from zero.

Lesson 1: Maintenance Protects Availability

Maintenance, repair, availability, warning signs, preventive action, and maintenance records — and how small maintenance decisions protect larger system functions.

Lesson 2: Prioritizing a Maintenance Need

More problems than you can solve, on purpose. Decide what gets attention first using impact, urgency, dependency, backup availability, and effort, and defend the order.

Lesson 3: Technology Maintenance Project

A fictional lab, an inventory, a network diagram, maintenance history, issue reports, an upcoming event, and limited maintenance capacity. Build an Esports Lab Maintenance Plan — not "fix everything," but identify what matters most and defend the plan.

Week 18 artifact

Your final artifact is an Esports Lab Maintenance Plan: current condition, maintenance needs, priority, action, owner, verification, and follow-up.

Learning targets

By the end of Week 18, you should be able to:

• explain how maintenance supports system availability
• distinguish preventive, corrective, and condition-based maintenance
• identify warning signs before complete failure
• connect maintenance priority to dependencies and impact
• explain why every maintenance need cannot have the same priority
• use backup availability when evaluating urgency
• create a simple maintenance record
• identify actions students can safely perform versus issues that should be escalated
• prioritize maintenance using evidence
• create a maintenance plan for a fictional esports lab

One idea to keep: maintenance isn't fix everything. It's keeping the important functions available by giving the right problems attention at the right time.