Carichi di lavoro di Azure Well-Architected Framework
Nel contesto di Azure Well-Architected Framework, il termine carico di lavoro si riferisce a una raccolta di risorse dell'applicazione, dati e infrastruttura di supporto 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 funzionali. I carichi di lavoro possono essere classificati in molti tipi.
I criteri tipici per la classificazione del carico 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 fattori influenti, ad esempio piattaforme tecnologiche o allineamento con un settore.
Destinatari previsti. Esempi di soluzioni con vari destinatari sono applicazioni line-of-business interne all'interno di aziende, una soluzione fornitore di software indipendente (ISV) acquistata o una soluzione SaaS (Software as a Service) multi-tenant per l'uso pubblico.
I carichi di lavoro che si trovano nella stessa classe possono condividere analogie, tra cui destinatari, requisiti di conformità e stack di tecnologie. I cinque pilastri di Well-Architected Framework, i relativi principi, elenchi di controllo e compromessi sono rilevanti per tutte le classi di carico di lavoro.
Le linee guida per il carico di lavoro di Well-Architected Framework descrivono le priorità e i compromessi comuni relativi a classi di carico di lavoro specifiche. Nelle linee guida per il carico di lavoro, le linee guida fondamentali si applicano ai principi di progettazione tecnici 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 ed efficienza delle prestazioni.
 Per creare un carico di lavoro di successo, svilupparlo in base ai principi di Well-Architected Framework, basati sugli ideali seguenti. |
