A busy Linux CPU does not explain every slow page
Run a bounded ten-second workload, compare the guest before and after, and check whether the practice page slows down at all.
Guides
Walkthroughs for observability, incident response and AI-assisted operations.
Browse guides with article filtersAIOps fundamentals
Start with what AI can do for operations, and where judgment still matters.
Read AIOps fundamentalsObservability for SRE
Make metrics, logs and traces work together.
Read Observability for SREIncident management with AI
Build an incident response practice that learns.
Read Incident management with AIPractical articles
Instructions, examples and implementation notes.
Repair the Linux lab when the server answers with the wrong thing
A running server can return HTTP 200 without returning your page. Introduce one reversible fault, follow the response and repair the request that failed.
Measuring service success: did the customer get the report?
Count the correct reports people can download on time, keeping missing outcomes visible and giving every accepted request its full deadline.
Choosing an SLO: what the extra nine asks you to change
At a million requests, moving from 99% to 99.9% allows 9,000 fewer missed reports. Choose the reliability work and customer promise behind that number.
Error budgets: the same balance can call for a different decision
Forty exports of margin looks different after a repaired fault than during a growing failure. Connect the count, its pace and the recovery work to release decisions.
A useful page tells the next responder where to begin
A growing queue is a clue, not a complete message. Help the next responder see who is waiting, what to compare first and how to recognize recovery.
Make the first on-call shift workable
A runbook can be correct and still stop at a login screen. Rehearse one delayed export to find the access, decisions and people a new responder will need.
Reduce toil without making the wrong retry faster
Forty retries a week look ready to automate. Follow the check before the click, then see whether a tool would remove work or simply move it.
What did those hundred canary exports actually test?
A new worker can finish a hundred reports without touching the code you changed. Choose work that answers the release question, then plan how to stop and recover.
When storage recovers but the reports are still waiting
A five-minute slowdown can leave ten more minutes of work in the queue. Follow the exports to see how retries, limits and recovery affect the wait.
After the incident: change what the next retry does
A report can be finished even when its caller sees a timeout. Follow one lost reply from duplicate work to a repair another engineer can test.
Choosing the reliability work that earns the next two weeks
Retry repairs, extra workers and less manual checking all help in different ways. A useful investment proposal makes the tradeoff visible, including what would change your mind.