A fejlesztők a Marsról, az adminisztrátorok a Vénuszról származnak

A véletlenek véletlenek, és ez valóban egy másik bolygón történt...

Három siker- és kudarctörténetet szeretnék megosztani arról, hogyan dolgozik egy háttérfejlesztő csapatban adminisztrátorokkal.

Előbb a történelem.
Webstúdió, az alkalmazottak száma egy kézzel megszámolható. Ma layout designer vagy, holnap backender, holnapután admin. Egyrészt óriási tapasztalatokra tehet szert. Másrészt minden területen hiányzik a kompetencia. Még mindig emlékszem az első munkanapra, még mindig zöld vagyok, a főnök azt mondja: „Nyitott gitt”, de nem tudom, mi az. Az adminokkal való kommunikáció kizárt, mert te magad vagy admin. Tekintsük ennek a helyzetnek az előnyeit és hátrányait.

+ Minden hatalom a te kezedben van.
+ Nem kell könyörögni senkinek a szerverhez való hozzáférésért.
+ Gyors reakcióidő minden irányban.
+ Jól fejleszti a készségeket.
+ Teljesen ismerje a termék architektúráját.

– Magas felelősség.
— A gyártás megszakadásának veszélye.
– Nehéz minden területen jó szakembernek lenni.

Nem érdekel, menjünk tovább

A második történet.
Nagy cég, nagy projekt. Van egy 5-7 fős adminisztrációs részleg és több fejlesztő csoport is. Amikor egy ilyen céghez jössz dolgozni, minden admin azt gondolja, hogy nem azért jöttél ide, hogy egy terméken dolgozz, hanem azért, hogy eltörj valamit. Sem az aláírt NFÜ, sem a kiválasztás az interjún nem utal másra. Nem, ez az ember a piszkos kis kezeivel jött ide, hogy tönkretegye a csókolózásunkat. Ezért egy ilyen személlyel minimális kommunikációra van szüksége; legalább válaszul matricát dobhat. Ne válaszoljon a projekt architektúrával kapcsolatos kérdésekre. Nem tanácsos megadni a hozzáférést, amíg a csapatvezető nem kéri. És amikor kéri, még kevesebb kiváltsággal adja vissza, mint amennyit kértek. Szinte minden kommunikációt az ilyen rendszergazdákkal elnyel a fekete lyuk a fejlesztési osztály és az adminisztrációs osztály között. Lehetetlen azonnal megoldani a problémákat. De nem tud személyesen jönni – az adminok túlságosan elfoglaltak a hét minden napján, 24 órában. (Mit csinálsz állandóan?) Néhány teljesítményjellemző:

• Az átlagos üzembe helyezési idő a termelésben 4-5 óra
• Maximális üzembe helyezési idő éles üzemben 9 óra
• Egy fejlesztő számára egy éles alkalmazás fekete doboz, akárcsak maga az éles szerver. Hányan vannak összesen?
• A kiadások alacsony minősége, gyakori hibák
• A fejlesztő nem vesz részt a kiadási folyamatban

Nos, mit vártam, persze, új embereket nem engednek be a gyártásba. Nos, oké, miután elnyertük a türelmünket, elkezdjük elnyerni mások bizalmát. De valamiért nem ilyen egyszerű a dolog az adminokkal.

1. törvény. Az admin láthatatlan.
A megjelenés napja, a fejlesztő és az admin nem kommunikál egymással. Az adminnak nincs kérdése. De később megérted, miért. Az admin elvi ember, nincsenek hírnökei, nem adja ki senkinek a telefonszámát, és nincs profilja a közösségi oldalakon. Még fotó sincs róla sehol, hogy nézel ki haver? Körülbelül 15 percig tanácstalanul ülünk a felelős menedzserrel, és megpróbáljuk felvenni a kapcsolatot ezzel a Voyager 1-gyel, majd megjelenik egy üzenet a vállalati e-mailben, hogy befejezte. Levelezni fogunk? Miért ne? Kényelmes, nem? Na jó, hűtsük le. A folyamat már zajlik, nincs visszaút. Olvassa el újra az üzenetet. "Befejeztem". mit fejeztél be? Ahol? Hol keresselek? Itt megértheti, hogy miért normális a 4 óra elengedés. Fejlesztési sokkot kapunk, de befejezzük a kiadást. Nincs többé vágy az elengedésre.

