Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / Microsoft Cloud Adoption Framework spiegato: strategia, pianificazione e landing zone di Azure (Doppiaggio IA)

Transcript

Microsoft Cloud Adoption Framework spiegato: strategia, pianificazione e landing zone di Azure (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

0:00
Speaker 2: Pronto per dieci giorni di Microsoft 365 e Copilot, intelligenza artificiale,
0:04
Speaker 2: Azure e le persone che stanno plasmando il futuro del
0:06
Speaker 2: lavoro e... A gennaio torna M365 con e ci stiamo espandendo.
0:12
Speaker 2: Unisciti a noi per sessioni live, dimostrazioni pratiche e conoscenze
0:15
Speaker 2: pratiche da parte di MVP ed esperti del settore di
0:17
Speaker 2: tutto il mondo. Nessuna slide generica, nessun termine di moda infinito.
0:22
Speaker 2: Stiamo affrontando le vere sfide. Copilot Studio, agenti di intelligenza artificiale, Fabric, Sicurezza,
0:27
Speaker 2: Governance e Automazione. Che tu sia un professionista IT, uno
0:31
Speaker 2: sviluppatore o un leader aziendale, ci sono sessioni pensate per te.
0:35
Speaker 2: Con 10 giorni interi puoi esplorare diverse tecnologie e connetterti
0:38
Speaker 2: con una community globale. Guarda in diretta e porta spunti
0:42
Speaker 2: pratici alla tua organizzazione. Gennaio 2027, 10 giorni, una community Microsoft.
0:49
Speaker 2: Le registrazioni sono aperte ora. Vai subito a casa tua.
1:00
Speaker 2: iscriviti ora su m365con. net e ci vediamo dal vivo a
1:04
Speaker 2: gennaio la maggior parte dei team inizia il proprio percorso
1:07
Speaker 2: in azzurro aprendo un abbonamento creando una macchina virtuale selezionando
1:10
Speaker 2: i servizi man mano che procedono punto di partenza migliore
1:13
Speaker 2: è molto meno entusiasmante ma evita molte seccature in seguito
1:16
Speaker 2: decidi perché ti stai trasferendo cosa stai trasferendo e quali
1:18
Speaker 2: regole devono essere rispettate alle persone prima di iniziare pensa
1:20
Speaker 2: ad aprire un ufficio potresti affittare stanze casuali in edifici
1:23
Speaker 2: diversi distribuire le chiavi senza un elenco e sperare che
1:26
Speaker 2: ogni reparto si occupi autonomamente di internet archiviazione e sicurezza
1:30
Speaker 2: Le persone potrebbero continuare a lavorare per un po', ma
1:32
Speaker 2: non sembrerebbe un unico ufficio. Oppure potresti allestire un edificio
1:36
Speaker 2: sicuro in cui le persone sappiano dove andare, chi può entrare,
1:38
Speaker 2: quanto costa ogni spazio e chi risolve i problemi. Ecco
1:40
Speaker 2: cosa ti aiuta a fare Microsoft Cloud Adoption Framework, spesso
1:43
Speaker 2: denominato CAF. Si tratta di linee guida Microsoft per spostare
1:45
Speaker 2: il lavoro in Azure e quindi eseguirlo nel tempo. Esamineremo
1:48
Speaker 2: i suoi sei elementi costitutivi, cosa significa realmente una landing
1:51
Speaker 2: zone di Azure e perché la governance non può attendere
1:53
Speaker 2: fino alla fine. Molti team saltano una parte e spesso
1:57
Speaker 2: la rimandano. Perché CAF è il problema degli edifici per uffici.
2:02
Speaker 2: Prima che i servizi cloud diventassero comuni, molte aziende costruivano
2:04
Speaker 2: i propri IT passo dopo passo. La posta elettronica veniva
2:07
Speaker 2: eseguita su un server, l'archiviazione dei file altrove, un'applicazione aveva
2:10
Speaker 2: il proprio server, il proprio piano di backup e talvolta
2:12
Speaker 2: una persona che ne sapeva il funzionamento. Le decisioni in
2:14
Speaker 2: materia di sicurezza potevano sistemare l'altro. Un team gestiva le reti,
2:18
Speaker 2: un altro i server. Il reparto finanziario riceveva le fatture,
2:20
Speaker 2: ma spesso non riusciva a vedere quale reparto causava la spesa.
2:23
Speaker 2: La configurazione è cresciuta nel corso degli anni, solitamente perché
2:25
Speaker 2: ogni nuovo problema necessitava di una soluzione. Azure offre più
2:28
Speaker 2: opzioni più velocemente. Ciò non significa che Azure risolva automaticamente
2:31
Speaker 2: i problemi di costi, sicurezza e distribuzione lenta. Se crei
2:33
Speaker 2: risorse cloud senza decisioni condivise, puoi ricreare lo stesso vecchio
2:36
Speaker 2: pasticcio solo con più pulsanti e una fattura mensile che
2:39
Speaker 2: cambia ogni giorno. CAF è la mappa di Microsoft per
2:41
Speaker 2: evitare tutto ciò. Non è un prodotto che installi. Non
2:44
Speaker 2: è una certificazione Azure. E non è una configurazione con
2:47
Speaker 2: un clic che trasforma un abbonamento Azure vuoto in un
2:49
Speaker 2: ambiente cloud finito. Al contrario, ti offre un modo per
2:51
Speaker 2: riflettere sul lavoro. Decidi perché l'organizzazione ha bisogno di Azure.
2:55
Speaker 2: Pianifica cosa spostare. Prepari un luogo in cui ospitare i
2:57
Speaker 2: carichi di lavoro. Quindi li sposti, li proteggi, li gestisci,
2:59
Speaker 2: li gestisci. Torniamo al nostro edificio. Il titolare dell'azienda decide
3:03
Speaker 2: cosa deve supportare l'edificio. La reception verifica chi è autorizzato
3:06
Speaker 2: a entrare. Ogni reparto lavora nella propria stanza. Le regole
3:09
Speaker 2: dell'edificio controllano l'accesso, la sicurezza e la spesa. Nel frattempo,
3:12
Speaker 2: il team delle strutture tiene accese le luci, interviene in
3:14
Speaker 2: caso di rottura e verifica che l'edificio rimanga sicuro. L'Azzurro
3:18
Speaker 2: funziona in modo simile, sebbene le parti avevano nomi diversi.
3:20
Speaker 2: Immagina un'azienda che desidera più spazio per nuovi prodotti e
3:21
Speaker 2: persone remote. Vuole che i team creino più rapidamente, ma
3:25
Speaker 2: inizia consentendo a ogni team di creare risorse di Azure
3:27
Speaker 2: come preferisce. Un team utilizza l'accesso pubblico perché è rapido.
3:31
Speaker 2: Un altro crea servizi costosi senza un responsabile del budget.
3:34
Speaker 2: Un terzo non riesce a connettere la propria applicazione perché
3:36
Speaker 2: nessuno ha pianificato la rete. Ben presto nessuno sa chi
3:39
Speaker 2: possiede questo. Le fatture arrivano con poco contesto. L'accesso diventa
3:42
Speaker 2: troppo ampio. Correggere la configurazione significa cambiare sistemi da cui
3:45
Speaker 2: le persone dipendono. Questo è il costo di trattare l'adozione
3:47
Speaker 2: del cloud come una gita per fare shopping anziché come
3:49
Speaker 2: un trasloco in ufficio. CAF aiuta i team a prendere
3:50
Speaker 2: queste decisioni prima che la confusione diventi la norma. La
3:54
Speaker 2: prima domanda viene prima di progetti, abbonamenti o macchine virtuali.
3:58
Speaker 2: Perché questo ufficio deve esistere? Strategia è piano. Decidi perché
4:03
Speaker 2: stai costruendo. La strategia inizia con una semplice domanda. Quale
4:06
Speaker 2: problema dovrebbe risolvere Azure per la tua organizzazione? Non quale
4:10
Speaker 2: servizio Azure dovremmo acquistare. Un'azienda potrebbe dover abbandonare un data
4:14
Speaker 2: center perché è necessario sostituire vecchio ardo. Un'altra potrebbe voler
4:17
Speaker 2: rilasciare nuove funzionalità più rapidamente. Un'azienda con team in paesi
4:19
Speaker 2: diversi potrebbe aver bisogno che le sue applicazioni siano più
4:21
Speaker 2: vicine a quegli utenti. Qualcun altro potrebbe preoccuparsi di più
4:24
Speaker 2: di riprendersi da un'interruzione senza aspettare che l'ardo danneggiato venga riparato.
4:28
Speaker 2: Sono motivi diversi. Portano a decisioni diverse. Pensa a un
4:30
Speaker 2: trasloco di un ufficio. Ti stai trasferendo perché l'ufficio attuale
4:33
Speaker 2: è troppo picco. Hai bisogno di una seconda sede. Il
4:35
Speaker 2: personale remoto si reca più spesso. O il vecchio edificio
4:37
Speaker 2: ha semplicemente bisogno di troppo lavoro per continuare a funzionare.
4:39
Speaker 2: Non sceglieresti lo stesso edificio per ogni situazione. Azzurro funziona
4:42
Speaker 2: allo stesso modo. La tua strategia dovrebbe indicare il risultato
4:44
Speaker 2: che ti aspetti. Forse vuoi ridurre la tua dipendenza dal
4:47
Speaker 2: tuo data center. Forse i team di prodotto devono rilasciare
4:49
Speaker 2: aggiornamenti più spesso. Forse il personale a moto ha bisogno
4:51
Speaker 2: di un accesso più sicuro ai sistemi aziendali. Oppure il
4:53
Speaker 2: reparto finanziario ha bisogno di chiari limiti di spesa prima
4:55
Speaker 2: che i costi del cloud iniziano a crescere. Utilizza misure
4:57
Speaker 2: semplici laddove possibile. Ad esempio, sposta questi 10 server prima
5:00
Speaker 2: che termini il loro supporto. Oppure riduci il tempo necessario
5:03
Speaker 2: per rilasciare una nuova versione da settimana in giorno. Oppure
5:05
Speaker 2: assegna a ogni reparto un budget mensile per il cloud
5:07
Speaker 2: con un responsabile. Ciò offre alle persone qualcosa di concreto
5:10
Speaker 2: su cui lavorare. Senza questo i progetti cloud vanno alla deriva.
5:13
Speaker 2: Il team tecnico crea risorse. L'azienda attende i risultati. Il
5:16
Speaker 2: reparto finanziario è una fattura. La sicurezza individua i rischi
5:18
Speaker 2: in ritardo nel lavoro. Quindi tutti si pongono la stessa domanda,
5:20
Speaker 2: perché lo stiamo facendo? Una volta che il motivo è chiaro,
5:23
Speaker 2: la pianificazione trasforma quel motivo in un elenco di roba.
5:26
Speaker 2: Devi sapere quali applicazioni hai, quali dati utilizzano, chi ne
5:28
Speaker 2: è il proprietario e quali persone capiscono come funzionano. Devi
5:31
Speaker 2: anche conoscere tempistiche, rischi, competenze e dipendenze. Una dipendenza è
5:36
Speaker 2: semplicemente qualcosa di cui un'applicazione ha bisogno prima di poter funzionare.
5:38
Speaker 2: Ad esempio, una vecchia applicazione per la gestione delle buste
5:41
Speaker 2: paga potrebbe aver bisogno di un database, di una posizione
5:43
Speaker 2: di file condivisa, di una connessione a un altro sistema aziendale.
5:45
Speaker 2: Se sposti solo l'applicazione e perdi uno di questi collegamenti,
5:47
Speaker 2: lo spostamento potrebbe sembrare completo, ma la gestione del posto
5:49
Speaker 2: e paga smetterà di funzionare. Ecco dove molti team trovano
5:52
Speaker 2: delle sorprese. Un'applicazione che sembra piccola potrebbe connettersi ad altri
5:55
Speaker 2: 5 sistemi. Un server potrebbe eseguire un'attività che nessuno documenta.
5:58
Speaker 2: L'unica persona che lo capisce potrebbe aver lasciato anni fa.
6:00
Speaker 2: La pianificazione individua questi problemi, mentre hai ancora tempo per affrontare.
6:03
Speaker 2: Quindi scegli un percorso per ogni applicazione. Alcune applicazioni possono
6:06
Speaker 2: essere spostate così come sono. Questa operazione è spesso chiamata
6:08
Speaker 2: rehosting o lift and shift. Prendi il server esistente ed
6:10
Speaker 2: eseguilo in Azure con poche modifiche, Altre hanno bisogno di
6:14
Speaker 2: qualche aggiustamento per funzionare meglio con Azure. Potresti spostare un
6:16
Speaker 2: database in un servizio di database Azure gestito, ad esempio,
6:19
Speaker 2: mantenendo la maggior parte dell'applicazione invariata. Alcune applicazioni necessitano di
6:23
Speaker 2: un ricorso, ad esempio. Il loro codice potrebbe essere obsoleto,
6:26
Speaker 2: difficile da supportare o troppo legato al vecchio ambiente. In
6:28
Speaker 2: altri casi, ha più senso sostituire l'applicazione con un servizio
6:31
Speaker 2: online o tenerla al di fuori di Azure per ora.
6:33
Speaker 2: Mantenere qualcosa dov'è può essere la scelta giusta. L'adozione del
6:36
Speaker 2: cloud non significa spostare messi in volacola. Ma è qui
6:39
Speaker 2: che i team spesso fanno una cattiva prima scelta. Iniziano
6:41
Speaker 2: con l'applicazione più vecchia e meno compresa perché sembra urgente.
6:44
Speaker 2: Quell'applicazione potrebbe essere fragile, scarsamente documentata e connessa a più
6:47
Speaker 2: sistemi di quanti chiunque immagini. Ciò può trasformare il primo
6:50
Speaker 2: spostamento in un lungo lavoro di recupero. Un primo carico
6:53
Speaker 2: di lavoro migliore è abbastanza importante da insegnarti qualcosa, ma
6:55
Speaker 2: abbastanza semplice da far sì che le persone comprendano il
6:57
Speaker 2: suo proprietario e sui dati come pare successo. Quel primo
7:00
Speaker 2: spostamento offre al team la possibilità di imparare senza mettere
7:02
Speaker 2: a rischio l'interattività. Immagina un'azienda il cui supporto hardware per
7:05
Speaker 2: server termina tra 3.000. Suo primo obiettivo non è riprogettare
7:08
Speaker 2: ogni vecchia applicazione. Non c'è tempo. Postare alcuni server su
7:11
Speaker 2: Azure con modifiche limitate potrebbe essere una mossa sensata perché
7:14
Speaker 2: elimina il rischio arduo e rimediato. Quindi l'azienda può creare
7:17
Speaker 2: un piano più lungo per migliorare o sostituire quell'applicazione in
7:19
Speaker 2: un secondo momento. Non si trassi di me. Si tratta
7:22
Speaker 2: di scegliere il lavoro giusto per il tempo a disposizione.
7:24
Speaker 2: La pianificazione richiede anche le persone giuste nella stessa. I
7:26
Speaker 2: responsabili aziendali spiegano cosa conta. I proprietari delle applicazioni spiegano
7:29
Speaker 2: come funziona solo. I team di sicurezza definiscono l'accesso sicuro.
7:32
Speaker 2: I team di rete pianificano le soluzioni. Il reparto finanziario
7:34
Speaker 2: tiene tempo. Il team cloud crea e supporta il lato Azure.
7:38
Speaker 2: Nessun team può rispondere a ogni domanda da solo. Quindi
7:41
Speaker 2: la strategia ti dice perché l'ufficio deve cambiare e la
7:42
Speaker 2: pianificazione ti dice chi si sta trasferendo, di cosa ha
7:44
Speaker 2: bisogno e quando può succedere. La fase successiva del CAF
7:47
Speaker 2: prepara l'edificio in base a queste esigenze prima dell'arrivo del
7:49
Speaker 2: primo reparto. Pronta. Crea la landing zone prima dell'arrivo degli inquinti.
7:54
Speaker 2: Con il piano in atto puoi preparare Azure stesso. CAF
7:57
Speaker 2: definisce pronta questa fase. L'idea centrale è la landing zone
8:00
Speaker 2: di Azure. Quel nome può sembrare tecnico, ma il significato
8:03
Speaker 2: è semplice. Una landing zone è una parte preparata di
8:05
Speaker 2: Azure in cui applicazioni e dati possono risiedere in sicurezza
8:09
Speaker 2: Pensala come la preparazione dell'edificio per gli uffici primo reparto.
8:12
Speaker 2: Hai bisogno dell'involucro dell'edificio. Hai bisogno di elettricità, cavi di rete, porte, serrature,
8:16
Speaker 2: uscite di sicurezza e un posto dove archiviare i documenti.
8:18
Speaker 2: Non inviteresti le persone in un pavimento di cemento vuoto
8:20
Speaker 2: e diresti loro di sistemare da sole il cablaggio. Una
8:22
Speaker 2: landing zone fornisce ai tuoi carichi di lavoro quella base preparata.
8:25
Speaker 2: Ciò non significa che ogni ambiente azzurra abbia lo stesso aspetto.
8:27
Speaker 2: Una piccola azienda potrebbe aver bisogno di una configurazione semplice
8:29
Speaker 2: con poche regole chiave. Una grande azienda potrebbe aver bisogno
8:32
Speaker 2: di molte aree separate per team, aree e sistemi sensibili.
8:35
Speaker 2: Il punto è creare le parti necessarie prima che arrivino
8:37
Speaker 2: le applicazioni. Inizia dalla reception. Nei servizi cloud Microsoft, Microsoft
8:41
Speaker 2: Entry ID funziona come quella reception. Gestisce le identità digitali,
8:44
Speaker 2: che significa che sa chi sta tentando di accedere e
8:47
Speaker 2: può aiutare a decidere a cosa può accedere. Una persona
8:50
Speaker 2: potrebbe aver bisogno di accedere a un'applicazione manuale. Un servizio
8:52
Speaker 2: potrebbe aver bisogno dell'autorizzazione per leggere da un database, ma
8:55
Speaker 2: in un database non dovrebbe mai avere un autore. Entry
8:57
Speaker 2: ID aiuta a gestire queste decisioni. La regola generale è semplice.
9:00
Speaker 2: Concedere alle persone solo l'accesso di cui hanno bisogno per svolgerlo.
9:03
Speaker 2: Ciò riduce al minimo gli errori e rende più difficili
9:05
Speaker 2: gli accessi indesiderati. Successivamente viene a disposizione dei differenti. Aggiura
9:08
Speaker 2: alcuni livelli per organizzare il lavoro. I gruppi di gestione
9:11
Speaker 2: si trovano a parte sua. Puoi considerarli come la struttura
9:13
Speaker 2: di proprietà più ampia, in cui le regole condivise possono
9:15
Speaker 2: essere applicate a più di un'area. Le sottoscrizioni si trovano
9:17
Speaker 2: di sotto. Una sottoscrizione è spesso uno spazio separato per fatturazione,
9:20
Speaker 2: accesso e carichi di lavoro. Una potrebbe supportare un'applicazione di produzione.
9:23
Speaker 2: Un'altra potrebbe supportare i test. Una sottoscrizione condivisa potrebbe eseguire
9:26
Speaker 2: servizi utilizzati da modi. All'interno delle sottoscrizioni, i gruppi di
9:29
Speaker 2: risorse ti aiutano ad accogliere elementi di Azure correlati. Il
9:32
Speaker 2: server web, il database e le archiviazioni di un'applicazione potrebbero
9:34
Speaker 2: trovarsi in un gruppo di risorse perché appartengono allo stesso
9:36
Speaker 2: car Le regole di denominazione di tag aiutano le persone
9:39
Speaker 2: a trovare le cose in un secondo luogo. Un nome
9:41
Speaker 2: ti dice di cosa si tratta. Un tag è più
9:43
Speaker 2: simile a un'etichetta che gli alleghi, come il proprietario del reparto,
9:46
Speaker 2: l'ambiente o un codice di costo. Se il reparto finanziario
9:49
Speaker 2: deve chiedere quale team ha causato l'addebito, le etichette rendono
9:51
Speaker 2: questa domanda molto più semplice da rispondere. Ma non trasformare
9:53
Speaker 2: nomi ed etichette in un gigantesco puzzle. Le persone hanno
9:56
Speaker 2: bisogno di regole che possano seguire senza aprire un documento
9:58
Speaker 2: di 20 vagi. Chiarezza e coerenza bastano. l'intelligenza. L'edificio ha
10:01
Speaker 2: anche bisogno di strade, porte e muli. In Azure questo
10:03
Speaker 2: è il networking. Controlla il modo in cui i sistemi
10:06
Speaker 2: si connettono tra loro, a internet e talvolta di nuovo
10:09
Speaker 2: ai sistemi che sono ancora in esecuzione nel tuo edificio
10:11
Speaker 2: o nel tuo data center. Alcune applicazioni hanno bisogno di
10:13
Speaker 2: un percorso privato verso un database. Altre devono accettare il
10:15
Speaker 2: traffico dai clienti su internet. Alcuni sistemi non dovrebbero mai
10:19
Speaker 2: comunicare tra loro. Questa separazione è importante. Non lasceresti tutte
10:23
Speaker 2: le porte degli uffici aperte solo perché le persone lavorano
10:25
Speaker 2: nello stesso edificio. Allo stesso modo, una buona progettazione di
10:27
Speaker 2: rete consente le connessioni di cui un carico di lavoro
10:29
Speaker 2: a bisogno inblocca quelle che non lo richiedono. Poi ci
10:31
Speaker 2: sono servizi che molti reparti condividono. L'identità è una, le
10:34
Speaker 2: connessioni di rete sono un'altra. Anche gli strumenti di monitoraggio
10:37
Speaker 2: backup e sicurezza possono essere inseriti in questa rete piattaforma condivisa.
10:40
Speaker 2: Invece di lasciare che ogni team applicativo crei la propria
10:42
Speaker 2: versione di tali elementi di base, l'organizzazione può fornirli una
10:45
Speaker 2: volta e lasciare che i carichi di lavoro li utilizzino
10:47
Speaker 2: Questa è spesso definita zona di destinazione della piattaforma. Una
10:49
Speaker 2: zona di destinazione dell'applicazione è diversa. Si tratta del singolo
10:51
Speaker 2: spazio ufficio in cui lavora un'applicazione o un team. Segue
10:54
Speaker 2: le regole di creazione più ampie, ma ha spazio per
10:56
Speaker 2: le esigenze di quel carico di lavoro. Ad esempio, il
10:58
Speaker 2: sito web di un cliente potrebbe aver bisogno di servizi
11:00
Speaker 2: diversi da un sistema finanziario interno. Possono avere zone di
11:03
Speaker 2: destinazione dell'applicazione separate, pur utilizzando le stesse regole di accesso,
11:06
Speaker 2: l'approccio di rete, il monitoraggio e il controllo di sicurezza.
11:08
Speaker 2: Ciò offre ai team spazio per lavorare senza trasformare Azure
11:11
Speaker 2: in un luogo aperto a tutti. Agiopoli si aiuta in questo.
11:13
Speaker 2: I criteri agiscono come regole di creazione che impediscono scelte
11:16
Speaker 2: non sicure. Potresti richiedere determinate etichette, in modo che i
11:18
Speaker 2: costi abbiano proprietà. Potresti bloccare l'archiviazione che consente l'accesso pubblico
11:21
Speaker 2: quando i dati dovrebbero rimanere privati. Potresti limitare le distribuzioni
11:25
Speaker 2: alle aree approvate. L'obiettivo non è impedire alle persone di lavorare.
11:28
Speaker 2: L'obiettivo è impedire gli errori comuni prima che diventino costosi
11:30
Speaker 2: e rischiosi. Ma è qui che molti principianti si bloccano.
11:33
Speaker 2: Vedono un enorme diagramma Microsoft pieno di caselle e decidono
11:36
Speaker 2: di aver bisogno di ogni casella fin dal primo giorno.
11:38
Speaker 2: Tu no. Un piccolo team non ha bisogno di costruire
11:42
Speaker 2: una torre aziendale solo perché esiste il progetto. Costruisci le
11:44
Speaker 2: fondamenta di cui la tua organizzazione ha bisogno ora, quindi
11:46
Speaker 2: aggiungile quando un carico di lavoro reale ti fornisce una motivazione.
11:49
Speaker 2: Il tuo primo carico di lavoro ti dice qualcosa che
11:50
Speaker 2: un diagramma non può mai dire. Una zona di destinazione
11:52
Speaker 2: può sembrare completa sulla carta, con criteri, reiti, regoli d'accesso
11:55
Speaker 2: e monitoraggio, tutti disegnati in modo ordinato. Poi arriva un'applicazione
11:58
Speaker 2: a bisogno di una connessione che nessuno aveva pianificato, un'autorizzazione
12:00
Speaker 2: che nessuno si aspettava, un'impostazione di backup che non si adatta.
12:03
Speaker 2: Questa non è la prova che la zona di destinazione
12:04
Speaker 2: non riusci. È il modo in cui l'edificio diventa migliore. Adotta.
12:08
Speaker 2: Sposta i carichi di lavoro. Impara, quindi migliora. Ora le
12:10
Speaker 2: persone possono iniziare a utilizzare lo spazio. CAF chiama questa
12:13
Speaker 2: operazione ad azione e copre due attività correlate. Sostare i
12:17
Speaker 2: carichi di lavoro esistenti in azione e modificare i carichi
12:19
Speaker 2: di lavoro in modo che funzionino meglio lì. Un carico
12:21
Speaker 2: di lavoro è semplicemente un'attività eseguita sulla tecnologia. Potrebbe essere
12:24
Speaker 2: un sito web, un'app aziendale, un database o un gruppo
12:26
Speaker 2: di servizi che funzionano insieme. Immagina un reparto che arriva
12:29
Speaker 2: il giorno del trasloco. La stanza è pronta, ma il
12:31
Speaker 2: trasloco richiede ancora attenzione. Il personale verifica i propri badge
12:34
Speaker 2: di accesso. Controlla che i telefoni funzionino. Si assicura di
12:36
Speaker 2: poter raggiungere i file di cui ha bisogno. Trova le
12:38
Speaker 2: uscite d'emergenza prima che si verifichi una vera emergenza. Spostamento
12:41
Speaker 2: di un'applicazione su Azure segue la stessa idea di base.
12:44
Speaker 2: Verifichi che l'applicazione funzioni, che possa raggiungere i sistemi da
12:47
Speaker 2: cui dipende e che le persone giuste possano supportarla. Inizia
12:50
Speaker 2: con un carico di lavoro che ti fornisca un test tech.
12:52
Speaker 2: Dovrebbe essere importante per l'azienda, ma non dovrebbe essere un
12:54
Speaker 2: mistero tenuto insieme da vecchio codice e un manuale mancante. Spostalo, testalo,
12:57
Speaker 2: scopri dove è necessario lavorare sulla configurazione e quindi usa
12:59
Speaker 2: quelle lezioni sul carico di lavoro successivo. Ecco come CAF
13:02
Speaker 2: evita che lo stesso errore si ripeta 50 volte. Ci
13:04
Speaker 2: sono alcuni percorsi che un'applicazione può intraprendere. Percorso più rapido
13:07
Speaker 2: è il re- hosting. Potresti anche sentire persone che chiamano questo
13:09
Speaker 2: processo lift in CPU. L'applicazione rimane per lo più la
13:11
Speaker 2: stessa ma viene eseguita su una macchina virtuale in Azure
13:13
Speaker 2: anziché su un server di tuo proprio. Ciò può avere
13:15
Speaker 2: senso quando devi abbandonare rapidamente il vecchio hardware. Il percorso
13:18
Speaker 2: successivo è la ripiatta fuori. L'applicazione svolge ancora lo stesso
13:21
Speaker 2: lavoro ma ne sposti una parte in un servizio Azure gestito.
13:24
Speaker 2: Ad esempio anziché eseguire il tuo server di database potresti
13:26
Speaker 2: utilizzare un servizio di database Azure eseguito e gestito da Microsoft.
13:29
Speaker 2: Quindi c'è refactoring e ricostruzione. Il refactoring significa modificare parti
13:33
Speaker 2: dell'applicazione in modo che possa utilizzare meglio i servizi cloud.
13:35
Speaker 2: La ricostruzione significa creare una nuova versione, perché quella precedente
13:38
Speaker 2: non soddisfa più le esigenze aziendali, a costi di manutenzione eccessive,
13:40
Speaker 2: non può essere attenzione eccessiva, non può essere trasferita in
13:42
Speaker 2: sicurezza così com'è. Non tutti i carichi di lavoro devono
13:44
Speaker 2: essere trasferiti su azienda. Un'applicazione potrebbe rimanere dov'è per una
13:46
Speaker 2: buona ragione. Oppure l'organizzazione potrebbe sostituirla con un servizio software online,
13:50
Speaker 2: invece di eseguire l'applicazione stessa. La risposta giusta dipende da
13:54
Speaker 2: cosa fa il carico di lavoro, da quante modifiche necessite
13:56
Speaker 2: e da quale rischio l'azienda può accettare. Prima che qualsiasi
13:58
Speaker 2: cosa diventi un carico di lavoro di produzione, testa più
14:00
Speaker 2: della schermata di accesso. L'applicazione svolge il suo normale lavoro.
14:04
Speaker 2: Può comunicare con il database e altri sistemi connessi. Funziona
14:06
Speaker 2: bene quando viene utilizzato da persone reali. È possibile ripristinare
14:09
Speaker 2: i dati se qualcosa non va. Le persone giuste hanno
14:11
Speaker 2: accesso mentre tutti gli altri ne sono esclusi. E si
14:13
Speaker 2: capisce quanto costa quando funziona normalmente. Una distribuzione di successo
14:17
Speaker 2: non è solo un'applicazione che si apre una volta. È
14:19
Speaker 2: un'applicazione che può essere eseguita, ripristinata ed essere supportata. Anche
14:23
Speaker 2: questo richiede il coinvolgimento di due gruppi. Il team dell'applicazione
14:25
Speaker 2: sa di cosa bisogna l'applicazione e in che modo gli
14:27
Speaker 2: utenti vi fanno affidamento. Il team della piattaforma sa come
14:29
Speaker 2: è configurato Azure e quali regole condivise si applicano. Nessuno
14:32
Speaker 2: dei due team può risolvere ogni problema da solo, ma
14:34
Speaker 2: molte organizzazioni cadono in una trappola familiare. Il team della
14:37
Speaker 2: piattaforma completa la landing zone, fornisce l'accesso al team dell'applicazione
14:40
Speaker 2: e passa all'attività successiva. Quindi il team dell'applicazione riscontra un
14:43
Speaker 2: problema con i criteri, le regole dirette o le autorizzazioni,
14:45
Speaker 2: inizia a cercare soluzioni per aggirare la piattaforma. Ciò crea
14:49
Speaker 2: frustrazione da entrambe le parti. Un approccio migliore è quello
14:51
Speaker 2: di trattare le prime mosse come lavoro condiviso. Quando un'applicazione
14:55
Speaker 2: necessita di una modifica ragionevole, i team decidono se tale
14:57
Speaker 2: modifica debba essere inserita nella configurazione dell'applicazione o dell'applicazione. Documentano
15:01
Speaker 2: la risposta, quindi semplificano la mossa successiva. Ogni carico di
15:03
Speaker 2: lavoro ti insegna qualcosa. Forse il processo di backup necessita
15:06
Speaker 2: di un proprietario più chiaro. Forse un'applicazione necessita di un
15:08
Speaker 2: percorso di rete di cui avranno bisogno anche altri carichi
15:10
Speaker 2: di rete. Forse una policy blocca una distribuzione sicura e
15:12
Speaker 2: necessita di modifiche. Non aspetti di avere un progetto perfetto
15:15
Speaker 2: prima di imparare queste cose. Impari muovendoti con attenzione, migliorando
15:18
Speaker 2: la configurazione e utilizzando di nuovo quei miglioramenti. Tuttavia, una
15:22
Speaker 2: volta che i reparti lavorano all'interno dell'edificio, qualcuno deve vigilare
15:24
Speaker 2: sulle regole, sulla sicurezza e sulla manutenzione quotidiana. Gestisci, proteggesi.
15:28
Speaker 2: Mantieni l'ufficio sicuro e funzionale. Gestire, proteggere e gestire non
15:32
Speaker 2: sono attività che tralasci fino alla fine del progetto di migrazione.
15:34
Speaker 2: Sono attività che attraversano l'intero percorso nel cloud perché le
15:37
Speaker 2: decisioni su accesso, spese, sicurezza e supporto influenzano ogni carico
15:39
Speaker 2: di lavoro fin dall'inizio. La governance stabilisce le regole per
15:42
Speaker 2: l'utilizzo di Azure. Ciò può includere quali team di servizi
15:44
Speaker 2: Azure possono utilizzare, in quali regioni possono eseguire la distribuzione,
15:47
Speaker 2: come vengono denominate le risorse, come vengono denominate le risorse,
15:49
Speaker 2: quali etichette devono avere, chi è il proprietario di lavoro
15:51
Speaker 2: e come vengono monitorate le spese. Pensa alla governance come
15:53
Speaker 2: alle regole che tutti accettano di seguire durante l'utilizzo dell'ufficio.
15:56
Speaker 2: Un reparto potrebbe dover stabilire chi è il proprietario di
15:58
Speaker 2: una stanza. Potrebbe essere necessaria l'approvazione prima di installare l'apparecchiatore costante.
16:01
Speaker 2: Potrebbe essere necessario seguire regole su dove archiviare i dati sensibili.
16:04
Speaker 2: Tali regole sono presenti affinché l'ufficio rimanga comprensibile man mano
16:07
Speaker 2: che si trasferiscono più persone. In Azure la governance aiuta
16:09
Speaker 2: anche con Se la tua organizzazione deve seguire regole per
16:12
Speaker 2: i dati dei clienti, i dati finanziari o le informazioni sanitarie,
16:15
Speaker 2: devi sapere dove si trovano tali dati, chi può accedervi
16:18
Speaker 2: e se sono stati implementati i controlli richiesti. La sicurezza
16:21
Speaker 2: si concentra sulla protezione di persone, sistemi e dati all'interno
16:24
Speaker 2: di tale ambiente. L'edimissione consente di controllare gli accessi e
16:27
Speaker 2: le autorizzazioni. L'accesso condizionale può verificare la situazione relativa a
16:30
Speaker 2: un accesso, ad esempio se la persona sta utilizzando un
16:33
Speaker 2: dispositivo approvato o necessita di un controllo di accesso aggiuntivo.
16:36
Speaker 2: Gli strumenti di Microsoft Defender possono aiutare a individuare minacce
16:38
Speaker 2: e attività sospette sulla piattaforma. L'idea alla base di tutto
16:41
Speaker 2: ciò è il privilegio minimo. Le persone ricevono l'accesso di
16:44
Speaker 2: cui hanno bisogno per il loro lavoro, non un accesso
16:45
Speaker 2: ampio solo perché sembra più semplice. Un'applicazione riceve solo le
16:48
Speaker 2: autorizzazioni di cui ha bisogno. All'inizio potrebbe sembrare più lento,
16:52
Speaker 2: ma l'accesso ampio crea un problema molto più grande. Quando
16:54
Speaker 2: un account viene compromesso, una persona commette un errore, un
16:57
Speaker 2: appaltatore e non lavora più con l'azienda. La gestione è
17:00
Speaker 2: il lavoro quotidiano che consente ad azori di funzionare. Qualcuno
17:02
Speaker 2: deve controllare gli avvisi di monitoraggio. Qualcuno deve controllare i
17:05
Speaker 2: backup e dimostrare che i dati possono essere ripristinati. Qualcuno
17:07
Speaker 2: deve installare aggiornamenti, rispondere agli incidenti, esaminare i costi e
17:10
Speaker 2: decidere cosa fare quando un servizio smette di funzionare alle
17:13
Speaker 2: due del mattino. Questi lavori vengono svolti dietro le quinte,
17:15
Speaker 2: ma gli utenti se ne accorgono subito quando nessuno ne
17:17
Speaker 2: è propito. Esiste anche un modello di responsabilità con il
17:20
Speaker 2: design dei servizi cloud. Microsoft gestisce e protegge i cloud
17:23
Speaker 2: source sottostanti. Microsoft si occupa dei data center fisici e
17:26
Speaker 2: dei servizi cloud principali. La tua organizzazione è ancora responsabile
17:30
Speaker 2: di ciò che inserisce in AdSource, di come configura i servizi,
17:32
Speaker 2: di chi può accedere, di come vengono protetti i dati,
17:34
Speaker 2: di come vengono gestiti i carichi di lavoro. Il passaggio
17:37
Speaker 2: ad azzurro non elimina tali responsabilità. Cambia il modo in
17:40
Speaker 2: cui le gestisci, quindi scrivi la responsabilità in termini chiari.
17:42
Speaker 2: Chi riceve un avviso quando un database non funziona? Si
17:45
Speaker 2: può ripristinare un backup? Chi approva l'accesso per un nuovo dipendente?
17:48
Speaker 2: Chi risponde quando Defender segna non è migliore? Chi verifica
17:50
Speaker 2: se un carico di lavoro sta spendendo più del previsto?
17:52
Speaker 2: Se la risposta è qualcuno nell'IT non è ancora una risposta,
17:55
Speaker 2: un errore comune all'inizio sembra il no. Un team attiva
17:58
Speaker 2: il monitoraggio, vengono visualizzate le dashboard e iniziano ad arrivare
18:01
Speaker 2: gli avvisi. Tutti si sentono più sicuri perché esiste un
18:03
Speaker 2: sistema di avviso. Poi di notte scatta un avviso. Nessuno
18:07
Speaker 2: lo riceve, oppure lo ricevono più persone e presumono che
18:09
Speaker 2: qualcun altro interverrà. L'avviso diventa rumore di sottofondo. Un piccolo
18:12
Speaker 2: problema si aggrava perché il sistema ha segnalato il problema,
18:14
Speaker 2: ma nessuno è responsabile della risposta. Il monitoraggio senza responsabile
18:17
Speaker 2: è solo rumore di fuoco. Anche le regole devono essere bilanciate.
18:20
Speaker 2: Troppe poche regole possono esporre i dati privati, con spese
18:22
Speaker 2: incontrollate e risorse impossibili da tracciare. Troppe regole possono spingere
18:26
Speaker 2: i team a trovare modi per aggirare il percorso ufficiale
18:27
Speaker 2: perché non riescono a svolgere il proprio lavoro. Una buona
18:29
Speaker 2: governance offre alle persone un percorso chiaro a seguire. Non
18:32
Speaker 2: trasforma ogni richiesta in una lunga discussione. CAF ti aiuta
18:36
Speaker 2: a riesaminare queste scelte man mano che l'organizzazione cambia. Una
18:38
Speaker 2: nuova applicazione, un'altra regione, una nuova esigenza di conformità o
18:41
Speaker 2: un diverso modo di lavorare potrebbero richiedere aggiornamenti alle regole
18:44
Speaker 2: e al modello di supporto. Il framework non termina quando
18:46
Speaker 2: l'ultimo carico di lavoro si sposta. Rimane utile perché l'ufficio
18:48
Speaker 2: continua a cambiare?