Perché DevOps non si integra bene nel business russo e di chi è la colpa

Che cos'è DevOps e quali attività svolge un ingegnere DevOps

Il termine DevOps (Operazioni di Sviluppo, ovvero operazioni all'interno

sviluppo - "High-tech") è stato utilizzato per la prima volta in2009 Consulente informatico Patrick Debois. In sostanza, non significa solo un posto vacante, ma un'intera metodologia che consente di creare prodotti digitali in modo più efficiente e rapido. Un insieme correlato di strumenti di sviluppo, gestione del prodotto, ingegneria del software e altre specialità garantisce un processo di creazione del software continuo.

Un ricco arsenale di pratiche avvicina DevOps agli altridiffuso in ambito IT utilizzando il metodo Agile. È un approccio di progettazione iterativo che consente di adattarsi ai requisiti in evoluzione. Di conseguenza, lo specialista DevOps cerca di migliorare il prodotto e i processi aziendali più prevedibili e più trasparenti. Migliora anche le metriche aziendali, come la riduzione del Time-to-Market. Questo è il periodo di tempo dall'inizio dello sviluppo del prodotto al suo lancio sul mercato. La conoscenza dei fattori che allungano il tempo per creare software e un approccio sistemico consentono all'ingegnere DevOps di rendere la produzione continua e veloce. Per renderlo più chiaro, puoi disegnare un'analogia con un nastro trasportatore per l'assemblaggio di automobili. Tutte le parti sono progettate in anticipo in modo che si adattino perfettamente insieme durante il montaggio. Gli ingegneri che sviluppano un motore pensano a come funziona in combinazione con le ruote, l'impianto frenante e così via. DevOps fa lo stesso: si assume la responsabilità di una quantità maggiore di prodotto rispetto allo sviluppatore, si assicura che tutti i team collaborino.

Pink Pony World: Race for Fashion Philosophy

Tuttavia, non tutte le aziende hanno bisogno di DevOps. Ad esempio, in team senza reparti IT preesistenti che non sono coinvolti nella produzione di un prodotto digitale, la filosofia DevOps non si applica affatto. Queste aree includono le aziende il cui profitto non dipende direttamente dalla soddisfazione dei clienti con il prodotto IT con cui interagiscono. Inoltre, spesso non è adatto alle piccole imprese. La metodologia richiede cambiamenti in molti processi aziendali consolidati e persino nella cultura aziendale. Le piccole imprese potrebbero semplicemente non tollerare tali cambiamenti dal punto di vista dell'economia del progetto.

La malattia alla moda della trasformazione digitale è spessoriguarda i responsabili di tali società. Alla ricerca di un'ottimizzazione infinita, dimenticano altri fattori che influenzano l'attività. Di conseguenza, le aziende perdono denaro, efficienza e, nel peggiore dei casi, processi di business che sono stati costruiti nel corso degli anni: giganti IT, banche, grandi eventi commerciali ed industriali sono un'altra questione. Per loro, DevOps può essere molto vantaggioso. Pertanto, secondo il rapporto annuale di Alfa-Bank per il 2017, l'introduzione della metodologia ci ha permesso di accelerare lo sviluppo e l'implementazione di 60 volte.

Stakhanovite-mnogostanochnik invece di un laboratorio

Ovviamente, una funzionalità così ampia è difficileper dipendente, quindi idealmente un intero team interfunzionale è coinvolto in DevOps. Comprende professionisti in ruoli e responsabili di processo e prodotto, sviluppatore di codice dell'infrastruttura, ingegnere e molti altri ruoli. Tuttavia, nella pratica russa, uno specialista DevOps può spesso diventare un modo alla moda per risparmiare denaro sulla creazione del prodotto. In genere, questa situazione si verifica dopo che il top manager dell'azienda decide che è giunto il momento della trasformazione digitale. L'azienda recluta urgentemente nuovi specialisti o amplia l'elenco delle responsabilità degli sviluppatori e degli amministratori di sistema esistenti. Di conseguenza, i servizi di reclutamento non offrono posti vacanti per gli ingegneri DevOps, ma per i dipendenti multi-stazione.

Un tale dipendente può essere obbligato individualmenteconfigurare i server, installare i sistemi di cablaggio e quindi tenere traccia degli errori, configurare i database e l'hosting del progetto e così via. Questo esempio è estremo, ma reale. Di conseguenza, i dipendenti si esauriscono rapidamente e l'implementazione della metodologia nel lavoro dell'azienda fallisce. Trattare uno specialista DevOps come un mago in grado di gestire contemporaneamente un gran numero di attività, insieme al monitoraggio del funzionamento dell'intero sistema, non porterà profitto all'azienda.

Un altro problema comune è correlato adividendo la squadra in due gruppi che non possono andare d'accordo tra loro. Immagina che un'azienda IT abbia un reparto DevOps, a cui è consentito modificare le normali procedure di lavoro. Tuttavia, queste regole rimangono vincolanti per altri sviluppatori. Certo, in questo caso non c'è bisogno di parlare di cooperazione e "fluidità" del lavoro. Le due squadre iniziano a scontrarsi e la produttività cala.

