Zhvilluesit janë nga Marsi, administratorët janë nga Venusi

Rastësitë janë të rastësishme, dhe me të vërtetë ndodhi në një planet tjetër...

Do të doja të ndaja tre histori suksesi dhe dështimi rreth mënyrës se si një zhvillues mbështetës punon në një ekip me administratorë.

Historia e parë.
Web studio, numri i punonjësve mund të numërohet me një dorë. Sot ju jeni një dizajner layout, nesër jeni një backender, pasnesër jeni një administrator. Nga njëra anë, ju mund të fitoni përvojë të jashtëzakonshme. Nga ana tjetër, mungon kompetenca në të gjitha fushat. E mbaj mend akoma ditën e parë të punës, jam akoma jeshil, shefi thotë: "Stuko e hapur", por nuk e di se çfarë është. Komunikimi me administratorët është i përjashtuar, sepse ju jeni një administrator vetë. Le të shqyrtojmë të mirat dhe të këqijat e kësaj situate.

+ E gjithë fuqia është në duart tuaja.
+ Nuk ka nevojë të luteni askënd për qasje në server.
+ Koha e shpejtë e reagimit në të gjitha drejtimet.
+ Përmirëson mirë aftësitë.
+ Të ketë një kuptim të plotë të arkitekturës së produktit.

- Përgjegjësi e lartë.
— Rreziku i prishjes së prodhimit.
— Është e vështirë të jesh një specialist i mirë në të gjitha fushat.

Nuk jam i interesuar, le të vazhdojmë

Historia e dytë.
Kompani e madhe, projekt i madh. Ekziston një departament administrimi me 5-7 punonjës dhe disa grupe zhvillimi. Kur vjen për të punuar në një kompani të tillë, çdo administrator mendon se nuk ke ardhur për të punuar në një produkt, por për të thyer diçka. As NDA e nënshkruar dhe as përzgjedhja në intervistë nuk tregojnë ndryshe. Jo, ky njeri erdhi këtu me duart e tij të vogla të pista për të prishur prodhimin tonë të puthjeve. Prandaj, me një person të tillë keni nevojë për një minimum komunikimi; të paktën, mund të hidhni një afishe si përgjigje. Mos u përgjigjeni pyetjeve në lidhje me arkitekturën e projektit. Këshillohet që të mos jepet akses derisa drejtuesi i ekipit të kërkojë. Dhe kur të kërkojë, do t'ia kthejë me privilegje edhe më pak se sa kanë kërkuar. Pothuajse i gjithë komunikimi me administratorë të tillë absorbohet nga vrima e zezë midis departamentit të zhvillimit dhe departamentit të administrimit. Është e pamundur të zgjidhen çështjet menjëherë. Por ju nuk mund të vini personalisht - administratorët janë shumë të zënë 24/7. (Çfarë jeni duke bërë gjatë gjithë kohës?) Disa karakteristika të performancës:

• Koha mesatare e vendosjes në prodhim është 4-5 orë
• Koha maksimale e vendosjes në prodhim 9 orë
• Për një zhvillues, një aplikacion në prodhim është një kuti e zezë, ashtu si vetë serveri i prodhimit. Sa janë gjithsej?
• Cilësi e ulët e lëshimeve, gabime të shpeshta
• Zhvilluesi nuk merr pjesë në procesin e lëshimit

Epo, çfarë prisja, natyrisht, njerëzit e rinj nuk lejohen në prodhim. Epo, në rregull, pasi kemi fituar durimin, ne fillojmë të fitojmë besimin e të tjerëve. Por për disa arsye, gjërat nuk janë aq të thjeshta me administratorët.

