Náhody sú náhodné a naozaj to bolo na inej planéte...
Chcel by som sa podeliť o tri príbehy o úspechu a neúspechu o tom, ako backendový vývojár pracuje v tíme s administrátormi.
Príbeh jedna.
Webové štúdio, počet zamestnancov sa dá spočítať jednou rukou. Dnes si layout designer, zajtra backender, pozajtra admin. Na jednej strane môžete získať obrovské skúsenosti. Na druhej strane chýbajú kompetencie vo všetkých oblastiach. Stále si pamätám prvý deň v práci, stále som zelený, šéf hovorí: „Otvorený tmel,“ ale neviem, čo to je. Komunikácia s administrátormi je vylúčená, pretože sám si admin. Pozrime sa na výhody a nevýhody tejto situácie.
+ Všetka moc je vo vašich rukách.
+ Nie je potrebné nikoho prosiť o prístup na server.
+ Rýchly reakčný čas vo všetkých smeroch.
+ Dobre zlepšuje zručnosti.
+ Úplné pochopenie architektúry produktu.
— Vysoká zodpovednosť.
— Riziko prerušenia výroby.
— Je ťažké byť dobrým odborníkom vo všetkých oblastiach.
Nezáujem, ideme ďalej
Druhý príbeh.
Veľká firma, veľký projekt. Je tu administratívne oddelenie s 5-7 zamestnancami a niekoľkými vývojovými skupinami. Keď prídete pracovať do takejto spoločnosti, každý admin si myslí, že ste sem neprišli pracovať na produkte, ale niečo rozbiť. Ani podpísaná NDA ani výber na pohovore nenaznačujú inak. Nie, tento muž sem prišiel so svojimi špinavými rukami, aby zničil našu produkciu bozkov. Preto s takouto osobou potrebujete minimum komunikácie, prinajmenšom môžete ako odpoveď hodiť nálepku. Neodpovedajte na otázky týkajúce sa architektúry projektu. Odporúča sa neudeliť prístup, kým o to vedúci tímu nepožiada. A keď požiada, vráti to s ešte menšími privilégiami, ako žiadali. Takmer všetku komunikáciu s takýmito administrátormi pohlcuje čierna diera medzi vývojovým oddelením a administratívnym oddelením. Problémy nie je možné okamžite vyriešiť. Ale nemôžete prísť osobne - správcovia sú príliš zaneprázdnení 24/7. (Čo celý čas robíte?) Niektoré výkonnostné charakteristiky:
- Priemerná doba nasadenia vo výrobe je 4-5 hodín
- Maximálna doba nasadenia vo výrobe 9 hodín
- Pre vývojára je produkčná aplikácia čiernou skrinkou, rovnako ako samotný produkčný server. Koľko ich je celkovo?
- Nízka kvalita vydaní, časté chyby
- Vývojár sa nezúčastňuje procesu vydania
No čo som čakal, noví ľudia do výroby samozrejme nesmú. Dobre, po získaní trpezlivosti začneme získavať dôveru ostatných. Ale z nejakého dôvodu to s administrátormi nie je také jednoduché.
Akt 1. Admin je neviditeľný.
Deň vydania, vývojár a správca nekomunikujú. Admin nemá žiadne otázky. Ale neskôr pochopíte prečo. Admin je zásadový človek, nemá messengerov, nikomu neprezrádza svoje telefónne číslo a nemá profil na sociálnych sieťach. Nikde nie je ani jeho fotka, ako vyzeráš? Asi 15 minút zmätene sedíme so zodpovedným manažérom a snažíme sa nadviazať komunikáciu s týmto Voyagerom 1, potom sa v podnikovom emaili objaví správa, že skončil. Budeme si dopisovať poštou? Prečo nie? Pohodlné, nie? No dobre, poďme vychladnúť. Proces už prebieha, niet cesty späť. Prečítajte si správu ešte raz. "Skončil som". Čo ste dokončili? Kde? Kde ťa mám hľadať? Tu pochopíte, prečo sú 4 hodiny na uvoľnenie normálne. Dostaneme vývojový šok, ale dokončíme vydanie. Už nie je žiadna túžba uvoľniť sa.
Akt 2. Nie táto verzia.
Ďalšie vydanie. Po získaní skúseností začíname vytvárať zoznamy potrebného softvéru a knižníc pre server pre správcov, pričom pre niektorých uvádzame verzie. Ako vždy dostávame slabý rádiový signál, že tam admin niečo dokončil. Začína sa regresný test, ktorý sám o sebe trvá približne hodinu. Zdá sa, že všetko funguje, ale je tu jedna kritická chyba. Nefunguje dôležitá funkcia. Nasledujúcich pár hodín bol tanec s tamburínami, veštenie na kávovej usadenine a podrobná kontrola každého kódu. Admin hovorí, že urobil všetko. Aplikácia napísaná pokrivenými vývojármi nefunguje, ale server funguje. Nejaké otázky na neho? Na konci hodiny dostaneme správcu, aby poslal verziu knižnice na produkčnom serveri do chatu a binga – nie je to tá, ktorú potrebujeme. Žiadame administrátora, aby nainštaloval požadovanú verziu, ale ako odpoveď dostávame, že to nemôže urobiť z dôvodu absencie tejto verzie v správcovi balíkov OS. Tu si manažér z hlbín pamäti pamätá, že tento problém už riešil iný admin tak, že požadovanú verziu jednoducho zložil ručne. Ale nie, naši to neurobia. Predpisy zakazujú. Karle, sedíme tu už niekoľko hodín, aký je časový limit?! Dostávame ďalší šok a nejako dokončíme uvoľnenie.
3. dejstvo, krátke
Naliehavý lístok, kľúčová funkcia nefunguje pre jedného z používateľov vo výrobe. Strávime pár hodín hrabaním a kontrolou. Vo vývojovom prostredí všetko funguje. Je jasné, že by bolo dobré pozrieť sa do protokolov php-fpm. Na projekte v tom čase neboli žiadne logové systémy ako ELK alebo Prometheus. Otvárame lístok do administratívneho oddelenia, aby umožnilo prístup k protokolom php-fpm na serveri. Tu musíte pochopiť, že o prístup žiadame z nejakého dôvodu, nepamätáte si, že čierna diera a správcovia sú zaneprázdnení 24 hodín denne, 7 dní v týždni? Ak ich požiadate, aby si prezreli samotné záznamy, potom je to úloha s prioritou „nie v tomto živote“. Lístok bol vytvorený, dostali sme okamžitú odpoveď od vedúceho administratívneho oddelenia: „Nemali by ste potrebovať prístup k produkčným protokolom, píšte bez chýb.“ Záves.
4. dejstvo a ďalšie
Vo výrobe stále zhromažďujeme desiatky problémov v dôsledku rôznych verzií knižníc, nekonfigurovaného softvéru, nepripraveného zaťaženia servera a iných problémov. Samozrejme, existujú aj chyby v kóde, nebudeme viniť administrátorov za všetky hriechy, spomenieme len jednu typickú operáciu pre tento projekt. Mali sme pomerne veľa pracovníkov na pozadí, ktorí boli spustení prostredníctvom supervízora a niektoré skripty bolo potrebné pridať do cronu. Niekedy tí istí pracovníci prestali pracovať. Zaťaženie frontového servera rástlo rýchlosťou blesku a smutní užívatelia pozerali na rotujúci nakladač. Na rýchlu opravu takýchto pracovníkov ich stačilo jednoducho reštartovať, ale to opäť dokázal iba administrátor. Kým sa vykonávala taká základná operácia, mohol prejsť celý deň. Tu, samozrejme, stojí za zmienku, že pokrivení programátori by mali písať pracovníkov, aby sa nezrútili, ale keď spadnú, bolo by pekné pochopiť, prečo, čo je niekedy nemožné kvôli nedostatočnému prístupu k produkcii, a v dôsledku toho nedostatok protokolov od vývojára.
Premena.
Keď sme to všetko vydržali dosť dlho, začali sme sa spolu s tímom uberať smerom, ktorý bol pre nás úspešnejší. Aby som to zhrnul, s akými problémami sme sa stretli?
- Nekvalitná komunikácia medzi vývojármi a administratívnym oddelením
- Ukazuje sa, že správcovia vôbec nerozumejú tomu, ako je aplikácia štruktúrovaná, aké má závislosti a ako funguje.
- Vývojári nerozumejú fungovaniu produkčného prostredia a v dôsledku toho nedokážu efektívne reagovať na problémy.
- Proces nasadenia trvá príliš dlho.
- Nestabilné uvoľnenia.
čo sme urobili?
Pre každé vydanie sa vygeneroval zoznam poznámok k vydaniu, ktorý obsahoval zoznam prác, ktoré je potrebné vykonať na serveri, aby ďalšie vydanie fungovalo. Zoznam obsahoval niekoľko sekcií, práce, ktoré by mal vykonať administrátor, osoba zodpovedná za vydanie a vývojár. Vývojári získali non-root prístup ku všetkým produkčným serverom, čo urýchlilo vývoj vo všeobecnosti a najmä riešenie problémov. Vývojári tiež rozumejú tomu, ako výroba funguje, na aké služby je rozdelená, kde a koľko stoja repliky. Niektoré bojové zaťaženia sa stali prehľadnejšími, čo nepochybne ovplyvňuje kvalitu kódu. Komunikácia počas procesu uvoľnenia prebiehala v chate jedného z instant messengerov. Jednak sme mali log o všetkých akciách a jednak komunikácia prebiehala v užšom prostredí. História akcií viac ako raz umožnila novým zamestnancom riešiť problémy rýchlejšie. Je to paradox, ale často to pomohlo aj samotným administrátorom. Nemienim to povedať s istotou, ale zdá sa mi, že správcovia začali viac chápať, ako projekt funguje a ako je napísaný. Niekedy sme si dokonca navzájom zdieľali nejaké detaily. Priemerný čas uvoľnenia sa skrátil na hodinu. Niekedy sme boli hotoví za 30-40 minút. Počet chýb sa výrazne znížil, ak nie desaťnásobne. Na skrátenie času uvoľnenia samozrejme vplývali aj iné faktory, ako napríklad autotesty. Po každom vydaní sme začali robiť retrospektívy. Aby mal celý tím predstavu o tom, čo je nové, čo sa zmenilo a čo bolo odstránené. Bohužiaľ, nie vždy k nim admini prišli, no, admini sú zaneprázdnení... Moja spokojnosť s prácou vývojára nepochybne vzrástla. Keď dokážete rýchlo vyriešiť takmer akýkoľvek problém, ktorý je vo vašej oblasti kompetencií, cítite sa na vrchole. Neskôr pochopím, že do určitej miery sme zaviedli kultúru devops, nie úplne, samozrejme, ale aj ten začiatok transformácie bol pôsobivý.
Príbeh tretí
Začiatok. Jeden admin, malé vývojové oddelenie. Po príchode som úplná nula, pretože... Nikde nemám prístup okrem pošty. Píšeme adminovi a žiadame o prístup. Okrem toho je tam informácia, že vie o novom zamestnancovi a potrebe vydať prihlasovacie údaje/heslá. Poskytujú prístup z úložiska a VPN. Prečo poskytnúť prístup k wiki, teamcity, rundesk? Zbytočné veci pre človeka, ktorý bol povolaný napísať celú backendovú časť. Až časom získame prístup k niektorým nástrojom. Príchod sa samozrejme stretol s nedôverou. Snažím sa pomaly získať pocit, ako funguje infraštruktúra projektu, prostredníctvom rozhovorov a hlavných otázok. V podstate nič nepoznám. Výroba je rovnaká čierna skrinka ako predtým. Ale viac než to, dokonca aj pódiové servery používané na testovanie sú čiernou skrinkou. Nemôžeme robiť nič iné, ako tam nasadiť pobočku z Gitu. Nemôžeme tiež nakonfigurovať našu aplikáciu ako súbory .env. Prístup k takýmto operáciám nie je povolený. Musíte prosiť o zmenu riadku v konfigurácii vašej aplikácie na testovacom serveri. (Existuje teória, že je životne dôležité, aby sa správcovia cítili v projekte dôležití; ak ich nepožiadajú o zmenu riadkov v konfiguráciách, jednoducho nebudú potrebné). No, ako vždy, nie je to pohodlné? Toto rýchlo omrzí, po priamom rozhovore s adminom zisťujeme, že vývojári sa narodili pre písanie zlého kódu, sú od prírody neschopní jedinci a je lepšie ich držať ďalej od výroby. Ale tu aj z testovacích serverov, pre každý prípad. Konflikt rýchlo eskaluje. S adminom neprebieha žiadna komunikácia. Situáciu zhoršuje skutočnosť, že je sám. Nasleduje typický obrázok. Uvoľnite. Niektoré funkcie nefungujú. Trvá nám dlho, kým prídeme na to, čo sa deje, do chatu sa vrhajú rôzne nápady od vývojárov, no admin v takejto situácii zvyčajne predpokladá, že za to môžu vývojári. Potom napíše do chatu, počkaj, opravil som ho. Keď nás požiadame, aby sme za sebou zanechali príbeh s informáciou o tom, v čom bol problém, dostávame toxické výhovorky. Ako, nestrkať nos tam, kam nemá. Vývojári musia napísať kód. Situácia, keď veľa telesných pohybov v projekte prechádza jednou jedinou osobou a iba on má prístup k operáciám, ktoré každý potrebuje, je mimoriadne smutná. Taký človek je strašná prekážka. Ak sa nápady Devops snažia skrátiť čas uvedenia na trh, potom sú títo ľudia najhorším nepriateľom nápadov Devops. Žiaľ, opona sa tu zatiahne.
PS Po krátkom rozhovore o vývojároch a administrátoroch v rozhovoroch s ľuďmi som stretol ľudí, ktorí zdieľali moju bolesť. No našli sa aj takí, ktorí povedali, že sa s niečím podobným ešte nestretli. Na jednej devops konferencii som sa Antona Isanina (Alfa Bank) spýtal, ako riešili problém úzkeho miesta v podobe adminov, na čo povedal: „Nahradili sme ich tlačidlami.“ Mimochodom s jeho účasťou. Rád by som veril, že dobrých adminov je oveľa viac ako nepriateľov. A áno, obrázok na začiatku je skutočná korešpondencia.
Zdroj: www.habr.com