Gestione dell'affidabilità

Anche se i servizi di produzione non sono in un abbonamento Dev/Test, potresti utilizzare altre fasi del tuo abbonamento Azure Dev/Test per garantire l'affidabilità in produzione.

Note

Gli abbonamenti Azure Dev/Test sono pensati per test e sviluppo in pre-produzione e non hanno un SLA garantito finanziariamente. Prima di scegliere un abbonamento Dev/Test, esamina le opzioni disponibili di abbonamento Azure Dev/Test per determinare quale offerta si adatta meglio alle tue esigenze di sviluppo e test.

Risorse correlate:

Quando utilizzi gli abbonamenti Dev/Test della tua organizzazione, decidi come fai:

  • Dati di controllo
  • Controllare la sicurezza e l'accesso
  • Gestisci la disponibilità di quel sistema di produzione

Tipicamente, ci sono diverse fasi di distribuzione che si attraversano prima della produzione: condiviso, QA, integrazione, staging e failover. A seconda di come la tua azienda definisce queste fasi, l'uso di un abbonamento Dev/Test per l'organizzazione potrebbe cambiare.

Se stai gestendo servizi mission-critical come applicazioni rivolte al cliente, non usare un abbonamento Dev/Test. Le sottoscrizioni di sviluppo/test non hanno un contratto di servizio con supporto finanziario. Queste sottoscrizioni sono destinate ai test di preproduzione e allo sviluppo.

Ingegneria dell'Affidabilità del Sito (SRE)

Per altre informazioni sull'ingegneria e sulla gestione dell'affidabilità, prendere in considerazione la gestione dell'affidabilità del sito, una disciplina di progettazione dedicata all'assistenza alle organizzazioni per ottenere in modo sostenibile l'affidabilità nei sistemi, nei servizi e nei prodotti.

Il modo in cui SRE e DevOps differiscono è ancora oggetto di discussione nel settore. Alcune differenze ampiamente concordate includono:

  • SRE è una disciplina di progettazione incentrata sull'affidabilità. DevOps è un movimento culturale che è emerso dalla necessità di abbattere i silo associati alle organizzazioni di sviluppo e operazioni.
  • SRE può essere il nome di un ruolo, come in: sono un ingegnere di affidabilità in sito (SRE). DevOps non può.
  • L'SRE tende a essere prescrittivo. DevOps non lo è intenzionalmente. L'adozione quasi universale dell'integrazione continua/consegna continua e dei principi Agile sono quanto di più vicino ci sia al DevOps.

Per altre informazioni sulla pratica di SRE, vedere i collegamenti seguenti:

Contratti del livello di servizio

Enterprise Dev/Test è destinato esclusivamente allo sviluppo e al test delle tue applicazioni. L'uso dell'abbonamento non prevede uno SLA con garanzia finanziaria.

Informazioni su come usare diversi tipi di sottoscrizioni di sviluppo/test

Sia che siano necessari crediti Azure mensili per i sottoscrittori di Visual Studio, le sottoscrizioni di sviluppo/test enterprise o una sottoscrizione Sviluppo/test con pagamento in base al consumo (PAYG), è possibile trovare facilmente offerte che funzionano per utenti singoli o team.

I singoli Azure Credits sono destinati a scenari individuali di sviluppo e test, mentre gli abbonamenti Enterprise Dev/Test sono disponibili per lo sviluppo di team in grandi organizzazioni. Esamina le opzioni di abbonamento disponibili per determinare quale offerta si adatta meglio alle tue esigenze di sviluppo e test.

Gestione delle iscrizioni individuali a crediti

I crediti di Azure di Visual Studio costituiscono un vantaggio individuale per attività individuali di Dev/Test e sviluppo nell'inner loop. Non puoi mettere in comune i crediti tra gli sviluppatori. Le sottoscrizioni di credito sono ancora sottoscrizioni di Azure, ma un'offerta di Azure specifica. Gestire le sottoscrizioni di credito nello stesso modo in cui si gestiscono altre sottoscrizioni di Azure in modo da poter lavorare all'interno di gruppi e team. Puoi eliminare i limiti di spesa individuali aggiungendo una carta di credito, oppure se il tuo abbonamento aziendale Dev/Test va al metodo di approvvigionamento scelto dalla tua azienda.

Nelle attività interne di sviluppo si usano spesso crediti, ma poi si passa a sottoscrizioni Azure Dev/Test dell'azienda o dell'organizzazione, incluse quelle con pagamento in base al consumo. In questo modo, man mano che si seguono i processi DevOps, è possibile eseguire il ciclo interno con la sottoscrizione di credito individuale. Nel ciclo esterno DevOps, le destinazioni di non produzione si trovano nello sviluppo/test aziendale- prod passa a prod.

Gestisci i tuoi abbonamenti a crediti, abbonamenti di sviluppo/test enterprise e abbonamenti PAYG e segmenta i tuoi sviluppatori usando gruppi di gestione ciascuno con una gerarchia unica.

Usando le offerte Azure Dev/Test della tua organizzazione

Se è necessaria una sottoscrizione di Sviluppo/test di Azure dell'organizzazione, sono disponibili due offerte tra cui scegliere.

Ogni opzione offre un proprio set di sconti e richiede un abbonamento Visual Studio.

Ogni offerta di abbonamento ti permette di far partire il tuo team con ambienti Dev/Test nel cloud utilizzando macchine virtuali preconfigurate. Creare più sottoscrizioni di Azure e gestirle da un account. È possibile gestire ambienti isolati e una fattura separata per progetti o team diversi.

Le sottoscrizioni di sviluppo/test enterprise richiedono un contratto Enterprise Agreement (EA). Le sottoscrizioni Dev/Test con pagamento in base al consumo non richiedono un EA, ma possono essere usate con un account con contratto Enterprise Agreement.

Perché usare le offerte PAYG rispetto a quelle di sviluppo/test aziendali?

Un'offerta Dev/Test con pagamento in base al consumo potrebbe essere la soluzione giusta da usare se sei un abbonato a Visual Studio. A differenza delle sottoscrizioni di credito per uso individuale, le offerte con pagamento in base al consumo sono ideali per lo sviluppo in team e consentono di avere più utenti all'interno di una sottoscrizione. Un'offerta di sviluppo/test con pagamento in base al consumo potrebbe essere ideale se:

  • Non si ha un contratto Enterprise. In questo caso, è possibile creare un account con pagamento in base al consumo solo con una licenza di Visual Studio.
  • Stai creando un accordo aziendale, ma devi impostare un abbonamento che non utilizzi l'accordo della tua organizzazione. Potresti avere un progetto specifico che richiede un proprio abbonamento oppure la creazione di un ambiente isolato con fatturazione separata per progetti o team.
  • Si preferisce mantenere isolate le identità. Potrebbe essere necessario che alcune identità rimangano separate da altre per proteggere l'accesso a dati, risorse e app.
  • Last updated on