Los equipos de desarrollo pueden estar débilmente acoplados y trabajar en diferentes direcciones, sin saber y sin querer usar DevOps. En el artículo de hoy, hablaremos sobre cómo las prácticas de DevOps pueden distorsionarse y transformarse para que puedan implementarse en empresas con regulaciones, políticas y hábitos de las personas establecidos desde hace mucho tiempo.



El material se basa en un informe de diálogo de Sergey Berdnikov (Golden Crown) y Artem Kalichkin (CFT) de la conferencia DevOops 2017 de octubre. Debajo del corte: transcripción de video y texto del informe.




Sergey: Soy el jefe del departamento de operaciones de nuestra empresa. Artem y yo comenzamos una pequeña revolución-evolución. Todo comenzó con la revolución, ahora ha pasado a la etapa de evolución.



Artem: La compañía ha estado operando en el mercado financiero desde 1992. El trabajo consta de dos partes principales. La primera parte es el desarrollo de software, Core Banking, contabilidad bancaria, etc. Aquí actuamos como proveedor: desarrollamos y le vendimos una caja, y usted la implementó y la operó.

La segunda parte es el procesamiento de servicios. Aquí brindamos servicios directamente a individuos o a través de nuestros socios. Estas son grandes redes comerciales, bancos y otros participantes en el mercado de servicios financieros. Aquí trabajamos el ciclo completo desde la idea hasta el desarrollo, implementación y operación adicional.

Trabajamos con Sergey en la parte de procesamiento de nuestra empresa. Sobre cómo llegamos a la historia con DevOps en este procesamiento, lo diremos.

Que fue

Sergey: Nuestro legado fue completamente bancario. La compañía inicialmente hizo productos bancarios, respectivamente, todo era familiar: toda la infraestructura de SPARC solamente, sus propios centros de datos, todo el núcleo estaba escrito en Oracle. Código PL / SQL, muchas cosas, no es fácil de escalar.

Escalamos solo verticalmente: compramos una poderosa pieza de hierro, la usamos hasta que se volvió obsoleta, la reemplazamos por una nueva y la antigua fue puesta en escena.

También escribió mucho código en Java. Reservamos a través de una reserva cálida: hay un centro de datos y toda la estructura copiada: conmutadores, servidores, todo en uno, perno a perno.



Aquí puede ver cómo se veía toda la estructura desde el punto de vista de los procesos. Había direcciones técnicas independientes Dev, luego Firewalls con fuego. El siguiente fue la TI centralizada, que participó en la eliminación, implementación, etc. Es decir, los desarrolladores escribieron una gran instrucción, y las operaciones de TI se dividieron en tres divisiones:

• Administradores aplicados que participaron en una implementación. No tenían una raíz, había usuarios en las máquinas, podían ejecutar instrucciones, esto se llama código de mono.
• Administradores de Unix que podían y sabían cómo configurar, agregar hardware, etc.
• Había especialistas en bases de datos individuales. Y dado que las bases de datos son el objetivo principal para nosotros, la esencia de nuestra existencia durante mucho tiempo, muchos procesos tuvieron lugar allí.

Artem: DevOps aún no está aquí en esta etapa, trabajamos de acuerdo con las regulaciones, con lo que Sergey no estaba contento.

Sergey: Me uní al equipo de administradores aplicados y recuerdo lo que fueron los "buenos tiempos". Podríamos hacer una solicitud por tres semanas. Entra una aplicación, encontraron algún tipo de error y la cancelaron, creyendo que los tontos no podían escribir aplicaciones. Y el conocimiento que era necesario para la correcta redacción de la solicitud estaba conmigo.

Entonces la gente vino corriendo en un día: "¿Y qué escribimos incorrectamente?" Le expliqué que en algún lugar donde no pusieron un signo más o menos, olvidaron una coma. Escriben una aplicación, les doy algún tipo de experiencia sobre cómo trabajar en Oracle y la envío al DBA, donde se sientan personas especialmente capacitadas que saben cómo cumplir con estas aplicaciones.

Y también trabajan conmigo, dicen: "¿Por qué no indicaste el indicador principal aquí, no escribiste un punto y coma?" La aplicación se cancela, el ciclo comienza de nuevo. Ahora, qué pena, pero qué hacer, antes de trabajar de esta manera.

