Share via


Carichi di lavoro di Azure Well-Architected Framework

Nel contesto di Azure Well-Architected Framework, il termine carico di lavoro fa riferimento a una raccolta di risorse, dati e supporto dell'infrastruttura che funzionano insieme per ottenere risultati aziendali definiti. Un carico di lavoro è costituito da componenti e anche procedure operative e di sviluppo.

Gli architetti progettano carichi di lavoro e un team del carico di lavoro li implementa. Un carico di lavoro è progettato e implementato per ottenere requisiti aziendali funzionali e non funzionanti. I carichi di lavoro possono essere classificati in molti tipi.

I criteri tipici per la classificazione dei carichi di lavoro includono:

  • Utilità, caratteristiche e modelli di utilizzo di un carico di lavoro, ad esempio applicazioni Web, elaborazione batch e analisi in tempo reale.

  • Principali driver influenti, ad esempio piattaforme tecnologiche o allineamento con un settore.

  • Destinatari di destinazione previsti. Esempi di soluzioni con vari destinatari sono applicazioni line-of-business interne all'interno di aziende, una soluzione fornitore di software indipendente acquistato (ISV) o una soluzione software multi-tenant come servizio (SaaS) per l'uso pubblico.

I carichi di lavoro che si trovano nella stessa classe possono condividere somiglianze, inclusi i destinatari di destinazione, i requisiti di conformità e gli stack tecnologici. I cinque pilastri del framework Well-Architected, i loro principi, elenchi di controllo e compromessi sono rilevanti per tutte le classi di carico di lavoro.

Le linee guida per il carico di lavoro del framework di Well-Architected descrivono le priorità e i compromessi comuni in quanto riguardano classi di carico di lavoro specifiche. Nelle linee guida per il carico di lavoro, le linee guida del pilastro si applicano ai principi di progettazione tecnica e alle aree di progettazione che rappresentano le priorità di un carico di lavoro. Seguire le raccomandazioni per configurare un carico di lavoro riuscito e allinearlo a Well-Architected Framework.

Che cos'è un carico di lavoro Well-Architected Framework?

La progettazione e le operazioni di qualsiasi carico di lavoro devono affrontare i cinque pilastri dell'architettura: affidabilità, sicurezza, ottimizzazione dei costi, eccellenza operativa e efficienza delle prestazioni.

Per creare un carico di lavoro riuscito, svilupparlo in conformità ai principi del framework di Well-Architected, basati sugli ideali seguenti.

Carico di lavoro Well-Architected Framework:

  • Dispone di requisiti funzionali e non funzionali definiti e con priorità per raggiungere un obiettivo.
  • È progettato in modo da poter ottenere tali requisiti usando risorse e incorporando modelli di progettazione e compromessi.
  • Viene costruito e gestito per le specifiche di una progettazione e uno scopo.
  • Viene misurata in base al modo in cui raggiunge il suo scopo.
  • Può adattarsi come scopo è affinato o modificato.
  • È così affidabile come deve essere.
  • È così sicuro come deve essere.
  • Restituisce un rendimento sufficiente sugli investimenti.
  • Viene sviluppato e gestito in modo responsabile.
  • Ottiene lo scopo entro un periodo di tempo accettabile.

Una collaborazione tra il team del carico di lavoro e i team centrali di un'organizzazione deve creare un carico di lavoro con le caratteristiche precedenti. Le sezioni seguenti descrivono questi team e le relative funzioni.

Team del carico di lavoro

Creare un team del carico di lavoro con membri del team con un'ampia gamma di discipline tecniche e aziendali. L'obiettivo principale di tutti i membri del team deve essere il successo del carico di lavoro.

Esempi di membri del team del carico di lavoro  
Ingegneri della sicurezza delle applicazioni
Stakeholder aziendali
Sviluppatori cloud o ingegneri software
Architetti di soluzioni cloud
Data scientist o analisti
Amministratori di database
Tecnici DevOps
Ingegneri dell'infrastruttura
Manager o proprietari di prodotti
Ingegneri di quality assurance (QA)
Membri del team di supporto

Team e stakeholder centralizzati

I team centralizzati spesso supportano il team del carico di lavoro. Forniscono funzioni di supporto e applicano la governance per molti o tutti i carichi di lavoro cloud all'interno di un'organizzazione. I team centralizzati si concentrano sul successo dell'organizzazione, che viene ottenuto in parte dal successo dei carichi di lavoro dell'organizzazione. Forniscono servizi, linee guida e guardrail per i carichi di lavoro.

Esempi di team e membri del team centralizzati  
Analisti di Business Intelligence
Stakeholder aziendali
Scheda Centro cloud di eccellenza (CCoE)
Team della piattaforma cloud
Analisti della sicurezza informatica
Amministratori di database
Architetti aziendali
Analisti finanziari
Ingegneri dell'infrastruttura
Funzionari legali e di conformità
Tecnici di rete
Specialisti dell'approvvigionamento
Project manager

