L2 Runbooks and Ownership
Runbooks describe step-by-step operational procedures that L2 must follow for recurring tasks and common issues.
Ownership
- Authoring and Updates: Product Engineering / Implementation team, with inputs from Tech BA, ETL Developer, and Metadata Architect.
- Execution: Client L2 Operations team.
- Approval: Implementation Manager / Project Manager, in alignment with client operations lead.
Minimum Runbooks Required for Canonical / Marketing Data Mart Flows
Runbooks should explicitly identify which steps are L2-only, and which steps require escalation before execution.
At minimum, the following runbooks must exist and be accessible to L2:
- Daily/Batch Execution Runbook
- How to verify all scheduled jobs for the canonical stack have run:
- Marketing Data Mart → LDZ ingestion
- LDZ → RDV transformations
- RDV / Mart → Canonical/UDS Interface Layer
- Interface Layer → Customer 360 / Campaign 360
- Expected run times and typical durations.
- Where to view status dashboards.
- Failure Handling Runbook (Per Layer)
- LDZ load failure (missing file, bad format, connectivity).
- RDV load failure (constraint violation, key mismatch, DV pattern violation).
- Interface Layer failure (schema mismatch, mapping metadata issue, transformation error).
- 360-layer failure (aggregations, joins, pre-aggregated tables, materialized views).
- Rerun and Backfill Runbook
- How to safely re-run a failed job for a specific date/batch.
- How to handle partial loads.
- Preconditions and post-checks for reruns.
- Release and Configuration Change Runbook
- How to validate after a code/config deployment.
- What basic smoke tests L2 must execute.
- Basic Data Validation Runbook (Non-Business)
- Row-count comparisons between layers where defined (e.g., LDZ vs RDV).
- Key technical checks (duplicate keys, nulls in non-null technical columns) when explicitly documented.