Artem: Entonces comenzamos a cambiar. Realmente hubo muchas aplicaciones. Cuando Sergey se unió a nuestro equipo, fue el resultado de una pequeña evolución y transformación. Fui autor de una gran cantidad de regulaciones para varios tipos de aplicaciones, porque de alguna manera tuve que sobrevivir. En general, toda nuestra transformación tuvo lugar no por exageración o moda, sino por la necesidad de resolver problemas específicos.

Por ejemplo, los cambios de configuración conducen al hecho de que mi combate se rompió y no funcionó correctamente. Me enteré de esto en un día o en la noche: sucedió que a las seis de la tarde rodaron algo, y hasta las tres de la mañana todo esto funcionó incorrectamente.

Hubo instalaciones de la versión antes de las cuales nadie iba y no discutieron qué hacer si algo sale mal. Las famosas famosas instrucciones de instalación de varias páginas se transmitieron a todos, literalmente, media hora antes del comienzo del trabajo en funcionamiento. Era necesario resolver algo, y en ese momento encontramos una solución: implementación adaptativa de los procesos ITIL.

Comenzamos a verificar si todo salió correctamente después del lanzamiento al combate, si el servicio y los principales indicadores clave funcionan normalmente. Comenzamos a salir antes de instalar las versiones. Y luego, de hecho, fue el comienzo de DevOps, cuando el equipo de desarrollo, que transmite el kit de distribución, comenzó al menos a reunirse con el equipo de operaciones, discutiendo lo que sucedería en el trabajo nocturno.

Sergey: Y había algo que discutir: teníamos cuatro páginas de instrucciones de instalación: ejecutar un comando, ejecutar un plan. Era casi imposible escribir sin errores. Juramos constantemente entre el desarrollo que escribimos incorrectamente, lo leímos, y cosas así. Las reuniones a veces se convirtieron en un infierno.

Artem: Intentamos movernos con las aplicaciones a Confluence, ya que es inconveniente transmitir en Word; era posible formar algo incorrecto. En Confluence, siempre planearon cargar la versión actual con todos los cambios.

Insertamos una pieza de código para rodar en combate. La confluencia masticó el marcado de meta, emitió algo más incorrecto, el administrador tomó el código, que se convirtió en fideos y comenzó a trabajar con él, fue un desastre.

Nos dimos cuenta de que no importaba cuán pervertido con la instrucción de la página, todo esto se convertía en una completa tontería, sin importar cómo se enmarcara.

Hubo requisitos previos importantes para el tiempo de inactividad prolongado en el trabajo nocturno, lo que condujo a un despegue deficiente después de la instalación, a las jambas y a una gran cantidad de conflictos entre el desarrollo y la operación.

• Muchos errores humanos en la transmisión de cambios;
• Búsqueda constante de los culpables;
• La tasa de eliminación de nuevos módulos hasta 3 semanas;
• Puntos únicos de falla (solo escala vertical), falta de equilibrio;
• Tiempo de inactividad planificado durante las actualizaciones durante 2 horas.

Fondo de transformación

Sergey: Hubo muchos cambios, constantemente nos equivocamos. Todas las semanas nos reuníamos, maldecíamos, nos calmamos. Este proceso se repitió para siempre, buscaron al culpable: "Todos estos son desarrolladores que escriben código curvo, incluso el módulo Java no se puede transmitir".

Artem: Y los desarrolladores pensaron que se trataba de cosas elementales: se produjo un error en los registros: resuélvelo, búscalo en Google y comprende lo que hay que arreglar en las configuraciones.

Sergey: También lanzaron nuevos productos durante mucho tiempo. Esto solo está relacionado estructuralmente: crearon una solicitud para nosotros, tuvimos que crear una solicitud para crear un usuario en el servidor y luego crear un esquema. Entonces el fútbol comenzó con las aplicaciones. Los desarrolladores emitieron módulos, pero no podemos usarlos, tenemos todo de acuerdo con las regulaciones.

Además, establecemos durante mucho tiempo. La instrucción es enorme, mientras lees, mientras lo haces, el carrete tomó alrededor de dos horas. Las acciones en sí mismas no se completaron en un segundo.

Artem: También hubo acciones de rutina, por ejemplo, 30 módulos Java. En total hay una configuración, en cada configuración necesitas entrar y hacer cambios. Primero, puedes volverte loco para hacer el mismo cambio: te odias a ti mismo y al resto de la humanidad. En segundo lugar, la probabilidad de cometer un error en la configuración 25 se vuelve extremadamente alta.

