„Tehnoloogiate loomine, mõtlemata sellele, kes neid kasutab, on täiesti mõttetu“: suur intervjuu Anton Weissiga

See post on Habr — an interview with Anton Weiss, co-owner of the technology consulting firm Otomato Software, who has over 15 years of experience in high technology. He is an expert in technical instruction, initiator and co-author of Israel's first DevOps certification course. Anton participates in international conferences and is known as an excellent speaker.

We'll discuss the following topics:

• Differences in work between Russia and Israel;
• Differences between startups and giants, especially in DevOps;
• The trend towards increasing complexity, and how to deal with it;
• Combining technical and non-technical skills;
• Rapid learning and adaptation to work;
• The most useful practices and technologies from the world of DevOps;
• Which talks are worth attending.

The difference between Russia and Israel

Oleg: Please tell me who you are and what you do.

Anton: Mina olen Anton, sündinud Peterburis, kuid kolisin 15-aastaselt Iisraeli ja olen sellest ajast seal elanud. Viimased kakskümmend aastat olen Iisraelis tegelenud IT-ga erinevates vormides. Nendest kahekümnest aastast olen viimased kümme spetsialiseerunud kõikidele tarkvaratoimetamisega seotud tegevustele: integreerimist, seda, mida varem nimetati konfiguratsioonihalduseks, ja seda, mida nüüd nimetatakse DevOps-iks. Olen töötanud suurtes ettevõtetes — rahvusvahelistes korporatsioonides nagu AT&T, BMC. Olen töötanud ka idufirmades. Viimased neli aastat omangi oma konsultatsioonifirmat, nimega Otomato Software, kus aitame organisatsioonidel optimeerida protsesse ja tutvuda uute tööriistadega: seega tegeleme nii tehnilise poole kui ka kõik muu ümberringi.

Oleg: Kas töö puhul on Venemaa ja Iisraeli vahel erinevusi?

Anton: Venemaa klientidega ma peaaegu ei töötanud. Kõik, mis mind Venemaaga kolme aasta jooksul sidunud on, on konverentsid. Ja mõnes Venemaa ettevõttes tegime midagi sarnast auditi põhimõttel: tulime, vaatasime, selgitasime, välja töötasime mõned soovitused ja lahkusime. See tähendab, et igapäevast tööd praktiliselt polnud, seega on mul raske täpselt öelda, millega see erineb. Arvan, et igal pool on midagi. Näiteks on Iisraelis meil selliseid suuri organisatsioone, kus inimesed on juba 15 aastat tööl, ja kõik liigub väga aeglaselt. Kuigi nad püüavad seal teha mingit transformatsiooni, parandada protsesse: nad räägivad, räägivad, aga... Meil on üks klient, kellega kaks aastat tagasi panime kõik paika ja tegime kõikid otsused, töötasime välja kõik programmid, ja mingil hetkel see kõik seiskus, me lahkusime sealt. Just paar päeva tagasi kohtusin sealsete juhtidega, kellega töötasime, ja küsin:

— Kuidas läheb?

— Noh, nii. Raske, — ütlevad, — teeme, praegu hakkab midagi toimuma.

Kaks aastat hiljem. On poliitika, on mõjupiirkonnad. On inimesi, kes ei soovi neid mõjupiirkondi vabastada, seetõttu on sellises olukorras väga keeruline midagi muuta. Samas, tööriistade valik liigub kuidagi edasi. Teisest küljest, Iisraelis on idufirmad, kus kõik muutub väga kiiresti, uue tööriistade loomine on lihtne, ja nad on kõik juba pilvepõhised ja täielikult pilves. See, muide, võib olla üks silmapaistvamaid erinevusi Venemaa ja Iisraeli vahel. Iisraelis on avaliku pilvega palju lihtsam. Sellest, mida ma olen näinud. Venemaal, näiteks, tundub, et kõik, peale idufirmade, leiavad avaliku pilvega liiklemise väga keeruliseks, kuid Iisraelis on see siiski kergem. Tänaseks on juba olemas mingi arusaam isegi pankade ja kindlustusseltside seas, et vähemalt osa oma asju saab viia avalikku pilve. Ja siin ei karda kedagi lepingud Google'i ja Amazoni ees. Sellest, mida ma olen kuulnud Venemaa konverentsidel, on seal siiski see kõik veel keerulisem, isegi just sanktsioonide ja mingite õigusküsimuste osas.

Erinevus idufirmade ja hiiglaste vahel

Oleg: Mõistsin. Muide, kus on sul töötada huvitavam ja meeldivam: idufirmades või suurtes organisatsioonides?

