Andrej Nikolsky, a Banki.ru portál üzemeltetési igazgatója a tavalyi konferencián beszélt. az árvaszolgáltatásokról: hogyan ismerjük fel az árva szolgáltatásokat az infrastruktúrában, miért problémásak az árvaszolgáltatások, mit tegyünk velük, és mi a teendő, ha semmi sem segít.
A következőben megtalálható a beszámoló szöveges változata.
Üdvözlöm, kollégák! André vagyok, a Banki.ru üzemeltetését vezetem.
Nálunk vannak nagy szolgáltatások, ezek monolit szolgáltatások, vannak hagyományosabb értelemben vett szolgáltatások, és vannak nagyon kicsik is. A munkás nyelvezetemben úgy mondom, hogy ha a szolgáltatás egyszerű és kicsi, akkor mikro, ha pedig nem túl bonyolult és nem kicsi, akkor egyszerűen szolgáltatás.
A szolgáltatások előnyei
Gyorsan át fogok futni a szolgáltatások előnyein.
Az első — skálázhatóság. Gyorsan létrehozhat valamit a szolgáltatáson, és elindíthatja a termelésben. Ha jön a forgalom, klónozza a szolgáltatást. Ha újabb forgalom érkezik, akkor ismét klónozza, és ezzel él. Ez jó bónusz, és tulajdonképpen, amikor elkezdtük, ezt tartottuk a legfontosabbnak, hogy miért is csináljuk mindezt.
Másodszor, elkülönített fejlesztés van, amikor több fejlesztőcsapat van, több különböző fejlesztő minden csapatban, és minden csapat a saját szolgáltatásán dolgozik.
Itt van egy árnyalat a csapatokkal kapcsolatban. A fejlesztők különbözőek lehetnek. És léteznek például . Ezt először Makszim Dorofejevnél láttam. Néha a hóember emberek vannak egyes csapatokban, míg másokban nincsenek. Ez miatt a cégen belüli különböző szolgáltatások némileg egyenlőtlenek.
Nézzük meg a képet: ez egy jó fejlesztő, nagy kezekkel, sok mindent meg tud csinálni. A fő probléma — honnan jönnek ezek a kezek.
A szolgáltatások lehetőséget adnak különböző programozási nyelvek használatára, amelyek jobban megfelelnek a különböző feladatoknak. Egyik szolgáltatás Go nyelven, másik Erlangon, megint másik Ruby-n, valami PHP-n, valami Python-on. Általánosságban széles spektrumot ölelhetünk fel. Itt is vannak árnyalatok.
A szolgáltatásorientált architektúra elsősorban a devopsról szól. Tehát ha nincs automatizálás, nincs telepítési folyamat, ha kézzel állítja be, akkor a konfigurációk eltérhetnek a szolgáltatás példányai között, és rendszeresen be kell lépnie, hogy csináljon valamit, akkor pokolban jár.
Például, ha 20 szolgáltatása van, és kézzel kell telepítenie, akkor 20 konzolja van, és egyszerre nyomja meg az "enter"-t, mint egy nindzsa. Ez nem túl jó.
Ha egy szolgáltatása van, amely a tesztelés után (ha van tesztelés, természetesen) még finomhangolásra szorul, hogy működjön a termelésben, akkor nekem is rossz híreim vannak az Ön számára.
Ha specifikus Amazon szolgáltatásokra támaszkodik és Oroszországban dolgozik, akkor két hónappal ezelőtt is ezt mondta: "Minden körülöttem ég, jól vagyok, minden klassz".
Az Ansible-t használjuk a telepítés automatizálásához, a Puppet-et a konvergenciához, a Bamboo-t a telepítés automatizálásához, a Confluence-t pedig annak leírásához.
Erről részletesebben nem szeretnék kitérni, mert a beszámoló inkább az interakciók gyakorlatairól szól, nem a technikai megvalósításról.
Például előfordult, hogy a Puppet a szerveren Ruby 2-t használ, míg egy alkalmazás Ruby 1.8-ra lett írva, és együtt nem működnek. Ott valamilyen hiba bekövetkezik. Amikor pedig több Ruby-változatot kell fenntartania egy gépen, általában problémák merülnek fel.
Például minden fejlesztőnknek biztosítunk egy környezetet, ahol körülbelül minden elérhető, minden szolgáltatás, amit fejleszteni lehet, hogy izolált környezetben dolgozhassanak, és szabadon kísérletezhessenek.
Előfordul, hogy szükség van egy speciálisan lefordított csomagra, amely támogatja az adott dolgot. Ez elég szigorú. Hallottam egy előadást, ahol a Docker-kép 45 GB volt. A Linuxban természetesen kicsit egyszerűbb, ott kisebb, de még mindig nem lesz hely elég.
Nos, és előfordulhat, hogy ellentmondásos függőségek vannak, amikor a projekt egy része egy könyvtár egyik verziójára támaszkodik, míg a projekt másik része egy másik verziójára, és a könyvtárakat egyáltalán nem lehet együtt telepíteni.
Van néhány weboldalunk és szolgáltatásunk PHP 5.6-ra, amiért szégyelljük magunkat, de mit tegyünk. Ez egy platformunkon van. Van szintén weboldalunk és szolgáltatásunk PHP 7-en, ezekből több van, ezért ezekért nem szégyelljük magunkat. És minden fejlesztőnek van egy kis adatbázisa, ahol boldogan dolgozik.
Ha ugyanazon a nyelven írsz egy cégnél, akkor három virtuális gép fejlesztőnként normálisnak számít. Ha különböző programozási nyelvek vannak, akkor a helyzet rosszabbá válik.
Keletkeznek weboldalak és szolgáltatások ezen, azon, majd még egy platform a Go számára, egy platform a Ruby számára, és még valami Redis oldalt. Végül ez egy nagy támogatási mezővé alakul, és az is folyamatosan elromolhat valami.
Ezért cseréltük le a programozási nyelv előnyeit különböző keretrendszerek használatára, mivel a PHP keretrendszerek eléggé eltérőek, különböző lehetőségeik vannak, eltérő közösségeik és támogatásuk. Így lehet szolgáltatást írni úgy, hogy már van valami kész alatta.
Minden szolgáltatásnak megvan a saját csapata.
A legnagyobb előnyünk, ami az évek során kialakult, hogy minden szolgáltatásnak van saját csapata. Ez kényelmes nagy projektek esetében, időt takaríthatunk meg a dokumentációval, a menedzserek jól ismerik a saját projektjüket.
A támogatási feladatokat kiválóan át lehet adni. Például, ha elromlott a biztosítási szolgáltatás. Akkor azonnal a biztosítással foglalkozó csapat megy és javítja.
Új funkciók gyorsan megvalósíthatók, mert ha van egy atomikus szolgáltatásod, akkor abba gyorsan be lehet építeni valamit.
És amikor elrontottad a szolgáltatásodat, ami elkerülhetetlenül bekövetkezik, nem érinti más szolgáltatásokat, és nem rohannak hozzád a más csapatoktól érkező fejlesztők, hogy azt mondják: «Aj-aj, ezt nem lenne szabad csinálni».
Mint mindig, vannak árnyalatok. Stabil csapataink vannak, a menedzserek szoros együttműködésben dolgoznak a csapattal. Világos dokumentumok vannak, a menedzserek szorosan figyelemmel kísérik ezeket. Minden csapatnak a menedzserével van néhány szolgáltatása, és van konkrét kompetencia pont.
Ha a csapatok mozgékonyak (ez néha nálunk is használatos), van egy jó módszer, amit «csillagtérképnek» hívnak.
Van egy listád a szolgáltatásokról és az emberekről. A csillag azt jelenti, hogy az illető szakértő az adott szolgáltatásban, a könyv azt jelenti, hogy az illető tanulmányozza azt a szolgáltatást. Az illető feladata, hogy a könyvet cserélje egy csillagra. Ha viszont a szolgáltatás mellett semmi sincs írva, akkor problémák kezdődnek, amiről később mesélek.
Hogyan jelennek meg az árván maradt szolgáltatások?
Az első probléma, az első mód, hogy egy árvának számító szolgáltatást hozzunk létre az infrastruktúrában – az emberek elbocsátása. Volt már valakinek olyan élménye, amikor az üzletből érkező határidők megérkeznek, mielőtt a feladatok felmérésére sor kerülne? Néha előfordul, hogy a határidők szigorúak, és a dokumentációra egyszerűen nincs elég idő. "A szolgáltatást át kell adni a termelésnek, utána majd kiegészítjük."
Ha a csapat kicsi, előfordulhat, hogy van benne egy fejlesztő, aki mindent ír, a többiek pedig kisegítik. "Én írtam a fő architektúrát, te pedig készíts néhány interfészt." Aztán egy idő után például a menedzser elmegy. Ebben az időszakban, amikor a menedzser elment, de még nincs új, a fejlesztők maguk döntenek arról, merre halad a szolgáltatás, mi történik. Ahogy tudjuk (térjünk vissza néhány diával korábban), egyes csapatokban vannak hópehely emberek, néha hópehely csapatvezető. Aztán ő is elmegy, és mi egy árvát kapunk.
Eközben a támogatásból és az üzletből érkező feladatok nem tűnnek el, hanem a backlogueba kerülnek. Ha a szolgáltatás fejlesztése során voltak architekturális hibák, azok is a backlogueban maradnak. A szolgáltatás lassan degradálódik.
Hogyan ismerjük fel az árvát?
Ez a lista jól leírja a helyzetet. Ki talált valamit a saját infrastruktúrájában?
A dokumentált work-around-okkal kapcsolatban: van egy szolgáltatás, amely alapvetően működik, van egy kétoldalas útmutató arról, hogyan kell vele dolgozni, de senki sem tudja, hogy belül hogyan működik.
Vagy például van egy linkrövidítő szolgáltatásunk. Jelenleg három különböző linkrövidítőt használunk különböző célokra a különböző szolgáltatásokban. Ezek ennek a következményei.
Most az evidens dolgok kapitányává válok. Mit kell tenni? Először is, a szolgáltatást át kell adni egy másik menedzsernek, egy másik csapatnak. Ha a csapatvezetőd még nem távozott, akkor abba az új csapatba, amikor úgy érzed, hogy a szolgáltatás árvához hasonlít, be kell vonni valakit, aki legalább egy kicsit ért hozzá.
A legfontosabb dolog: a procedúráknak, amelyeket vérrel írtak, átadottnak kell lenniük. A mi esetünkben ezt általában én figyelem, mert nekem fontos, hogy minden jól működjön. A menedzsereknek az a fontos, hogy ezt gyorsan átadják, hogy utána mi történik vele, az már nem annyira lényeges számukra.
A következő módja a mostohagyermek létrehozásának az, hogy "kiszervezzük, így gyorsabb lesz, és utána átadjuk a csapatnak". Nyilvánvaló, hogy mindenkinek vannak tervei a csapatban, sorban állás. Gyakran a megrendelő azt hiszi, hogy a külsős szakszolgáltatók ugyanúgy dolgoznak, mint a cég technikai osztálya. Pedig motivációik eltérőek. A külsősöknél furcsa technológiai megoldások és különös algoritmusok is előfordulnak.
Például volt egy szolgáltatásunk, amelyben a Sphinx különböző meglepő helyeken volt. Később elmondom, mit kellett tennünk.
A külsős cégek saját keretrendszerekkel dolgozhatnak. Ez egyszerűen egy szűk PHP, amelyben a korábbi projektből másoltak be kódot, ahol bármi megtalálható. Nagy kódvázlatok a telepítő szkriptekben, amikor bonyolult Bash-szkriptek segítségével kell pár sort megváltoztatni egy fájlban, miközben ezek a telepítő szkriptek egy harmadik skripttel vannak meghívva. Végül megváltoztatja a telepítési rendszert, választ egy mást, és hopp, máris nem működik a szolgáltatás. Mert ott még 8 hivatkozást kellett volna elhelyezni különböző mappák között. Vagy megtörténik, hogy ezer bejegyzés működik, de százezer már nem.
Folytatom a kapitánykodást. A külsős szolgáltatás átvétele egy kötelező eljárás. Valakinek már volt olyan tapasztalata, hogy a külsős szolgáltatás megérkezett, de senki sem fogadta el? Ez nem annyira népszerű, mint a mostohagyermek szolgáltatás, de mégis.
A szolgáltatást ellenőrizni kell, a szolgáltatást felül kell vizsgálni, a jelszavakat meg kell változtatni. Volt olyan esetünk, amikor egy szolgáltatást dobtak ránk, ahol az adminisztrációs felület kódjában "if login == 'admin' && password == 'admin'..." volt megírva. Ülünk, és gondolkodunk, hogy ezt 2018-ban tényleg emberek írják?
A tárolási kapacitás tesztelése is szükséges. Meg kell nézni, mi történik száz ezer bejegyzésnél, még azelőtt, hogy ezt a szolgáltatást élesben bevezetnénk.
Nem szabad szégyenkezni, ha a szolgáltatást újraírásra kell küldeni. Amikor azt mondja: "Nem fogadjuk el ezt a szolgáltatást, van 20 feladatunk, végezzék el ezeket, akkor elfogadjuk", ez teljesen normális. A lelkiismerete nem vonhatja kétségbe, hogy a menedzsert vagy hogy a vállalkozás pénzt költ. A vállalkozás később sokkal többet költ.
Volt egy esetünk, amikor úgy döntöttünk, hogy pilóta projekten dolgozunk külsős cégnél.
Időben leadták, és ez volt az egyetlen minőségi kritérium. Ezért egy másik, már nem is egészen pilot projektet készítettek. Ezeket a szolgáltatásokat elfogadták, adminisztratív módon közölték, itt van a kód, itt a csapat, itt a menedzser. A szolgáltatások valóban elkezdtek nyereséget termelni. Ennek ellenére a valóságban továbbra is árvák maradtak, senki sem érti, hogyan működnek, és a menedzserek mindent elhárítanak a feladataiktól.
Van egy másik nagyszerű fogalom - partizánfejlesztés. Amikor egy részleg, rendszerint a marketing osztály, szeretné tesztelni a hipotézist, és egy szolgáltatást teljesen kiszervezve rendelnek meg. Erre elkezd beérkezni a forgalom, lezárják az iratokat, aláírják a szerződést a kivitelezővel, átadják a szolgáltatást, és azt mondják: „Fiúk, nekünk itt van egy szolgáltatás, már van forgalmunk, pénzt hoz nekünk, fogadjuk el.” Mi meg azt mondjuk: „Hoppá, hogyan is történt ez?”.
És még egy módja van az árvák szolgáltatásainak megszerzésének: amikor egy csapat hirtelen túlterhelt lesz, a vezetőség azt mondja: „Vigyük át ennek a csapatnak a szolgáltatását egy másik csapatnak, amelynek kisebb a terhelése.” Aztán átadjuk egy harmadik csapatnak, és a menedzsert is kicseréljük. És végül megint árvák leszünk.
Mi a probléma az árvákkal?
Aki nem tudja, ez a Wasa nevű, Svédországban emelt csatahajó, híres arról, hogy öt perccel a vízre bocsátás után elsüllyedt. A svéd király egyébként senkit sem ölt meg ezért. Két mérnögeneráció építette, akik nem tudták, hogyan kell ilyen hajókat építeni. Logikus következmény.
A hajó amúgy sokkal rosszabbul is elsüllyedhetett volna, például amikor rajta volt a király, aki valahová indult viharba. Így viszont azonnal elsüllyedt, ami az agilis módszertan szerint jó — korai bukás.
Ha korán buktunk meg, általában nincsenek problémák. Például az átvétel során küldtük átfinomításra. De ha már a termelésben buktunk meg, amikor pénzt fektettek bele, akkor problémák adódhatnak. Az üzleti nyelven következmények.
Mik a veszélyei az árvák szolgáltatásainak:
- A szolgáltatás váratlanul lerobbanhat.
- A szolgáltatás sokáig javítva van, vagy egyáltalán nem javítják.
- Biztonsági problémák.
- Problémák a finomításokkal és frissítésekkel.
- Ha egy fontos szolgáltatás elromlik, a cég hírneve szenved.
Mit tegyünk az árvák szolgáltatásaival?
Ismételten szeretném hangsúlyozni, hogy mit kell tenni. Először is, szükség van dokumentációra. 7 év a Banki.ru-nál megtanított arra, hogy a tesztelőknek nem szabad a fejlesztők szavára hagyatkozniuk, és üzemeltetés sem bízhat meg mindenkiben. Ellenőrizni kell.
Másodszor, interakciós sémákat kell írni, mert néha a nem túl jól elfogadott szolgáltatások olyan függőségeket tartalmaznak, amelyekről senki sem beszélt. Például a fejlesztők a saját kulcsukkal csatlakoztatták a szolgáltatást valamilyen Yandex.Térképhez vagy a Dadata-hoz. Ha elfogy a szabad kereted, minden összeomlik, és nem tudod, mi történt. Minden ilyen csapda dokumentálva kell, hogy legyen: a szolgáltatás használja a Dadata-t, Sms-t, vagy valami mást.
Harmadszor, technikai adóssággal való munka. Amikor valamilyen átmeneti megoldást csinálsz, vagy elfogadsz egy szolgáltatást, és mondod, hogy valakit meg kell csinálni, figyelni kell, hogy azt meg is csinálják. Mert később kiderülhet, hogy a kis gödör nem is olyan kicsi, és bele is esel.
Az architekturális feladatokkal kapcsolatban a Sphinx története volt. Az egyik szolgáltatásban a Sphinx a listák bevitelére volt használva. Csak egy lista lapozással, de közben minden éjszaka újra indexeltek. Két indexből állt: az egyik indexet minden éjszaka nagyban, a másikat pedig kisban indexelték. Minden nap, 50% eséllyel vagy felrobban, vagy nem, az indexelés során és a hírek nem frissültek a főoldalon. Először ez 5 perc volt, amíg az index újraindult, később az index megnövekedett, és egy idő után 40 percig tartott az újraindexelés. Amikor ezt eltávolítottuk, megkönnyebbültünk, mert nyilvánvaló volt, hogy hamarosan az index teljes munkanapot fog újraindexelni. Ez kudarcot jelentett volna a portálunk számára, nyolc óra hírek nélkül — minden, a business megállt.
A munka terve árvaszolgáltatással
Valójában nagyon nehéz ezt csinálni, mert a DevOps a kommunikációról szól. Jó kapcsolatokat szeretnél ápolni a kollégáiddal, és amikor a kollégákat és a menedzsereket szabályokkal ütik fejbe, ellentmondásos érzéseik lehetnek azok iránt, akik így cselekszenek.
Mindezeken túl van egy másik fontos dolog: minden egyes szolgáltatásért, a telepítési folyamat konkrét szakaszaiért konkrét embereknek kell felelniük. Ha nincsenek emberek, és másokat kell bevonni, hogy ezt az egészet tanulmányozzák, akkor az nehézkessé válik.
Ha mindez nem segített, és a szolgáltatás még mindig árván maradt, senki sem akarja elvinni, a dokumentáció nem készül el, a csapat, akit a szolgáltatáshoz behoztak, visszautasít mindent, van egy egyszerű megoldás - mindent átírni.
Tehát újra megfogalmazod a szolgáltatás követelményeit, és írsz egy új szolgáltatást, egy jobb platformon, furcsa technológiai megoldások nélkül. És átköltözöl rá a gyakorlatban.
Volt egy helyzetünk, amikor egy Yii 1-es szolgáltatást vettünk át, és rájöttünk, hogy nem tudjuk tovább fejleszteni, mert elfogytak a Yii 1-ben jól író fejlesztők. Minden fejlesztő jól tud írni a harmadik Symfony-val. Mi a teendő? Időt, csapatot és menedzsert jelöltünk ki, átírtuk a projektet, és fokozatosan áttettük rá a forgalmat.
Ezután a régi szolgáltatás eltávolítható. Ez a kedvenc eljárásom, amikor a konfigurációkezelő rendszerből elő kell venni egy szolgáltatást, és ki kell takarítani, majd megnézni, hogy minden szerver a termelésben le legyen állítva, hogy a fejlesztőknek ne maradjon nyoma. A git repó megmarad.
Ez minden, amit el akartam mondani, készen állok a vitára, a téma vitás, sokan úszkáltak benne.
A diákat nézve szó volt arról, hogy egységesítettétek a nyelveket. Példaként a képek átméretezését említettétek. De tényleg szükséges, hogy egy nyelvre korlátozzuk? Mert a kép átméretezés PHP-n, nos, valóban meg lehetett volna csinálni Golang-ban is.
Valójában ez nem kötelező, ahogyan minden más gyakorlat sem. Lehet, hogy bizonyos esetekben még el is kerülendő. De meg kell érteni, hogy ha a cégében 50 fős műszaki részleg van, ahol 45-en PHP-fejlesztők, 3-an DevOps mérnökök, akik tudnak Python, Ansible, Puppet és hasonlók, és csak egy ír valamilyen Go nyelven képkockázó szolgáltatást, akkor amikor ő elmegy, az értékes tudás vele távozik. És ezzel együtt speciális fejlesztőt kell keresnie a piacon, aki ismeri ezt a nyelvet, különösen, ha ritka. Tehát szervezeti szempontból ez problémás. DevOps szempontból nem csak egy meglévő, szolgáltatások telepítéséhez használt playbook-ot kell klónozni, hanem újra kell írni őket.
Jelenleg Node.js-en készítünk egy szolgáltatást, és ez tényleg egy platform lesz minden fejlesztő számára, különböző nyelveken. De leültünk, és átgondoltuk, hogy megéri-e. Tehát itt az a kérdés, hogy érdemes-e leülni és gondolkodni.
Hogyan monitorozzátok a szolgáltatásaitokat? Hogyan gyűjtitek és követitek a naplókat?
A naplókat Elasticsearchba gyűjtjük, és a Kibanában helyezzük el, attól függően, hogy éles vagy tesztkörnyezet, különböző gyűjtőket használunk. Valahol Lumberjack, máshol meg valami más, már nem emlékszem. És van még néhány hely bizonyos szolgáltatásokban, ahol Telegrafot állítunk be, és különböző helyekre küldjük.
Hogyan éljünk együtt a Puppet-tel és az Ansible-lal egy környezetben?
Valójában most két környezetünk van, egy Puppet és egy Ansible. Dolgozunk azon, hogy hibridáljuk őket. Az Ansible jó környezet az első beállításhoz, a Puppet pedig nem túl jó az első beállításhoz, mert közvetlenül a platformon kell dolgozni, és a Puppet biztosítja a konfiguráció konvergenciáját. Ez azt jelenti, hogy a platform önmagát támogatja aktuális állapotban, míg ahhoz, hogy az Ansible által kezelt gép aktuális maradjon, folyamatosan futtatni kell rajta playbook-okat valamilyen időszakonként. Ez a különbség.
Hogyan biztosítjátok a kompatibilitást? Vannak konfigurációitok Ansible-ben és Puppet-ben is?
Ez a mi nagy fájdalmunk, manuálisan biztosítjuk a kompatibilitást, és azon gondolkodunk, hogyan lépjünk át mindezen. A Puppet telepíti a csomagokat és tart néhány linket, míg az Ansible például kódot telepít és friss alkalmazáskonfigurációkat illeszt be.
A prezentációban különböző Ruby verziókról volt szó. Milyen megoldást javasolsz?
Egy helyen találkoztunk ezzel, és folyamatosan fejben kell tartanunk. Csak azt a részt kapcsoltuk ki, amely a Ruby azon verzióján futott, ami nem volt kompatibilis az alkalmazásokkal, és külön tartottuk.
Idén a konferencia december 7-én a 'Technopolis'-ban kerül megrendezésre. November 11-ig fogadjuk a jelentkezéseket az előadásokra. ha szeretnél előadni.
A résztvevők regisztrációja nyitva áll, csatlakozzatok!
Forrás: habr.com
