Conferencia para fanáticos de DevOps

Esto, por supuesto, se trata de DevOpsConf . Si no entra en detalles, el 30 de septiembre y el 1 de octubre celebraremos una conferencia sobre la unificación de los procesos de desarrollo, prueba y operación, y si entra en detalles, le pido un gato.

Dentro del marco del enfoque DevOps, todas las partes del desarrollo tecnológico del proyecto están entrelazadas, ocurren en paralelo y se afectan entre sí. De particular importancia aquí es la creación de procesos de desarrollo automatizados que se pueden cambiar, simular y probar en tiempo real. Esto ayuda a responder instantáneamente a los cambios en el mercado.

En la conferencia, queremos mostrar cómo este enfoque afecta el desarrollo de productos. Cómo es la fiabilidad y adaptabilidad del sistema para el cliente. Cómo DevOps cambia la estructura y el enfoque de la empresa a la organización del flujo de trabajo.

Entre bastidores

Es importante para nosotros saber no solo qué están haciendo las diferentes compañías como parte del enfoque de DevOps, sino también entender por qué esto es todo. Por lo tanto, invitamos no solo a expertos al Comité del Programa, sino a expertos que ven el discurso de DevOps desde diferentes perspectivas:

• ingenieros superiores;
• desarrolladores
• timlides;
• CTO

Por un lado, esto crea dificultades y conflictos al analizar las solicitudes de informes. Si un ingeniero está interesado en analizar un accidente mayor, entonces es más importante que el desarrollador comprenda cómo crear software que funcione en las nubes e infraestructuras. Pero al aceptar, creamos un programa que será valioso e interesante para todos: desde ingenieros hasta CTO.



La tarea de nuestra conferencia no es solo seleccionar informes más de alta tecnología, sino presentar el panorama general: cómo funciona el enfoque DevOps en la práctica, qué tipo de comisión puede encontrar al pasar a nuevos procesos. Al mismo tiempo, creamos la parte de contenido, pasando de la tarea empresarial a tecnologías específicas.

Las secciones de la conferencia permanecerán igual que la última vez .

• Plataforma de infraestructura.
• Infraestructura como código.
• Entrega continua
• Comentarios
• Arquitectura en DevOps, DevOps para CTO.
• Prácticas SRE.
• Formación y gestión del conocimiento.
• Seguridad, DevSecOps.
• Transformación de DevOps.

Call for Papers: qué informes estamos buscando

Dividimos condicionalmente la audiencia potencial de la conferencia en cinco grupos: ingenieros, desarrolladores, especialistas en seguridad, líderes de equipo y CTO. Cada grupo tiene su propia motivación para asistir a la conferencia. Y, si observa DevOps desde estas posiciones, puede comprender cómo enfocar su tema y dónde poner énfasis.

Para los ingenieros que están creando una plataforma de infraestructura, es importante comprender las tendencias existentes, comprender qué tecnologías son las más avanzadas ahora. Estarán interesados ​​en familiarizarse con la experiencia real de usar estas tecnologías e intercambiar puntos de vista. Un ingeniero escuchará con gusto un informe con un análisis de algún accidente grave, nosotros, a su vez, intentaremos recoger y pulir dicho informe.

Para los desarrolladores, es importante comprender un concepto como la aplicación nativa de la nube . Es decir, cómo desarrollar software para que funcione en las nubes y diversas infraestructuras. El desarrollador necesita recibir constantemente comentarios del software. Aquí queremos escuchar casos sobre cómo las empresas construyen este proceso, cómo monitorear el rendimiento del software y cómo funciona todo el proceso de entrega.

Es importante que los profesionales de ciberseguridad comprendan cómo configurar el proceso de seguridad para que no detenga los procesos de desarrollo y los cambios dentro de la empresa. Los temas sobre los requisitos que DevOps establece para tales especialistas serán interesantes.

Los Timlids quieren saber cómo funciona el proceso de entrega continua en otras compañías. De qué manera la empresa hizo esto, cómo se desarrollaron los procesos de desarrollo y la garantía de calidad dentro de DevOps. Los compañeros de equipo nativos de Cloud también son interesantes. Y también: preguntas sobre la interacción dentro del equipo y entre equipos de desarrolladores e ingenieros.

