Pro / contro di interrompere un flusso di lavoro DevOps?

Sto provando a valutare se è una buona idea passare da un flusso di lavoro in stile devops ai tradizionali dev-then-op (non sono sicuro di come lo chiami).

Siamo un piccolo dipartimento di 5 persone nascosto all'interno di una società di media tradizionale (ad es. Non software) di 4000 dipendenti. Due anni fa abbiamo iniziato a creare software per consentire al nostro dipartimento di aumentare significativamente la nostra produzione. Abbiamo avuto un discreto successo e la grande azienda sta iniziando a prenderne atto. Ad oggi, siamo stati i soli responsabili per la progettazione, lo sviluppo e l'implementazione di quella che è diventata una piattaforma di microservizi AWS con ~ 10 servizi. Il nostro team non si identifica come DevOps, ma senza dubbio stiamo vivendo la vita di DevOps, con ogni sviluppatore intimamente familiare sia con il codice che con il sistema su cui viene eseguito.

Una delle domande che affronteremo a breve è quali "efficienze" sono condivise tra noi e il dipartimento IT della nostra società madre. Il proprietario del nostro progetto di solito preferisce l'outsourcing rispetto all'apprendimento interno, quindi nel nostro caso queste efficienze probabilmente significano quanto più lavoro IT "fuori dal comune" possibile. Attualmente, direi che il nostro team ha una divisione del 70/30% tra esperienza nella codifica e infrastruttura. Il reparto IT è solidamente nel regno IT, senza crossover visibile nello sviluppo del software.

Il nostro proprietario del progetto (un individuo non tecnico) spera che consegnando più lavoro possibile al team IT vedremo un aumento della produttività di ~ 1: 1 per ogni ora di operazioni che abbiamo svolto. Sono scettico su questo però. Il nostro prodotto è ancora pre-beta (nonostante sia già una risorsa aziendale significativa) e nella nostra esperienza limitata con il reparto IT di solito ci sono ritardi significativi per cose tanto semplici quanto le modifiche alle autorizzazioni del filesystem.

In questo momento, la mia soluzione ideale sarebbe che il dipartimento IT ci "adotti" e ci consenta di continuare a implementare il nostro lavoro, garantendo al contempo che soddisfiamo gli standard e i requisiti dell'ufficio IT. Non sono sicuro di quanto sia realistico. Inoltre è quasi l'approccio opposto che il nostro proprietario del progetto sta sostenendo poiché aggiungerebbe ulteriori operazioni a breve termine.

Nella nostra situazione, quali sono i probabili pro / contro di rimanere con l'approccio DevOps rispetto alla consegna dell'IT?

Non è una buona idea.

Nella mia esperienza otterrete gli svantaggi di entrambi, mentre i vantaggi previsti non riusciranno in qualche modo a concretizzarsi.

dettagliato:

1. Perderai velocità.
   L'IT rispetterà il proprio standard. La nuova attività (per loro) seguirà lo stesso modello 'lento' che tutto il loro lavoro ha ora. Preparati, lo troveranno stimolante, quindi anche meno velocità delle semplici azioni standard.
2. Non riuscirai a scaricare.
   I ragazzi si appoggeranno a voi ragazzi per ogni singola anomalia. Farai uno sforzo per accelerare un ragazzo - e la prossima cosa che ora ti ripeterai perché il seguente compito / problema / giorno ci sarà di nuovo un nuovo ragazzo.
3. Sarà richiesta la documentazione, ma non aiuterà.
   Ancora una volta il comportamento del modello sarà che i manuali brevi non riusciranno a rilevare ogni anomalia e i testi approfonditi non verranno letti per troppo tempo. Quindi qualsiasi investimento qui sarà una perdita, allo stesso modo l'enorme sforzo necessario per attuare miglioramenti per portare i tuoi strumenti a una qualità "ridotta".

Ultimo ma non meno importante, qualsiasi problema si rifletterà su di voi ragazzi. Catrame, principio di tarbrush.

