SLA s vývojovým týmem

Proč definovat SLA pro ticketing a lead time v programmatic SEO

V prostředí Měření, automatizace a programmatic SEO se marketingové a datové týmy opírají o rychlé iterace, kontrolované experimenty a distribuci změn ve velkém rozsahu (šablony, feedy, generativní obsah, interní prolinkování). Bez jasně definovaných SLA (Service Level Agreement) s vývojovým týmem se pipeline zadrhává při prioritizaci, validaci a release cyklu. Cílem tohoto článku je nabídnout operační rámec pro návrh, měření a správu SLA v kontextu ticketingu a lead time, se specifiky pro programmatic SEO (vyšší objem, opakované změny, měřitelné výstupy).

Termíny a pojmy: SLI, SLO, SLA, lead time, cycle time

SLI (Service Level Indicator): měřená veličina (např. „median lead time ticketů typu SEO-Template“).
SLO (Service Level Objective): cílová hodnota SLI (např. „P85 ≤ 5 pracovních dní“).
SLA (Service Level Agreement): závazek a pravidla (čas odezvy, čas vyřešení, eskalace, výjimky).
Lead time: čas od vytvoření ticketu po nasazení do produkce.
Cycle time: čas od začátku práce (např. „In Progress“) po nasazení.

Model pracovních toků: od nápadu po produkci

Intake: standardizované zadání se schématem povinných polí (viz níže).
Triage: posouzení priority, rizika, odhad námahy, přiřazení do služby/komponenty.
Příprava: analýza, návrh, technické specifikace, závislosti, testovací případy.
Implementace: vývoj, code review, automatické testy, feature flagy.
Uvolnění (release): staging → produkce, smoke testy, měření dopadu.
Ověření: validační metriky (indexace, logy, experimenty), report.

Standardní schéma ticketu pro programmatic SEO

Minimalistická, ale strojově čitelná struktura (JSON přiložený v tickete nebo formou polí):

{ "type": "SEO-Template|SEO-Feed|Schema|CrawlBudget|InternalLinking", "business_goal": "Zvýšení organické návštěvnosti kategorií X o +12 %", "hypothesis": "Zjednocení šablony H-Tags sníží duplicitu title/H1 a zlepší CTR", "impact_metric": "CTR|IndexationRate|TimeToIndex|Clicks|Impressions", "success_criteria": {"metric":"CTR","baseline":0.042,"target":0.048,"window_days":28}, "risk_level": "Low|Medium|High", "dependencies": ["FE-234","CMS-19"], "rollout_strategy": "feature_flag|canary|A/B", "test_plan": "unit|integration|e2e|structured-data-test", "data_owner": "@seo-analyst-1", "tech_owner": "@dev-lead-2", "deadline_type": "Soft|Hard", "deadline": "2025-11-15", "attachments": ["spec.md","wireframe.png"] }

Service classes a priority: jak mapovat marketingové potřeby na dev kapacitu

Service Class	Popis	Příklady	Doporučené SLO (P85)
Expedite	Incidenty, penalizace, kritické chyby indexace	Robots chybný, hreflang rozbitý	Odezva < 2h, vyřešení ≤ 24h
Fixed Date	Deadline daný kampaní/partnerem	Sezónní landingy, legislativní změna	Dodržení data ≥ 95 %
Standard	Standardní vývoj šablon, feedů, schémat	SEO šablona kategorie, JSON-LD rozšíření	Lead time ≤ 10 pracovních dní
Intangible	Interní vylepšení, refaktoring, DX	Linting schémat, build pipelines	Podíl kapacity ≥ 15 % / sprint

Definice SLA: odezva, triage, implementace, release

Time to Acknowledge (TTA): čas do reakce na nový ticket. SLA: P95 < 8 pracovních hodin.
Time to Triage (TTT): přesun do „Ready“ s vyplněnými poli. SLA: P90 < 2 pracovní dny.
Lead Time: Created → Deployed. SLA (Standard): P85 ≤ 10 pracovních dní.
Change Failure Rate: podíl releasů s rollbackem. SLO: ≤ 5 % měsíčně.
Time to Recover (incidenty SEO): P90 ≤ 24 hodin.

Měření lead time: eventy, logika, granularita

Doporučený event-based model (etikety/stavy v nástroji jako Jira/Azure DevOps/GitLab Issues):

created_at (ticket vznikl)
in_progress_at (první přechod do „In Progress“)
merged_at (PR/merge)
deployed_at (produkční release, build tag, commit SHA)

Lead time = deployed_at - created_at; Cycle time = deployed_at - in_progress_at. Reportujte P50/P85/P95 a IQR (Q3–Q1). Oddělte Expedite a Fixed Date od Standard, abyste nezkreslili mediány.

Fronty, WIP a Littleův zákon

Pro stabilitu lead time platí Littleův zákon: WIP = λ × CT (přibližně), kde λ je přítok ticketů a CT cycle time. Řízením WIP snižujete rozptyl a zkracujete lead time. Zavádějte WIP limity ve sloupcích In Progress a Code Review.

Matice SLA podle typu práce