Anton: Muidugi on meeldivam idufirmades, sest suurtes organisatsioonides... no, tõeliselt on tõesti raske midagi edasi viia. Loomulikult on neil omad eelised. Kui vaadata suuri organisatsioone, siis neil on näiteks tuntavasti rohkem seda, mida nimetatakse mitmekesisuseks. Suured ettevõtted, kuna neile on vaja palju inimesi või kuna tegemist on mingi organisatsioonikultuuriga, mis on aastaid kujunenud, on valmis palkama erinevaid inimesi. Siin Iisraelis, näiteks idufirmades, ei leia sa peaaegu kunagi araabe, neid on peaaegu mitte. Suurtes organisatsioonides on see palju lihtsam. Kuid idufirmad kasvavad enamasti mingist kultuurilisest taustast, kus enamik osalejatest on neid nn valgeid mehi. Seal on kultuur, et tuleb korralikult pingutada ja soovitatavalt töötada 10–12 tundi päevas, ja seda on ka vähe. Tundub, et meie selja taga on Moskva (ehk siis Tel-Aviv), taganeda ei ole kuhugi, ja seepärast peame siin ja praegu verega pingutama.

Oleg: Kuidas on lähenemine DevOpsile erinev väikestes ja suurtes ettevõtetes? Kui näiteks oled kahest inimesest koosnev meeskond, võid sa CI/CD-d mitte seadistada ja artefakte kopeerida SCP kaudu.

Anton: Ühelt poolt jah. Kuid teiselt poolt, CI/CD seadistamine ei tähenda automaatset continuous delivery-d. Siiski on kahe inimesega ettevõttes mõne pipeline'i seadistamine väga lihtne. Kui varem pidi selle kallal vaeva nägema, siis täna on sul palju pilveteenuseid. Kirjutasid YAML-i — ja edasi! Asjad on lihtsamad. Tegelikult esindavad väljakutsuvaid olukordi kasvavad idufirmad. Need, kes on ületanud 20 inimese piiri, ja siis hakkavad nad kogema muresid skaleerimisega, sest protsessid puuduvad. Varem töötas kõik kuidagi, aga siis algab see segadus ja ei ole selge, kuidas säilitada endist dünaamilisust ja samal ajal juhtida protsesse ning otsustada, kes hakkab sellega tegelema.

Ja siis hakkavad kõik asjad, nagu "meil on DevOps meeskond, mis vastutab DevOps'i eest," me teame, kuhu see enamasti viib. Tekib pudelikael ja järk-järgult kasvavad nad suurematesse firmadesse. Suurtes ettevõtetes on hoopis teine probleem, neil on juba mitte lihtsalt pudelikael, vaid tohutu värav, mis avatakse korra päevas, ja kogu ülejäänud aeg koguneb sinna suur hulk prahti. Ja nad mõtlevad: "Kuidas meil nüüd sellest väravast teha palju väikseid väravaid, mida oleks palju lihtsam avada?" Teisisõnu, täiesti erinevad probleemid. Startupide probleem on see, et "meid imetakse sisse funnelisse, kuidas me pinnale pääseme?" aga suurtes ettevõtetes — nad on juba funnelis, nad on juba allilmades, nüüd mõtlevad nad, kuidas sealt tagasi üles pääseda.

Kompleksuse kasvutrend ja kuidas sellega toime tulla

Oleg: Lisaks tehnilisele poolele: kui sul on vähe inimesi, lihtsad tehnoloogiad, pead sa teadma mingit põhilist Linuxit ja kõik. Aga minimaalsete skaleeringute juures pead sa õppima mingit Kubernetes't ja see tundub probleemina.

Anton: Ja see on kindlasti probleem. Meil oli konverents just kaks päeva tagasi ja oli väga selgelt tunda, et peaaegu kõik, kes seal midagi rääkisid, mainisid ühte sõna: "kompleksus". See on tänapäeval tõeliselt määrav sõna kogu DevOps diskursuses.

Oleg: Kuidas oli aga aasta tagasi?

Anton: Püüdes kõike kiiresti ja dünaamiliselt teha, et saavutada kurikuulus paindlikkus, oleme endale keerukust juurde lisanud. Tõeliselt palju väikeseid torustikke, mis eraldi töötavad suurepäraselt, aga siis püüame neist kokku panna mingit ühte maailmapilti ja seal see keerukus tegelikult tekib. Sest me ehitame nüüd kõigist nendest väikestest torustikest ühe protsessi, et kogu ettevõte töötaks tõeliselt hästi.

Oleg: Ja mis on vastus? Kuidas selle keerukusega toime tulla?

Anton: Aga vastuseid pole, need tekivad protsessi käigus. Minu ettekanne käsitles just ühe sellise lahenduse teemat. Suures osas, kuhu see kõik viib? Ma olin kunagi nakatunud süsteemse mõtlemisega, DevOps'is mainitakse seda palju. Hakkasin sellest huvituma, lugesin Peter Senge, Russell Ackoffi, Donella Meadowsi raamatuid — inimesi, kes tõid süsteemse mõtlemise teema päevakorrale ja esitasid selle põhipostulaadid. Üks peamisi prisme, läbi mille süsteemne mõtlemine maailma vaatab, on tagasiside silmused. Selle keerukusega seoses tekivad nüüd need tagasiside silmused, st keerukus muutub väga ja väga kõrgeks, ja me hakkame otsima tööriistu, et seda keerukust vähemalt natukene ohjata. Ma ei räägi vähendamisest — pigem ohjeldamisest, et see meid ei paiskaks.