Sergey: Recuerdo cómo recibí una oferta para escalar horizontalmente. Y tenemos 150 módulos con diferentes configuraciones: si el error está en una versión de la configuración, me pondrán una segunda y cometeré un error. No somos robots, después de todo.

Artem: El tiempo de inactividad programado de 2 horas de tiempo de actualización es uno de los factores críticos de por qué comenzamos a buscar una solución, cómo escaparnos de ella.

El hecho es que brindamos servicios financieros, servicios de procesamiento. Trabajamos en paises extranjeros. Luego trabajamos en 11 zonas horarias, en 2013 solo teníamos una hora de ventana, cuando el uso del servicio era mínimo, la cantidad de llamadas de los clientes se minimizaba, llegaba la calma y se podía hacer algo.

Condicionalmente, podríamos realizar el trabajo de una hora a dos de la noche. Dos horas es mucho más que esta ventana. Nos estábamos acercando a un desastre, si no fuera por la transformación, porque ahora físicamente no tenemos ventanas.

La respuesta a todos estos problemas se me ocurrió, un intento de averiguar qué es DevOps.

En ese momento, nuestro colega vino con HighLoad, estaba ocupado con la implementación de CMBD, porque necesitaba que las configuraciones no se rompieran y al menos pudiera administrar algo. Escuchó el informe de Sasha Titov, quien habló sobre algún chef. Parece ser también la gestión de la configuración

En 2013, leí todo al respecto, decidí que algo de basura no era lo que necesitaba. Necesito controlar, y obligan al código a escribir allí. Sin embargo, la situación no cambió, los problemas se acumularon y me obligué a sentarme en casa y comenzar a resolver las cosas. Pensé que había algo en esto, algún tipo de salvación.

Y luego descubrí los postulados y valores de que deberíamos tener el mismo entorno, el mismo script de implementación y actualización, que deberíamos verificar estos escenarios, comenzando con el entorno de prueba.

Hubo una oportunidad para minimizar las instrucciones y acciones manuales, y para automatizar todo lo más posible, no solo con scripts de bash dispares, en los que otro administrador se rompería la pierna más tarde.

Fue entonces cuando se me ocurrió esta idea, con la primera declaración de lo que quiero recibir. Este es el documento de 2013, el primero creado en la compañía sobre DevOps.

Sergey: Aquí hay una idea clave: reducir la velocidad de eliminación de nuevos módulos, reducir la cantidad de errores durante la eliminación a la batalla. Es decir, había objetivos específicos que queríamos lograr en la primera etapa del lanzamiento de nuevos lanzamientos.



Hubo muchos argumentos en contra. Por ejemplo, el temor a que la automatización lo rompa todo: funciona de manera incomprensible, da miedo ejecutar el código de otra persona, es un gran servicio, la gente recibe dinero a través de nosotros. No es serio

El siguiente en unirse a los guardias. Nos atravesaron por completo: ¡una especie de escenario idéntico! Y tienen una imagen perfecta del mundo: en la unidad flash, transfiera las versiones, las firmaremos con una clave PGP, y todo estará bien: el servicio perfecto. Trabajamos con ellos durante tanto tiempo para llegar al final, solo gracias a las actividades del proyecto hicimos algo.

Artem: Aquí procedemos de los valores: aquí es donde perdemos dinero, este simple es inaceptable.

Los muchachos y yo encontramos una manera de minimizar estas pérdidas. ¿Tienes una mejor opción? Si no, quédese callado; si es así, critique y ofrezca. ¿Nada que ofrecer? Entonces lo intentamos.

Hubo un proceso de persuasión y forzamiento: sugerimos usar nuestras ideas en un número limitado de sistemas.

Sergey: Nos pidieron que escribiéramos todos los riesgos, cómo lo liberaremos. Era necesario coordinarse con personas que podían perder dinero. Además, los programadores dijeron: "¡Escribimos algún tipo de código, solíamos transmitir código postal normalmente, escribimos instrucciones, y algún otro tipo de código para escribir para eliminarlo!"

Artem: “Escribo código de aplicación de lógica de negocios, uso marcos para minimizar cualquier parte innecesaria del código. Y pides más código para escribir. Tomar y sacar, al final "- tales diálogos fueron al principio. Sin embargo, todo esto gradualmente funcionó a través de demostraciones y creencias.



