Společnost

SLA s vývojovým týmem: nastavení ticketingu a doby realizace

Natália Šimková 0

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, opakovatelné 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 toků práce: od nápadu po produkci

  1. Intake: standardizované zadání se schématem povinných polí (viz níže).
  2. Triage: posouzení priority, rizika, odhad námahy, přiřazení do služby/komponenty.
  3. Příprava: analýza, návrh, technické specifikace, závislosti, testovací případy.
  4. Implementace: vývoj, code review, automatické testy, feature flagy.
  5. Uvolnění (release): staging → produkce, smoke testy, měření dopadu.
  6. 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": "Sjednocení š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í zlepšení, refaktoring, DX Linting schémat, build pipelines Podíl kapacity ≥ 15 % / sprint

Definice SLA: odpověď, 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 release 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 vytvořen)
  • 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, aby nedošlo k zkreslení mediánů.

Fronty, WIP a Littleův zákon

Pro stabilitu lead time platí Littleův zákon: WIP = λ × CT (přibližně), kde λ je příliv ticketů a CT cycle time. Řízením WIP snižujete rozptyl a zkracujete lead time. Zaveďte WIP limity na 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 pro 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 flags a rollout strategie pro programmatic SEO

  • Flag-guarded templates: povolit pro kategorii/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 releasu

  1. Technická verifikace: dostupnost, render, strukturovaná data, sitemap/robots diffy.
  2. Indexace: Time to Index, Indexation Rate na cluster, logy crawl budgetu.
  3. Výkon: CTR, pozice, impression share, organické kliky; experimenty (A/B, CUPED, diff-in-diff).
  4. 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í práva definovaná v RACI.
  • Obnova: rollback/feature flag off, fix forward podle závažnosti.
  • Postmortem: bez obviňování; kořenová příčina, akční položky s termínem 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 historii cycle time s Monte Carlo simulací (10k běhů) na odhad termínů dodání. Výstupem je rozdělení dat (P50/P85/P95), které se transformuje 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ů dev práce. SLA pro „Fixed Date“ úlohy 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í releasu: Change Failure Rate, Time to Recover, rollbacky.
  • Doručení včas pro „Fixed Date“ úlohy.

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. Release frekvence: 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 tiket 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 šablony ticketů
Natália Šimková

Website:

Related Story