Para el CTO, lo más importante es descubrir cómo combinar todos estos procesos y ajustarlos a las necesidades del negocio. Se asegura de que la aplicación sea confiable tanto para el negocio como para el cliente. Y aquí debe comprender qué tecnologías funcionarán bajo qué tareas comerciales, cómo construir todo el proceso, etc. CTO también es responsable del presupuesto. Por ejemplo, debe comprender cuánto dinero necesita gastar en especialistas en reciclaje para que puedan trabajar en DevOps.



Si tiene algo que decir en estas ocasiones, no guarde silencio; presente un informe . La fecha límite para la convocatoria es el 20 de agosto. Cuanto antes se presente, más tiempo tendrá para finalizar el informe y prepararse para la presentación. Por lo tanto, no apriete.

Bueno, si no necesita hablar en público, simplemente compre un boleto y venga el 30 de septiembre y el 1 de octubre para conversar con sus colegas. Prometemos que será interesante e inspirador.

Como vemos DevOps

Para entender exactamente lo que queremos decir con DevOps, recomiendo leer (o releer) mi charla " ¿Qué es DevOps "? Caminando por las olas del mercado, observé cómo la idea de DevOps se está transformando en empresas de diferentes tamaños: desde una pequeña startup hasta compañías multinacionales. El informe se basa en una serie de preguntas, respondiéndolas, puede comprender si su empresa se está mudando a DevOps o si hay problemas en alguna parte.

DevOps es un sistema complejo, debería tener:

• Producto digital.
• Los módulos de negocio que este producto digital está desarrollando.
• Equipos de productos que escriben código.
• Prácticas de entrega continua.
• Plataformas como servicio.
• Infraestructura como servicio.
• Infraestructura como código.
• Prácticas de confiabilidad separadas conectadas dentro de DevOps.
• Práctica de retroalimentación que describe todo esto.

Al final del informe hay un esquema que da una idea del sistema DevOps en la empresa. Le permitirá ver qué procesos de su empresa ya están depurados y cuáles solo deben construirse.



Puedes ver el video aquí .

Y ahora habrá una bonificación: varios videos de RIT ++ 2019 que se relacionan con los problemas más comunes de la transformación DevOps.

Infraestructura de la empresa como producto

Artyom Naumenko dirige el equipo DevOps en Skyeng y se encarga del desarrollo de la infraestructura de su empresa. Explicó cómo la infraestructura afecta los procesos de negocios en SkyEng: cómo calcular el ROI para ello, qué métricas deberían elegirse para el cálculo y cómo trabajar para mejorarlas.

En camino a microservicios

Nixys se compromete a apoyar proyectos web ocupados y sistemas distribuidos. Su director técnico, Boris Ershov, dijo cómo transferir productos de software, cuyo desarrollo comenzó hace unos 5 años (o incluso más), a los rieles modernos.



Como regla general, tales proyectos son un mundo especial donde hay rincones tan oscuros y antiguos de la infraestructura que los ingenieros actuales no saben sobre ellos. Y los enfoques de arquitectura y desarrollo una vez seleccionados están desactualizados y no pueden proporcionar a las empresas el mismo ritmo de desarrollo y lanzamiento de nuevas versiones. Como resultado, cada lanzamiento del producto se convierte en una aventura increíble donde algo se cae constantemente y en el lugar más inesperado.

Los gerentes de tales proyectos inevitablemente enfrentan la necesidad de transformar todos los procesos tecnológicos. En su informe, Boris dijo:

• Cómo elegir la arquitectura adecuada para el proyecto y ordenar la infraestructura;
• qué herramientas utilizar y qué dificultades se encuentran en el camino hacia la transformación;
• Qué hacer a continuación.

Libere la automatización o cómo entregar rápidamente y sin dolor

Alexander Korotkov es un desarrollador líder del sistema CI / CD en CIAN. Habló sobre las herramientas de automatización que mejoraron la calidad y redujeron el tiempo de entrega de código en producción en 5 veces. Pero tales resultados no podrían haberse logrado con una sola automatización, por lo que Alexander llamó la atención sobre los cambios en los procesos de desarrollo.

¿Cómo te ayudan a aprender los accidentes?

