Les coincidències són aleatòries, i de fet va ser en un altre planeta...
M'agradaria compartir tres històries d'èxit i fracàs sobre com treballa un desenvolupador de fons en un equip amb administradors.
Primera història.
Estudi web, el nombre d'empleats es pot comptar amb una mà. Avui ets dissenyador de maquetació, demà ets backender, passat demà és administrador. D'una banda, podeu obtenir una gran experiència. D'altra banda, hi ha una manca de competència en tots els àmbits. Encara recordo el primer dia de feina, encara sóc verd, el cap diu: “Obre la massilla”, però no sé què és. S'exclou la comunicació amb els administradors, perquè tu mateix ets un administrador. Considerem els pros i els contres d'aquesta situació.
+ Tot el poder està a les teves mans.
+ No cal demanar a ningú que accedeixi al servidor.
+ Temps de reacció ràpid en totes direccions.
+ Millora bé les habilitats.
+ Tenir una comprensió completa de l'arquitectura del producte.
— Alta responsabilitat.
— Risc de trencament de producció.
— És difícil ser un bon especialista en tots els àmbits.
No m'interessa, seguim
La segona història.
Gran empresa, gran projecte. Hi ha un departament d'administració amb 5-7 empleats i diversos grups de desenvolupament. Quan véns a treballar en una empresa així, tots els administradors pensen que no has vingut aquí per treballar en un producte, sinó per trencar alguna cosa. Ni el NDA signat ni la selecció a l'entrevista indiquen el contrari. No, aquest home va venir aquí amb les seves petites mans brutes per arruïnar la nostra producció de petons. Per tant, amb una persona així necessiteu un mínim de comunicació; com a mínim, podeu llançar un adhesiu com a resposta. No respongui a preguntes sobre l'arquitectura del projecte. És aconsellable no concedir l'accés fins que el líder de l'equip ho demani. I quan ho demani, el retornarà amb encara menys privilegis dels que demanaven. Gairebé tota la comunicació amb aquests administradors és absorbida pel forat negre entre el departament de desenvolupament i el departament d'administració. És impossible resoldre els problemes ràpidament. Però no podeu venir en persona: els administradors estan massa ocupats les 24 hores del dia. (Què estàs fent tot el temps?) Algunes característiques de rendiment:
- El temps mitjà de desplegament en producció és de 4-5 hores
- Temps màxim de desplegament en producció 9 hores
- Per a un desenvolupador, una aplicació en producció és una caixa negra, igual que el propi servidor de producció. Quants n'hi ha en total?
- Baixa qualitat dels llançaments, errors freqüents
- El desenvolupador no participa en el procés de llançament
Bé, què esperava, per descomptat, no es permet la producció de gent nova. Bé, d'acord, havent guanyat paciència, comencem a guanyar-nos la confiança dels altres. Però per alguna raó, les coses no són tan senzilles amb els administradors.
Acte 1. L'administrador és invisible.
El dia del llançament, el desenvolupador i l'administrador no es comuniquen. L'administrador no té cap pregunta. Però després entens per què. L'administrador és una persona de principis, no té missatgers, no dóna el seu número de telèfon a ningú i no té un perfil a les xarxes socials. Ni tan sols hi ha una foto d'ell enlloc, com et sembla? Ens asseiem amb el responsable responsable durant uns 15 minuts desconcertats, intentant establir comunicació amb aquest Voyager 1, després apareix un missatge al correu electrònic corporatiu que ha acabat. Ens correspondrem per correu? Perquè no? Convenient, no? Bé, d'acord, refresquem-nos. El procés ja està en marxa, no hi ha marxa enrere. Torna a llegir el missatge. "He acabat". Què has acabat? On? On t'he de buscar? Aquí entendreu per què 4 hores per alliberar és normal. Tenim un xoc de desenvolupament, però acabem el llançament. Ja no hi ha ganes d'alliberar.
Acte 2. No aquesta versió.
El proper llançament. Un cop adquirida experiència, comencem a crear llistes del programari i biblioteques necessàries per al servidor per als administradors, indicant les versions per a alguns. Com sempre, rebem un senyal de ràdio feble que l'administrador ha acabat alguna cosa allà. Comença la prova de regressió, que dura aproximadament una hora. Sembla que tot funciona, però hi ha un error crític. La funcionalitat important no funciona. Les hores següents van ser ballant amb panderetes, endevinació sobre fons de cafè i una revisió detallada de cada tros de codi. L'administrador diu que ho ha fet tot. L'aplicació escrita per desenvolupadors torts no funciona, però el servidor funciona. Alguna pregunta per a ell? Al final d'una hora, fem que l'administrador enviï la versió de la biblioteca al servidor de producció al xat i al bingo; no és la que necessitem. Demanem a l'administrador que instal·li la versió requerida, però en resposta rebem que no pot fer-ho a causa de l'absència d'aquesta versió al gestor de paquets del sistema operatiu. Aquí, des dels retrassos de la seva memòria, el gerent recorda que un altre administrador ja havia resolt aquest problema simplement muntant la versió requerida a mà. Però no, els nostres no ho faran. La normativa prohibeix. Karl, portem unes hores asseguts aquí, quin és el límit de temps?! Tenim un altre xoc i d'alguna manera acabem el llançament.
Acte 3, curt
Bitllet urgent, la funcionalitat clau no funciona per a un dels usuaris en producció. Passem un parell d'hores picant i comprovant. En un entorn de desenvolupament, tot funciona. Hi ha una comprensió clara que seria una bona idea mirar els registres de php-fpm. En aquell moment no hi havia sistemes de registre com ELK o Prometheus al projecte. Obrim un tiquet al departament d'administració perquè donin accés als registres php-fpm del servidor. Aquí heu d'entendre que estem demanant accés per un motiu, no recordeu que el forat negre i els administradors estan ocupats les 24 hores del dia? Si els demaneu que mirin els registres ells mateixos, aquesta és una tasca amb una prioritat "no en aquesta vida". El bitllet es va crear, vam rebre una resposta instantània del cap del departament d'administració: "No hauríeu de necessitar accés als registres de producció, escriviu sense errors". Una cortina.
Acte 4 i posteriors
Encara estem recopilant desenes de problemes en producció, a causa de diferents versions de biblioteques, programari no configurat, càrregues del servidor no preparats i altres problemes. Per descomptat, també hi ha errors de codi, no culparem els administradors de tots els pecats, només esmentarem una operació més típica d'aquest projecte. Teníem un munt de treballadors de fons que es van llançar a través del supervisor i s'havien d'afegir alguns scripts a cron. De vegades aquests mateixos treballadors deixaven de treballar. La càrrega del servidor de cues va créixer a la velocitat del llamp i els usuaris tristos van mirar el carregador giratori. Per solucionar ràpidament aquests treballadors, n'hi havia prou amb reiniciar-los, però de nou, només un administrador podria fer-ho. Mentre es feia una operació tan bàsica, podia passar un dia sencer. Aquí, per descomptat, val la pena assenyalar que els programadors torts haurien d'escriure els treballadors perquè no s'estavellin, però quan cauen, estaria bé entendre per què, que de vegades és impossible per la manca d'accés a la producció, de per descomptat, i com a conseqüència, la manca de registres del desenvolupador.
Transfiguració.
Després d'haver suportat tot això durant força temps, juntament amb l'equip vam començar a avançar cap a una direcció que ens va tenir més èxit. En resum, quins problemes ens hem trobat?
- Manca de comunicació de qualitat entre desenvolupadors i departament d'administració
- Els administradors, resulta (!), no entenen gens com està estructurada l'aplicació, quines dependències té i com funciona.
- Els desenvolupadors no entenen com funciona l'entorn de producció i, com a resultat, no poden respondre eficaçment als problemes.
- El procés de desplegament triga massa.
- Alliberaments inestables.
Què hem fet?
Per a cada llançament, es va generar una llista de notes de versió, que incloïa una llista de treballs que cal fer al servidor perquè funcioni la següent versió. La llista contenia diverses seccions, el treball que hauria de dur a terme l'administrador, la persona responsable del llançament i el desenvolupador. Els desenvolupadors van rebre accés no root a tots els servidors de producció, la qual cosa va accelerar el desenvolupament en general i la resolució de problemes en particular. Els desenvolupadors també entenen com funciona la producció, en quins serveis es divideix, on i quant costen les rèpliques. Algunes de les càrregues de combat s'han fet més clares, cosa que sens dubte afecta la qualitat del codi. La comunicació durant el procés de llançament va tenir lloc al xat d'un dels missatgers instantanis. En primer lloc, teníem un registre de totes les accions i, en segon lloc, la comunicació es feia en un entorn més proper. Tenir un historial d'accions ha permès més d'una vegada als nous empleats resoldre problemes més ràpidament. És una paradoxa, però això sovint ajudava els mateixos administradors. No em comprometré a dir-ho amb certesa, però em sembla que els administradors han començat a entendre més com funciona el projecte i com està escrit. De vegades fins i tot compartim alguns detalls entre nosaltres. El temps mitjà de llançament s'ha reduït a una hora. De vegades vam acabar en 30-40 minuts. El nombre d'errors ha disminuït significativament, si no deu vegades. Per descomptat, altres factors també van influir en la reducció del temps de llançament, com els autotests. Després de cada llançament, vam començar a fer retrospectives. Perquè tot l'equip tingui una idea de què hi ha de nou, què ha canviat i què s'ha eliminat. Malauradament, els administradors no sempre els venien, bé, els administradors estan ocupats... Sens dubte, la meva satisfacció laboral com a desenvolupador ha augmentat. Quan pots resoldre ràpidament gairebé qualsevol problema de la teva àrea de competència, et sents al capdavant. Més endavant, entendré que fins a cert punt vam introduir una cultura devops, no del tot, és clar, però fins i tot aquell inici de la transformació va ser impressionant.
La tercera història
Posada en marxa. Un administrador, petit departament de desenvolupament. En arribar sóc un zero complet, perquè... No tinc accés enlloc excepte des del correu. Escrivim a l'administrador i li demanem accés. A més, hi ha informació que té coneixement del nou empleat i de la necessitat d'emetre inicis de sessió/contrasenyes. Donen accés des del repositori i VPN. Per què donar accés a wiki, teamcity, rundesk? Coses inútils per a una persona que va ser trucada per escriure tota la part de fons. Només amb el temps podem accedir a algunes eines. L'arribada, és clar, va ser rebuda amb desconfiança. Estic intentant fer-me una idea lentament de com funciona la infraestructura del projecte mitjançant xats i preguntes dirigides. Bàsicament no reconec res. La producció és la mateixa caixa negra que abans. Però més que això, fins i tot els servidors d'escenari utilitzats per a les proves són una caixa negra. No podem fer res més que desplegar-hi una branca des de Git. Tampoc podem configurar la nostra aplicació com a fitxers .env. No es permet l'accés a aquestes operacions. Heu de demanar que canviï una línia a la configuració de la vostra aplicació al servidor de prova. (Hi ha una teoria que és vital que els administradors se sentin importants en el projecte; si no se'ls demana que canviïn les línies a les configuracions, simplement no seran necessaris). Bé, com sempre, no és convenient? Això s'avorreix ràpidament, després d'una conversa directa amb l'administrador descobrim que els desenvolupadors van néixer per escriure codi dolent, són per naturalesa persones incompetents i és millor mantenir-los allunyats de la producció. Però aquí també des de servidors de prova, per si de cas. El conflicte augmenta ràpidament. No hi ha comunicació amb l'administrador. La situació s'agreuja pel fet d'estar sol. La següent és una imatge típica. Alliberament. Algunes funcionalitats no funcionen. Ens triga molt de temps esbrinar què està passant, diverses idees dels desenvolupadors es llancen al xat, però l'administrador en aquesta situació normalment assumeix que els desenvolupadors són els culpables. Llavors escriu al xat, espera, el vaig corregir. Quan ens demanen que deixem una història amb informació sobre quin era el problema, rebem excuses tòxiques. Com, no enganxeu el nas on no pertoca. Els desenvolupadors han d'escriure codi. La situació en què molts moviments corporals en un projecte passen per una sola persona i només ell té accés per realitzar les operacions que tothom necessita és extremadament trista. Una persona així és un coll d'ampolla terrible. Si les idees de Devops s'esforcen per reduir el temps de llançament al mercat, aquestes persones són el pitjor enemic de les idees de Devops. Malauradament, aquí es tanca el teló.
PS Després de parlar una mica sobre desenvolupadors i administradors en xats amb gent, vaig conèixer gent que compartia el meu dolor. Però també hi va haver qui va dir que mai s'havia trobat amb una cosa semblant. En una conferència de devops, vaig preguntar a Anton Isanin (Alfa Bank) com van tractar el problema del coll d'ampolla en forma d'administradors, als quals va dir: "Els vam substituir per botons". A propòsit amb la seva participació. M'agradaria creure que hi ha molts més bons administradors que enemics. I sí, la imatge del principi és una correspondència real.
Font: www.habr.com