Maintaining IoT Systems
The Maintaining domain tests how a running deployment stays available, secure, and accurate across its life: monitoring and alerting, maintenance strategy, update management, incident response, service reporting, and end-of-life. Expect calculation items on availability and scenario items on change control.
Monitor the service, not just the devices
Instrument four layers: device health (battery, signal, last-seen, uptime), connectivity (broker sessions, message rate, error codes), platform (queue depth, API latency, storage), and business outcome (the metric the project was funded to improve). Alert on symptoms that matter, use thresholds with hysteresis, and suppress duplicates. An alert that fires nightly and is ignored is worse than no alert.
Plan maintenance by type
Preventive (scheduled battery, calibration, cleaning), predictive (trend battery voltage or sensor drift to replace before failure), corrective (repair after fault). Failure data sets spares levels and batches site visits, usually the largest recurring cost.
Control change: updates and patching
Stage firmware and configuration rollouts: canary group → 10% → remainder, with health gates, signed images, A/B partitions, and automatic rollback inside an agreed maintenance window.
Respond and report
An incident runbook covers detection, triage, containment (isolate a compromised device or segment), eradication, recovery, and post-incident review. Track availability against the SLA.
Worked example. A gateway has MTBF 4,000 h and MTTR 8 h. Availability = 4,000 ÷ (4,000 + 8) = 99.80%, which misses a 99.9% SLA. Cutting MTTR to 4 h gives 4,000 ÷ 4,004 = 99.90%, meeting it. The reasoning: at this failure rate, availability is bought with faster recovery - on-site spares, remote diagnostics, clear runbooks - not with a more reliable box.
End of life
Track certificate and credential expiry, vendor support dates, and protocol deprecation. Decommissioning must revoke identities, wipe keys, remove network access, archive data per retention policy, and update the asset register.
Traps
- Alerting on raw values without debounce, causing fatigue.
- Pushing firmware to the whole fleet at once.
- Missing certificate expiry - a common cause of total outage with healthy devices.
- Reporting device uptime instead of service availability.
- Decommissioning hardware without revoking credentials.