Alexey Kirpichnikov ha estado implementando DevOps e infraestructura en SKB Kontur durante 5 años. Durante tres años, ocurrieron alrededor de 1,000 fakaps de diversos grados de epopeya en su compañía. Entre ellos, por ejemplo, el 36% se debió al lanzamiento de una versión de baja calidad en la producción, y el 14% se debió al trabajo de mantenimiento de hierro en el centro de datos.

La obtención de información tan precisa sobre accidentes permite el archivo de informes (post mortem), que los ingenieros de la compañía han estado realizando durante varios años seguidos. Postmortem escribe al ingeniero de turno, quien fue el primero en responder a la señal sobre el accidente y comenzó a reparar todo. ¿Por qué torturar a los ingenieros que luchan fakaps por la noche, escribiendo informes? Estos datos le permiten ver la imagen completa y mover el desarrollo de la infraestructura en la dirección correcta.

En su discurso, Alexey compartió cómo escribir una autopsia realmente útil y cómo implementar la práctica de tales informes en una gran empresa. Si te encantan las historias sobre cómo alguien se equivocó, mira un video de la actuación.



Entendemos que su visión de DevOps puede no coincidir con nuestros puntos de vista. Será interesante saber cómo ve la transformación de DevOps. Comparta sus experiencias y visiones sobre este tema en los comentarios.

¿Qué informes ya hemos aceptado en el programa?

Esta semana, el Comité del Programa adoptó 4 informes: sobre seguridad, infraestructura y prácticas de SRE.

Quizás el tema más doloroso de la transformación DevOps: cómo asegurarse de que los chicos del departamento de seguridad de la información no arruinen las conexiones ya construidas entre desarrollo, operación y administración. Algunas compañías no tienen un departamento de seguridad de la información . ¿Cómo, entonces, garantizar la seguridad de la información? Esto le dirá a Mona Arkhipova de sudo.su. De su informe aprendemos:

• qué y de quién es necesario proteger;
• ¿Cuáles son los procesos de seguridad de rutina?
• Cómo se cruzan los procesos de TI y SI
• qué es CIS CSC y cómo implementarlo;
• cómo y por qué indicadores realizar controles regulares de SI.

El siguiente informe aborda el desarrollo de la infraestructura como código. Reduzca la cantidad de rutina manual y no convierta todo el proyecto en caos, ¿es esto posible? Maxim Kostrikin de Ixtens responderá esta pregunta. Sus compañías usan Terraform para trabajar con la infraestructura de AWS. La herramienta es conveniente, pero la pregunta es cómo usarla para evitar la aparición de una gran cantidad de código. El mantenimiento de este patrimonio costará más y más cada año.

Maxim mostrará cómo los patrones de colocación de código apuntan a simplificar la automatización y el trabajo de desarrollo.

Escucharemos otro informe sobre infraestructura de Vladimir Ryabov de Playkey . Aquí hablaremos sobre la plataforma de infraestructura y aprenderemos:

• cómo entender si la capacidad de almacenamiento se usa de manera eficiente;
• cuántos cientos de usuarios pueden recibir 10 TB de contenido si solo se usan 20 TB de almacenamiento;
• cómo comprimir datos 5 veces y proporcionarlos a los usuarios en tiempo real;
• cómo sobre la marcha sincronizar datos entre varios centros de datos;
• cómo excluir cualquier influencia de los usuarios entre sí en el uso secuencial de una máquina virtual.

El secreto de esta magia está en la tecnología ZFS para FreeBSD y su última bifurcación de ZFS en Linux . Vladimir compartirá casos de Playkey.

Matvey Kukuy de Amixr.IO está listo para decir con ejemplos de la vida qué es SRE y cómo ayuda a construir sistemas confiables. Amixr.IO pasa los incidentes de los clientes a través de su backend, docenas de equipos de servicio en todo el mundo ya han resuelto 150 mil casos. En la conferencia, Matvey compartirá estadísticas e ideas que su compañía ha acumulado, resolviendo problemas de clientes y analizando fakapy.

Una vez más, le insto a que no sea codicioso y comparta su experiencia con DevOps-samurai. Solicite el informe y tendremos 2.5 meses para preparar una excelente presentación. Si quiere ser un oyente, suscríbase al boletín con las actualizaciones del programa y piense seriamente en la reserva anticipada de boletos, ya que aumentarán su precio más cerca de las fechas de la conferencia.