Sådan bygger du et platformteam nu! hemmelighederne for vellykket teknik

TLDR; Skaleringshold er hårde. Et platformhold, der er gjort rigtigt, kan hjælpe med at lette vanskelighederne.
En platform midt i havet (En god metafor til den sædvanlige isolering af platformhold)

Hos Conde Nast International voksede vi fra et team på 20 ingeniører til under 100 på mindre end et år. Vi fandt ud af, at det at bygge et system, der vil blive brugt på mange markeder, har mange bevægelige dele og gentagelse. For eksempel genopbygning af infrastruktur og applikationskonfiguration. Tilføjelse af tredjeparts add-on software. Opbygning af applikationen vha. CDN-omdirigeringer. DNS-registrering og konfiguration.

Der var mange AWS-konti brugt af mange hold. Sporing af brugsovervågning var et rod. Enhver udvikler skal overveje, hvor og hvordan de kører deres system. De gør det normalt uafhængigt af hinanden. De skal overveje at overvåge og logge. Dette inkluderer også diverse undersystemer som implementering af kølogging og routing af trafik.

Der var mange ting, vi kunne have gjort for at gøre processen meget lettere og glattere. Dette er den primære årsag til, at vi besluttede at opbygge et infrastrukturhold derefter senere på et platformteam.

Platformteamet

Platformteamet

Platformteamet er ikke en del af produktteamene, men fungerer i stedet for et teknisk effektivitetsteam. Dette betyder, at platformteamets vigtigste klientel er produktteams. Det nævnte produktteam skal også lære om platformen generelt. Derefter rejse problemer og feed backs for kontinuerlig forbedring (den nye CI). Dette skulle ikke betyde, at platformteamet er isoleret med resten af ​​organisationen. Men snarere en vigtig spiller til organisationens succes.

Infrastrukturstyring er et af platformsteamets ansvar. Sikring af bedste praksis og dyb forståelse af infrastruktur i skyen eller på stedet. For eksempel at sørge for, at infrastruktur er revisionsdygtig. Dette kan implementeres på mange måder. Men den mest almindelige måde at implementere på er infrastruktur som kode (IAC).

IAC er aktiveret af infrastruktur som en service (IaaS). Platformteamet håndterer opbygning af IAC ved hjælp af værktøjer, der er åbne. dette betyder, at platformen, der bygges, er en abstraktion af værktøjerne. Disse værktøjer er løst forbundet, og integrationen af ​​disse værktøjer er platformen. Tænk på det som en platform som en service (PaaS), men tættere på hvad virksomheden bruger sager.

Vi vidste, hvorfor vi bygger platformteamet. Nu måtte vi lægge grundlaget, som platformteamet er bygget på. I modsætning til produkthold, som normalt har et synligt mål og mandater. Platformteam har flere ikke-funktionelle krav, vi var nødt til at definere dette dybtgående.

Her er min personlige beslutning om, hvordan man opbygger et vellykket platformteam.

Holdet og dets mandater

Mandater

Automatisering

Folk er tilbøjelige til fejl. Automation inden for platformen giver os mulighed for at være mere selvsikker, når vi udfører et stykke kode. Dette giver os mulighed for at isolere eventuelle fejl og fejl i koden. og udfør derefter kontinuerlig implementering.

Automatiske test er vigtige, uanset hvad der ikke testes, er endnu ikke fuldt implementeret. Der er mange slags test, der er nødvendige, afhængigt af hvilken slags software. F.eks. Enhed til ende fuzzing pen-test.

Sikkerhed er af største vigtighed, og automatiseret sikkerhedstest bør være en prioritet. Dette for at forhindre CORS angribe SQL-injektion og andet. Hvis du har dette, mindskes angrebets overflade.

Brug princippet om mindst privilegium, når du giver adgang. Sørg samtidig for at afbalancere dette med let adgang. En udvikler, der bruger en platform, der har brug for adgang hvert 5. sekund, er dårligt til interpersonelle relationer. Et platformteam skal være aktiverere ikke barrierer. Dette betyder, at man går meget langt for at opbygge relationer og muliggøre effektivitet i teamet.

