Operations, Maintenance, and Troubleshooting
Operations questions test disciplined process: observe, isolate, change one thing, verify.
Observability and maintenance
Know the three pillars: metrics (numeric time series for trends and alerting), logs (discrete events for detail), and traces (request paths across services for latency attribution). Establish a baseline of normal behaviour so anomalies are meaningful, and alert on symptoms users feel rather than on every raw threshold - alert fatigue degrades response more than missing a single noisy alert.
Maintenance is scheduled work: patching cadence, certificate and credential rotation, capacity review, backup verification, and configuration drift checks against the baseline.
Incident handling
A recognisable flow: detect, triage and assign severity, mitigate (restore service, even temporarily), communicate, then perform root cause analysis and feed corrective actions into change management. Mitigation and diagnosis are separate goals; restoring service first is usually correct.
Troubleshooting method
- Define the symptom precisely and its scope (who, what, where, since when).
- Identify what changed.
- Form a hypothesis and test it with the least invasive check.
- Change one variable at a time.
- Verify the fix and record it.
You can traverse the stack top-down (application to physical) or bottom-up (physical to application); choose based on where evidence points.
Traps
- Restarting a component that hides the cause and destroys evidence.
- Confusing correlation with causation when a change coincided with the fault.
- Treating monitoring and logging as the same control.
- Closing an incident without a corrective action owner.
Rule of thumb
If you cannot state the symptom in one sentence with scope and timing, you are not ready to test a hypothesis.