Skip to main content

13.9 — Playbook, Interview & Production Checklist

13.118 Troubleshooting playbook​

When something breaks:

Step 1 — Define impact​

Who is affected?

Step 2 — Define time​

When did it start?

Step 3 — Find last known good​

What was the last confirmed healthy state?

Step 4 — Locate boundary​

Which layer first diverged?

Step 5 — Collect evidence​

Logs, metrics, lineage, source status.

Step 6 — Classify​

Connectivity, authentication, authorization, schema, data, runtime, scheduling, or consumption.

Step 7 — Recover​

Use the narrowest safe action.

Step 8 — Validate​

Freshness, completeness, correctness, performance.

Step 9 — Communicate​

State impact and recovery clearly.

Step 10 — Prevent​

Create the control that would have caught the incident earlier.

13.119 Architect decision framework​

When designing monitoring, ask:

  1. What can fail?
  2. How will we detect it?
  3. How quickly must we detect it?
  4. Who owns it?
  5. What evidence is required?
  6. What is the safe recovery?
  7. How do we validate recovery?
  8. What prevents recurrence?
  9. What does it cost to monitor?
  10. What happens at 10x and 100x scale?

13.120 Interview preparation — fundamentals​

Q1. What is the Data Integration Monitor?​

It is the operational interface for monitoring supported data-integration tasks and their execution history, status, schedules, and logs.

Q2. Is a successful task proof of correct data?​

No. It proves technical execution completed. Freshness, completeness, reconciliation, and semantic correctness require additional controls.

Q3. When would you use Data Pipeline Analyzer?​

When you need to understand where along an object's upstream pipeline errors, warnings, or data discrepancies originate.

Q4. When would you use View Analyzer?​

When investigating view-model complexity, performance, memory behavior, and potential persistence candidates.

Q5. Why monitor remote queries?​

Because federated workloads cross the Datasphere/source boundary and source-side latency or workload can dominate performance.

13.121 Interview preparation — intermediate​

Q1. How do you troubleshoot stale data?​

Start with the business freshness definition, identify the last successful watermark, inspect the relevant monitor and logs, follow upstream dependencies, verify source freshness, and reconcile the target.

Q2. How do you troubleshoot a failed task chain?​

Identify the first failed child, inspect its logs and dependencies, classify the cause, determine whether retry is safe, recover the failed scope, and validate downstream outputs.

Q3. Why is retry not always safe?​

Because a previous execution may have partially committed data, and a non-idempotent retry can create duplicates or inconsistent state.

Q4. How do you investigate a slow view?​

Baseline the workload, use Runtime Metrics, View Analyzer and Explain Plan where appropriate, inspect remote dependencies, identify the expensive component, change one variable, and re-measure.

13.122 Interview preparation — architect​

Q1. How would you design enterprise Datasphere observability?​

I would define monitoring across availability, execution, freshness, correctness, performance, security, and capacity; standardize SLOs and ownership; use native monitoring tools first; add operational reporting where native coverage is insufficient; and establish runbooks and RCA discipline.

Q2. How do you distinguish technical success from business success?​

Technical success means the workload completed. Business success additionally requires the data to be fresh, complete, accurate, semantically correct, authorized, and available within the business SLA.

Q3. How do you prevent monitoring from becoming expensive?​

Use native monitoring first, collect only actionable telemetry, define thresholds around business outcomes, aggregate operational metrics, and automate only high-value checks.

Q4. What is the architect's role in troubleshooting?​

The architect designs systems so that failures are observable, diagnosable, recoverable, and preventable. Troubleshooting is therefore part of architecture, not merely operations.

13.123 Production readiness checklist​

Monitoring​

  • Every critical task has an owner.
  • Task status is monitored.
  • Logs are accessible to operators.
  • Freshness is measured.
  • Critical data products have SLOs.
  • Data-quality controls exist.
  • Reconciliation exists for important measures.

Performance​

  • Critical views have a known baseline.
  • Runtime regressions are detectable.
  • Remote queries are understood.
  • Persistence decisions are documented.
  • Capacity trends are reviewed.

Recovery​

  • Retry behavior is understood.
  • Idempotency has been assessed.
  • Backfill procedures exist.
  • Runbooks exist.
  • Escalation contacts exist.
  • Recovery validation is documented.

Governance​

  • Monitoring access follows least privilege.
  • Audit requirements are understood.
  • Ownership is explicit.
  • Changes are traceable.
  • Evidence is preserved during incidents.

13.124 Monitoring maturity model​

Level 1 — Reactive​

Failure -> human notices

Level 2 — Monitored​

Failure -> alert

Level 3 — Diagnosable​

Failure -> alert -> logs -> root cause

Level 4 — Recoverable​

Failure -> alert -> runbook -> controlled recovery

Level 5 — Preventive​

Failure -> detection -> recovery -> RCA -> preventive control

Level 6 — Predictive​

Trend -> forecast -> proactive action

Enterprise architecture should target Level 5 or better for critical data products.

13.125 The architect's operating loop​

Use this loop continuously:

OBSERVE | v MEASURE | v DIAGNOSE | v RECOVER | v VALIDATE | v LEARN | v IMPROVE

This is the bridge between Datasphere development and enterprise platform engineering.

13.126 Final mental model​

Remember six layers:

  1. PLATFORM Is the service healthy?

  2. PIPELINE Is data moving?

  3. FRESHNESS Is data current?

  4. QUALITY Is data correct?

  5. PERFORMANCE Is the workload healthy?

  6. OPERATIONS Can we detect, recover, and prevent failure?

If you can answer all six, you are no longer merely monitoring tasks.

You are operating a data platform.

13.127 Official SAP documentation anchors​

Use current SAP documentation as the source of truth because monitoring capabilities and UI details evolve.

Key references:

Architect rule: Never diagnose a production Datasphere incident from a single green or red status. Correlate execution, lineage, freshness, correctness, performance, and business impact.