66
@proof_pilar ·

How long should a first pipeline run before somebody has to touch it Orchestration

Built our first real scheduled pipeline about six weeks ago. It has needed manual intervention four times: an API rate limit, an upstream schema change, a disk filling up, and one thing I still cannot explain. I expected to build it and mostly forget it. Is four times in six weeks a sign I built it badly, or is this the job?

10 answers Share
Report

Answering anonymously — a moderator will review it first.

  • @coldstorage_cy · 10mo ago · 3 replies

    Four in six weeks for a first pipeline is unremarkable, and three of your four causes were external. Nobody builds something that survives an unannounced upstream schema change.

    What separates a good pipeline from a bad one is not that it never breaks, it is how fast you know and how cheap the recovery is. Ask yourself:

    • Did you find out from a monitor, or from a person asking why the dashboard was empty?
    • Could you rerun the failed day safely, or did it need surgery?
    • Did you add a check after each incident so that class of failure is now noisy rather than silent?

    If the answers are monitor, rerun and yes, you are doing this correctly and the count does not matter. The unexplained one is the only item on your list I would chase. Unexplained failures come back.

    62
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @coldstorage_cy · 10mo ago

      That is the one to fix. Alerting on data freshness rather than on task failure catches a whole category of silent problems.

      24
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
    • @proof_pilar · 10mo ago

      Two out of three. We found out from a person the first time and that was easily the worst one.

      20
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
  • @dbt_and_dust · 10mo ago · 3 replies

    Add a contract test on the upstream schema. Ten lines that fail loudly when a column type changes turn a mysterious 3am mess into a clear message before anything downstream runs.

    45
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @proof_pilar · 10mo ago

      Do you fail the run on a schema change, or warn and carry on with the columns you know?

      20
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
    • @dbt_and_dust · 10mo ago

      Fail on a type change or a missing column, warn on a new column. New columns are usually harmless and blocking on them trains people to ignore the alert.

      26
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
  • @goroutine_gil · 10mo ago

    The first six weeks is when you find all the assumptions. It gets quieter. It never becomes zero.

    18
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @arrayformula_al · 10mo ago · 3 replies

    Disk filling up is the one that is genuinely on you, and it will happen again. Set the alert at 70 percent, not 90.

    30
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @proof_pilar · 10mo ago

      We had no alert at all, which is how it became an incident rather than a chore.

      16
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
    • @arrayformula_al · 10mo ago

      Add a retention rule on the staging area at the same time. Almost every disk-full I have seen was old intermediate output nobody meant to keep.

      20
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report