Přeskočit na obsah
BigTree108

Služby site reliability engineeringu

Služby site reliability engineeringu (SRE) pro systémy, které musí běžet: cíle úrovně služeb (SLO) a error budgety, observabilita pomocí OpenTelemetry, on-call a řízení incidentů, zátěžové testování a plánování kapacity, disaster recovery a chaos engineering a automatizace opakující se provozní práce, s dedikovanými site reliability inženýry pro váš tým nebo s SRE projekty dodanými na klíč.

Služby SRE, které poskytujeme

  • Observabilita od kódu po zákazníka

    Služby instrumentované pomocí OpenTelemetry, s metrikami, logy a trasami v Prometheus, Loki a Tempo pod Grafanou nebo v Datadog, New Relic, Dynatrace či Elastic, propojenými přes trace ID, takže jeden pomalý požadavek lze sledovat napříč všemi službami, kterých se dotkl.

  • Cíle úrovně služeb a error budgety

    Ukazatele měřené podle toho, co uživatelé zažívají, například latence a neúspěšné požadavky, cíle dohodnuté s product ownerem a upozornění na rychlost čerpání (burn rate) generovaná pomocí Sloth nebo Pyrra, takže vyčerpaný error budget předřadí práci na spolehlivosti před nové funkce.

  • Rotace on-call a alerting

    Rotace a eskalační politiky v PagerDuty, incident.io, Grafana IRM nebo Jira Service Management, upozornění zredukovaná tak, aby každé vyžadovalo člověka, runbook odkazovaný z každého vyvolání a rozpisy z Opsgenie převedené dřív, než ho Atlassian v dubnu 2027 vypne.

  • Řízení incidentů a postmortemy

    Úrovně závažnosti, vedoucí incidentu a frekvence aktualizací stavové stránky dohodnuté před prvním výpadkem, každý incident vedený ve vlastním kanálu Slack nebo Teams a postmortem bez hledání viníka, jehož opatření se sledují až do dokončení.

  • Automatizace rutinní práce a připravenost na produkci

    Opakující se provozní práce se nejprve změří a poté automatizuje: obnovy certifikátů, restarty, failovery a úklid zajišťují skripty a operátory Kubernetes, a než nová služba převezme produkční provoz, proběhne posouzení připravenosti.

  • Zátěžové a výkonnostní testování

    Zátěžové, stresové a soak testy v k6, Gatling, Locust nebo JMeter proti prostředím podobným produkci i v pipeline, s profilováním, které ukáže, kde se ztrácí čas, když test nesplní cíl.

  • Plánování kapacity a autoscaling

    Předpověď růstu ze skutečného provozu, autoscaling podle signálů, na kterých záleží, například délky fronty přes KEDA nebo počtu požadavků za sekundu, a rezerva ponechaná pro prodejní špičky i pro ztrátu celé zóny.

  • Cvičení disaster recovery

    Cíle doby obnovy (RTO) a bodu obnovy (RPO) stanovené pro každou službu, zálohy obnovované a regiony přepínané podle plánu a naměřený výsledek porovnaný s cílem, takže je známo, že plán obnovy funguje, dřív, než bude potřeba.

  • Chaos engineering

    Záměrně vyvolávané poruchy pomocí AWS Fault Injection Service, Azure Chaos Studio, Chaos Mesh nebo LitmusChaos: zastavená instance, zpomalená závislost, odpojená zóna, počínaje stagingem a přechodem do produkce, jakmile jsou systém i tým připraveni.

site reliability inženýři do vašeho týmu

  • Dedikovaní site reliability inženýři

    Site reliability inženýři, kteří nastoupí do vašeho týmu na plný úvazek, pracují ve vašich nástrojích a procesu a zodpovídají se vašemu vedoucímu. Pohovor s nimi vedete vy; my neseme ukrajinskou smlouvu, mzdy, fakturaci a dovolenou.

  • Projekty v oblasti „Site reliability engineering“

    Vymezená část práce v oblasti „site reliability engineering“ s rozsahem, pevným plánem a jmenovaným vedoucím na naší straně, který odpovídá za výsledek a o postupu informuje ve vašich kanálech.

  • Průběžná spolupráce v oblasti „site reliability engineering“

    Průběžná služba v oblasti „Site reliability engineering“: každý měsíc stejní lidé, backlog, kterému určujete priority, a hodiny, které vidíte v našem portálu i na faktuře.

Stránka o dedikovaném týmu vysvětluje, jak se specialisté připojují k vašemu týmu, a stránka o outsourcingu pokrývá dodávku projektů, převzetí systémů a jak účtujeme.

