As coincidencias son aleatorias, e efectivamente foi noutro planeta...
Gustaríame compartir tres historias de éxito e fracaso sobre como traballa un programador backend nun equipo con administradores.
Historia un.
Estudio web, o número de empregados pódese contar cunha man. Hoxe es un maquetador, mañá es un backender, pasadomañá es un administrador. Por unha banda, podes gañar unha experiencia tremenda. Por outra banda, hai unha falta de competencia en todos os ámbitos. Aínda recordo o primeiro día de traballo, aínda estou verde, o xefe di: “Abre masilla”, pero non sei que é. Exclúese a comunicación cos administradores, porque ti mesmo es un administrador. Consideremos os pros e os contras desta situación.
+ Todo o poder está nas túas mans.
+ Non hai que pedirlle a ninguén acceso ao servidor.
+ Tempo de reacción rápido en todas as direccións.
+ Mellora ben as habilidades.
+ Ter unha comprensión completa da arquitectura do produto.
- Alta responsabilidade.
— Risco de rotura da produción.
— É difícil ser un bo especialista en todas as áreas.
Non me interesa, seguimos
A segunda historia.
Gran empresa, gran proxecto. Hai un departamento de administración con 5-7 empregados e varios grupos de desenvolvemento. Cando chegas a traballar nunha empresa deste tipo, todos os administradores pensan que non viñeches aquí para traballar nun produto, senón para romper algo. Nin o NDA asinado nin a selección na entrevista indican o contrario. Non, este home veu aquí coas súas pequenas mans sucias para estragar a nosa produción de bicos. Polo tanto, con esa persoa necesitas un mínimo de comunicación; polo menos, podes lanzar un adhesivo en resposta. Non responda preguntas sobre a arquitectura do proxecto. É recomendable non conceder o acceso ata que o xefe do equipo o solicite. E cando o pida, devolverallo con aínda menos privilexios dos que pedían. Case toda a comunicación con estes administradores é absorbida polo buraco negro entre o departamento de desenvolvemento e o departamento de administración. É imposible resolver os problemas rapidamente. Pero non podes vir en persoa: os administradores están demasiado ocupados as 24 horas do día, os 7 días da semana. (Que estás facendo todo o tempo?) Algunhas características de rendemento:
- O tempo medio de implantación na produción é de 4-5 horas
- Tempo máximo de implantación en produción 9 horas
- Para un programador, unha aplicación en produción é unha caixa negra, igual que o propio servidor de produción. Cantos hai en total?
- Baixa calidade dos lanzamentos, erros frecuentes
- O programador non participa no proceso de lanzamento
Ben, o que esperaba, por suposto, a xente nova non pode entrar na produción. Ben, vale, tendo paciencia, comezamos a gañar a confianza dos demais. Pero por algún motivo, as cousas non son tan sinxelas cos administradores.
Acto 1. O administrador é invisible.
O día do lanzamento, o programador e o administrador non se comunican. O administrador non ten preguntas. Pero comprendes por que despois. O administrador é unha persoa con principios, non ten mensaxeiros, non dá o seu número de teléfono a ninguén e non ten un perfil nas redes sociais. Non hai nin unha foto del por ningures, que te pareces amigo? Sentámonos co xestor responsable uns 15 minutos desconcertados, intentando establecer comunicación con este Voyager 1, despois aparece unha mensaxe no correo electrónico corporativo que rematou. Imos corresponder por correo? Por que non? Conveniente, non? Ben, vale, imos arrefriar. O proceso xa está en marcha, non hai volta atrás. Le a mensaxe de novo. "Rematei". Que remataches? Onde? Onde debo buscarte? Aquí entendes por que 4 horas para o lanzamento son normais. Temos un choque de desenvolvemento, pero rematamos o lanzamento. Xa non hai ganas de liberar.
Acto 2. Non esa versión.
O próximo lanzamento. Unha vez adquirida experiencia, comezamos a crear listas do software e bibliotecas necesarias para o servidor para administradores, indicando as versións para algúns. Como sempre, recibimos un sinal de radio débil de que o administrador rematou algo alí. Comeza a proba de regresión, que leva aproximadamente unha hora. Todo parece funcionar, pero hai un erro crítico. A funcionalidade importante non funciona. As seguintes horas foron bailando con pandeiretas, adiviñación en pos de café e unha revisión detallada de cada peza de código. O administrador di que fixo todo. A aplicación escrita por programadores corruptos non funciona, pero o servidor funciona. Algunha pregunta para el? Ao final dunha hora, conseguimos que o administrador envíe a versión da biblioteca no servidor de produción ao chat e ao bingo; non é a que necesitamos. Pedimos ao administrador que instale a versión requirida, pero en resposta recibimos que non pode facelo debido á ausencia desta versión no xestor de paquetes do SO. Aquí, desde os recovecos da súa memoria, o xestor lembra que outro administrador xa resolvera este problema simplemente montando a man a versión requirida. Pero non, o noso non o fará. A normativa prohibe. Karl, levamos varias horas sentados aquí, cal é o límite de tempo? Temos outro choque e dalgún xeito rematamos o lanzamento.
Acto 3, curto
Ticket urxente, a funcionalidade clave non funciona para un dos usuarios en produción. Levamos un par de horas piscando e revisando. Nun entorno de desenvolvemento, todo funciona. Hai unha clara comprensión de que sería unha boa idea mirar nos rexistros de php-fpm. Nese momento non había sistemas de rexistro como ELK ou Prometheus no proxecto. Abrimos un ticket ao departamento de administración para que dean acceso aos rexistros php-fpm no servidor. Aquí tes que entender que estamos pedindo acceso por un motivo, non te lembras de que o buraco negro e os administradores están ocupados as 24 horas do día, os 7 días da semana? Se lles pide que miren os propios rexistros, entón esta é unha tarefa cunha prioridade "non nesta vida". Creouse o ticket, recibimos unha resposta instantánea do xefe do departamento de administración: "Non debería ter acceso aos rexistros de produción, escribir sen erros". Unha cortina.
Acto 4 e máis aló
Aínda estamos recollendo decenas de problemas na produción, debido a diferentes versións de bibliotecas, software sen configurar, cargas de servidor sen preparar e outros problemas. Por suposto, tamén hai erros de código, non culparemos aos administradores de todos os pecados, só mencionaremos unha operación máis típica dese proxecto. Tiñamos moitos traballadores en segundo plano que se lanzaron a través do supervisor e houbo que engadir algúns scripts a cron. Ás veces, estes mesmos traballadores deixaban de traballar. A carga no servidor de filas creceu á velocidade do lóstrego e os usuarios tristes miraron o cargador xirando. Para arranxar rapidamente estes traballadores, bastaba con reinicialos, pero de novo, só un administrador podería facelo. Mentres se realizaba unha operación tan básica, podía pasar un día enteiro. Aquí, por suposto, convén sinalar que os programadores tortos deberían escribir traballadores para que non caian, pero cando se caen, estaría ben entender por que, que ás veces é imposible pola falta de acceso á produción, de por suposto, e, como consecuencia, a falta de rexistros do desarrollador.
Transfiguración.
Despois de sufrir todo isto durante bastante tempo, xunto co equipo comezamos a ir cara a unha dirección que era máis exitosa para nós. En resumo, que problemas nos enfrontamos?
- Falta de calidade de comunicación entre desenvolvedores e departamento administrativo
- Os administradores, resulta(!), non entenden para nada como está estruturada a aplicación, que dependencias ten e como funciona.
- Os desenvolvedores non entenden como funciona o ambiente de produción e, como resultado, non poden responder eficazmente aos problemas.
- O proceso de implantación leva demasiado tempo.
- Versións inestables.
Que fixemos?
Para cada versión, xerouse unha lista de Notas de lanzamento, que incluía unha lista do traballo que hai que facer no servidor para que funcione a seguinte versión. A lista contiña varias seccións, traballos que deberían realizar o administrador, a persoa responsable da versión e o desenvolvedor. Os desenvolvedores recibiron acceso non root a todos os servidores de produción, o que acelerou o desenvolvemento en xeral e a resolución de problemas en particular. Os desenvolvedores tamén saben como funciona a produción, en que servizos se divide, onde e canto custan as réplicas. Algunhas das cargas de combate fixéronse máis claras, o que sen dúbida afecta á calidade do código. A comunicación durante o proceso de lanzamento tivo lugar no chat dun dos mensaxeiros instantáneos. En primeiro lugar, tiñamos un rexistro de todas as accións e, en segundo lugar, a comunicación tivo lugar nun ambiente máis próximo. Ter un historial de accións permitiu máis dunha vez aos novos empregados resolver problemas máis rápido. É un paradoxo, pero isto moitas veces axudou aos propios administradores. Non me comprometerei a dicir con certeza, pero paréceme que os administradores comezaron a comprender máis como funciona o proxecto e como está escrito. Ás veces incluso compartimos algúns detalles entre nós. O tempo medio de lanzamento reduciuse a unha hora. Ás veces estabamos feito en 30-40 minutos. O número de erros diminuíu significativamente, se non dez veces. Por suposto, outros factores tamén influíron na redución do tempo de lanzamento, como as probas automáticas. Despois de cada lanzamento, comezamos a realizar retrospectivas. Para que todo o equipo teña unha idea do que hai de novo, do que cambiou e do que se eliminou. Por desgraza, os administradores non sempre acudían a eles, ben, os administradores están ocupados... Sen dúbida, a miña satisfacción laboral como programador aumentou. Cando podes resolver rapidamente case calquera problema que estea na túa área de competencia, séntese na parte superior. Máis tarde, entenderei que ata certo punto introducimos unha cultura devops, non por completo, claro, pero mesmo ese comezo da transformación foi impresionante.
Terceira historia
Posta en marcha. Un administrador, pequeno departamento de desenvolvemento. Ao chegar son un cero completo, porque... Non teño acceso a ningún sitio excepto desde o correo. Escribimos ao administrador e pedimos acceso. Ademais, hai información de que está ao tanto do novo empregado e da necesidade de emitir inicios de sesión/contrasinais. Dan acceso desde o repositorio e VPN. Por que dar acceso a wiki, teamcity, rundesk? Cousas inútiles para unha persoa que foi chamada para escribir toda a parte de fondo. Só co paso do tempo accedemos a algunhas ferramentas. A chegada, por suposto, foi recibida con desconfianza. Estou tentando facerme unha idea de como funciona a infraestrutura do proxecto a través de chats e preguntas. Basicamente non recoñezo nada. A produción é a mesma caixa negra que antes. Pero máis que iso, incluso os servidores de escenario utilizados para as probas son unha caixa negra. Non podemos facer outra cousa que implementar alí unha rama de Git. Tampouco podemos configurar a nosa aplicación como ficheiros .env. Non se concede o acceso a tales operacións. Ten que pedir que cambie unha liña na configuración da súa aplicación no servidor de proba. (Hai unha teoría de que é vital que os administradores se sintan importantes no proxecto; se non se lles pide que cambien as liñas nas configuracións, simplemente non serán necesarios). Ben, coma sempre, non é conveniente? Isto axiña se aburre, despois dunha conversación directa co administrador descubrimos que os desenvolvedores naceron para escribir código malo, son por natureza persoas incompetentes e é mellor mantelos lonxe da produción. Pero aquí tamén desde servidores de proba, por se acaso. O conflito está a escalar rapidamente. Non hai comunicación co administrador. A situación vese agravada polo feito de estar só. A seguinte é unha imaxe típica. Lanzamento. Determinadas funcións non funcionan. Levamos moito tempo descubrir o que está a suceder, varias ideas dos desenvolvedores lánzanse ao chat, pero o administrador en tal situación adoita asumir que os desenvolvedores son os culpables. Despois escribe no chat, espera, corrixíno. Cando se nos pide que deixemos unha historia con información sobre cal era o problema, recibimos escusas tóxicas. Como, non metas o nariz onde non lle corresponde. Os desenvolvedores deben escribir código. A situación na que moitos movementos do corpo nun proxecto pasan por unha soa persoa e só el ten acceso para realizar as operacións que todos necesitan é extremadamente triste. Tal persoa é un pescozo de botella terrible. Se as ideas de Devops se esforzan por reducir o tempo de comercialización, entón esas persoas son o peor inimigo das ideas de Devops. Desafortunadamente, o telón pecha aquí.
P.S. Despois de falar un pouco sobre desenvolvedores e administradores nos chats con persoas, coñecín xente que compartía a miña dor. Pero tamén houbo quen dixo que nunca se atopara con algo así. Nunha conferencia de devops, preguntei a Anton Isanin (Alfa Bank) como trataron o problema do pescozo de botella en forma de administradores, ao que dixo: "Substituímolos por botóns". Por certo coa súa participación. Gustaríame crer que hai moitos máis bos administradores que inimigos. E si, a imaxe do principio é unha correspondencia real.
Fonte: www.habr.com