Naključja so naključna in res je bilo na drugem planetu...
Rad bi delil tri zgodbe o uspehu in neuspehu o tem, kako zaledni razvijalec deluje v skupini s skrbniki.
Zgodba ena.
Spletni studio, število zaposlenih lahko preštejemo z eno roko. Danes ste oblikovalec postavitev, jutri ste backender, pojutrišnjem ste skrbnik. Po eni strani lahko pridobite ogromno izkušenj. Po drugi strani pa je pomanjkanje kompetenc na vseh področjih. Še vedno se spomnim prvega delovnega dne, še vedno sem zelen, šef pravi: "Odprti kit," pa ne vem, kaj je to. Komunikacija z administratorji je izključena, ker sam si admin. Razmislimo o prednostih in slabostih te situacije.
+ Vsa moč je v vaših rokah.
+ Nikogar ni treba prositi za dostop do strežnika.
+ Hiter odzivni čas v vseh smereh.
+ Dobro izboljša veščine.
+ Popolnoma razumeti arhitekturo izdelka.
— Visoka odgovornost.
— Nevarnost prekinitve proizvodnje.
— Težko je biti dober strokovnjak na vseh področjih.
Ne zanima, gremo naprej
Druga zgodba.
Veliko podjetje, velik projekt. Deluje administrativni oddelek s 5-7 zaposlenimi in več razvojnimi skupinami. Ko prideš delat v tako podjetje, vsak admin misli, da nisi prišel sem delat produkt, ampak nekaj pokvariti. Niti podpisana NDA niti izbor na razgovoru ne kaže drugače. Ne, ta moški je prišel sem s svojimi umazanimi rokicami, da bi uničil našo produkcijo poljubljanja. Zato s takšno osebo potrebujete najmanj komunikacije, vsaj v odgovor lahko vržete nalepko. Ne odgovarjajte na vprašanja o arhitekturi projekta. Priporočljivo je, da dostopa ne odobrite, dokler vodja ekipe ne vpraša. In ko bo zahteval, mu bo vrnil s še manj privilegiji, kot so zahtevali. Skoraj vso komunikacijo s takšnimi skrbniki posrka črna luknja med razvojnim in administrativnim oddelkom. Težave je nemogoče rešiti takoj. Vendar ne morete priti osebno - skrbniki so preveč zaposleni 24/7. (Kaj počnete ves čas?) Nekatere značilnosti delovanja:
- Povprečni čas uvajanja v proizvodnji je 4-5 ur
- Najdaljši čas uvajanja v proizvodnji 9 ur
- Za razvijalca je aplikacija v produkciji črna skrinjica, tako kot sam produkcijski strežnik. Koliko jih je skupaj?
- Nizka kakovost izdaj, pogoste napake
- Razvijalec ne sodeluje v procesu izdaje
Pa kaj sem pričakoval, seveda novi ljudje ne smejo v proizvodnjo. No, v redu, ko pridobimo potrpljenje, začnemo pridobivati zaupanje drugih. Toda iz nekega razloga stvari z administratorji niso tako preproste.
Akt 1. Administrator je neviden.
Dan izdaje, razvijalec in skrbnik ne komunicirata. Administrator nima vprašanj. Toda pozneje boste razumeli, zakaj. Administrator je načelna oseba, nima messengerjev, nikomur ne izda svoje telefonske številke in nima profila na družbenih omrežjih. Nikjer ni niti njegove fotografije, kako izgledaš, stari? Približno 15 minut začudeno sedimo z odgovornim vodjo in poskušamo vzpostaviti komunikacijo s tem Voyagerjem 1, nato pa se v službeni e-pošti pojavi sporočilo, da je končal. Si bova dopisovala po pošti? Zakaj ne? Priročno, kajne? No, v redu, ohladimo se. Proces je že v teku, poti nazaj ni. Še enkrat preberi sporočilo. "Končal sem". Kaj si končal? Kje? Kje naj te iščem? Tukaj razumete, zakaj so 4 ure za sprostitev normalne. Dobimo razvojni šok, vendar dokončamo izdajo. Nobene želje po izpustitvi ni več.
Act 2. Ne ta različica.
Naslednja izdaja. Po pridobljenih izkušnjah začnemo ustvarjati sezname potrebne programske opreme in knjižnic za strežnik za skrbnike, pri čemer navedemo različice za nekatere. Kot vedno prejmemo šibek radijski signal, da je administrator tam nekaj dokončal. Začne se regresijski test, ki traja približno eno uro. Zdi se, da vse deluje, vendar obstaja ena kritična napaka. Pomembna funkcija ne deluje. Naslednjih nekaj ur je sledil ples s tamburaši, vedeževanje na kavni usedlini in podroben pregled vsake šifre. Admin pravi, da je naredil vse. Aplikacija, ki so jo napisali pokvarjeni razvijalci, ne deluje, strežnik pa deluje. Imate vprašanja zanj? Ob koncu ene ure dobimo od skrbnika, da pošlje različico knjižnice na produkcijskem strežniku v klepet in bingo - to ni tista, ki jo potrebujemo. Administratorja prosimo za namestitev zahtevane različice, vendar v odgovoru prejmemo, da tega ne more storiti, ker te različice ni v upravitelju paketov OS. Tukaj, iz globin svojega spomina, se upravitelj spomni, da je drug administrator že rešil to težavo tako, da je preprosto ročno sestavil zahtevano različico. Ampak ne, naši tega ne bodo naredili. Predpisi prepovedujejo. Karl, tukaj sediva že nekaj ur, kakšna je časovna omejitev?! Doživimo nov šok in nekako zaključimo izdajo.
3. dejanje, kratko
Nujna vozovnica, ključna funkcionalnost ne deluje za enega od uporabnikov v produkciji. Nekaj ur preživljamo in preverjamo. V razvojnem okolju vse deluje. Obstaja jasno razumevanje, da bi bilo dobro pogledati v dnevnike php-fpm. Takrat na projektu ni bilo log sistemov, kot sta ELK ali Prometheus. Administratorskemu oddelku odpremo vstopnico, da omogočijo dostop do dnevnikov php-fpm na strežniku. Tu morate razumeti, da prosimo za dostop z razlogom, ali se ne spomnite črne luknje in skrbnikov, ki so zaposleni 24/7? Če jih prosite, naj sami pogledajo dnevnike, potem je to naloga s prioriteto »ne v tem življenju«. Vstopnica je bila ustvarjena, takoj smo prejeli odgovor vodje administrativnega oddelka: "Ne potrebujete dostopa do produkcijskih dnevnikov, pišite brez napak." Zavesa.
4. dejanje in naprej
Še vedno zbiramo na desetine težav v proizvodnji zaradi različnih različic knjižnic, nekonfigurirane programske opreme, nepripravljenih obremenitev strežnika in drugih težav. Seveda se pojavljajo tudi napake v kodi, za vse grehe ne bomo krivili skrbnikov, omenili bomo le še eno tipično operacijo za ta projekt. Imeli smo precej delavcev v ozadju, ki so bili zagnani prek nadzornika, in nekaj skript je bilo treba dodati v cron. Včasih so ti isti delavci nehali delati. Obremenitev strežnika čakalne vrste je naraščala s svetlobno hitrostjo in žalostni uporabniki so pogledali vrteči se nakladalnik. Za hitro popravilo takšnih delavcev je bilo dovolj, da jih preprosto znova zaženete, vendar je to lahko storil le skrbnik. Med izvajanjem tako osnovne operacije je lahko minil cel dan. Tukaj seveda velja opozoriti, da bi morali pokvarjeni programerji pisati delavce, da se ti ne zrušijo, a ko padejo, bi bilo lepo razumeti, zakaj, kar je včasih zaradi nedostopa do produkcije nemogoče, seveda in posledično pomanjkanje dnevnikov razvijalca.
Preobrazba.
Ko smo vse to prenašali že kar dolgo časa, smo skupaj z ekipo začeli krmariti v smer, ki je bila za nas uspešnejša. Če povzamem, s kakšnimi težavami smo se srečevali?
- Pomanjkanje kakovostne komunikacije med razvijalci in administracijo
- Izkazalo se je (!), da skrbniki sploh ne razumejo, kako je aplikacija strukturirana, kakšne odvisnosti ima in kako deluje.
- Razvijalci ne razumejo delovanja produkcijskega okolja in se posledično ne morejo učinkovito odzvati na težave.
- Postopek uvajanja traja predolgo.
- Nestabilne izdaje.
Kaj smo storili?
Za vsako izdajo je bil ustvarjen seznam opomb ob izdaji, ki je vključeval seznam dela, ki ga je treba opraviti na strežniku, da bo naslednja izdaja delovala. Seznam je vseboval več razdelkov, dela, ki naj bi jih opravil skrbnik, odgovorna oseba za izdajo in razvijalec. Razvijalci so prejeli nekorenski dostop do vseh produkcijskih strežnikov, kar je pospešilo razvoj na splošno in še posebej reševanje problemov. Razvijalci tudi razumejo, kako proizvodnja poteka, na katere storitve je razdeljena, kje in koliko stanejo replike. Nekatere bojne obremenitve so postale jasnejše, kar nedvomno vpliva na kakovost kode. Komunikacija med postopkom izdaje je potekala v klepetu enega od takojšnjih sporočil. Prvič, imeli smo dnevnik vseh akcij, drugič pa je komunikacija potekala v ožjem okolju. Zgodovina dejanj je novim zaposlenim več kot enkrat omogočila hitrejše reševanje težav. To je paradoks, vendar je to pogosto pomagalo skrbnikom samim. Ne bom se zavezal z gotovostjo, vendar se mi zdi, da so skrbniki začeli bolj razumeti, kako projekt deluje in kako je napisan. Včasih sva si celo povedala kakšne podrobnosti. Povprečni čas sprostitve je skrajšan na eno uro. Včasih smo bili gotovi v 30-40 minutah. Število hroščev se je znatno zmanjšalo, če ne desetkrat. Seveda so na skrajšanje časa sprostitve vplivali tudi drugi dejavniki, kot na primer avtotesti. Po vsaki izdaji smo začeli izvajati retrospektive. Tako da ima celotna ekipa predstavo o tem, kaj je novega, kaj je spremenjeno in kaj je bilo odstranjeno. Žal admini niso vedno prišli do njih, no, admini so zaposleni... Moje zadovoljstvo pri delu kot razvijalca se je nedvomno povečalo. Ko lahko hitro rešite skoraj vsako težavo, ki je v vaši pristojnosti, se počutite na vrhu. Kasneje bom razumel, da smo do neke mere uvedli devops kulturo, seveda ne povsem, a že ta začetek preobrazbe je bil impresiven.
Zgodba tretja
Začeti. En skrbnik, majhen razvojni oddelek. Ob prihodu sem čista ničla, saj... Nimam dostopa nikjer, razen iz pošte. Pišemo adminu in prosimo za dostop. Poleg tega obstajajo informacije, da je seznanjen z novim zaposlenim in potrebo po izdaji prijav/gesel. Omogočajo dostop iz repozitorija in VPN. Zakaj omogočiti dostop do wiki, teamcity, rundesk? Neuporabne stvari za osebo, ki je bila poklicana, da napiše celoten backend del. Šele čez čas dobimo dostop do nekaterih orodij. Prihod je seveda naletel na nezaupanje. S pomočjo klepetov in vodilnih vprašanj počasi poskušam dobiti občutek, kako deluje infrastruktura projekta. V bistvu ničesar ne prepoznam. Proizvodnja je ista črna skrinjica kot prej. Toda več kot to, celo odrski strežniki, ki se uporabljajo za testiranje, so črna skrinjica. Ne moremo storiti ničesar drugega, kot da tam namestimo vejo Gita. Prav tako ne moremo konfigurirati naše aplikacije kot datoteke .env. Dostop za takšne operacije ni odobren. Prositi morate, da spremenite vrstico v konfiguraciji vaše aplikacije na testnem strežniku. (Obstaja teorija, da je za skrbnike ključnega pomena, da se počutijo pomembne pri projektu; če niso pozvani, da spremenijo vrstice v konfiguracijah, preprosto ne bodo potrebni). No, kot vedno, ali ni priročno? To hitro postane dolgočasno, po neposrednem pogovoru z adminom ugotovimo, da so razvijalci rojeni za pisanje slabe kode, so po naravi nesposobni posamezniki in jih je bolje oddaljiti od produkcije. Tukaj pa tudi iz testnih strežnikov, za vsak slučaj. Konflikt se hitro stopnjuje. Ni komunikacije z adminom. Situacijo otežuje dejstvo, da je sam. Sledi tipična slika. Sprostitev. Določene funkcije ne delujejo. Dolgo rabimo, da ugotovimo, kaj se dogaja, v klepet se mečejo razne ideje razvijalcev, a admin v taki situaciji običajno domneva, da so krivi razvijalci. Potem piše v klepetu, počakaj, sem ga popravil. Ko nas prosijo, naj za seboj pustimo zgodbo z informacijami o tem, v čem je težava, dobimo strupene izgovore. Kot, ne vtikaj nosu, kamor mu ni mesto. Razvijalci morajo napisati kodo. Situacija, ko veliko telesnih gibov v projektu poteka skozi eno samo osebo in ima le ta dostop do operacij, ki jih vsi potrebujejo, je izjemno žalostna. Takšna oseba je strašno ozko grlo. Če si ideje Devops prizadevajo skrajšati čas do trženja, potem so takšni ljudje najhujši sovražnik idej Devops. Na žalost se tu zastor zapre.
P.S. Potem ko sem v klepetih z ljudmi malo govoril o razvijalcih proti skrbnikom, sem srečal ljudi, ki so delili mojo bolečino. Bili pa so tudi takšni, ki so povedali, da se s čim takim še niso srečali. Na eni devops konferenci sem Antona Isanina (Alfa Bank) vprašal, kako so se spopadli s problemom ozkega grla v obliki adminov, na kar je rekel: “Zamenjali smo jih z gumbi.” Mimogrede z njegovo udeležbo. Rad bi verjel, da je dobrih adminov veliko več kot sovražnikov. In ja, slika na začetku je prava korespondenca.
Vir: www.habr.com