Keskne lahendused tulevad esile, tead, isegi Kubernetes on midagi sellist. Sul on keskne juhtimispink, mis, kui sa seda haldad, kontrollib kogu keerukust nende teenuste ümber, mis töötavad. Teenusemoos, see sama service mesh, on sama tüüpi lahendus. Me räägime: "Meil on hunnik teenuseid, vaja on, et nad saaksid omavahel suhelda, kuna nad istuvad arusaamatutes kohtades ja pole üldse kindel, kas nad saavad vastuseid või mitte, ja nad ise ei saa hakkama. Seega teeme nii, et keskmisse lisame mingi universaalse intelligentsi, mis ütleb neile, kellega saab rääkida, kellega ei saa rääkida, ja kaitseb neid, kui keegi juhuslikult vastab neile ebaviisakalt." Ja sellega on palju küsimusi. Ühelt poolt on see mingisugune vajadus, kuna organisatsioonid ei suuda hakkama saada. Oleme viimase paariga aastal aidanud mitmeid organisatsioone astuda uude julgesse Cloud Native maailma, eriti kui see on seotud ettevõtte kasvamise ja laiendamisega, ning inimesed lihtsalt kaotavad suuna. Kõigi nende keskel asub väike meeskond nn DevOps'e, kellel tuleb kirjutada tuhandeid ridu YAML-i, et kuidagi selle kõigega toime tulla, ja kõik lihtsalt praguneb liistude alt.

Cloud Native

Oleg: Kas sa saaksid veidi selgitada, mis on Cloud Native? See on muutunud mingiks buzzwordiks, praegu kirjutatakse seda igale seinale. Kuidas sina seda näed?

Anton: Põhimõtteliselt algas kõik sellest, et hakkasime kasutama „platvormina teenust“ lähenemist, see tähendab, et meil tuli käivitada palju rohkem tarkvara ja palju rohkem veebiteenuseid, kui kunagi varem. Me mõistsime, et ei saa enam iga teenust eraldi kohelda kui meie lemmikloomade, kelle nime me teame ja kelle eest me elu jooksul hoolitseme – meil tuleb nendega tegeleda nagu mingisuguse karja, mitte individuaalselt. Selle jaoks vajame ühtset platvormi, kuhu saame selle koodi paigutada, ja platvorm peab olema piisavalt intelligentne, et seda hallata. Lihtsalt öeldes, see on automaatne jootmine, automaatne jootmine ja söötmine teenuste jaoks.

Selle lähenemise pioneerid olid Heroku. Nad ütlesid, et et need teenused saaksid meie infrastruktuuride kasutamiseks, peavad nad olema ka 'lehma'. See tähendab, et neil peavad olema teatud omadused. Nii sündis 12-faktori rakendus, mis peaks omama võimalikult vähe püsivat olekut. Selline rakendus peab olema kokku pandud mingi konveieri abil, kus kontrollitakse selle ühilduvust platvormiga. See peab olema vastupidav — teadma, et kui miski läheb valesti, ei pea kohe kukkuma. Teiselt poolt, mingil moel toetuma platvormile. Ühesõnaga, mingi hübriid. Pead mõistma, et sa ei ole üksi, et on platvorm ja tuleb austada selle piiranguid. Suures plaanis algas kõik sealt.

Kuid mingil põhjusel ei õigustanud see lähenemine "platvorm teenusena" ennast ja lubatud buumi ei toimunud. Jah, Heroku oli, seejärel järgnesid kohe kõik suured tegijad, kes tõid välja analooge: Google App Engine, Amazonil — Elastic Beanstalk. Olen palju töötanud ettevõtetega, mis alustasid selle lähenemisega. Kuid hetkel, kui teed midagi, mis veidi ületab platvormi lubatud piire, muutub see kohutavaks peavaluks. Sest hakkad kokku põrkama seintega, mis on igal pool. Ja nagu inimestele omane, kui nad kokku põrkavad seintega, hakkavad nad otsima viisi, kuidas seina läbi lõhkuda.

Kaasaegne Cloud Native on sellest sündinud: kuidas jätkuvalt pilves joosta, kasutada erinevaid platvormi teenuseid ja samas tagada hämmastav paindlikkus kõiges, mis toimub. Me pidevalt tasakaalustame paindlikkuse ja lihtsuse vahel. Paindlikkus toob endaga kaasa keerukuse, samas kui lihtsustamine ja selge platvormi loomine toovad alati kaasa piiranguid. Cloud Native on ilmselt tasakaalu leidmine pilve platvormi piirangute ja paindlikkuse vahel, mida pakub pilv automaatse skaleerimisega, ning sellel kõigel on hind.

Oleg: Tõenäoliselt peab organisatsioon ise kuidagi õppima kõik selle protsessiga elama.

