Sebbene le soluzioni PaaS (Platform as a Service) da sole non possano cambiare i modi di interazione individuale e di squadra, spesso fungono da catalizzatori per cambiamenti organizzativi in risposta alla maggiore flessibilità delle tecnologie IT.
In effetti, il massimo ritorno sugli investimenti in PaaS è spesso possibile solo mediante un cambiamento dei ruoli organizzativi, delle aree di responsabilità e dei modelli di relazioni. Fortunatamente, soluzioni PaaS come OpenShift Container Platform offrono la flessibilità necessaria affinché ogni organizzazione IT possa determinare autonomamente la velocità e l'entità dei cambiamenti riguardanti le persone coinvolte e i processi in atto.
Nella prima fase della containerizzazione, la priorità principale è l'implementazione di una piattaforma di container come nuovo sistema di distribuzione delle applicazioni. In questo momento, le organizzazioni allineano il lavoro abituale ai ruoli consueti per rispondere alle richieste standard dei team di sviluppo, riguardanti ad esempio sistemi di storage, ambienti di distribuzione, e così via. Nelle fasi successive, l'accento è posto sull'automazione o sulla fornitura di possibilità di self-service per gli sviluppatori, al fine di ridurre il carico sui sistemisti e aumentare l'autonomia e la reattività degli sviluppatori a un livello superiore. È così che l'organizzazione inizia a muoversi verso DevOps. Nella fase finale della containerizzazione, l'azienda si avvicina a un modello DevOps più puro e canonico, in cui molte delle precedenti attività e compiti passano sotto il controllo di team multifunzionali, che si raggruppano non in base a piattaforme o tecnologie, ma in base alla garanzia del funzionamento delle applicazioni o dei servizi applicativi.
In questo post presenteremo una guida per effettuare le necessarie modifiche organizzative e spiegheremo come i ruoli IT tradizionali cambiano con l'implementazione delle tecnologie containerizzate in azienda.
Collegare i nuovi lavori ai vecchi ruoli
Nella sua forma di base, il modello di organizzazione PaaS è concepito per allocare in modo più flessibile e rapido le risorse IT alle applicazioni come ambiente di esecuzione. E sebbene questo fornisca alcuni vantaggi agli amministratori di sistema, gli sviluppatori qui di solito non ottengono benefici significativi e nuove opportunità, poiché in questa fase l'azienda può tranquillamente procedere senza iniziare ad automatizzare, implementare l'auto-servizio o migliorare radicalmente il processo di distribuzione. Pur toccando minimamente i processi di sviluppo in questa fase, PaaS aumenta comunque la dinamicità del sistema IT, consentendo agli amministratori di servire meglio le richieste degli sviluppatori. Ad esempio, se un tempo la creazione di un ambiente di sviluppo richiedeva diversi di macchine virtuali E la gestione del storage poteva richiedere giorni, se non addirittura settimane, con il coinvolgimento di diversi amministratori, mentre con PaaS tutto avviene molto più rapidamente e con il lavoro di un solo amministratore. In altre parole, i team di sviluppo inviano richieste come prima, ma il lavoro di realizzazione di queste richieste viene eseguito secondo un nuovo schema.
Verso un'organizzazione DevOps
Avviando PaaS e trasferendo i professionisti della gestione dei sistemi IT e gli sviluppatori di applicazioni, l'organizzazione può continuare a implementare la metodologia DevOps, che, tra l'altro, include i seguenti principi chiave:
- Dividere il lavoro in fasi più piccole, per ottenere feedback nelle fasi iniziali, ridurre i rischi e evitare la "paralisi analitica";
- Automatizzare le operazioni in misura sufficiente, per non creare ostacoli o colli di bottiglia nel processo di distribuzione dell'applicazione;
- La condivisione della conoscenza è la chiave per costruire fiducia;
- Ripagare regolarmente i debiti tecnici, dedicando tempo sistematico a miglioramenti in ogni ciclo di lavoro.
Nella seconda fase dell'implementazione delle tecnologie container, i team di sviluppo iniziano naturalmente a vedere opportunità di miglioramento e l'azienda tende verso un modello DevOps più canonico. Il meccanismo tradizionale di richiesta e esecuzione degli interventi di manutenzione è ora percepito come un collo di bottiglia, quindi l'organizzazione cerca di automatizzare le azioni ripetitive e fornire agli sviluppatori strumenti di auto-servizio. Inoltre, queste capacità per gli sviluppatori all'interno di una determinata richiesta sono definite attraverso la collaborazione di specialisti IT nella gestione delle piattaforme e di coloro che sono responsabili della consegna delle applicazioni. In altre parole, agli amministratori di sistema, che eseguivano le richieste degli sviluppatori, subentrano le due categorie di personale sopra menzionate, responsabili della definizione e dell'applicazione delle politiche che stabiliscono cosa gli sviluppatori possono fare autonomamente. Le procedure automatizzate aiutano a garantire il rispetto di tali requisiti e a coordinare le azioni nei casi in cui la situazione esca dai confini delle politiche attuali.
La transizione verso una mappa iterativa, in cui l'ambiente IT e il modello operativo subiscono cambiamenti iterativi nel tempo, è una pietra miliare critica per la creazione di un sistema DevOps maturo all'interno dell'azienda. Il grado di adozione della metodologia DevOps dipende dalla tolleranza di ciascuna organizzazione ai cambiamenti e da quali siano i cambiamenti che apportano i maggiori benefici. Ad esempio, se la necessità di creare nuovi ambienti o applicazioni si presenta raramente, l'ottimizzazione delle relative operazioni sarà meno importante rispetto al rafforzamento del controllo degli sviluppatori sul ciclo di vita delle applicazioni.
Nuove sfide che le organizzazioni IT affrontano nella transizione a OpenShift
In questa sezione esamineremo i ruoli e le attività che le organizzazioni passate a OpenShift adottano normalmente per accelerare l'automazione e l'autoservizio utilizzando tecnologie e PaaS.
Nella tabella sottostante sono elencati i principali compiti di alto livello che esistono in qualsiasi organizzazione che ha implementato OpenShift, con esempi di lavori e competenze corrispondenti. Questo elenco di compiti non deve essere confuso con uno schema di divisione del lavoro o con la struttura organizzativa dei team, ma rappresenta semplicemente un insieme di attività che devono essere svolte dalle persone responsabili del supporto dell’ambiente IT, per una riuscita implementazione della piattaforma container. In realtà, mostreremo più avanti come l'implementazione delle tecnologie container crei le premesse per lo sviluppo di una strategia DevOps più matura all'interno dell'azienda, il che a sua volta aumenta il grado di cross-funzionalità dei team e riduce i rischi di specializzazione eccessiva a livello sia dei singoli dipendenti che dei team.
Tabella 1. Definizioni dei compiti di OpenShift
Attività
Competenze richieste
Automazione e provisioning delle infrastrutture IT
Attività:
- Progettazione e costruzione di soluzioni hardware
- Organizzazione e supporto dell'automazione della configurazione iniziale
- Progettazione e automazione della preparazione delle VM e degli host
- Progettazione e implementazione dei data center
- Amministrazione di sistema Linux
- Script di automazione
- Conoscenza dei sistemi di archiviazione
- Competenze nella progettazione e realizzazione di reti
- Sicurezza
Installazione e gestione della piattaforma OpenShift
Attività:
- Esecuzione dell'installazione del cluster
- Gestione dei servizi infrastrutturali
- Gestione della scalabilità della piattaforma
- Autenticazione e autorizzazione a livello di piattaforma
- Amministrazione di sistema Linux
- Conoscenza delle tecnologie di rete
- Script di automazione (Ansible)
- Conoscenza dei sistemi di archiviazione
- Conoscenza delle tecnologie e architetture dei container
- Conoscenza delle architetture Kubernetes e OpenShift
- Sicurezza delle piattaforme
- Integrazione del monitoraggio
Gestione della preparazione degli ambienti client (tenant provisioning), isolamento delle risorse IT
Attività:
- Creazione di utenti e team all'interno della piattaforma
- Progettazione e gestione delle quote
- Progettazione e implementazione di RBAC
- Conoscenza delle architetture Kubernetes e OpenShift
- Conoscenza delle tecnologie e architetture dei container
- Script di automazione
- Buona conoscenza dei progetti, delle quote, dell'assegnazione dei ruoli e dell'utilizzo dei pianificatori
Costruzione e gestione delle immagini di base
Attività:
- Sviluppo del flusso di lavoro per la modifica delle immagini
- Sviluppo delle immagini secondo gli standard
- Amministrazione di sistema Linux
- Script di automazione
- Configurazione dei componenti runtime delle applicazioni e middleware
- Conoscenza delle architetture dei container
- Framework di build delle applicazioni
- Buona conoscenza delle immagini, imagestream e modelli
Progettazione e gestione di pipeline di distribuzione
Attività:
- Progettazione e documentazione degli standard delle pipeline
- Sviluppo di guide rapide e modelli
- Formazione degli sviluppatori
- Gestione del codice sorgente
- Progettazione e implementazione di applicazioni
- Script di automazione
- Test automatizzati
- Verifica della qualità del codice
- Conoscenza delle architetture dei container
- Conoscenza delle infrastrutture immutable
- Sicurezza – gestione dell'accesso alle fasi della pipeline, approvazione dei flussi di lavoro, ecc.
- Buona conoscenza dei modelli OpenShift, dei componenti buildconfigs, deploymentconfigs, services, routes, configmaps
Sviluppo di applicazioni e test
Attività:
- Codifica delle applicazioni
- Sviluppo di test automatizzati
- Reazione ai fallimenti dei test durante la pipeline di distribuzione
- Reazione ai fallimenti delle applicazioni
- Test di accettazione dell'utente
- Progettazione e implementazione di applicazioni
- Test automatizzati
- Gestione del codice sorgente
- Monitoraggio delle applicazioni
- Conoscenza delle architetture di applicazioni cloud native
Monitoraggio operativo e gestione delle applicazioni
Attività:
- Progettazione delle applicazioni in relazione alle prestazioni
- Monitoraggio delle applicazioni in fase di esecuzione
- Scalabilità delle applicazioni (o autoscalabilità)
- Gestione della disponibilità delle applicazioni
- Quote per richieste e limiti nella gestione delle risorse
- Test delle prestazioni e delle capacità IT
- Progettazione e implementazione delle prestazioni delle applicazioni
- Monitoraggio delle prestazioni delle applicazioni
- Test delle prestazioni e stress testing
Test di accettazione dell'utente
Attività:
- Test dell'interfaccia utente (design e interazione con l'utente)
- Sviluppo di test automatizzati
- Progettazione e verifica delle interfacce utente
- Template per test automatizzati
- Framework di test
- Template per la progettazione delle applicazioni
Nuove funzioni che emergono nell'organizzazione IT durante la transizione a OpenShift
Con la transizione a un modello organizzativo orientato al DevOps, di solito si riduce il numero di specializzazioni dei ruoli mentre aumentano i team e i ruoli cross-funzionali per massimizzare l'efficacia della collaborazione. Ecco come riteniamo si presenti l'elenco delle posizioni principali in un'organizzazione IT che utilizza OpenShift:
- Ingegnere delle operazioni delle applicazioni (Application Operations Engineer) OPPURE Ingegnere per l'affidabilità del sito (Site Reliability Engineer). In passato, questa posizione poteva essere chiamata "Amministratore del server delle applicazioni".
- Sviluppatore di applicazioni/sviluppatore software/ingegnere del software.
- Amministratore del cluster/piattaforma applicativa. In precedenza, questo ruolo poteva essere denominato «Amministratore di sistema» o «Amministratore delle piattaforme Linux».
- Responsabile del rilascio software (Release Manager)/Ingegnere di build (Build Engineer).
Matrice dei ruoli e delle responsabilità RACI
Infine, passiamo alla mappatura delle posizioni e dei compiti discussi, per fornire una visione generale di come dovrebbe apparire la struttura organizzativa che implementa DevOps sulla piattaforma OpenShift. I ruoli inizialmente elencati possono essere svolti da rami della vecchia struttura organizzativa tradizionale. Tuttavia, nel tempo, ci sono processi di consolidamento e si formano nuovi team orientati alle applicazioni, che si occupano della maggior parte, se non di tutte, le attività indicate qui sotto.
Attività
Ruoli
Ingegnere delle operazioni applicative / Ingegnere di affidabilità del sito
Sviluppatore di applicazioni/ Sviluppatore software / Ingegnere del software
Amministratore del cluster/piattaforma applicativa
Responsabile del rilascio software / Ingegnere di build
Automazione e provisioning delle infrastrutture IT
I
I
R/A
C
Installazione e gestione della piattaforma OpenShift
C
I
R/A
C
Progettazione e gestione di pipeline di distribuzione
C
C
I
R/A
Gestione della preparazione degli ambienti clienti (tenant provisioning), isolamento e risorse IT
C
I
R/A
I
Costruzione e gestione delle immagini di base
R
C
R/A
C
Sviluppo di applicazioni e test
C
R/A
I
I
Monitoraggio operativo e gestione delle applicazioni
R/A
C
C
I
Test di accettazione dell'utente
C
R
I
I
Legende nella matrice RACI
Fonte:
- Responsabile – Esecutore – colui che compie le azioni necessarie per completare il compito.
- Responsabile – Responsabile – la persona che alla fine è responsabile per l'esecuzione corretta e accurata del compito o per il raggiungimento del risultato; è anche l'unica che può delegare il lavoro agli esecutori.
- Consultato – Consulenti – solitamente sono esperti nel campo specifico, il cui parere viene richiesto; con loro si mantiene una comunicazione bidirezionale.
- Informato – Informati – persone che vengono tenute al corrente degli avvenimenti (spesso solo al termine del compito o raggiungimento del risultato); ricevono informazioni in modo unidirezionale.
Come funziona la collaborazione dei team in un'organizzazione DevOps
Lo schema tradizionale per l'acquisizione delle risorse consiste generalmente in un ciclo di richieste per l'assegnazione delle risorse, che vengono poi eseguite da più team. Alla fine, tutte le risorse necessarie vengono allocate e confermate dalla parte richiedente. Spesso, questi processi sono parzialmente o completamente gestiti manualmente e richiedono frequenti e numerosi interventi tra i team per l'elaborazione efficace di ciascuna 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 si rivolgono ad altri con richieste per svolgere le opere necessarie, utilizzando mezzi di comunicazione più o meno formalizzati, come un sistema di ticket o l'email. Queste richieste entrano quindi in coda e attendono il loro turno, con attese prolungate che spesso portano a un deterioramento, se non a un aggravamento, delle relazioni tra i team. La tensione è ulteriormente accentuata dal fatto che i membri dei diversi team si incontrano raramente di persona e tendono a condividere solo le informazioni minime necessarie.
Figura 2. Organizzazione IT DevOps
In questo diagramma viene mostrato come si sviluppa la collaborazione all'interno di un'organizzazione DevOps. Qui, gli stessi team della diagramma precedente hanno abbandonato le comunicazioni inefficaci che aumentavano la disconnessione, sostituendole con contatti personali, creando così canali permanenti di interazione tra le squadre. Questi canali facilitano la formazione di un insieme ibrido di competenze, che aiuta i membri a comprendere e rappresentare meglio le necessità, i problemi e le opportunità delle squadre di cui fanno parte. Le squadre offrono reciprocamente la possibilità di svolgere il lavoro necessario tramite portali di self-service automatizzati, invece di gestire manualmente le richieste di modifica degli altri, come avveniva in precedenza. E grazie alla presenza di canali di interazione, questi sistemi di self-service possono adattarsi rapidamente alle esigenze dei team per cui sono stati creati. Per raggiungere un ulteriore livello di comprensione e scambio di conoscenze all'interno dell'organizzazione, i membri dei team ruotano periodicamente i loro ruoli per acquisire esperienza nell'interazione con diversi team e comprendere meglio il quadro generale dei sistemi IT che gestiscono, migliorando così il loro livello di cross-funzionalità e utilità.
In sintesi
In questo post abbiamo esaminato come l'implementazione di soluzioni PaaS possa incentivare un'organizzazione a adottare la metodologia DevOps, comportando un cambiamento nei ruoli e nelle responsabilità tradizionali. Abbiamo quindi elencato le principali sfide IT che emergono in un'organizzazione con il passaggio a OpenShift, così come le competenze necessarie per affrontarle. Inoltre, abbiamo fornito un insieme di ruoli organizzativi principali che si sviluppano nella creazione di team DevOps cross-funzionali, e una matrice RACI che allinea i nuovi ruoli con i nuovi compiti. Infine, abbiamo spiegato come la piattaforma OpenShift e la metodologia DevOps associata possano trasformare la struttura organizzativa, passando da una gerarchia tradizionale e sistemi di gestione delle richieste a team cross-funzionali caratterizzati da un livello più elevato di comunicazione personale.
Fonte: habr.com
