Come costruire un team di piattaforma ora! i segreti dell'ingegneria di successo

TLDR; I team di ridimensionamento sono difficili. Un team di piattaforma fatto bene può aiutare ad alleviare le difficoltà.
Una piattaforma in mezzo al mare (una buona metafora per il solito isolamento dei team della piattaforma)

In Conde Nast International siamo passati da un team di 20 ingegneri a meno di 100 in meno di un anno. Abbiamo scoperto che la costruzione di un sistema che verrà utilizzato in molti mercati ha molte parti mobili e ripetizioni. Ad esempio ricostruendo l'infrastruttura e la configurazione dell'applicazione. Aggiunta di software aggiuntivo di terze parti. Creazione dell'applicazione mediante reindirizzamenti CDN. Registrazione e configurazione DNS.

C'erano molti account AWS utilizzati da molti team. Il monitoraggio del monitoraggio dell'utilizzo è stato un disastro. Ogni sviluppatore deve pensare a dove e come eseguire il proprio sistema. Di solito lo fanno indipendentemente l'uno dall'altro. Devono pensare al monitoraggio e alla registrazione. Ciò include anche sottosistemi vari come la registrazione in coda che distribuisce e instrada il traffico.

Ci sono state molte cose che avremmo potuto fare per rendere il processo molto più semplice e fluido. Questo è il motivo principale per cui abbiamo deciso di creare un team di infrastrutture e successivamente un team di piattaforme.

Il team della piattaforma

Il team della piattaforma

Il team della piattaforma non fa parte dei team del prodotto, ma agisce invece come un team di efficienza ingegneristica. Ciò significa che la principale clientela del team della piattaforma sono i team del prodotto. Detto questo, il team del prodotto deve anche conoscere la piattaforma in generale. Quindi sollevare problemi e feedback per il miglioramento continuo (il nuovo elemento della configurazione). Ciò non dovrebbe significare che il team della piattaforma sia isolato con il resto dell'organizzazione. Ma piuttosto un attore vitale per il successo dell'organizzazione.

La gestione delle infrastrutture è una delle responsabilità del team della piattaforma. Garantire le migliori pratiche e una profonda conoscenza dell'infrastruttura nel cloud o in loco. Ad esempio, assicurarsi che l'infrastruttura sia in grado di controllare. Questo può essere implementato in molti modi. Ma il modo più comune di implementazione è l'infrastruttura come codice (IAC).

IAC è abilitato da infrastruttura come servizio (IaaS). Il team della piattaforma gestisce la creazione di IAC utilizzando strumenti di provenienza aperta. questo significa che la piattaforma in costruzione è un'astrazione degli strumenti. Questi strumenti sono vagamente connessi e l'integrazione di questi strumenti è la piattaforma. Pensalo come una piattaforma come servizio (PaaS) ma più vicino a ciò che i casi d'uso dell'azienda.

Sapevamo perché stavamo costruendo il team della piattaforma. Ora abbiamo dovuto gettare le basi su cui è costruito il team della piattaforma. A differenza dei team di prodotti che di solito hanno obiettivi e mandati visibili. Il team della piattaforma ha requisiti più non funzionali, abbiamo dovuto definirlo in modo approfondito.

Ecco la mia opinione personale su come costruire un team di piattaforme di successo.

La squadra e i suoi mandati

mandati

Automazione

Le persone sono soggette a errori. L'automazione all'interno della piattaforma ci consente di essere più sicuri nell'esecuzione di un pezzo di codice. Questo ci consente di isolare eventuali bug ed errori all'interno del codice. e quindi eseguire una distribuzione continua.

I test automatizzati sono importanti, tutto ciò che non è stato testato non è ancora completamente implementato. Esistono molti tipi di test a seconda del tipo di software. Ad esempio test di penna fuzzing end-to-end unità di integrazione.

La sicurezza è fondamentale e la verifica automatizzata della sicurezza dovrebbe essere una priorità. Questo per evitare che CORS attacchi l'attacco SQL e altro. Avere questo ridurrà la superficie di attacco.

Utilizzare il principio del privilegio minimo ogni volta che si dà accesso. Allo stesso tempo, assicurati di bilanciarlo con facilità di accesso. Uno sviluppatore che utilizza una piattaforma che necessita dell'accesso ogni 5 secondi è dannoso per le relazioni interpersonali. Una squadra della piattaforma dovrebbe essere abilitanti non ostacoli. Questo significa fare di tutto per costruire relazioni e consentire l'efficienza nel team.