|---|
Un carico di lavoro di Framework ben progettato:
- Ha requisiti funzionali e non funzionali definiti e classificati in ordine di priorità per raggiungere un obiettivo.
- È progettato in modo da poter ottenere tali requisiti usando le risorse e incorporando modelli di progettazione e compromessi.
- Viene costruito e gestito in base alle specifiche di un design e di uno scopo.
- Viene misurata in base al modo in cui raggiunge adeguatamente il suo scopo.
- Può adattarsi in base al suo scopo è perfezionato o modificato.
- È altrettanto affidabile come deve essere.
- È altrettanto sicuro come deve essere.
- Offre un ritorno sufficiente sugli investimenti.
- Viene sviluppato e gestito in modo responsabile.
- Raggiunge 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 software engineer Architetti di soluzioni cloud Data scientist o analisti Amministratori di database |
Tecnici DevOps Ingegneri dell'infrastruttura Responsabili o proprietari di prodotti Ingegneri di controllo della qualità Membri del team di supporto |
Team centralizzati e stakeholder
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 si ottiene in parte grazie al successo dei carichi di lavoro dell'organizzazione. Forniscono servizi, linee guida e protezioni per i carichi di lavoro.
| Esempi di team centralizzati e membri del team | |
|---|---|
| Analisti di Business Intelligence Stakeholder aziendali Scheda CCoE (Cloud Center of Excellence) Team della piattaforma cloud Analisti della cybersecurity Amministratori di database Progettisti aziendali |
Analisti finanziari Ingegneri dell'infrastruttura Responsabili legali e di conformità Tecnici di rete Specialisti dell'approvvigionamento Responsabili di progetto |
Un team del carico di lavoro Well-Architected Framework è incentrato sui risultati del carico di lavoro. Si coordinano con e traggono vantaggio dal supporto specializzato dei membri centralizzati del team.
Modello di responsabilità condiviso
È necessario distribuire e usare un carico di lavoro per recapitare 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 sono presenti nel contesto dell'organizzazione. Un'organizzazione ha spesso ruoli di governance e autorità regolamentati. 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à con Cloud Adoption Framework per Azure, standardizzare le risorse cloud del carico di lavoro. Applicare rigorosamente la standardizzazione per fornire una piattaforma regolamentata per facilitare 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 formalizzata e completamente allineata alle zone di destinazione di Azure. Oppure l'organizzazione potrebbe avere una strategia di adozione diversa o nessuna implementazione. Se non è disponibile alcuna implementazione, i team del carico di lavoro sono quasi completamente autonomi.
Per qualsiasi piattaforma e governance usata dall'organizzazione, è necessario applicare i principi di Well-Architected Framework ai carichi di lavoro. Il framework ben progettato fa spesso riferimento alle zone di destinazione di Azure, ma non dipende da un'implementazione specifica della piattaforma. I pilastri, i principi, gli elenchi di controllo e le guide del framework ben progettato sono per tutte le piattaforme cloud e la maggior parte dei tipi di carico di lavoro.
Rispetto dei requisiti
In tutto il framework ben progettato, ad esempio i pilastri di base e le linee guida per il carico di lavoro, le raccomandazioni coincidono con l'obbligo del carico di lavoro. Le raccomandazioni in genere non implicano 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 congiunto con i team centralizzati. Ad esempio, le scelte di implementazione potrebbero essere basate su protezioni impostate da un team centralizzato. 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 aiutare il codeliver sugli obiettivi del carico di lavoro. Se si esternalizzano componenti o responsabilità, è necessario soddisfare correttamente tali obblighi.
Informazioni sui vincoli
Un team centralizzato supporta carichi di lavoro diversi in base alle funzionalità principali del team e all'infrastruttura di base. Per fornire questo supporto su scala organizzativa, il team centralizzato potrebbe implementare uniformità e vincoli sul servizio offerto o sull'infrastruttura. Quando si progetta il carico di lavoro, è fondamentale comprendere tali vincoli e, ove possibile, collaborare con gli architetti aziendali che conoscono tali vincoli. Apprendere le implementazioni precedenti il più possibile.
Ogni implementazione della governance della piattaforma è diversa, ma i vincoli seguenti sono comuni per molti carichi di lavoro:
- Elenchi di elementi consentiti per le risorse cloud
- Requisiti di configurazione per le risorse cloud
- Elenchi di indirizzi 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 ufficio
- Requisiti di applicazione di patch
- Implementazione specifica di hub-spoke, che determina le implementazioni dns (Domain Name System) e degli endpoint privati
- Requisiti di controllo della catena di approvvigionamento
Comunicare in modo esplicito i requisiti
Se il requisito del carico di lavoro è dovuto a un vincolo o a un contratto di servizio (SLA) che non definisce chiaramente una funzionalità o un'offerta di infrastruttura di base, considerare tale situazione come un rischio. Per affrontare questo rischio, il team del carico di lavoro deve fornire chiarezza agli altri team su come il problema influisce sul carico di lavoro. Potrebbe essere necessario modificare i requisiti, la progettazione o l'implementazione del carico di lavoro 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 realistiche.
Comunicare i requisiti comuni del carico di lavoro
Ogni partnership di piattaforma è diversa, ma le aree seguenti sono argomenti comuni nelle conversazioni di responsabilità condivisa:
- Requisiti legali e di conformità
- 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 in tempo reale efficace
- Requisiti di prestazioni, ad esempio velocità effettiva della rete, disponibilità delle risorse cloud o disponibilità a livello di area
- Aspettative per l'accesso a Internet pubblico da un punto di vista in uscita e in ingresso
- Obiettivi del livello di servizio (SLO) o contratti di servizio offerti agli utenti del carico di lavoro
- Disponibilità del supporto tecnico
Cercare le vittorie unificate
La responsabilità condivisa non riguarda solo compromessi, vincoli e compromessi. 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. Poiché un team di sicurezza centralizzato esegue attività di sviluppo sicure su larga scala nell'intera organizzazione, può eseguire test di penetrazione di routine superiori e superiori alle proprie 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 impegno se si è allineati ai modelli e alle procedure di un team dell'architettura aziendale perché il team ha già semplificato i processi. È anche possibile impedire la rielaborazione se una soluzione non è possibile all'interno della partnership senza negoziazione.
Spese per biglietti di grandi dimensioni. I team della piattaforma spesso ospitano componenti o servizi troppo costosi o troppo gestiti per un singolo team del carico di lavoro. I team della piattaforma possono permettersi questi componenti e servizi perché dividono i costi tra carichi di lavoro.
Spesso questi servizi o piattaforme centralizzate vengono offerti come semplice showback, in modo da mantenere ottimizzato il costo del carico di lavoro. E quando vengono offerti come chargeback, spesso sono più economici a causa delle economie di scala e centralizzazione.
I team della piattaforma spesso offrono opzioni self-service ai team del carico di lavoro per varie attività. Ad esempio:
- Fornire un repository di documentazione per l'istruzione autoguidato
- Onboarding nella gestione dei costi tramite l'assegnazione di tag alle risorse specifiche
- Offerta di sottoscrizioni tramite un processo formale di distribuzione automatica delle sottoscrizioni
Esplorare le opzioni di progettazione self-service e della piattaforma che potrebbero essere adatte per il 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, condividerlo con i team partner. Indicare loro come hanno contribuito al successo del carico di lavoro. Quando il carico di lavoro non soddisfa gli 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 prevedere ai partner se il carico di lavoro funziona bene con un'offerta o se è a rischio di essere un vicino rumoroso.
Cercare di migliorare continuamente
Un tema su tutti i pilastri del framework ben progettato è un miglioramento continuo. Adottare una mentalità progressiva. È possibile gestire nuovi approcci ai problemi esistenti, adottare una nuova tecnologia, soddisfare nuovi requisiti o operare con nuovi vincoli. Man mano che il carico di lavoro migliora nel tempo, aspettarsi la stessa mentalità dei team partner. Tuttavia, ogni opportunità di miglioramento implica anche modifiche e deve essere supportata da un processo di gestione appropriato.
I team del carico di lavoro hanno l'obbligo di comunicare con i team della piattaforma sulle modifiche proposte ai requisiti del carico di lavoro che potrebbero avere un 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 cadenza di comunicazione regolare con i partner per apprendere e condividere le modalità di evoluzione di un prodotto.
Ottenere un risultato positivo
I carichi di lavoro hanno molte aspettative da utenti, azionisti, organismi normativi, dipendenti, centro di eccellenza e responsabili dell'esperienza. Le aspettative possono impostare la rotazione direzionale della bussola. Well-Architected Framework fornisce chiarezza relativa alla progettazione e all'implementazione offrendo razionalizzazioni esplicite per le decisioni architetturali per ottenere un risultato positivo. Sviluppare un carico di lavoro riuscito e condividerlo con l'organizzazione.