Slučajnosti su slučajne, i zaista je bilo na drugoj planeti...
Želio bih podijeliti tri priče o uspjehu i neuspjehu o tome kako backend programer radi u timu s administratorima.
Priča prva.
Web studio, broj zaposlenih se može prebrojati jednom rukom. Danas si layout dizajner, sutra si bekender, prekosutra si admin. S jedne strane, možete steći ogromno iskustvo. S druge strane, postoji nedostatak kompetentnosti u svim oblastima. Još se sećam prvog radnog dana, zelena sam, kaže gazda: „Otvori kit“, ali ne znam šta je. Komunikacija sa administratorima je isključena, jer sami ste admin. Razmotrimo prednosti i nedostatke ove situacije.
+ Sva moć je u vašim rukama.
+ Nema potrebe nikoga moliti za pristup serveru.
+ Brzo vrijeme reakcije u svim smjerovima.
+ Dobro poboljšava vještine.
+ Imati potpuno razumijevanje arhitekture proizvoda.
— Visoka odgovornost.
— Rizik od prekida proizvodnje.
— Teško je biti dobar stručnjak u svim oblastima.
Ne zanima me, idemo dalje
Druga priča.
Velika kompanija, veliki projekat. Postoji odjel uprave sa 5-7 zaposlenih i nekoliko razvojnih grupa. Kada dođete da radite u takvoj kompaniji, svaki admin misli da niste došli da radite na nekom proizvodu, već da biste nešto razbili. Ni potpisani NDA ni izbor na intervjuu ne ukazuju drugačije. Ne, ovaj čovjek je došao ovamo sa svojim prljavim malim rukama da uništi našu produkciju ljubljenja. Stoga vam je s takvom osobom potreban minimum komunikacije; u najmanju ruku, možete baciti naljepnicu kao odgovor. Ne odgovarajte na pitanja o arhitekturi projekta. Preporučljivo je ne odobravati pristup dok vođa tima ne zatraži. A kada zatraži, vratit će ga sa 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. Probleme je nemoguće brzo riješiti. Ali ne možete doći lično - administratori su prezaposleni 24/7. (Šta radiš cijelo vrijeme?) Neke karakteristike performansi:
- Prosječno vrijeme implementacije 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 proizvodni server. Koliko ih ima ukupno?
- Nizak kvalitet izdanja, česte greške
- Programer ne učestvuje u procesu izdavanja
Pa šta sam očekivao, naravno, novi ljudi se ne puštaju u proizvodnju. Dobro, pošto smo stekli strpljenje, počinjemo da stičemo poverenje drugih. Ali iz nekog razloga, stvari nisu tako jednostavne sa administratorima.
Čin 1. Administrator je nevidljiv.
Dan izdanja, programer i administrator ne komuniciraju. Administrator nema pitanja. Ali kasnije ćete shvatiti zašto. Administrator je principijelna osoba, nema mesindžere, nikome ne daje svoj broj telefona i nema profil na društvenim mrežama. Nigdje nema ni njegove fotografije, kako ti ličiš čovječe? Sjedimo sa odgovornim menadžerom oko 15 minuta u nedoumici, pokušavajući uspostaviti komunikaciju sa ovim Voyagerom 1, a onda se u korporativnom emailu pojavljuje poruka da je završio. Hoćemo li se dopisivati poštom? Zašto ne? Zgodno, zar ne? Pa, ok, ohladimo se. Proces je već u toku, nema povratka. Pročitajte poruku ponovo. "Završio sam". Šta si završio? Gdje? Gdje da te tražim? Ovdje razumijete zašto je 4 sata za oslobađanje normalno. Dobijamo razvojni šok, ali završavamo izdanje. Više nema želje za oslobađanjem.
Čin 2. Ne ta verzija.
Sljedeće izdanje. Stekavši iskustvo, počinjemo kreirati liste potrebnog softvera i biblioteka za server za administratore, navodeći verzije za neke. Kao i uvijek, dobijamo slab radio signal da je administrator nešto završio tamo. Počinje test regresije, koji sam po sebi traje oko sat vremena. Čini se da sve radi, ali postoji jedna kritična greška. Važna funkcionalnost ne radi. Sljedećih nekoliko sati bilo je plesanje uz tamburaše, proricanje sudbine na talogu od kafe i detaljan pregled svakog dijela koda. Administrator kaže da je sve uradio. Aplikacija koju su napisali pokvareni programeri ne radi, ali server radi. Ima li pitanja za njega? Na kraju jednog sata dobijamo od administratora da pošalje verziju biblioteke na proizvodnom serveru u chat i bingo - nije ona koja nam treba. Tražimo od administratora da instalira potrebnu verziju, ali u odgovoru dobijamo da to ne može učiniti zbog odsustva ove verzije u upravitelju paketa OS. Ovdje, iz skrovišta svoje memorije, menadžer se sjeća da je drugi administrator već riješio ovaj problem jednostavnim ručno sklapanjem potrebne verzije. Ali ne, naši to neće učiniti. Propisi zabranjuju. Karle, sjedimo ovdje već nekoliko sati, koliko je vremensko ograničenje?! Dobijamo još jedan šok i nekako završimo izdanje.
Čin 3, kratki
Hitna karta, ključna funkcionalnost ne radi za jednog od korisnika u produkciji. Provodimo nekoliko sati bockajući i provjeravajući. U razvojnom okruženju sve funkcioniše. Postoji jasno razumevanje da bi bilo dobro pogledati php-fpm logove. U to vrijeme na projektu nije postojao log sistem poput ELK ili Prometheus. Otvaramo tiket odeljenju administracije da nam daju pristup php-fpm logovima na serveru. 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 pogledaju same dnevnike, onda je to zadatak s prioritetom „ne u ovom životu“. Karta je kreirana, odmah smo dobili odgovor od šefa administrativnog odjela: „Ne treba vam pristup evidencijama proizvodnje, pišite bez grešaka.” Zavjesa.
Čin 4 i dalje
Još uvijek prikupljamo desetine problema u produkciji, zbog različitih verzija biblioteka, nekonfigurisanog softvera, nepripremljenog opterećenja servera i drugih problema. Naravno, postoje i greške u kodu, nećemo kriviti administratore za sve grijehe, već ćemo spomenuti još jednu tipičnu operaciju za taj projekat. Imali smo dosta pozadinskih radnika koji su pokrenuti preko supervizora, a neke skripte su morale biti dodate u cron. Ponekad su ti isti radnici prestajali da rade. Opterećenje na serveru čekanja raslo je munjevitom brzinom, a tužni korisnici su gledali u učitavač koji se okreće. Da biste brzo popravili takve radnike, bilo je dovoljno jednostavno ih ponovo pokrenuti, ali opet, to je mogao učiniti samo administrator. Dok se radila takva osnovna operacija, mogao bi proć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 razumjeti zašto, što je ponekad nemoguće zbog nedostatka pristupa proizvodnji, naravno, i kao posljedica toga, nedostatak dnevnika od programera.
Transfiguracija.
Izdržavši sve ovo dosta dugo, zajedno sa ekipom smo krenuli u pravcu koji je za nas bio uspješniji. Da rezimiramo, sa kojim smo se problemima suočili?
- Nedostatak kvalitetne komunikacije između programera i administracije
- Administratori, ispostavilo se (!), uopće ne razumiju kako je aplikacija strukturirana, koje ovisnosti ima i kako funkcionira.
- Programeri ne razumiju kako proizvodno okruženje funkcionira i, kao rezultat, ne mogu efikasno odgovoriti na probleme.
- Proces implementacije traje predugo.
- Nestabilna izdanja.
Šta smo uradili?
Za svako izdanje generisana je lista napomena o izdanju, koja je uključivala spisak poslova koji treba da se obavi na serveru da bi sledeće izdanje radilo. Lista je sadržavala nekoliko sekcija, posao koji treba da obavi administrator, osoba odgovorna za izdanje i programer. Programeri su dobili non-root pristup svim proizvodnim serverima, što je ubrzalo razvoj općenito, a posebno rješavanje problema. Programeri također imaju razumijevanje o tome kako produkcija funkcionira, na koje je usluge podijeljena, gdje i koliko koštaju replike. Neka borbena opterećenja su postala jasnija, što nesumnjivo utiče na kvalitet koda. Komunikacija tokom procesa objavljivanja odvijala se u chatu jednog od instant messengera. Prvo, imali smo dnevnik svih akcija, a drugo, komunikacija se odvijala u bližem okruženju. Posjedovanje historije akcija više puta je omogućilo novim zaposlenima da brže rješavaju probleme. To je paradoks, ali to je često pomoglo i samim administratorima. Neću se obavezati da kažem sa sigurnošću, ali čini mi se da su administratori počeli više razumjeti kako projekat funkcionira i kako je napisan. Ponekad smo čak dijelili neke detalje jedno s drugim. Prosječno vrijeme puštanja je smanjeno na sat vremena. Ponekad smo završili za 30-40 minuta. Broj grešaka se značajno smanjio, ako ne i deset puta. Naravno, i drugi faktori su uticali na smanjenje vremena objavljivanja, kao što su autotestovi. Nakon svakog izdanja, počeli smo provoditi retrospektive. Tako da ceo tim ima ideju šta je novo, šta je promenjeno, a šta je uklonjeno. Nažalost, admini nisu uvijek dolazili kod njih, pa, admini su zauzeti... Moje zadovoljstvo poslom kao programera je nesumnjivo poraslo. Kada možete brzo da rešite skoro svaki problem koji je u vašoj oblasti ется ste na vrhu. Kasnije ću shvatiti da smo donekle uveli devops kulturu, ne u potpunosti, naravno, ali je i taj početak transformacije bio impresivan.
Treća priča
Startup. Jedan admin, mali razvojni odjel. Po dolasku sam potpuna nula, jer... Nemam pristup nigdje osim sa pošte. Pišemo administratoru i tražimo pristup. Osim toga, postoje informacije da je svjestan novog zaposlenika i potrebe za izdavanjem logina/lozinki. Oni daju pristup iz spremišta i VPN-a. Zašto dati pristup wikiju, teamcity-u, rundesk-u? Beskorisne stvari za osobu koja je pozvana da napiše cijeli backend dio. Tek vremenom dobijamo pristup nekim alatima. Dolazak je, naravno, dočekan s nepovjerenjem. Pokušavam kroz razgovore i sugestivna pitanja polako dobiti osjećaj kako infrastruktura projekta funkcionira. U suštini ne prepoznajem ništa. Proizvodnja je ista crna kutija kao i prije. Ali više od toga, čak i scenski serveri koji se koriste za testiranje su crna kutija. Ne možemo učiniti ništa osim da tamo postavimo granu iz Gita. Također ne možemo konfigurirati našu aplikaciju poput .env datoteka. Pristup za takve operacije nije odobren. Morate moliti da promijenite liniju u konfiguraciji vaše aplikacije na test serveru. (Postoji teorija da je od vitalnog značaja da se administratori osećaju važnim u projektu; ako se od njih ne traži da promene redove u konfiguracijama, jednostavno neće biti potrebni). Pa, kao i uvek, zar nije zgodno? Ovo brzo postane dosadno, nakon direktnog razgovora sa administratorom saznajemo da su programeri rođeni da pišu loš kod, po prirodi su nekompetentni pojedinci i bolje ih je držati podalje od proizvodnje. Ali ovdje i sa test servera, za svaki slučaj. Sukob brzo eskalira. Nema komunikacije sa administratorom. Situaciju otežava činjenica da je sam. Slijedi tipična slika. Pustiti. Određene funkcije ne rade. Treba nam dosta vremena da shvatimo šta se dešava, razne ideje programera se ubacuju u chat, ali admin u takvoj situaciji obično pretpostavlja da su programeri krivi. Onda piše u čet, čekaj, ispravio sam ga. Na zahtjev da iza sebe ostavimo priču s informacijama o tome u čemu je problem, dobijamo toksične izgovore. Kao, ne guraj svoj nos tamo gde mu nije mesto. Programeri moraju napisati kod. Izuzetno je tužna situacija kada mnogi pokreti tijela u projektu prolaze kroz jednu osobu i samo ona ima pristup za obavljanje operacija koje su svima potrebne. Takva osoba je strašno usko grlo. Ako Devops ideje nastoje smanjiti vrijeme za plasiranje na tržište, onda su takvi ljudi najgori neprijatelj Devops ideja. Nažalost, zavjesa se ovdje zatvara.
PS Nakon što sam malo pričao o programerima i administratorima u razgovorima s ljudima, upoznao sam ljude koji dijele moju bol. Ali bilo je i onih koji su rekli da se nikada nisu susreli sa ovim. Na jednoj devops konferenciji pitao sam Antona Isanina (Alfa banka) kako se nose sa problemom uskog grla u vidu admina, na šta je on rekao: „Zamenili smo ih dugmadima“. Između ostalog uz njegovo učešće. Voleo bih da verujem da ima mnogo više dobrih admina nego neprijatelja. I da, slika na početku je prava prepiska.
Izvor: www.habr.com