Un barile di polvere nella stiva: DevOps non è solo abilità

Uno dei compiti del dipartimento DevOps è stabilirecomunicazione tra diversi specialisti IT dell'azienda. Gli ingegneri DevOps non dovrebbero solo implementare tecnologie e processi di debug, ma anche immergere il team di sviluppo nel corso del business: condividere le responsabilità, aiutare ad aumentare le competenze. Tuttavia, tali specialisti si occupano spesso di compiti puramente tecnici, solitamente per la banale mancanza di tempo, sia per loro che per coloro le cui competenze devono essere aumentate.

Di conseguenza, a causa del fatto che l'introduzione alla modaTutti usano le tecnologie e le conoscenze e le competenze sono concentrate in un dipartimento, sorgono situazioni problematiche, comprese quelle catastrofiche. Le nuove soluzioni create dagli ingegneri DevOps, senza il lavoro coordinato di diversi reparti, possono portare tanti problemi quanti avrebbero dovuto risolvere inizialmente, il che non significa che gli specialisti DevOps debbano creare una cultura aziendale da zero, come sembrano spesso pensare quelli domestici. capi. L'unità della pipeline di produzione digitale e l'incoraggiamento al trasferimento di nuove competenze e comunicazioni devono provenire dai leader dell'azienda. Senza questo, anche il team DevOps si svilupperà male e non condividerà le conoscenze con il team.

Né DevOps outsourcing néconsultare uno specialista dall'esterno. Nel primo caso, il team esterno è guidato non dalle esigenze dell'azienda cliente, ma dall'insieme standard di tecnologie quotate sul mercato. Per il cliente, questa è una lotteria: i dipendenti in outsourcing utilizzano una vaga comprensione di DevOps nel mercato. Di conseguenza, i processi aziendali diventano sempre più complessi, ma questo non porta alcun vantaggio all'azienda. Spesso le aziende stesse incoraggiano questo approccio, ad esempio chiedendo loro di non modificare i propri processi di sviluppo. È chiaro che questo è contrario al concetto stesso di DevOps.

Lungo, costoso, problematico: DevOps aspro in russo

Invece di applicare la filosofia DevOps aa tutti i processi aziendali, le aziende nazionali spesso preferiscono lavorare su strumenti che non influiscano sulla velocità del lavoro. Uno dei risultati, ad esempio, è il "muro di mattoni": le operazioni, ovvero il team di amministratori di sistema, rimangono isolate e gli sviluppatori si limitano a lanciare applicazioni contro di loro. Di conseguenza, la cassetta degli attrezzi sta ancora migliorando. Tuttavia, non si verificano cambiamenti fondamentali, la trasparenza non sta aumentando e la collaborazione del team IT non sta migliorando.

Un altro intoppo in cui si imbattonomanager durante l'implementazione di DevOps: mancanza di basi di conoscenza aziendali. Secondo il rapporto DORA del 2019, i team che utilizzavano fonti informative interne all’azienda erano 1,73 volte più efficaci degli altri. Anche questo problema è dovuto alla cultura chiusa di molte aziende russe, in cui il team non condivide la conoscenza. A causa di questa natura chiusa, le aziende iniziano ad accumulare debito tecnico. Gli strumenti stanno diventando obsoleti, gli artefatti non vengono rimossi, la documentazione non viene aggiornata.

L’oggettiva esigenza aziendale di stabilità della produzione, e quindi di profitto, unita a una base tecnologica obsoleta e al debito tecnico portano all’uso infruttuoso di DevOps.

Tutto ciò porta spesso al fatto che, dopo una lunga agonia, le nuove soluzioni offerte dal team DevOps vengono semplicemente buttate via e i processi vengono "annullati".

Ogni azienda ha il proprio percorso di trasformazione digitale. Nella maggior parte dei casi, cambia davvero in meglio il modo in cui il codice viene sviluppato e distribuito. Ciò significa che DevOps esiste ancora in Russia: ogni mese ci sono molte offerte di lavoro sul mercato legate a questa metodologia. Un'altra cosa è che ci sono diverse definizioni della specialità e dei compiti pratici dietro di loro. Tuttavia, le aziende dovrebbero smetterla di inseguire sistemi IT fantasmagorici ed essere critiche nell'adottare una filosofia alla moda ma non necessariamente redditizia, dando la priorità alle proprie esigenze.

Vedi anche:

Potrebbero esserci universi nei buchi neri. Vi parliamo della nuova scoperta

Al terzo giorno di malattia, la maggior parte dei pazienti COVID-19 perde il senso dell'olfatto e spesso soffre di naso che cola

Ricerca: 15 milioni di tonnellate di microplastiche trovate sul fondo dell'oceano