Alt, hvad der skal gøres to gange, skal automatiseres. Hold til TØRR-princip så meget som muligt.
 
Platformen skal automatiseres for at fjerne kognitiv overhead. Hjælp os også med at være mere stabile som platform. Dette er ikke et alternativ til dokumentation og post mortems, men snarere et resultat af dem.

En stor del af automatiseringen er implementeringsstrategi og måling af implementeringer ved hjælp af metrics. Endelig planlægning af metrics mod kundeadoption.

Brug smarte implementeringer og forstå, hvornår de skal anvende. Eksempel på dette er følgende. Blågrønne implementeringer, a / b-test, automatiske tilbagekoblinger og nul viden tilbageførsler.

Effektivitet
Det er vigtigt at opbygge en yderst effektiv platform. Dette vil give os mulighed for at bevæge os hurtigere. Fixing af bugs hurtigt for at opbygge effektivitet. Og bygningsfunktioner på nødvendighedsbasis. Genbrug af kode og oprettelse af referenceimplementering er nøglen. Dette vil hjælpe den bredere virksomhed med at få en højere leveringstid til markedet såvel som en konkurrencefordel. Sørg for at dokumentere eventuelle kendte ukendte og kanter. Almindelige problemer og eskaleringsstier.

Effektivitet i platformen betyder også at fejle hurtigt og fikse den. Platformen skal være så gennemsigtig som muligt, når der vises fejl. Fejl fører derefter til hurtigere debugging og implementeringer. Effektiviteten ligger i at gentage små funktioner snarere end en stor implementering.

At have et eskalationssystem til videnbase er ikke en hindring. I stedet er det et sted at starte, når du føler dig fortabt. Dette med gode forhold giver produktive resultater og mere effektivt samarbejde. Hjælpe teams til at dele viden. De får erfaring med hinanden, og det er en god måde at opbygge et meget effektivt team.
 
Selvbetjening

Tilstrækkelig og kontinuerlig dokumentation er vigtig. Træning er nødvendig for udviklere. Overhead til uddannelse af nye udviklere bør tages i betragtning. Hver ny teknologi, vi anvender, har en overhead. Dette skal omhyggeligt overvejes, hvis omkostningen er værdien af ​​vedtagelsen. Interaktive træningslaboratorier og portalers udviklere er nyttige. Et sted, hvor vi kan finde opdagelse af mvp og referenceimplementering. Alt dette vil hjælpe os med at opnå selvforsyning.

Alle nye ingeniører skulle bygge noget ved hjælp af platformen deres første måned. Dette kan være en del af den oprindelige orientering af nyansatte. Dette vil også lade os afsløre problemer inden for platformens selvbetjeningskarakter. Også omskoling for hver nye del af platformen. At gøre DIY-opdagelse inden for platformen tilskyndes. At genopfinde hjulet og bruge skygge-IT frarådes aktivt. Vedligeholdelse af mange implementeringer af den samme ting er spildt og unødvendigt.

Overvågning af metrics og alarmeringssporing er kraftfulde værktøjer. SRE kan oprindeligt være en del af platformfunktionen integreret i kerneplatformteamet. Dette vil hjælpe SRE til at forstå den underliggende implementering af platformen.

Den vigtigste del af platformen er, at den er bygget til udviklere. Bestræbelse på at skabe balance mellem opbygning af bedste praksis og fremme mellemmenneskelig kommunikation. En selvbetjeningsplatform betyder, at du får know-how. Derefter forstå værdien af ​​at have en platform. Dette betyder, at udviklere undertiden vil have frustrationer. Feedback skal tages med i betragtning, mens platformen udvikles. Der skal være en måde at give feedback til platformudviklere og hvordan platformen har det generelt. Uden dette lever platformen isoleret med resten af ​​virksomheden. Vedtagelse vil være anstrengende i bedste fald. Folk ønsker at bruge og vedtage noget, de har det godt med at bruge. Når alt kommer til alt softwareudvikling er et menneskets centralt projekt. Kommunikation, interaktionsmotivation er en vigtig del af udviklingen. Vi er nødt til at perfektionere dette sammen med forretningskrav og frister. En ikke-eksisterende perfekt platform er til ingen nytte for nogen. En semi-funktionel og usikret platform er en forbandelse for enhver virksomhed.