Anton: Loomulikult! Kõik see mõjutab meid. Mikroteenused kuuluvad samuti siia. Põhimõtteliselt tähendab see, et meil on väikesed teenused ja rakendused, mis on hajutatud üle pilve ja võivad olla igal ajal kus iganes, ning neid võib olla täna 10 koopiat ja homme 1500. See on osa Cloud Native'ist. Me ei ole piiratud andmekeskuse füüsiliste piiretega. Põhimõtteliselt on kogu maailm minu pilv — see on täiesti uimastav nägemus, suurepärane ambitsioon, kuid sellel on hind, ja see hind on keerukus. See hind on see, et põhimõtteliselt ei suuda keegi mõista, mis juhtub, kui meie rakendus kasvab äkki 10 instantsilt 1500-le. Keegi ei suuda seda ette kujutada ning hakkavad ilmnema kõik skaleerituse artefaktid. Me ei saa, kui inimesed ja operaatorid, selle jaoks midagi teha, välja arvatud reageerida toimuvasse kaosesse. Nii hakkame mõtlema: "Kuidas ehitada oma rakendust ja infrastruktuuri nii, et kui need artefaktid ilmnevad, saaks neid kõigepealt ette näha ja teiseks nendega kuidagi hakkama saada, et jätkata funktsioneerimist?"

Tehniliste ja mitte-tehniliste oskuste ühendamine

Oleg: Kas sul on ettekandeid tehniliste asjade kohta, näiteks, teeninduse kvaliteedi kohta ja on ettekandeid juhtimise ja kõikide muu kohta. Kas sa oled rohkem tehnilise suunitlusega inimene, või juhid, või on sul see kuidagi teisiti?

Anton: Ma isegi hakkasin mingil hetkel kirjutama postitust sellest, aga pole veel lõpetanud. Mingil määral tunnen ma end isiklikult rebituna nende kahe asja vahel, sest ühtepidi meeldib mulle mõista, kuidas asjad toimivad, ja meeldib nendega tegeleda. Kui õnnestub lahendada mõni tehniline probleem, annab see lihtsalt sellise erakordse rahulduse, mis toob kaasa dopamiini tõusu: "Oh, lahe, ma saan, ma lahendasin". Ja on raske sellest loobuda, see on raske jätta. Ja kuna see on olemas, jätkan ma tehniliste asjadega tegelemist. Uued tehnoloogiad sütitavad mind: on äge midagi avastada, midagi aru saada. Seega juhtub, et kuna need teadmised on olemas, soovivad inimesed neid osta, ja ma jätkan nende müümist.

Teisena, ma mõistan, et see on lihtsalt väike osa suurest pildist; olen piisavalt kaua töötanud tööstuses ja ei saa mitte näha, et tehnoloogia on lihtsalt osa suurest süsteemist, üks komponente. Olen juhtinud meeskondi ja tean, kui oluline on arvestada tehnoloogia ja tööriistade seost nendega, kes neid kasutavad. Lõppude lõpuks eksisteerivad infotehnoloogia ja tegelikult iga tehnoloogia selleks, et neid kasutaksid inimesed. Tehnoloogia loomine ilma mõtlemapanemata sellele, kes seda kasutab, on täiesti mõttetu. Tehnoloogia iseenesest ei ole huvitav, kui ei mõelda selle rakendusele, ja rakendus on alati seotud inimestega, kes sellest mingil moel kasu saavad. Seepärast huvitab mind kõik, mis seondub tehnoloogiaga. Tunnen, et sellest tuleb rääkida; ma mõistan, et ilma selleta kaotavad asjad tõeliselt tähenduse. Kuni selleni, et mõnikord on mul hea meel lihtsalt istuda ja paar päeva või isegi nädalat millegi kallal näppida. Võin kiinduda mingisse probleemisse, mida ma ei suuda lahendada, ja kui leian lahenduse, tunnen tohutut rahuldust. Kuid siis tõstan pea klaviatuurilt, vaatan ringi ja mõistan, et kõikjal toimub midagi, mida ma ei saa ignoreerida. Siis muutuvad kood ja Linuxis nokitsemine täiesti ebahuvitavaks, ebaoluliseks, ja tahan hakata probleeme lahendama teisel tasemel, inimtasemel.

Kuidas DevOpsis kiiresti selgeks saada

Oleg: Kuule, kas saad soovitada midagi neile, kes tegelevad inseneritöö ja DevOpsi praktikate õppimisega samal ajal? Kuidas kõik see endasse mahutada ja millises järjekorras? Ütleme nii, kuidas oma karjääri plaanida, et lühikese ajaga edukamaks saada?

Anton: Ahh… Well, there are no universal tips, again from my experience. For quite a long time, probably the first ten years of my career, I was dissatisfied with my position. I focused on what I didn’t like, searching for it, thinking about what I would find more interesting to do. But in the end, I did nothing about it. The main advice is… When do I think my career took off? It was when I started talking about things that genuinely interested me. The field of technical knowledge, not just technical, the entire sphere of information technology is very broad; you can be a technician: a developer, a tester, an integrator, a system administrator — all these are different roles, and everyone can find their niche there. Don’t want to be a complete techie but are interested in both technical and business aspects? Engage in product management or project management. There are plenty of niches, find one that intrigues you.

