Vývojáři jsou z Marsu, administrátoři z Venuše

Náhody jsou náhodné a skutečně to bylo na jiné planetě...

Rád bych se podělil o tři příběhy o úspěchu a neúspěchu o tom, jak backendový vývojář pracuje v týmu s administrátory.

První příběh.
Web studio, počet zaměstnanců lze spočítat jednou rukou. Dnes jsi návrhář rozložení, zítra backender, pozítří admin. Na jedné straně můžete získat obrovské zkušenosti. Na druhou stranu chybí kompetence ve všech oblastech. Pořád si pamatuji první den v práci, jsem stále zelený, šéf říká: „Otevřete tmel,“ ale nevím, co to je. Komunikace s adminy je vyloučena, protože sám jsi admin. Zvažme klady a zápory této situace.

+ Veškerá moc je ve vašich rukou.
+ Není třeba nikoho prosit o přístup na server.
+ Rychlá reakční doba ve všech směrech.
+ Dobře zlepšuje dovednosti.
+ Úplné pochopení architektury produktu.

— Vysoká zodpovědnost.
— Riziko přerušení výroby.
— Je těžké být dobrým specialistou ve všech oblastech.

Nemám zájem, pojďme dál

Druhý příběh.
Velká firma, velký projekt. Je zde administrativní oddělení s 5-7 zaměstnanci a několika vývojovými skupinami. Když přijdete pracovat do takové společnosti, každý admin si myslí, že jste sem nepřišel pracovat na produktu, ale něco rozbít. Ani podepsaná NDA ani výběr při pohovoru nenaznačují jinak. Ne, tento muž sem přišel se svými špinavými rukama, aby zničil naši produkci líbání. Proto s takovým člověkem potřebujete minimum komunikace, minimálně můžete jako odpověď hodit nálepku. Neodpovídejte na otázky týkající se architektury projektu. Je vhodné neudělit přístup, dokud o to vedoucí týmu nepožádá. A když požádá, vrátí to s ještě menšími výsadami, než o které žádali. Téměř veškerou komunikaci s takovými administrátory pohlcuje černá díra mezi vývojovým oddělením a administrativním oddělením. Problémy není možné řešit okamžitě. Ale nemůžete přijít osobně - administrátoři jsou příliš zaneprázdněni 24/7. (Co celou dobu děláte?) Některé výkonnostní charakteristiky:

• Průměrná doba nasazení ve výrobě je 4-5 hodin
• Maximální doba nasazení ve výrobě 9 hodin
• Pro vývojáře je produkční aplikace černou skříňkou, stejně jako samotný produkční server. Kolik jich je celkem?
• Nízká kvalita vydání, časté chyby
• Vývojář se neúčastní procesu vydání

No co jsem čekal, noví lidé do výroby samozřejmě nesmí. Dobře, když jsme získali trpělivost, začneme získávat důvěru ostatních. Ale z nějakého důvodu to s administrátory není tak jednoduché.

Akt 1. Admin je neviditelný.
Den vydání, vývojář a administrátor spolu nekomunikují. Admin nemá žádné otázky. Ale později pochopíte proč. Admin je zásadový člověk, nemá messengery, nikomu nedává své telefonní číslo a nemá profil na sociálních sítích. Nikde není ani jeho fotka, jak vypadáš vole? Asi 15 minut zmateně sedíme s odpovědným manažerem a snažíme se navázat komunikaci s tímto Voyagerem 1, pak se ve firemním emailu objeví zpráva, že skončil. Budeme si dopisovat poštou? Proč ne? Pohodlné, že? Dobře, pojďme vychladnout. Proces již probíhá, není cesty zpět. Přečtěte si zprávu znovu. "Skončil jsem". co jsi dokončil? Kde? Kde tě mám hledat? Zde chápete, proč jsou 4 hodiny na vydání normální. Dostáváme vývojový šok, ale dokončíme vydání. Už není žádná touha uvolnit se.