Se quanto sopra sembra cinico, beh, temo di essere stato lì. Ripetutamente.

Cosa fare invece?

Fai shopping nel reparto IT, trova un candidato utile e mantieni questo ragazzo "in prestito" per alleviare il tuo carico di lavoro.

Puoi trovare molte delle risposte nel risultato del sondaggio DevOps che dovresti chiedere al proprietario del prodotto di leggere. Questo è un documento scritto appositamente per uomini d'affari con scarse conoscenze tecniche che parlano nei termini che dovrebbe comprendere.

In media avrai bisogno di 1 sviluppatore aggiuntivo per ogni 4 persone per mantenere lo stesso livello di sviluppo delle funzionalità (38% vs 49% del tempo dedicato a nuovi lavori). Il tempo medio per il ripristino da un errore scenderà fino a 25 volte. Il tuo lavoro sarà meno divertente del 20% e avrai il 40% di probabilità di consigliare il tuo lavoro ad un amico. Solo questi tre fatti dovrebbero essere sufficienti.

Quello che perderai inserendoti nell'organizzazione IT è la parte "Dev" del tuo piccolo team DevOps. Quando i team vengono segmentati in ruoli artificiali di NetOps, SysOps e Dev, si presentano i seguenti problemi:

1. Burocrazia e isolamento non necessari - Per fare qualsiasi cosa gli sviluppatori dovranno inviare un ticket all'IT e attendere che lo implementino. Non saranno più in grado di implementare e interagire con essi stessi, fino a includere le loro istanze Dev e QA che limiteranno l'infrastruttura che possono codificare. Sono bloccati alla barriera della VM invece di essere in grado di codificare sullo stack completo. Se ciò che inviano all'IT assomiglia a un codice DevOps, saranno mal equipaggiati per gestirlo e potrebbero tornare alle distribuzioni manuali.
2. Trascurare - In alternativa, possono semplicemente distribuirlo così com'è e quindi trascurare la bestia perché non sanno come interagire con esso - e non sono sviluppatori, quindi il codice non è il loro problema.
3. Interruzioni - Uno dei vantaggi spesso trascurati di DevOps è la sua natura programmatica. Certo, potrebbe essere necessario più tempo per distribuire quel server trattandolo come codice, ma questo automatizza gli errori umani. Il modo in cui è andato in sviluppo è il modo in cui andrà in QA / Test è il modo in cui andrà in prod, riducendo così le interruzioni. Quando gli sviluppatori perdono l'accesso alle apparecchiature di rete, devono implementare il loro servizio o l'infrastruttura di elaborazione non solo richiede più tempo, ma introduce più umani fallibili che causeranno più interruzioni.
4. Documentazione - In alcuni sensi, il codice DevOps è auto-documentante. Sai come il server è stato creato e distribuito perché il codice ti dice. Tra 5 anni, quando è il momento di eseguire l'aggiornamento a CentOS 8 o altro, nessuno saprà più come distribuire l'applicazione, inclusi i livelli di rete, archiviazione, monitoraggio e backup.

In breve, dovresti suggerire al proprietario del tuo progetto di prendere il tempo di leggere The Mythical Man-Month per disobbedire dell'idea che vedrai una relazione 1: 1 in termini di produttività e The Phoenix Project che è un buon romanzo (e divertente) illustrazione di ciò che viene guadagnato e perso usando DevOps in un linguaggio non tecnico per persone non tecniche. Se il proprietario del progetto ha qualsiasi tipo di pendolarismo, è disponibile un audiolibro Audible di The Phoenix Project.

Suggerirei di adottare parte del team IT e fornire loro una formazione approfondita sul nuovo sistema.

Una volta compreso completamente il sistema, è logico scaricarlo su di essi.

Altrimenti, diventerai un Centro di supporto per l'IT e passerai molto tempo a combattere gli incendi man mano che apprendono le complessità del nuovo sistema.