Hoppa till innehåll
BigTree108

Tjänster inom site reliability engineering

Tjänster inom site reliability engineering (SRE) för system som måste vara tillgängliga: servicenivåmål och felbudgetar, observerbarhet med OpenTelemetry, jour och incidenthantering, belastningstester och kapacitetsplanering, katastrofåterställning och chaos engineering samt repetitivt driftarbete som automatiseras bort, med dedikerade site reliability-ingenjörer till ert team eller SRE-projekt som levereras från början till slut.

SRE-tjänster som vi erbjuder

  • Observerbarhet från kod till kund

    Tjänster instrumenteras med OpenTelemetry, med mätvärden, loggar och spår i Prometheus, Loki och Tempo under Grafana, eller i Datadog, New Relic, Dynatrace eller Elastic, kopplade med ett trace-ID så att en långsam förfrågan kan följas genom alla tjänster den berörde.

  • Servicenivåmål och felbudgetar

    Indikatorer som mäts utifrån det användarna upplever, till exempel latens och misslyckade förfrågningar, mål som överenskommits med produktägaren och burn rate-larm som genereras med Sloth eller Pyrra, så att en förbrukad felbudget flyttar tillförlitlighetsarbete före nya funktioner.

  • Jourscheman och larm

    Jourscheman och eskaleringspolicyer i PagerDuty, incident.io, Grafana IRM eller Jira Service Management, larm som rensas tills varje larm kräver en person, en runbook länkad från varje larm och Opsgenie-scheman som flyttas över innan Atlassian stänger ner tjänsten i april 2027.

  • Incidenthantering och postmortems

    Allvarlighetsgrader, en incidentledare och en takt för uppdateringar av statussidan som överenskommits före det första avbrottet, varje incident hanteras i en egen Slack- eller Teams-kanal och en skuldfri postmortem vars åtgärder följs upp tills de är klara.

  • Automatisering av repetitivt arbete och produktionsberedskap

    Repetitivt driftarbete mäts och automatiseras sedan: förnyelse av certifikat, omstarter, failovers och städning hanteras av skript och Kubernetes-operatorer, och en beredskapsgranskning görs innan varje ny tjänst tar produktionstrafik.

  • Belastnings- och prestandatester

    Belastnings-, stress- och uthållighetstester i k6, Gatling, Locust eller JMeter mot produktionslika miljöer och i pipelinen, med profilering för att hitta var tiden går när ett test missar sitt mål.

  • Kapacitetsplanering och autoskalning

    Tillväxtprognos utifrån verklig trafik, autoskalning på de signaler som spelar roll, till exempel könivå via KEDA eller förfrågningar per sekund, och marginal som reserveras för försäljningstoppar och för bortfall av en hel zon.

  • Övningar i katastrofåterställning

    Mål för återställningstid och återställningspunkt fastställs per tjänst, säkerhetskopior återställs och regioner växlas över enligt schema, och det uppmätta resultatet jämförs med målet, så att återställningsplanen är känd för att fungera innan den behövs.

  • Chaos engineering

    Fel som medvetet införs med AWS Fault Injection Service, Azure Chaos Studio, Chaos Mesh eller LitmusChaos: en instans stoppas, ett beroende saktas ned, en zon kapas, med start i staging och vidare till produktion när systemet och teamet är redo.

Anlita site reliability-ingenjörer

  • Dedikerade site reliability-ingenjörer

    Site reliability-ingenjörer som går med i ert team på heltid, arbetar i era verktyg och er process och rapporterar till er teamledare. Ni intervjuar dem; vi står för det ukrainska avtalet, lönen, faktureringen och ledigheten.

  • Projekt inom Site reliability engineering

    En avgränsad insats inom site reliability engineering med omfång, fast plan och en namngiven ledare hos oss som äger resultatet och rapporterar framsteg i era kanaler.

  • Löpande site reliability engineering

    Site reliability engineering som löpande tjänst: samma personer varje månad, en backlog ni prioriterar och timmar ni kan se i vår portal och på fakturan.

Sidan om dedikerade team förklarar hur specialister går med i ert team, och sidan om outsourcing beskriver projektleverans, övertaganden och hur vi debiterar.