Sergey: En las primeras iteraciones, tomamos muchas decisiones importantes en términos de la estructura de nuestra empresa y en términos de tecnología. En primer lugar, implementamos la gestión de la configuración. Esto nos ahorró la molestia de sacar la configuración incorrecta con una instrucción de 10 páginas A4.

Luego, las operaciones comenzaron a hundirse y los administradores de aplicaciones se trasladaron a la dirección técnica con los desarrolladores. Daba una sensación de mando, una sensación de codo. Comenzamos a comprender que estábamos haciendo un producto y no cumplíamos aplicaciones incomprensibles con el deseo de rechazarlos; había objetivos específicos.

El trabajo en equipo se une cuando te sientas al lado de las personas, cuando ves cómo funcionan, cuando ven cómo trabajamos nosotros. Incluso tuvimos un diálogo entre los equipos: esta es la primera chispa de DevOps reales. No había tecnología, no alguna tecnología nueva. Desde el punto de vista de la tecnología, pensamos que nada echaría raíces en absoluto, trabajamos de manera diferente en otro mundo.

La primera idea es escribir Configuration Management nosotros mismos, hay muchos desarrolladores. Luego recordamos todo lo que escribimos nosotros mismos y nos negamos: todos fallamos.

Artem: Voy a corregir a mi colega. Sergey está equivocado: todo lo que escribimos nosotros mismos funcionó perfectamente en nuestro campo aplicado, en el que somos fuertes. Y cuando intentaron escribir algunas de sus arañas para construir automáticamente CMDB o algún tipo de sistema de monitoreo autoescrito para controlar la lógica de negocios, sí, aquí viene un sistema de otra clase.

En esta etapa, resultó que los administradores de la aplicación pasaron del departamento de TI a nuestro departamento técnico. Como dijo Sergey, comenzaron a sentir todo el valor comercial, elemental debido a las cosas mercantiles.

Tuvimos la oportunidad de pagarles bonos de proyecto por logros, fue muy motivador. Cuando comenzaron el diálogo, la eliminación de módulos se redujo de tres semanas a una semana o más, y algunos progresos se realizaron incluso sin ninguna automatización profunda.



Sergey: En este momento, si no entendemos algo con la aplicación, le pedimos al desarrollador que aparezca: "Vamos a decidir juntos y escribir cómo debería sonar la aplicación".

Artem: Y sobre esto, condicionalmente, la estructura de comando, comenzamos a pasar a la tecnología.

Sergey: Ahora te diremos cómo elegimos el sistema. Fue lo suficientemente interesante. En primer lugar, probamos Chef, por una simple razón: conocíamos a un gurú que conoce a Chef. Luego probamos Puppet, porque en ese momento Oracle anunció soporte para Puppet.

Ansible también lo intentó, pero a ambos equipos no les gustó como sistema. También hubo problemas de seguridad: Ansible en 2013 fue muy diferente del actual.

Lanzamos dos proyectos diferentes con la misma funcionalidad en paralelo. Y todo funcionó bien, había una sensación de que algo andaba mal aquí y debería dejarse solo. ¿Cómo elegimos?

Artem: Los programadores escribieron en Chef, los administradores escribieron en Puppet. La idea era lo que intentaremos, luego compararemos dónde es mejor y elegimos. Pero cuando nos reunimos, cuando finalmente pasó el tiempo, la dualidad comenzó a crear problemas, porque el volumen de código está creciendo, continúa creciendo y a todos les gusta todo, los desarrolladores escriben y automatizan.

Reuní a todos y pregunté sobre qué escribiríamos. Los programadores dijeron: "Nos gusta mucho Chef". Y administradores: "¡Y para nosotros en Puppet!". Era una lata completa. Comparé y entendí que en el entorno actual y los parámetros actuales no hay una forma objetiva de elegir este o aquel producto.

Como resultado, hice, como les gusta decir en nuestro país, elecciones con un resultado predecible. Algún tipo de voto "cerrado" entre los participantes. Pero no hubo falsificación, hubo un efecto condicional en el cerebro, como resultado de lo cual se eligió a Puppet. Decidí que calmaría a los desarrolladores ofendidos más rápido que a los administradores ofendidos. Simplemente no había otro criterio de selección.

Sergey: En ese momento, pensamos durante mucho tiempo cómo poner binarismo. En la diapositiva puede ver una foto de nuestra junta y reunión. Decidimos que necesita utilizar algún tipo de sistema de embalaje, y no su bicicleta. Nuevamente ganó la mente.

