Los desarrolladores son de Marte, los administradores son de Venus

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
Una startup. Un administrador, un pequeño equipo de desarrollo. Cuando me uní, era un completo cero, ya que no tenía acceso a nada más que a mi correo electrónico. Le escribimos al administrador para solicitar acceso. También sabía del nuevo empleado y de la necesidad de emitir nombres de usuario y contraseñas. Me dieron acceso al repositorio y... vpn¿Por qué dar acceso a Wiki, TeamCity y RunDesk? Es inútil para alguien contratado para escribir todo el backend. Solo con el tiempo obtenemos acceso a algunas herramientas. Naturalmente, mi llegada genera desconfianza. Poco a poco intento familiarizarme con la infraestructura del proyecto mediante chats y preguntas capciosas. Prácticamente no aprendo nada. La producción es tan oscura como siempre. Pero incluso los servidores de pruebas que usamos para las pruebas son oscuras aquí. No podemos hacer nada más que desplegar ramas desde Git. Tampoco podemos configurar nuestra aplicación, como los archivos .env. El acceso para tales operaciones no está permitido. Hay que rogar para que se cambie una línea en la configuración de la aplicación en el servidor de pruebas. (Existe la teoría de que los administradores necesitan sentirse vitalmente como las personas más importantes del proyecto; si no se les pide que cambien líneas de configuración, simplemente no serán necesarios). Como siempre, ¿no es conveniente? Esto se vuelve rápidamente tedioso. Tras una conversación directa con el administrador, descubrimos que los desarrolladores nacen para escribir mal código, son incompetentes por naturaleza y es mejor mantenerlos alejados de la producción. Y luego está el entorno de pruebas. servidores Por si acaso. El conflicto se intensifica rápidamente. No hay comunicación con el administrador. La situación se agrava al estar solo. Entonces llega el escenario típico: lanzamiento. Una función no funciona. Pasamos mucho tiempo intentando averiguar qué pasa, con los desarrolladores aportando diversas ideas en el chat, pero el administrador suele asumir que la culpa es de los desarrolladores. Luego escribe en el chat: "Espera, ya lo arreglé". Cuando pedimos dejar un historial con información sobre el problema, recibimos excusas tóxicas. Dicen: "No metas donde no te toca". Los desarrolladores deberían escribir código. Una situación en la que muchos procesos del proyecto pasan por una sola persona, y solo ella tiene acceso para realizar las operaciones que todos necesitan, es extremadamente triste. Una persona así es un cuello de botella terrible. Si las ideas de DevOps buscan reducir el tiempo de comercialización, estas personas son el peor enemigo de las ideas de DevOps. Desafortunadamente, aquí es donde se cierra el telón.

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 podcast 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