Endelig vil der altid være ting, der er uden for platformens rækkevidde. Dette skal altid afgøres fra sag til sag. At vide, at folk stadig har brug for det i slutningen af ​​dagen, og du bliver nødt til at omdirigere anmodningen til et andet team. Eventuelt eskalerer det.

Holdplanlæggeren ser på holdet på højt niveau

principper

Holdet ønsker at stå op med sine beslutninger

Myndighed

På mange måder ligger succes eller fiasko for et platformteam i den beslutning, det træffer. Platformteamet skal tage beslutninger, der påvirker andre hold. Dette sker, mens platformen bygges. For eksempel sproget de værktøjer og rammer, vi bruger.

Platformteamets autoritet ligger ikke i håndhævelsen af ​​standarder. Men i den subtile styring af udviklingsholdet i den ene eller den anden beslutning. For eksempel at opbygge en anbefaling til logning. For at gøre det kompatibelt med en logningsparser under forsendelse af logfiler. At bygge ud hårde og hurtige standarder er ikke platformteamets ansvar. Udviklingsteamet bør selv have beføjelsen til at vælge og vælge. Ligesom værktøjsrammer og sprog finder det egnet til sager til egen brug. Når det er sagt, er der grundlæggende kræfter, der skal besluttes på forhånd. For eksempel brug af sky eller flere skyudbydere.

Sælgerlåsning er både en gave og en forbandelse for platformhold. Gave i den forstand, at disse beslutninger er truffet af andre hold. Dette betyder, at hold har bygget deres økosystem af værktøjer omkring en beslutning. Forbannelse, da vi er nødt til at leve disse beslutninger inden for en ansøgnings livscyklus. Eller tilføj en ekstra overhead til migrering. Et platformteam skal have synlighed og autoritet over den bredere organisation for at have en bedre chance for succes.

Drej det på denne måde. Vi mener, at DevOps ikke er en kultur

Forfølgelse og evangelisering

DevOps er en kultur, der ikke spiller en rolle. Platformteamet skal være i stand til at evangelisere dette.

Det sædvanlige mislykkede punkt i softwareudvikling er den manglende forståelse af, hvordan applikationen vil fungere under produktionsmiljøforhold.

Det første tekniske team, der letter kommunikation på tværs af team, er normalt platformsteamet. Derefter falder fortalerne for genanvendelse af kode og bedste praksis som standard for platformteamet. Ydeevne og pålidelighed bliver platformsteamets primære bekymring.

Ingeniøreffektivitet er konstant fortalere for platformteamet. Hele formålet med at opbygge platformteamet er, at ingeniører skal bygge mere med mindre kognitive overhead. Detaljerne, der kan genbruges og automatiseres, falder normalt til platformteamet.

Vi gør din platform stabil et anker ad gangen

Ansvarlighed

Med myndighed til at foretage ændringer i de grundlæggende byggesten i hvert af systemerne. En fejl eller en sårbarhed inden for en af ​​disse vil forårsage et kaskadeproblem. Resten af ​​ingeniørteamet vil derefter blive påvirket.

Ansvarlighed som et team er vigtigt for at sikre, at hver gang teamet foretager en banebrydende ændring, bliver resten af ​​teamet informeret.

Beklagelig post mortem er et krav for at få hvert medlem til at føle sig tryg ved at foretage ændringer. Opbygning af et bedre system på samme tid som ejerskab af systemet. Ansvaret for at skubbe til en supportmodel og operationer går derefter til platformen og SRE-teamet.