Vilka som arbetar med site reliability engineering åt er

  • Site reliability-ingenjörer

    Servicenivåer, jour, incidenter och automatisering

  • Observerbarhetsingenjörer

    Instrumentering, instrumentpaneler och larmregler

  • DevOps- och plattformsingenjörer

    Pipelines, infrastruktur som kod och Kubernetes

  • Prestandaingenjörer

    Belastningstester, profilering och kapacitetsmodeller

  • Backend-utvecklare

    Åtgärder för fel som spårats tillbaka till koden

Så arbetar vi med SRE

Tillförlitlighet bestäms genom överenskommelse snarare än av antalet larm: varje tjänst har mål som produktägaren har godkänt, larm utlöses när felbudgeten förbrukas i stället för vid varje CPU-topp, och när budgeten tar slut går tillförlitlighetsarbete före nya funktioner tills den har återhämtat sig. Instrumentpaneler, larmregler och runbooks finns i Git bredvid koden och ändras via pull requests.

På ett system som ett annat team har byggt börjar vi med en skrivskyddad granskning av övervakning, larm, tidigare incidenter och återställningsplaner samt en skriftlig lista över risker i prioritetsordning efter effekt. Jouren startar först när de tider som täcks, svarstiden för varje allvarlighetsgrad och eskaleringsvägen in i ert team har överenskommits skriftligen, och varje incident avslutas med en skuldfri genomgång och åtgärder som följs upp tills de är klara.

Andra tjänster inom moln, DevOps och säkerhet

Översikt: Moln, DevOps och säkerhet

Frågor om site reliability engineering

Inom vilka branscher arbetar era site reliability-ingenjörer?

Främst fintech och bank, där betalnings- och handelssystem omfattas av stränga krav på tillgänglighet och av regler för motståndskraft som DORA; moln-, hosting- och telekomleverantörer vars kunder är beroende av deras tillgänglighet; e-handel och detaljhandel, med kapacitet planerad runt försäljningstoppar; SaaS-produkter för företag med åtaganden om tillgänglighet i sina avtal; vårdplattformar; AI- och dataprodukter med GPU-arbetslaster och pipelines som måste fortsätta köras; samt säkerhetsföretag.

Vad är skillnaden mellan SRE och DevOps?

DevOps handlar om hur koden når produktion: pipelines, infrastruktur som kod och releaser. SRE handlar om hur den beter sig när den väl är där: mål för tillgänglighet och latens, den övervakning som mäter dem, jour, incidenthantering och det tekniska arbete som tar bort återkommande fel. De flesta team behöver båda, och vi bemannar antingen den ena eller båda.

Vilka verktyg för observerbarhet arbetar ni med?

OpenTelemetry för instrumentering; Prometheus, Grafana, Loki, Tempo och Mimir, självhostade eller som Grafana Cloud; Datadog, New Relic, Dynatrace, Elastic och Splunk; Azure Monitor, Amazon CloudWatch och Google Cloud Observability; samt PagerDuty, incident.io och Grafana IRM för jour. Vi arbetar i de verktyg ni redan betalar för.

Hur snabbt kan site reliability-ingenjörer börja?

När rätt site reliability-ingenjör finns tillgänglig styrs starten bara av er intervju samt NDA och IP-överlåtelse. Annars gör vi en sökning, som vanligtvis ger kandidatprofiler inom två till tre veckor, och ingen börjar förrän ni har sagt ja.

Hur anlitar vi site reliability-ingenjörer via BigTree108?

Berätta om arbetet, senioriteten och de timmar ni behöver. Vi föreslår en eller två personer med deras profiler, ni intervjuar dem på samma sätt som ni skulle intervjua en egen anställning, och ni skriver under ett avtal med BIG TREE 108 LLC och får en faktura i månaden.

Vem äger arbetet de producerar?

Det gör ni. Varje specialist har ett undertecknat avtal med BigTree108 som överlåter allt arbetsresultat till bolaget, och vårt avtal med er överlåter det vidare. Kod, designer och dokument levereras in i era egna repositories och verktyg, inte på ett ställe där bara vi kan ändra dem.

Behöver ni site reliability-ingenjörer?

Berätta vad som körs i produktion, hur ni övervakar det och vad som har gått fel på senare tid. Ni får svar inom en arbetsdag: en plan, kandidatprofiler eller en avgränsning för en tillförlitlighetsgranskning.