törvény 2. Nem az a változat.
A következő kiadás. A tapasztalatok megszerzése után megkezdjük a szerverhez szükséges szoftverek és könyvtárak listáinak létrehozását a rendszergazdák számára, megjelölve néhány verziót. Mint mindig, most is gyenge rádiójelet kapunk, hogy az admin befejezett valamit. Megkezdődik a regressziós teszt, amely maga körülbelül egy órát vesz igénybe. Úgy tűnik, minden működik, de van egy kritikus hiba. A fontos funkciók nem működnek. A következő néhány óra tamburákkal való tánc, kávézaccos jóslás és minden kódrészlet részletes áttekintése volt. Az admin azt mondja, mindent megtett. A ferde fejlesztők által írt alkalmazás nem működik, de a szerver működik. Kérdésed van hozzá? Egy óra elteltével megkérjük az adminisztrátort, hogy küldje el az éles szerveren lévő könyvtár verzióját a chatbe és a bingóba – nem erre van szükségünk. Megkérjük az adminisztrátort, hogy telepítse a szükséges verziót, de válaszul azt kapjuk, hogy ezt nem tudja megtenni, mivel ez a verzió hiányzik az operációs rendszer csomagkezelőjéből. A menedzser emléke mélyéről itt emlékszik arra, hogy egy másik admin már megoldotta ezt a problémát úgy, hogy egyszerűen összeállította kézzel a kívánt verziót. De nem, a miénk ezt nem fogja megtenni. A szabályzat tiltja. Karl, már több órája itt ülünk, mennyi az időkorlát?! Újabb sokkot kapunk, és valahogy befejezzük a kiadást.

3. felvonás, rövid
Sürgős jegy, kulcsfunkciók nem működnek az éles folyamatban lévő felhasználók egyikénél. Pár órát töltünk bökdöséssel és ellenőrzéssel. Fejlesztői környezetben minden működik. Egyértelmű, hogy jó ötlet lenne megvizsgálni a php-fpm naplókat. A projektben akkoriban nem voltak olyan naplórendszerek, mint az ELK vagy a Prometheus. Nyitunk egy jegyet az adminisztrációs részleghez, hogy hozzáférést biztosítsanak a php-fpm naplókhoz a szerveren. Itt meg kell értened, hogy okkal kérünk hozzáférést, nem emlékszel arra, hogy a fekete lyuk és az adminok éjjel-nappal elfoglaltak? Ha megkéri őket, hogy nézzék meg magukat a naplókat, akkor ez egy „nem ebben az életben” prioritású feladat. A jegy elkészült, azonnali választ kaptunk az adminisztrációs osztály vezetőjétől: „Ne kelljen hozzáférni a gyártási naplókhoz, írjon hiba nélkül.” Egy függöny.

4. törvény és azután
Továbbra is több tucat problémát gyűjtünk a termelés során, a könyvtárak különböző verziói, a konfigurálatlan szoftverek, a szerverek előkészítetlen betöltése és egyéb problémák miatt. Természetesen vannak kódhibák is, nem az adminokat hibáztatjuk minden bűnért, csak megemlítünk még egy tipikus műveletet arra a projektre. Elég sok háttérmunkásunk volt, akiket a felügyelőn keresztül indítottunk el, és néhány szkriptet hozzá kellett adni a cronhoz. Néha ugyanazok a munkások abbahagyták a munkát. A sorszerver terhelése villámgyorsan nőtt, és a szomorú felhasználók a forgó betöltőre néztek. Az ilyen dolgozók gyors javításához elegendő volt egyszerűen újraindítani őket, de ismét csak egy rendszergazda teheti ezt meg. Amíg egy ilyen alapműveletet végeztek, eltelhetett egy egész nap. Itt persze érdemes megjegyezni, hogy a ferde programozóknak munkásokat kell írniuk, hogy ne zuhanjanak le, de amikor mégis esnek, jó lenne megérteni, miért, ami néha lehetetlen a termeléshez való hozzáférés hiánya miatt, természetesen, és ennek következtében a naplók hiánya a fejlesztőtől.