Akti 1. Administratori është i padukshëm.
Dita e publikimit, zhvilluesi dhe administratori nuk komunikojnë. Administratori nuk ka pyetje. Por ju e kuptoni pse më vonë. Administratori është një person parimor, nuk ka mesazherë, nuk i jep askujt numrin e tij të telefonit dhe nuk ka një profil në rrjetet sociale. Nuk ka as një foto të tij askund, si dukesh ti çu? Ne ulemi me menaxherin përgjegjës për rreth 15 minuta të hutuar, duke u përpjekur të krijojmë komunikim me këtë Voyager 1, më pas shfaqet një mesazh në emailin e korporatës që ai ka përfunduar. Do të korrespondojmë me postë? Pse jo? I përshtatshëm, apo jo? Epo, mirë, le të qetësohemi. Procesi tashmë është duke u zhvilluar, nuk ka kthim prapa. Lexoni përsëri mesazhin. "Unë mbarova". cfare ke perfunduar? Ku? Ku duhet të të kërkoj? Këtu e kuptoni pse 4 orë për lirim janë normale. Ne marrim një tronditje zhvillimi, por e përfundojmë lëshimin. Nuk ka më asnjë dëshirë për lirim.

Akti 2. Jo ai version.
Lëshimi i radhës. Pasi kemi fituar përvojë, fillojmë të krijojmë lista të softuerit dhe bibliotekave të nevojshme për serverin për administratorët, duke treguar versionet për disa. Si gjithmonë, marrim një sinjal të dobët radio që administratori ka përfunduar diçka atje. Fillon testi i regresionit, i cili në vetvete zgjat rreth një orë. Gjithçka duket se po funksionon, por ka një gabim kritik. Funksionaliteti i rëndësishëm nuk funksionon. Orët e ardhshme ishin vallëzimi me dajre, tregimi i fatit në llum kafeje dhe një rishikim i detajuar i çdo kodi. Administratori thotë se ka bërë gjithçka. Aplikacioni i shkruar nga zhvillues të shtrembër nuk funksionon, por serveri funksionon. Ndonjë pyetje për të? Në fund të një ore, marrim administratorin të dërgojë versionin e bibliotekës në serverin e prodhimit në chat dhe bingo - nuk është ai që na nevojitet. Ne i kërkojmë administratorit të instalojë versionin e kërkuar, por si përgjigje marrim se ai nuk mund ta bëjë këtë për shkak të mungesës së këtij versioni në menaxherin e paketave OS. Këtu, nga skutat e kujtesës së tij, menaxheri kujton se një administrator tjetër e kishte zgjidhur tashmë këtë problem duke montuar thjesht versionin e kërkuar me dorë. Por jo, tanët nuk do ta bëjnë këtë. Rregulloret e ndalojnë. Karl, kemi disa orë që rrimë këtu, sa është afati?! Ne marrim një tjetër tronditje dhe disi përfundojmë lëshimin.

Akti 3, i shkurtër
Biletë urgjente, funksionaliteti kryesor nuk funksionon për një nga përdoruesit në prodhim. Kalojmë nja dy orë duke kërkuar dhe kontrolluar. Në një mjedis zhvillimi, gjithçka funksionon. Ekziston një kuptim i qartë se do të ishte një ide e mirë të shikoni në regjistrat php-fpm. Nuk kishte sisteme log si ELK ose Prometheus në projekt në atë kohë. Ne hapim një biletë në departamentin e administrimit në mënyrë që ata të japin akses në regjistrat php-fpm në server. Këtu duhet të kuptoni se ne po kërkojmë akses për një arsye, a nuk ju kujtohet vrima e zezë dhe administratorët që janë të zënë 24/7? Nëse u kërkoni që të shikojnë vetë shkrimet, atëherë kjo është një detyrë me një përparësi "jo në këtë jetë". Bileta u krijua, morëm një përgjigje të menjëhershme nga kreu i departamentit të administratës: "Nuk duhet të keni nevojë për qasje në regjistrat e prodhimit, shkruani pa gabime." Një perde.

