Basado en una discusión de chat
Recientemente, han estallado batallas reales sobre la definición de DevOps y SRE.
A pesar de que en muchos sentidos las discusiones sobre este tema ya me han puesto los dientes nerviosos, incluido yo mismo, decidí llevar mi opinión sobre este tema al tribunal de la comunidad Habra. Para aquellos que estén interesados, bienvenidos al gato. ¡Y que todo comience de nuevo!
Prehistoria
Entonces, en la antigüedad, un equipo de desarrolladores de software y administradores de servidores vivían separados. El primero escribió con éxito el código, el segundo, utilizando varias palabras cálidas y afectuosas dirigidas al primero, configuró los servidores, acudió periódicamente a los desarrolladores y recibió en respuesta un completo "todo funciona en mi máquina". La empresa estaba esperando el software, todo estaba inactivo, se estropeaba periódicamente, todo el mundo estaba nervioso. Especialmente el que pagó por todo este lío. Gloriosa era de las lámparas. Bueno, ya sabes de dónde viene DevOps.
El nacimiento de las prácticas DevOps
Luego vinieron tipos serios y dijeron: esto no es una industria, no se puede trabajar así. Y trajeron modelos de ciclo de vida. Aquí, por ejemplo, está el modelo V.
Entonces ¿Qué vemos? Una empresa viene con un concepto, los arquitectos diseñan soluciones, los desarrolladores escriben código y luego falla. Alguien de alguna manera prueba el producto, alguien de alguna manera lo entrega al usuario final, y en algún lugar a la salida de este modelo milagroso se encuentra un cliente comercial solitario esperando el clima prometido junto al mar. Llegamos a la conclusión de que necesitamos métodos que nos permitan establecer este proceso. Y decidimos crear prácticas que las implementaran.
Una digresión lírica sobre el tema de qué es la práctica.
Por práctica me refiero a una combinación de tecnología y disciplina. Un ejemplo es la práctica de describir la infraestructura utilizando código Terraform. La disciplina es cómo describir la infraestructura con código, está en la cabeza del desarrollador y la tecnología es la terraforma misma.
Y decidieron llamarlas prácticas DevOps; creo que se referían desde el desarrollo hasta las operaciones. Se nos ocurrieron varias cosas inteligentes: prácticas de CI/CD, prácticas basadas en el principio de IaC, miles de ellas. Y listo, los desarrolladores escriben el código, los ingenieros de DevOps transforman la descripción del sistema en forma de código en sistemas que funcionan (sí, desafortunadamente el código es solo una descripción, pero no la encarnación del sistema), la entrega continúa, etcétera. Los administradores de ayer, habiendo dominado nuevas prácticas, se capacitaron con orgullo como ingenieros de DevOps, y todo empezó a partir de ahí. Y fue la tarde, y fue la mañana... lo siento, no de ahí.
No todo es bueno otra vez, gracias a Dios.
Tan pronto como todo se calmó y varios "metodólogos" astutos comenzaron a escribir libros gruesos sobre las prácticas de DevOps, surgieron silenciosamente disputas sobre quién era el famoso ingeniero de DevOps y que DevOps es una cultura de producción, el descontento surgió nuevamente. De repente resultó que la entrega de software no es una tarea en absoluto trivial. Cada infraestructura de desarrollo tiene su propia pila, en algún lugar necesita ensamblarla, en algún lugar necesita implementar el entorno, aquí necesita Tomcat, aquí necesita una forma astuta y complicada de ejecutarlo; en general, le late la cabeza. Y el problema, por extraño que parezca, resultó estar principalmente en la organización de los procesos: esta función de entrega, como un cuello de botella, comenzó a bloquear los procesos. Además, nadie canceló Operaciones. En el modelo V no es visible, pero a la derecha sigue estando todo el ciclo de vida. Como resultado, es necesario de alguna manera mantener la infraestructura, monitorear, resolver incidentes y también ocuparse de la entrega. Aquellos. sentarse con un pie tanto en desarrollo como en operación, y de repente resultó ser Desarrollo y Operaciones. Y luego estaba el revuelo general por los microservicios. Y con ellos, el desarrollo de las máquinas locales comenzó a trasladarse a la nube: intente depurar algo localmente, si hay docenas y cientos de microservicios, la entrega constante se convierte en un medio de supervivencia. Para una “pequeña y modesta empresa” estaba bien, pero ¿aún así? ¿Qué pasa con Google?
SRE de Google
Vino Google, se comió los cactus más grandes y decidió: no necesitamos esto, necesitamos confiabilidad. Y hay que gestionar la fiabilidad. Y decidí que necesitamos especialistas que gestionen la fiabilidad. Los llamé ingenieros de SR y les dije: eso es todo, háganlo bien como siempre. Aquí está SLI, aquí está SLO, aquí está el monitoreo. Y metió las narices en las operaciones. Y llamó a su SRE "DevOps confiable". Todo parece estar bien, pero hay un truco sucio que Google podría permitirse: para el puesto de ingenieros SR, contratar personas que fueran desarrolladores calificados y que también hicieran un poco de tarea y entendieran el funcionamiento de los sistemas en funcionamiento. Además, el propio Google tiene problemas para contratar a este tipo de personas, principalmente porque aquí compite consigo mismo; es necesario describirle la lógica empresarial a alguien. La entrega se asignó a los ingenieros de lanzamiento, SR: los ingenieros gestionan la confiabilidad (por supuesto, no directamente, sino influyendo en la infraestructura, cambiando la arquitectura, rastreando cambios e indicadores, lidiando con incidentes). Bien, puedes . Pero, ¿qué pasa si no eres Google, pero la confiabilidad sigue siendo una preocupación?
Desarrollo de ideas DevOps
En ese momento llegó Docker, que surgió de lxc, y luego varios sistemas de orquestación como Docker Swarm y Kubernetes, y los ingenieros de DevOps exhalaron: la unificación de prácticas simplificó la entrega. Lo simplificó hasta tal punto que fue posible incluso subcontratar la entrega a los desarrolladores: qué es despliegue.yaml. La contenedorización resuelve el problema. Y la madurez de los sistemas CI/CD ya está en el nivel de escribir un archivo y listo: los desarrolladores pueden manejarlo ellos mismos. Y luego empezamos a hablar de cómo podemos hacer nuestro propio SRE, con... o al menos con alguien.
SRE no está en Google
Bueno, está bien, hicimos la entrega, parece que podemos exhalar, volver a los viejos tiempos, cuando los administradores observaban cómo se cargaba el procesador, ajustaban los sistemas y tranquilamente bebían algo incomprensible de las tazas en paz y tranquilidad... Detente. No es por eso que empezamos todo (¡lo cual es una lástima!). De repente resulta que con el enfoque de Google podemos adoptar fácilmente excelentes prácticas: lo importante no es la carga del procesador, ni la frecuencia con la que cambiamos los discos allí u optimizamos el costo en la nube, pero las métricas comerciales son igualmente notorias. SLx. Y nadie les ha quitado la gestión de infraestructura, y necesitan resolver incidentes, estar en servicio periódicamente y, en general, estar al tanto de los procesos comerciales. Y chicos, empezad a programar poco a poco a buen nivel, Google ya os está esperando.
Para resumir. De repente, pero ya estás cansado de leer y no puedes esperar para escupir y escribirle al autor un comentario sobre el artículo. DevOps como práctica de entrega siempre ha sido y será. Y no irá a ninguna parte. La SRE como conjunto de prácticas operativas hace que esta entrega sea exitosa.
Fuente: habr.com