Sutapimai atsitiktiniai, ir iš tikrųjų tai buvo kitoje planetoje...
Norėčiau pasidalinti trimis sėkmės ir nesėkmių istorijomis apie tai, kaip backend kūrėjas dirba komandoje su administratoriais.
Istorija viena.
Interneto studija, darbuotojų skaičių galima suskaičiuoti viena ranka. Šiandien esate maketuotojas, rytoj – backender, poryt – administratorius. Viena vertus, galite įgyti didžiulės patirties. Kita vertus, visose srityse trūksta kompetencijos. Pirmą darbo dieną dar prisimenu, dar žalias, viršininkas sako: „Atviras glaistas“, bet nežinau, kas tai. Bendravimas su administratoriais neleidžiamas, nes pats esi adminas. Panagrinėkime šios situacijos privalumus ir trūkumus.
+ Visa valdžia yra jūsų rankose.
+ Nereikia niekam prašyti prieigos prie serverio.
+ Greitas reakcijos laikas visomis kryptimis.
+ Gerai tobulina įgūdžius.
+ Turite visišką produkto architektūros supratimą.
- Didelė atsakomybė.
— Gamybos gedimo pavojus.
– Sunku būti geru visų sričių specialistu.
Neįdomu, eikime toliau
Antroji istorija.
Didelė įmonė, didelis projektas. Yra administracijos skyrius, kuriame dirba 5-7 darbuotojai, kelios plėtros grupės. Kai ateini dirbti į tokią įmonę, kiekvienas adminas galvoja, kad čia atėjai ne dirbti prie produkto, o ką nors sulaužyti. Nei pasirašyta NDA, nei atranka pokalbio metu nerodo kitaip. Ne, šis žmogus atėjo čia su savo nešvariomis mažomis rankomis, kad sugadintų mūsų bučinių produkciją. Todėl su tokiu žmogumi jums reikia minimalaus bendravimo, bent jau galite mesti lipduką atsakydami. Neatsakykite į klausimus apie projekto architektūrą. Patartina nesuteikti prieigos, kol nepaprašo komandos vadovas. O kai paprašys, grąžins su dar mažesnėmis privilegijomis, nei prašė. Beveik visą bendravimą su tokiais administratoriais sugeria juodoji skylė tarp plėtros skyriaus ir administracijos skyriaus. Neįmanoma greitai išspręsti problemų. Bet jūs negalite atvykti asmeniškai - administratoriai yra per daug užsiėmę 24 valandas per parą, 7 dienas per savaitę. (Ką veikiate visą laiką?) Kai kurios veikimo charakteristikos:
- Vidutinis diegimo laikas gamyboje yra 4-5 valandos
- Maksimalus diegimo laikas gamyboje 9 valandos
- Kūrėjui gamybinė programa yra juodoji dėžė, kaip ir pats gamybos serveris. Kiek jų iš viso?
- Žema leidimų kokybė, dažnos klaidos
- Kūrėjas nedalyvauja išleidimo procese
Na, ko aš tikėjausi, aišku, nauji žmonės į gamybą neįleidžiami. Na, gerai, įgavę kantrybės, pradedame įgyti kitų pasitikėjimą. Bet kažkodėl su administratoriais viskas nėra taip paprasta.
1 veiksmas. Administratorius nematomas.
Išleidimo diena, kūrėjas ir administratorius nebendrauja. Administratoriui klausimų nėra. Bet kodėl vėliau suprasi. Adminas yra principingas žmogus, neturi pasiuntinių, niekam neišduoda savo telefono numerio, neturi ir anketos socialiniuose tinkluose. Niekur net nėra jo nuotraukos, kaip tu atrodai bičiulis? Su atsakingu vadovu sėdime apie 15 minučių sutrikę, bandydami užmegzti ryšį su šiuo „Voyager 1“, tada įmonės el. laiške pasirodo pranešimas, kad jis baigė. Ar susirašysime paštu? Kodėl gi ne? Patogu, ar ne? Na, gerai, atsivėsinkime. Procesas jau vyksta, kelio atgal nėra. Dar kartą perskaitykite pranešimą. "Aš baigiau". Ką baigei? Kur? Kur man tavęs ieškoti? Čia jūs suprantate, kodėl 4 valandos paleidimui yra normalu. Sulaukiame plėtros šoko, bet užbaigiame leidimą. Nebėra jokio noro paleisti.
2 aktas. Ne ta versija.
Kitas leidimas. Įgiję patirties, pradedame kurti reikalingos programinės įrangos ir serverio bibliotekų sąrašus administratoriams, kai kuriems nurodant versijas. Kaip visada, gauname silpną radijo signalą, kad adminas ten kažką baigė. Prasideda regresijos testas, kuris pats užtrunka apie valandą. Atrodo, kad viskas veikia, tačiau yra viena kritinė klaida. Svarbi funkcija neveikia. Kitos valandos buvo šokiai su tamburinais, ateities spėjimas ant kavos tirščių ir išsami kiekvieno kodo peržiūra. Administratorius sako, kad padarė viską. Kreivų kūrėjų parašyta programa neveikia, bet serveris veikia. Turi klausimų jam? Pasibaigus valandai, administratorius nusiunčia gamybiniame serveryje esančios bibliotekos versiją į pokalbį ir bingo – tai ne ta, kurios mums reikia. Administratoriaus prašome įdiegti reikiamą versiją, tačiau atsakydami gauname, kad jis to padaryti negali, nes šios versijos nėra OS paketų tvarkyklėje. Čia iš savo atminties užkaborių vadovas prisimena, kad kitas adminas jau buvo išsprendęs šią problemą, tiesiog rankomis surinkęs reikiamą versiją. Bet ne, mūsiškiai to nedarys. Taisyklės draudžia. Karlai, mes čia sėdime kelias valandas, koks laiko limitas?! Gauname dar vieną šoką ir kažkaip užbaigiame leidimą.
3 veiksmas, trumpas
Skubus bilietas, pagrindinė funkcija neveikia vienam iš gamybinių vartotojų. Porą valandų praleidžiame bakstelėdami ir tikrindami. Plėtros aplinkoje viskas veikia. Yra aiškus supratimas, kad būtų gera idėja pažvelgti į php-fpm žurnalus. Tuo metu projekte nebuvo tokių rąstų sistemų kaip ELK ar Prometėjas. Mes atidarome bilietą į administravimo skyrių, kad jie suteiktų prieigą prie php-fpm žurnalų serveryje. Čia reikia suprasti, kad prieigos prašome ne veltui, ar neprisimenate apie juodąją skylę ir administratorių užimtumą 24 valandas per parą, 7 dienas per savaitę? Jei paprašysite jų pažvelgti į pačius rąstus, tai yra užduotis, kurios prioritetas yra „ne šiame gyvenime“. Bilietas buvo sukurtas, iškart gavome administracijos skyriaus vedėjo atsakymą: „Nereikėtų prieiti prie gamybos žurnalų, rašyk be klaidų“. Užuolaidą.
4 veiksmas ir toliau
Gamyboje vis dar renkame dešimtis problemų dėl skirtingų bibliotekų versijų, nesukonfigūruotos programinės įrangos, neparengtų serverių apkrovų ir kitų problemų. Žinoma, yra ir kodo klaidų, dėl visų nuodėmių nekaltinsime adminų, tik paminėsime dar vieną tipišką tam projektui operaciją. Turėjome gana daug foninių darbuotojų, kurie buvo paleisti per prižiūrėtoją, ir kai kuriuos scenarijus reikėjo pridėti prie cron. Kartais tie patys darbuotojai nustodavo dirbti. Eilių serverio apkrova augo žaibišku greičiu, o vartotojai liūdi žiūrėjo į besisukantį krautuvą. Norint greitai ištaisyti tokius darbuotojus, pakako juos tiesiog paleisti iš naujo, bet vėlgi, tai galėjo padaryti tik administratorius. Kol buvo atliekama tokia pagrindinė operacija, galėjo praeiti visa diena. Čia, žinoma, verta pastebėti, kad kreivai programuotojai turėtų rašyti darbininkus, kad jie nedūžtų, bet kai jie nukrenta, būtų malonu suprasti, kodėl, o tai kartais neįmanoma dėl to, kad nėra galimybės patekti į gamybą, Žinoma, ir dėl to kūrėjo trūksta žurnalų.
Atsimainymas.
Gana ilgai visa tai ištvėrę, kartu su komanda pradėjome sukti mums sėkmingesne kryptimi. Apibendrinant, su kokiomis problemomis susidūrėme?
- Trūksta kokybiško komunikacijos tarp kūrėjų ir administracijos skyriaus
- Administratoriai, pasirodo(!), visiškai nesupranta, kaip aplikacija sukonstruota, kokias priklausomybes ji turi ir kaip veikia.
- Kūrėjai nesupranta, kaip veikia gamybos aplinka, ir dėl to negali efektyviai reaguoti į problemas.
- Diegimo procesas trunka per ilgai.
- Nestabilūs leidimai.
Ką mes padarėme?
Kiekvienam leidimui buvo sugeneruotas leidimo pastabų sąrašas, kuriame buvo darbų, kuriuos reikia atlikti serveryje, kad veiktų kitas leidimas, sąrašas. Sąraše buvo keli skyriai, darbai, kuriuos turėtų atlikti administratorius, už išleidimą atsakingas asmuo ir kūrėjas. Kūrėjai gavo ne root prieigą prie visų gamybos serverių, o tai paspartino kūrimą apskritai ir ypač problemų sprendimą. Kūrėjai taip pat turi supratimą, kaip veikia gamyba, į kokias paslaugas ji skirstoma, kur ir kiek kainuoja kopijos. Kai kurios kovinės apkrovos tapo aiškesnės, o tai neabejotinai turi įtakos kodo kokybei. Bendravimas išleidimo proceso metu vyko vieno iš momentinių pasiuntinių pokalbyje. Pirma, turėjome visų veiksmų žurnalą, antra – bendravimas vyko artimesnėje aplinkoje. Veiksmų istorija ne kartą leido naujiems darbuotojams greičiau išspręsti problemas. Tai paradoksas, bet tai dažnai padėdavo patiems administratoriams. Tikrai nesiimsiu pasakyti, bet man atrodo, kad administratoriai pradėjo geriau suprasti, kaip projektas veikia ir kaip jis parašytas. Kartais net pasidalindavome vieni su kitais kai kuriomis detalėmis. Vidutinis išleidimo laikas sutrumpintas iki valandos. Kartais baigdavome per 30–40 minučių. Klaidų skaičius gerokai sumažėjo, jei ne dešimt kartų. Žinoma, išleidimo laiko sutrumpėjimui įtakos turėjo ir kiti veiksniai, pavyzdžiui, automatiniai testai. Po kiekvieno išleidimo pradėjome vesti retrospektyvas. Kad visa komanda suprastų, kas naujo, kas pasikeitė ir kas pašalinta. Deja, ne visada pas juos ateidavo adminai, na, administratoriai užsiėmę... Pasitenkinimas darbu mano, kaip kūrėjo, neabejotinai išaugo. Kai galite greitai išspręsti beveik bet kokią problemą, kuri yra jūsų kompetencijos srityje, jaučiatės aukščiausias. Vėliau suprasiu, kad tam tikru mastu mes įvedėme devops kultūrą, žinoma, ne iki galo, bet ir ta virsmo pradžia buvo įspūdinga.
Trečia istorija
Pradėti. Vienas administratorius, mažas plėtros skyrius. Atvykusi esu visiškas nulis, nes... Niekur neturiu prieigos, išskyrus paštą. Rašome administratoriui ir prašome prieigos. Be to, yra informacija, kad jis žino apie naują darbuotoją ir būtinybę išduoti prisijungimo vardus/slaptažodžius. Jie suteikia prieigą iš saugyklos ir VPN. Kodėl reikia suteikti prieigą prie wiki, teamcity, rundesk? Nenaudingi dalykai žmogui, kuris buvo pakviestas parašyti visą backend dalį. Tik laikui bėgant gauname prieigą prie kai kurių įrankių. Atvykimas, žinoma, buvo sutiktas su nepasitikėjimu. Stengiuosi pamažu pajusti, kaip veikia projekto infrastruktūra per pokalbius ir užduodamus klausimus. Iš esmės aš nieko nepripažįstu. Gamyba ta pati juodoji dėžė kaip ir anksčiau. Tačiau net testavimui naudojami scenos serveriai yra juodoji dėžė. Negalime padaryti nieko kito, kaip tik įdiegti filialą iš „Git“. Taip pat negalime konfigūruoti savo programos kaip .env failų. Prieiga tokioms operacijoms nesuteikiama. Turite maldauti, kad bandomojo serverio programos konfigūracijos eilutė būtų pakeista. (Egzistuoja teorija, kad administratoriams labai svarbu jaustis svarbiems projekte; jei jų neprašys pakeisti konfigūracijų eilučių, jų tiesiog neprireiks). Na, kaip visada, argi tai nėra patogu? Tai greitai pasidaro nuobodu, po tiesioginio pokalbio su administratoriumi sužinome, kad kūrėjai gimė rašyti blogą kodą, iš prigimties yra nekompetentingi asmenys ir geriau juos laikyti toliau nuo gamybos. Bet čia taip pat iš bandomųjų serverių, tik tuo atveju. Konfliktas sparčiai didėja. Su adminu nebendraujama. Situaciją apsunkina tai, kad jis vienas. Toliau pateikiamas tipiškas vaizdas. Paleisti. Tam tikros funkcijos neveikia. Užtrunka ilgai, kol išsiaiškinsime, kas vyksta, į pokalbį metamos įvairios kūrėjų idėjos, tačiau administratorius tokioje situacijoje dažniausiai mano, kad kalti kūrėjai. Tada pokalbyje rašo, palauk, aš jį pataisiau. Paprašius palikti istoriją su informacija apie tai, kokia buvo problema, gauname nuodingų pasiteisinimų. Pavyzdžiui, nekiškite nosies ten, kur jai nedera. Kūrėjai turi parašyti kodą. Situacija, kai projekte daug kūno judesių vyksta per vieną žmogų ir tik jis turi galimybę atlikti visiems reikalingas operacijas, yra be galo liūdna. Toks žmogus yra baisi kliūtis. Jei Devops idėjos siekia sutrumpinti pateikimo į rinką laiką, tai tokie žmonės yra didžiausias Devops idėjų priešas. Deja, čia uždanga užsidaro.
PS Pokalbiuose su žmonėmis šiek tiek pakalbėjęs apie kūrėjus ir administratorius, sutikau žmonių, kurie pasidalino mano skausmu. Tačiau buvo ir tokių, kurie sakė, kad su niekuo panašaus nėra susidūrę. Vienoje „devops“ konferencijoje paklausiau Antono Isanino („Alfa Bank“), kaip jie sprendė administratorių kliūties problemą, į kurią jis atsakė: „Pakeitėme juos mygtukais“. Beje su jo dalyvavimu. Norėčiau tikėti, kad gerų administratorių yra daug daugiau nei priešų. Ir taip, paveikslas pradžioje yra tikras susirašinėjimas.
Šaltinis: www.habr.com