Monitorujte third-party závislosti
Většina produkčních drift incidentů přichází z kódu, který neovládáte: partnerská API, vendor status pages, pricing podmínky a právní texty, které vaše workflow bere jako kontrakty.
Tento návod je engineering playbook pro monitoring externích závislostí s ownershipem, deterministickými diffy a uzavíráním incidentů.
Tiering závislostí a model ownershipu
Než vytvoříte monitory, definujte tiery:
- Tier 1 (customer-path critical): auth, payments, shipping, identity.
- Tier 2 (operational critical): enrichment, analytics, support tooling.
- Tier 3 (policy/informational): právní podmínky, pricing copy, dokumentace a changelogy.
Pro každou závislost určete:
- Service owner: odpovídá za chování integrace.
- Responder: on-call engineer, který acknowledgedne incidenty.
- Escalation owner: team lead nebo PM owner pro business-impact rozhodnutí.
Bez ownera neexistuje cesta k vyřešení.
Monitoring matrix vlastněná engineeringem
| Povrch závislosti | Typ monitoru | Fokus driftu | Kadence | Owner |
|---|---|---|---|---|
| Odpověď partnerského API | JSON/API | změny polí, typů a requiredness | 5 min až 30 min | Service owner |
| Vendor status page | HTML | status bloky incidentů, sekce root cause | 5 min až 30 min | SRE/on-call |
| Pricing/plan kontrakt | HTML | řádky plánů, text kvót, billing terms | 30 min až 24 h | PM owner + service owner |
| Právní podmínky / privacy | HTML | text klauzulí, verze/datum, rozsah policy | 24 h | Compliance owner |
| Integrační dokumentace | HTML + JSON | auth příklady, příklady response schémat | 30 min až 24 h | Integration owner |
Příklad provozní konfigurace
dependency: stripe-api
tier: tier-1
owner: payments-service
responder: sre-oncall
monitor:
type: json
checkInterval: 30m
selectJsonPaths:
- data.version
- data.contract
- errors[*].code
ignoreJsonPaths:
- meta.requestId
- meta.generatedAtPoužijte to jako výchozí šablonu a potom ji zpřísněte podle konkrétní závislosti.
V čem je DiffMon jiný
DiffMon je postavený pro contract monitoring, ne pro generické hlídání stránek:
- Structured diffs: změny na úrovni kontraktu místo čistě screenshotového šumu.
- Incident workflow: detekce, acknowledge, resolve a explicitní ownership.
- Přijetí baseline: očekávané rollouty označíte jako nový baseline bez ztráty historie.
- Delivery logy + request ID: přesně vidíte, co bylo odesláno a co selhalo.
- Webhooky připravené na automation: stabilní envelope (
schemaVersion: "v1") pro spolehlivé integrace.
Praktické produktové vstupy:
Příklad webhook routingu
Headers:
X-Diffmon-Timestamp: <unix-seconds>
X-Diffmon-Signature: v1=<hex>
Canonical signing input:
v1:<timestamp>:<rawBody>Před vytvořením nebo aktualizací downstream incidentů ověřujte podpisy a deduplikujte podle identity eventu nebo fingerprintu.
FAQ
Jakou sadu závislostí monitorovat jako první?
Začněte Tier 1 závislostmi v customer-critical tocích, kde contract drift může přímo rozbít produkční chování.
Kdo by měl vlastnit incidenty způsobené driftem závislostí?
Service owner by měl zůstat accountable, zatímco on-call respondenti provádějí triáž a eskalují podle závažnosti v runbooku.
Potřebujeme API i HTML monitoring?
Ano. Mnoho incidentů vzniká kvůli schema driftu API, zatímco business a compliance riziko často žije v HTML kontraktních plochách.
Další kroky
- Vytvořte inventář závislostí se sloupci tier, owner a responder.
- Nejdřív spusťte monitory pro Tier 1 a Tier 2 závislosti.
- Všechny diff eventy routeujte nejdřív do jednoho sdíleného incident kanálu a až potom podle týmů větvěte.
- Jednou týdně projděte delivery logy a odstraňte tiché integrační chyby.
Související návody
- Jak detekovat breaking změny API v produkci
- Change detection vs visual regression testing
- Průvodce detekcí změn na webu
Začněte monitorovat s DiffMonem
Spusťte API change monitoring pro partnerské kontrakty, přidejte website change detection pro status, právní a pricing surfaces a slaďte interval i delivery policy na pricing.