Si tratta, ovviamente, di . Se non entri nei dettagli, il 30 settembre e il 1 ottobre terremo una conferenza sulla combinazione dei processi di sviluppo, test e funzionamento, e se entri nei dettagli, per favore, sotto cat.
Nell’approccio DevOps, tutte le parti dello sviluppo tecnologico del progetto sono intrecciate, avvengono in parallelo e si influenzano a vicenda. Di particolare importanza qui è la creazione di processi di sviluppo automatizzati che possono essere modificati, simulati e testati in tempo reale. Questo ti aiuta a rispondere immediatamente ai cambiamenti del mercato.
Alla conferenza vogliamo mostrare come questo approccio influenza lo sviluppo del prodotto. Come viene garantita l'affidabilità e l'adattabilità del sistema per il cliente. Come DevOps sta cambiando la struttura e l'approccio di un'azienda all'organizzazione del proprio processo di lavoro.
dietro le quinte
Per noi è importante sapere non solo cosa stanno facendo le diverse aziende nell'ambito dell'approccio DevOps, ma anche capire perché tutto ciò viene fatto. Pertanto, abbiamo invitato a far parte del comitato del programma non solo esperti, ma specialisti che vedono il discorso DevOps da diverse posizioni:
- ingegneri senior;
- sviluppatori;
- leader della squadra;
- CTO.
Da un lato ciò crea difficoltà e conflitti nella discussione delle richieste di relazioni. Se un ingegnere è interessato ad analizzare un incidente rilevante, allora è più importante che uno sviluppatore capisca come creare un software che funzioni nel cloud e nelle infrastrutture. Ma concordando, creiamo un programma che sarà prezioso e interessante per tutti: dagli ingegneri al CTO.
L'obiettivo della nostra conferenza non è solo selezionare i report più pubblicizzati, ma presentare il quadro generale: come funziona nella pratica l'approccio DevOps, in che tipo di rake si può incorrere quando si passa a nuovi processi. Allo stesso tempo costruiamo la parte contenutistica, scendendo dalla problematica aziendale alle tecnologie specifiche.
Le sezioni del convegno rimarranno le stesse di .
- Piattaforma infrastrutturale.
- Infrastruttura come codice.
- Consegna continua.
- Contattaci.
- Architettura in DevOps, DevOps per CTO.
- Pratiche SRE.
- Formazione e gestione della conoscenza.
- Sicurezza, DevSecOps.
- Trasformazione DevOps.
Call for Papers: che tipo di report cerchiamo
Abbiamo suddiviso condizionatamente il potenziale pubblico della conferenza in cinque gruppi: ingegneri, sviluppatori, specialisti della sicurezza, responsabili del team e CTO. Ogni gruppo ha la propria motivazione per venire alla conferenza. E, se guardi a DevOps da queste posizioni, puoi capire come focalizzare il tuo argomento e dove porre l'accento.
Per gli ingegneri, Per chi sta creando una piattaforma infrastrutturale, è importante capire i trend esistenti, per capire quali tecnologie sono oggi le più avanzate. Saranno interessati a conoscere l'esperienza di vita reale nell'uso di queste tecnologie e nello scambio di opinioni. Un ingegnere sarà felice di ascoltare un rapporto che analizza alcuni incidenti gravi e noi, a nostra volta, proveremo a selezionare e perfezionare tale rapporto.
Per gli sviluppatori è importante comprendere un concetto come applicazione nativa del cloud. Cioè, come sviluppare software in modo che funzioni nel cloud e in varie infrastrutture. Lo sviluppatore deve ricevere costantemente feedback dal software. Qui vogliamo ascoltare casi su come le aziende costruiscono questo processo, come monitorare le prestazioni del software e come funziona l'intero processo di consegna.
Specialisti della sicurezza informatica È importante capire come impostare il processo di sicurezza in modo che non blocchi i processi di sviluppo e cambiamento all’interno dell’azienda. Saranno interessanti anche gli argomenti sui requisiti che DevOps impone a tali specialisti.
I leader del team vogliono saperlo, come funziona il processo di consegna continua in altre aziende. Quale percorso hanno intrapreso le aziende per raggiungere questo obiettivo, come hanno costruito processi di sviluppo e garanzia della qualità all'interno di DevOps. Anche i leader del team sono interessati al cloud nativo. E anche domande sull'interazione all'interno del team e tra i team di sviluppo e di ingegneria.
per CTO la cosa più importante è capire come collegare tutti questi processi e adattarli alle esigenze aziendali. Si assicura che l'applicazione sia affidabile sia per l'azienda che per il cliente. E qui devi capire quali tecnologie funzioneranno per quali attività aziendali, come costruire l'intero processo, ecc. Il CTO è anche responsabile del budget. Ad esempio, deve capire quanti soldi devono essere spesi per la riqualificazione degli specialisti in modo che possano lavorare in DevOps.
Se hai qualcosa da dire su questi argomenti, non tacere, . La scadenza per la Call for Papers è il 20 agosto. Prima ti registri, più tempo avrai per finalizzare il tuo rapporto e prepararti per la presentazione. Quindi, non ritardare.
Bene, se non hai bisogno di parlare pubblicamente, basta e vieni il 30 settembre e il 1 ottobre per comunicare con i colleghi. Promettiamo che sarà interessante e stimolante.
Come vediamo DevOps
Per capire esattamente cosa intendiamo per DevOps, consiglio di leggere (o rileggere) il mio report”" Camminando tra le onde del mercato, ho osservato come l’idea di DevOps si stesse trasformando in aziende di diverse dimensioni: dalla piccola startup alle multinazionali. Il report è costruito su una serie di domande, rispondendo potrai capire se la tua azienda si sta muovendo verso DevOps o se ci sono problemi da qualche parte.
DevOps è un sistema complesso, deve includere:
- Prodotto digitale.
- Moduli aziendali che sviluppano questo prodotto digitale.
- Team di prodotto che scrivono codice.
- Pratiche di consegna continua.
- Piattaforme come servizio.
- Infrastruttura come servizio.
- Infrastruttura come codice.
- Pratiche separate per il mantenimento dell'affidabilità, integrate in DevOps.
- Una pratica di feedback che descrive tutto.
Alla fine del report è presente uno schema che dà un’idea del sistema DevOps presente in azienda. Ti permetterà di vedere quali processi nella tua azienda sono già stati snelliti e quali devono ancora essere costruiti.
È possibile guardare il video del rapporto .
E ora ci sarà un bonus: diversi video del RIT++ 2019, che toccano le questioni più generali della trasformazione DevOps.
L'infrastruttura aziendale come prodotto
Artyom Naumenko guida il team DevOps di Skyeng e si occupa dello sviluppo dell'infrastruttura della sua azienda. Ha raccontato come l'infrastruttura influisce sui processi aziendali in SkyEng: come calcolarne il ROI, quali metriche dovrebbero essere scelte per il calcolo e come lavorare per migliorarle.
Sulla strada dei microservizi
La società Nixys fornisce supporto per progetti web impegnativi e sistemi distribuiti. Il suo direttore tecnico, Boris Ershov, ha spiegato come tradurre i prodotti software, il cui sviluppo è iniziato 5 anni fa (o anche più), su una piattaforma moderna.
Di norma, tali progetti sono un mondo speciale in cui ci sono angoli così oscuri e antichi dell'infrastruttura che gli attuali ingegneri non li conoscono. Inoltre, gli approcci all'architettura e allo sviluppo scelti una volta sono obsoleti e non possono fornire all'azienda lo stesso ritmo di sviluppo e rilascio di nuove versioni. Di conseguenza, ogni rilascio di prodotto si trasforma in un'avventura incredibile, dove qualcosa cade costantemente e nel posto più inaspettato.
I gestori di tali progetti si trovano inevitabilmente ad affrontare la necessità di trasformare tutti i processi tecnologici. Nel suo rapporto, Boris ha detto:
- come scegliere l'architettura giusta per il progetto e mettere in ordine l'infrastruttura;
- quali strumenti utilizzare e quali insidie si incontrano nel percorso di trasformazione;
- cosa fare dopo.
Automazione dei rilasci o modalità di consegna rapida e indolore
Alexander Korotkov è uno sviluppatore leader del sistema CI/CD presso CIAN. Ha parlato di strumenti di automazione che hanno permesso di migliorare la qualità e ridurre di 5 volte i tempi di consegna del codice alla produzione. Ma tali risultati non potevano essere raggiunti solo con l’automazione, quindi Alexander ha prestato attenzione anche ai cambiamenti nei processi di sviluppo.
In che modo gli incidenti ti aiutano ad imparare?
Alexey Kirpichnikov implementa DevOps e l'infrastruttura presso SKB Kontur da 5 anni. Nel corso di tre anni, nella sua compagnia si sono verificati circa 1000 fakap di vari gradi di epicità. Di questi, ad esempio, il 36% è stato causato dall'implementazione in produzione di una versione di bassa qualità e il 14% da lavori di manutenzione hardware nel data center.
Un archivio di relazioni (autopsie) che gli ingegneri dell’azienda conservano da diversi anni consecutivi consente di ottenere informazioni così precise sugli incidenti. L'autopsia è redatta dall'ingegnere di turno, che per primo ha risposto al segnale di emergenza e ha iniziato a sistemare tutto. Perché tormentare gli ingegneri che lottano di notte con le maschere facciali scrivendo rapporti? Questi dati consentono di avere una visione d’insieme e di spostare lo sviluppo delle infrastrutture nella giusta direzione.
Nel suo discorso, Alexey ha spiegato come scrivere un'autopsia veramente utile e come implementare la pratica di tali rapporti in una grande azienda. Se ti piacciono le storie su come qualcuno ha sbagliato, guarda il video dello spettacolo.
Comprendiamo che la tua visione di DevOps potrebbe non corrispondere alla nostra. Sarà interessante sapere come vedi la trasformazione DevOps. Condividi la tua esperienza e visione di questo argomento nei commenti.
Quali rapporti abbiamo già accettato nel programma?
Questa settimana il comitato del programma ha adottato 4 rapporti: sulla sicurezza, sulle infrastrutture e sulle pratiche SRE.
Forse l'argomento più doloroso della trasformazione DevOps: come assicurarsi che i ragazzi del dipartimento di sicurezza delle informazioni non distruggano le connessioni già costruite tra sviluppo, funzionamento e amministrazione. Alcune aziende gestiscono senza un dipartimento di sicurezza delle informazioni. Come garantire la sicurezza delle informazioni in questo caso? A proposito Mona Arkhipova da sudo.su. Dal suo rapporto apprendiamo:
- cosa deve essere protetto e da chi;
- quali sono i processi di sicurezza di routine;
- come si intersecano i processi IT e di sicurezza delle informazioni;
- cos'è il CIS CSC e come implementarlo;
- come e con quali indicatori condurre controlli regolari sulla sicurezza delle informazioni.
La prossima relazione riguarda lo sviluppo dell'infrastruttura come codice. Ridurre la quantità di routine manuale e non trasformare l'intero progetto nel caos, è possibile? A questa domanda Maxim Kostrikin di Ixtens. La sua azienda utilizza Terraform per lavorare con l'infrastruttura AWS. Lo strumento è comodo, ma la domanda è come evitare di creare un enorme blocco di codice quando lo si utilizza. Il mantenimento di tale eredità diventerà ogni anno sempre più costoso.
Maxim mostrerà come funzionano i modelli di posizionamento del codice, volti a semplificare l'automazione e lo sviluppo.
un altro sentiremo parlare di infrastrutture da Vladimir Ryabov di Playkey. Qui parleremo della piattaforma infrastrutturale e impareremo:
- come capire se lo spazio di archiviazione viene utilizzato in modo efficace;
- come diverse centinaia di utenti possono ricevere 10 TB di contenuti se vengono utilizzati solo 20 TB di spazio di archiviazione;
- come comprimere i dati 5 volte e fornirli agli utenti in tempo reale;
- come sincronizzare i dati al volo tra diversi data center;
- come eliminare qualsiasi influenza reciproca degli utenti quando si utilizza una macchina virtuale in sequenza.
Il segreto di questa magia è la tecnologia ZFS per FreeBSD e la sua forchetta fresca ZFS su Linux. Vladimir condividerà i casi da Playkey.
Matvey Kukuy di Amixr.IO pronto con esempi dalla vita , che cosa SRE e come aiuta a costruire sistemi affidabili. Amixr.IO trasmette gli incidenti dei clienti attraverso il suo backend; decine di team in servizio in tutto il mondo hanno già trattato 150mila casi. Alla conferenza, Matvey condividerà le statistiche e le intuizioni che la sua azienda ha accumulato risolvendo i problemi dei clienti e analizzando i fallimenti.
Ancora una volta ti esorto a non essere avido e a condividere la tua esperienza come samurai DevOps. Servire per una relazione, e io e te avremo 2,5 mesi e mezzo per preparare un discorso eccellente. Se vuoi essere un ascoltatore, alla newsletter con gli aggiornamenti del programma e pensa seriamente a prenotare i biglietti in anticipo, perché diventeranno più costosi con l'avvicinarsi delle date della conferenza.
Fonte: habr.com