DevOps-teamtopologier

Fördelningen av roller, ansvarsområden och förtroende mellan IT-team och programteam är av största vikt för den operativa omvandling som ingår i molnimplementeringen i stor skala.

IT-teamen strävar efter att behålla kontrollen. Programägare försöker maximera flexibiliteten. Den balans som du slutligen skapar mellan dessa två mål påverkar i hög grad framgången för din molndriftsmodell.

Enligt Conways lag producerar team arkitekturer baserat på deras kommunikationsstruktur. Att förstå den här principen är viktigt när du arbetar för att uppnå den nödvändiga balansen mellan autonomi och kontroll. Alla organisationer som utformar ett system (definieras brett) skapar en designstruktur som är en kopia av organisationens kommunikationsstruktur.

Ur ett DevOps-perspektiv måste organisationer optimera för snabba svar på kundernas behov. Team som äger, utformar och implementerar sina program och system finner sin högsta grad av autonomi i arkitekturer med följande egenskaper:

• Evolutionär arkitektur som stöder konstanta ändringar
• Distributionsbarhet
• Testbarhet

Conways lösning är att utmanövreras Conways lag. Om din organisation följer en viss struktur för att producera tjänster och produkter och vill optimera, måste du tänka om din organisationsstruktur. Utveckla ditt team och din organisationsstruktur för att uppnå önskad arkitektur.

Den här principen leder till avsiktligt utformade teamtopologier där team ansvarar för alla program, system eller plattformar som de äger från slutpunkt till slutpunkt för att uppnå hela devops-området.

Följande tabell innehåller en förenklad kategorisering av dessa team.

Teamtyp	Definition
Programarbetsbelastningsteam	Dessa team skapar program som leder till direkta affärsresultat för ett segment av affärsdomänen. När det gäller Azure-landningszoner ansvarar dessa team för livscykeln för programarbetsbelastningar från slutpunkt till slutpunkt.
Plattformsteam	Dessa team skapar övertygande interna plattformar för att påskynda leveransen och minska den kognitiva belastningen för programarbetsbelastningsteam. När det gäller Azure-landningszoner ansvarar dessa team för livscykeln från slutpunkt till slutpunkt för Azure-landningszonen.
Aktivera team	De här teamen hjälper till att övervinna kunskapsluckor genom att hjälpa andra team med specialiserade funktioner som DevOps.

Utformningsbeaktanden

• Upprätta ett tvärfunktionellt plattformsteam för att utforma, skapa, etablera, hantera och underhålla livscykeln för Azure Landing Zone. Det här teamet kan inkludera medlemmar från ditt centrala IT-team, säkerhet, efterlevnad och affärsenheter för att säkerställa att ett brett spektrum av ditt företag representeras. Se till att du undviker antimönster.

• Överväg att etablera ett aktiveringsteam som kan tillhandahålla DevOps-funktioner för att stödja program och plattformar som inte har befintliga DevOps-funktioner, eller ett affärsfall för att upprätta en (till exempel äldre program med minimala utvecklingsfunktioner).

• Begränsa inte dina programarbetsbelastningsteam till centrala artefakter, eftersom det kan hindra deras flexibilitet. Du kan använda principdriven styrning och rollbaserad åtkomstkontroll i Azure (Azure RBAC) för att framtvinga konsekventa baslinjekonfigurationer och se till att programteam (affärsenhet) är tillräckligt flexibla för att förnya men ändå kunna dra nytta av en fördefinierad uppsättning mallar.

• Tvinga inte dina programteam att använda en central process- eller etableringspipeline för instansiering eller hantering av programresurser. Befintliga team som redan förlitar sig på en DevOps-pipeline för programleverans kan fortfarande använda sina aktuella verktyg. Kom ihåg att du kan använda Azure Policy för att framtvinga organisationsstandarder och utvärdera efterlevnad i stor skala och hantera säkerhetsöverväganden för dina DevOps-processer.

• Generell tillämpning av en DevOps-modell etablerar inte omedelbart kompatibla DevOps-team.

• Investeringar i tekniska funktioner och resurser är avgörande.

• Programteam för vissa äldre program kanske inte har de tekniska resurser som krävs för att överensstämma med en DevOps-strategi.

Designrekommendationer

Följande avsnitt innehåller designrekommendationer som hjälper dig att utforma teamtopologier.

Justera teamtopologier med din molndriftsmodell

Se till att du justerar dina teamtopologier med önskad molndriftsmodell.

Upprätta en grundläggande process för operativa fitnessgranskningar så att du fullt ut förstår de problem som kan uppstå från dina teamstrukturer.

Definiera funktioner för ditt plattformsteam

Följande lista innehåller en rekommenderad uppsättning funktioner för plattformsteamet som ansvarar för dina Azure-landningszoner:

• Arkitekturstyrning
• Prenumerationsetablering och delegering av nödvändiga principer för nätverks-, identitets- och åtkomsthantering
• Plattformshantering och övervakning (holistisk)
• Kostnadshantering (holistisk)
• Plattform som kod (hantering av mallar, skript och andra tillgångar)
• Övergripande åtgärder i Microsoft Azure i din Microsoft Entra-klientorganisation (hantering av tjänstens huvudnamn, Registrering av Microsoft Graph API och rolldefinitioner)
• Azure RBAC (holistiskt)
• Nyckelhantering för centrala tjänster (enkelt protokoll för e-postöverföring och domänkontrollanter)
• Principhantering och tillämpning (holistisk)
• Säkerhetsövervakning och granskningar (holistiska)
• Nätverkshantering (holistisk)

Definiera funktioner för dina programarbetsbelastningsteam

Följande lista innehåller en rekommenderad uppsättning funktioner för dina programteam som ansvarar för programarbetsbelastningar:

• Skapa och hantera programresurser via en DevOps-modell
• Databashantering
• Programmigrering eller transformering
• Programhantering och övervakning (programresurser)
• Azure RBAC (programresurser)
• Säkerhetsövervakning och granskningar (programresurser)
• Hantering av hemligheter och nycklar (programnycklar)
• Kostnadshantering (programresurser)
• Nätverkshantering (programresurser)

Definiera funktioner för att aktivera team

Följande lista innehåller en rekommenderad uppsättning funktioner för ett aktiveringsteam som ansvarar för att hjälpa dina andra team:

• Definition av vägledning och funktioner för horisontell (korsfunktion) som hjälper dig att få rätt expertis i hela organisationen, vilket säkerställer anpassningen till din övergripande molndriftsmodell (till exempel DevOps)
• Stöd, utbildning och coachning för andra team för att nå den nödvändiga kompetensnivån
• Upprätta en gemensam uppsättning återanvändbara mallar och bibliotek för dina program- eller plattformsteam och främja InnerSourcing, till exempel Azure-verifierade moduler.

Definiera interaktionslägen mellan team

Målen med interaktioner mellan dina team är att:

• Uppnå autonomi
• Avblockera beroenden
• Minimera avfallstiden
• Undvik flaskhalsar

Teamtopologier beskriver tre teaminteraktionslägen:

Interaktionsläge	beskrivning
Samarbete	Teamen arbetar nära varandra.
X som en tjänst	Teams använder eller tillhandahåller något till andra team med minsta möjliga samarbete, ungefär som interaktioner med tredjepartsleverantörer.
Underlätta	Team hjälper eller får hjälp av ett annat team att ta bort hinder.