Tutto ciò che deve essere fatto due volte dovrebbe essere automatizzato. Attenersi al principio DEUMIDIFICAZIONE il più possibile.
 
La piattaforma dovrebbe essere automatizzata per rimuovere il sovraccarico cognitivo. Aiutaci anche ad essere più stabili come piattaforma. Questa non è un'alternativa alla documentazione e ai post mortem, ma piuttosto un loro risultato.

Una grande parte dell'automazione è la strategia di distribuzione e la misurazione delle implementazioni utilizzando le metriche. Finalmente tracciare le metriche contro l'adozione da parte dei clienti.

Usa distribuzioni intelligenti e capire quando applicare. Esempio di questo sono i seguenti. Distribuzioni verde blu, test a / b, rollback automatici e rollback a conoscenza zero.

Efficienza
Costruire una piattaforma altamente efficiente è importante. Questo ci permetterà di muoverci più velocemente. Correzione rapida di bug per aumentare l'efficienza. E la costruzione di funzionalità per necessità. Riutilizzare il codice e creare l'implementazione di riferimento è la chiave. Ciò aiuterà le aziende più grandi a ottenere un lead time di mercato più elevato nonché un vantaggio competitivo. Assicurati di documentare eventuali incognite e casi limite noti. Problemi comuni e percorsi di escalation.

L'efficienza nella piattaforma significa anche fallire velocemente e risolverlo. La piattaforma dovrebbe essere il più trasparente possibile quando si mostrano errori. Gli errori porteranno quindi a debug e implementazioni più rapidi. L'efficienza sta nell'iterare piccole funzionalità piuttosto che in una grande distribuzione.

Avere un sistema di escalation per la base di conoscenza non è un ostacolo. Invece è un punto di partenza ogni volta che ti senti perso. Questo con buone relazioni produce risultati produttivi e una cooperazione più efficiente. Aiutare i team a condividere le conoscenze. Faranno esperienza l'uno con l'altro ed è un buon modo per costruire un team altamente efficiente.
 
Fai da te

È necessaria una documentazione sufficiente e continua. La formazione è necessaria per gli sviluppatori. Il sovraccarico della formazione dei nuovi sviluppatori dovrebbe essere preso in considerazione. Ogni nuova tecnologia che adottiamo ha un sovraccarico. Ciò richiede un'attenta considerazione se l'overhead vale il valore dell'adozione. I laboratori di formazione interattiva e il portale degli sviluppatori sono utili. Un luogo in cui possiamo fare scoperta di mvp e implementazione di riferimento. Tutto ciò ci aiuterà a raggiungere l'autosufficienza.

Tutti i nuovi ingegneri dovrebbero costruire qualcosa utilizzando la piattaforma nel loro primo mese. Questo può far parte dell'orientamento iniziale dei nuovi assunti. Questo ci permetterà anche di scoprire problemi all'interno della natura self service della piattaforma. Anche riqualificazione per ogni nuova parte della piattaforma. È incoraggiato fare scoperte fai-da-te all'interno della piattaforma. Reinventare la ruota e utilizzare l'ombra IT è attivamente scoraggiato. Il mantenimento di molte implementazioni della stessa cosa è dispendioso e non necessario.

Il monitoraggio delle metriche e la traccia degli avvisi sono strumenti potenti. SRE può inizialmente far parte della funzione di piattaforma incorporata nel team della piattaforma principale. Ciò aiuterà SRE a comprendere l'implementazione sottostante della piattaforma.

