Sebbene le soluzioni PaaS (Platform as a Service) da sole non possano cambiare il modo in cui individui e team interagiscono, spesso fungono da catalizzatore per il cambiamento organizzativo in risposta alla maggiore agilità dell’IT.
Infatti, il massimo ritorno sugli investimenti PaaS spesso può essere ottenuto solo modificando ruoli, responsabilità (attività) e relazioni organizzative. Fortunatamente, le soluzioni PaaS come OpenShift Container Platform sono sufficientemente flessibili da consentire a ciascuna organizzazione IT di determinare la velocità e la portata del cambiamento rispetto alle persone coinvolte e ai processi che si verificano.
Nella prima fase della containerizzazione aziendale, la priorità principale è l’implementazione della piattaforma container come nuovo sistema di distribuzione delle applicazioni. A questo punto, le organizzazioni collegano lavori familiari a ruoli familiari per rispondere alle richieste standard dei team di sviluppo su questioni quali sistemi di storage, ambienti di distribuzione e così via. Nelle fasi successive della containerizzazione, si parla già di automazione o di fornitura di funzionalità self-service agli sviluppatori al fine di ridurre il carico sugli amministratori di sistema e portare l’autonomia e l’efficienza degli sviluppatori a un livello superiore. È così che un'organizzazione inizia a muoversi verso DevOps. Nella fase finale della containerizzazione, l’impresa arriva a un modello DevOps più puro e canonico, all’interno del quale molti dei compiti e del lavoro precedenti sono sotto il controllo di team interfunzionali raggruppati non per piattaforme o tecnologie, ma dal punto di vista al fine di garantire il funzionamento delle applicazioni o dei servizi applicativi.
In questo post forniremo indicazioni su come apportare le modifiche organizzative necessarie e su come stanno cambiando i ruoli IT tradizionali con l'adozione delle tecnologie container nell'azienda.
Collegare nuovi lavori a vecchi ruoli
Nella sua forma iniziale di base, il modello organizzativo PaaS è progettato per allocare in modo più flessibile e rapido le risorse IT alle applicazioni come ambiente di runtime. Sebbene ciò offra alcuni vantaggi agli amministratori di sistema, gli sviluppatori in genere non ottengono benefici significativi o nuove funzionalità, poiché in questa fase un'azienda può facilmente fare a meno dell'automazione, del self-service o di un radicale miglioramento della pipeline di distribuzione. Pur avendo un impatto minimo sui processi di sviluppo in questa fase, il PaaS aumenta comunque l'agilità del sistema IT, consentendo agli amministratori di soddisfare al meglio le richieste degli sviluppatori. Ad esempio, mentre in precedenza si creava un ambiente di sviluppo da diverse macchine virtuali Mentre la creazione e l'implementazione di volumi di storage potevano richiedere giorni o addirittura settimane, richiedendo il coinvolgimento di diversi amministratori, nel PaaS tutto viene svolto molto più rapidamente e da un solo amministratore. In altre parole, i team di sviluppo inviano le richieste come prima, ma il lavoro per implementarle viene ora svolto secondo un nuovo modello.
Verso un'organizzazione DevOps
Lanciando PaaS e migrando verso di esso gli specialisti delle operazioni IT e gli sviluppatori di applicazioni, l'organizzazione può continuare a implementare la metodologia DevOps, che, tra gli altri, include i seguenti principi di base:
- Suddividere il lavoro in piccoli passiricevere feedback tempestivi, ridurre i rischi ed evitare la paralisi dell'analisi;
- Automatizzare sufficientemente le operazionievitare di creare ostacoli o colli di bottiglia nel processo di distribuzione delle applicazioni;
- Scambio di conoscenze – la chiave per costruire la fiducia;
- Pagare regolarmente i debiti tecnici, dedicando un certo tempo in ogni ciclo di lavoro per miglioramenti sistematici.
Nella seconda fase di adozione della tecnologia container, i team di sviluppo iniziano naturalmente a vedere opportunità di miglioramento e l’azienda si orienta verso un modello DevOps più tradizionale. Il meccanismo tradizionale di invio e soddisfazione delle richieste di servizio è ora percepito come un collo di bottiglia, quindi l'organizzazione sta cercando di automatizzare le azioni ripetitive e fornire funzionalità self-service agli sviluppatori. Inoltre, queste capacità di sviluppo all'interno di una determinata applicazione sono determinate dagli sforzi congiunti degli specialisti IT che gestiscono le piattaforme e dei responsabili della distribuzione delle applicazioni. In altre parole, gli amministratori di sistema, che eseguono azioni su richiesta degli sviluppatori, vengono sostituiti dalle due categorie di dipendenti sopra menzionate che sono responsabili di descrivere e applicare le politiche che regolano esattamente ciò che gli sviluppatori possono fare da soli. Le procedure automatizzate aiutano a garantire la conformità ai requisiti specificati e a coordinare le azioni quando una situazione non rientra nell'ambito delle politiche esistenti.
Il passaggio a una pianificazione iterativa, in cui l'ambiente IT e il modello operativo subiscono modifiche iterative nel tempo, è una pietra miliare fondamentale per realizzare un'azienda DevOps matura. Il grado di adozione della metodologia DevOps dipende dalla tolleranza al cambiamento di ogni singola organizzazione e da quali cambiamenti apportano i maggiori vantaggi. Ad esempio, se la necessità di creare nuovi ambienti o applicazioni si verifica raramente, l’ottimizzazione delle attività corrispondenti sarà meno importante che aumentare il controllo degli sviluppatori sul ciclo di vita dell’applicazione.
Nuove sfide che si presentano nelle organizzazioni IT durante la migrazione a OpenShift
In questa sezione esamineremo i ruoli e le attività che le organizzazioni che hanno adottato OpenShift in genere utilizzano per accelerare l'automazione e il self-service utilizzando la tecnologia e PaaS.
La tabella seguente elenca le principali attività di livello superiore presenti in qualsiasi organizzazione che ha implementato OpenShift, con esempi di lavori e competenze correlate. Questo elenco di attività non deve essere confuso con una struttura di suddivisione del lavoro o con una struttura di squadra, ma piuttosto con un insieme di attività che devono essere completate dai responsabili del supporto dell'ambiente o degli ambienti IT per la corretta implementazione di una piattaforma contenitore. Infatti, mostreremo ulteriormente che l'introduzione delle tecnologie container crea i prerequisiti per la formazione di una strategia DevOps più matura nell'impresa, che a sua volta aumenta il grado di funzionalità incrociata dei team e riduce i rischi di una ristretta specializzazione a livello aziendale. livello sia dei singoli che dei team.
Tabella 1. Definizioni delle attività OpenShift
compiti
Competenze richieste
Automazione e provisioning delle infrastrutture IT
Società:
- Progettazione e realizzazione di soluzioni hardware
- Organizzazione e supporto dell'automazione del setup iniziale
- Progettazione e automazione della preparazione di VM e host
- Progettazione e realizzazione di data center
- Amministrazione del sistema Linux
- Scenari di automazione
- Conoscenza dei sistemi di accumulo
- Conoscenza della progettazione e implementazione della rete
- sicurezza
Installazione e gestione della piattaforma OpenShift
Società:
- Esecuzione di un'installazione cluster
- Gestione dei servizi infrastrutturali
- Gestione del ridimensionamento della piattaforma
- Autenticazione e autorizzazione a livello di piattaforma
- Amministrazione del sistema Linux
- Conoscenza delle tecnologie di rete
- Script di automazione (Ansible)
- Conoscenza dei sistemi di accumulo
- Conoscenza delle tecnologie e delle architetture dei container
- Conoscenza delle architetture Kubernetes e OpenShift
- Sicurezza della piattaforma
- Monitoraggio dell'integrazione
Gestione della predisposizione degli ambienti cliente (tenant provisioning), isolamento delle capacità IT
Società:
- Creazione di utenti e team all'interno della piattaforma
- Progettazione e gestione delle quote
- Progettazione e implementazione del RBAC
- Conoscenza delle architetture Kubernetes e OpenShift
- Conoscenza delle tecnologie e delle architetture dei container
- Scenari di automazione
- Buona conoscenza di progetti, quote, assegnazioni di ruoli e collaborazione con i pianificatori
Creazione e gestione delle immagini di base
Società:
- Sviluppo di un flusso di lavoro di modifica delle immagini
- Sviluppo di immagini basato su standard
- Amministrazione del sistema Linux
- Scenari di automazione
- Configurazione dei componenti e del middleware dell'applicazione runtime
- Conoscenza delle architetture dei contenitori
- Framework di creazione di applicazioni
- Buona conoscenza di immagini, imagestream e template
Progettare e gestire pipeline di distribuzione
Società:
- Progettazione e documentazione degli standard di trasporto
- Sviluppo di guide rapide e template
- Formazione per sviluppatori
- Gestione del codice sorgente
- Progettazione e implementazione dell'applicazione
- Scenari di automazione
- Test automatizzati
- Test di qualità del codice
- Conoscenza delle architetture dei contenitori
- Conoscenza delle infrastrutture immutabili
- Sicurezza: gestione dell'accesso alle fasi della pipeline, approvazione dei flussi di lavoro, ecc.
- Buona conoscenza dei modelli OpenShift, componenti buildconfig, deployconfig, servizi, percorsi, configmap
Sviluppo di applicazioni e test
Società:
- Codifica dell'applicazione
- Sviluppo di test automatizzati
- Rispondere agli errori dei test durante la pipeline di distribuzione
- Rispondere agli errori delle applicazioni
- Test di accettazione da parte dell'utente
- Progettazione e implementazione dell'applicazione
- Test automatizzati
- Gestione del codice sorgente
- Monitoraggio dell'applicazione
- Conoscenza delle architetture applicative cloud native
Monitoraggio operativo e gestione delle applicazioni
Società:
- Progettare applicazioni nel contesto delle prestazioni
- Monitoraggio delle applicazioni in fase di runtime
- Scalabilità dell'applicazione (o scalabilità automatica)
- Gestione della disponibilità delle applicazioni
- Richiedi quote e limiti di gestione delle risorse
- Test delle prestazioni e della capacità IT
- Progettazione e implementazione delle prestazioni delle applicazioni
- Monitoraggio delle prestazioni dell'applicazione
- Test di prestazioni e carico
Test di accettazione da parte dell'utente
Società:
- Test dell'interfaccia utente (design ed esperienza utente)
- Sviluppo di test automatizzati
- Progettare e testare le interfacce utente
- Modelli di test automatizzati
- Framework di test
- Modelli di progettazione dell'applicazione
Nuovi ruoli che emergono in un'organizzazione IT durante la migrazione a OpenShift
Quando si passa a un modello organizzativo incentrato su DevOps, la quantità di specializzazione dei ruoli tende a diminuire e il numero di team e ruoli interfunzionali a sua volta aumenta per massimizzare l'efficienza della collaborazione. Ecco come pensiamo che appaia l'elenco delle posizioni chiave in un'organizzazione IT che utilizza OpenShift:
- Ingegnere delle operazioni applicative O Ingegnere dell'affidabilità del sito. In precedenza, questa posizione poteva essere chiamata "Amministratore del server delle applicazioni".
- Sviluppatore di applicazioni/Sviluppatore di software/Ingegnere di software.
- Amministratore di cluster/piattaforma applicativa. In precedenza, questo ruolo poteva essere chiamato "Amministratore di sistema" o "Amministratore". Linux-piattaforme".
- Responsabile del rilascio/Ingegnere di costruzione.
Matrice dei ruoli e dei compiti RACI
Infine, passiamo a confrontare le posizioni e i compiti sopra discussi per dare un'idea generale di come dovrebbe essere la struttura di un'organizzazione che implementa DevOps sulla piattaforma OpenShift. Inizialmente, i seguenti ruoli possono essere ricoperti da diversi rami della vecchia struttura organizzativa tradizionale. Col passare del tempo, però, si verifica un consolidamento e vengono creati nuovi team attorno ad applicazioni che svolgono la maggior parte o addirittura tutte le attività elencate di seguito.
compiti
ruolo
Ingegnere delle operazioni applicative/Ingegnere dell'affidabilità del sito
Sviluppatore di applicazioni/Sviluppatore di software/Ingegnere di software
Amministratore della piattaforma cluster/applicativa
Responsabile della versione software/Ingegnere di assemblaggio
Automazione e provisioning delle infrastrutture IT
I
I
RA
C
Installazione e gestione della piattaforma OpenShift
C
I
RA
C
Progettare e gestire pipeline di distribuzione
C
C
I
RA
Gestisci il provisioning, l'isolamento e la capacità IT dei tenant
C
I
RA
I
Creazione e gestione delle immagini di base
R
C
RA
C
Sviluppo di applicazioni e test
C
RA
I
I
Monitoraggio operativo e gestione delle applicazioni
RA
C
C
I
Test di accettazione da parte dell'utente
C
R
I
I
Convenzioni nella matrice RACI
Fonte:
- Responsabile – L’esecutore è colui che fa ciò che è necessario per portare a termine l’attività.
- Responsabile – Responsabile – un dipendente che è in ultima analisi responsabile della corretta e completa esecuzione di un compito o del raggiungimento di un risultato; e anche l'unico che può delegare il lavoro agli artisti.
- consultato – Consulenti: in genere si tratta di esperti in materia di cui si richiede la consulenza; Con loro viene mantenuta una comunicazione bidirezionale.
- Informato – Informati – persone che vengono tenute informate sugli eventi (e talvolta solo al termine di un compito o al raggiungimento di un risultato); ricevono informazioni unilateralmente.
Come i team lavorano insieme in un'organizzazione DevOps
L'acquisizione tradizionale delle risorse comporta in genere un ciclo di richieste di risorse che vengono poi eseguite da più team. Alla fine, tutte le risorse necessarie vengono assegnate e confermate dal richiedente. Spesso questi processi sono parzialmente o interamente manuali e richiedono frequenti e molteplici interazioni tra i team per elaborare con successo ogni richiesta.
Figura 1. Organizzazione IT tradizionale
Il diagramma sopra illustra le tipiche relazioni tra i team in un'organizzazione IT tradizionale. In questo schema, alcuni team contattano altri team con la richiesta di svolgere il lavoro necessario, utilizzando mezzi di comunicazione più o meno formali, come un sistema di ticket o e-mail. Queste richieste poi si mettono in coda e restano dietro le quinte, con lunghe attese che spesso portano al peggioramento, o addirittura all’esacerbazione, dei rapporti tra i team. Ad aumentare la tensione c’è il fatto che i membri di team diversi raramente si incontrano di persona e tendono a condividere solo le informazioni minime necessarie.
Figura 2: Organizzazione IT DevOps
Questo diagramma mostra come funziona la collaborazione in un'organizzazione DevOps. Qui gli stessi team del diagramma precedente hanno abbandonato le comunicazioni inefficaci che rinforzavano i silos e li hanno sostituiti con contatti personali, creando così canali costanti di interazione tra i team. Questi canali promuovono un insieme di competenze ibride che aiutano i dipendenti a comprendere e immaginare meglio le esigenze, le sfide e le opportunità dei team che rappresentano. I team si danno la possibilità reciproca di completare il lavoro attraverso portali self-service automatizzati, invece di gestire manualmente le richieste di modifica di altre persone come avveniva in passato. E grazie alla presenza di canali di interazione, questi sistemi self-service possono adattarsi rapidamente alle esigenze dei team per cui sono pensati. Per ottenere una comprensione e una condivisione delle conoscenze ancora maggiori all'interno dell'organizzazione, i membri del team ruotano periodicamente i ruoli per acquisire esperienza interagendo con team diversi e comprendere meglio il quadro generale dei sistemi IT che supportano, aumentando così il loro livello di funzionalità incrociata e utilità.
Riassumendo
In questo post abbiamo discusso di come l'adozione di soluzioni PaaS possa spostare un'organizzazione verso DevOps, modificando ruoli e attività tradizionali come parte del processo. Ecco perché abbiamo elencato le principali sfide IT che un'organizzazione deve affrontare durante la migrazione a OpenShift, nonché le competenze necessarie per completarle. Abbiamo inoltre fornito un insieme fondamentale di ruoli organizzativi che emergono durante la creazione di team DevOps interfunzionali e una matrice RACI che collega nuovi ruoli a nuove attività. Infine, abbiamo discusso di come la piattaforma OpenShift e la metodologia DevOps ad essa associata possono cambiare la struttura organizzativa delle organizzazioni mentre passano da gerarchie e sistemi di ticket tradizionali a team interfunzionali con un livello più elevato di comunicazione personale.
Fonte: habr.com