De hecho, elegimos no RPM, sino IPS, el administrador de paquetes de Solaris. Nos importamos de la versión 11 a los diez primeros, que estaban en pie, y comenzamos a usarlo. Rehusarse a usar muletas y zip-s autoescritas en ese momento fue la decisión más correcta.

Artem: Por eso todavía era importante: en la receta, el resultado aparece en forma de un cambio en el número de versión, se extiende más y más del repositorio y se hace necesario.

Cuando vinimos a entrenar a DevOps, Chef, todas estas cosas, y pensamos: "Ahora nos dirán cómo transferir binarios", pero no nos dijeron nada al respecto. Las respuestas suelen ser: "Cada uno decide a su manera y sale como puede". Por lo tanto, se dieron cuenta de que la respuesta de la industria a esto es "42", como de "Hitchhikers 'Guide to the Galaxy", la respuesta a la pregunta principal del universo.

Sergey: También tuvimos un largo debate sobre cómo construir un CI / CD, qué es. Al igual que Configuration Management, una utilidad que tomaron y entregaron. Y aquí hay muchas opciones y opciones, argumentaron durante mucho tiempo, los desarrolladores crearon su propio sistema y, en funcionamiento, hicimos el nuestro para la eliminación.

En ese momento, nos dimos cuenta de que no había una solución perfecta. Simplemente tome todo lo que hemos ganado y aguante. Los desarrolladores tenían su propio sistema de ensamblaje, hicimos nuestra entrega nosotros mismos. No había una elección perfecta, y aún así trabajamos con diferentes equipos de diferentes maneras. No hay ideal

También tenemos una gran pila, la mayor parte de nuestro código está incrustado en la base de datos: todo el procesamiento financiero, en el cual, desafortunadamente, el paradigma es "cuanto más cerca de los datos, más rápido funciona". Oracle vende, Fowler está de acuerdo. Las transacciones financieras se bloquean en PS / SQL, no encontramos ningún producto de código abierto que ayude a resolver nuestro problema con el control de versiones y la entrega. Quizás lo era, pero comenzamos a escribir nuestro propio instrumento.

Artem: De hecho, tenemos un gran problema porque, como se mencionó en la diapositiva inicial, Production es un gran servidor vertical. En consecuencia, elevar el mismo servidor vertical grande a Stage es terriblemente costoso y muy difícil. Esto no es tan malo.

El hecho es que necesitamos crear un entorno que sea aproximadamente similar en rendimiento y llenarlo con datos que sean similares en volumen y, no menos importante, cardinalidad, para que nuestras pruebas de Etapa pasen correctamente.

Aquí fueron decisiones muy difíciles. En primer lugar, lo que hicimos en términos de escala: nos dimos cuenta de que no podíamos proporcionar los mismos vehículos verticales en el escenario que en la batalla.Pero podemos, en el momento X, corregir los indicadores de referencia de las solicitudes de rendimiento del sistema en el entorno Stage y compararlos cuando se lanzan nuevos paquetes. Si comienzan a cambiar de manera anormal, significa que algo ha flotado en nosotros y algo no está funcionando mal. Este es un problema.

Luego descubrimos un problema con la transferencia de datos de la batalla al escenario para llenarlo con la misma cantidad de datos. Es imposible que ninguna de las personas que no tienen acceso a los datos del cliente según los documentos tengan acceso a ellos.

No tenemos derecho a verter datos personales y secretos bancarios de los clientes en Stage. Para transferir estos datos, escribí scripts de ofuscación de datos para que no sean recuperables y no comparables con los reales. Al mismo tiempo, es importante que sea imposible reemplazar todos los nombres con aaa bbb, porque estamos perdiendo la cardinalidad de datos y todas nuestras comprobaciones en el escenario muestran información incorrecta.

Por lo tanto, también escribimos este script con el objetivo de generar una cardinalidad condicionalmente aleatoria de estos datos de texto para que nuestras solicitudes muestren una imagen adecuada comparable a una batalla, y podamos entender los cambios.

Nos estamos alejando de un estado absoluto de rendimiento, estamos viendo cambios. La situación no ha empeorado en comparación con la versión anterior, que, en nuestra opinión, no fue mala en el rendimiento.



