Sebbene le soluzioni PaaS (Platform as a Service) di per sé non possano cambiare i modi di interazione individuale e di gruppo, spesso fungono da catalizzatore per cambiamenti organizzativi in risposta alla crescente flessibilità delle tecnologie IT.
In pratica, il massimo ritorno sugli investimenti in PaaS è spesso possibile solo a patto che ci siano cambiamenti nei ruoli organizzativi, nelle aree di responsabilità e nelle relazioni. Fortunatamente, soluzioni PaaS come OpenShift Container Platform offrono sufficiente flessibilità affinché ogni organizzazione IT possa determinare autonomamente la velocità e la scala delle trasformazioni riguardanti le persone coinvolte e i processi in corso.
Nella prima fase della containerizzazione aziendale, la priorità principale è l'implementazione di una piattaforma container come nuovo sistema di distribuzione delle applicazioni. In questo momento, le organizzazioni collegano attività familiari a ruoli noti, per rispondere alle richieste standard dei team di sviluppo in questioni come sistemi di archiviazione, ambienti di distribuzione e altro. Nelle fasi successive della containerizzazione, si parla già di automazione o di fornire ai programmatori opportunità di self-service, con l'obiettivo di ridurre il carico sui sistemisti e portare l'autonomia e la reattività dei programmatori a un livello superiore. Questo è il modo in cui un'organizzazione comincia a muoversi verso il DevOps. Nella fase finale della containerizzazione, l'azienda arriva a un modello DevOps più pulito e canonico, nel quale molte delle precedenti attività e compiti vengono trasferiti al controllo di team cross-funzionali, che si raggruppano non in base a piattaforme o tecnologie, ma in base al supporto delle applicazioni o dei servizi applicativi.
In questo post presenteremo una guida per apportare i necessari cambiamenti organizzativi e spiegheremo come i ruoli IT tradizionali cambiano con l'implementazione delle tecnologie container nelle aziende.
Collegare nuove attività a vecchi ruoli
Nella sua forma base, il modello organizzativo PaaS è creato per assegnare in modo più flessibile e rapido le risorse IT alle applicazioni come ambiente di esecuzione. Anche se ciò offre alcuni vantaggi agli amministratori di sistema, gli sviluppatori generalmente non ottengono benefici sostanziali e nuove opportunità, poiché in questa fase l'azienda può tranquillamente operare senza avviare l'automazione, implementare il self-service o migliorare radicalmente il pipeline di distribuzione. Anche 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 in passato la creazione di un ambiente di sviluppo richiedeva giorni o addirittura settimane, coinvolgendo diversi amministratori, ora con PaaS tutto avviene molto più rapidamente e con il lavoro di un solo amministratore. macchine virtuali In altre parole, i team di sviluppatori presentano richieste come prima, ma l'attuazione di queste richieste avviene secondo un nuovo schema.
Verso un'organizzazione DevOps
Attivando PaaS e trasferendo su di essa specialisti dell'operatività dei sistemi IT e sviluppatori di applicazioni, l'organizzazione può continuare l'implementazione della metodologia DevOps, che include tra gli altri i seguenti principi fondamentali:
- Suddividere il lavoro in fasi più piccole, per ricevere feedback nelle fasi iniziali, ridurre i rischi ed evitare il 'paralisi analitica';
- Automatizzare le operazioni sufficientemente, per non creare ostacoli o colli di bottiglia nel processo di distribuzione dell'applicazione;
- La condivisione delle conoscenze è la chiave per costruire fiducia;
- Pagar regolarmente i debiti tecnici, dedicando in ogni ciclo di lavoro un tempo specifico ai miglioramenti sistematici.
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 invio e gestione delle richieste di assistenza è ora percepito come un collo di bottiglia, quindi l'organizzazione cerca di automatizzare le azioni ripetitive e di fornire agli sviluppatori opportunità di self-service. Inoltre, queste opportunità per gli sviluppatori, nell'ambito di una determinata richiesta, sono definite da sforzi congiunti degli specialisti IT che gestiscono le piattaforme e di coloro che sono responsabili della distribuzione delle applicazioni. In altre parole, gli amministratori di sistema che svolgono azioni su richiesta degli sviluppatori sono gradualmente sostituiti dalle due categorie di personale sopra menzionate, responsabili della definizione e dell'applicazione delle politiche che regolano ciò che gli sviluppatori possono fare da soli. Le procedure automatizzate aiutano a garantire che siano rispettati tali requisiti e a coordinare le azioni nei casi in cui la situazione esca dai confini delle politiche attuali.
La transizione verso un calendario iterativo, in cui l'ambiente IT e il modello operativo subiscono cambiamenti iterativi nel tempo, rappresenta una pietra miliare critica nel processo di creazione di un sistema DevOps maturo all'interno dell'azienda. Il grado di accettazione della metodologia DevOps dipende dalla tolleranza di ciascuna organizzazione ai cambiamenti e da quali cambiamenti portano il maggiore beneficio. Ad esempio, se la necessità di creare nuovi ambienti o applicazioni sorge raramente, allora l'ottimizzazione delle relative azioni sarà meno importante rispetto al rafforzamento del controllo degli sviluppatori sul ciclo di vita delle applicazioni.
Nuove sfide che sorgono nelle organizzazioni IT durante la transizione a OpenShift
In questa sezione esamineremo i ruoli e i compiti che le organizzazioni che sono passate a OpenShift di solito applicano per accelerare l'automazione e il self-service utilizzando tecnologie e PaaS.
Nella tabella sottostante sono elencate le principali attività di alto livello che esistono in qualsiasi organizzazione che ha implementato OpenShift, con esempi di lavori e competenze corrispondenti. Questo elenco di attività non deve essere confuso con una suddivisione dei lavori o con la struttura organizzativa dei team, è semplicemente un insieme di compiti che devono essere gestiti da parte di coloro che sono responsabili del supporto dell'ambiente IT, per una corretta implementazione della piattaforma container. In effetti, dimostreremo più avanti come l'implementazione delle tecnologie container crei le premesse per sviluppare una strategia DevOps più matura nell'impresa, il che aumenta la cross-funzionalità dei team e riduce i rischi di specializzazione ristretta, sia a livello di singoli dipendenti che di team.
Tabella 1. Definizioni delle attività di OpenShift
Problemi
Competenze richieste
Automazione e provisioning delle infrastrutture IT
Attività:
- Progettazione e costruzione di soluzioni hardware
- Organizzazione e supporto all'automazione della configurazione iniziale
- Progettazione e automazione del provisioning di VM e host
- Progettazione e implementazione di data center
- Amministrazione di sistema Linux
- Script di automazione
- Conoscenza dei sistemi di archiviazione
- Conoscenza nella progettazione e implementazione 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 container
- Conoscenza delle architetture Kubernetes e OpenShift
- Sicurezza della piattaforma
- Integrazione del monitoraggio
Gestione del provisioning degli ambienti clienti (tenant provisioning), isolamento delle risorse IT
Attività:
- 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 architetture container
- Script di automazione
- Ottime conoscenze in progetti, quote, binding dei ruoli e lavoro con i pianificatori
Costruzione e gestione delle immagini di base
Attività:
- Sviluppo di workflow di modifica delle immagini
- Sviluppo di immagini basate su standard
- Amministrazione di sistema Linux
- Script di automazione
- Configurazione dei componenti runtime delle applicazioni e middleware
- Conoscenza delle architetture container
- Framework di build delle applicazioni (application build frameworks)
- Ottime conoscenze in immagini, imagestream e modelli
Progettazione e gestione dei pipeline di distribuzione
Attività:
- Progettazione e documentazione degli standard dei pipeline
- Sviluppo di guide concise e modelli
- Formazione degli sviluppatori
- Gestione del codice sorgente
- Progettazione e implementazione delle applicazioni
- Script di automazione
- Test automatizzati
- Verifica della qualità del codice
- Conoscenza delle architetture container
- Conoscenza delle infrastrutture immutabili
- Sicurezza: gestione dell'accesso alle fasi del 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
- Gestione dei guasti dei test durante il pipeline di distribuzione
- Gestione dei guasti delle applicazioni
- Test di accettazione degli utenti
- Progettazione e implementazione delle applicazioni
- Test automatizzati
- Gestione del codice sorgente
- Monitoraggio delle applicazioni
- Conoscenza delle architetture delle applicazioni cloud native
Monitoraggio operativo e gestione delle applicazioni
Attività:
- Progettazione delle applicazioni nel contesto delle prestazioni
- Monitoraggio delle applicazioni in fase di esecuzione
- Scalabilità delle applicazioni (o autoscalabilità)
- Gestione dell'affidabilità delle applicazioni
- Quote di richieste e limiti per la gestione delle risorse
- Test delle prestazioni e capacità IT
- Progettazione e implementazione delle prestazioni delle applicazioni
- Monitoraggio delle prestazioni delle applicazioni
- Test delle prestazioni e test di carico
Test di accettazione degli utenti
Attività:
- Test UI (design e interazioni utente)
- Sviluppo di test automatizzati
- Progettazione e verifica delle interfacce utente
- Modelli di test automatizzati
- Framework di testing
- Modelli di progettazione delle applicazioni
Nuove posizioni che emergono nelle organizzazioni IT durante la transizione a OpenShift
Con la transizione a un modello organizzativo orientato al DevOps, la specializzazione dei ruoli tende a diminuire, mentre aumenta il numero di team e ruoli cross-funzionali per massimizzare l'efficacia della collaborazione. Ecco come, secondo noi, appare l'elenco delle posizioni principali nelle organizzazioni IT che utilizzano OpenShift:
- Ingegnere delle operazioni delle applicazioni (Application Operations Engineer) OPPURE Ingegnere dell'affidabilità del sito (Site Reliability Engineer). In passato, questa posizione poteva essere chiamata «Amministratore di server delle applicazioni».
- Sviluppatore di applicazioni/sviluppatore software/ingegnere del software.
- Amministratore di cluster / piattaforme applicative. In precedenza, questo ruolo poteva essere chiamato "Amministratore di sistema" o "Amministratore di piattaforme Linux".
- Manager del rilascio software (Release Manager) / Ingegnere di costruzione (Build Engineer).
Matrice dei ruoli e compiti RACI
Infine, passiamo alla mappatura delle posizioni e dei compiti discussi in precedenza, per fornire una visione generale di come dovrebbe apparire la struttura dell'organizzazione che implementa DevOps sulla piattaforma OpenShift. Inizialmente, i ruoli indicati di seguito possono essere svolti da diverse branche della vecchia, tradizionale struttura organizzativa. Tuttavia, nel tempo avviene una consolidazione e nascono nuovi team, costruiti attorno alle applicazioni, che si occupano della maggior parte, se non di tutti, i compiti indicati di seguito.
Problemi
Ruoli
Ingegnere di operazioni applicative / Ingegnere di affidabilità del sito
Sviluppatore di applicazioni / Sviluppatore software / Ingegnere programmatore
Amministratore di cluster / piattaforme applicative
Manager del rilascio software / Ingegnere di costruzione
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 dei pipeline di distribuzione
C
C
I
R/A
Gestione della preparazione degli ambienti dei clienti (tenant provisioning), isolamento e capacità 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 degli utenti
C
R
I
I
Simboli nella matrice RACI
Fonte:
- Responsabile – Esecutore – colui che svolge le necessità per completare il compito.
- Responsabile – Responsabile – il dipendente che in ultima analisi è responsabile per l'esecuzione corretta e accurata del compito o per il raggiungimento del risultato; inoltre, è l'unico a poter delegare il lavoro agli esecutori.
- Consultato – Consultant – di norma, sono esperti nel campo di competenza, il cui parere è richiesto; con loro c'è una comunicazione bilaterale.
- Informato – Informati – persone che vengono tenute al corrente degli sviluppi (a volte, solo al termine del compito o al raggiungimento del risultato); ricevono informazioni in modo unidirezionale.
Come si svolge la collaborazione dei team in un'organizzazione DevOps
Lo schema tradizionale di ottenimento delle risorse è di solito un ciclo di richieste per l'assegnazione delle risorse, che vengono poi eseguite da diversi team. Alla fine, tutte le risorse necessarie vengono assegnate e confermate dalla parte richiedente. Spesso, questi processi vengono eseguiti in parte, se non completamente, manualmente e richiedono frequenti e numerosi interazioni tra i team per gestire con successo ogni richiesta.
Figura 1. Organizzazione IT tradizionale
Il diagramma sopra illustra le relazioni tipiche tra i team in un'organizzazione IT tradizionale. In questo schema, alcuni team si rivolgono ad altri team con richieste per l'esecuzione dei lavori necessari, utilizzando mezzi di comunicazione più o meno formalizzati, come sistemi di ticketing o email. Queste richieste vengono poi messe in coda e attendono il loro turno, e spesso un'attesa prolungata porta a deterioramenti, se non addirittura a un'esacerbazione delle relazioni tra i team. La tensione è aggravata dal fatto che i membri di diversi team raramente si incontrano di persona e, di solito, condividono solo le informazioni minimamente necessarie.
Figura 2. Organizzazione IT DevOps
In questo diagramma viene mostrato come funziona la collaborazione all'interno di un'organizzazione DevOps. Qui gli stessi team del diagramma precedente hanno abbandonato le comunicazioni inefficaci, che accentuavano la disconnessione, e le hanno sostituite con contatti personali, creando così canali permanenti di interazione tra i team. Questi canali favoriscono la formazione di un insieme ibrido di competenze, che aiuta i dipendenti a comprendere e rappresentare meglio le necessità, i problemi e le opportunità dei team che rappresentano. I team si consentono reciprocamente di eseguire i lavori necessari tramite portali di self-service automatizzati invece di elaborare manualmente le richieste di modifica degli altri, come si faceva in precedenza. E grazie alla presenza di canali di interazione, questi sistemi di self-service sono in grado di adattarsi rapidamente ai bisogni dei team per cui sono stati creati. Per raggiungere una maggiore comprensione reciproca e uno scambio di conoscenze all'interno dell'organizzazione, i membri dei team eseguono periodicamente rotazioni di ruolo, per acquisire esperienza nell'interazione con diversi team e comprendere meglio il quadro complessivo dei sistemi IT che gestiscono, aumentando così il loro livello di cross-funzionalità e utilità.
In sintesi
In questo post, abbiamo discusso di come l'implementazione di soluzioni PaaS possa spingere un'organizzazione ad adottare la metodologia DevOps, portando a un cambiamento nei ruoli e nei compiti tradizionali. Pertanto, abbiamo elencato le principali sfide IT che sorgono in un'organizzazione con la transizione a OpenShift, così come le competenze necessarie per affrontarle. Abbiamo anche fornito un set di ruoli organizzativi fondamentali che emergono nella costruzione di team DevOps cross-funzionali e una matrice RACI che collega i nuovi ruoli con i nuovi compiti. Infine, abbiamo descritto come la piattaforma OpenShift e la relativa metodologia DevOps possano trasformare la struttura organizzativa, passando dalla tradizionale gerarchia e dai sistemi di gestione delle richieste a team cross-funzionali con un livello di comunicazione personale più elevato.
Fonte: habr.com