Akt 2. Ne ta verze.
Příští vydání. Poté, co jsme získali zkušenosti, začínáme vytvářet seznamy potřebného softwaru a knihoven pro server pro administrátory, s uvedením verzí pro některé. Jako vždy dostáváme slabý rádiový signál, že tam admin něco dokončil. Začíná regresní test, který sám o sobě trvá asi hodinu. Zdá se, že vše funguje, ale je tu jedna kritická chyba. Nefunguje důležitá funkce. Následujících několik hodin bylo tancem s tamburínami, věštěním na kávové sedlině a podrobnou kontrolou každého kódu. Admin říká, že udělal všechno. Aplikace napsaná pokřivenými vývojáři nefunguje, ale server funguje. Nějaké otázky na něj? Na konci hodiny přimějeme administrátora, aby poslal verzi knihovny na produkčním serveru do chatu a binga – není to ta, kterou potřebujeme. Žádáme administrátora o instalaci požadované verze, ale jako odpověď dostáváme, že to nemůže udělat z důvodu absence této verze ve správci balíčků OS. Zde si manažer z hloubi své paměti pamatuje, že tento problém již vyřešil jiný admin tak, že požadovanou verzi jednoduše sestavil ručně. Ale ne, naši to neudělají. Předpisy zakazují. Karle, sedíme tu několik hodin, jaký je časový limit?! Dostáváme další šok a nějak dokončujeme vydání.

3. dějství, krátké
Urgentní lístek, klíčová funkce nefunguje pro jednoho z uživatelů v produkci. Strávíme pár hodin šťoucháním a kontrolou. Ve vývojovém prostředí vše funguje. Je jasné, že by bylo dobré podívat se do protokolů php-fpm. V té době na projektu nebyly žádné log systémy jako ELK nebo Prometheus. Otevřeme lístek do administračního oddělení, aby umožnilo přístup k protokolům php-fpm na serveru. Zde musíte pochopit, že žádáme o přístup z nějakého důvodu, nepamatujete si, že černá díra a admini byli zaneprázdněni 24/7? Pokud je požádáte, aby se sami podívali na protokoly, pak je to úkol s prioritou „není v tomto životě“. Lístek byl vytvořen, dostali jsme okamžitou odpověď od vedoucího administrativního oddělení: „Neměli byste potřebovat přístup k produkčním protokolům, pište bez chyb.“ Závěs.

Akt 4 a další
Ve výrobě stále shromažďujeme desítky problémů kvůli různým verzím knihoven, nekonfigurovanému softwaru, nepřipravenému zatížení serveru a dalším problémům. Samozřejmě jsou zde i chyby v kódu, nebudeme vinit administrátory ze všech hříchů, jen zmíníme ještě jednu typickou operaci pro tento projekt. Měli jsme poměrně hodně pracovníků na pozadí, kteří byli spuštěni prostřednictvím supervizora, a některé skripty bylo nutné přidat do cronu. Někdy titíž pracovníci přestali pracovat. Zátěž frontového serveru rostla rychlostí blesku a smutní uživatelé se dívali na rotující nakladač. K rychlé opravě takových pracovníků stačilo je jednoduše restartovat, ale to opět mohl udělat pouze administrátor. Zatímco se prováděla taková základní operace, mohl uplynout celý den. Zde se samozřejmě sluší poznamenat, že pokřivení programátoři by měli psát workery, aby se nezhroutili, ale když spadnou, bylo by hezké pochopit, proč, což je někdy nemožné kvůli nedostatečnému přístupu k produkci, samozřejmě a v důsledku toho nedostatek protokolů od vývojáře.

Proměna.
Když jsme to všechno vydrželi poměrně dlouho, začali jsme se společně s týmem ubírat směrem, který byl pro nás úspěšnější. Abychom to shrnuli, s jakými problémy jsme se potýkali?

• Nekvalitní komunikace mezi vývojáři a administrativním oddělením
• Správci, jak se ukázalo (!), vůbec nechápou, jak je aplikace strukturována, jaké má závislosti a jak funguje.
• Vývojáři nechápou, jak produkční prostředí funguje, a v důsledku toho nemohou efektivně reagovat na problémy.
• Proces nasazení trvá příliš dlouho.
• Nestabilní vydání.