La parte più importante della piattaforma è che è costruita per gli sviluppatori. Sforzarsi di equilibrare lo sviluppo delle migliori pratiche e la promozione della comunicazione interpersonale. Una piattaforma self-service significa che avrai il know-how. Quindi capire il valore di avere una piattaforma. Ciò significa che gli sviluppatori a volte avranno frustrazioni. I feedback devono essere presi in considerazione durante l'iterazione dello sviluppo della piattaforma. Dovrebbe esserci un modo per fornire feedback agli sviluppatori della piattaforma e al modo in cui la piattaforma sta facendo in generale. Senza questo la piattaforma vive isolata con il resto dell'azienda. L'adozione sarà al massimo faticosa. Le persone vogliono usare e adottare qualcosa per cui si sentono bene. Lo sviluppo di software dopotutto è un tipo di progetto incentrato sulle persone. La comunicazione, la motivazione delle interazioni è una parte importante dello sviluppo. Dobbiamo perfezionarlo insieme ai requisiti e alle scadenze aziendali. Una piattaforma perfetta inesistente non serve a nessuno. Una piattaforma semi funzionale e non protetta è una maledizione per qualsiasi azienda.

Infine ci saranno sempre cose che non rientrano nell'ambito della piattaforma. Questo dovrebbe sempre essere deciso caso per caso. Sapendo che le persone ne hanno ancora bisogno alla fine della giornata e dovrai reindirizzare la richiesta in un'altra squadra. Forse intensificarlo.

Il team planner guarda la squadra ad alto livello

I principi

Il team cerca di resistere alle sue decisioni

Autorità

In molti modi il successo o il fallimento di un team della piattaforma sta nella decisione che prende. Il team della piattaforma dovrà prendere decisioni che riguardano altri team. Questo accade mentre si costruiscono le basi della piattaforma. Ad esempio il linguaggio utilizzato dagli strumenti e dai framework.

L'autorità del team della piattaforma non sta nel rispetto degli standard. Ma nel sottile governo del team di sviluppo in una decisione o nell'altra. Ad esempio, creando una raccomandazione per la registrazione. Per renderlo compatibile con un parser di registrazione durante la spedizione dei registri. La creazione di standard rigidi e veloci non è responsabilità del team della piattaforma. Il team di sviluppo stesso dovrebbe avere la prerogativa di scegliere. Come i framework e i linguaggi degli strumenti che ritiene adatti ai propri casi d'uso. Detto questo, ci sono forze fondamentali che devono essere decise in anticipo. Ad esempio l'utilizzo del cloud o di più provider cloud.

Il blocco del fornitore è sia un dono che una maledizione per i team della piattaforma. Dono nel senso che queste decisioni sono state prese da altre squadre. Ciò significa che i team hanno costruito il loro ecosistema di strumenti attorno a una decisione. Maledizione anche dal momento che dobbiamo vivere queste decisioni all'interno del ciclo di vita di un'applicazione. Oppure aggiungi un ulteriore sovraccarico di migrazione. Un team della piattaforma dovrebbe avere visibilità e autorità sull'organizzazione più ampia per avere maggiori possibilità di successo.

Giralo in questo modo. Crediamo che DevOps sia una cultura non una persona

Advocacy ed evangelizzazione

DevOps è una cultura non un ruolo. Il team della piattaforma dovrebbe essere in grado di evangelizzare questo.

Il solito punto di errore nello sviluppo del software è la mancanza di comprensione delle prestazioni dell'applicazione in condizioni di ambiente di produzione.

Il primo team tecnico che facilita la comunicazione tra team di solito è il team della piattaforma. Quindi la difesa del riutilizzo del codice e delle migliori pratiche di default ricade sul team della piattaforma. Le prestazioni e l'affidabilità diventano la preoccupazione principale del team della piattaforma.

L'efficienza ingegneristica è la costante difesa del team della piattaforma. L'intero scopo di costruire il team della piattaforma è che gli ingegneri costruiscano di più con un sovraccarico cognitivo. I dettagli che potrebbero essere riutilizzati e automatizzati di solito ricadono sul team della piattaforma.

Rendiamo stabile la tua piattaforma un'ancora alla volta

Responsabilità

Con l'autorità di apportare modifiche ai mattoni fondamentali di ciascuno dei sistemi. Un bug o una vulnerabilità all'interno di uno di questi causerà un problema a cascata. Il resto del team di ingegneri sarà quindi interessato.

La responsabilità in quanto squadra è importante per assicurarsi che ogni volta che la squadra sta effettuando un cambiamento decisivo, il resto della squadra viene informato.

Post mortem irreprensibile è un requisito per rendere sicuro ogni membro di apportare modifiche. Costruire un sistema migliore e allo stesso tempo assumere la proprietà del sistema. La responsabilità di spingere per un modello di supporto e le operazioni spetta quindi alla piattaforma e al team SRE.

