Chapter 37 — Data governance: operations
Lesson map
Lesson 37 published. Map, example, EX109.
flowchart TD
N0["Learning outcomes"]
N1["37.1 Daily operations"]
N2["37.2 Data incidents"]
N3["37.3 Runbooks"]
N4["37.4 On-call"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX109"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["37.1 Daily operations"]
N2["37.2 Data incidents"]
N3["37.3 Runbooks"]
N4["37.4 On-call"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX109"]
[Learning outcomes]
|
v
[37.1 Daily operations]
|
v
[37.2 Data incidents]
|
v
[37.3 Runbooks]
|
v
[37.4 On-call]
|
v
[Worked example] --> [Exercise EX109]
Learning outcomes
You will (1) run governance as daily operations; (2) handle data incidents; (3) maintain runbooks and on-call.
37.1 Daily operations
Governance needs routines. Kofi defines a daily cycle: overnight controls run, alerts reach owners by seven in the morning, stewards triage alerts by nine and the morning leakage view publishes with quality badges. Weekly, owners review trends and break ageing. Monthly, the governance board reviews service reports and decisions. He documents the cycle in an operations calendar so everyone knows when to expect information and when they must act on it. The calendar is shared with all owners and stewards, and reminders are sent automatically before each review meeting.
37.2 Data incidents
A data incident is an event where data quality or availability falls badly enough to affect decisions. Kofi defines severity levels, from a single district's missing data to a wrong leakage figure sent to the regulator. Each level has response times, communication rules and a lead. When a billing extract fails on a reporting day, the incident lead informs the regulator's contact that figures will be a day late rather than sending estimated numbers silently. The regulator's contact thanks Tidewater for the early warning.
37.3 Runbooks
For common alerts Kofi writes runbooks: step-by-step guides covering how to confirm the problem, likely causes, fixes and who to inform. The runbook for a stuck flow sensor explains how to compare with neighbouring sensors, request a site visit and mark affected data. He tests runbooks by asking a steward who did not write them to follow each one with a synthetic incident, revising steps that cause confusion during the test. Runbooks are stored next to the alerts they cover, so the link appears in each alert message.
37.4 On-call
Data alerts can occur at night. Kofi proposes an on-call rota among data engineers for critical data such as the safety-relevant sensor feeds, with clear escalation to operations engineers. Non-critical alerts wait until morning. He reviews alert volumes to ensure on-call staff are not woken for issues that could wait. Prof. Varga notes that sustainable operations require attention to staff workload, because exhausted on-call engineers make mistakes and leave. Alert thresholds that wake staff unnecessarily are adjusted after each monthly review of night-time alerts and their outcomes.
Worked example
Kofi sets daily, weekly and monthly governance routines, defines data incident severity with regulator communication, tests runbooks with a steward and designs a sustainable on-call rota.
Synthetic case. Operations are synthetic.
Errors and limits
Sending estimates silently damages trust; communicate delays.
Exercises
- EX109 — Triage time. By when do stewards triage alerts? Rubric: 3 = nine in the morning;; 2 = partly correct;; 1 = wrong;; 0 = none.
- EX110 — Reporting-day failure. What did the incident lead do when an extract failed on reporting day? Rubric: 3 = told the regulator figures would be a day late;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX111 — Runbook test. How are runbooks tested? Rubric: 3 = a steward who did not write them follows them on a synthetic incident;; 2 = partly correct;; 1 = vague;; 0 = none.
Continue studying — lesson 37 (chapter 37 of 50)
← Chapter 36 · Course chapter index · Chapter 38 →
Continue to the next authored lesson.