Praegu räägitakse palju "T"-kujulistest professionaalidest. Tuleb mõista, kus on sinu T jalga, valida üks, alustada süvenemist sellesse kohta. Kaevates avastad hämmastavad sügavused. Kuid kaevata võib igal pool. Olen täiesti teadlik, et on palju alasid, kuhu ma sügavale ei kaevanud, kuna proovisin vaadata ja sain aru, et see pole minu jaoks. Aga seal, kus sind huvitab kaevamine — kaevake edasi, ja siin on väga oluline sellest rääkida. Ehk jälle, ma mõistan, et see pole kõigile. Kuid ka siin on kõigil erinevad väljendusvõimalused: kellelegi sobib võib-olla blogide kirjutamine, kui sa ei oska kirjutada ilusaid ja lõbusaid blogisid — kirjuta lihtsalt tehnilisi blogisid, avalda Gisti GitHubis. Kui lahendasid mingi probleemi — avalda.

Üldiselt toimub täna karjääriline areng peamiselt teadmiste jagamise kaudu. Pole ime, et DevOps-is on teadmiste vahetamine selline oluline väärtus. Kõik, kes selles osalevad, saavad sellest kasu, ja sina ise saad samuti alati kasu, kui jagad oma teadmisi. Igaüks, kes on avatud lähtekoodiga oma koodi jaganud, teab hästi, kui oluline on koodi korrigeerida ja kui erinevalt tuleb mõelda, kui annad selle kellelegi teisele, ning mõistad, et keegi teine kasutab seda. Siia mängu astuvad need sotsiaaltehnilised aspektid, millest ma rääkisin. Sa hakkad mõtlema, et see pole lihtsalt kood, vaid kood, mida teine inimene loeb, võib-olla tahab ta seda muuta, ja tal tuleb mõista, mida see kood teeb. Ja kui need suhted tekivad, hakkad juba oma peas teisi inimesi kaasama. Inimese karjäär areneb vaid teistega suhtlemise kaudu. Üldiselt, mis on karjäär? Karjäär tähendab, et muutun kasulikuks suuremale hulgale inimestele, olen kasulik ja vajalik. Sa teenid teadmisi, mis on suuremale hulgale inimestele vajalikud ja kasulikud. Selleks tuleb mõista, mida need inimesed tahavad ja mida nad vajavad. Nii lihtsalt ongi. Kõik asjad viivad alati inimeseni.

Oleg: Kujutage ette, et me oleme toredad ja tegeleme DevOpsiga, erinevate uute praktikatega ja muu sellisega. Kuid on inimesi, kes tunnevad ja austavad seda, ja on neid, kes ütlevad, et ei tunne. Kujutage ette, et töötate suures ettevõttes, kus sellest seni… ütleme ettevaatlikult, ei teata väga palju ja ei austata ka. Kas on mingeid võimalusi, kuidas hakata neid ideid ellu viima? Kui te pole juht. On selge, et kui olete juht, võite lihtsalt öelda: „Hakkame rakendama homme“. Aga mis saab siis, kui te olete tavaline inimene ja soovite paremaks muutuda?

Anton: Esiteks ei ole see tingimata efektiivne, kui ütlete nagu juht: „Hakkame rakendama homme“. Inimesed hakkavad võib-olla midagi tegema, kuid see ei tähenda, et teadlikkus selle kohta, miks see rakendatakse, tekib iseenesest. Ja ükskõik millised muudatused ei meeldi kellelegi, eriti kui neile öeldakse: „Sa pead muutuma“.

Oleg: Ja mida siis teha?

Anton: Kujuta nüüd, ma olen selles kohas olnud ja tegelenud selliste protsesside rakendamisega, tegelikult alustades allpool, olles lihtsalt meeskonna liige, ja seejärel, olles juba tiimijuht. Ainus lähenemine, mis toimib, on narkokaubanduse lähenemine. See on see, mida ma nimetan "teenustele orienteeritud koostööks", see tähendab teadlikkusele põhinevat koostööd, et mõista, mida sa pakud. Suuremas plaanis tead, et sul on sinu ümber inimesi, keda võid pidada oma klientideks. Me teeme midagi, keegi teine kasutab sellest kasu. Kõige lihtsamas stsenaariumis, millest Agile kunagi rääkis: ma olen arendaja, mul on klient, ja seetõttu pean ma aru saama, mida mu klient tahab, et efektiivselt tarkvara arendada.

Suures ettevõttes on mul sageli puudulik otsene suhtlemine kliendiga, kasutajaga. Kuid minu ümber on teised inimesed. Näiteks, kui ma kirjutan teegi — teised inimesed integreerivad seda, kui ma arendan mingit tagaplaati — mul on eesliini arendajad, kes peavad selle kallal töötama, ja kui ma kirjutan koodi — mul on testijad, kes kas kirjutavad mulle teste või ma jagan neile versioone, et neil oleks mida testida. Suures plaanis tuleks mõelda, et "ma olen teenusepakkuja, kellest on kliendid. Kõige paremini töötab kõik, kui ma teen oma kliendid rahulolevaks. Kui mu kliendid on rahul, siis olen ka mina rahul. Ma teen endale esmalt nime, teen head suhtlemist ja saan positiivset tagasisidet." Ja tagasivaatavalt narkodiileri lähenemisele, ma tahan, et need kliendid tuleksid jälle minu juurde, et saada sama asja.

