Chapter 20 — Web3, blockchain and cryptoasset security: troubleshooting
Lesson map
Lesson 20 published. Map, example, EX058.
flowchart TD
N0["Learning outcomes"]
N1["20.1 Methodical diagnosis"]
N2["20.2 Symptoms and causes"]
N3["20.3 Recording fixes"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX058"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["20.1 Methodical diagnosis"]
N2["20.2 Symptoms and causes"]
N3["20.3 Recording fixes"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX058"]
[Learning outcomes]
|
v
[20.1 Methodical diagnosis]
|
v
[20.2 Symptoms and causes]
|
v
[20.3 Recording fixes]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX058]
Learning outcomes
You will (1) diagnose faults methodically; (2) separate symptoms from causes; (3) record fixes for reuse.
20.1 Methodical diagnosis
When members report that bookings are slow to confirm, Lucas follows a method: define the symptom precisely, gather data, form hypotheses, test them one at a time and confirm the fix. He measures that confirmations take about forty seconds instead of the usual twelve. He checks node health, block production times, the booking application's logs and the network between them. A methodical approach avoids guessing and changing several things at once, which can hide the real cause or introduce new problems that are even harder to trace afterwards.
20.2 Symptoms and causes
Block production is normal, so the ledger is not slow. The booking application logs show it waits for a node response for thirty seconds before retrying another node. The node it prefers, node-b, has a high response time because its programming interface is overloaded by a reporting script running every minute. The symptom is slow bookings; the cause is a reporting script running too often against the same node the application uses. Separating symptom from cause leads to the right fix rather than adding more servers or replacing software unnecessarily.
20.3 Recording fixes
Lucas moves the reporting script to node-a and reduces its frequency to every ten minutes. Confirmations return to about twelve seconds. He records the symptom, data gathered, hypotheses, tests, cause and fix in a troubleshooting log, with a short summary at the top for quick reading. Next time a similar symptom appears, anyone can check the log first. Ms Adebayo notes that recorded fixes are an organisation's accumulated experience; without them, the same problems are rediscovered painfully by every new volunteer who joins the team.
Worked example
Slow confirmations of about forty seconds are traced to an overloaded node-b interface, fixed by moving and slowing a reporting script, restoring twelve seconds.
Synthetic case. The fault and fix are synthetic.
Errors and limits
Changing several things at once can hide the real cause of a fault.
Exercises
- EX058 — Measured delay. How slow were confirmations? Rubric: 3 = about forty seconds instead of twelve;; 2 = forty seconds;; 1 = two seconds;; 0 = none.
- EX059 — Root cause. What caused the slow bookings? Rubric: 3 = a reporting script overloading node-b's interface;; 2 = overloaded interface;; 1 = slow blocks;; 0 = none.
- EX060 — Fix applied. What fix was applied? Rubric: 3 = moved the script to node-a every ten minutes;; 2 = move and slow script;; 1 = new servers;; 0 = none.
Synthesis
Methodical diagnosis separates symptoms from causes and recorded fixes speed future work.
Continue studying — chapter 20 of 30
← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →