Andrey Nikolsky, a Banki.ru portál operatív igazgatója beszélt a tavalyi konferencián árva szolgáltatásokról: hogyan lehet azonosítani az árvát az infrastruktúrában, miért rosszak az árva szolgáltatások, mit lehet tenni velük, és mit kell tenni, ha semmi sem segít.
A vágás alatt a jelentés szöveges változata látható.
Hello kollégák! A nevem Andrey, a Banki.ru műveleteit vezetem.
Vannak nagy szolgáltatásaink, ezek ilyen monolitikus szolgáltatások, vannak klasszikusabb értelemben vett szolgáltatások, és vannak nagyon kicsik. A munkás-paraszt terminológiámban azt mondom, hogy ha egy szolgáltatás egyszerű és kicsi, akkor az mikro, ha pedig nem túl egyszerű és kicsi, akkor az csak szolgáltatás.
A szolgáltatások előnyei
Gyorsan áttekintem a szolgáltatások előnyeit.
Az első a méretezés. Gyorsan tehet valamit a szolgáltatáson, és elindíthatja a gyártást. Forgalmat kapott, klónozta a szolgáltatást. Nagyobb a forgalom, klónoztad és élsz vele. Ez jó bónusz, és elvileg, amikor elkezdtük, azt tartották számunkra a legfontosabbnak, hogy miért tesszük mindezt.
Másodszor, elszigetelt fejlesztés, amikor több fejlesztőcsapat, minden csapatban több különböző fejlesztő van, és minden csapat saját szolgáltatást fejleszt.
A csapatoknál van egy árnyalat. A fejlesztők mások. És vannak pl. . Ezt Maxim Dorofejevnél láttam először. Néha hópelyhes emberek egyes csapatokban vannak, másokban nem. Ez kissé egyenetlenné teszi a vállalaton belül igénybe vett különböző szolgáltatásokat.
Nézd meg a képet: ez egy jó fejlesztő, nagy kezei vannak, sok mindenre képes. A fő probléma az, hogy honnan származnak ezek a kezek.
A szolgáltatások lehetővé teszik különböző programozási nyelvek használatát, amelyek jobban megfelelnek a különböző feladatoknak. Néhány szolgáltatás Go-ban, néhány Erlang-ban, van Ruby-ban, valami PHP-ben, valami Python-ban. Általában nagyon széles körben bővíthető. Itt is vannak árnyalatok.
A szolgáltatás-orientált architektúra elsősorban a devopokról szól. Vagyis ha nincs automatizálásod, nincs telepítési folyamat, ha manuálisan konfigurálod, akkor a konfigurációd szolgáltatáspéldányról példányra változhatnak, és oda kell menned, hogy csinálj valamit, akkor a pokolban vagy.
Például 20 szolgáltatása van, és kézzel kell telepítenie, 20 konzolja van, és egyszerre nyomja meg az „enter” billentyűt, mint egy nindzsa. Nem túl jó.
Ha van egy szolgáltatásod a tesztelés után (persze ha van tesztelés), és még mindig fájllal kell befejezned, hogy élesben működjön, akkor is van egy rossz hírem.
Ha bizonyos Amazon-szolgáltatásokra támaszkodik, és Oroszországban dolgozik, akkor két hónappal ezelőtt azt is tapasztalta, hogy „Minden ég, jól vagyok, minden rendben van.”
Az Ansible-t a telepítés automatizálására, a Puppet-et a konvergenciára, a Bamboo-t a telepítés automatizálására, a Confluence-t pedig az egész leírására használjuk.
Nem térek ki erre részletesen, mert a jelentés inkább az interakciós gyakorlatokról szól, nem pedig a technikai megvalósításról.
Például voltak olyan problémák, amikor a Puppet a szerveren működik a Ruby 2-vel, de néhány alkalmazás Ruby 1.8-ra van írva, és nem működnek együtt. Ott valami elromlik. És amikor a Ruby több verzióját kell futtatnia egy gépen, akkor általában problémák merülnek fel.
Például minden fejlesztőnek adunk egy platformot, amelyen nagyjából minden megtalálható, amink van, az összes fejleszthető szolgáltatás, hogy legyen egy elszigetelt környezete, felbonthatja és megépítheti, ahogy akarja.
Előfordul, hogy valami speciálisan összeállított csomagra van szüksége valami támogatással. Elég kemény. Meghallgattam egy riportot, ahol a Docker kép 45 GB-ot nyom. Linuxban persze egyszerűbb, ott minden kisebb, de mégsem lesz elég hely.
Nos, vannak egymásnak ellentmondó függőségek, amikor a projekt egyik része egy verziójú könyvtártól függ, a projekt másik része egy másik verziótól függ, és a könyvtárak egyáltalán nincsenek együtt telepítve.
PHP 5.6-os oldalaink és szolgáltatásaink vannak, szégyelljük őket, de mit tehetünk? Ez az egyetlen oldalunk. PHP 7-en vannak oldalak, szolgáltatások, van több is, nem szégyelljük őket. És minden fejlesztőnek megvan a saját bázisa, ahol boldogan fűrészel.
Ha egy cégnél egy nyelven írsz, akkor fejlesztőnként három virtuális gép normálisan hangzik. Ha különböző programozási nyelvekkel rendelkezik, akkor a helyzet rosszabbodik.
Vannak webhelyei és szolgáltatásai ezen, ezen, majd egy másik webhely a Go számára, egy webhely a Ruby számára, és néhány másik Redis az oldalon. Ennek eredményeként mindez egy nagy támogatási mezővé válik, és egy része folyamatosan eltörhet.
Ezért a programozási nyelv előnyeit különböző keretrendszerek használatára cseréltük, hiszen a PHP keretrendszerek meglehetősen eltérőek, eltérő képességekkel, különböző közösségekkel, eltérő támogatással rendelkeznek. És írhatsz szolgáltatást úgy, hogy már van valami készen rá.
Minden szolgáltatásnak saját csapata van
Legfőbb előnyünk, ami több év alatt kikristályosodott, hogy minden szolgáltatásnak saját csapata van. Ez kényelmes egy nagy projektnél, időt takaríthat meg a dokumentációval, a vezetők jól ismerik a projektjüket.
Könnyedén küldhet be feladatokat a támogatásból. Például a biztosítási szolgáltatás tönkrement. A biztosítással foglalkozó csapat pedig azonnal megjavítja.
Gyorsan új funkciók jönnek létre, mert ha van egy atomszolgáltatás, gyorsan belecsavarhat valamit.
És amikor megszakítja a szolgáltatást, és ez elkerülhetetlenül megtörténik, nem befolyásolta mások szolgáltatásait, és a fejlesztők más csapatoktól nem futnak oda hozzád, és azt mondják: "Ó, ne csináld."
Mint mindig, most is vannak árnyalatok. Stabil csapataink vannak, a menedzserek hozzá vannak szögezve a csapathoz. Világos dokumentumok vannak, a vezetők mindent szorosan figyelemmel kísérnek. Minden menedzserrel rendelkező csapatnak több szolgáltatása van, és van egy meghatározott kompetenciapont.
Ha lebegnek a csapatok (mi is ezt használjuk néha), akkor van egy jó módszer, a „csillagtérkép”.
Van egy listája a szolgáltatásokról és az emberekről. A csillag azt jelenti, hogy a személy ennek a szolgáltatásnak a szakértője, a könyv azt jelenti, hogy a személy ezt a szolgáltatást tanulmányozza. A személy feladata az, hogy a füzetet csillagra cserélje. És ha nem írnak semmit a szolgáltatás elé, akkor kezdődnek a problémák, amelyekről a továbbiakban beszélek.
Hogyan jelennek meg az árva szolgáltatások?
Az első probléma, az első módja annak, hogy árva szolgáltatást kapjon az infrastruktúrájában, hogy kirúgja az embereket. Volt már olyan, hogy valaki betartotta a határidőket a feladatok értékelése előtt? Néha megesik, hogy szűkek a határidők, és egyszerűen nem jut elég idő a dokumentációra. "Át kell adnunk a szolgáltatást a termelésnek, majd hozzáadjuk."
Ha kicsi a csapat, akkor előfordul, hogy van egy fejlesztő, aki mindent megír, a többi szárnyban van. "Megírtam az alap architektúrát, tegyük hozzá a felületeket." Aztán egy ponton például a menedzser elmegy. És ebben az időszakban, amikor a menedzser távozott, és még nem neveztek ki újat, a fejlesztők maguk döntik el, hová megy a szolgáltatás, és mi történik ott. És mint tudjuk (menjünk vissza néhány diát), egyes csapatokban hópelyhes emberek, néha hópehely csapatvezetők vannak. Aztán felmond, és árva szolgálatot kapunk.
Ugyanakkor a támogatásból és az üzleti életből származó feladatok nem tűnnek el, hanem a lemaradásba kerülnek. Ha a szolgáltatás fejlesztése során architekturális hibák történtek, azok is a lemaradásba kerülnek. A szolgáltatás lassan romlik.
Hogyan lehet azonosítani az árvát?
Ez a lista jól leírja a helyzetet. Ki tanult valamit az infrastruktúrájukról?
A dokumentált megoldásokról: van szolgáltatás, és általában működik, van egy kétoldalas kézikönyve, hogy hogyan kell vele dolgozni, de belül senki sem tudja, hogyan működik.
Vagy például van valami link rövidítő. Jelenleg például három linkrövidítőt használunk különböző célokra a különböző szolgáltatásokban. Ezek csak a következmények.
Most én leszek a nyilvánvaló kapitánya. Mit kell tenni? Először is át kell adnunk a szolgáltatást egy másik menedzserhez, egy másik csapathoz. Ha a csapatvezetőd még nem lépett ki, akkor ebbe a másik csapatba, ha megérted, hogy a szolgáltatás olyan, mint egy árva, be kell vonnod valakit, aki legalább valamit ért hozzá.
A legfontosabb dolog: vérrel kell írni az áthelyezési eljárásokat. A mi esetünkben ezt szoktam figyelni, mert szükségem van rá, hogy működjön. A vezetőknek szükségük van arra, hogy gyorsan kézbesítsék, és az, hogy később mi történik vele, már nem olyan fontos számukra.
Az árva készítésének következő módja: „Kiszervezzük, gyorsabb lesz, majd átadjuk a csapatnak.” Egyértelmű, hogy mindenkinek vannak tervei a csapatban, fordulat. Egy üzleti ügyfél gyakran azt gondolja, hogy a megbízó ugyanazt fogja tenni, mint a cég műszaki osztálya. Bár a motivátoraik mások. Furcsa technológiai megoldások és furcsa algoritmikus megoldások vannak az outsourcingban.
Például volt egy szolgáltatásunk, ahol különböző váratlan helyeken volt Szfinx. Később elmondom, mit kellett tennem.
A megbízók saját maguk által írt keretrendszerrel rendelkeznek. Ez csak egy csupasz PHP másolás-beillesztéssel egy korábbi projektből, ahol mindenfélét megtalálhatsz. A telepítési szkriptek nagy hátrányt jelentenek, ha összetett Bash-szkripteket kell használnia néhány fájl több sorának megváltoztatásához, és ezeket a telepítési parancsfájlokat valamilyen harmadik szkript hívja meg. Ennek eredményeként módosítja a telepítési rendszert, mást választ, ugrál, de a szolgáltatás nem működik. Mert ott kellett még 8 linket tenni a különböző mappák közé. Vagy megesik, hogy ezer lemez működik, de százezer már nem.
Én továbbra is kapitány leszek. A kihelyezett szolgáltatás elfogadása kötelező eljárás. Volt már valakinek olyan, hogy kihelyezett szolgáltatás érkezett és nem fogadták el sehol? Ez persze nem annyira népszerű, mint egy árva szolgáltatás, de akkor is.
A szolgáltatást ellenőrizni kell, a szolgáltatást felül kell vizsgálni, a jelszavakat módosítani kell. Volt olyan esetünk, amikor szolgáltatást adtak nekünk, van egy adminisztrációs panel, hogy "if login == 'admin' && password == 'admin'...", ez van írva a kódban. Ülünk és gondolkodunk, és az emberek ezt írják 2018-ban?
A tárolókapacitás tesztelése is szükséges. Meg kell nézni, hogy mi lesz százezer lemezen, még mielőtt ezt a szolgáltatást gyártásba helyezné valahol.
Nem lehet szégyen a szolgáltatás fejlesztésére küldeni. Ha azt mondod: "Nem fogadjuk el ezt a szolgáltatást, 20 feladatunk van, csináld meg, akkor elfogadjuk", ez normális. Lelkiismeretét nem sértheti meg az a tény, hogy menedzsert állít fel, vagy hogy a vállalkozás pénzt pazarol. A vállalkozás ezután többet költ.
Volt egy esetünk, amikor úgy döntöttünk, hogy kiszervezünk egy kísérleti projektet.
Időben szállították, és ez volt az egyetlen minőségi kritérium. Ezért csináltunk egy újabb kísérleti projektet, ami már nem is volt igazán pilot. Ezeket a szolgáltatásokat elfogadták, és adminisztratív úton azt mondták: itt a kódod, itt a csapat, itt a menedzsered. A szolgáltatások valójában már elkezdtek nyereséget termelni. Ugyanakkor valójában még mindig árvák, senki sem érti a működésüket, a vezetők pedig mindent megtesznek, hogy megtagadják feladataikat.
Van egy másik nagyszerű koncepció - a gerillafejlesztés. Amikor egy részleg, általában a marketing osztály, tesztelni akar egy hipotézist, és a teljes szolgáltatást kiszervezi. Megindul a forgalom, lezárják az iratokat, aláíratják a kivitelezővel, beüzemelnek, és azt mondják: "Srácok, itt van egy szervizünk, már van forgalom, hoz pénzt, fogadjuk el." Azt mondtuk: "Oppa, hogy lehet ez?"
És egy másik módja annak, hogy árva szolgáltatást kapjunk: amikor egy csapat hirtelen leterheltnek találja magát, a vezetőség azt mondja: „Áthelyezzük ennek a csapatnak a szolgáltatását egy másik csapathoz, annak kisebb a terhelése.” Aztán áthelyezzük egy harmadik csapathoz, és megváltoztatjuk a menedzsert. És a végén megint van egy árvánk.
Mi a probléma az árvákkal?
Aki nem tudja, ez a svédországi Wasa csatahajó, amely arról híres, hogy 5 perccel az indítás után elsüllyedt. És a svéd király egyébként senkit sem végzett ki ezért. A mérnökök két generációja építette, akik nem tudták, hogyan kell ilyen hajókat építeni. Természetes hatás.
A hajó egyébként sokkal rosszabb módon is elsüllyedhetett volna, például amikor a király már lovagolt rajta valahol viharban. És így azonnal megfulladt, az Agile szerint jó korán megbukni.
Ha korán elbukunk, általában nincs probléma. Például az átvétel során átdolgozásra küldték. De ha már a termelésben megbukunk, amikor pénzt fektetnek be, akkor problémák adódhatnak. Következmények, ahogy az üzleti életben nevezik.
Miért veszélyesek az árva szolgáltatások:
- A szolgáltatás hirtelen megszakadhat.
- A szerviz javítása sokáig tart, vagy egyáltalán nem javítják.
- Biztonsági problémák.
- Problémák a fejlesztésekkel és frissítésekkel.
- Ha egy fontos szolgáltatás meghibásodik, a cég hírneve csorbul.
Mi a teendő az árva szolgáltatásokkal?
Még egyszer megismétlem, mit tegyek. Először is dokumentációnak kell lennie. A Banki.ru-nál eltöltött 7 év megtanított arra, hogy a tesztelők ne fogadják el a fejlesztők szavát, és a műveletek ne fogadják el mindenki szavát. Ellenőriznünk kell.
Másodszor, interakciós diagramokat kell írni, mert előfordul, hogy a nem túl jól fogadott szolgáltatások olyan függőségeket tartalmaznak, amelyekről senki nem beszélt. Például a fejlesztők telepítették a szolgáltatást néhány Yandex.Maps vagy Dadata kulcsára. Kifogyott a szabad limitből, minden elromlott, és egyáltalán nem tudod, mi történt. Minden ilyen rake-et le kell írni: a szolgáltatás Dadata-t, SMS-t, valami mást használ.
Harmadszor, a technikai adóssággal való munka. Amikor valamilyen mankót hajt végre, vagy elfogad egy szolgáltatást, és azt mondja, hogy valamit tenni kell, akkor meg kell bizonyosodnia arról, hogy megtörténik. Mert akkor kiderülhet, hogy nem is olyan kicsi a kis lyuk, és átesel rajta.
Az építészeti feladatokkal a Szfinxről szóló történetünk volt. Az egyik szolgáltatás a Sphinxet használta a listák bevitelére. Csak egy oldalszámozott lista, de minden este újraindexelték. Két indexből állították össze: minden este indexelt egy nagyot, és volt egy kis index is, amit rácsavartak. Minden nap, akár 50%-os valószínűséggel bombázik, akár nem, az index összeomlott a számítás során, híreink pedig leálltak a főoldalon. Eleinte 5 percbe telt az index újraindexelése, majd az index nőtt, és valamikor 40 percbe telt az újraindexelés. Amikor ezt kivágtuk, megkönnyebbülten fellélegeztünk, mert egyértelmű volt, hogy eltelik még egy kis idő, és teljes munkaidőben újraindexeljük az indexünket. Ez portálunk kudarca lesz, nyolc órája nincs hír - ez az, az üzlet leállt.
Tervezze meg egy árva szolgáltatással való együttműködést
Valójában ezt nagyon nehéz megtenni, mert a devops a kommunikációról szól. Szeretne jó viszonyban lenni a kollégáival, és amikor szabályzatokkal fejbe vágja kollégáit és vezetőit, ellentmondásos érzései lehetnek azokkal szemben, akik ezt teszik.
Mindezen pontokon kívül van még egy fontos dolog: minden egyes szolgáltatásért, a telepítési eljárás egyes szakaszaiért meghatározott személyeknek kell felelniük. Amikor nincsenek emberek, és másokat kell vonzani, ezt az egészet tanulmányozni, nehéz lesz.
Ha mindez nem segített, és az árva szolgáltatás továbbra is árva, senki nem akarja átvenni, nincs megírva a dokumentáció, a szolgáltatásba behívott csapat nem hajlandó semmit tenni, van egy egyszerű módszer - újra kell csinálni mindent .
Vagyis újra felveszed a szolgáltatás követelményeit, és új szolgáltatást írsz, jobbat, jobb platformon, furcsa technológiai megoldások nélkül. És vándorolsz hozzá a csatában.
Volt olyan helyzetünk, amikor igénybe vettünk egy szolgáltatást Yii 1-en, és rájöttünk, hogy nem tudjuk tovább fejleszteni, mert elfogytak a fejlesztők, akik jól tudnak írni Yii 1-en. Minden fejlesztő jól ír Symfony XNUMX-on. Mit kell tenni? Időt osztottunk ki, csapatot, menedzsert jelöltünk ki, átírtuk a projektet és simán átkapcsoltuk rá a forgalmat.
Ezt követően a régi szolgáltatás törölhető. Ez a kedvenc eljárásom, amikor ki kell venni és ki kell törölni a konfigurációkezelő rendszerből valamilyen szolgáltatást, majd végig kell menni, és megnézni, hogy az összes gyártásban lévő autót letiltották-e, hogy a fejlesztőknek nyoma se maradjon. Az adattár a Gitben marad.
Csak erről akartam beszélni, kész vagyok a vitára, a téma a holivar, sokan úsztak benne.
A diák azt mondta, hogy egyesítetted a nyelveket. Ilyen volt például a képek átméretezése. Valóban szigorúan egy nyelvre kell korlátozni? Mert a kép átméretezése PHP-ben, igazából Golangban is elvégezhető.
Valójában ez nem kötelező, mint minden gyakorlat. Talán bizonyos esetekben még nem is kívánatos. De meg kell értened, hogy ha van egy műszaki részleged egy 50 fős cégnél, ebből 45 PHP specialista, másik 3 devop, aki ismeri a Python-t, az Ansible-t, a Puppet-et és hasonlókat, és csak az egyikük ír néhányba. egyfajta nyelv. valami Go képátméretező szolgáltatás, majd amikor kilép, a szakértelem is vele jár. Ugyanakkor keresnie kell egy piacspecifikus fejlesztőt, aki ismeri ezt a nyelvet, különösen, ha ritka. Vagyis szervezési szempontból ez problémás. Devops szempontjából nem csak klónoznia kell néhány kész játékkönyv-készletet, amelyet a szolgáltatások üzembe helyezéséhez használ, hanem újra meg kell írnia őket.
Jelenleg egy szolgáltatást építünk a Node.js-re, és ez csak egy platform lesz a közelben minden fejlesztő számára külön nyelvvel. De ültünk és úgy gondoltuk, hogy a játék megéri a gyertyát. Vagyis ez egy olyan kérdés, amelyen le kell ülni és gondolkodni.
Hogyan figyeli a szolgáltatásait? Hogyan gyűjti és figyeli a naplókat?
A naplókat az Elasticsearch-ben gyűjtjük és a Kibanába helyezzük el, és attól függően, hogy termelési vagy tesztkörnyezetről van szó, ott különböző gyűjtőket használnak. Hol favágó, hol máshol valami más, nem emlékszem. És még mindig vannak olyan helyek bizonyos szolgáltatásokban, ahol a Telegraf-ot telepítjük, és máshol külön forgatjuk.
Hogyan éljünk együtt a Puppettel és az Ansible-vel ugyanabban a környezetben?
Valójában most két környezetünk van, az egyik a Puppet, a másik az Ansible. Azon dolgozunk, hogy hibridizáljuk őket. Az Ansible jó keretrendszer a kezdeti beállításhoz, a Puppet rossz keretrendszer a kezdeti beállításhoz, mert gyakorlati munkát igényel közvetlenül a platformon, a Puppet pedig biztosítja a konfigurációkonvergenciát. Ez azt jelenti, hogy a platform naprakész állapotban tartja magát, és ahhoz, hogy az ansibilizált gép naprakész legyen, folyamatosan, bizonyos gyakorisággal kell futtatni rajta a playbookokat. Ez a különbség.
Hogyan tartod fenn a kompatibilitást? Az Ansible-ben és a Puppet-ben is vannak konfigurációid?
Ez a mi nagy fájdalmunk, kezünkkel fenntartjuk a kompatibilitást, és azon gondolkozunk, hogyan lépjünk tovább valahol ettől az egésztől. Kiderült, hogy a Puppet kihelyezi a csomagokat és ott karbantart néhány hivatkozást, az Ansible pedig például kiadja a kódot, és ott állítja be a legújabb alkalmazáskonfigurációkat.
Az előadás a Ruby különböző verzióiról szólt. Milyen megoldás?
Ezzel egy helyen találkoztunk, és állandóan a fejünkben kell tartanunk. Egyszerűen kikapcsoltuk azt a Rubyn futó részt, amely nem volt kompatibilis az alkalmazásokkal, és külön tartottuk.
Az idei konferencia december 7-én kerül sor a Technopolisban. A beszámolókra november 11-ig várjuk a jelentkezéseket. nekünk, ha szeretnél beszélni.
A résztvevők regisztrációja megnyílt, csatlakozzon hozzánk!
Forrás: will.com