Slučajnosti su slučajne, i doista je bilo na drugom planetu...
Želio bih podijeliti tri priče o uspjehu i neuspjehu o tome kako pozadinski programer radi u timu s administratorima.
Priča prva.
Web studio, broj zaposlenih se može izbrojati jednom rukom. Danas ste layout dizajner, sutra ste backender, prekosutra ste admin. S jedne strane, možete steći ogromno iskustvo. S druge strane, nedostaje kompetencija u svim područjima. Još se sjećam prvog radnog dana, još sam zelen, šef kaže: "Otvori kit", ali ne znam što je to. Komunikacija s adminima je isključena, jer ti si sam admin. Razmotrimo prednosti i mane ove situacije.
+ Sva moć je u vašim rukama.
+ Nema potrebe moliti bilo koga za pristup poslužitelju.
+ Brzo vrijeme reakcije u svim smjerovima.
+ Dobro poboljšava vještine.
+ Imajte potpuno razumijevanje arhitekture proizvoda.
— Visoka odgovornost.
— Rizik od prekida proizvodnje.
— Teško je biti dobar stručnjak u svim područjima.
Ne zanima me, idemo dalje
Druga priča.
Velika tvrtka, veliki projekt. Postoji administrativni odjel sa 5-7 zaposlenika i nekoliko razvojnih grupa. Kad dođeš raditi u takvu tvrtku, svaki admin misli da nisi došao raditi na proizvodu, nego nešto pokvariti. Niti potpisani NDA niti odabir na razgovoru ne pokazuju drugačije. Ne, ovaj čovjek je došao ovamo sa svojim prljavim malim ručicama da uništi našu produkciju ljubljenja. Stoga vam je s takvom osobom potrebna minimalna komunikacija, u najmanju ruku možete baciti naljepnicu kao odgovor. Ne odgovarajte na pitanja o arhitekturi projekta. Preporučljivo je ne odobriti pristup dok voditelj tima ne zatraži. A kad traži, vratit će s još manje privilegija nego što su tražili. Gotovo svu komunikaciju s takvim administratorima apsorbira crna rupa između odjela za razvoj i odjela administracije. Nemoguće je brzo riješiti probleme. Ali ne možete doći osobno - administratori su previše zauzeti 24/7. (Što radiš cijelo vrijeme?) Neke karakteristike izvedbe:
- Prosječno vrijeme postavljanja do proizvodnje je 4-5 sati
- Maksimalno vrijeme implementacije u proizvodnji 9 sati
- Za programera, aplikacija u produkciji je crna kutija, baš kao i sam produkcijski poslužitelj. Koliko ih je ukupno?
- Niska kvaliteta izdanja, česte pogreške
- Programer ne sudjeluje u procesu izdavanja
Pa što sam očekivao, naravno, novi ljudi ne smiju u proizvodnju. Pa, u redu, stjecanjem strpljenja počinjemo stjecati povjerenje drugih. Ali iz nekog razloga stvari s administratorima nisu tako jednostavne.
Čin 1. Administrator je nevidljiv.
Dan izlaska, programer i administrator ne komuniciraju. Admin nema pitanja. Ali kasnije ćete shvatiti zašto. Admin je principijelna osoba, nema messengere, nikome ne daje svoj broj telefona i nema profil na društvenim mrežama. Nigdje nema čak ni njegove fotografije, kako ti izgledaš stari? Sjedimo s odgovornim menadžerom oko 15 minuta u nedoumici, pokušavajući uspostaviti komunikaciju s tim Voyagerom 1, a onda se u korporativnom e-mailu pojavi poruka da je završio. Hoćemo li se dopisivati poštom? Zašto ne? Zgodno, zar ne? Pa dobro, ohladimo se. Proces je već u tijeku, nema povratka. Ponovno pročitajte poruku. "Završio sam". Što ste završili? Gdje? Gdje da te tražim? Ovdje vam je jasno zašto je 4 sata za puštanje normalno. Doživljavamo razvojni šok, ali završavamo izdanje. Više nema želje za puštanjem.
Čin 2. Ne ta verzija.
Sljedeće izdanje. Stekavši iskustvo, počinjemo stvarati popise potrebnog softvera i biblioteka za poslužitelj za administratore, navodeći verzije za neke. Kao i uvijek, dobivamo slab radio signal da je admin tu nešto završio. Započinje regresijski test koji sam traje oko sat vremena. Čini se da sve radi, ali postoji jedna kritična greška. Važna funkcija ne radi. Sljedećih nekoliko sati bili su ples uz tamburaše, gatanje na talogu kave i detaljno pregledavanje svake šifre. Admin kaže da je sve napravio. Aplikacija koju su napisali pokvareni programeri ne radi, ali server radi. Ima li pitanja za njega? Na kraju jednog sata tražimo od administratora da pošalje verziju biblioteke na produkcijskom poslužitelju u chat i bingo - to nije ona koju trebamo. Molimo administratora da instalira potrebnu verziju, ali kao odgovor dobivamo da on to ne može učiniti zbog nepostojanja ove verzije u upravitelju OS paketa. Ovdje se iz zadubljenja sjećanja upravitelj prisjeća da je jedan drugi admin već riješio ovaj problem tako što je jednostavno ručno sastavio potrebnu verziju. Ali ne, naši to neće učiniti. Propisi zabranjuju. Karl, sjedimo ovdje već nekoliko sati, koje je vremensko ograničenje?! Dobivamo novi šok i nekako završavamo izdanje.
Čin 3, kratak
Hitna karta, ključna funkcija ne radi za jednog od korisnika u produkciji. Proveli smo par sati čeprkajući i provjeravajući. U razvojnom okruženju sve funkcionira. Postoji jasno razumijevanje da bi bilo dobro pogledati u php-fpm zapisnike. U to vrijeme na projektu nije bilo log sustava kao što su ELK ili Prometheus. Otvaramo kartu odjelu administracije kako bi oni dali pristup php-fpm zapisima na poslužitelju. Ovdje morate shvatiti da tražimo pristup s razlogom, zar se ne sjećate da su crna rupa i administratori zauzeti 24/7? Ako ih zamolite da sami pogledaju dnevnike, onda je to zadatak s prioritetom "ne u ovom životu". Ulaznica je kreirana, dobili smo trenutni odgovor od voditelja odjela administracije: "Ne biste trebali imati pristup zapisima proizvodnje, pišite bez grešaka." Zavjesa.
4. čin i dalje
Još uvijek prikupljamo desetke problema u proizvodnji, zbog različitih verzija biblioteka, nekonfiguriranog softvera, nepripremljenog opterećenja poslužitelja i drugih problema. Naravno, ima i grešaka u kodu, nećemo kriviti admine za sve grijehe, samo ćemo spomenuti još jednu tipičnu operaciju za taj projekt. Imali smo dosta pozadinskih radnika koji su se pokretali preko supervizora, a neke skripte je trebalo dodati u cron. Ponekad su ti isti radnici prestajali raditi. Opterećenje poslužitelja čekanja raslo je brzinom munje, a tužni su korisnici gledali u utovarivač koji se vrtio. Da biste brzo popravili takve radnike, bilo je dovoljno jednostavno ih ponovno pokrenuti, ali opet, to je mogao učiniti samo administrator. Dok se izvodi tako temeljna operacija, znao je proći i cijeli dan. Ovdje, naravno, vrijedi napomenuti da bi pokvareni programeri trebali pisati radnike kako se ne bi srušili, ali kada padnu, bilo bi lijepo shvatiti zašto, što je ponekad nemoguće zbog nedostatka pristupa produkciji, Naravno, i kao posljedica toga, nedostatak zapisnika od programera.
Preobraženje.
Nakon što smo sve to dugo trpjeli, zajedno s timom počeli smo se usmjeravati u smjeru koji je za nas bio uspješniji. Ukratko, s kojim problemima smo se suočavali?
- Nedostatak kvalitetne komunikacije između programera i administracije
- Administratori, pokazalo se(!), uopće ne razumiju kako je aplikacija strukturirana, koje ovisnosti ima i kako radi.
- Programeri ne razumiju kako proizvodno okruženje funkcionira i, kao rezultat toga, ne mogu učinkovito odgovoriti na probleme.
- Proces postavljanja predugo traje.
- Nestabilna izdanja.
Što smo učinili?
Za svako izdanje generiran je popis napomena o izdanju, koji je uključivao popis posla koji je potrebno obaviti na poslužitelju da bi sljedeće izdanje radilo. Popis je sadržavao nekoliko odjeljaka, posao koji bi trebao obaviti administrator, osoba odgovorna za izdanje i programer. Programeri su dobili ne-root pristup svim proizvodnim poslužiteljima, što je ubrzalo razvoj općenito, a posebno rješavanje problema. Programeri također razumiju kako proizvodnja funkcionira, na koje je usluge podijeljena, gdje i koliko koštaju replike. Neka borbena opterećenja postala su jasnija, što nedvojbeno utječe na kvalitetu koda. Komunikacija tijekom procesa puštanja odvijala se u chatu jednog od instant messengera. Prvo, imali smo dnevnik svih akcija, a drugo, komunikacija se odvijala u bližem okruženju. Povijest radnji više je puta omogućila novim zaposlenicima brže rješavanje problema. Paradoksalno, ali to je često pomoglo samim administratorima. Neću se obvezati reći sa sigurnošću, ali čini mi se da su administratori počeli više shvaćati kako projekt funkcionira i kako je napisan. Ponekad smo čak međusobno dijelili neke detalje. Prosječno vrijeme puštanja smanjeno je na sat vremena. Ponekad smo bili gotovi za 30-40 minuta. Broj grešaka značajno se smanjio, ako ne i deseterostruko. Naravno, i drugi čimbenici utjecali su na smanjenje vremena izlaska, poput autotestova. Nakon svakog izdanja počeli smo raditi retrospektive. Tako da cijeli tim ima ideju o tome što je novo, što je promijenjeno, a što je uklonjeno. Nažalost, admini im nisu uvijek dolazili, dobro, admini su zauzeti... Moje zadovoljstvo poslom kao programera nedvojbeno je poraslo. Kada možete brzo riješiti gotovo svaki problem koji je u vašem području nadležnosti, osjećate se na vrhu. Kasnije ću shvatiti da smo donekle uveli devops kulturu, ne u potpunosti, naravno, ali i taj početak transformacije je bio impresivan.
Priča treća
Pokretanje. Jedan administrator, mali razvojni odjel. Po dolasku sam potpuna nula, jer... Nemam pristup nigdje osim s maila. Pišemo adminu i tražimo pristup. Osim toga, postoji informacija da je upoznat s novim zaposlenikom i potrebom izdavanja prijava/lozinki. Omogućuju pristup iz repozitorija i VPN-a. Zašto dati pristup wikiju, teamcityju, rundesku? Beskorisne stvari za osobu koja je pozvana da napiše cijeli backend dio. Tek s vremenom dobivamo pristup nekim alatima. Dolazak je, naravno, dočekan s nepovjerenjem. Kroz razgovore i sugestivna pitanja pokušavam polako steći osjećaj kako funkcionira infrastruktura projekta. Uglavnom ne prepoznajem ništa. Proizvodnja je ista crna kutija kao i prije. Ali više od toga, čak su i pozornice poslužitelji korišteni za testiranje crna kutija. Ne možemo učiniti ništa osim da tamo postavimo granu Gita. Također ne možemo konfigurirati našu aplikaciju kao .env datoteke. Pristup takvim operacijama nije dopušten. Morate moliti da se promijeni redak u konfiguraciji vaše aplikacije na testnom poslužitelju. (Postoji teorija da je bitno da se administratori osjećaju važnima u projektu; ako se od njih ne traži da promijene retke u konfiguracijama, jednostavno neće biti potrebni). Pa, kao i uvijek, nije li zgodno? Ovo brzo dosadi, nakon izravnog razgovora s adminom saznajemo da su programeri rođeni za pisanje lošeg koda, po prirodi su nekompetentni pojedinci i bolje ih je držati podalje od proizvodnje. Ali ovdje i s testnih poslužitelja, za svaki slučaj. Sukob brzo eskalira. Nema komunikacije s adminom. Situaciju otežava činjenica da je sam. Sljedeća je tipična slika. Otpuštanje. Određene funkcije ne rade. Dugo nam treba da shvatimo što se događa, razne ideje developera se bacaju na chat, ali admin u takvoj situaciji obično pretpostavi da su developeri krivi. Onda napiše u chatu, čekaj, ispravio sam ga. Na upit da iza sebe ostavimo priču s informacijama o tome u čemu je problem, dobivamo otrovne isprike. Kao, ne guraj nos gdje mu nije mjesto. Programeri moraju pisati kod. Situacija kada se mnogi pokreti tijela u projektu odvijaju kroz jednu jedinu osobu i samo on ima pristup za obavljanje operacija koje su svima potrebne je krajnje žalosna. Takva osoba je užasno usko grlo. Ako Devops ideje nastoje smanjiti vrijeme izlaska na tržište, onda su takvi ljudi najgori neprijatelji Devops ideja. Nažalost, zavjesa se ovdje spušta.
p.s. Nakon što sam malo popričao o programerima i administratorima u razgovorima s ljudima, upoznao sam ljude koji dijele moju bol. No, bilo je i onih koji su rekli da se s ovakvim nečim nikada nisu susreli. Na jednoj devops konferenciji pitao sam Antona Isanina (Alfa banka) kako su se nosili s problemom uskog grla u vidu admina, na što je on rekao: “Mi smo ih zamijenili gumbima.” Usput uz njegovo sudjelovanje. Volio bih vjerovati da ima puno više dobrih admina nego neprijatelja. I da, slika na početku je pravo dopisivanje.
Izvor: www.habr.com