Ah .. Quindi non tutti avranno lo stesso lavoro nel girare questa ruota

competenza

L'esperienza e le competenze necessarie per il team della piattaforma dipendono dalla struttura dell'azienda.

Ad esempio alcune aziende hanno un team SRE funzionante che si occupa del funzionamento e dell'operatività di ciascuna applicazione. Ciò significa che la creazione del modello di supporto non è interamente responsabilità del team della piattaforma.

La gestione del fornitore è anche un'attività che può essere delegata ai team di supporto dell'applicazione.

Ma in genere ecco le competenze di cui avrai bisogno all'interno del tuo team di piattaforma:

  • orchestrazione e containerizzazione dei container
  • gestione del cloud
  • gestione del fornitore
  • gestione della pipeline
  • configurazione dns e cdn
  • configurazione del server
  • git e scm
  • product-ionizzazione
  • osservabilità (traccia di monitoraggio della registrazione)
  • operatività (runbook e supporto allerta post mortems di escalation)
  • competenze trasversali e gestione delle persone
  • infrastruttura definita dal software (infrastruttura come codice)
  • collaborazione con altri team e negoziazione con la direzione
  • flusso di lavoro comune e gestione dell'architettura
  • sicurezza
  • formazione e insegnamento degli sviluppatori
  • sviluppo della documentazione

Idealmente, i tuoi ingegneri disporranno di competenze di dominio e quindi di una buona conoscenza operativa di altri domini.

Il mio suggerimento per sviluppare le competenze è di passare da un membro all'altro in modo tale che ci siano esperti a livello di dominio. Quindi eseguire un passaggio di consegne o eseguire la programmazione di coppie di tabelle estreme. Tale ridondanza è integrata nella struttura del team.

Dato l'enorme mandato del team della piattaforma. Possiamo tranquillamente presumere che ci dovrebbe essere una grande squadra per svolgere tutte queste attività in parallelo. Alcune attività possono essere delegate al team dell'applicazione. Anche se ciò aggiungerebbe costi aggiuntivi per lo sviluppo. Potremmo anche dividere questa squadra, ma ciò, se gestito in modo improprio, potrebbe portare a un ulteriore disallineamento.

Si consiglia di avere una struttura semi piatta con più ingegneri senior e principali che possano prendere una decisione agile. Anche avere un grande team come questo con molte parti mobili significherebbe che un ruolo di guida tecnica non è adatto, piuttosto che avere un responsabile tecnico per l'architetto di piattaforme e soluzioni è essenziale.

L'architetto della soluzione potrebbe definire la tabella di marcia del team della piattaforma. Quindi coordinalo con il resto dei team di ingegneria. In questo processo possiamo anche comprendere le esigenze dell'organizzazione. E quindi pianificare quali funzionalità sono necessarie. Infine, l'architetto della soluzione può aiutare a guidare la selezione delle tecnologie da aggiungere alla piattaforma.

Il responsabile tecnico potrebbe aiutare a comunicare e costruire relazioni. Questo è importante per una serie di motivi. Innanzitutto essendo un vero team interfunzionale il numero di richieste sarà elevato. In secondo luogo, la definizione delle priorità delle attività sarà cruciale per lo sviluppo delle capacità.

Davvero molte parti in movimento. Ma fatto bene può essere una macchina ben oliata

epilogo

Il team della piattaforma è un nuovo concetto abilitato dalle nuove tecnologie che arrivano sul mercato. Un buon esempio di ciò è la kubernetes e la sua onnipresenza. Questo nuovo team può aiutare l'azienda a sviluppare facilmente le capacità. I team di ridimensionamento hanno difficoltà ad avere un nuovo team di attivatori che aiuteranno il team a scalare più velocemente con meno attrito. Questa è la mia opinione personale basata sull'esperienza che deve essere al centro di quella squadra e su quali competenze sono necessarie per essere integrate.

Lavora con noi Dai un'occhiata a questo lavoro presso Condé Nast International: https://www.linkedin.com/jobs/view/839478085

Unisciti alla nostra community Slack e leggi i nostri argomenti settimanali su Faun ⬇

Se questo post ti è stato utile, fai clic sul pulsante clap below in basso alcune volte per mostrare il tuo supporto per l'autore! ⬇