Esta es la segunda iteración. Probablemente la frase clave aquí es que el proyecto terminó aquí. No hubo proyecto DevOps. Aquí originalmente era un cliente interno: yo. Obtuve mi resultado: se redujeron las instrucciones, se redujeron los errores durante el lanzamiento de la versión, la configuración de combate comenzó a cambiar, se gestionó a través de Puppet, se volvió controlada, comprensible. Lo que quería era lo que obtuve.

Sergey: Hubo cambios menores de su presentación. Una vez más, las responsabilidades fluyeron de TI centralizada a la dirección técnica.

Se convirtió en un OPS completo con una raíz. En realidad, esto ayudó a cumplir las tareas en términos de la eliminación de nuevos módulos. Comenzamos a hacer módulos más rápido, después de tres semanas, la ejecución en solo tres días nos pareció ideal. El resultado fue tangible: hubo un impulso, el equipo comenzó a generar ideas sobre cómo y cómo mejorar.



Lo que hicimos desde el punto de vista de las unidades relacionadas: tenemos un equipo de más de 200 personas, 150 desarrolladores, 6 OPS. Había muchas escoltas, guardias de seguridad. Primero: se ha dado cuenta de que es la mejor aplicación ideal que no necesita hacerse. Comenzaron a hacer esto e intentarlo: si una persona tiene la oportunidad de hacer algo sin crear una aplicación, todo el mundo está bien. Y se hace perfectamente rápido.

Artyom:Aquí hay un ejemplo, hacemos una oferta a través de git. El gerente mismo entra y hace una oferta para la batalla.

Sergey: Encontramos herramientas como Gitlab, nos gustó que una persona pueda trabajar con una interfaz gráfica. Hay un botón de "descarga", el usuario puede que ni siquiera entienda lo que hace realmente el commit.

Al mismo tiempo, hemos escrito guiones para verificar el contenido, por ejemplo, que pdf es pdf, verificar el tamaño del archivo y otra lógica de acuerdo con las reglas emitidas por el equipo de seguridad. La gente tuvo la oportunidad de actualizar estos documentos sin crear aplicaciones. La carga en operaciones ha disminuido.

Otra dificultad era cómo calcular esos momentos. En la rutina, no está claro cómo buscar áreas problemáticas. Por lo tanto, se nos ocurrió nuestra propia escala y la llamamos "chacales".

Nos inspiramos en la vieja imagen. Consideramos que asignamos a cada aplicación ejecutada el número de chacales, lo aburrido y aburrido que es y no queremos hacerlo. Al final del mes, consideraron qué aplicaciones obtuvieron más puntajes los chacales.

Se sentaron como una unidad completa y pensaron cómo deshacerse de esta desgracia. Cómo hacer que no sea necesario crear aplicaciones para esto, fue genial y atrajo a la gente.

La siguiente etapa, donde encontramos métodos de automatización, son los bots. Dominamos la API de Telegram, comenzamos a cortar bots para todos seguidos, especialmente para nosotros. Concluimos los últimos desencadenantes.



A los negocios les gustó: hay situaciones en las que algo miente, todos comienzan a llamar y preguntar qué está sucediendo. Y para que una persona pueda tomar el teléfono, seleccione el comando "incidentes" y lea los últimos incidentes. La gente comenzó a realizar incidentes con más detalle para que nadie los llamara o preguntara por ellos.

Luego comenzamos a escribir características adicionales para obtener información que solía ser consultas en Jira. La empresa quiere saber si la transferencia se completó: ingresa un número, obtiene el resultado. Esto también facilitó enormemente la vida en términos de aplicaciones.

Artyom:Al mismo tiempo, hicimos otra transformación organizacional, pero ya local, dentro del departamento de Sergey. Luego nos vimos muy infectados con la idea de un ingeniero de guardia y, gracias a Sergey, pudimos construir este esquema en el departamento. Hay un ingeniero sentado en incidentes, hay un ingeniero sentado en aplicaciones, todos los demás destruyen los chacales, se dedican a disparar.

Trabajar con DEV

Sergey: Lo que la unidad comenzó a hacer: aparecieron reordenamientos, la gente estaba involucrada no solo en chacales, sino también en otros asuntos. En primer lugar, tuvimos un diálogo con el desarrollo. Les dijimos a los nuevos equipos qué es DevOps, cómo cocinarlo correctamente, les enseñamos CM.

