SLA s vývojovým týmem: ticketing a doba zpracování

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 zasekne 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í s opisem 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, automatizované 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 ticketu 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 vývojové kapacity

Service Class	Popis	Příklady	Doporučené SLO (P85)
Expedite	Incidenty, penalizace, kritické chyby indexace	Robots.txt 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	Obyčejný 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 pipeline	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 (štítky/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 nezpřesnili mediány.

Fronty, WIP a Littleho zákon

Pro stabilitu lead time platí Littleho zákon: WIP = λ × CT (přibližně), kde λ je přírůstek ticketů a CT cycle time. Řízením WIP snižujete rozptyl a zkrácení 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)	Release frekvence	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: dle komponenty a WIP rovnoměrně rozděluje úkoly na dostupné vývojáře.
Propojení s PR: ticket key v názvu větve (feature/SEO-123-templates) a automatické odkazování.
Release notes bot: generuje changelog a publikuje ho do interní wiki + datasetu.

Feature flags a rollout strategie pro programmatic SEO

Flag-guarded templates: povolit per kategorie/segment, procentuální rollout.
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 releasu

Technická verifikace: dostupnost, render, strukturovaná data, sitemap/robots rozdíly.
Indexace: Time to Index, Indexation Rate per 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é metriky a Monte Carlo

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

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 „Fixed Date“ úkoly se odvozuje z P85 lead time a WSJF priority.

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 dle service class.
Zdraví release: Change Failure Rate, Time to Recover, rollbacky.
On-time delivery pro „Fixed Date“ úkoly.

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í dny. 4. Lead time: Standard P85 ≤ 10 pracovních dnů; Schema P85 ≤ 5 dnů. 5. Frekvence release: 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 key.
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).