Akti 4 dhe më tej
Ne jemi ende duke mbledhur dhjetëra probleme në prodhim, për shkak të versioneve të ndryshme të bibliotekave, softuerit të pakonfiguruar, ngarkesave të papërgatitura të serverëve dhe problemeve të tjera. Sigurisht, ka edhe gabime kodi, nuk do të fajësojmë administratorët për të gjitha mëkatet, do të përmendim vetëm një operacion tjetër tipik për atë projekt. Ne kishim shumë punëtorë në sfond që u lansuan përmes mbikëqyrësit dhe disa skripta duhej të shtoheshin në cron. Ndonjëherë të njëjtët punëtorë pushonin së punuari. Ngarkesa në serverin e radhës u rrit me shpejtësi rrufeje dhe përdoruesit e trishtuar shikonin ngarkuesin rrotullues. Për të rregulluar shpejt punëtorë të tillë, mjaftonte thjesht rinisja e tyre, por përsëri, vetëm një administrator mund ta bënte këtë. Ndërkohë që po kryhej një operacion i tillë bazë, mund të kalonte një ditë e tërë. Këtu, sigurisht, vlen të theksohet se programuesit e shtrembër duhet t'i shkruajnë punëtorët në mënyrë që ata të mos rrëzohen, por kur ata bien, do të ishte mirë të kuptonim pse, e cila ndonjëherë është e pamundur për shkak të mungesës së aksesit në prodhim, natyrisht, dhe si pasojë mungesa e regjistrave nga zhvilluesi.

Shpërfytyrimi.
Duke i duruar të gjitha këto për një kohë të gjatë, së bashku me ekipin filluam të drejtohemi në një drejtim që ishte më i suksesshëm për ne. Për ta përmbledhur, me çfarë problemesh u përballëm?

• Mungesa e komunikimit cilësor ndërmjet zhvilluesve dhe departamentit të administratës
• Administratorët, rezulton(!), nuk e kuptojnë fare se si është i strukturuar aplikacioni, çfarë varësish ka dhe si funksionon.
• Zhvilluesit nuk e kuptojnë se si funksionon mjedisi i prodhimit dhe, si rezultat, nuk mund t'i përgjigjen në mënyrë efektive problemeve.
• Procesi i vendosjes zgjat shumë.
• Lëshime të paqëndrueshme.

Çfarë kemi bërë?
Për çdo version, u krijua një listë e Shënimeve të Publikimit, e cila përfshinte një listë të punës që duhet të bëhet në server që versioni tjetër të funksionojë. Lista përmbante disa seksione, punë që duhet të kryhen nga administratori, personi përgjegjës për lëshimin dhe zhvilluesi. Zhvilluesit morën akses jo-root në të gjithë serverët e prodhimit, gjë që përshpejtoi zhvillimin në përgjithësi dhe zgjidhjen e problemeve në veçanti. Zhvilluesit gjithashtu kanë një kuptim se si funksionon prodhimi, në cilat shërbime ndahet, ku dhe sa kushtojnë kopjet. Disa nga ngarkesat luftarake janë bërë më të qarta, gjë që padyshim ndikon në cilësinë e kodit. Komunikimi gjatë procesit të lëshimit u zhvillua në bisedën e një prej lajmëtarëve të çastit. Së pari, kishim një regjistër të të gjitha veprimeve dhe së dyti, komunikimi bëhej në një mjedis më të afërt. Pasja e një historie veprimesh ka lejuar më shumë se një herë punonjësit e rinj të zgjidhin problemet më shpejt. Është një paradoks, por kjo shpesh i ka ndihmuar vetë administratorët. Nuk do të marr përsipër të them me siguri, por më duket se administratorët kanë filluar të kuptojnë më shumë se si funksionon projekti dhe si është shkruar. Ndonjëherë ne ndamë edhe disa detaje me njëri-tjetrin. Koha mesatare e lëshimit është reduktuar në një orë. Ndonjëherë mbaronim për 30-40 minuta. Numri i gabimeve është ulur ndjeshëm, nëse jo dhjetëfish. Sigurisht, në uljen e kohës së lëshimit ndikuan edhe faktorë të tjerë, si autotestet. Pas çdo lëshimi, filluam të bënim retrospektiva. Kështu që i gjithë ekipi të ketë një ide se çfarë është e re, çfarë ka ndryshuar dhe çfarë është hequr. Fatkeqësisht, administratorët nuk kanë ardhur gjithmonë tek ata, mirë, administratorët janë të zënë... Padyshim që kënaqësia ime në punë si zhvillues është rritur. Kur mund të zgjidhni shpejt pothuajse çdo problem që është në fushën tuaj të kompetencës, ndiheni në krye. Më vonë, do të kuptoj se deri diku kemi futur një kulturë devops, jo plotësisht, sigurisht, por edhe ai fillim i transformimit ishte mbresëlënës.