See, if I believe a certain approach is correct, for example, continuous integration with tests… There are programmers who find it difficult to test their work today. We need to ensure they don’t have to think too much about it, making these checks as simple as possible for them. Today, this seems quite trivial, but it wasn’t trivial at all ten years ago: at that time, when I pushed my code, everything would automatically build and deploy somewhere, and I would only receive a message if there was an error. Meanwhile, I could peacefully go have a coffee without worrying about compiling on my own computer or having all the necessary tools because that's also a headache. So, by reducing the amount of headache, people get hooked on it. We all see this: as soon as you have a well-functioning pipeline, those who use it quickly can’t imagine life without it. If I want to make a change, a process needs to be created that fosters a certain emotional dependence among people.

Oleg: Hästi. Paljud inimesed lootavad, et tuleb mingi kuningas, suur juht või keegi, kes ütleb neile, kuidas elada, ja pärast seda liiguvad kõik kindlasti uude julgusse maailma DevOpsiga või millegagi muuga. Kas selline kuningas on vajalik?

Anton: Ei, kuningas, kes ütleb, kuidas elada, ei ole kindlasti vajalik. Juht, kes on valmis kuulama oma töötajaid, neile usaldama ja toetama neid nii, et nad saaksid oma tööd teha nõnda, nagu neile tundub kõige mugavam ja õigem? Jah, selline inimene on vajalik, sest vastasel juhul on see lihtsalt konflikt. Ja vaenulikkus alluvate ja nende ülemuse vahel ei lõppe kunagi hästi. Tulemuseks on, et kellelegi läheb see kindlasti halvasti, kas ülemusele või alluvatele.

Kuid probleem on selles, et inimestele on väga raske rääkida, mida nad peaksid tegema ja mida nad ei peaks tegema. Lõppkokkuvõttes teevad nad seda, kuhu neid viib nende kultuuriline taust, ego või hetkeemotsionaalne seisund.

Kõige kasulikumaid praktikaid ja tehnoloogiaid DevOpsi maailmast.

Oleg: Tegelikult on praegu jutuks palju erinevaid praktikaid: on lähenemisviise Google'ilt, Netflixilt ja erinevatelt konverentside esinejatelt. Milliseid praktikaid pead sina kõige kasulikumateks?