Ahm .. Så ikke alle har det samme job med at dreje dette hjul

ekspertise

Den erfaring og ekspertise, der kræves på platformteamet, afhænger af virksomhedens struktur.

For eksempel har nogle virksomheder et fungerende SRE-team, der tager sig af driften og driften af ​​hver applikation. Dette betyder, at skabelsen af ​​supportmodel ikke udelukkende er platformsteams ansvar.

Sælgerledelse er også en opgave, der kan delegeres til applikationssupporthold.

Men generelt er her den ekspertise, du har brug for inden for dit platformteam:

  • containerorkestrering og containerisering
  • skystyring
  • leverandørstyring
  • ledningsledelse
  • dns og cdn-konfiguration
  • serverkonfiguration
  • git og scm
  • produkt-ionisering
  • observerbarhed (sporingsovervågning af logging)
  • operationelisering (runbooks og support til eskalering af post mortems alarmering)
  • blød dygtighed og ledelse af mennesker
  • softwaredefineret infrastruktur (infrastruktur som kode)
  • samarbejde med andre teams og forhandling med ledelsen
  • fælles arbejdsgang og arkitekturstyring
  • sikkerhed
  • udvikleruddannelse og undervisning
  • dokumentationsudvikling

Ideelt set vil dine ingeniører have en domæneekspertise og derefter have god, fungerende viden om andre domæner.

Mit forslag til at opbygge ekspertisen er at skifte mellem medlemmer, så der er eksperter på domæneniveau. Derefter foretages en overlevering eller udfør ekstreme tabelparprogrammering. Sådan at overflødighed er indbygget i holdstrukturen.

I betragtning af platformsteamets enorme mandat. Vi kan med sikkerhed antage, at der skulle være et stort hold til at udføre alle disse aktiviteter parallelt. Nogle af opgaverne kan delegeres til applikationsteamet. Selvom det ville tilføje yderligere omkostninger til udvikling. Vi kunne også opdele dette hold, men det, når det håndteres forkert, kunne føre til yderligere forkert justering.

Det anbefales at have en semi-flad struktur med flere senior- og hovedingeniører, der kan tage en smidig beslutning. At have et stort team som dette med mange bevægelige dele ville betyde, at en teknisk hovedrolle er uegnet snarere at have en ingeniørchef for platform og løsningsarkitekt er vigtig.

Løsningsarkitekten kunne lægge køreplanen for platformteamet. Derefter koordineres det med resten af ​​ingeniørholdene. I denne proces kan vi også forstå organisationens behov. Og planlæg derefter, hvilke muligheder vi har brug for. Endelig kan løsningsarkitekten hjælpe med at lede valget af teknologier, der kan føjes til platformen.

Ingeniørchefen kunne hjælpe med at kommunikere og opbygge relationer. Dette er vigtigt af flere grunde. Først som et sandt tværfunktionelt team, vil antallet af anmodninger være stort. For det andet vil prioriteringen af ​​opgaver være af afgørende betydning for opbygningen af ​​kapaciteter.

Faktisk masser af bevægelig del. Men gjort rigtigt kan det være en lignende godt olieret maskine

epilog

Platformteamet er et nyt koncept aktiveret af nye teknologier, der kommer på markedet. Et godt eksempel på dette er kubernetes og dets allestedsnærværende. Dette nye team kan hjælpe virksomheden med let at opbygge muligheder. Skaleringshold har svært ved at have et nyt hold af aktiverere vil hjælpe holdet med at skalere hurtigere med mindre friktion. Dette er min personlige take baseret på erfaring, hvad der skal være kernen i dette team, og hvilken ekspertise, der er nødvendig for at blive indbygget i det.

Arbejd med os Tjek dette job hos Condé Nast International: https://www.linkedin.com/jobs/view/839478085

Deltag i vores community Slack og læs vores ugentlige Faun-emner ⬇

Hvis dette indlæg var nyttigt, skal du klikke på klappen knappen nedenfor et par gange for at vise din støtte til forfatteren! ⬇