La tragedia (del
alemán Tragödie de
la tragoedia latina de
otro griego τραγωδία) es un género de obras de arte destinado a representarse en un escenario en el que la trama lleva a los personajes a un desenlace catastrófico.
La mayoría de las tragedias están escritas en verso. Esta tragedia fue escrita por Baruch Sadogursky (
@jbaruch ) y Leonid Igolnik (
@ligolnik ). Si estamos hablando de DevOps a gran escala, ¿qué es sino una tragedia?
Este artículo está marcado por la severidad del realismo, describe la realidad de un gran desarrollo de manera más significativa, como un montón de contradicciones internas. Revela los conflictos más profundos de la realidad en una forma extremadamente intensa y saturada, adquiriendo el valor de un símbolo artístico.
¡Y ahora terminamos de tocar Belinsky y bienvenidos al corte! Hay texto y video. ¡No tomes rehenes!
Como saben, los griegos adoraban los diagramas de Venn. Y le mostraremos hasta tres, y todo sobre DevOps.
Existe una descripción tradicional de DevOps: esta es la intersección de Operaciones, Desarrollo y QA. Es históricamente interesante que QA se agregó allí más tarde.
Pero hoy hablaremos de otra cosa: la intersección de tecnología, procesos y personas. Acerca de lo que debe hacer con estos tres componentes para obtener DevOps.
Ahora compare dos cuadros más:
A veces sucede
Pentágono Inc.
Comencemos la historia con una compañía mítica llamada Pentágono, que se ocupa de las transacciones con tarjeta de crédito.
Acto I - Bomberos
Personas . La compañía recién está comenzando su trabajo, tiene tres ingenieros. Los tres vinieron de la misma compañía de defensa. Los chicos son lo suficientemente inteligentes, por lo que tienen todo: JavaScript, Node, React, Docker, microservicios.
Proceso . ¿Cómo sería el proceso cuando hay tres personas en un equipo? Kanban: ya sea en un trozo de papel o Trello. Los chicos son inteligentes y entienden que el control de calidad es necesario desde el principio, por lo tanto, pruebas de TDD, unidad e integración. Sin operaciones, todos tienen raíz.
Herramientas En consecuencia, para tres personas que solo están criando algo:
JIRA ,
GitHub ,
Travis CI , etc.
Hablemos de cómo viven estas personas en esta hermosa pila. En primer lugar, como en las buenas nuevas empresas: estamos aserrando, aserrando un producto y esperando al primer cliente.
De repente, ocurrió un milagro: una organización que organiza las mejores conferencias en el espacio postsoviético decidió confiar en estos tipos y realizar sus transacciones a través de ellos.
¿Qué hace una startup real cuando obtiene su primer cliente? Celebra! Y alrededor de las tres de la noche, cuando todo está en un estado
especial , el cliente llama y dice que nada funciona.
Por supuesto, antes que nada, ¡pánico!
¡El siguiente paso es luchar! Nos fijamos en los registros, por ejemplo.
Miramos, miramos, resultó que uno de nuestros tres héroes, Vasya, que había vuelto a casa después del festival, cometió su pequeña idea. Recordamos que después de la confirmación y las pruebas aprobadas, todo entra en producción.
Bueno, ¿cuál de nosotros no falló en la producción? No culparemos a Vasya. Regrese a la confirmación anterior. ¡No va a hacerlo! Por alguna razón, no hay suficiente biblioteca, llamada pad izquierdo.
Para aquellos que no saben qué pasó con el panel izquierdo, les contamos. Entonces,
el 23 de marzo de 2016, la mitad de Internet se rompió . En general, el módulo de pad izquierdo en JavaScript simplemente inserta espacios en el lado izquierdo de las líneas. Y la mitad de Internet dependía directa o transitivamente de este módulo. El autor de left-pad de alguna manera logró pelear con los propietarios del repositorio central de npm, por lo que simplemente se alejó de ellos, tomando todo su trabajo. npm es generalmente un sistema misterioso: no solo verifican cuando agrega un nuevo módulo para descargar, sino que también verifican todos los módulos antiguos.
Así, una y otra vez, la lucha contra el fuego continúa. Y los problemas son los mismos todo el tiempo.
Acto II - Instaladores de alarmas contra incendios
Noticias de la compañía: recaudó dinero, encontró un inversor, contrató a 27 personas, una de ellas con experiencia en operaciones. Aparecieron 100 clientes e incluso soporte técnico.
El proceso, en consecuencia, también debe obtener una actualización. Normal Scrum, pruebas exploratorias, apareció. Nos dimos cuenta de que NoOps no existe en absoluto, porque hay Ops (si la arquitectura no tiene servidor, entonces el servidor todavía está allí, simplemente no es suyo). Dado que está mal despertar a todo el equipo por la noche, ha aparecido un desarrollador de guardia.
En consecuencia, el conjunto de herramientas se ha expandido. Como mínimo, ha aparecido la Base de conocimiento, ya que ahora hay un asistente y él necesita buscar información en alguna parte. Otra novedad es
JFrog Artifactory : un sistema que le permite almacenar lo que fue atracado ayer para que pueda retroceder fácilmente (la lección con el panel izquierdo no fue en vano), en lugar de reconstruirlo nuevamente. Pusimos un sistema para recolectar registros y buscarlos.
Se ha agregado
Pingdom : sistema de monitoreo encantador: le das una URL y te dice si funciona o si falla.
Entonces, en este punto recaudaron dinero nuevamente. Entonces, notamos. Viernes, tres de la mañana, el cliente llama. Algo no funciona: pase Visa y MasterCard, pero American Express no.
¿Y cómo reacciona primero el soporte cuando un cliente llama a las tres de la mañana? Pánico!
Entonces llamamos al asistente. Adivina quién está de servicio? ¡Por supuesto, Vasya! Adivina en qué estado se encuentra Vasya. Si Pero Vasya se recupera, mira qué apoyo le ha enviado y dice que él está sospechosamente familiarizado con esto y que ya lo ha hecho. Por lo tanto, Vasya simplemente toma y repara. Todos se van a dormir. El debate comienza el lunes.
Aquí hay un ejemplo de un documento específico que producimos para la base de conocimiento, de modo que si algo se repite nuevamente, se puede encontrar rápidamente. Además, a veces se muestra a los clientes:
El documento muestra los encabezados principales, razones, características, una lista de eventos. Se deben indicar los síntomas, se proporciona una descripción técnica de qué se rompió exactamente y cómo solucionarlo. La parte más importante del documento es la razón clave por la que algo cayó.
En el caso de Vasya, tenemos un desbordamiento de la cola de registro. Debe borrarlo de las transacciones con tarjeta de crédito y, además, aumentar su tamaño. Por ejemplo, a los 42!
Tal proceso es muy bueno para la mejora continua interna y garantiza la instalación de esos mismos "detectores de humo". La segunda razón por la cual este documento es importante es el informe al cliente. Algunos servicios, después de "descansar" por un tiempo, publican las razones de esto.
A veces el problema resulta ser tan catastrófico que no vale la pena hablar de ello.
En GitLab
en febrero de 2017 , una persona eliminó una base de datos de producción. Aquí está el análisis que GitLab ha subido:
Entonces, en algún lugar hay respaldo, solo que nadie sabe dónde. Luego se encontraron copias de seguridad, pero resultaron estar vacías. Sí, hay un volcado de base. Pero se hizo en una versión diferente de postgres, por lo que no encaja. Tenemos instantáneas, pero no tienen base de datos. La replicación desde S3 tampoco funcionó debido a la falta de datos.
Por lo tanto, cinco técnicas diferentes para respaldar datos no funcionaron. Creemos que esto no se puede publicar, ya que nadie más confiará en ellos. Pero, dependiendo de cómo se hable al respecto, el cliente puede perdonar. Es cierto, solo una vez.
Por cierto, ese tipo que lo hizo consiguió un ascenso. Además, cambió su estado de Twitter a
Especialista en bases de
datos (eliminación) en GitLab .
Acto III - Climax
Entonces, ¿qué está pasando en nuestra empresa? Recaudaron dinero nuevamente, contrataron a un grupo de personas; ahora tenemos cinco ingenieros de operaciones y una persona que se dedica al rendimiento. Hay un arquitecto jefe. Ha aparecido un equipo de éxito de clientes que cubre todas las industrias que pueden necesitar soporte. Se ralentizan para que el resto del equipo pueda seguir trabajando. A menudo, en un equipo de este tipo, hay un grupo que puede construir relaciones con operaciones o apoyo, y también periódicamente hay que dejar a los ingenieros en scrum, sprint o durante un mes. La empresa creció, apareció un abogado, un director financiero. La base de clientes ha crecido a 1000.
A medida que el equipo crece, el proceso de desarrollo debe cambiar.
SAFE apareció, un marco que explica qué hacer scrum cuando hay muchos equipos o centros de desarrollo, más de uno. El número de procesos que están presentes en Safe puede matar a un caballo, pero si solo se pueden tomar todos a la vez. Si quita solo las piezas que se requieren en esta etapa del desarrollo de la compañía, entonces todo debería estar bien.
La prueba del sistema aparece cuando los equipos grandes tienen ciertas necesidades o si tiene un sistema enorme a partir del cual necesita construir algo. Los equipos de scrum individuales pueden probar bien sus sistemas, pero alguien debería ser responsable del hecho de que todo el sistema se debe ensamblar en producción.
¿Qué hay del equipo de operaciones? Como dijimos, hay dos opciones para hacer DevOps. El primero es para el libro y para las instrucciones de Netflix, Google y Twitter. El segundo es en la vida real, donde no todos los ingenieros pueden confiar en la raíz de la producción.
La ruta de escalada es un concepto importante que le permite resolver cualquier problema en un momento dado, porque al final de la ruta de escalación hay un teléfono móvil del CEO, después de una llamada en la que todos los problemas desaparecen en 5 horas 58 minutos.
SOC II : un conjunto de estándares que el proveedor proporciona al cliente. Estas normas confirman que la empresa tiene ciertas soluciones de seguridad, enfoques para la división del trabajo.
Backlog: una lista de problemas que deben abordarse para mejorar el sistema. Por lo general, el arquitecto posterior se convierte en el arquitecto principal, que debe analizar las necesidades del sistema y las necesidades del producto y priorizar estas tareas.
Las herramientas, por supuesto, también se están mejorando.
Hay mas noticias Vasya fue promovida. Ahora es vicepresidente de ingeniería.
Viernes, sábado, domingo pasa, no llega nada. Todo funciona Todos están en shock. Llega el lunes, un abogado llega a Vasya y le dice que estuvo en una conferencia de abogados y escuchó sobre LGPL 2.2 allí. Vasya no tiene idea si tienen LGPL 2.2.
La gente trabajó durante mucho tiempo y luego encontró LGPL 2.2. Necesito cortar. Pero esto está siendo cortado por una parte saludable del sistema, y nadie canceló el lanzamiento mañana. Bueno, nada, lidió con esto.
El director del fondo llega a Vasya:
- ¿Cuánto dinero necesitas para servidores y producción? Haciendo el presupuesto para el próximo año ...
- 42 - dice Vasya.
También resolvimos este problema.
Vienen a Vasya y dicen que hay un cliente potencial, pero teme que nunca hayamos tenido un cliente tan grande, y quiere convencerse de que será bueno. Sabemos por la historia que en esta etapa todos murieron.
Pero como debemos tener un final feliz, lo atribuimos a la tragedia griega.
Epílogo - Mejora proactiva
Ahora hablemos de la última etapa de escalado de DevOps: mejora proactiva. Se trata de la prevención de incendios.
No le están sucediendo cambios a las personas. Pero con el proceso, mucho más.
Como tenemos un ingeniero de rendimiento, de alguna manera debe monitorear el sistema. Licencia y gestión de seguridad aparecieron. Rendimiento proactivo: ahora estamos observando atentamente hacia dónde se mueven los indicadores clave y arreglando las cosas antes de que comience un gran incendio. Al escalar un producto, es aconsejable tener algo que diga: si desea tener un microservicio, al menos debe tener monitoreo estándar, registros, etc.
En consecuencia, hay herramientas que respaldan todo esto. Por ejemplo, una herramienta para el monitoreo de licencias y seguridad es
JFrog Xray .
Blazemeter : dado que ahora hay un rendimiento proactivo, debe generar de alguna manera una carga. Están surgiendo cosas como la virtualización de servicios, que le permite utilizar objetos simulados para API remotas, porque no todos los proveedores con los que trabaja pueden proporcionar una API de prueba.
Analizando
Analicemos algunos eventos de actos anteriores.
¿Recuerdas el caso cuando Vasily planeó un presupuesto con un dedo en el cielo? Al trabajar en uno de nuestros productos, queríamos averiguar en qué recursos se gastaban. Después de agrupar todo lo que estaba en la cartera, obtuvimos este diagrama:
Pensamos erróneamente que estábamos gastando el 80% en Big Feature A; de hecho, solo se necesita el 13%. Al mismo tiempo, hasta el 34% se destina a mantener las luces encendidas: cosas que deben hacerse en los productos: reparar errores, actualizar bibliotecas, etc.
De hecho, solo hay una métrica objetiva de la calidad del producto: la satisfacción del cliente, que se expresa en llamadas de soporte.
Segundo ejemplo Rompimos todos los defectos de criticidad:
El 65% de las entradas pertenecen a los primeros niveles de criticidad. ¿Es esto una pesadilla?
Ahora tome los mismos datos y mírelos desde un ángulo diferente.
Ahora el cuadro refleja la situación después del informe. Resultó que el 52% de los boletos fueron cerrados por el ingeniero utilizando la información proporcionada, es decir, escribió al soporte lo que no sabían. Solo alrededor del 20% de los boletos se cerraron con algún tipo de cambio de código. Por lo tanto, resulta que la I + D no tiene la culpa. Ni siquiera el soporte tiene la culpa. De hecho, nos faltaba capacitación, y Vasya, como vicepresidente de ingeniería, después de ver cuánto tiempo pasa en todo tipo de tonterías, envió un grupo de ingenieros para capacitar al personal de soporte.
Los chicos corrigieron la documentación en cuellos de botella, corrigieron los registros. Como resultado, la pieza, que llevó mucho tiempo a los desarrolladores, desapareció.
Conclusiones
En todas las etapas, desde la lucha contra incendios hasta la instalación de alarmas y la resolución proactiva de problemas, hay muchos procesos, personas, especialistas, enfoques y herramientas que deben instalarse. Todo esto no se puede hacer en un día. Además, algunas cosas no son necesarias en algunas etapas de desarrollo.
Es importante comprender que en las personas, en los procesos y en las herramientas, se necesitan constantemente algunas mejoras.
Lo que necesita ser mejorado exactamente, seremos ayudados a descubrir los mismos números de los que hablamos. Solo sobre la base de estos datos podemos tomar las decisiones correctas sobre dónde invertir tiempo y qué avanzar.
Y no olvide los dos principios fundamentales de DevOps:
- Lo construyes, lo tienes.
- El dolor es instructivo.
El próximo domingo, Baruch y Leonid entregarán un informe "#DataDrivenDevOps" en DevOops 2018 en San Petersburgo. Vamos, habrá muchas cosas interesantes: aquí están los informes , aquí está John Willis , y aquí hay una fiesta con BoFs y karaoke . Esperando por ti!