Typ práce	TTA	TTT	Lead Time (P85)	Frekvence releasů	Poznámka
SEO-Template	< 8h	< 2d	≤ 10d	2–3× týdně	Nutné A/B nebo canary
SEO-Feed	< 8h	< 2d	≤ 7d	denně	Automatická validace dat
Schema/Structured Data	< 8h	< 1d	≤ 5d	denně	Lint + testy
Internal Linking	< 8h	< 2d	≤ 8d	2× týdně	Guardrails na crawl budget
Incident/Expedite	< 2h	< 4h	≤ 1d	ad hoc	Hotfix pipeline

Automatizace ticketingu: pole, validátory, šablony

Form validátory: bez business_goal, success_criteria a test_plan ticket neprojde.
Autotagging: NLP pipeline nad názvem/popisem přiřadí komponentu, typ práce, service class.
Auto-assign: podle komponenty a WIP rozloží úkoly na dostupné vývojáře.
Propojení s PR: ticket klíč v názvu větve (feature/SEO-123-templates) a automatické linkování.
Release notes bot: generuje changelog a publikuje ho do interní wiki + datasetu.

Feature flagy a rollout strategie pro programmatic SEO

Flag-guarded templates: povolit per kategorie/segment, procentuální rollouty.
Canary release: 5–10 % URL nebo sitemap-canary pro rychlou detekci regresí.
Kill switch: reverzibilní nasazení během indexačních oken.

Validace a měření dopadu po release

Technická verifikace: dostupnost, render, strukturovaná data, sitemap/robots diffs.
Indexace: Time to Index, Indexation Rate na cluster, logy crawl budgetu.
Výkon: CTR, pozice, impression share, organické kliky; experimenty (A/B, CUPED, diff-in-diff).
Bezpečnostní guardrails: anomálie v 404/500, nárazové nárůsty duplicitních URL.

Incident management a SLA na zotavení

Detekce: alerty na pokles indexace > X p.b., nárůst chyb renderu, změny robots/hreflang.
Reakce: TTA < 2h, koordinovaný war room, rozhodovací pravomoci definované v RACI.
Obnova: rollback/feature flag off, fix forward dle závažnosti.
Postmortem: bez obviňování; kořenová příčina, akční položky s deadline a ownerem.

RACI a odpovědnosti

Aktivita	Responsible	Accountable	Consulted	Informed
Triage ticketu	SEO PM	Dev Lead	Data Analyst	Stakeholder
Návrh šablony	FE Engineer	Tech Lead	SEO Architect	SEO PM
Release	DevOps	Engineering Manager	QA	Marketing
Incident	On-call	Engineering Manager	SEO PM	Leadership

Forecasting lead time: historická data a Monte Carlo

Pro plánování kapacity kombinuje přístup historii cycle time s Monte Carlo simulací (10k běhů) pro odhad termínů dodání. Výstupem je rozdělení dat (P50/P85/P95), které se převedou do SLO pro úlohy „Fixed Date“.

WSJF a cost of delay: rámec pro prioritizaci

Weighted Shortest Job First:

WSJF = (Business Value + Time Criticality + Risk Reduction/Opportunity Enablement) / Job Size

V programmatic SEO se Business Value odhaduje z očekávaného nárůstu organické návštěvnosti/konverzí, Time Criticality z indexačních oken/sezóny a Job Size z odhadů vývojové práce. SLA pro úlohy „Fixed Date“ se odvodí z P85 lead time a WSJF pořadí.

Dashboard SLA: co reportovat

Lead/Cycle time (P50/P85/P95) podle typů práce a týmů.
WIP a průtok: počet ticketů v každém stavu, throughput za sprint/týden.
Dodržení SLO: % ticketů v limitu podle service class.
Zdraví release: Change Failure Rate, Time to Recover, rollbacky.
On-time delivery pro úlohy „Fixed Date“.

Příklad SLA dokumentu (výňatek)

1. Rozsah: SEO-Template, SEO-Feed, Schema, Internal Linking, Incidenty. 2. Odezva: TTA P95 < 8h (Expedite < 2h). 3. Triage: TTT P90 < 2 pracovních dnů. 4. Lead time: Standard P85 ≤ 10 pracovních dní; Schema P85 ≤ 5 dní. 5. Frekvence releasů: min. 2× týdně (Standard), denně (Schema/Feed). 6. Incidenty: Time to Recover P90 ≤ 24h; postmortem do 72h. 7. Eskalace: po překročení SLO → Dev Lead → EM → CTO do 24h. 8. Výjimky: Hard deadline → přednostní zpracování (Fixed Date). 9. Reporting: týdenní dashboard + měsíční retrospektiva.

Integrace a datové toky

Ticketing API → DWH (eventy stavů, vlastní pole) → metrické tabulky.
CI/CD → release eventy (tagy, SHA, artefakty) → mapování na ticket klíče.
Web telemetry → technická validace po releasu (render, chybovost, Core Web Vitals).
SEO data → indexace, CTR, pozice → výpočet dopadu.

Údržba SLA: retrospektiva, error budget, iterace

SLA není statická smlouva. Každý kvartál:

Vyhodnoťte error budget (porušení SLO) a příčiny (kapacita, závislosti, kvalita specifikací).
Revidujte SLO podle reality (nový mix práce, sezónnost, reorganizace).
Aktualizujte šabl