Átváltozás.
Mindezt elég sokáig bírva a csapattal együtt elkezdtünk egy számunkra sikeresebb irányba terelni. Összefoglalva, milyen problémákkal kellett szembenéznünk?

• Hiányzik a minőségi kommunikáció a fejlesztők és az adminisztrációs osztály között
• Az adminisztrátorok, mint kiderült(!), egyáltalán nem értik, hogyan épül fel az alkalmazás, milyen függőségei vannak és hogyan működik.
• A fejlesztők nem értik a termelési környezet működését, és ennek következtében nem tudnak hatékonyan reagálni a problémákra.
• A telepítési folyamat túl sokáig tart.
• Instabil kiadások.

Mit tettünk?
Minden kiadáshoz létrejött a Kiadási megjegyzések listája, amely tartalmazza a szerveren elvégzendő munkák listáját a következő kiadás működéséhez. A lista több szakaszt tartalmazott, olyan munkákat, amelyeket az adminisztrátornak, a kiadásért felelős személynek és a fejlesztőnek kell elvégeznie. A fejlesztők nem root hozzáférést kaptak minden éles szerverhez, ami általánosságban felgyorsította a fejlesztést és különösen a problémamegoldást. A fejlesztők tisztában vannak azzal is, hogyan működik a gyártás, milyen szolgáltatásokra oszlik, hol és mennyibe kerülnek a replikák. A harci terhelések egy része világosabbá vált, ami kétségtelenül befolyásolja a kód minőségét. A kiadás során a kommunikáció az egyik azonnali üzenetküldő chatjében zajlott. Először is volt egy naplónk minden tevékenységről, másodszor pedig a kommunikáció szűkebb környezetben zajlott. A cselekvések múltja nem egyszer tette lehetővé az új alkalmazottak számára a problémák gyorsabb megoldását. Ez paradoxon, de ez gyakran maguknak az adminoknak segített. Nem vállalom, hogy biztosat mondjak, de számomra úgy tűnik, hogy az adminisztrátorok kezdték jobban megérteni a projekt működését és megírását. Néha meg is osztottunk egymással néhány részletet. Az átlagos kiadási idő egy órára csökkent. Néha 30-40 perc alatt végeztünk. A hibák száma jelentősen, ha nem tízszeresére csökkent. Természetesen más tényezők is befolyásolták a kiadási idő csökkenését, például az automatikus tesztek. Minden megjelenés után elkezdtünk retrospektíveket készíteni. Hogy az egész csapatnak legyen fogalma az újdonságokról, mi változott és mi lett eltávolítva. Sajnos nem mindig jöttek hozzájuk az adminok, hát az adminok elfoglaltak... Fejlesztői munkával való elégedettségem kétségtelenül nőtt. Ha gyorsan meg tud oldani szinte minden olyan problémát, amely a kompetenciájába tartozik, akkor a csúcson érzi magát. Később meg fogom érteni, hogy bizonyos mértékig bevezettünk egy devops kultúrát, persze nem teljesen, de már az átalakulás kezdete is lenyűgöző volt.