Anton: Enamikul organisatsioonidest, sõltumata sellest, kas nad on suured või väikesed (eriti kannatavad selle all start-up'id), on probleemiks see, et neil puudub protsesside jälgimine — arusaam sellest, kuidas me tegelikult töötame, kuidas me tarkvara tarnime ja kus asjad umbe jäävad. Tavaliselt pakun välja harjutuse, mis tuleneb efektiivse juhtimise lähenemisest, lean management'ist — see nimetatakse väärtuse voogude kaardistamiseks. See nõuab teatavat valmisolekut, et koguda ühte ruumi organisatsiooni peamised mängijad, kõik, kes mingil moel osalevad tarnimisprotsessis: need, kes määratlevad vajalikud muudatused, tooted, projektijuhid, arendajad, testijad, süsteemiadministraatorid, isegi müüjad, kes töötavad klientidega. Koguda nad kõik kokku ja mõista, kuidas tarkvara muutus toimub, millist teed see tavaliselt läbib.

See, it seems quite trivial: what's going on? Someone has devised it — someone has coded it, we have a pipeline, it ran — it was rolled out. Yes, we know that our build takes a lot of time, yes, we will resolve that. We know that programmers cannot compile on their machines right now because they have Java, it requires a lot of memory, we know that too, and we'll sort it out. And I often visit organizations, and they say:

— We need to automate this, address that.
— Are you sure this is where we should start? How do you know this?
— Well, we don't know for sure, but we feel that there's a problem there.

On the theory of constraints by Goldratt, which states that addressing an issue anywhere that isn't a constraint does not solve anything; it only complicates the problem. What many people lack is an understanding of where things get stuck and how they flow.

Sometimes you just gather different people, and one person says:
— At this point, the release is going for approval.

And another says:
— No, it's not like that for us; we are not moving forward. Here we are waiting for the environment for load testing.

Või näiteks, testijad ütlevad:
— Just siin me tavaliselt teeme kõik käsitsi.

Ja programmeerijad ütlevad neile:
— Aga meil on selle jaoks automatiseeritud protsess. Miks te seda ei kasuta?

Ja testijad ütlevad:
— Me ei teadnud, et see olemas on.

Iga meeskond näeb ainult oma osa ja keegi ei näe kogu pilti — see mõjutab tihti meie võimet tõhusalt tarkvara välja anda palju rohkem kui tööriista olemasolu või puudumine. Selliseid asju. Tuleb alustada protsesside kaardistamisest. Selge, et kui ettevõttes ei ole hetkel mingit CI/CD — see on juba minevik. Selge, et seda tuleb ka luua. Aga tasub kõigepealt vastata küsimusele, kui palju sellesse investeerida, milliseid probleeme see lahendab. Selleks on samuti vaja inimesi, kes mõistavad, kuidas seda õigesti teha.

Oleg: Tehnilisest vaatenurgast, millistele tehnoloogiatele tasub tähelepanu pöörata? Selge, et lihtsast CI/CD-st ei tasu enam rääkida. Millised ägedad uued tehnoloogiad võiksid huvi pakkuda?

Anton: Esiteks, on kõigile täiesti selge, et konteinerid on võitnud. Seetõttu, kui keegi veel konteineritega ei tegele, peaks kindlasti vaatama ja seda võimalikult kiiresti tegema, sest suund on sellele poole. Suured ettevõtted mõistavad, et nende tarkvara täiendamine konteineritesse on hädavajalik. Ja platvormide tasemel on Kubernetes võitnud: pole vahet, kas see on pilves või mitte — me viime klientidele Kubernetes'iga lahenduse. Nüüd on ka VMware teada andnud, et neil tuleb Kubernetes otse hüperviisoril. Kõik on selge, Google on võitnud. Mis ei ole kellelegi üllatus.

Oleg: Google on võitnud?

Anton: Kuid kui me vaatame paar aastat tagasi, ei olnud veel selge, kas valida Swarm või Kubernetes, ja kas Docker tapetakse. Dockerit tapeti, see on täiesti selge. Kõik liitusid, ka Microsoft ja Amazon aitasid — "tule, tapame Dockerit koos!" Nad tapsid Dockeri! Aga suures plaanis oli Docker ise süüdi. Nad lootsid, et tulevad, teevad kõikjale revolutsiooni, ei soovi kellelegi müüa ja alistavad kõik korraga, sealhulgas Google'i, Microsofti ja Amazoni? Nende võimalused selleks olid väga väikesed. Näib, et nad ei leidnud kedagi, kellega sõbraks saada. Kui sa ei sõbrune kellegagi, siis lõpuks keelatakse sind. Nii ka läks.

Nii et. Seetõttu tuleb konteineritele tähelepanu pöörata. Kontrollerid ja orkestreerimine muutuvad järjest enam tavaliseks. Praegu on konverentsidel juba ettekanded, nagu näiteks „Kunagi ei ole liiga hilja alustada Kubernetesega, isegi kui olete pensionil”. Seega on see vajalik. Ja nüüd hakkab Kubernetes ümber toimuma palju huvitavat. Üks Kubernetes'e põnevamaid omadusi on tõeliselt universaalse API loomine, mis võimaldab meil kirjeldada kõike, mis meie infrastruktuuris toimub. Viimase aasta jooksul oleme näinud katseid selle API ümber luua mitmeid asju. Teenusete filter on üks selline katse, peaaegu kõik praegu olemasolevad teenusete filtrite rakendused väidavad mingil määral: „Laieneme API-ga, lisame intelligentsust, kirjelduse objektidest väljaspool Kubernetes'e, kuid loeme objekte Kubernetes'est ja seeläbi teame, mida teha”.

Teine selline näide on see, mis toimub praegu Continuous Delivery Foundationiga, mis loodi umbes poolteist aastat tagasi, ja selle taga on taas Google, CloudBees, GitLab. Google'i projekt Tekton keskendub ideele luua universaalne API, et kirjeldada continuous delivery protsessi. Suures plaanis püüavad nad jagada selle kõik kindlateks objektideks, mis peavad olema continuous integration / continuous delivery süsteemis, ja selle kaudu luua võimalus neid Salvestada Kubernetesesse, et võiks olla erinevaid komponente, mis oskavad neid määratlemisi lugeda ja otsustada, mida nendega teha. Teenuse sihtmärkide osas toimuvad samad asjad, millest ma rääkisin. aruandesMicrosoft püüab praegu luua spetsiifikatsiooni, mida teenuse sihtpunkt peaks tegema, tuntud kui SMI Spec. Ideega, et iga teenuse sihtpunkti rakendus suudab täita kõike, mis sellel spetsiifikatsioonis on kirjutatud, pluss midagi veel.

Seetõttu on Kubernetes võitnud. Hetkel, mil sa muutud innovatsioonide platvormiks, on väga keeruline sind kõrvale heita, sest selle peale on juba kasvanud, ning nüüd, kui Kubernetes kõrvaldada, tuleb koos beebiga välja visata ka vesi.

Millistele ettek الأن jaolged sen otto da powinien spełniać

Oleg: Millistele ettekannetele sa ise lähed, mis tundub sulle huvitav?

Anton: Esiteks, kui on mingi uus tehnoloogiline nipp või vidin, mida ma pole veel jõudnud ise uurida, ja on esineja, kes oskab seda arusaadavalt seletada, siis ma arvan, et see on absoluutne eelis, sest selle asemel, et praegu lugeda, kaevata ja võimalik, et raskustega aru saada, saad tulla ja poole tunni jooksul kuulata, kuidas keegi sulle näitab ja räägib. Taaskord, selleks on vajalik teatud oskus ja soov osata tehnoloogiat selgitada. Ja ma mõistan, et see ei tule iseenesest, selle nimel tuleb tööd teha. See on mulle ka palju aega võtnud. Muide, see, et ma tegeleb tehnilise õpetamisega, on mulle selles väga aidanud. Kui sul on ees klass ja pead inimestele midagi selgitama, ja sa mõistad, et ükskõik kuidas sa seletad, nad ei saa aru — siis saad aru, et probleem on tõenäoliselt selles, kuidas sa seletad, mitte selles, et inimesed ei mõista.

Oleg: Mis see tehniline õpetamine on? Mida sa teed?

Anton: Olen umbes 7-8 aastat õpetanud puhtalt tehnilisi aineid. Kõik algas sellest, et õpetasin selliseid asju nagu Maven ja shell scripting aasta aega. Kuna olen Jenkinsiga väga süvitsi tegelenud ja seda hästi tundnud, õpetasin inimestele Jenkinsiga töötamist ja haldamist. Viimastel aastatel olen tegelenud kõikide teemadega, mis on seotud cloud native'inguga: Kubernetes, konteinerid ja kõik, mis sellega seondub. Varsti lähen Londonisse, et viia läbi meistriklass Istio teemal. See ei ole minu peamine tegevus, aga iga kuu-kaks korraldan ma meistriklassid.

Oleg: Kas sa lähed peamiselt ettekande, teema või inimese pärast?

Anton: Kui ma tean, et esineja on hea, siis lähen sinna lihtsalt selleks, et õppida teistel inimestelt, kuidas hästi rääkida. Õppimine on alati oluline. Kui on teema, aga ma ei tunne esinejat, siis lähen vaatama, kuid see on nagu stand-up: vaatan esimesed 10-15 minutit, kui ei haaku – lahkun. On ka esinejaid, kellele ma tõeliselt lähen igal juhul, sest nad räägivad alati huvitavalt. Isegi asjadest, mida sa tead, oskavad nad näidata oma vaatenurgast, mis pöörab kogu küsimuse täiesti uuele tasandile. Viimasel ajal meeldib mulle… Esiteks Simon Wardley – konsultant, kellel on oma meetod kaartide joonistamiseks. Ta seletab kaartide abil, kuidas ettevõtted saavad oma strateegiat õigesti üles ehitada. Ta on kunagi olnud mõne portfelli CTO ja CEO, ja räägib sellest palju, samuti tehnoloogiast. Ta, muide, toetab pidevalt serverivaba (serverless) lähenemist ja ütleb, et neil, kes seda täna ei tee, on suured probleemid.

Oleg: See on see tüüp, kellel on Mediumis raamat? Он её в виде постов сделал. Ebatavaline formaat.

Anton: Ta räägib tõeliselt huvitavalt. Tema loengud viimase 2-3 aasta jooksul on mulle enim meelde jäänud. Näiteks John Willis, kes käis eelmisel aastal DevOopsil — just sellepärast, et ta teab tõeliselt rääkida. Temaga on teatud probleem, sest ta räägib väga palju Ameerika reaalsusest, asjadest, mis ei ole vahel kuidagi rakendatavad ei Venemaa ega Israelis. Nendel on praegu mingi sõda mingite muudatuste kinnitamise komiteede vastu, millest nad pidevalt räägivad. Tundub, et see on asi, mis eksisteerib Ameerika ettevõtetes, seal on selline protsess IT muudatuste läbiviimiseks ja kinnitamiseks, kus tuleb läbi minna mingitest komiteedest.

Oleg: Aga meil sellist asja ei ole — ma ei saa isegi aru, millest sa praegu räägid.

Anton: Mina ka ei saa eriti aru, Israelis ei ole ka sellist asja. Aga seal nad sellest räägivad. Kui kuulata neid mehi, nagu DORA, kes teevad State of DevOps Report, räägivad nad sellest samuti palju. Ütleme, et ma räägin sellest, et inimesed räägivad mingist probleemist, mis on ainult nende juures, ja see ei huvita sind üldse.

Oleg: Sa oled käinud eelmisel DevOpsil, milliseid ettekandeid peaks seal vaatama ja üle vaatama?

Anton: Vaata keskkondades ja projekti klastrites. Selline põhimõte on õige. Natuke huvitab teema — peaks minema.

Oleg: Seal on mingi Anton Weiss, ma arvan. Tõenäoliselt tasub teda vaadata.

Anton: Ei, selle peale ei mine, sest see on igav 🙂

Oleg: Noh, aitäh palju. See oli äge! Näen, et oled juba esitluse järgmisele konverentsile esitanud, nii et — kohtume järgmisel DevOpsil!

Konverents DevOps 2020 Moskvas toimub 29-30 aprillil, seekord — Moskvas. Konverentsi sisu oleme kirjeldanud Habr's reklaamis „DevOps-insenerid ei eksisteeri“. Programm on aktiivselt koostamisel (konverentsini on veel palju kuuk), aga esimesed esinejad on juba näha saidil. Seal saab ka osta pileteid.

Allikas: habr.com