Recorrimos un largo camino desde que nosotros mismos les escribimos recetas, luego aprendieron a editarlas y luego escribieron por su cuenta. También hablamos sobre CI, ayudamos a configurar la tubería y recolectamos paquetes. Ayudamos a construir un entorno de desarrollo seguro.

Artem: Desde el punto de vista de CI, todo esto es muy importante. Paralelamente, actúo como productora, líder de proyectos y equipos de desarrollo de líderes. Y aquí hay un caso muy interesante.

En equipos pequeños, combinamos las funciones de operación, es decir, Stage y Prod en la misma unidad. En estos pequeños proyectos, pequeños productos, equipos e infraestructuras, esto resultó ser muy conveniente. Ves a través de cómo rodarás la batalla.

Sergey: Cuando un ingeniero de combate establece un entorno de prueba, lo hace uno a uno, sabiendo que ella vendrá a él más tarde, y él lo sufrirá. Este es un factor psicológico importante que no puede ser gratuito, es mejor hacer todo de una vez y normalmente.



¿Qué salió de eso? Aquí, muchos dicen que no hay un departamento de DevOps, creemos que tenemos un departamento de DevOps. ¿Cuáles son las principales tareas del departamento?

Él camina, promueve, habla sobre DevOps. Todos entienden qué es y cómo cocinarlo. Cuentan y muestran cómo un nuevo producto con una base de datos se puede implementar en cinco minutos.

Nuestra única limitación es la seguridad, la coordinación de los esquemas. Cuando tenemos una máquina virtual y se acuerdan los esquemas, todo lleva cinco minutos. Todo rueda completamente automáticamente.

Artem: Cuando en agosto tuve un lanzamiento de un nuevo producto en batalla, es decir, uno completamente nuevo, lanzamos 15-20 lanzamientos por día sin conflictos ni tensiones. Aquí hay una sensación de valor: es genial cuando te has sentado tranquilamente y vas a la siguiente.



Sergey:Hablaré sobre el dolor. Apoyamos el plan de recuperación DRP desde cero. Y cuando no había automatización, copiamos casi configuraciones allí. Se agregaron constantemente nuevos módulos y el plan debe actualizarse constantemente. Con la llegada de DevOps y la automatización, el plan se redujo: tomamos la última versión actual de Git y le agregamos planes.

Este plan de implementación se está volviendo honesto. Esto es compatible, entre otras cosas, con pruebas de ejecución de implementación. Hacemos pruebas, y en una carrera de combate corremos con el cambio a la reserva. Toda la historia de rutina se ha ido. Esto, por cierto, nos ayudó a mover un poco la pila.

Solíamos usar SPARC Solaris, ahora x86 apareció por una simple razón: hoy nadie escribe ni prueba las aplicaciones hipster para Sparc. Y usamos, por ejemplo, Haproxy, junto con los desarrolladores vimos correcciones de errores para Solaris. Nos molestó, no quería soportarlo más. Hemos elegido una plataforma en la que todos están probando productos, y ahora estamos trabajando en ello normalmente. Esto también nos llevó a acelerar todo el proceso.

Artem: Esto generalmente abrió la puerta a un nuevo mundo lleno de milagros. Porque la llegada de x86 nos permitió utilizar utilidades realmente relevantes y útiles para nuestras tareas. Además, cuando tuvimos esta oportunidad, simultáneamente avanzamos hacia la agrupación.

De hecho, ahora todo, excepto el procesamiento central y nuclear, está agrupado y funciona bien con nosotros. No nos preocupamos: o no hay tiempo de inactividad o lleva un máximo de un minuto, incluso donde no hay clúster.

El único lugar donde se quedó y tenía al menos dos horas fue la migración de los esquemas de procesamiento central. Ahora lleva ocho minutos.



Sergey: En la diapositiva hay un nuevo documento, una aplicación de una línea: fusionar en git. Ya no hay esas diez hojas A4.

La implementación de nuevos módulos lleva hasta tres horas. Estos son algunos casos difíciles cuando necesita hacer algo en Oracle, por ejemplo, obtener una máquina virtual. Las compensaciones desaparecieron. No recuerdo que nadie haya pasado algo mal. Por supuesto, hay algunas asperezas, pero todas son pequeñas, frívolas y se corrigen muy rápidamente.



