Where we are
Session 3 wrote the contract; session 4 gave the platform underneath it a name and a set of tradeoffs. Tonight closes the loop with the discipline of actually running the thing day to day: the DataOps practices, the signals worth watching, and the promise that makes "late" a measurable fact rather than a Monday-meeting argument. This session owns three of Tideline's twenty planted defects, and it is worth being honest about exactly how much new ground they cover.
★ What you walk out with tonight. The two DataOps principles that change behaviour more than the other sixteen combined. The four golden signals translated line by line onto a pipeline. And a written freshness SLO with a real error budget, which is the single artifact most data teams have never produced for the dashboard everyone depends on most.
LiveThree defects, but an honest count of what is genuinely new3 min▶
This session owns D1 (no freshness stamp anywhere), D19 (no freshness promise, so the pipeline cannot be late) and D20 (no evidence the data was tested before it landed). Session 1's measured bench shows adding the DataOps and SRE lens moves the cumulative catch count from 17 to 19 - a gain of exactly two. D1 was already caught earlier, by the usability lens: a missing timestamp is a visible interface property, so Nielsen's heuristic 1, visibility of system status, flags it on its own.
The honest version: this lens contributes two genuinely new findings, D19 and D20, and its third finding, D1, was already covered by a lens that came before it. That overlap is not a flaw in the operating lens - it is the same lesson session 1 taught with IBCS and PAIR. What the operating lens adds that nothing else can is the reason D1 exists at all: without a stated promise, freshness has no target to be measured against, and a missing stamp is a symptom of that absence rather than an independent problem.
Tideline's data was silently partial one Sunday night this quarter. Nobody found out from the pipeline. A customer success manager found out on Monday because a churn number looked wrong, opened a ticket, and it took four hours to trace the number back to a load that had finished but only half-populated a table. There was no test that would have caught it before it landed, and no promise it broke, because none existed.
Self-studyWhy the operating lens sits after the platform lens3 min▶
Sequencing matters here. A promise about freshness only means something once you know what the platform underneath is actually capable of - session 4's PACELC tradeoff for the normal case sets the ceiling on what latency an SLO can honestly target. Promising a five-minute freshness window on top of a platform that was built to favour consistency over latency is not an operating problem, it is a platform problem wearing an operating costume. Tonight assumes the platform choice is already known and asks what discipline sits on top of it.
Eighteen principles, and the two that change behaviour
7 min liveThe DataOps Manifesto reads like a wall of text if you take it in one pass, so it helps to read it in the four clusters it actually falls into: how the team relates to its customer and to itself, how the work is engineered, how quality is enforced, and how the whole thing keeps improving.
LiveAll eighteen, by name, plus the later addition5 min▶
Primary-verified at dataopsmanifesto.org. The eighteen, grouped for readability rather than as a wall of eighteen bullets:
Team and customer. Continually satisfy your customer. Value working analytics. Embrace change. It's a team sport. Daily interactions. Self-organize.
Engineering practice. Reduce heroism. Reflect. Analytics is code. Orchestrate. Make it reproducible. Disposable environments.
Quality. Simplicity. Analytics is manufacturing. Quality is paramount. Monitor quality and performance.
Continuous improvement. Reuse. Improve cycle times.
A later addition, not in the original eighteen: start with data testing. It is usually cited alongside the eighteen because it directly addresses D20 - data landing untested is exactly the gap this addition was written to close.
LiveReduce heroism and analytics is manufacturing4 min▶
Reduce heroism names something most teams reward by accident: the engineer who fixes the pipeline at 11pm gets praised, and the praise teaches everyone that the correct response to a fragile system is a hero, not a fix. A team that reduces heroism treats a midnight save as a process failure to investigate, not a story to tell in standup.
Analytics is manufacturing reframes a pipeline run as a repeatable, monitored production process rather than a one-off craft output. A manufacturing line has statistical process control, defined tolerances and a stop-the-line rule. A pipeline treated as manufacturing gets the same: known-good ranges for row counts, an owner for out-of-tolerance runs, and a rule for when a bad batch should never reach the warehouse at all.
Tideline's Sunday-night partial load was quietly fixed by whichever engineer noticed it first, three separate times over the past year, by three different people, none of whom filed anything. Each fix was a small act of heroism. None of them changed the process that keeps causing the same failure.
Four golden signals, translated for a pipeline
6 min liveGoogle SRE's four golden signals were written for services, but each one has a direct, specific meaning on a data pipeline - close enough that a team that already monitors latency, traffic, errors and saturation on their APIs can extend the same habit to their data without inventing a new vocabulary.
LiveLatency, traffic, errors, saturation - the pipeline reading5 min▶
Rob Ewaschuk's chapter in Site Reliability Engineering, O'Reilly 2017, names the four signals for monitoring distributed services. The translation to a pipeline is close enough to be almost literal.
| Golden signal | On a data pipeline |
|---|---|
| Latency | Freshness lag - the time between an event happening and it being visible on the screen. |
| Traffic | Row volume - whether the batch that just landed is close to the size a normal day produces. |
| Errors | Failed loads, and the more dangerous case: loads that finish with no error but only partially wrote their data. |
| Saturation | Warehouse compute slots or queue depth approaching the ceiling the platform can actually serve. |
Errors is the signal worth instrumenting first if a team has none of the four today. A dashboard that only checks whether the job exited successfully will never catch a job that exited successfully having done half its job.
Self-studyThe Agile Manifesto as the DataOps ancestor3 min▶
The DataOps Manifesto is explicitly descended from the Agile Manifesto's twelve principles, published in 2001 and primary-verified at agilemanifesto.org. This session does not re-teach all twelve; the one worth citing directly is delivery cadence - Agile's principle of delivering working software frequently, in preference to a long release cycle, maps onto DataOps as shipping small, tested pipeline changes rather than a quarterly overhaul. The lineage matters more than the full list: DataOps is what happens when the Agile Manifesto's cadence and team principles are applied to a pipeline instead of an application.
A promise with an error budget is what makes lateness real
7 min live"The dashboard should be fresh" is not a promise, it is a wish. A promise has a target, a measurement window, and an explicit tolerance for missing it. Once that exists, a late dashboard is a fact you can point to, not an opinion someone can argue away in the Monday meeting.
LiveThe three parts of a promise that can be checked5 min▶
An SLO turns a hope into an instrument. It needs three parts, and a promise missing any one of them is not actually operable:
- A target - a specific number, such as 99 percent of loads landing within 30 minutes of the source event.
- A measurement window - the period the target is evaluated over, commonly a rolling 30 days, so one bad night does not sink the whole quarter's reputation on its own.
- An error budget - the amount of missing the target that is tolerated before it becomes an incident. If the target is 99 percent over 30 days, the budget is the 1 percent of loads allowed to miss - and once that 1 percent is spent, the next miss is treated as a real failure, not background noise.
The error budget is the part most teams skip, and it is the part that actually changes behaviour. Without it, every miss is treated the same, whether it is the first of the month or the fortieth, and nobody can say when "still fine" becomes "actually broken".
LiveTesting before the data lands, not after4 min▶
"Start with data testing" is the DataOps Manifesto's later addition, and it targets D20 directly: evidence the data was checked before a reader ever saw it, not after a reader complained. The cheapest version of this is a small set of assertions that run between the pipeline finishing and the data becoming visible - row counts within an expected range, no unexpected nulls in a key column, referential checks against a known dimension.
The distinction that matters is timing. A test that runs after the dashboard has already been read by three people is a post-mortem input, not a safeguard. A test that blocks the data from landing until it passes is the only version that actually prevents D20 from happening again.
The Sunday-night partial load would have been caught by one test: a row-count check against the trailing four-week average, with the load held back if it fell more than 30 percent short. That single assertion, run before the table became visible, would have turned a four-hour customer-facing mystery into a page nobody outside the data team ever saw.
Write Tideline's freshness promise
★ 17 min · everyone buildsThree things to produce, in order, using Tideline's actual Sunday-night incident as the material. Nothing here needs a tool - a promise is a sentence, a test is a name, and a display requirement is a short list.
1. Write the SLO. Fill in all three parts: a target (a percentage and a time window, such as "99% of loads land within 30 minutes"), a measurement window (such as "measured on a rolling 30 days"), and an error budget stated as a count or a percentage of tolerated misses. Write it as one sentence a non-technical stakeholder could read and understand what "late" means.
2. Name the one data test that would have caught the silent Sunday-night partial load. Be specific: what column or table, what check, and what threshold. "We should test the data more" does not count as an answer - "row count against the trailing four-week average, held back below 70 percent" does.
3. Decide what the screen must display so a reader can tell the promise was kept. At minimum this is a visible freshness stamp and a status against the SLO, not just a raw timestamp a reader has to interpret themselves. Write the exact words that should appear near the number.
Notice that step 3 retroactively fixes D1. A freshness stamp only becomes meaningful once there is a promise for it to be measured against - which is the honest reason this session's third defect was really session 1's usability lens borrowing a fix that only makes sense once the operating layer exists.
Before session 6
20 min- Ask the owner of your team's most-read pipeline whether a freshness SLO exists in writing anywhere. If the honest answer is no, that is the artifact to produce this week, using tonight's three-part template.
- Pick one dashboard and identify which of the four golden signals - latency, traffic, errors, saturation - it currently has zero instrumentation for. Errors is the most common gap; confirm whether that holds for yours.
- Find one place in your team's culture where a midnight fix was quietly praised rather than treated as a process failure. Write down what "reduce heroism" would have looked like instead.
- Bring the SLO. Session 6 starts making the surface honest about what it shows, and an SLO with no visible status on the screen is exactly the kind of half-finished promise that session will catch.
Three questions
Of the three defects this session owns - D1, D19, D20 - which one was already caught by an earlier lens in the course, and why?
D1 is a rendered, visible property of the screen, so a usability-only reviewer already catches it. D19 and D20 are the genuinely new findings this lens contributes, which is why the measured catch count only rises by two, from 17 to 19, not by three.
Why does an SLO need an error budget in addition to a target and a measurement window?
The error budget is what turns a target into an operable promise. It defines exactly how much missing is acceptable before a miss stops being background noise and starts being a real failure worth acting on.
Which golden signal did Tideline's Sunday-night incident reveal was never actually being measured?
The job exited successfully, so a monitor watching only for failed jobs saw nothing wrong. The gap was in errors: a silently-partial load is exactly the case that pure job-success monitoring cannot see.
What this session teaches, and where it came from
Every fact on this page, and its verification tier, is recorded in the course's source map.
Session 5 cheat sheet · pin this
The platform and the operating discipline are sound; now comes the part everyone actually looks at. Session 6 turns to the surface itself - the truncated axis with a lie factor of 6.5 to 1, the gauge spending a quarter of a panel on one number, and the thirteen colours fighting for attention on a single screen.