Un team del carico di lavoro di Well-Architected Framework è incentrato sui risultati del carico di lavoro. Si coordinano con e beneficiano del supporto specializzato dai membri del team centralizzati.

Modello di responsabilità condivisa

Un carico di lavoro deve essere distribuito e usato per fornire valore. Come parte del team del carico di lavoro, si ha la responsabilità di progettare, implementare e distribuire il carico di lavoro in modo da creare valore all'organizzazione.

I carichi di lavoro esistono nel contesto dell'organizzazione. Un'organizzazione spesso ha regolamentato i ruoli di governance e autorità. Il team del carico di lavoro ha la responsabilità di progettare, implementare e distribuire un carico di lavoro all'interno della base dell'organizzazione.

In conformità alle Cloud Adoption Framework per Azure, standardizzare le risorse cloud del carico di lavoro. Applicare rigorosamente la standardizzazione per fornire una piattaforma regolamentata per consentire l'onboarding dei team del carico di lavoro. Applicare questa governance in base al modello operativo cloud dell'organizzazione.

È possibile usare le zone di destinazione di Azure per semplificare l'esecuzione della standardizzazione. Le zone di destinazione della piattaforma e le zone di destinazione dell'applicazione sono disponibili in Azure. Distribuire il carico di lavoro in una zona di destinazione dell'applicazione.

L'organizzazione potrebbe avere un'offerta di piattaforma cloud rigorosamente formale e completamente allineata alle zone di destinazione di Azure. O l'organizzazione potrebbe avere una strategia di adozione diversa o nessuna implementazione. Se non esiste alcuna implementazione, i team del carico di lavoro sono quasi completamente autonomi.

Per qualsiasi piattaforma e governance usata dall'organizzazione, è necessario applicare i principi del framework di Well-Architected ai carichi di lavoro. Il framework Well-Architected fa spesso riferimento alle zone di destinazione di Azure, ma non dipende da un'implementazione specifica della piattaforma. I pilastri Well-Architected Framework, i principi, gli elenchi di controllo e le guide sono per tutte le piattaforme cloud e la maggior parte dei tipi di carico di lavoro.

Soddisfare i requisiti

In tutto il framework Well-Architected, ad esempio i pilastri principali e le linee guida per il carico di lavoro, le raccomandazioni coincidono con l'obbligo del carico di lavoro. Le raccomandazioni non implicano in genere ciò che il membro del team o il team facilita tali obblighi. È possibile determinare chi deve eseguire ogni azione. Eseguire il mapping a livello di carico di lavoro per determinare i ruoli e le responsabilità del team correlati alla topologia, al tipo di carico di lavoro e alla criticità.

Il team del carico di lavoro diretto gestisce la maggior parte dei requisiti del carico di lavoro. Alcuni requisiti vengono gestiti come uno sforzo comune con i team centralizzati. Ad esempio, le scelte di implementazione potrebbero essere basate su guardrail che un team centralizzato imposta. Oppure un team centralizzato potrebbe gestire esclusivamente le scelte di implementazione.

Il team del carico di lavoro deve creare una relazione di lavoro con altri team per facilitare il codeliver sugli obiettivi del carico di lavoro. Se si estraono componenti o responsabilità in uscita, è necessario fornire correttamente tali obblighi.

Informazioni sui vincoli

Un team centralizzato supporta carichi di lavoro diversi in base alle funzionalità principali del team e all'infrastruttura principale. Per fornire questo supporto su una scala organizzativa, il team centralizzato potrebbe implementare uniformità e vincoli per il servizio offerto o l'infrastruttura. Quando si progetta il carico di lavoro, è fondamentale comprendere tali vincoli e, se possibile, collaborare con gli architetti aziendali che conoscono tali vincoli. Informazioni sulle implementazioni precedenti il più possibile.

Ogni implementazione della governance della piattaforma è diversa, ma i vincoli seguenti sono comuni per molti carichi di lavoro:

  • Consenti elenchi per le risorse cloud
  • Mandato di configurazione per le risorse cloud
  • Elenchi consentiti a livello di area per le risorse cloud e la disponibilità della connettività cross-premise
  • Supporto limitato o nessuna piattaforma al di fuori dell'orario di lavoro
  • Requisiti di patch
  • Implementazione specifica dell'hub spoke, che consente di eseguire l'implementazione di Domain Name System (DNS) e dell'endpoint privato
  • Requisiti di controllo della catena di fornitura

Comunicare in modo esplicito i requisiti

Se il requisito del carico di lavoro viene affrontato con un vincolo o un contratto di servizio (contratto di servizio) che non definisce chiaramente una funzionalità di base o un'offerta di infrastruttura, considera questa situazione come rischio. Per risolvere questo rischio, il team del carico di lavoro deve fornire chiarezza agli altri team su come influisce sul carico di lavoro. Potrebbe essere necessario modificare i requisiti del carico di lavoro, la progettazione o l'implementazione o modificare l'offerta di infrastruttura.

Quando si comprendono gli obblighi del team della piattaforma correlati alle direttive organizzative e agli obblighi del team del carico di lavoro, è possibile comunicare i requisiti del carico di lavoro con aspettative e raccomandazioni realistice.

