Ogni anno miliardi di utenti interagiscono con i prodotti e i servizi Google. Offerte chiave come Ricerca, Gmail, Maps, YouTube, Chrome e ora anche Google Cloud sono così integrate nella vita moderna da contribuire a definire l'esperienza del 21° secolo. Questo impatto a livello mondiale è il risultato della comprovata qualità delle nostre offerte e dell'aspettativa che Google sia sempre disponibile.
In Google Cloud introduciamo continuamente modifiche al codice dei nostri prodotti e servizi per garantire la migliore esperienza utente possibile, migliorare la sicurezza e l'affidabilità e rispettare i requisiti normativi e di conformità. Qualsiasi modifica di questo tipo, grande o piccola che sia, a volte può causare dei problemi. Per far fronte a questo rischio, diamo la priorità alla sicurezza delle modifiche in tutto ciclo di vita di un cambiamento.
Questo documento spiega in che modo i team di Google Cloud si avvalgono dei decenni di esperienza investire nell'eccellenza nello sviluppo per implementare best practice e best practice per l'affidabilità che soddisfano le aspettative dei clienti di Google Cloud per la velocità e l'affidabilità dello sviluppo.
Il ciclo di vita di una modifica in Google Cloud
I team di prodotto di Google Cloud condividono gran parte della procedura di gestione e degli strumenti con altri team tecnici di Google. Implementiamo un approccio standard per lo sviluppo di software per la gestione del cambiamento che dà la priorità all'integrazione continua (CI) e alla distribuzione continua (CD). L'integrazione continua prevede la proposta, il test e l'invio frequente di modifiche, spesso più volte al giorno per un determinato prodotto o servizio. Il CD è un'estensione dell'integrazione continua in cui gli ingegneri preparano continuamente candidati alla release in base all'ultimo snapshot stabile di una base di codice.
Questo approccio dà la priorità alla creazione e all'implementazione di modifiche in più fasi per ai clienti di Google Cloud nel più breve tempo possibile, ma anche nel modo più sicuro possibile. Consideriamo la sicurezza delle modifiche prima di scrivere qualsiasi codice e continuiamo a concentrarci anche dopo l'implementazione delle modifiche in produzione. Il nostro modello di gestione del cambiamento prevede quattro fasi generali: progettazione, sviluppo, qualifica e implementazione. Queste quattro fasi sono mostrate nel seguente diagramma e vengono descritte in maggiore dettaglio nel presente documento:
La sicurezza prima di tutto
Siamo consapevoli che anche piccoli errori all'inizio del processo di sviluppo possono causare grandi problemi in un secondo momento e influire notevolmente sulle esperienze dei clienti. Di conseguenza, tutte le modifiche sostanziali devono iniziare con un documento di progettazione approvato. Abbiamo un modello di documento di progettazione comune per consentire ai team tecnici di proporre modifiche. Questo documento di progettazione comune ci aiuta a valutare i principali cambiamenti i prodotti Google Cloud in modo coerente. Il seguente diagramma mostra cosa il processo di progettazione standard per un cambiamento importante ha questo aspetto:
La fase di progettazione inizia quando uno sviluppatore di software propone una modifica soddisfa i requisiti aziendali, tecnici, di costo e di manutenzione. Dopo aver inviato la modifica, viene avviata una procedura di revisione e approvazione completa con esperti di alto livello, tra cui esperti di affidabilità e sicurezza, nonché responsabili tecnici. Il lavoro per implementare la modifica può procedere solo dopo che il tecnico che il progetto proposto risponde a tutti i feedback degli esperti e di ogni esperto approva il design. Questa procedura di progettazione e revisione riduce la probabilità che i team di prodotto di Google Cloud inizino a lavorare su modifiche che potrebbero avere un impatto negativo sui clienti in produzione.
Sicuro come sviluppato
La nostra procedura di sviluppo del codice ne aumenta la qualità e l'affidabilità. Dopo l'approvazione di una modifica proposta, il processo di sviluppo inizia con un onboarding completo per i nuovi ingegneri, che include formazione, tutoraggio e feedback dettagliati sulle modifiche al codice proposte. Un approccio di sviluppo e testing a più livelli con test manuali e automatici convalida continuamente il codice in ogni fase di sviluppo. Ogni modifica al codice viene esaminata accuratamente per garantirne la conformità agli elevati standard di Google.
Il seguente diagramma fornisce un flusso di lavoro che illustra approssimativamente la nostra procedura di sviluppo:
La fase di sviluppo inizia quando un ingegnere inizia a scrivere codice e i test di unità e integrazione corrispondenti. Durante questa fase, l'ingegnere possono eseguire test che hanno scritto e una suite di test pre-invio per garantire che il codice aggiunte e modifiche sono valide. Dopo aver completato le modifiche al codice ed eseguito i test, l'ingegnere richiede una revisione manuale da parte di un'altra persona che abbia familiarità con il codice. Questo processo di revisione umana è spesso iterativo e può comportare altre revisioni del codice. Quando l'autore e il recensore raggiungono un accordo, l'autore invia il codice.
Gli standard di programmazione garantiscono modifiche di alta qualità
La cultura, le pratiche e gli strumenti ingegneristici di Google sono progettati per garantire che il codice sia corretto, chiaro, conciso ed efficiente. Lo sviluppo del codice in Google avviene nel nostro monorepo, il repository di codice integrato più grande al mondo. Il monorepo contiene milioni di file di codice sorgente, miliardi di righe di codice e una cronologia di centinaia di milioni di commit chiamati elenchi di modifiche. Continua a crescere rapidamente, con decine di migliaia di nuovi elenchi di modifiche aggiunti ogni giorno lavorativo. I vantaggi principali del monorepo sono che semplifica il riutilizzo del codice, facilita la gestione delle dipendenze e impone flussi di lavoro degli sviluppatori coerenti tra prodotti e servizi.
Il riutilizzo del codice è utile perché abbiamo già una buona idea del funzionamento del codice riutilizzato in produzione. Sfruttando il codice di alta qualità esistente, le modifiche sono intrinsecamente più solide e facili da gestire allo standard richiesto. Questa pratica non solo consente di risparmiare tempo e fatica, ma garantisce anche che la salute complessiva della base di codice rimanga elevata, il che si traduce in prodotti più affidabili.
I servizi Google Cloud basati su software open source di alta qualità possono integrare il monorepo con un altro repository, in genere Git, per utilizzare i branching per gestire il software open source.
Una nota sulla formazione
L'investimento nella qualità del codice inizia quando un ingegnere entra a far parte di un team. Se l'ingegnere è nuovo in Google o ha meno dimestichezza con l'infrastruttura e l'architettura del team, deve seguire un'onboarding approfondita. Nell'ambito di questo onboarding, studiano guide di stile, best practice e guide di sviluppo ed eseguono manualmente esercizi pratici. Inoltre, i nuovi ingegneri richiedono un livello aggiuntivo di approvazione per ogni singolo invio della lista di modifiche. Approvazione per modifiche in un determinato linguaggio di programmazione vengono concesse dagli ingegneri che hanno superato una serie di aspettative rigorose basate sulle loro competenze e hanno guadagnato la leggibilità in quel linguaggio di programmazione. Qualsiasi ingegnere può ottenere la leggibilità per un linguaggio di programmazione. La maggior parte dei team ha più approvatori per i linguaggi di programmazione in cui scrive il codice.
Lo spostamento a sinistra migliora la velocità in sicurezza
Lo spostamento a sinistra è un principio che sposta i test e la convalida all'inizio del processo di sviluppo. Questo principio si basa sulla nostra osservazione che i costi aumentare drasticamente più avanti nel processo di rilascio, che troviamo e correggiamo un bug. In un caso estremo, considera un bug che un cliente trova in produzione. Questo bug potrebbe influire negativamente sui carichi di lavoro e sulle applicazioni del cliente. il cliente potrebbe anche dover eseguire il processo di assistenza clienti Google Cloud prima il team tecnico competente può mitigare il bug. Se un ingegnere assegnato al che il problema è una persona diversa da quella che ha introdotto inizialmente che conteneva il bug, il nuovo tecnico dovrà acquisire familiarità con le modifiche al codice, probabilmente aumentando il tempo necessario per la riproduzione alla fine correggere il bug. L'intero processo richiede molto tempo ai clienti e all'assistenza di Google Cloud, e chiede ai tecnici di eliminare stanno lavorando per sistemare qualcosa.
Al contrario, prendi in considerazione un bug rilevato da un errore di test automatico mentre un ingegnere sta lavorando a una modifica in fase di sviluppo. Quando l'ingegnere vede l'errore del test, possono correggerlo immediatamente. A causa dei nostri standard di codifica, l'ingegnere non sarebbe nemmeno in grado di inviare la modifica con il fallimento del test. Questo rilevamento precoce consente all'ingegnere di correggere il bug senza alcun impatto sul cliente e senza costi aggiuntivi per il passaggio di contesto.
Quest'ultimo scenario è infinitamente preferibile per tutte le parti coinvolte. Di conseguenza, nel corso degli anni, Google Cloud ha investito molto per questo spostamento dell'IA, i test in movimento tradizionalmente eseguiti durante la fase di qualificazione le fasi di implementazione direttamente nel ciclo di sviluppo. Oggi, tutti i test delle unità, ma i più grandi test di integrazione e le ampie analisi statiche e dinamiche viene completato in parallelo mentre un ingegnere propone delle modifiche al codice.
I test automatici prima dell'invio applicano gli standard di programmazione
I test pre-invio sono controlli che vengono eseguiti prima dell'invio di qualsiasi modifica . I test pre-invio possono essere test delle unità e di integrazione specifici per un di cambiamento o di test generali (ad esempio, analisi statica e dinamica) che vengono eseguiti qualsiasi modifica. Storicamente, i test pre-invio venivano eseguiti come ultimo passaggio prima qualcuno invia una modifica a un codebase. Oggi, in parte a causa del principio di shift left e della nostra implementazione dell'integrazione continua, eseguiamo i test di preinvio in modo continuo mentre un tecnico apporta modifiche al codice in un ambiente di sviluppo e prima di unire le modifiche nel nostro monorepo. Un tecnico può anche eseguire manualmente eseguire il preinvio della suite di test con un solo clic nell'interfaccia utente di sviluppo il test pre-invio viene eseguito automaticamente per ogni elenco di modifiche prima di un codice umano per la revisione.
La suite di test pre-invio in genere copre test di unità, test di fuzz (fuzzing), test di integrazione ermetici, nonché analisi del codice statico e dinamico. Per le modifiche alle librerie di base o al codice ampiamente utilizzato in Google, gli sviluppatori eseguono un pre-invio globale. Un pre-invio globale verifica la modifica rispetto all'intera piattaforma Google codebase, riducendo al minimo il rischio che una modifica proposta influisca negativamente sugli altri di progetti o sistemi.
Test di unità e integrazione
I test accurati sono fondamentali per il processo di sviluppo del codice. Tutti devono scrivere test delle unità per le modifiche al codice e monitoriamo continuamente la copertura del codice a livello di progetto per assicurarci di convalidare il comportamento previsto. Inoltre, richiediamo che ogni percorso critico dell'utente includa test di integrazione. in cui convalidiamo la funzionalità di tutti i componenti necessari delle dipendenze.
I test delle unità e tutti i test di integrazione, tranne quelli più grandi, sono progettati per completare e vengono eseguiti in modo incrementale con un parallelismo elevato dell'ambiente, con un conseguente feedback di sviluppo automatizzato rapido e continuo.
Fuzzing
Mentre i test delle unità e di integrazione ci aiutano a convalidare il comportamento previsto con input e output predeterminati, il fuzzing è una tecnica che bombarda un'applicazione con input casuali, con l'obiettivo di esporre difetti o punti deboli nascosti che potrebbero causare vulnerabilità di sicurezza o arresti anomali. Il fuzzing ci consente di identificare e risolvere in modo proattivo potenziali punti deboli del nostro software, migliorando la sicurezza e l'affidabilità complessive dei nostri prodotti prima che i clienti interagiscano con le modifiche. La casualità di questi test è particolarmente utile perché a volte gli utenti interagiscono con i nostri prodotti in modi interessanti che non prevediamo e il fuzzing ci aiuta a tenere conto di scenari che non abbiamo considerato manualmente.
Analisi statica
Gli strumenti di analisi statica svolgono un ruolo fondamentale nel mantenere la qualità del codice nei nostri per i flussi di lavoro di sviluppo. L'analisi statica si è evoluta notevolmente dai primi giorni del linting con espressioni regolari per identificare pattern di codice C++ problematici. Oggi l'analisi statica copre tutta la produzione di Google Cloud linguaggi di programmazione diversi e trova pattern di codice errati, inefficienti o deprecati.
Con frontend del compilatore e modelli LLM avanzati, possiamo proporre automaticamente miglioramenti mentre gli ingegneri scrivono codice. Ogni modifica al codice proposta viene esaminata con analisi statiche. Con l'aggiunta di nuovi controlli statici nel tempo, l'intera il codebase viene costantemente scansionato per verificarne la conformità e le correzioni vengono generati e inviati per la revisione.
Analisi dinamica
L'analisi statica si concentra sull'identificazione di pattern di codice noti che possono ai problemi, l'analisi dinamica adotta un approccio diverso. Implica la compilazione ed eseguire codice per scoprire i problemi che emergono solo durante l'esecuzione, violazioni della memoria e condizioni di gara. Google ha una lunga storia di utilizzo l'analisi dinamica e ha anche ha condiviso diversi dei suoi strumenti con la più ampia community di sviluppatori, che include:
- AddressSanitizer: rileva errori di memoria come overflow del buffer e use-after-free
- ThreadSanitizer (C++, Go): rileva race di dati e altri bug di threading
- MemorySanitizer: scova l'utilizzo di memoria non inizializzata
Questi strumenti e altri simili sono essenziali per rilevare bug complessi che non possono essere rilevati solo tramite l'analisi statica. Usando sia i feed statici analisi dinamica, Google si impegna a garantire che il suo codice sia ben strutturato, privo di problemi noti e si comporta come previsto in scenari reali.
Le revisioni del codice umano convalidano le modifiche e i risultati dei test
Quando un ingegnere raggiunge un traguardo critico nel suo codice e vuole nel repository principale, avviano una revisione del codice proponendo un elenco modifiche. Una richiesta di revisione del codice è costituita da:
- Una descrizione che descriva lo scopo delle modifiche e qualsiasi altro contesto
- Il codice modificato vero e proprio
- Test delle unità e eventuali test di integrazione per il codice modificato
- Risultati del test di preinvio automatico
È in questo punto del processo di sviluppo che interviene un'altra persona. Uno o più revisori designati esaminano attentamente l'elenco delle modifiche per verificarne la correttezza e la chiarezza, utilizzando come guida i test allegati e i risultati precedenti l'invio. Ogni directory di codice ha un insieme di revisori designati responsabili di garantire la qualità di quel sottoinsieme della base di codice e la cui approvazione è necessaria per apportare modifiche all'interno della directory. Revisori e tecnici collaborano per individuare e risolvere gli eventuali problemi relativi a una proposta di modifica del codice. Quando il listino delle modifiche soddisfa i nostri standard, un revisore dà la sua approvazione ("LGTM", acronimo di "Looks good to me", ovvero "Ok"). Tuttavia, se l'ingegnere è ancora in fase di addestramento linguaggio di programmazione utilizzato, hanno bisogno dell'ulteriore approvazione di un esperto che abbia ottenuto la leggibilità nel linguaggio di programmazione.
Dopo che una lista di modifiche supera i test e i controlli automatici e riceve un LGTM, l'ingegnere che ha proposto la modifica può apportare solo modifiche minime al codice. Eventuali modifiche sostanziali invalidano l'approvazione e ne richiedono un'altra fase di revisione. Anche le piccole modifiche vengono segnalate automaticamente ai revisori originali. Una volta che il tecnico invia il codice finalizzato, passa attraverso un altro una serie completa di test pre-invio prima che l'elenco modifiche venga unito al monorepo. Se uno o più test non vanno a buon fine, l'invio viene rifiutato e lo sviluppatore e i revisori ricevono un avviso per intraprendere un'azione correttiva prima di riprovare a inviare le modifiche.
Idoneità alla distribuzione sicura
Sebbene i test di preinvio siano completi, non rappresentano la fine della procedura di test di Google. I team spesso hanno test aggiuntivi, come i test di integrazione su larga scala, che non sono possibili da eseguire durante la revisione iniziale del codice (l'esecuzione potrebbe richiedere più tempo o ambienti di test ad alta fedeltà). Inoltre, i team devono essere a conoscenza di eventuali errori causati da fattori al di fuori del loro controllo, come le modifiche alle dipendenze esterne.
Ecco perché Google richiede una fase di qualificazione dopo la fase di sviluppo. Questa fase di qualificazione utilizza un processo di compilazione e test continuo, come mostrato nel seguente diagramma:
Questo processo esegue periodicamente test per tutto il codice interessato dalla gestione diretta o indiretta modifiche dall'ultima esecuzione. Eventuali errori vengono riassegnati automaticamente al team di ingegneri responsabile. In molti casi, il sistema è in grado di identificare l'elenco modifiche che ha causato l'interruzione ed eseguirne il rollback. Questi test di integrazione su larga scala vengono eseguiti in una serie di ambienti di staging che vanno da ambienti parzialmente simulati a intere sedi fisiche.
I test hanno una serie di obiettivi di qualificazione che vanno dall'affidabilità di base e sicurezza alla logica di business. Questi test di idoneità includono il test del codice per quanto segue:
- La capacità di fornire la funzionalità richiesta, che viene testata utilizzando Test di integrazione su larga scala
- Capacità di soddisfare i requisiti aziendali, testati con materiali sintetici rappresentazioni dei carichi di lavoro dei clienti
- La capacità di sostenere i guasti dell’infrastruttura sottostante, ovvero testati utilizzando l'inserimento di errori nello stack
- La capacità di sostenere la capacità di pubblicazione, che viene testata con framework di test di carico
- La possibilità di eseguire il rollback in sicurezza
Implementazioni sicure
Nonostante i più efficaci processi di sviluppo, test e qualifica, difetti a volte si infiltrano negli ambienti di produzione con un impatto negativo sui nostri utenti. In questa sezione viene spiegato come funziona il processo di implementazione di Google Cloud. limita l'impatto delle modifiche difettose e garantisce il rapido rilevamento di qualsiasi di regressione lineare. Applichiamo questo approccio a tutti i tipi di modifiche implementate in produzione, inclusi binari, configurazioni, aggiornamenti dello schema, modifiche della capacità e liste di controllo dell'accesso.
Modifica della propagazione e della supervisione
Applichiamo un approccio coerente al deployment delle modifiche in Google Cloud per ridurre al minimo l'impatto negativo sui clienti e isolare i problemi per domini in errore fisici. Il processo si basa sulle nostre pratiche di affidabilità SRE di decenni e sul nostro sistema di monitoraggio su scala planetaria per rilevare e mitigare le modifiche errate il più rapidamente possibile. Il rilevamento rapido ci consente di informare i clienti più rapidamente e di adottare azioni correttive per evitare sistematicamente che si verifichino nuovamente errori simili.
La maggior parte dei prodotti Google Cloud opera a livello di regione o zona. Ciò significa che un prodotto regionale pubblicato nella regione A è indipendente dallo stesso prodotto pubblicato nella regione B. Analogamente, un prodotto zonale in esecuzione nella zona C della regione A è indipendente dallo stesso prodotto zonale in esecuzione nella zona D della regione A. Questa architettura riduce al minimo il rischio di un'interruzione del servizio che colpisca altre regioni o altre zone all'interno di una singola regione. Alcuni servizi, come IAM o la console Google Cloud, fornire un livello coerente a livello globale che comprende regioni, per questo le chiamiamo servizi globali. I servizi globali vengono replicati nelle regioni per evitare single point of failure e ridurre al minimo la latenza. La piattaforma di implementazione condivisa di Google Cloud è consapevole se un servizio è a livello di zona, di regione o globale e orchestra le modifiche in produzione in modo appropriato.
Il processo di implementazione di Google Cloud suddivide tutte le repliche di un servizio di cui è stato eseguito il deployment su più località target in ondate. Le ondate iniziali includono una piccola di repliche, con gli aggiornamenti che procedono in serie. L'equilibrio iniziale delle onde proteggendo la maggior parte dei carichi di lavoro dei clienti massimizzando l'esposizione ai carichi di lavoro per rilevare i problemi il prima possibile e includere carichi di lavoro sintetici che imitano i modelli comuni dei carichi di lavoro dei clienti.
Se l'implementazione continua a essere eseguita correttamente man mano che le repliche del servizio vengono aggiornate nelle località di destinazione, le successive ondate di implementazione aumentano progressivamente di dimensioni e introducono un maggiore parallelismo. Anche se un certo parallelismo è necessario per il numero di località Google Cloud, non consentiamo aggiornamenti simultanei in località che si trovano in onde diverse. Se un'ondata si protrae fino a notte fonda o nel fine settimana, può completare la sua progressione, ma non è possibile avviare una nuova ondata fino all'inizio dell'orario di lavoro del team che gestisce l'implementazione.
Il seguente diagramma è un flusso di lavoro di esempio che illustra l'implementazione che utilizziamo in Google Cloud per prodotti e servizi regionali:
Il processo di implementazione di Google Cloud utilizza il Canary Analysis Service (CAS) per automatizzare i test A/B per tutta la durata di un'implementazione. Alcune repliche diventano canarini (ovvero un deployment parziale e limitato nel tempo di una modifica in un servizio) e le repliche rimanenti costituiscono il gruppo di controllo che non include la modifica. Ogni passaggio della procedura di implementazione ha un tempo di attesa per rilevare i problemi latenti prima di passare al passaggio successivo, in modo da garantire che tutte le funzionalità di un servizio vengano esercitate correttamente e che eventuali anomalie vengano rilevate da CAS. Il tempo di compilazione è definito con attenzione per bilanciare il rilevamento di problemi a lenta combustione con la velocità di sviluppo. L'implementazione di Google Cloud richiede in genere una settimana.
Questo diagramma fornisce una rapida panoramica dell'aspetto del flusso di lavoro di CAS:
Il flusso di lavoro inizia con il deployment dello strumento di implementazione della modifica alla versione canary replica. Lo strumento di implementazione richiede quindi un esito alle CA. CAS valuta la replica del canary rispetto al gruppo di controllo e restituisce un verdetto PASS o FAIL. Se un segnale di integrità non funziona, viene generato un avviso per i proprietari del servizio e il passaggio in esecuzione dell'implementazione è stato messo in pausa o eseguito il rollback. Se la modifica causa interruzione del servizio per i clienti esterni, viene dichiarato un incidente esterno e i clienti interessati vengono avvisati utilizzando il servizio Stato del servizio personalizzato. Gli incidenti attivano anche una revisione interna. La filosofia post mortem di Google assicura che venga identificato e applicato il giusto insieme di azioni correttive ridurre al minimo la probabilità che errori simili si ripetano.
Monitorare gli indicatori e la sicurezza post-implementazione
I difetti del software non si manifestano sempre immediatamente e alcuni potrebbero richiedere circostanze specifiche per essere attivati. Per questo motivo, continuiamo a monitorare i sistemi di produzione al termine di un'implementazione. Nel corso degli anni, abbiamo notato che anche se un'implementazione non attiva immediatamente problemi, è comunque la causa più probabile di un incidente di produzione. Per questo motivo, i nostri playbook di produzione chiedono agli addetti alla gestione degli incidenti di correlare le implementazioni recenti ai problemi osservati e di ripristinare per impostazione predefinita un'implementazione recente se non possono escludere che le modifiche recenti siano la causa principale dell'incidente.
Il monitoraggio post-implementazione si basa sullo stesso insieme di indicatori di monitoraggio che utilizziamo per le analisi A/B automatiche durante una finestra di implementazione. Il team di la filosofia di monitoraggio e avviso combina due tipi di monitoraggio: introspettiva (noto anche come white-box) e sintetico (detto anche come black-box). Il monitoraggio introspettivo usa metriche come utilizzo della CPU, memoria sull'utilizzo e altri dati dei servizi interni. Il monitoraggio sintetico esamina il comportamento del sistema dal punto di vista del cliente, monitorando i tassi di errore del servizio e le risposte al traffico sintetico dei servizi di prober. Il monitoraggio sintetico è orientato ai sintomi e identifica i problemi attivi, mentre il monitoraggio introspettivo ci consente di diagnosticare i problemi confermati e, in alcuni casi, di identificare i problemi imminenti.
Per facilitare il rilevamento di incidenti che interessano solo alcuni clienti, raggruppiamo i carichi di lavoro dei clienti in coorti di carichi di lavoro correlati. Gli avvisi vengono attivati come non appena le prestazioni di una coorte si discostano dalla norma. Questi avvisi consentono rilevare regressioni specifiche per il cliente anche se appare un rendimento aggregato sia normale.
Protezione della catena di fornitura del software
Ogni volta che i team di Google Cloud introducono modifiche, utilizziamo un controllo di sicurezza chiamato Autorizzazione dei binari per Borg (BAB) per proteggere la nostra catena di approvvigionamento del software e i clienti di Cloud dai rischi legati agli addetti ai lavori. BAB parte dalla fase di revisione del codice e crea un audit trail di codice del deployment in produzione. Per garantire l'integrità della produzione, BAB ammette solo le modifiche che soddisfano i seguenti criteri:
- Sono a prova di manomissione e firmati
- Provenire da un team di compilazione e da una posizione di origine identificati
- Sono stati esaminati e approvati esplicitamente da una parte diversa dal codice autore
Se ti interessa applicare alcuni degli stessi concetti nel tuo software abbiamo incluso i concetti chiave di BAB in una specifica aperta chiamato Supply-chain Levels for Software Artifacts (SLSA). Lo SLSA funge da framework di sicurezza per lo sviluppo e l'esecuzione del codice ambienti di produzione.
Conclusione
Google Cloud si basa sui decenni di investimenti di Google nell'eccellenza dello sviluppo. La salute del codice e la salute della produzione sono principi culturali radicati nella tutti i team tecnici di Google. Il nostro processo di revisione del design garantisce che le implicazioni sull'integrità del codice e della produzione sono considerate fin da subito. Il nostro procedura di sviluppo, basata sul principio di spostamento a sinistra e su test approfonditi, garantisce che le idee di design vengano implementate in modo sicuro e corretto. Le nostre Il processo di qualifica estende ulteriormente i test per includere integrazioni su larga scala e alle dipendenze esterne. Infine, la nostra piattaforma di lancio ci consente acquisire progressivamente la sicurezza che una determinata modifica si comporti effettivamente come previsto. Dal concepimento alla produzione, il nostro approccio ci consente di soddisfare le aspettative dei clienti di Google Cloud sia in termini di velocità di sviluppo sia di affidabilità.