Co jsme udělali?
Pro každé vydání byl vygenerován seznam poznámek k vydání, který obsahoval seznam práce, kterou je třeba na serveru provést, aby další vydání fungovalo. Seznam obsahoval několik sekcí, práce, které by měl provést správce, osoba odpovědná za vydání a vývojář. Vývojáři získali non-root přístup ke všem produkčním serverům, což urychlilo vývoj obecně a řešení problémů zvláště. Vývojáři také rozumí tomu, jak produkce funguje, na jaké služby se dělí, kde a kolik stojí repliky. Některé bojové zátěže se zpřehlednily, což nepochybně ovlivňuje kvalitu kódu. Komunikace během procesu uvolňování probíhala v chatu jednoho z instant messengerů. Za prvé jsme měli protokol o všech akcích a za druhé komunikace probíhala v užším prostředí. Historie akcí více než jednou umožnila novým zaměstnancům řešit problémy rychleji. Je to paradox, ale často to pomohlo samotným adminům. Nebudu to říkat s jistotou, ale zdá se mi, že administrátoři začali více chápat, jak projekt funguje a jak je napsán. Občas jsme spolu sdíleli i nějaké detaily. Průměrná doba uvolnění byla zkrácena na hodinu. Někdy jsme byli hotovi za 30-40 minut. Počet chyb se výrazně snížil, ne-li desetinásobně. Snížení doby vydání samozřejmě ovlivnily i další faktory, například autotesty. Po každém vydání jsme začali provádět retrospektivy. Aby měl celý tým představu o tom, co je nového, co se změnilo a co bylo odstraněno. Bohužel ne vždy na ně admini přišli, no, admini jsou zaneprázdněni... Moje pracovní spokojenost jako vývojáře nepochybně vzrostla. Když dokážete rychle vyřešit téměř jakýkoli problém, který je ve vaší oblasti působnosti, cítíte se na vrcholu. Později pochopím, že jsme do určité míry zavedli kulturu devops, samozřejmě ne úplně, ale i ten začátek transformace byl působivý.

Třetí příběh
Spuštění. Jeden administrátor, malé vývojové oddělení. Po příjezdu jsem úplná nula, protože... Nemám přístup nikam kromě pošty. Napíšeme adminovi a požádáme o přístup. Navíc je zde informace, že ví o novém zaměstnanci a nutnosti vydat přihlašovací údaje/hesla. Poskytují přístup z úložiště a VPN. Proč poskytovat přístup k wiki, teamcity, rundesk? Pro člověka, který byl povolán k napsání celé backendové části, zbytečné věci. Až časem získáme přístup k některým nástrojům. Příjezd se samozřejmě setkal s nedůvěrou. Snažím se pomalu získat pocit, jak funguje infrastruktura projektu, prostřednictvím chatů a hlavních otázek. V podstatě nic nepoznávám. Výroba je stejná černá skříňka jako předtím. Ale víc než to, dokonce i stage servery používané pro testování jsou černou skříňkou. Nemůžeme dělat nic jiného, ​​než tam nasadit větev z Gitu. Také nemůžeme konfigurovat naši aplikaci jako soubory .env. Přístup k takovým operacím není udělen. Musíte požádat o změnu řádku v konfiguraci vaší aplikace na testovacím serveru. (Existuje teorie, že je životně důležité, aby se správci cítili v projektu důležití; pokud nebudou požádáni o změnu řádků v konfiguracích, jednoduše nebudou potřeba). No, jako vždy, není to pohodlné? To nás rychle omrzí, po přímém rozhovoru s adminem zjistíme, že vývojáři se narodili pro psaní špatného kódu, jsou od přírody neschopní jedinci a je lepší je držet dál od výroby. Ale zde také z testovacích serverů, pro každý případ. Konflikt rychle eskaluje. S adminem neprobíhá žádná komunikace. Situaci zhoršuje skutečnost, že je sám. Následuje typický obrázek. Uvolnění. Některé funkce nefungují. Trvá nám dlouho, než přijdeme na to, co se děje, do chatu se vrhají různé nápady od vývojářů, ale admin v takové situaci obvykle předpokládá, že za to mohou vývojáři. Pak píše do chatu, počkej, opravil jsem ho. Když jsme požádáni, abychom za sebou zanechali příběh s informací o tom, v čem byl problém, dostáváme toxické výmluvy. Jako, nestrkej nos tam, kam nemá. Vývojáři musí psát kód. Situace, kdy mnoho tělesných pohybů v projektu prochází jedinou osobou a pouze on má přístup k provádění operací, které všichni potřebují, je nesmírně smutná. Takový člověk je hrozné úzké hrdlo. Pokud se nápady Devops snaží zkrátit dobu uvedení na trh, pak jsou tito lidé nejhorším nepřítelem nápadů Devops. Tady se bohužel opona zatahuje.

PS Poté, co jsem si v chatech s lidmi trochu promluvil o vývojářích a správcích, potkal jsem lidi, kteří sdíleli mou bolest. Našli se ale i tací, kteří říkali, že se s něčím podobným ještě nesetkali. Na jedné devops konferenci jsem se zeptal Antona Isanina (Alfa Bank), jak se vypořádali s problémem úzkého místa v podobě adminů, na což řekl: „Nahradili jsme je tlačítky.“ Mimochodem podcast s jeho účastí. Rád bych věřil, že dobrých adminů je mnohem více než nepřátel. A ano, obrázek na začátku je skutečná korespondence.

Zdroj: www.habr.com