Las coincidencias son aleatorias, y efectivamente fue en otro planeta...
Quiero compartir tres historias de éxito y fracaso sobre cómo trabaja un desarrollador backend en equipo con administradores.
La primera historia.
Estudio web, el número de empleados se puede contar con una mano. Hoy eres codificador, mañana eres backender, pasado mañana eres administrador. Por un lado, puedes obtener una experiencia tremenda. Por otro lado, hay una falta de competencia en todas las áreas. Todavía recuerdo el primer día de trabajo, todavía estoy verde, el jefe dice: "Abrir masilla", pero no sé qué es. La comunicación con los administradores está excluida porque. usted es el administrador. Considere los pros y los contras de esta posición.
+ Todo el poder está en tus manos.
+ No hay necesidad de rogar a nadie para acceder desde el servidor.
+ Tiempo de reacción rápido en todos los ámbitos.
+ Habilidades de bombas de pozo.
+ Hay una comprensión completa de la arquitectura del producto.
- Alta responsabilidad.
- El riesgo de romper la producción.
— Es difícil ser un buen especialista en todas las áreas.
No me interesa, sigamos.
La segunda historia.
Gran empresa, gran proyecto. Hay un departamento de administración con 5-7 empleados y varios equipos de desarrollo. Cuando vienes a trabajar en una empresa de este tipo, todos los administradores piensan que viniste aquí no para trabajar en un producto, sino para romper algo. Ni el NDA firmado, ni la selección en la entrevista dicen lo contrario. No, este hombre vino aquí con sus manos sucias para arruinar nuestra producción de besos. Por lo tanto, con esa persona necesita un mínimo de comunicación, puede arrojar una pegatina al extremo en respuesta. No responda preguntas sobre la arquitectura del proyecto. Es recomendable no dar acceso hasta que el líder del equipo lo solicite. Y cuando se le solicite, emitir con incluso menos privilegios de los solicitados. Casi toda la comunicación con dichos administradores es absorbida por un agujero negro entre el departamento de desarrollo y el departamento de administración. Los problemas no se pueden resolver rápidamente. Y no puede acercarse en persona: los administradores están demasiado ocupados las 24 horas del día, los 7 días de la semana. (¿Qué haces todo el tiempo?) Algunas características de rendimiento:
- Tiempo promedio de implementación a producción 4-5 h
- Tiempo máximo de implementación a producción 9h
- Para un desarrollador, una aplicación en producción es una caja negra, al igual que el propio servidor de producción. ¿Y cuántos de ellos en general?
- Mala calidad de publicación, errores frecuentes
- El desarrollador no está involucrado en el proceso de lanzamiento.
Bueno, qué esperaba, por supuesto, los recién llegados no pueden entrar en producción. Bueno, está bien, con paciencia, comenzamos a ganarnos la confianza de los demás. Pero por alguna razón, no es tan simple con los administradores.
Acto 1. El administrador es invisible.
El día del lanzamiento, el desarrollador y el administrador no se comunican. El administrador no tiene preguntas. Pero por qué entender más tarde. El administrador es una persona de principios, no tiene mensajería instantánea, no da número de teléfono a nadie, no tiene perfil en redes sociales. Sí, ni siquiera hay una foto de él en ninguna parte, ¿cómo te ves amigo? Nos sentamos con el gerente responsable durante unos 15 minutos desconcertados, tratando de establecer contacto con este Voyager 1, luego cae un mensaje en el correo corporativo que ha terminado. ¿Vamos a escribirnos por correo? ¿Por qué no? Conveniente, ¿no? Está bien, vamos a refrescarnos. El proceso ya está en marcha, no hay vuelta atrás. Volvemos a leer el mensaje. "Terminé". ¿Qué terminaste? ¿Dónde? ¿Dónde buscarte? Aquí entiendes por qué 4 horas por lanzamiento es normal. Recibimos un shock de desarrollo, pero terminamos el lanzamiento. Ya no hay deseo de liberar.
Acto 2. Versión incorrecta.
Próximo lanzamiento. Habiendo ganado experiencia, comenzamos a formar listas de software y bibliotecas necesarias para el servidor para administradores, indicando versiones para algunos. Como siempre, recibimos una señal de radio débil de que el administrador ha terminado algo allí. Comienza la prueba de regresión, que dura alrededor de una hora. Todo parece estar funcionando, pero hay un error crítico. La funcionalidad importante no está funcionando. Las próximas horas son baile con panderetas, adivinación en posos de café, revisión detallada de cada pieza de código. El administrador dice que lo hizo. La aplicación escrita por los desarrolladores de krivorukovy no funciona y el servidor funciona. ¿Cuáles son sus preguntas? Al final de una hora, aún conseguimos que el administrador suelte la versión de la biblioteca en el servidor de producción y participe en el chat; no es lo que necesitamos. Le pedimos al administrador que instale la versión requerida, en respuesta obtenemos que no puede hacerlo debido a la ausencia de esta versión en el administrador de paquetes del sistema operativo. Aquí, desde los contenedores de la memoria, el administrador recuerda que otro administrador ya resolvió este problema, simplemente recolectando la versión deseada con sus manos. Pero no, no haremos eso. El reglamento lo prohíbe. Carl, ya llevamos varias horas sentados, ¿cuáles son las normas? Recibimos otra sorpresa, el lanzamiento de alguna manera está terminando.
Acto 3, corto
Ticket urgente, funcionalidad clave no funciona para uno de los usuarios en producción. Meter un par de horas, comprobar. En un entorno de desarrollo, todo funciona. Existe un entendimiento claro de que sería bueno mirar los registros de php-fpm. No había ningún sistema de registro como ELK o Prometheus en ese momento en el proyecto. Abrimos un ticket al departamento de administración para que den acceso a los logs de php-fpm al servidor. Aquí debe comprender que no estamos solicitando acceso fácilmente, ¿recuerda el agujero negro y el ajetreo de los administradores las 24 horas del día, los 7 días de la semana? Si les pide que miren los registros ellos mismos, entonces esta es una tarea con una prioridad de "no en esta vida". Se crea el ticket, recibimos una respuesta instantánea del jefe del departamento de administración: "No debería necesitar acceso a los registros en producción, escriba sin errores". Una cortina.
Acto 4 y más allá
Estamos recopilando una docena más de problemas en producción, debido a diferentes versiones de bibliotecas, software no configurado, falta de preparación para las cargas del servidor y otros problemas. Los errores de código, por supuesto, también ocurren, no culparemos a los administradores por todos los pecados, solo mencionaremos una operación típica más para ese proyecto. Tuvimos muchos trabajadores en segundo plano que se iniciaron a través del supervisor, y algunos scripts tuvieron que agregarse a cron. A veces estos mismos trabajadores dejaban de trabajar. En el servidor de cola, la carga creció a la velocidad del rayo y los usuarios tristes miraron el loder giratorio. Para una solución rápida, bastaba con reiniciar a dichos trabajadores, pero nuevamente, solo el administrador podía hacer esto. Mientras se realizaba una operación tan elemental, podía pasar un día entero. Aquí, por supuesto, vale la pena señalar que los programadores corruptos deberían escribir trabajadores para que no se caigan, pero cuando se caen, sería bueno entender por qué, que a veces es imposible debido a la falta de acceso a la producción, por supuesto. y, como resultado, la falta de registros del desarrollador.
Transformaciones.
Habiendo soportado todo esto durante bastante tiempo, junto con el equipo, comenzamos a tomar una dirección más exitosa para nosotros. En resumen, ¿cuáles fueron los desafíos que enfrentamos?
- Falta de comunicación de alta calidad entre los desarrolladores y el departamento de administración.
- Resulta que los administradores (!), no entienden en absoluto cómo funciona la aplicación, qué dependencias tiene y cómo funciona.
- Los desarrolladores no entienden cómo funciona el entorno de producción y, como resultado, no pueden responder de manera efectiva a los problemas.
- El proceso de implementación lleva demasiado tiempo.
- Lanzamientos inestables.
¿Qué hemos hecho?
Para cada versión, se formó una lista de Notas de la versión, que incluía una lista del trabajo que debía realizarse en el servidor para que funcionara la próxima versión. La lista contenía varias secciones, el trabajo que debe realizar el administrador responsable de la versión y el desarrollador. Los desarrolladores obtuvieron acceso (no root) a todos los servidores de producción, lo que aceleró el desarrollo en general y la resolución de problemas en particular. Además, los desarrolladores comprendieron cómo funciona la producción, en qué servicios se divide, dónde y cuánto cuestan las réplicas. Por una parte, las cargas de combate se han vuelto más comprensibles, lo que sin duda afecta la calidad del código. La comunicación durante el proceso de liberación tuvo lugar en el chat de uno de los mensajeros. En primer lugar, teníamos un registro de todas las acciones y, en segundo lugar, la comunicación se llevó a cabo en un entorno más cercano. Tener un historial de acciones más de una vez permitió a los nuevos empleados resolver problemas más rápido. Es una paradoja, pero esto a menudo ayudaba a los propios administradores. No me comprometeré a decirlo con seguridad, pero me parece que los administradores han comenzado a comprender más cómo funciona el proyecto, cómo está escrito. A veces incluso compartimos algunos detalles entre nosotros. El tiempo promedio de liberación se redujo a una hora. A veces encajamos en 30-40 minutos. La cantidad de errores se ha reducido varias veces, si no docenas de veces. Por supuesto, otros factores también contribuyeron a la reducción del tiempo de lanzamiento, por ejemplo, como las pruebas automáticas. Después de cada lanzamiento, comenzamos a hacer retrospectivas. Para que todo el equipo tenga una idea de lo nuevo, lo que ha cambiado y lo que se ha eliminado. Desafortunadamente, los administradores no siempre acudieron a ellos, bueno, los administradores están ocupados... Como desarrollador, mi satisfacción laboral sin duda ha aumentado. Cuando puedes resolver rápidamente casi cualquier problema que esté en tu área de competencia, te sientes como un caballo. Más tarde, me daré cuenta de que hemos introducido la cultura DevOps hasta cierto punto, no completamente, por supuesto, pero incluso ese comienzo de la transformación fue impresionante.
Tercera historia
Puesta en marcha. Un administrador, pequeño departamento de desarrollo. Al llegar, soy un completo cero, porque excepto desde el acceso al correo que no tengo en ninguna parte. Escribimos al administrador, le pedimos que dé acceso. Además, hay información de que está al tanto del nuevo empleado y la necesidad de emitir nombres de usuario/contraseñas. Dan acceso desde el repositorio y vpn. ¿Por qué dar acceso a wiki, teamcity, rundesk? Cosas inútiles para una persona que fue llamada a escribir toda la parte de back-end. Solo con el tiempo logramos acceder a algunas herramientas. La llegada, por supuesto, fue recibida con incredulidad. Estoy tratando de sentir lentamente cómo funciona la infraestructura del proyecto a través de chats y preguntas capciosas. Básicamente no sé nada. La producción es la misma caja negra que antes. Pero más que eso, incluso hay una caja negra de servidores de escenario que se utilizan para las pruebas. Además de implementar una rama desde el git allí, no podemos hacer nada. Además, no podemos configurar nuestra aplicación como archivos .env. No se permite el acceso para tales operaciones. Debe participar en la mendicidad para cambiar la línea en la configuración de su aplicación en el servidor de prueba. (Existe la teoría de que es vital que los administradores se sientan importantes en el proyecto, si no se les pide que cambien líneas en las configuraciones, simplemente no serán necesarios). Bueno, como siempre, ¿no es conveniente? Esto rápidamente se vuelve aburrido, luego de una conversación directa con el administrador, descubrimos que los desarrolladores nacieron para escribir mal código, por naturaleza son personalidades incompetentes y es mejor mantenerlos alejados de la producción. Pero aquí también de servidores de prueba, por si acaso. El conflicto está escalando rápidamente. No hay comunicación con el administrador. La situación se agrava por el hecho de que está solo. A continuación se muestra una imagen típica. Liberar. Cierta funcionalidad no funciona. Descubrimos lo que está sucediendo durante mucho tiempo, se lanzan varias ideas de los desarrolladores al chat, pero el administrador en tal situación generalmente asume que los desarrolladores tienen la culpa. Luego escribe en el chat, espera, corregí. Cuando se nos pide que dejemos una historia con información sobre cuál fue el problema, obtenemos excusas tóxicas. No metas la nariz donde no corresponde. Los desarrolladores deben escribir código. La situación en la que muchos movimientos del cuerpo en el proyecto pasan por una sola persona y solo él tiene acceso para realizar las operaciones que todos necesitan es extremadamente triste. Tal persona es un cuello de botella terrible. Si las ideas de Devops apuntan a reducir el tiempo de comercialización, entonces esas personas son el peor enemigo de las ideas de Devops. Desafortunadamente, el telón se está cerrando aquí.
PD Habiendo hablado un poco sobre desarrolladores vs administradores en chats con personas, conocí a personas que compartían mi dolor. Pero también hubo quienes dijeron que no se habían encontrado con tal cosa. En una conferencia de devops, le pregunté a Anton Isanin (Alfa-Bank) cómo lidiaron con el problema del cuello de botella en forma de administradores, a lo que respondió: "Los reemplazamos con botones". Por cierto con su participación. Me gustaría creer que hay muchos más administradores buenos que enemigos. Y sí, la imagen del principio es una correspondencia real.
Fuente: www.habr.com