Historia e tretë
Një startup. Një administrator, një ekip i vogël zhvillimi. Kur u bashkova për herë të parë, isha një zero e plotë, pasi nuk kisha qasje në asgjë tjetër përveç email-it tim. I shkruam administratorit duke kërkuar qasje. Ai gjithashtu dinte për punonjësin e ri dhe nevojën për të dhënë hyrje dhe fjalëkalime. Ata më dhanë qasje në depo dhe përfshirëPse t'u jepet akses Wiki-t, TeamCity-t dhe RunDesk-ut? E padobishme për dikë të punësuar për të shkruar të gjithë backend-in. Vetëm me kalimin e kohës fitojmë akses në disa mjete. Natyrisht, mbërritja ime pritet me mosbesim. Po përpiqem ngadalë të krijoj një ide për infrastrukturën e projektit përmes bisedave dhe pyetjeve udhëheqëse. Kryesisht nuk mësoj asgjë. Prodhimi është si një kuti e zezë si gjithmonë. Por edhe serverat e skenës që përdoren për testim janë kuti të zeza këtu. Ne nuk mund të bëjmë asgjë tjetër përveçse të vendosim degë nga Git. Gjithashtu nuk mund të konfigurojmë aplikacionin tonë, siç janë skedarët .env. Qasja për operacione të tilla nuk lejohet. Duhet të lutesh që të ndryshosh një rresht në konfigurimin e aplikacionit tënd në serverin e testimit. (Ekziston një teori që administratorët kanë nevojë jetike të ndihen si njerëzit më të rëndësishëm në projekt; nëse nuk u kërkohet të ndryshojnë rreshtat e konfigurimit, thjesht nuk do të nevojiten.) Si gjithmonë, a nuk është e përshtatshme? Kjo bëhet shpejt e lodhshme. Pas një bisede të drejtpërdrejtë me administratorin, zbulojmë se zhvilluesit kanë lindur për të shkruar kod të keq, janë të paaftë nga natyra dhe është më mirë t'i mbani larg prodhimit. Dhe pastaj është mjedisi i testimit. serverat Për çdo rast. Konflikti përshkallëzohet shpejt. Nuk ka komunikim me administratorin. Situata përkeqësohet nga fakti që ai është vetëm. Pastaj vjen skenari tipik. Publikimi. Një veçori e caktuar nuk po funksionon. Ne kalojmë shumë kohë duke u përpjekur të kuptojmë se çfarë po ndodh, me zhvilluesit që hedhin ide të ndryshme në bisedë, por administratori zakonisht supozon se zhvilluesit janë fajtorë. Pastaj ai shkruan në bisedë, "Prit, e rregullova unë." Kur kërkojmë të lëmë një histori me informacion në lidhje me problemin, marrim justifikime toksike. Ata thonë, "Mos e fus hundën aty ku nuk i takon." Zhvilluesit duhet të shkruajnë kod. Një situatë ku shumë procese projekti kalojnë përmes një personi të vetëm, dhe vetëm ata kanë qasje për të kryer operacionet që u nevojiten të gjithëve, është jashtëzakonisht e trishtueshme. Një person i tillë është një pengesë e tmerrshme. Nëse idetë e DevOps përpiqen të zvogëlojnë kohën e daljes në treg, atëherë njerëz të tillë janë armiku më i keq i ideve të DevOps. Fatkeqësisht, këtu mbyllet perdja.

PS Pasi fola pak për zhvilluesit vs administratorët në biseda me njerëz, takova njerëz që ndanë dhimbjen time. Por ka pasur edhe nga ata që kanë thënë se nuk kanë hasur ndonjëherë në diçka të tillë. Në një konferencë devops, pyeta Anton Isanin (Alfa Bank) se si e trajtuan problemin e bllokimit në formën e administratorëve, për të cilin ai tha: "Ne i zëvendësuam me butona". Meqe ra fjala podcast me pjesëmarrjen e tij. Do të doja të besoja se ka më shumë administratorë të mirë sesa armiq. Dhe po, fotografia në fillim është një korrespondencë e vërtetë.

Burimi: www.habr.com