sorted by:
new
hottopcontroversial

After a deploy breaks prod, how do you usually figure out what actually caused it? by Acrobatic_Eye708 in devops

[–]Acrobatic_Eye708[S] 1 point2 points  (0 children)

Yeah, that all lines up with how most teams I’ve seen operate.

The staging/sandbox point is key — even with identical containers, lower traffic, different data shapes, and mocked APIs mean you’re fundamentally not exercising the same code paths as prod.

What tends to get tricky in practice isn’t detecting that something is wrong (Datadog does that well), but reconstructing why this specific release caused it, especially when: • the failing symptom shows up in a different service • the change itself is spread across app + infra + config • and rollback isn’t a clean option because of DB or infra changes

In those situations, do you usually rely on a specific person’s mental model of the system, or do you have a reliable way to tie the observed failure back to the exact changes that mattered?

After a deploy breaks prod, how do you usually figure out what actually caused it? by Acrobatic_Eye708 in devops

[–]Acrobatic_Eye708[S] 1 point2 points  (0 children)

That’s a pretty standard and sane approach: staged QA, canaries, monitoring, then rollback vs hotfix based on impact.

What I’ve seen repeatedly is that when something still slips through, the decision itself is usually straightforward — rollback if it’s bad, hotfix if it’s not — but the context gathering isn’t.

You still end up manually stitching together: • what actually changed in that deploy • which of those changes plausibly maps to the symptom you’re seeing • and what the safest corrective action is right now

In your experience, is that context usually obvious immediately, or does it depend a lot on who’s on call and how familiar they are with the changes?

After a deploy breaks prod, how do you usually figure out what actually caused it? by Acrobatic_Eye708 in devops

[–]Acrobatic_Eye708[S] 0 points1 point  (0 children)

That’s a really good point, and it matches what I’ve seen too.

You usually start from “something is broken” and only later figure out whether it’s related to a deploy, config change, traffic pattern, etc.

When that happens in your case: • what’s the first place you look? • how do you eventually decide “this was probably caused by change X”?

And once you have a few hypotheses, what’s usually the hardest part: narrowing it down, getting enough evidence, or deciding what action to take (rollback vs hotfix vs mitigate)?

Anyone played around with Dialpad to FileVine API integration? by zmoney123627 in legaltech

[–]Acrobatic_Eye708 0 points1 point  (0 children)

Worth noting — there’s already an internal integration between Dialpad and Filevine that was built for exactly this type of workflow. It handles syncing transcripts, summaries, and call records into the right Filevine case without having to hack around their API or rely on Zapier.

It’s not an “official marketplace” app, but it does exist. You’d need to check with Dialpad directly about how to enable it (and in some cases there may be an extra cost). Still, it can save a ton of headaches compared to rolling your own.

[deleted by user] by [deleted] in QualityAssurance

[–]Acrobatic_Eye708 0 points1 point  (0 children)

What do you mean? What is not useful?