Ogni anno, miliardi di utenti interagiscono con i prodotti e i servizi di Google. Offerte chiave come Ricerca, Gmail, Maps, YouTube, Chrome e ora anche Google Cloudsono così perfettamente integrate nella vita moderna che contribuiscono a definire l'esperienza del XXI secolo. Questo impatto a livello mondiale è il risultato della qualità comprovata 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, grande o piccola che sia, a volte può causare problemi. Per affrontare questo rischio, diamo la priorità alla sicurezza delle modifiche durante l'intero ciclo di vita di una modifica.
Questo documento spiega in che modo Google Cloud i team si basano su decenni di investimenti di Google nell'eccellenza dello sviluppo per implementare le best practice di affidabilità e gli standard di ingegneria che soddisfano Google Cloud le aspettative dei clienti in termini di velocità e affidabilità dello sviluppo.
La durata di una modifica in Google Cloud
Google Cloud I team di prodotto condividono gran parte della procedura di gestione e degli strumenti con altri team tecnici di Google. Implementiamo un approccio standard allo sviluppo di software per la gestione delle modifiche che dà la priorità all'integrazione continua (CI) e alla distribuzione continua (CD). La CI include la proposta, il test e l'invio frequenti di modifiche, spesso più volte al giorno per un determinato prodotto o servizio. Il CD è un'estensione della CI in cui gli ingegneri preparano continuamente i candidati alla release in base all'ultimo snapshot stabile di un codebase.
Questo approccio dà la priorità alla creazione e all'implementazione delle modifiche in più fasi per Google Cloud i clienti il prima possibile, ma anche nel modo più sicuro possibile. Consideriamo la sicurezza delle modifiche prima di scrivere qualsiasi codice e continuiamo a concentrarci sulla sicurezza anche dopo aver implementato le 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 discusse in modo più dettagliato in questo documento:
La sicurezza prima di tutto
Siamo consapevoli che anche piccoli errori nelle prime fasi del processo di sviluppo possono causare grandi problemi in seguito, con un impatto significativo sulle esperienze dei clienti. Di conseguenza, richiediamo che tutte le modifiche principali inizino con un documento di progettazione approvato. Abbiamo un modello di documento di progettazione comune che i team di ingegneria possono utilizzare per proporre modifiche importanti. Questo documento di progettazione comune ci aiuta a valutare in modo coerente le modifiche principali nei prodottiGoogle Cloud . Il seguente diagramma mostra il nostro processo di progettazione standard per una modifica importante:
La fase di progettazione inizia quando uno sviluppatore di software propone una modifica che soddisfa i requisiti aziendali, tecnici, di costo e di manutenzione. Dopo l'invio della modifica, viene avviata una procedura completa di revisione e approvazione con esperti senior, tra cui esperti di affidabilità e sicurezza e responsabili tecnici. L'implementazione della modifica può procedere solo dopo che l'ingegnere che ha proposto il progetto ha preso in considerazione tutti i feedback degli esperti e ogni esperto ha approvato il progetto. Questo processo di progettazione e revisione riduce la probabilità che i team di prodotto inizino a lavorare su modifiche che potrebbero influire negativamente sui clienti in produzione.Google Cloud
Sicuro come sviluppato
Il nostro processo di sviluppo del codice aumenta la qualità e l'affidabilità del codice. Dopo l'approvazione di una modifica proposta, inizia il processo di sviluppo con un onboarding completo per i nuovi ingegneri, che include formazione, tutoraggio e feedback dettagliato sulle modifiche al codice proposte. Un approccio di sviluppo e test a più livelli con test manuali e automatici convalida continuamente il codice in ogni fase dello sviluppo. Ogni modifica del codice viene esaminata attentamente per assicurarsi che soddisfi gli elevati standard di Google.
Il seguente diagramma mostra un flusso di lavoro che illustra approssimativamente l'aspetto della nostra procedura di sviluppo:
La fase di sviluppo inizia quando un ingegnere inizia a scrivere il codice e i test delle unità e di integrazione corrispondenti. Durante questa fase, l'ingegnere può eseguire i test che ha scritto e una suite di test pre-invio per assicurarsi che le aggiunte e le modifiche al codice siano 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. Questa procedura di revisione umana è spesso iterativa e può comportare revisioni aggiuntive del codice. Quando l'autore e il revisore raggiungono un consenso, l'autore invia il codice.
Gli standard di codifica garantiscono modifiche di alta qualità
La cultura, le pratiche e gli strumenti di ingegneria di Google sono progettati per garantire che il nostro codice sia corretto, chiaro, conciso ed efficiente. Lo sviluppo del codice in Google avviene nel nostro monorepo, il più grande repository di codice integrato al mondo. Il monorepo contiene milioni di file sorgente, miliardi di righe di codice e ha una cronologia di centinaia di milioni di commit chiamati changelist. Continua a crescere rapidamente, con decine di migliaia di nuove changelist aggiunte ogni giorno lavorativo. I principali vantaggi del monorepo sono che facilita il riutilizzo del codice, semplifica la gestione delle dipendenze e applica flussi di lavoro degli sviluppatori coerenti tra prodotti e servizi.
Il riutilizzo del codice è utile perché abbiamo già una buona idea di come il codice riutilizzato funziona in produzione. Sfruttando il codice di alta qualità già esistente, le modifiche sono intrinsecamente più robuste e più facili da mantenere allo standard richiesto. Questa pratica non solo fa risparmiare tempo e fatica, ma garantisce anche che la salute complessiva del codice rimanga elevata, portando a prodotti più affidabili.
Google Cloud servizi basati su software open source di alta qualità possono integrare il monorepo con un altro repository, in genere Git, per utilizzare la ramificazione per gestire il software open source.
Una nota sull'addestramento
L'investimento nella qualità del codice inizia quando un ingegnere entra a far parte di un team. Se l'ingegnere non ha mai lavorato in Google o ha meno familiarità con l'infrastruttura e l'architettura del team, deve seguire un onboarding approfondito. Nell'ambito di questo onboarding, studiano guide di stile, best practice e guide allo sviluppo ed eseguono manualmente esercizi pratici. Inoltre, i nuovi ingegneri richiedono un ulteriore livello di approvazione per ogni invio di changelist individuale. L'approvazione delle modifiche in un determinato linguaggio di programmazione viene concessa da ingegneri che hanno superato una serie rigorosa di aspettative basate sulla loro esperienza e hanno ottenuto 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 codificano.
Shift a sinistra migliora la velocità in modo sicuro
Lo shift left è un principio che anticipa i test e la convalida nel processo di sviluppo. Questo principio si basa sulla nostra osservazione che i costi aumentano notevolmente quanto più tardi nel processo di rilascio 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 e il cliente potrebbe anche dover seguire la procedura diassistenza clienti Google Cloudd prima che il team di ingegneria pertinente possa mitigare il bug. Se l'ingegnere incaricato di risolvere il problema è una persona diversa da quella che ha introdotto originariamente la modifica che conteneva il bug, il nuovo ingegnere dovrà familiarizzare con le modifiche al codice, il che probabilmente aumenterà il tempo necessario per riprodurre e alla fine correggere il bug. L'intero processo richiede molto tempo da parte dei clienti e dell'assistenza di Google Cloude impone agli ingegneri di interrompere il lavoro in corso per risolvere un problema.
Al contrario, considera un bug rilevato da un test automatico non riuscito mentre un ingegnere sta lavorando a una modifica in fase di sviluppo. Quando l'ingegnere vede l'esito negativo del test, può correggerlo immediatamente. A causa dei nostri standard di codifica, il tecnico non sarebbe nemmeno in grado di inviare la modifica con il test non riuscito. Questo rilevamento precoce significa che l'ingegnere può correggere il bug senza alcun impatto sui clienti e senza overhead di cambio di contesto.
Il secondo scenario è di gran lunga preferibile per tutti i soggetti coinvolti. Di conseguenza, nel corso degli anni, Google Cloud ha investito molto in questo principio di spostamento a sinistra, spostando i test tradizionalmente eseguiti durante le fasi di qualifica e implementazione delle modifiche direttamente nel ciclo di sviluppo. Oggi, tutti i test delle unità, tutti i test di integrazione tranne quelli più grandi e le analisi statiche e dinamiche approfondite vengono completati in parallelo mentre un ingegnere propone modifiche al codice.
I test automatici pre-invio applicano gli standard di codifica
I test pre-invio sono controlli eseguiti prima dell'invio di modifiche in una determinata directory. I test preinvio possono essere test delle unità e di integrazione specifici per una modifica o test generali (ad esempio, analisi statica e dinamica) eseguiti per qualsiasi modifica. Storicamente, i test pre-invio venivano eseguiti come ultimo passaggio prima che qualcuno inviasse una modifica a un codebase. Oggi, in parte grazie al principio di shift left e alla nostra implementazione della CI, eseguiamo test pre-commit 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 ingegnere può anche eseguire manualmente una suite di test pre-invio con un solo clic nell'interfaccia utente di sviluppo e ogni test pre-invio viene eseguito automaticamente per ogni changelist prima di una revisione del codice da parte di una persona.
La suite di test pre-invio in genere copre test delle unità, fuzz test (fuzzing), test di integrazione ermetici, nonché analisi statica e dinamica del codice. Per le modifiche alle librerie principali o al codice utilizzato ampiamente in Google, gli sviluppatori eseguono un controllo pre-invio globale. Un test di pre-invio globale verifica la modifica rispetto all'intera codebase di Google, riducendo al minimo il rischio che una modifica proposta influisca negativamente su altri progetti o sistemi.
Test delle unità e di integrazione
Test approfonditi sono parte integrante del processo di sviluppo del codice. Tutti sono tenuti a 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 qualsiasi percorso utente critico disponga di test di integrazione in cui convalidiamo la funzionalità di tutti i componenti e le dipendenze necessari.
I test delle unità e tutti i test di integrazione, tranne quelli più grandi, sono progettati per essere completati rapidamente e vengono eseguiti in modo incrementale con un elevato parallelismo in un ambiente distribuito, con conseguente feedback di sviluppo automatizzato rapido e continuo.
Fuzzing
Mentre i test unitari 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 portare a vulnerabilità della sicurezza o arresti anomali. Il fuzzing ci consente di identificare e risolvere in modo proattivo le potenziali debolezze del nostro software, migliorando la sicurezza e l'affidabilità complessive dei nostri prodotti prima che i clienti interagiscano con le modifiche. La casualità di questo test è particolarmente utile perché a volte gli utenti interagiscono con i nostri prodotti in modi interessanti che non ci aspettiamo 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 mantenimento della qualità del codice nei nostri flussi di lavoro di sviluppo. L'analisi statica si è evoluta in modo significativo rispetto ai primi tempi di linting con espressioni regolari per identificare pattern di codice C++ problematici. Oggi, l'analisi statica copre tutte le lingue di produzione e rileva pattern di codice errati, inefficienti o ritirati. Google Cloud
Con frontend del compilatore avanzati e LLM, possiamo proporre automaticamente miglioramenti mentre gli ingegneri scrivono il codice. Ogni modifica al codice proposta viene verificata con analisi statiche. Man mano che aggiungiamo nuovi controlli statici, l'intera base di codice viene costantemente analizzata per verificare la conformità e le correzioni vengono generate e inviate automaticamente per la revisione.
Analisi dinamica
L'analisi statica si concentra sull'identificazione di pattern di codice noti che possono causare problemi, mentre l'analisi dinamica adotta un approccio diverso. Comporta la compilazione e l'esecuzione del codice per scoprire problemi che emergono solo durante l'esecuzione, come violazioni di memoria e condizioni di competizione. Google ha una lunga storia di utilizzo dell'analisi dinamica e ha persino condiviso diversi dei suoi strumenti con la più ampia community di sviluppatori, tra cui:
- AddressSanitizer: Rileva errori di memoria come overflow del buffer e use-after-free
- ThreadSanitizer (C++, Go): trova le competizioni per i dati e altri bug di threading
- MemorySanitizer: Scopri l'utilizzo della memoria non inizializzata
Questi strumenti e altri simili sono essenziali per rilevare bug complessi che non possono essere rilevati solo tramite l'analisi statica. Utilizzando l'analisi statica e dinamica, Google si impegna a garantire che il suo codice sia ben strutturato, privo di problemi noti e si comporti come previsto in scenari reali.
Le revisioni del codice umane convalidano le modifiche e i risultati dei test
Quando un ingegnere raggiunge una tappa fondamentale del suo codice e vuole integrarlo nel repository principale, avvia una revisione del codice proponendo un elenco di modifiche. Una richiesta di revisione del codice è costituita da:
- Una descrizione che illustri lo scopo delle modifiche e qualsiasi contesto aggiuntivo
- Il codice modificato effettivo
- Test delle unità e di integrazione per il codice modificato
- Risultati del test di pre-invio automatico
È a questo punto del processo di sviluppo che interviene un altro essere umano. 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 pre-invio. Ogni directory di codice ha un insieme di revisori designati responsabili di garantire la qualità di quel sottoinsieme del codebase e la cui approvazione è necessaria per apportare modifiche all'interno di quella directory. Revisori e ingegneri collaborano per individuare e risolvere eventuali problemi che potrebbero sorgere con una modifica del codice proposta. Quando l'elenco delle modifiche soddisfa i nostri standard, un revisore dà la sua approvazione ("LGTM", abbreviazione di "looks good to me", ovvero "mi sembra tutto a posto"). Tuttavia, se l'ingegnere è ancora in formazione per il linguaggio di programmazione utilizzato, ha bisogno dell'approvazione aggiuntiva di un esperto che abbia ottenuto la leggibilità nel linguaggio di programmazione.
Dopo che un elenco 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 richiedono un'altra revisione. Anche le piccole modifiche vengono segnalate automaticamente ai revisori originali. Una volta inviato il codice definitivo, l'ingegnere esegue un altro ciclo completo di test pre-invio prima che l'elenco delle modifiche venga unito al monorepo. Se uno dei test non va a buon fine, l'invio viene rifiutato e lo sviluppatore e i revisori ricevono un avviso per intraprendere un'azione correttiva prima di tentare di inviare nuovamente le modifiche.
Idoneità al rilascio sicuro
Sebbene il test pre-invio sia completo, non è la fine del processo di test in Google. I team spesso eseguono test aggiuntivi, come test di integrazione su larga scala, che non è fattibile eseguire durante la revisione iniziale del codice (potrebbero richiedere più tempo per l'esecuzione o ambienti di test ad alta fedeltà). Inoltre, i team devono essere consapevoli di eventuali errori causati da fattori al di fuori del loro controllo, come modifiche alle dipendenze esterne.
Per questo motivo, Google richiede una fase di qualificazione dopo la fase di sviluppo. Questa fase di qualificazione utilizza un processo continuo di build e test, come mostrato nel seguente diagramma:
Questo processo esegue periodicamente test per tutto il codice interessato da modifiche dirette o indirette dall'ultima esecuzione. Eventuali errori vengono automaticamente riassegnati al team di ingegneri responsabile. In molti casi, il sistema è in grado di identificare automaticamente la changelist che ha causato l'interruzione e di 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à e sicurezza di base alla logica di business. Questi test di qualificazione includono la verifica del codice per quanto segue:
- La capacità di fornire la funzionalità richiesta, testata utilizzando test di integrazione su larga scala
- La capacità di soddisfare i requisiti aziendali, testata con rappresentazioni sintetiche dei carichi di lavoro dei clienti
- La capacità di sostenere i guasti dell'infrastruttura sottostante, che viene testata utilizzando l'inserimento di guasti 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
Anche con i processi di sviluppo, test e qualificazione più rigorosi, a volte i difetti si insinuano negli ambienti di produzione e influiscono negativamente sui nostri utenti. In questa sezione spieghiamo come la Google Cloud procedura di implementazione limiti l'impatto delle modifiche difettose e garantisca il rilevamento rapido di eventuali regressioni. Applichiamo questo approccio a tutti i tipi di modifiche implementate in produzione, inclusi binari, configurazioni, aggiornamenti dello schema, modifiche della capacità ed elenchcontrollo dell'accessosi.
Propagazione e supervisione delle modifiche
Applichiamo un approccio coerente all'implementazione delle modifiche in Google Cloud per ridurre al minimo gli impatti negativi sui clienti e isolare i problemi in singoli domini di errore logici e fisici. Il processo si basa sulle nostre pratiche di affidabilità SRE, che applichiamo da 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 avvisare più velocemente i clienti e intraprendere azioni correttive per impedire sistematicamente il ripetersi di errori simili.
La maggior parte dei prodotti Google Cloud sono regionali o zonali. Ciò significa che un prodotto regionale in esecuzione nella regione A è indipendente dallo stesso prodotto in esecuzione nella regione B. Allo stesso modo, un prodotto di zona in esecuzione nella zona C all'interno della regione A è indipendente dallo stesso prodotto di zona in esecuzione nella zona D all'interno della regione A. Questa architettura riduce al minimo il rischio di un'interruzione che influisce su altre regioni o altre zone all'interno di una singola regione. Alcuni servizi, come IAM o la consoleGoogle Cloud , forniscono un livello coerente a livello globale che copre tutte le regioni, motivo per cui li chiamiamo servizi globali. I servizi globali vengono replicati in più regioni per evitare single point of failure e ridurre al minimo la latenza. La piattaforma di implementazione condivisa Google Cloud è consapevole del fatto che un servizio sia zonale, regionale o globale e coordina le modifiche alla produzione in modo appropriato.
Il Google Cloud processo di implementazione suddivide tutte le repliche di un servizio di cui è stato eseguito il deployment in più località di destinazione in ondate. Le ondate iniziali includono un numero ridotto di repliche, con gli aggiornamenti che procedono in serie. Le ondate iniziali bilanciano la protezione della maggior parte dei carichi di lavoro dei clienti con la massimizzazione dell'esposizione alla diversità dei carichi di lavoro per rilevare i problemi il prima possibile e includono carichi di lavoro sintetici che imitano i pattern comuni dei carichi di lavoro dei clienti.
Se l'implementazione continua ad avere esito positivo 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 è necessario un certo parallelismo per tenere conto del numero di Google Cloud località, non consentiamo aggiornamenti simultanei alle località che si trovano in onde diverse. Se un'ondata si estende fino a notte fonda o a un fine settimana, può completare la sua progressione, ma nessuna nuova ondata può iniziare fino all'inizio dell'orario di lavoro per il team che gestisce l'implementazione.
Il seguente diagramma è un esempio di flusso di lavoro che illustra la logica di implementazione che utilizziamo in Google Cloud per prodotti e servizi regionali:
Il Google Cloud processo di implementazione utilizza il servizio di analisi canary (CAS) per automatizzare i test A/B per tutta la durata di un'implementazione. Alcune repliche diventano canarini (ovvero un deployment parziale e con limiti di 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 problemi a lenta combustione prima di passare al passaggio successivo, per garantire che tutte le funzionalità di un servizio siano ben esercitate e che le potenziali anomalie vengano rilevate da CAS. Il tempo di cottura è definito con cura per bilanciare il rilevamento dei problemi a lenta combustione con la velocità di sviluppo. Google Cloud Le implementazioni in genere richiedono una settimana.
Questo diagramma fornisce una rapida panoramica dell'aspetto del flusso di lavoro CAS:
Il flusso di lavoro inizia con lo strumento di implementazione che esegue il deployment della modifica nella replica canary. Lo strumento di implementazione richiede quindi un verdetto a CAS. CAS valuta la replica canary rispetto al gruppo di controllo e restituisce un risultato PASS o FAIL. Se un indicatore di integrità non funziona, viene generato un avviso per i proprietari del servizio e il passaggio di implementazione in esecuzione viene messo in pausa o viene eseguito il rollback. Se la modifica causa interruzioni per i clienti esterni, viene dichiarato un incidente esterno e i clienti interessati vengono informati tramite il servizio Stato del servizio personalizzato. Gli incidenti attivano anche una revisione interna. La filosofia postmortem di Google garantisce che venga identificato e applicato il giusto insieme di azioni correttive per ridurre al minimo la probabilità che si verifichino nuovamente guasti simili.
Indicatori di monitoraggio e 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 dopo il completamento di un rollout. Nel corso degli anni, abbiamo notato che anche se un'implementazione non causa problemi immediati, un'implementazione errata è comunque la causa più probabile di un incidente di produzione. Per questo motivo, i nostri playbook di produzione indicano al personale incaricato di rispondere agli incidenti di correlare i recenti rollout con i problemi osservati e di eseguire il rollback di un recente rollout se non è possibile escludere che le modifiche recenti siano una causa principale dell'incidente.
Il monitoraggio post-implementazione si basa sullo stesso insieme di indicatori di monitoraggio che utilizziamo per le analisi A/B automatizzate durante una finestra di implementazione. La filosofia di monitoraggio e avvisi Google Cloud combina due tipi di monitoraggio: introspezione (noto anche come white box) e sintetico (noto anche come black box). Il monitoraggio introspettivo utilizza metriche come l'utilizzo della CPU, l'utilizzo della memoria e altri dati del servizio interno. 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 probing. Il monitoraggio sintetico è orientato ai sintomi e identifica i problemi attivi, mentre il monitoraggio introspezione ci consente di diagnosticare i problemi confermati e, in alcuni casi, identificare problemi imminenti.
Per facilitare il rilevamento degli incidenti che interessano solo alcuni clienti, raggruppiamo i carichi di lavoro dei clienti in coorti di carichi di lavoro correlati. Gli avvisi vengono attivati non appena il rendimento di una coorte si discosta dalla norma. Questi avvisi ci consentono di rilevare regressioni specifiche per i clienti anche se il rendimento aggregato sembra 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 binaria per Borg (BAB) per proteggere la nostra catena di fornitura del software e i clienti di Cloud dal rischio interno. BAB inizia dalla fase di revisione del codice e crea un audit trail del codice e della configurazione di cui è stato eseguito il deployment in produzione. Per garantire l'integrità della produzione, BAB accetta solo le modifiche che soddisfano i seguenti criteri:
- Sono a prova di manomissione e firmati
- Provengono da un build party e da una posizione di origine identificati
- Sono stati esaminati e approvati esplicitamente da una parte distinta dall'autore del codice
Se ti interessa applicare alcuni degli stessi concetti nel ciclo di vita di sviluppo del tuo software, abbiamo incluso i concetti chiave di BAB in una specifica aperta chiamata Supply-chain Levels for Software Artifacts (SLSA). SLSA funge da framework di sicurezza per lo sviluppo e l'esecuzione del codice negli ambienti di produzione.
Conclusione
Google Cloud si basa su decenni di investimenti di Google nell'eccellenza dello sviluppo. L'integrità del codice e della produzione sono principi culturali instillati in tutti i team di ingegneri di Google. Il nostro processo di revisione della progettazione garantisce che le implicazioni sul codice e sullo stato di produzione vengano prese in considerazione fin dall'inizio. Il nostro processo di sviluppo, basato sul principio dello spostamento a sinistra e su test approfonditi, garantisce che le idee di progettazione vengano implementate in modo sicuro e corretto. La nostra procedura di qualifica espande ulteriormente i test per coprire integrazioni su larga scala e dipendenze esterne. Infine, la nostra piattaforma di implementazione ci consente di aumentare gradualmente la certezza che una determinata modifica si comporti effettivamente come previsto. Dalla progettazione alla produzione, il nostro approccio ci consente di soddisfare Google Cloud le aspettative dei clienti in termini di velocità di sviluppo e affidabilità.