Estamos a falar, por suposto, de . Se non entras en detalles, o 30 de setembro e o 1 de outubro celebraremos unha conferencia sobre a combinación dos procesos de desenvolvemento, probas e operación, e se entras en detalles, por favor, baixo cat.
Dentro do enfoque DevOps, todas as partes do desenvolvemento tecnolóxico do proxecto están entrelazadas, ocorren en paralelo e inflúen mutuamente. Aquí ten especial importancia a creación de procesos de desenvolvemento automatizados que se poidan cambiar, simular e probar en tempo real. Isto axúdache a responder instantáneamente aos cambios no mercado.
Na conferencia queremos mostrar como este enfoque inflúe no desenvolvemento do produto. Como se garante a fiabilidade e adaptabilidade do sistema para o cliente. Como DevOps está cambiando a estrutura e o enfoque dunha empresa para organizar o seu proceso de traballo.
detrás das cámaras
É importante para nós saber non só o que están a facer as diferentes empresas no marco do enfoque DevOps, senón tamén comprender por que se fai todo isto. Polo tanto, invitamos non só expertos a unirse ao Comité do Programa, senón tamén especialistas que ven o discurso de DevOps desde diferentes posicións:
- enxeñeiros superiores;
- desenvolvedores;
- xefes de equipo;
- CTO.
Por unha banda, isto xera dificultades e conflitos á hora de discutir as solicitudes de informes. Se un enxeñeiro está interesado en analizar un accidente importante, é máis importante que un programador comprenda como crear software que funcione en nubes e infraestruturas. Pero ao poñernos de acordo, creamos un programa que será valioso e interesante para todos: desde enxeñeiros ata CTO.
O obxectivo da nosa conferencia non é só seleccionar os informes máis exagerados, senón presentar a imaxe xeral: como funciona o enfoque DevOps na práctica, con que tipo de rake podes atopar ao pasar a novos procesos. Ao mesmo tempo, construímos a parte de contido, baixando do problema empresarial a tecnoloxías específicas.
As seccións da conferencia seguirán sendo as mesmas que en .
- Plataforma de infraestruturas.
- Infraestrutura como código.
- Entrega continua.
- Comentarios.
- Arquitectura en DevOps, DevOps para CTO.
- Prácticas de SRE.
- Formación e xestión do coñecemento.
- Seguridade, DevSecOps.
- Transformación DevOps.
Call for Papers: que tipo de informes buscamos
Dividimos condicionalmente o público potencial da conferencia en cinco grupos: enxeñeiros, desenvolvedores, especialistas en seguridade, xefes de equipo e CTO. Cada grupo ten a súa propia motivación para acudir á conferencia. E, se miras a DevOps desde estas posicións, podes entender como enfocar o teu tema e onde poñer énfase.
Para enxeñeiros, que están a crear unha plataforma de infraestrutura, é importante comprender as tendencias existentes, comprender que tecnoloxías son agora as máis avanzadas. Estarán interesados en coñecer experiencias da vida real no uso destas tecnoloxías e en intercambiar opinións. Un enxeñeiro estará encantado de escoitar un informe que analice algún accidente grave e nós, á súa vez, tentaremos seleccionar e pulir ese informe.
Para desenvolvedores é importante entender tal concepto como aplicación nativa na nube. É dicir, como desenvolver software para que funcione en nubes e diversas infraestruturas. O programador debe recibir constantemente comentarios do software. Aquí queremos escoitar casos sobre como as empresas constrúen este proceso, como supervisar o rendemento do software e como funciona todo o proceso de entrega.
Especialistas en ciberseguridade É importante entender como configurar o proceso de seguridade para que non se parase os procesos de desenvolvemento e cambio dentro da empresa. Tamén serán interesantes os temas sobre os requisitos que DevOps impón a estes especialistas.
Os líderes do equipo queren saber, como funciona o proceso de entrega continua noutras empresas. Que camiño tomaron as empresas para logralo, como construíron procesos de desenvolvemento e garantía de calidade dentro de DevOps. Os xefes de equipo tamén están interesados no nativo da nube. E tamén preguntas sobre a interacción dentro do equipo e entre os equipos de desenvolvemento e enxeñería.
Para CTO o máis importante é descubrir como conectar todos estes procesos e axustalos ás necesidades empresariais. Asegúrese de que a aplicación sexa fiable tanto para a empresa como para o cliente. E aquí cómpre comprender que tecnoloxías funcionarán para que tarefas empresariais, como construír todo o proceso, etc. O CTO tamén é responsable do orzamento. Por exemplo, debe comprender canto diñeiro hai que gastar en reciclar especialistas para que poidan traballar en DevOps.
Se tes algo que dicir sobre estes asuntos, non te quedes calado, . O prazo para a convocatoria de traballos remata o 20 de agosto. Canto antes te rexistres, máis tempo terás para finalizar o teu informe e preparar a túa presentación. Entón, non te demores.
Ben, se non tes necesidade de falar publicamente, só e achégate o 30 de setembro e o 1 de outubro para comunicarte cos compañeiros. Prometemos que será interesante e inspirador.
Como vemos DevOps
Para entender exactamente o que queremos dicir con DevOps, recomendo ler (ou reler) o meu informe "" Paseando polas ondas do mercado, observei como a idea de DevOps íase transformando en empresas de diferentes tamaños: desde unha pequena startup ata empresas multinacionais. O informe está construído sobre unha serie de preguntas, ao responder a elas, podes entender se a túa empresa está avanzando cara a DevOps ou se hai problemas nalgún lugar.
DevOps é un sistema complexo, debe incluír:
- Produto dixital.
- Módulos empresariais que desenvolven este produto dixital.
- Equipos de produto que escriben código.
- Prácticas de entrega continua.
- Plataformas como servizo.
- Infraestrutura como servizo.
- Infraestrutura como código.
- Prácticas separadas para manter a fiabilidade, integradas en DevOps.
- Unha práctica de feedback que o describe todo.
Ao final do informe hai un diagrama que dá unha idea do sistema DevOps na empresa. Permitirache ver que procesos na túa empresa xa se simplificaron e cales aínda están por construír.
Podes ver o vídeo da reportaxe .
E agora haberá un extra: varios vídeos de RIT++ 2019, que abordan os problemas máis xerais da transformación de DevOps.
Infraestrutura da empresa como produto
Artyom Naumenko dirixe o equipo DevOps en Skyeng e encárgase do desenvolvemento da infraestrutura da súa empresa. Contou como a infraestrutura afecta aos procesos comerciais en SkyEng: como calcular o ROI para iso, que métricas se deben escoller para o cálculo e como traballar para melloralas.
No camiño dos microservizos
A empresa Nixys ofrece soporte para proxectos web ocupados e sistemas distribuídos. O seu director técnico, Boris Ershov, contou como traducir produtos de software, cuxo desenvolvemento comezou hai 5 anos (ou incluso máis), a unha plataforma moderna.
Como regra xeral, estes proxectos son un mundo especial onde hai recunchos tan escuros e antigos da infraestrutura que os enxeñeiros actuais non coñecen deles. E os enfoques de arquitectura e desenvolvemento que antes se escolleron están desactualizados e non poden proporcionar á empresa o mesmo ritmo de desenvolvemento e lanzamento de novas versións. Como resultado, cada lanzamento de produto convértese nunha aventura incrible, onde algo se cae constantemente e no lugar máis inesperado.
Os xestores deste tipo de proxectos enfróntanse inevitablemente á necesidade de transformar todos os procesos tecnolóxicos. No seu informe, Boris dixo:
- como elixir a arquitectura adecuada para o proxecto e poñer en orde a infraestrutura;
- que ferramentas utilizar e que trampas se atopan no camiño da transformación;
- que facer a continuación.
Automatización de lanzamentos ou como entregar de forma rápida e sen dor
Alexander Korotkov é un dos principais desenvolvedores do sistema CI/CD en CIAN. Falou de ferramentas de automatización que permitiron mellorar a calidade e reducir 5 veces o tempo de entrega do código á produción. Pero tales resultados non se poderían conseguir só coa automatización, polo que Alexander tamén prestou atención aos cambios nos procesos de desenvolvemento.
Como che axudan a aprender os accidentes?
Alexey Kirpichnikov leva 5 anos implementando DevOps e infraestrutura en SKB Kontur. Ao longo de tres anos, aproximadamente 1000 fakaps de diversos graos de épico ocorreron na súa compañía. Entre eles, por exemplo, o 36 % foron causados polo lanzamento dunha versión de baixa calidade na produción e o 14 % foron causados por traballos de mantemento de hardware no centro de datos.
Un arquivo de informes (post mortems) que os enxeñeiros da empresa levan mantendo durante varios anos seguidos permite obter información tan precisa sobre os accidentes. A autopsia está redactada polo enxeñeiro de garda, que foi o primeiro en responder ao sinal de emerxencia e comezou a arranxar todo. Por que atormentar aos enxeñeiros que loitan pola noite cos facaps escribindo informes? Estes datos permítenche ver a imaxe completa e mover o desenvolvemento da infraestrutura na dirección correcta.
No seu discurso, Alexey compartiu como escribir unha autopsia realmente útil e como implementar a práctica deste tipo de informes nunha gran empresa. Se che gustan as historias de como alguén se meteu a pata, mira o vídeo da actuación.
Entendemos que a túa visión de DevOps pode non coincidir coa nosa. Será interesante saber como ves a transformación de DevOps. Comparte a túa experiencia e visión deste tema nos comentarios.
Que informes xa aceptamos no programa?
Esta semana o Comité do Programa adoptou 4 informes: sobre seguridade, infraestruturas e prácticas de SRE.
Quizais o tema máis doloroso da transformación de DevOps: como asegurarse de que os mozos do departamento de seguridade da información non destrúan as conexións xa construídas entre desenvolvemento, operación e administración. Algunhas empresas xestionan sen un departamento de seguridade da información. Como garantir a seguridade da información neste caso? Sobre iso Mona Arkhipova de sudo.su. Do seu informe aprendemos:
- que hai que protexer e de quen;
- cales son os procesos de seguridade rutineiros;
- como se cruzan os procesos de TI e de seguridade da información;
- que é CIS CSC e como implementalo;
- como e con que indicadores realizar controis regulares de seguridade da información.
O seguinte informe refírese ao desenvolvemento da infraestrutura como código. Reducir a cantidade de rutina manual e non converter todo o proxecto nun caos, é isto posible? A esta pregunta Maxim Kostrikin de Ixtens. A súa empresa usa Terraform para traballar coa infraestrutura de AWS. A ferramenta é conveniente, pero a pregunta é como evitar crear un bloque enorme de código ao usalo. O mantemento deste legado será cada vez máis caro cada ano.
Maxim mostrará como funcionan os patróns de colocación de código, destinados a simplificar a automatización e o desenvolvemento.
Un máis escoitaremos falar das infraestruturas Vladimir Ryabov de Playkey. Aquí falaremos da plataforma de infraestruturas, e aprenderemos:
- como entender se o espazo de almacenamento se está a utilizar de forma eficaz;
- como varios centos de usuarios poden recibir 10 TB de contido se só se usan 20 TB de almacenamento;
- como comprimir datos 5 veces e proporcionalos aos usuarios en tempo real;
- como sincronizar datos sobre a marcha entre varios centros de datos;
- como eliminar calquera influencia dos usuarios uns sobre os outros cando se usa unha máquina virtual de forma secuencial.
O segredo desta maxia é a tecnoloxía ZFS para FreeBSD e o seu garfo fresco ZFS en Linux. Vladimir compartirá casos de Playkey.
Matvey Kukuy de Amixr.IO preparado con exemplos da vida , que pasou SRE e como axuda a construír sistemas fiables. Amixr.IO pasa os incidentes dos clientes a través do seu backend; decenas de equipos de garda en todo o mundo xa trataron 150 mil casos. Na conferencia, Matvey compartirá as estatísticas e os coñecementos que a súa empresa acumulou resolvendo os problemas dos clientes e analizando os fallos.
Unha vez máis exhorto a que non sexas codicioso e compartas a túa experiencia como samurai de DevOps. Atender para un informe, e ti e mais eu teremos 2,5 meses para preparar un excelente discurso. Se queres ser oínte, ao boletín con actualizacións do programa e pensa seriamente en reservar entradas con antelación, porque se encarecerán máis preto das datas da conferencia.
Fonte: www.habr.com