Harmadik történet
Üzembe helyezés. Egy adminisztrátor, kis fejlesztési részleg. Érkezéskor teljesen nulla vagyok, mert... Sehova nem férek hozzá, csak a levélből. Írunk az adminnak és hozzáférést kérünk. Ezen kívül vannak olyan információk, amelyek szerint tisztában van az új munkatárssal és a bejelentkezési adatok/jelszavak kiadásának szükségességével. Hozzáférést biztosítanak a tárolóból és a VPN-ből. Miért adjunk hozzáférést a wikihez, a teamcityhez, a rundeskhez? Haszontalan dolgok annak a személynek, akit elhívtak, hogy írja meg a teljes háttérrészt. Csak idővel jutunk hozzá bizonyos eszközökhöz. Az érkezést természetesen bizalmatlanság fogadta. Csevegéseken és felvezető kérdéseken keresztül próbálom lassan átérezni, hogyan működik a projekt infrastruktúrája. Alapvetően nem ismerek fel semmit. A gyártás ugyanaz a fekete doboz, mint korábban. De ennél is több, még a teszteléshez használt színpadi szerverek is egy fekete doboz. Nem tehetünk mást, mint telepítünk egy ágat a Gitből. Alkalmazásunkat sem tudjuk .env fájlokhoz hasonlóan konfigurálni. Az ilyen műveletekhez nem biztosítanak hozzáférést. Könyörögnie kell, hogy módosítson egy sort az alkalmazás konfigurációjában a tesztkiszolgálón. (Van egy elmélet, miszerint az adminok számára létfontosságú, hogy fontosnak érezzék magukat a projektben; ha nem kérik őket, hogy módosítsák a sorokat a konfigurációkban, egyszerűen nem lesz szükség rájuk). Nos, mint mindig, nem kényelmes? Ez hamar unalmassá válik, az adminisztrátorral való közvetlen beszélgetés után rájövünk, hogy a fejlesztők rossz kódok írására születtek, természetüknél fogva inkompetens egyének, és jobb távol tartani őket a gyártástól. De itt is tesztszerverekről, hátha. A konfliktus gyorsan eszkalálódik. Nincs kommunikáció az adminisztrátorral. A helyzetet súlyosbítja, hogy egyedül van. A következő egy tipikus kép. Kiadás. Bizonyos funkciók nem működnek. Sok időbe telik, mire rájövünk, mi történik, a fejlesztők különféle ötletei bedobódnak a chatbe, de az adminisztrátor ilyen helyzetben általában azt feltételezi, hogy a fejlesztők a hibásak. Aztán beírja a chaten, hogy várj, kijavítottam. Amikor arra kérnek, hogy hagyjunk magunk mögött egy történetet, amelyben a probléma mi volt, mérgező kifogásokat kapunk. Például, ne dugd oda az orrodat, ahol nem való. A fejlesztőknek kódot kell írniuk. Rendkívül szomorú az a helyzet, amikor egy projektben sok testmozgás egyetlen emberen megy keresztül, és csak ő férhet hozzá a mindenki számára szükséges műveletek elvégzéséhez. Az ilyen ember szörnyű szűk keresztmetszet. Ha a Devops ötletek arra törekszenek, hogy csökkentsék a piacra jutás idejét, akkor az ilyen emberek a Devops ötletek legrosszabb ellenségei. Sajnos itt bezárul a függöny.

PS. Miután beszéltem egy kicsit a fejlesztőkről és az adminokról az emberekkel folytatott csevegés során, találkoztam olyan emberekkel, akik osztoztak a fájdalmamban. De voltak olyanok is, akik azt mondták, hogy még soha nem találkoztak ilyesmivel. Az egyik devops konferencián megkérdeztem Anton Isanint (Alfa Bank), hogyan kezelték a szűk keresztmetszet problémáját adminisztrátorok formájában, mire azt mondta: „Gombokra cseréltük őket.” Apropó podcast részvételével. Szeretném hinni, hogy sokkal több a jó admin, mint az ellenség. És igen, az elején látható kép valódi levelezés.

Forrás: www.habr.com