Kdo pracuje na vašem zadání v oblasti „site reliability engineering“

  • Site reliability inženýři

    Úrovně služeb, on-call, incidenty a automatizace

  • Inženýři observability

    Instrumentace, dashboardy a pravidla upozornění

  • DevOps a platform inženýři

    Pipeline, infrastruktura jako kód a Kubernetes

  • Inženýři výkonu

    Zátěžové testy, profilování a modely kapacity

  • Backend vývojáři

    Opravy poruch dohledaných až v kódu

Jak děláme SRE

Spolehlivost se určuje dohodou, a ne počtem upozornění: každá služba má cíle, které product owner odsouhlasil, upozornění se spouštějí, když se čerpá error budget, a ne při každém výkyvu CPU, a když se rozpočet vyčerpá, předchází práce na spolehlivosti nové funkce, dokud se nezotaví. Dashboardy, pravidla upozornění a runbooky žijí v Gitu vedle kódu a mění se přes pull requesty.

U systému, který postavil jiný tým, začínáme posouzením monitoringu, upozornění, minulých incidentů a plánů obnovy jen pro čtení a písemným seznamem rizik v pořadí podle dopadu. On-call začíná teprve tehdy, když se písemně dohodnou pokryté hodiny, doba reakce pro každou závažnost a eskalační cesta do vašeho týmu, a každý incident končí rozborem bez hledání viníka a opatřeními sledovanými až do dokončení.

Další služby cloudu, DevOps a bezpečnosti

Přehled: Cloud, DevOps a bezpečnost

Otázky k site reliability engineeringu

V jakých odvětvích pracují vaši site reliability inženýři?

Většinou ve fintechu a bankovnictví, kde se na platební a obchodní systémy vztahují přísné požadavky na dostupnost a pravidla odolnosti, například DORA; u poskytovatelů cloudu, hostingu a telekomunikací, jejichž zákazníci na dostupnosti závisejí; v e-commerce a maloobchodu s kapacitou plánovanou podle prodejních špiček; u podnikových SaaS produktů se závazky dostupnosti ve smlouvách; u zdravotnických platforem; u AI a datových produktů s GPU workloady a pipeline, které musí běžet; a u bezpečnostních firem.

Jaký je rozdíl mezi SRE a DevOps?

DevOps se věnuje tomu, jak se kód dostává do produkce: pipeline, infrastruktura jako kód a releasy. SRE se věnuje tomu, jak se kód chová, když už tam je: cíle dostupnosti a latence, monitoring, který je měří, on-call, reakce na incidenty a inženýrská práce, která odstraňuje opakující se poruchy. Většina týmů potřebuje obojí a my obsazujeme jedno i druhé.

S jakými nástroji pro observabilitu pracujete?

OpenTelemetry pro instrumentaci; Prometheus, Grafana, Loki, Tempo a Mimir, provozované vlastními silami nebo jako Grafana Cloud; Datadog, New Relic, Dynatrace, Elastic a Splunk; Azure Monitor, Amazon CloudWatch a Google Cloud Observability; a PagerDuty, incident.io a Grafana IRM pro on-call. Pracujeme v nástrojích, které už platíte.

Jak rychle mohou nastoupit site reliability inženýři?

Když je k dispozici ten pravý site reliability inženýr, začátek brzdí jen váš pohovor, NDA a převod práv duševního vlastnictví. Jinak vedeme hledání, které obvykle přinese profily kandidátů do dvou až tří týdnů, a nikdo nenastoupí, dokud neřeknete ano.

Jak probíhá najímání přes BigTree108 (role: site reliability inženýři)?

Řekněte nám, jakou práci, jakou seniority a kolik hodin potřebujete. Navrhneme jednoho nebo dva lidi s jejich profily, pohovoříte s nimi stejně jako s vlastním zaměstnancem a podepíšete jednu smlouvu s BIG TREE 108 LLC a budete dostávat jednu fakturu měsíčně.

Komu patří práce, kterou vytvářejí?

Vám. Každý specialista má podepsanou smlouvu s BigTree108, která převádí všechny výsledky práce na společnost, a naše smlouva s vámi je převádí dál. Kód, návrhy a dokumenty se dodávají do vašich vlastních repozitářů a nástrojů, ne do míst, kde je můžeme měnit jen my.

Potřebujete site reliability inženýry?

Napište nám, co běží v produkci, jak to monitorujete a co se v poslední době pokazilo. Odpověď dostanete do jednoho pracovního dne: plán, profily kandidátů nebo rozsah posouzení spolehlivosti.