Április 25-én a Mail.ru Group konferenciát tartott a felhőkről és a környékről - . Néhány kiemelés:
- A fő — A Mail.ru Cloud Solutions, a #CloudMTS, a SberCloud, a Selectel, a Rostelecom Data Center és a Yandex.Cloud beszélt felhőpiacunk sajátosságairól és szolgáltatásaikról;
- A Bitrix24 kollégái elmondták, hogyan ;
- Leroy Merlin, Otkritie, Burger King és Schneider Electric nyújtottak érdekességet — milyen IT-feladatokat tűz ki vállalkozásuk elé, és milyen technológiákat – köztük a felhőalapúakat – látják a legígéretesebbnek.
Megtekintheti a mailto:CLOUD konferencia összes videóját , itt pedig elolvashatod, hogyan zajlott a mikroszolgáltatásokról szóló vita. Alekszandr Deulin, a MegaFon üzleti rendszerek kutatási és fejlesztési központjának vezetője és Szergej Szergejev, az M.Video-Eldorado csoport információs technológiai igazgatója megosztotta a monolitoktól való megszabadulás sikeres eseteit. Megbeszéltük az informatikai stratégia, a folyamatok, sőt a HR kapcsolódó kérdéseit is.
Panelírók
- Szergej Szergejev, Csoport informatikai igazgatója "M.Video-Eldorado";
- Alexander Deulin, az üzleti rendszerek kutatási és fejlesztési központjának vezetője MegaFon;
- Moderátor — Dmitrij Lazarenko, a PaaS irányának vezetője Mail.ru Cloud Solutions.
Alexander Deulin beszéde után csatlakozik hozzá a beszélgetéshez Szergej Szergejev (M.Video-Eldorado) és Dmitry Lazarenko, a Mail.ru Cloud Solutions vita moderátora.
Az alábbiakban elkészítettük számotokra a beszélgetés átiratát, de megtekintheti a videót is:
A mikroszolgáltatásokra való átállás a piaci igényekre adott válasz
Dmitrij:
Volt már sikeres tapasztalata a mikroszolgáltatásokra való átállással kapcsolatban? És általában: hol látja a legnagyobb üzleti hasznot a mikroszolgáltatások használatából vagy a monolitokról a mikroszolgáltatások felé való átállásból?
Szergej:
Valamilyen utat már elértünk a mikroszolgáltatásokra való átállásban, és több mint három éve alkalmazzuk ezt a megközelítést. Az első igény, amely indokolta a mikroszolgáltatások szükségességét, a különböző front-end termékek végtelen integrálása volt a háttérirodával. És minden alkalommal kénytelenek voltunk további integrációt és fejlesztést végezni, bevezetve a saját szabályainkat az adott szolgáltatás működéséhez.
Egy ponton rájöttünk, hogy fel kell gyorsítanunk rendszereink működését és a funkcionalitás kimenetét. Abban a pillanatban már léteztek a piacon olyan koncepciók, mint a mikroszolgáltatások és a mikroszolgáltatási megközelítés, ezért úgy döntöttünk, hogy kipróbáljuk. Ez 2016-ban kezdődött. Ezután a platformot lefektették, és az első 10 szolgáltatást külön csapat valósította meg.
Az egyik első, legterheltebb szolgáltatás az árkalkulációs szolgáltatás volt. Minden alkalommal, amikor bármely csatornára, az M.Video-Eldorado cégcsoporthoz érkezik, legyen az weboldal vagy kiskereskedelmi üzlet, ott kiválaszt egy terméket, megnézi az árat a weboldalon vagy a „Kosárban”, a költség automatikusan megjelenik egy szolgáltatással számolva. Miért van erre szükség: ezt megelőzően minden rendszernek megvoltak a saját elvei a promóciókkal - kedvezményekkel és így tovább. Az árképzést háttérirodánk intézi, a kedvezményes funkcionalitást egy másik rendszerben valósítjuk meg. Ezt központosítani kellett, és üzleti folyamat formájában egyedi, elkülöníthető szolgáltatást kellett létrehozni, amely lehetővé teszi ennek megvalósítását. Nagyjából így kezdtük.
Az első eredmények értéke nagyon nagy volt. Először is tudtunk olyan elkülöníthető entitásokat létrehozni, amelyek lehetővé teszik számunkra, hogy külön-külön és összesített módon dolgozzunk. Másodszor, csökkentettük a tulajdonlási költségeket a több rendszerrel való integráció tekintetében.
Az elmúlt három év során három frontvonali rendszert adtunk hozzá. Nehéz volt fenntartani őket a vállalat által megengedhető forrásmennyiséggel. Ezért felmerült a feladat, hogy a piacra gyorsaságban, belső költségekben és hatékonyságban reagálva új piacokat keressünk.
Hogyan mérhető a mikroszolgáltatásokra való átállás sikere?
Dmitrij:
Hogyan határozható meg a mikroszolgáltatásokra való átállás sikere? Mi volt az „előtte” az egyes cégeknél? Milyen mérőszámot használt az átállás sikerességének meghatározására, és ki határozta meg valójában?
Szergej:
Mindenekelőtt az IT-n belül született meg, mint lehetővé tevő – új képességek „feloldása”. Arra volt szükségünk, hogy viszonylag ugyanannyi pénzért mindent gyorsabban csináljunk, reagálva a piaci kihívásokra. A siker most a különböző rendszerek által újrafelhasznált szolgáltatások számában, a folyamatok egymás közötti egységesítésében fejeződik ki. Most van, de abban a pillanatban lehetőség nyílt egy platform létrehozására, és megerősíteni azt a hipotézist, hogy ezt megtehetjük, ez meg fogja adni a hatást és kiszámítani az üzleti helyzetet.
Sándor:
A siker inkább belső érzés. Az üzlet mindig többet akar, és lemaradásunk mélysége a siker bizonyítéka. Nekem úgy tűnik.
Szergej:
Igen, egyetértek. Három év alatt már több mint kétszáz szolgáltatásunk és lemaradásunk van. A csapaton belüli erőforrásigény csak nő – évente 30%-kal. Ez azért történik, mert az emberek érezték: gyorsabb, más, más technológiák vannak, mindez fejlődik.
Jönnek a mikroszolgáltatások, de a mag megmarad
Dmitrij:
Olyan ez, mint egy véget nem érő folyamat, ahol fejlesztésbe fektetsz be. Az üzleti mikroszolgáltatásokra való átállás már véget ért, vagy nem?
Szergej:
Nagyon könnyű válaszolni. Mit gondolsz: a telefonok cseréje végtelen folyamat? Mi magunk vásárolunk telefonokat minden évben. És itt van: amíg szükség van a gyorsaságra, a piachoz való alkalmazkodásra, addig bizonyos változtatásokra lesz szükség. Ez nem jelenti azt, hogy elhagyjuk a szokásos dolgokat.
De nem tudunk egyszerre mindent lefedni és újra csinálni. Vannak örökölt, szabványos integrációs szolgáltatásaink, amelyek korábban is léteztek: vállalati buszok és így tovább. De van lemaradás, és van igény is. A mobilalkalmazások száma és funkcionalitásuk növekszik. Ugyanakkor senki nem mondja, hogy 30%-kal több pénzt kapsz. Vagyis egyrészt mindig vannak igények, másrészt a hatékonyság keresése.
Dmitrij:
Az élet jó formában van. (nevet)
Sándor:
Általában igen. Nincsenek forradalmi megközelítéseink a magrésznek a tájból való eltávolítására. Szisztematikus munka folyik a rendszerek szétbontásán, hogy azok jobban összhangban legyenek a mikroszolgáltatási architektúrával, hogy csökkentsék a rendszerek egymásra gyakorolt hatását.
De azt tervezzük, hogy megtartjuk a központi részt, mivel az üzemeltetői környezetben mindig lesz néhány platform, amit megvásárolunk. Ismét szükségünk van egy egészséges egyensúlyra: nem szabad rohanni a mag kivágásával. Egymás mellé helyezzük a rendszereket, és most kiderült, hogy már sok alapvető alkatrész tetején vagyunk. Továbbá a funkcionalitás fejlesztésével létrehozzuk a szükséges reprezentációkat minden kommunikációs szolgáltatásunkkal működő csatornához.
Hogyan adjunk el mikroszolgáltatásokat vállalkozásoknak
Dmitrij:
Érdeklődöm azok számára is, akik még nem váltottak, de tervezik: mennyire volt könnyű eladni ezt az ötletet az üzletnek, és kaland volt, befektetési projekt? Vagy tudatos stratégia volt: most mikroszolgáltatásokra megyünk, és ennyi, semmi sem állít meg. Neked milyen volt?
Szergej:
Nem megközelítést árultunk, hanem üzleti hasznot. Probléma volt az üzleti életben, és megpróbáltuk megoldani. Abban a pillanatban ez abban nyilvánult meg, hogy a különböző csatornák eltérő alapelveket alkalmaztak az árak kiszámításához - külön-külön az akciókhoz, az akciókhoz stb. Nehéz volt karbantartani, előfordultak hibák, meghallgattuk az ügyfelek panaszait. Vagyis egy probléma megoldását adtuk el, de azzal jöttünk, hogy pénzre volt szükségünk egy platform létrehozásához. És bemutattak egy üzleti esetet a befektetés első szakaszának példáján: hogyan fogjuk tovább megtéríteni, és ez mit tesz lehetővé.
Dmitrij:
Feljegyezted valahogy az első szakasz idejét?
Szergej:
Igen, persze. Hat hónapot szántunk a mag platformként való létrehozására és a pilot tesztelésére. Ez idő alatt megpróbáltunk olyan platformot létrehozni, amelyen a pilótát korcsolyázni tudjuk. Aztán a hipotézis beigazolódott, és mivel működik, ez azt jelenti, hogy folytathatjuk. Elkezdték reprodukálni és megerősíteni a csapatot – áthelyezték egy külön divízióba, amely éppen ezt teszi.
Ezután következik a szisztematikus munka, amely az üzleti igényeken, a lehetőségeken, az erőforrások rendelkezésre állásán és mindenen, ami jelenleg készül.
Dmitrij:
RENDBEN. Sándor, mit szólsz?
Sándor:
Mikroszolgáltatásaink a „tenger habjából” születtek – az erőforrás-takarékosság, a szerverkapacitás és a csapaton belüli erők újraelosztása formájában jelentkező némi maradék miatt. Kezdetben nem adtuk el ezt a projektet vállalkozásoknak. Ez egy olyan projekt volt, amelyben mindketten kutakodtunk és ennek megfelelően fejlesztettünk. 2018 elején kezdtük, és egyszerűen lelkesedéssel fejlesztettük ezt az irányt. Az értékesítés még csak most kezdődött, és folyamatban vagyunk.
Dmitrij:
Előfordul, hogy egy vállalkozás megengedi Önnek, hogy olyan dolgokat csináljon, mint a Google – heti egy szabad napon? Van ilyen irányvonal?
Sándor:
A kutatással egy időben üzleti problémákkal is foglalkoztunk, így minden mikroszolgáltatásunk megoldást jelent az üzleti problémákra. Csak az elején építettünk olyan mikroszolgáltatásokat, amelyek az előfizetői bázis egy kis részét lefedték, és mára szinte az összes zászlóshajó termékben jelen vagyunk.
Az anyagi hatás pedig már most is látszik - már számolhatunk is, megbecsülhető a termékbevezetések sebessége és a bevételkiesés, ha a régi utat követtük volna. Erre építjük az ügyet.
Mikroszolgáltatások: hype vagy szükségszerűség?
Dmitrij:
A számok számok. A bevétel vagy a megtakarított pénz pedig nagyon fontos. Mi van, ha a másik oldalra néz? Úgy tűnik, hogy a mikroszolgáltatások trend, felhajtás, és sok cég visszaél vele? Mennyire világosan tesz különbséget aközött, amit csinál, és amit nem fordít le mikroszolgáltatásokra? Ha most örökség, akkor 5 év múlva is lesz öröksége? Hány évesek lesznek az M.Video-Eldorádóban és a MegaFonnál működő információs rendszerek 5 év múlva? Lesznek tíz-tizenöt éves információs rendszerek, vagy egy új generáció? Hogy látod ezt?
Szergej:
Úgy tűnik számomra, hogy nehéz nagyon messzire gondolni. Ha visszatekintünk, ki gondolta, hogy a technológiai piac így fog fejlődni, beleértve a gépi tanulást és a felhasználó arcalapú azonosítását? De ha az elkövetkező éveket nézzük, számomra úgy tűnik, hogy az alapvető rendszerek, a vállalati ERP-osztályú rendszerek a vállalatoknál - ezek már elég régóta működnek.
Cégeink együttesen 25 évesek, és a klasszikus ERP-vel nagyon mélyen vannak a rendszerekben. Egyértelmű, hogy néhány darabot kiveszünk onnan, és megpróbáljuk mikroszolgáltatásokká összesíteni, de a mag megmarad. Nehezen tudom most elképzelni, hogy az összes alaprendszert lecseréljük, és gyorsan áttérünk az új rendszerek másik, jó oldalára.
Támogatom, hogy minden, ami közelebb van az ügyfélhez és a fogyasztóhoz, ott van a legnagyobb üzleti haszon és érték, ahol az alkalmazkodóképesség és a gyorsaságra, a változásra, a „próbáld ki, mondd le, használd újra, csinálj mást” való összpontosítás. szükség” – ott fog megváltozni a táj. A dobozos termékek pedig nem nagyon illenek oda. Legalábbis mi nem látjuk. Ott a legkönnyebb, legegyszerűbb megoldásokra van szükség.
Ezt a fejlődést látjuk:
- alapvető információs rendszerek (többnyire back office);
- középső rétegek mikroszolgáltatások formájában összekötik a magot, összesítik, gyorsítótárat hoznak létre stb.;
- a frontvonali rendszerek a fogyasztót célozzák;
- olyan integrációs réteg, amely általában a piacterekbe, más rendszerekbe és ökoszisztémákba integrálódik. Ez a réteg a lehető legkönnyebb, egyszerű és minimális üzleti logikát tartalmaz.
Ugyanakkor támogatom, hogy továbbra is alkalmazzuk a régi elveket, ha azokat megfelelően alkalmazzák.
Tegyük fel, hogy van egy klasszikus vállalati rendszere. Egy szállító környezetében található, és két egymással együttműködő modulból áll. Van egy szabványos integrációs interfész is. Miért kell újra csinálni és mikroszolgáltatást vinni oda?
De ha a back office-ban van 5 modul, amelyekből az információk egy üzleti folyamatba gyűjtődnek, amit aztán 8-10 front-line rendszer használ fel, akkor az előny azonnal érezhető. Öt háttérirodai rendszerből hoz létre egy szolgáltatást, egy elszigeteltet, amely az üzleti folyamatra összpontosít. Tegye technológiailag fejlettebbé a szolgáltatást - hogy az információkat gyorsítótárazza, hibatűrő legyen, valamint dokumentumokkal vagy üzleti entitásokkal is működjön. És egyetlen elv szerint integrálhatja az összes élvonalbeli termékbe. Lemondták a front-line terméket – egyszerűen kikapcsolták az integrációt. Holnap írnod kell egy mobilalkalmazást, vagy készítened kell egy kis weboldalt, és csak egy részt kell a funkcionalitásba beillesztened – minden egyszerű: úgy szerelted össze, mint egy konstruktort. Ebben az irányban több fejlődést látok - legalábbis hazánkban.
Sándor:
Szergej teljesen leírta a megközelítésünket, köszönöm. Csak azt mondom, hova nem megyünk – a lényeghez, az online számlázás témájához. Vagyis a minősítés és a töltés valójában egy „nagy” cséplő marad, amely megbízhatóan írja le a pénzt. És ezt a rendszert továbbra is szabályozó hatóságaink tanúsítják. Minden más, ami az ügyfelek felé néz, természetesen mikroszolgáltatás.
Dmitrij:
Itt a tanúsítás egy történet. Valószínűleg több támogatás. Ha keveset költ támogatásra, vagy a rendszer nem igényel támogatást és módosítást, jobb, ha nem nyúl hozzá. Ésszerű kompromisszum.
Hogyan lehet megbízható mikroszolgáltatásokat fejleszteni
Dmitrij:
Bírság. De még mindig érdekel. Most egy sikertörténetet mesélsz: minden rendben volt, áttértünk a mikroszolgáltatásokra, megvédtük az ötletet az üzlettel, és minden sikerült. De hallottam más történeteket is.
Néhány éve egy svájci cég, amely két évet fektetett be egy új banki mikroszolgáltatási platform kifejlesztésébe, végül lezárta a projektet. Teljesen összeomlott. Sok millió svájci frankot költöttek el, végül a csapat szétoszlott - ez nem sikerült.
Volt már hasonló történetetek? Voltak-e nehézségek? Például a mikroszolgáltatások fenntartása és a monitorozás is fejfájást okoz a cég operatív tevékenységében. Végül is az alkatrészek száma tízszeresére nő. Hogyan látja, volt-e itt sikertelen befektetésre példa? És mit tud tanácsolni az embereknek, hogy ne ütközzenek ilyen problémákkal?
Sándor:
A sikertelen példák között szerepelt a prioritások megváltoztatása és a projektek lemondása. Amikor a felkészültség megfelelő szakaszában volt (sőt, az MVP készen áll), az üzlet azt mondta: „Új prioritásaink vannak, áttérünk egy másik projektre, ezt pedig lezárjuk.”
Nem volt globális kudarc a mikroszolgáltatásokkal kapcsolatban. Nyugodtan alszunk, 24 órás ügyeleti műszakunk van, amely a teljes BSS-t [üzlettámogatási rendszert] kiszolgálja.
És még valami - mikroszolgáltatásokat adunk bérbe a dobozos termékekre vonatkozó szabályok szerint. A siker kulcsa az, hogy először össze kell állítani egy csapatot, amely teljes mértékben felkészíti a mikroszolgáltatást a gyártásra. Maga a fejlettség feltételesen 40%. A többi az elemzés, a DevSecOps módszertan, a megfelelő integrációk és a megfelelő architektúra. Különös figyelmet fordítunk a biztonságos alkalmazások építésének elveire. Az információbiztonsági képviselők minden projektben részt vesznek mind az architektúra tervezési szakaszában, mind a megvalósítási folyamat során. Rendszereket is felügyelnek a kódok sebezhetőségeinek elemzésére.
Tegyük fel, hogy telepítjük a hontalan szolgáltatásainkat – a Kubernetesben vannak. Ez lehetővé teszi, hogy mindenki nyugodtan aludjon a szolgáltatások automatikus skálázása és automatikus emelése miatt, és az ügyeleti műszak felveszi az incidenseket.
Mikroszolgáltatásaink teljes fennállása alatt csak egy-két incidens jutott el a mi vonalunkra. Most már nincs probléma a működéssel. Természetesen nem 200, hanem körülbelül 50 mikroszolgáltatásunk van, de ezeket a zászlóshajóknál használják. Ha kudarcot vallanak, mi lennénk az elsők, akik értesülnénk róla.
Mikroszolgáltatások és HR
Szergej:
Egyetértek kollégámmal a támogatásra utalással kapcsolatban - abban, hogy a munkát helyesen kell megszervezni. De elmondom a problémákat, amelyek természetesen léteznek.
Először is a technológia új. Ez a jó értelemben vett hype, és egy olyan szakembert találni, aki ezt megérti és meg tudja alkotni, nagy kihívás. Őrült a verseny az erőforrásokért, így a szakértők aranyat érnek.
Másodszor, bizonyos tájak kialakításával és egyre több szolgáltatással folyamatosan megoldani kell az újrahasználat problémáját. Ahogy a fejlesztők szeretik: „Most írjunk ide sok érdekességet...” Emiatt a rendszer növekszik és veszít a hatékonyságából pénzben, fenntartási költségben stb. Vagyis az újrahasználatot be kell építeni a rendszerarchitektúrába, bele kell foglalni a szolgáltatások bevezetésének ütemtervébe és a hagyaték új architektúrába való átviteléhez.
Egy másik probléma - bár ez a maga módján jó - a belső verseny. – Ó, új divatos srácok jelentek meg itt, új nyelvet beszélnek. Az emberek persze mások. Van, aki Java nyelven szokott írni, van, aki Dockert és Kuberneteset ír és használ. Ezek teljesen más emberek, máshogy beszélnek, más kifejezéseket használnak, és néha nem értik egymást. A gyakorlat megosztásának, a tudásmegosztásnak a képessége vagy képtelensége ebben az értelemben is probléma.
Nos, az erőforrások bővítése. "Szuper, gyerünk! És most gyorsabban, többet akarunk. Mi van, nem tudsz? Nem lehet kétszer annyit szállítani egy év alatt? És miért?" Az ilyen növekvő fájdalmak valószínűleg sok mindenben, sokféle megközelítésben szokásosak, és érezni is lehet őket.
A megfigyeléssel kapcsolatban. Számomra úgy tűnik, hogy a szolgáltatások vagy az ipari felügyeleti eszközök már tanulnak vagy képesek együttműködni mind a Dockerrel, mind a Kubernetestel eltérő, nem szabványos módban. Azért, hogy például ne legyen 500 Java gép, ami alatt mindez fut, nevezetesen aggregál. De ezeknek a termékeknek még nincs érettsége; ezen kell keresztülmenniük. A téma valóban új, tovább fog fejlődni.
Dmitrij:
Igen, nagyon érdekes. És ez vonatkozik a HR-re is. Talán az Ön HR folyamata és HR-márkája változott egy kicsit ez alatt a 3 év alatt. Elkezdtél toborozni más, eltérő kompetenciákkal rendelkező embereket. És valószínűleg vannak előnyei és hátrányai is. Korábban a blokklánc és az adattudomány volt a hírverés, és ezekben a szakemberek milliókat értek. Most a költségek csökkennek, a piac telítődik, és hasonló tendencia figyelhető meg a mikroszolgáltatások terén is.
Szergej:
Igen, abszolút.
Sándor:
A HR felteszi a kérdést: „Hol van a rózsaszín unikornis a háttér és a frontend között?” A HR nem érti, mi az a mikroszolgáltatás. Elmondtuk nekik a titkot, és elmondtuk nekik, hogy a backend csinált mindent, és nincs egyszarvú. A HR azonban változik, gyorsan tanul, és olyan embereket toboroz, akik rendelkeznek alapvető informatikai ismeretekkel.
A mikroszolgáltatások fejlődése
Dmitrij:
Ha megnézzük a célarchitektúrát, a mikroszolgáltatások egy ilyen szörnyetegnek tűnnek. Az utazásod több évig tartott. Másoknak egy év, másoknak három évük van. Előre látta az összes problémát, a célarchitektúrát, változott valami? Például a mikroszolgáltatások esetében most újra megjelennek az átjárók és a szervizhálók. Használtad őket az elején, vagy magát az architektúrát változtattad meg? Vannak ilyen kihívásai?
Szergej:
Több kommunikációs protokollt is átírtunk már. Eleinte egy protokoll volt, most váltottunk másikra. Növeljük a biztonságot és a megbízhatóságot. Vállalati technológiákkal kezdtük – Oracle, Web Logic. Most eltávolodunk a technológiai vállalati termékektől a mikroszolgáltatásokban, és áttérünk a nyílt forráskódú vagy teljesen nyílt technológiákra. Elhagyjuk az adatbázisokat, és áttérünk arra, ami ebben a modellben számunkra hatékonyabb. Nincs többé szükségünk az Oracle technológiákra.
Egyszerűen szolgáltatásként kezdtük, nem gondolva arra, hogy mennyire szükségünk van a gyorsítótárra, mit fogunk tenni, ha nincs kapcsolat egy mikroszolgáltatással, de szükség van adatokra stb. Most egy platformot fejlesztünk, hogy leírható legyen az architektúra nem a szolgáltatások nyelvén, és az üzleti nyelven, vigye magasabb szintre az üzleti logikát, amikor elkezdünk szavakkal beszélni. Most megtanultunk betűkkel beszélni, és a következő szint az, amikor a szolgáltatásokat valamilyen aggregátumba gyűjtik, amikor ez már szó - például egy teljes termékkártya. Mikroszolgáltatásokból van összeállítva, de egy erre épülő API.
A biztonság nagyon fontos. Amint elkezd elérhetővé válni, és van egy olyan szolgáltatása, amelyen keresztül sok érdekességhez juthat, méghozzá nagyon gyorsan, a másodperc töredéke alatt, akkor megvan a vágy, hogy egy nem a legbiztonságosabb módon megszerezze azt. Ahhoz, hogy ezt elkerüljük, meg kellett változtatnunk a tesztelés és a monitorozás megközelítését. Változtatnunk kellett a csapaton, a kézbesítés-menedzsment struktúrán, a CI/CD-n.
Ez egy evolúció - mint a telefonoknál, csak sokkal gyorsabban: először a nyomógombos telefonok, majd az okostelefonok jelentek meg. Átírták és újratervezték a terméket, mert a piacnak más igénye volt. Így fejlődünk: első osztály, tizedik osztály, munka.
Iteratívan technológiai oldalról évre lefektetnek valamit, a lemaradás és igények felől mást. Egyik dolgot összekapcsolunk a másikkal. A csapat 20%-át technikai adósságra és technikai támogatásra költi, 80%-ot pedig az üzleti egységre. És úgy mozgunk, hogy megértjük, miért tesszük, miért tesszük ezeket a technológiai fejlesztéseket, és mihez vezetnek. Mint az.
Dmitrij:
Menő. Mi van a MegaFonban?
Sándor:
A mikroszolgáltatások kapcsán a fő kihívás az volt, hogy ne essünk káoszba. A MegaFon építészeti irodája azonnal csatlakozott hozzánk, sőt kezdeményező és hajtóerő is lett - most már nagyon erős építészetünk van. Feladata az volt, hogy megértse, milyen célmodellhez megyünk, és milyen technológiákat kell kipróbálni. Az építészettel mi magunk végeztük ezeket a kísérleteket.
A következő kérdés az volt: "Akkor hogyan lehet ezt az egészet kihasználni?" És még egy: „Hogyan biztosítható az átlátható interakció a mikroszolgáltatások között?” A szervizháló segített megválaszolni az utolsó kérdést. Kikísérleteztük az Istiót, és tetszettek az eredmények. Most a termelési zónák felé való terelés szakaszában vagyunk. Pozitívan állunk hozzá minden kihíváshoz - az a tény, hogy folyamatosan változtatnunk kell a veremben, tanulnunk kell valami újat. Mi a fejlesztésben vagyunk érdekeltek, nem pedig a régi megoldások kihasználásában.
Dmitrij:
Arany szavak! Az ilyen kihívások lábujjhegyen tartják a csapatot és az üzletet, és megteremtik a jövőt. A GDPR létrehozta a vezető adatvédelmi tiszteket, a jelenlegi kihívások pedig a mikroszolgáltatások és az építészeti tisztek vezetőit. És tetszik.
Sokat beszélgettünk. A lényeg az, hogy a mikroszolgáltatások jó tervezése és maga az architektúra lehetővé teszi számos hiba elkerülését. Természetesen a folyamat iteratív és evolúciós, de ez a jövő.
Köszönet minden résztvevőnek, köszönet Szergejnek és Sándornak!
Kérdések a közönségtől
A hallgatóság kérdése (1):
Szergej, hogyan változott meg az IT menedzsment a cégedben? Megértem, hogy ha több rendszerből álló nagy halom van, akkor annak kezelése meglehetősen világos és logikus folyamat. Hogyan építette újra az informatikai komponens kezelését, miután ilyen rövid idő alatt nagyon sok mikroszolgáltatást integráltak?
Szergej:
Egyetértek kollégámmal abban, hogy az építészet nagyon fontos a változás motorjaként. Azzal kezdtük, hogy létrehoztunk egy építészeti részleget. Az építészek egyben tulajdonosai a funkcionalitás elosztásának és a tájban való megjelenésre vonatkozó követelményeknek. Így ezeknek a változásoknak a koordinátoraiként is működnek. Ennek eredményeként egy adott szállítási folyamatban specifikus változások történtek, amikor létrehoztunk egy CI/CD platformot.
De a szabványt, a fejlesztés alapelveit, az üzleti elemzést, a tesztelést és a fejlesztést nem törölték. Csak növeltük a sebességet. Korábban a ciklus sok időt vett igénybe, a tesztkörnyezetekre történő telepítés sokkal többet. Most az üzleti élet látja ennek előnyeit, és azt mondja: „Miért nem tehetjük meg ugyanezt más helyeken is?”
Ez jó értelemben olyan, mint egy injekció oltóanyag formájában, amely megmutatta: meg tudod csinálni így, de lehet másképp is. Persze baj van a személyzettel, a kompetenciákkal, a tudással, az ellenállással.
A hallgatóság kérdése (2):
A mikroszolgáltatási architektúra kritikusai szerint a tesztelés és a fejlesztés nehéz. Ez logikus, ha a dolgok bonyolulttá válnak. Milyen kihívásokkal kellett szembenéznie a csapatának, és hogyan sikerült leküzdenie azokat? Kérdés mindenkinek.
Sándor:
Nehézségek adódnak a mikroszolgáltatásokról platformra való átálláskor, de ezek megoldhatók.
Például olyan terméket készítünk, amely 5-7 mikroszolgáltatásból áll. Integrációs teszteket kell biztosítanunk a teljes mikroszolgáltatási veremben, hogy zöld utat adjunk a fő ágra való átálláshoz. Ez a feladat nem volt újdonság számunkra: ezt már régóta csináltuk a BSS-nél, amikor a szállító már leszállított megoldásokat szállított nekünk.
A mi problémánk pedig csak a kis csapatban van. Egy feltételes termékhez egy minőségbiztosítási mérnök szükséges. Így 5-7 mikroszolgáltatásból álló terméket szállítunk, amelyből 2-3 harmadik fél által fejleszthető. Például van egy termékünk, amelynek fejlesztésében számlázási rendszer szállítónk, a Mail.ru Group és a MegaFon R&D vesz részt. Ezt tesztekkel kell lefednünk, mielőtt gyártásba szállítjuk. A minőségbiztosítási mérnök másfél hónapja dolgozik ezen a terméken, és a csapat többi tagja támogatása nélkül maradt.
Ezt a bonyolultságot csak a méretezés okozza. Tisztában vagyunk vele, hogy a mikroszolgáltatások nem létezhetnek légüres térben; abszolút elszigeteltség nem létezik. Egy szolgáltatás megváltoztatásakor mindig igyekszünk megőrizni az API szerződést. Ha valami változik a motorháztető alatt, marad az első szerviz. Ha végzetesek a változások, akkor valamiféle építészeti átalakulás történik, és egy teljesen más adatmetamodellre térünk át, ami teljesen inkompatibilis - csak akkor beszélünk a v2 service API specifikáció megjelenéséről. Az első és a második verziót egyszerre támogatjuk, és miután minden fogyasztó átvált a második verzióra, egyszerűen bezárjuk az elsőt.
Szergej:
hozzá szeretném tenni. Teljesen egyetértek a komplikációkban - előfordulnak. A táj egyre összetettebbé válik, és a rezsiköltségek nőnek, különösen a tesztelésnél. Hogyan kezeljük ezt: váltson automatizált tesztelésre. Igen, ezen felül be kell fektetnie az automatikus tesztek és az egységtesztek írásába. Annak érdekében, hogy a fejlesztők ne vállalhassanak kötelezettséget a teszt sikeres teljesítése nélkül, nem tudták megváltoztatni a kódot. Hogy még a nyomógomb se működjön autoteszt, egységteszt nélkül.
Fontos megőrizni a korábbi funkcionalitást, és ez többletköltséget jelent. Ha átír egy technológiát egy másik protokollra, akkor addig írja át, amíg mindent teljesen be nem zár.
Néha szándékosan nem végzünk teljes körű tesztelést, mert nem akarjuk leállítani a fejlesztést, bár nálunk is van egy-egy dolog. A táj nagyon nagy, összetett, sok rendszer van. Néha csak csonkok – igen, ha csökkenti a biztonsági ráhagyást, több kockázat jelenik meg. De ugyanakkor felszabadítod a készletet.
Sándor:
Igen, az automatikus tesztek és az egységtesztek lehetővé teszik a magas színvonalú szolgáltatás létrehozását. Egy olyan csővezetékért vagyunk, amelyen nem lehet átmenni egység- és integrációs tesztek nélkül. Az emulátorokat és a kereskedelmi rendszereket gyakran tesztzónákba és fejlesztői környezetekbe kell húznunk, mert nem minden rendszer helyezhető el tesztzónákba. Sőt, nem csak nedvesek – teljes értékű választ generálunk a rendszertől. Ez egy komoly része a mikroszolgáltatásokkal való munkavégzésnek, és mi is fektetünk ebbe. E nélkül káosz fog kialakulni.
A hallgatóság kérdése (3):
Ha jól értem, a mikroszolgáltatások kezdetben egy külön csapatból nőttek ki, és mára ebben a modellben léteznek. Mik az előnyei és hátrányai?
Nálunk is hasonló a történet: egyfajta mikroszolgáltatás-gyár jött létre. Most elvileg eljutottunk arra a pontra, hogy ezt a megközelítést kiterjesztjük a folyamok és rendszerek szerinti termelésre is. Vagyis távolodunk a mikroszolgáltatások, mikroszolgáltatási modellek központosított fejlesztésétől, és egyre közelebb kerülünk a rendszerekhez.
Ennek megfelelően a mi működésünk is rendszerekre megy, vagyis decentralizáljuk ezt a témát. Mi a megközelítésed és mi a céltörténeted?
Sándor:
Rögtön kiejtette a szájából a „mikroszolgáltatások gyára” nevet – mi is szeretnénk skálázni. Először is, most tényleg egy csapatunk van. Szeretnénk minden MegaFon fejlesztőcsapat számára lehetőséget biztosítani arra, hogy egy közös ökoszisztémában dolgozzanak. Nem akarjuk teljesen átvenni a mostani fejlesztési funkciókat. A lokális feladat a méretezés, a globális feladat a fejlesztés irányítása a mikroszolgáltatási réteg összes csapatához.
Szergej:
Elmondom, milyen utat jártunk be. Valójában egy csapatként kezdtünk dolgozni, de most már nem vagyunk egyedül. Én a következők híve vagyok: kell lennie a folyamatnak tulajdonosának. Valakinek meg kell értenie, kezelnie, irányítania és fel kell építenie a mikroszolgáltatások fejlesztési folyamatát. Erőforrásokkal kell rendelkeznie, és részt kell vennie az erőforrás-gazdálkodásban.
Ezek az erőforrások, akik ismerik a technológiákat, sajátosságokat és értik a mikroszolgáltatások kiépítését, termékcsapatokban helyezkedhetnek el. Van egy keverékünk, ahol a mikroszolgáltatási platform emberei a mobilalkalmazást készítő termékcsapatban vannak. Ott vannak, de a mikroszolgáltatási platformkezelési részleg folyamata szerint dolgoznak a fejlesztési vezetőjükkel. Ezen a részlegen belül van egy külön csapat, amely a technológiával foglalkozik. Vagyis egy közös erőforráskészletet keverünk egymás között, és felosztjuk, csapatoknak adjuk.
Ugyanakkor a folyamat általános marad, ellenőrzött, általános technológiai elvek szerint halad, egységteszttel és így tovább - minden, ami a tetejére épül. Lehetnek oszlopok a termékmegközelítés különböző részlegeitől gyűjtött erőforrások formájában.
Sándor:
Szergej, valójában te vagy a folyamat tulajdonosa, igaz? Meg van osztva a feladathátralék? Ki a felelős a terjesztéséért?
Szergej:
Nézd: itt a mix megint. Van egy lemaradás, amely technológiai fejlesztések alapján alakul ki – ez egy történet. Van lemaradás, ami projektekből, és termékekből van lemaradás. De az egyes szolgáltatási termékek bevezetésének vagy a szolgáltatás létrehozásának sorrendjét termékspecialista dolgozza ki. Nem az informatikai igazgatóságon van, külön eltávolították onnan. De az én embereim határozottan ugyanazon eljárás szerint dolgoznak.
A különböző irányú lemaradás - a változások lemaradása - tulajdonosa különböző emberek lesznek. A technológiai szolgáltatások összekapcsolása, szervezőelve - mindez az informatikában lesz. Az én tulajdonomban van a platform és az erőforrások is. A tetején a lemaradás és a funkcionális változások, illetve az ilyen értelemben vett architektúra áll.
Tegyük fel, hogy egy vállalkozás azt mondja: „Szeretnénk ezt a funkciót, új terméket akarunk létrehozni – kölcsönt újra.” Azt válaszoljuk: "Igen, újra fogjuk csinálni." Az építészek azt mondják: „Gondoljuk meg: a hitelben hol írunk mikroszolgáltatásokat, és hogyan fogjuk csinálni?” Ezután projektekre, termékekre vagy technológiai halomra bontjuk, csapatokba tesszük és megvalósítjuk. Létrehozott egy terméket belsőleg, és úgy döntött, hogy mikroszolgáltatásokat használ ebben a termékben? Azt mondjuk: „Most a régi rendszereinknek, vagy a frontvonali rendszereinknek át kell állniuk ezekre a mikroszolgáltatásokra.” Az építészek azt mondják: „Tehát: az élvonalbeli termékeken belüli technológiai lemaradásban - átállás a mikroszolgáltatásokra. Megy". A termékspecialisták vagy a cégtulajdonosok pedig megértik, hogy mekkora kapacitás van lefoglalva, mikor és miért.
A vita vége, de nem minden
Megszervezték a mailto:CLOUD konferenciát .
Más rendezvényeket is lebonyolítunk - pl. @Kubernetes Meetup, ahol mindig nagyszerű hangszórókat keresünk:
- Kövesse @Kubernetes és más @Meetup híreinket Telegram csatornánkon
- Szeretne felszólalni az egyik @Meetups-on? Hagyjon igényt
Forrás: will.com