Koincidoj estas hazardaj, kaj efektive ĝi estis sur alia planedo...
Mi volas konigi tri rakontojn pri sukceso kaj fiasko pri kiel backend-programisto funkcias en teamo kun administrantoj.
Historio unue.
Retejo studio, la nombro da dungitoj povas esti kalkulita per unu mano. Hodiaŭ vi estas kodisto, morgaŭ vi estas backender, postmorgaŭ vi estas administranto. Unuflanke, vi povas akiri enorman sperton. Aliflanke, estas manko de kompetenteco en ĉiuj kampoj. Mi ankoraŭ memoras la unuan labortagon, mi estas ankoraŭ verda, la estro diras: "Malfermu masilon", sed mi ne scias kio ĝi estas. Komunikado kun administrantoj estas ekskludita, ĉar. vi estas la administranto. Konsideru la avantaĝojn kaj malavantaĝojn de ĉi tiu pozicio.
+ Ĉiu potenco estas en viaj manoj.
+ Ne necesas petegi iun ajn por aliro de la servilo.
+ Rapida tempo de reago trans la tabulo.
+ Bone pumpas kapablojn.
+ Estas kompleta kompreno pri la produkta arkitekturo.
- Alta respondeco.
- La risko rompi produktadon.
— Estas malfacile esti bona specialisto en ĉiuj fakoj.
Ne interesas, ni pluiru.
La dua rakonto.
Granda firmao, granda projekto. Estas administra fako kun 5-7 dungitoj kaj pluraj evoluigaj teamoj. Kiam vi venas por labori en tia kompanio, ĉiu administranto pensas, ke vi venis ĉi tien ne por labori pri produkto, sed por rompi ion. Nek la subskribita NDA, nek la elekto ĉe la intervjuo diras alie. Ne, ĉi tiu viro venis ĉi tien kun siaj malpuraj manoj por ruinigi nian kisproduktadon. Sekve, kun tia persono vi bezonas minimuman komunikadon, vi povas ĵeti glumarkon al la ekstremo en respondo. Ne respondu demandojn pri la arkitekturo de la projekto. Estas konsilinde ne doni aliron ĝis la teamestro petos. Kaj kiam oni petas, doni eĉ malpli da privilegioj ol petis. Preskaŭ ĉiu komunikado kun tiaj administrantoj estas englutita de nigra truo inter la disvolva fako kaj la administra fako. Problemoj ne povas esti solvitaj rapide. Kaj vi ne povas alproksimiĝi persone - la administrantoj estas tro okupataj 24/7. (Kion vi faras la tutan tempon?) Kelkaj elfaraj trajtoj:
- Meza deplojo tempo al produktado 4-5h
- Maksimuma deplojo tempo al produktado 9h
- Por programisto, aplikaĵo en produktado estas nigra skatolo, same kiel la produktadservilo mem. Kaj kiom da ili ĝenerale?
- Malbona eldonkvalito, oftaj eraroj
- La programisto ne estas implikita en la eldonprocezo
Nu, kion mi atendis, kompreneble, novuloj ne rajtas en produktado. Nu, bone, kun pacienco, ni komencas akiri la fidon de aliaj. Sed ial, ĝi ne estas tiel simpla kun administrantoj.
Akto 1. La administranto estas nevidebla.
Eldontago, programisto kaj administranto ne komunikas. La administranto ne havas demandojn. Sed kial kompreni poste. La administranto estas principa persono, ne havas tujmesaĝilojn, ne donas telefonnumeron al iu ajn, ne havas profilon en sociaj retoj. Jes, eĉ ne estas foto de li ie ajn, kiel vi aspektas ulo? Ni sidas kun la respondeca administranto dum ĉirkaŭ 15 minutoj en konfuzo, provante establi kontakton kun ĉi tiu Voyager 1, tiam mesaĝo falas sur la kompania poŝto, ke li finis. Ĉu ni korespondos poŝte? Kial ne? Oportuna, ĉu ne? Bone, ni malvarmiĝu. La procezo jam iras, ne estas returniĝo. Ni denove legas la mesaĝon. "Mi finis". Kion vi finis? Kie? Kie serĉi vin? Ĉi tie vi komprenas kial 4 horoj por eldono estas normala. Ni ricevas evoluan ŝokon, sed ni finas la liberigon. Ne plu estas deziro liberigi.
Akto 2. Malĝusta versio.
Sekva eldono. Akirinte sperton, ni komencas formi listojn de la necesaj programoj kaj bibliotekoj por la servilo por administrantoj, indikante versiojn por iuj. Kiel ĉiam, ni ricevas malfortan radiosignalon, ke la administranto finis ion tie. Komenciĝas la regresa testo, kiu mem daŭras ĉirkaŭ unu horon. Ĉio ŝajnas funkcii, sed estas unu kritika cimo. Grava funkcio ne funkcias. La sekvaj horoj estas dancado kun tamburinoj, aŭgurado sur kafgrundo, detala revizio de ĉiu kodo. Administranto diras, ke li faris ĝin. La aplikaĵo skribita de krivorukovy programistoj ne funkcias, kaj la servilo funkcias. Kiuj estas liaj demandoj. Post iom da horo, ni ankoraŭ igas la administranton faligi la version de la biblioteko sur la produktadservilo kaj bingo en la babilejon - ĝi ne estas tio, kion ni bezonas. Ni petas la administranton instali la bezonatan version, respondante ni ricevas, ke li ne povas fari tion pro la foresto de ĉi tiu versio en la OS-pakadministranto. Ĉi tie, el la rubujoj de memoro, la administranto memoras, ke alia administranto jam solvis ĉi tiun problemon, simple kolektante la deziratan version per siaj manoj. Sed ne, ni ne faros tion. La regularo malpermesas. Carl, ni sidas jam de kelkaj horoj, kio estas la regularo?! Ni ricevas alian ŝokon, la liberigo iel finiĝas.
Akto 3, mallonga
Urĝa bileto, ŝlosila funkcio ne funkcias por unu el la uzantoj en produktado. Piku kelkajn horojn, kontrolu. En evolua medio, ĉio funkcias. Estas klara kompreno, ke estus bone rigardi la php-fpm-protokolojn. Ekzistis neniu registradsistemo kiel ELK aŭ Prometheus tiutempe en la projekto. Ni malfermas bileton al la administra fako por ke ili donu aliron al la php-fpm protokoloj sur la servilo. Ĉi tie vi devas kompreni, ke ni ne facile petas aliron, ĉu vi memoras pri la nigra truo kaj la okupado de administrantoj 24/7? Se vi petas ilin rigardi la ŝtipojn mem, tiam ĉi tio estas tasko kun prioritato "ne en ĉi tiu vivo". La bileto estas kreita, ni ricevas tujan respondon de la estro de la administra fako: "Vi ne bezonas aliron al la protokoloj en produktado, skribu sen cimoj." Kurteno.
Akto 4 kaj poste
Ni kolektas dekduon pli da problemoj en produktado, pro malsamaj versioj de bibliotekoj, ne agordita programaro, nepreparita por servilaj ŝarĝoj kaj aliaj problemoj. Kodaj cimoj, kompreneble, ankaŭ okazas, ni ne kulpigos la administrantojn pri ĉiuj pekoj, ni mencios nur unu pli tipan operacion por tiu projekto. Ni havis multajn fonlaboristojn, kiuj estis lanĉitaj per la kontrolisto, kaj kelkaj skriptoj devis esti aldonitaj al cron. Foje tiuj samaj laboristoj ĉesis labori. Sur la vicservilo, la ŝarĝo kreskis kun fulmorapido, kaj malĝojaj uzantoj rigardis la turniĝantan loder. Por rapida riparo, sufiĉis simple rekomenci tiajn laboristojn, sed denove, nur la administranto povis fari tion. Dum tia elementa operacio estis farita, tuta tago povis pasi. Ĉi tie, kompreneble, indas rimarki, ke malrektaj programistoj skribu laboristojn, por ke ili ne falu, sed kiam ili falas, estus bone kompreni kial, kio foje estas neebla pro la manko de aliro al produktado, kompreneble. , kaj kiel rezulto, la manko de programistoj.
Transformoj.
Elteninte ĉion ĉi dum sufiĉe longa tempo, kune kun la teamo, ni komencis stiri en pli sukcesa direkto por ni. Resume, kiuj estis la defioj, kiujn ni alfrontis?
- Manko de altkvalita komunikado inter programistoj kaj la administra fako
- Administrantoj, rezultas (!), tute ne komprenas kiel funkcias la aplikaĵo, kiajn dependecojn ĝi havas kaj kiel ĝi funkcias.
- Programistoj ne komprenas kiel funkcias la produktadmedio kaj, kiel rezulto, ne povas efike respondi al problemoj.
- La deploja procezo daŭras tro longa.
- Malstabilaj eldonoj.
Kion ni faris?
Por ĉiu eldono, listo de Eldonaj Notoj estis formita, kiu inkludis liston de laboro kiu devis esti farita sur la servilo por la venonta eldono por funkcii. La listo enhavis plurajn sekciojn, la laboron kiu devas esti farita de la administranto respondeca por la eldono kaj la programisto. Programistoj ricevis aliron (ne radikon) al ĉiuj produktaj serviloj, kiuj akcelis evoluon ĝenerale kaj problemon solvantan aparte. Ankaŭ la programistoj komprenis kiel funkcias produktado, en kiajn servojn ĝi estas dividita, kie kaj kiom kostas kopioj. De parto, batalŝarĝoj fariĝis pli kompreneblaj, kio sendube influas la kvaliton de la kodo. Komunikado dum la eldonprocezo okazis en la babilejo de unu el la mesaĝistoj. Unue, ni havis protokolon de ĉiuj agoj, kaj due, komunikado okazis en pli proksima medio. Havi historion de agoj pli ol unufoje permesis al novaj dungitoj solvi problemojn pli rapide. Estas paradokso, sed tio ofte helpis la administrantojn mem. Mi ne entreprenos diri certe, sed ŝajnas al mi, ke la administrantoj komencis kompreni pli kiel la projekto funkcias, kiel ĝi estas skribita. Foje ni eĉ dividis kelkajn detalojn unu kun la alia. La meza eldontempo estis reduktita al horo. Kelkfoje ni taŭgas en 30-40 minutoj. La nombro da cimoj estis reduktita plurfoje, se ne dekoj da fojoj. Kompreneble, aliaj faktoroj ankaŭ kontribuis al la redukto de eldontempo, ekzemple, kiel aŭtotestoj. Post ĉiu eldono, ni komencis fari retrospektivojn. Por ke la tuta teamo havu ideon pri kio nova, kio ŝanĝiĝis kaj kio estis forigita. Bedaŭrinde, la administrantoj ne ĉiam venis al ili, nu, la administrantoj estas okupataj... Kiel programisto, mia laborkontento sendube pliiĝis. Kiam vi povas rapide solvi preskaŭ ajnan problemon, kiu estas en via areo de kompetenteco, vi sentas vin kiel ĉevalo. Poste, mi rimarkos, ke ni iom enkondukis DevOps-kulturon, ne tute kompreneble, sed eĉ tiu komenco de la transformo estis impona.
Rakonto tri
Ekfunkciigo. Unu administranto, malgranda disvolva fako. Alveninte, mi estas kompleta nulo, ĉar krom de la poŝta aliro mi havas nenie. Ni skribas al la administranto, ni petas doni aliron. Krome, ekzistas informoj, ke li konscias pri la nova dungito kaj la bezono elsendi ensalutojn / pasvortojn. Ili donas aliron de la deponejo kaj vpn. Kial doni aliron al vikio, teamcity, rundesk? Senutilaj aferoj por persono, kiu estis vokita por skribi la tutan malantaŭan parton. Nur kun la tempo ni akiras aliron al iuj iloj. La alveno, kompreneble, estis renkontita kun nekredemo. Mi provas malrapide ekscii kiel funkcias la projekta infrastrukturo per babilejoj kaj gvidaj demandoj. Esence mi scias nenion. Produktado estas la sama nigra skatolo kiel antaŭe. Sed pli ol tio, ekzistas eĉ nigra skatolo da scenejaj serviloj uzataj por testado. Krom deploji branĉon de la git tie, ni povas fari nenion. Ankaŭ, ni ne povas agordi nian aplikaĵon kiel .env dosierojn. Aliro por tiaj operacioj ne estas permesita. Vi devas okupiĝi pri petado, por ke vi ŝanĝu la linion en la agordo de via aplikaĵo sur la testa servilo. (Ekzistas teorio ke estas esenca por administrantoj senti sin gravaj en la projekto, se ili ne estas petataj ŝanĝi liniojn en la agordoj, ili simple ne estos bezonataj). Nu, kiel ĉiam, ĉu ne oportune? Ĉi tio rapide enuiĝas, post rekta konversacio kun la administranto, ni ekscias, ke la programistoj naskiĝis por skribi malbonan kodon, laŭ naturo ili estas nekompetentaj personecoj kaj estas pli bone teni ilin for de produktado. Sed ĉi tie ankaŭ de testaj serviloj, ĉiaokaze. La konflikto rapide pligrandiĝas. Ne estas komunikado kun la administranto. La situacio pligraviĝas pro la fakto, ke li estas sola. Malsupre estas tipa bildo. Liberigu. Certa funkcio ne funkcias. Ni ekscias, kio okazas dum longa tempo, diversaj ideoj de programistoj estas ĵetitaj en la babilejon, sed la administranto en tia situacio kutime supozas, ke la programistoj kulpas. Poste li skribas en la babilejo, atendu, mi korektis. Kiam oni petas postlasi rakonton kun informoj pri kio estis la problemo, ni ricevas toksajn ekskuzojn. Ne metu vian nazon kie ĝi ne apartenas. Programistoj devas skribi kodon. La situacio, kiam multaj korpaj movoj en la projekto trapasas unu solan homon kaj nur li havas aliron por plenumi la operaciojn, kiujn ĉiuj bezonas, estas ege malĝoja. Tia homo estas terura botelo. Se Devops-ideoj celas redukti tempon al merkatado, tiam tiaj homoj estas la plej malbona malamiko de devops-ideoj. Bedaŭrinde, la kurteno fermiĝas ĉi tie.
PS Iom parolinte pri programistoj kontraŭ administrantoj en babiloj kun homoj, mi renkontis homojn, kiuj kunhavis mian doloron. Sed estis ankaŭ tiuj, kiuj diris, ke ili ne renkontis tian aferon. En unu devops-konferenco, mi demandis Anton Isanin (Alfa-Banko) kiel ili traktis la problemon de botelkolo en formo de administrantoj, al kiuj li diris: "Ni anstataŭigis ilin per butonoj." Parenteze kun lia partopreno. Mi ŝatus kredi, ke ekzistas multe pli bonaj administrantoj ol malamikoj. Kaj jes, la bildo ĉe la komenco estas vera korespondado.
Fonto: www.habr.com