¿Qué nos permitió alcanzar el éxito? En primer lugar, no comenzamos una revolución aquí y ahora. No dije: "Necesitamos implementar DevOps en tres semanas". Abordamos este proceso metódicamente, agitados durante mucho tiempo, le contamos a la gente, goteamos en nuestros cerebros, hablamos sobre los objetivos que estamos logrando.

Artem: Luché contra las preguntas de las autoridades: "Artem, ¿cuándo es DevOps?" Dijo que no habrá fecha límite, lo intentamos en Prod, no preguntes nada.

Sergey:Por otro lado, todo también es muy bueno. No impusimos a todas las unidades las tecnologías que utilizamos. La compañía es grande, los vecinos miran y dicen: "Bueno, sí, genial, pero lo implementaremos cada seis meses". No lo necesitan. No caminamos, no decimos, que tenemos la única decisión correcta. En algún lugar no queremos usar nuestra pila, para ellos hemos reunido scripts de bash simples que permiten la integración con otros comandos.

Artem: Aquí estoy convencido de que la parte superior no puede ser forzada a implementar DevOps. Esto no es realista para tal proyecto.



Sergey: Analizamos dónde perdemos la mayor parte de nuestro tiempo: hoy perdemos la mayor parte de nuestro tiempo en seguridad.

Sabemos cómo trabajar rápidamente, implementar rápidamente, pero estamos de acuerdo con un esquema de implementación: esto es una especie de infierno. Ahora que lo miramos, recuerda lo mismo cuando había divisiones completamente diferentes de Dev y Ops. Ahora que no tenemos un plan, estamos pensando en cómo incluir la seguridad en nuestro proceso para que puedan analizar los cambios.

Artem: Por ejemplo, puedes usar Merge para esto, ver qué ha cambiado en la receta. El guardia de seguridad también es ingeniero.

Sergey:A menudo, nuestros procesos formales no brindan seguridad real. Cuando realizamos una auditoría, entendemos que todos los procedimientos han pasado, pero no hemos recibido el nivel de seguridad deseado y se ha gastado mucho tiempo y recursos. Constantemente encontramos algunos problemas que han ocurrido debido a la pobre integración de los procesos de seguridad y CI / CD.

Desde el punto de vista de OPS, todavía tenemos el problema de perder el tiempo en CI y ajustar las recetas. Esta cosa ya está comenzando a ganar "chacales". Por lo tanto, miramos los sistemas para presentar marcos para desarrolladores, miramos hacia Docker, Kubernetes, para poder escribir: "Chicos, hay herramientas, no hay documentos grandes, pueden unificar el proceso de entrega".

Queremos avanzar en esta idea, pero la seguridad vuelve a resistir. Dicen: "¿Qué tipo de redes virtuales tiene, cómo funcionarán estos servicios sin un firewall?" Hay algunas contradicciones, pero creo que ganaremos de todos modos.

Artem: Tengo mi propio dolor, me gustaría terminarlo. Tenemos un gran problema: somos una empresa, y no somos la única empresa, hay representantes que están en la misma situación. Estamos bajo el control constante del regulador, el Banco Central constantemente viene con una auditoría. Pasamos por una auditoría, pasamos por una auditoría aparentemente independiente.

Es difícil culpar al auditor, él hace el trabajo sobre la base de estándares que establecen que el hardware físico debe ser una máquina separada, no virtual. Sin contenedores.

Ni un solo estándar internacional en este momento ha movido un ápice hacia las nuevas tecnologías. Hay un agujero negro No se dan cuenta de que este es un gran problema. No puedo culpar a los auditores, realizan auditorías de acuerdo con las normas. No tienen de dónde sacar esto, pero ni un solo estándar está tratando en este sentido de cambiar, transformarse en algún lugar y moverse.

Necesito descubrir cómo hacer una imagen de la existencia de la compañía con estas terribles palabras para que todo sea correcto y honesto.

Si está cansado de lecturas largas, le recomendamos que escuche el lanzamiento del podcast “Five Minute PHP” con nuestros amigos Baruch Sadogursky y Vyacheslav Kuznetsov. Tendencias DevOps, DecSecOps, victoria de Kubernetes e informe del estado de DevOps 2018 de DORA.

Y si quieres más informes geniales, ven a la conferencia DevOops 2018. ¡Habrá Baruch, y Glory, e incluso John Willis ! Todos los oradores y el programa están en el sitio .

Una buena ventaja: hasta el 1 de octubre, se puede reservar un boleto para DevOops 2018 con un descuento .