Comunicare i requisiti comuni del carico di lavoro

Ogni partnership della piattaforma è diversa, ma le aree seguenti sono argomenti comuni nelle conversazioni di responsabilità condivise:

  • Requisiti di conformità e legali
  • Specifiche di rete, ad esempio la necessità di indirizzi IP in ingresso statici o in uscita
  • Requisiti di osservabilità per fornire la valutazione del sito live efficace
  • Requisiti di prestazioni, ad esempio velocità effettiva di rete, disponibilità delle risorse cloud o disponibilità a livello di area
  • Aspettative per l'accesso a Internet pubblico da una prospettiva di uscita e ingresso
  • Obiettivi a livello di servizio o contratti di servizio offerti agli utenti del carico di lavoro
  • Disponibilità del supporto tecnico

Cercare vittorie unificate

La responsabilità condivisa non riguarda solo i compromessi, i vincoli e la compromissione. I team della piattaforma hanno spesso competenze altamente specializzate e budget dedicati che possono aumentare oltre a ciò che un singolo team del carico di lavoro può sostenere. Si considerino gli esempi seguenti.

Specialisti della sicurezza. Il carico di lavoro potrebbe avere un ciclo di vita di sviluppo sicuro. Il team di sicurezza centralizzato esegue attività di sviluppo sicure su larga scala nell'organizzazione, può eseguire test di penetrazione di routine superiori e superiori alle attività. Può anche essere utile per la pianificazione e l'esecuzione di una strategia di risposta agli eventi imprevisti.

Linee guida per l'architettura aziendale. È possibile risparmiare tempo e sforzo se si allineano ai modelli e alle procedure del team dell'architettura aziendale perché il team ha già semplificato i processi. È anche possibile evitare di rielaborare se una soluzione non è possibile all'interno della partnership senza negoziazione.

Spese di big ticket. I team della piattaforma ospitano spesso componenti o servizi troppo costosi o troppo costosi per un singolo team di carico di lavoro. I team della piattaforma possono offrire questi componenti e servizi perché dividono i costi tra carichi di lavoro.

Spesso questi servizi o piattaforme centralizzate vengono offerti come semplici showback, in modo da mantenere ottimizzato il costo del carico di lavoro. E quando vengono offerti come chargeback, spesso sono più economici a causa di economie di scala e centralizzazione.

I team della piattaforma offrono spesso opzioni self-service ai team del carico di lavoro per varie attività. Ad esempio:

  • Fornire un repository di documentazione per l'istruzione auto-guidata
  • Onboarding in gestione dei costi tramite tag di risorse specifici
  • Offerta di sottoscrizioni tramite un processo formale di distribuzione delle sottoscrizioni

Esplorare le opzioni self-service che potrebbero essere adatte al carico di lavoro.

Condividere successi e sfide

Responsabilità condivisa con altri team significa anche condividere successi e sfide di un carico di lavoro. Quando il carico di lavoro soddisfa gli obblighi e ottiene il valore previsto, condividere tale valore con i team partner. Dirle come hanno contribuito al successo del carico di lavoro. Quando il carico di lavoro non soddisfa i propri obblighi, condividere ciò che non funziona e collaborare e ricalibrare per tornare in pista.

I team della piattaforma hanno anche obblighi e criteri di successo. È consigliabile che i partner ti dicano se il carico di lavoro funziona bene con un'offerta o se è a rischio di essere un vicino rumoroso.

Cercare un miglioramento continuo

Un tema tra tutti i pilastri Well-Architected Framework è un miglioramento continuo. Adottare una mentalità progressiva. È possibile affrontare nuovi approcci ai problemi esistenti, adottare nuove tecnologie, soddisfare nuovi requisiti o operare con nuovi vincoli. Poiché il carico di lavoro migliora nel tempo, aspettarsi la stessa mentalità dei team partner. Tuttavia, ogni opportunità di miglioramento significa anche modifiche e deve essere supportata da un processo di gestione appropriato.

I team del carico di lavoro hanno un obbligo di comunicare con i team della piattaforma sulle modifiche proposte ai requisiti del carico di lavoro che potrebbero avere effetto sui servizi del team della piattaforma. Analogamente, i team della piattaforma hanno l'obbligo di includere i partner del carico di lavoro nei processi di controllo delle modifiche e comunicare chiaramente le modifiche della piattaforma interessate. Stabilire una regolare cadenza di comunicazione con i partner per apprendere e condividere il modo in cui un prodotto si evolve.

Ottenere un risultato positivo

I carichi di lavoro hanno molte aspettative da utenti, azionisti, organi normativi, dipendenti, centro di eccellenza e responsabili dell'esperienza. Le aspettative possono impostare la bussola direzionale che gira. Il framework Well-Architected fornisce chiarezza correlata alla progettazione e all'implementazione offrendo razionalizzazioni esplicite per le decisioni dell'architettura per ottenere un risultato positivo. Sviluppare un carico di lavoro riuscito e condividere tale successo con l'organizzazione.