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ë
Fillimi. Një administrator, departament i vogël zhvillimi. Me të mbërritur jam një zero e plotë, sepse... Nuk kam akses askund përveçse nga posta. Ne i shkruajmë administratorit dhe kërkojmë qasje. Përveç kësaj, ka informacione se ai është në dijeni të punonjësit të ri dhe nevojës për të lëshuar hyrje/fjalëkalime. Ata japin akses nga depoja dhe VPN. Pse t'i jepet akses në wiki, teamcity, rundesk? Gjëra të kota për një person që u thirr për të shkruar të gjithë pjesën e pasme. Vetëm me kalimin e kohës ne fitojmë akses në disa mjete. Ardhja, natyrisht, u prit me mosbesim. Po përpiqem të kuptoj ngadalë se si funksionon infrastruktura e projektit përmes bisedave dhe pyetjeve kryesore. Në thelb nuk njoh asgjë. Prodhimi është e njëjta kuti e zezë si më parë. Por më shumë se kaq, edhe serverët e skenës që përdoren për testim janë një kuti e zezë. Ne nuk mund të bëjmë asgjë tjetër përveçse të vendosim një degë nga Git atje. Ne gjithashtu nuk mund ta konfigurojmë aplikacionin tonë si skedarët .env. Aksesi për operacione të tilla nuk jepet. Ju duhet të luteni për të ndryshuar një linjë në konfigurimin e aplikacionit tuaj në serverin e testimit. (Ekziston një teori që është jetike që administratorët të ndihen të rëndësishëm në projekt; nëse nuk u kërkohet të ndryshojnë linjat në konfigurime, ato thjesht nuk do të nevojiten). Epo, si gjithmonë, a nuk është i përshtatshëm? Kjo shpejt bëhet e mërzitshme, pas një bisede të drejtpërdrejtë me administratorin zbulojmë se zhvilluesit kanë lindur për të shkruar kod të keq, nga natyra janë individë të paaftë dhe është më mirë t'i mbajmë larg prodhimit. Por këtu edhe nga serverët e testimit, për çdo rast. Konflikti po përshkallëzohet shpejt. Nuk ka asnjë komunikim me administratorin. Situata rëndohet nga fakti se ai është vetëm. Më poshtë është një foto tipike. Lirimi. Një funksion i caktuar nuk funksionon. Na duhet shumë kohë për të kuptuar se çfarë po ndodh, ide të ndryshme nga zhvilluesit hidhen në chat, por administratori në një situatë të tillë zakonisht supozon se fajin e kanë zhvilluesit. Pastaj shkruan ne chat, prit, e korrigjova. Kur na kërkohet të lëmë një histori pas me informacione se cili ishte problemi, ne marrim justifikime toksike. Si, mos e ngul hundën aty ku nuk i takon. Zhvilluesit duhet të shkruajnë kodin. Situata kur shumë lëvizje të trupit në një projekt kalojnë përmes një personi të vetëm dhe vetëm ai ka akses për të kryer operacionet për të cilat të gjithë kanë nevojë ë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 për në treg, atëherë njerëz të tillë janë armiku më i keq i ideve të Devops. Për fat të keq, perdja mbyllet këtu.
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 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