Anton Weiss, themelues dhe drejtor i Otomato Software, një nga iniciatorët dhe instruktorët e certifikimit të parë DevOps në Izrael, foli në vitin e kaluar rreth teorisë së kaosit dhe parimeve kryesore të inxhinierisë së kaosit, dhe gjithashtu shpjegoi se si funksionon organizimi ideal DevOps i së ardhmes.
Ne kemi përgatitur një version tekst të raportit.
Mirëmëngjes
DevOpsDays në Moskë për të dytin vit radhazi, kjo është hera ime e dytë në këtë skenë, shumë prej jush janë në këtë dhomë për herë të dytë. Çfarë do të thotë? Kjo do të thotë që lëvizja DevOps në Rusi po rritet, shumëfishohet dhe më e rëndësishmja, do të thotë se ka ardhur koha të flasim për atë që është DevOps në 2018.
Ngrini duart kush mendon se DevOps është tashmë një profesion në 2018? Ka të tilla. A ka ndonjë inxhinier DevOps në dhomë përshkrimi i punës së të cilëve thotë "Inxhinier DevOps"? A ka ndonjë menaxher DevOps në dhomë? Nuk ka të tillë. Arkitektët DevOps? Gjithashtu nr. Jo mjaftueshem. A është vërtet e vërtetë që askush nuk thotë se janë inxhinier DevOps?
Pra, shumica prej jush mendojnë se ky është një anti-model? Se një profesion i tillë nuk duhet të ekzistojë? Ne mund të mendojmë çfarë të duam, por ndërkohë që ne jemi duke menduar, industria po ecën solemnisht përpara në tingullin e trombës së DevOps.
Kush ka dëgjuar për një temë të re të quajtur DevDevOps? Kjo është një teknikë e re që lejon një bashkëpunim efektiv midis zhvilluesve dhe devops. Dhe jo aq e re. Duke gjykuar nga Twitter, ata filluan të flasin për këtë 4 vjet më parë. Dhe deri më tani, interesi për këtë po rritet dhe po rritet, domethënë ka një problem. Problemi duhet zgjidhur.
Ne jemi njerëz kreativë, nuk jemi thjesht të qetë. Ne themi: DevOps nuk është një fjalë mjaftueshëm gjithëpërfshirëse; ende i mungojnë të gjitha llojet e elementeve të ndryshme, interesante. Dhe ne shkojmë në laboratorët tanë sekretë dhe fillojmë të prodhojmë mutacione interesante: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logjika është e hekurt, apo jo? Sistemi ynë i dorëzimit nuk është funksional, sistemet tona janë të paqëndrueshme dhe përdoruesit tanë janë të pakënaqur, nuk kemi kohë të nxjerrim softuerin në kohë, nuk futemi në buxhet. Si do ta zgjidhim gjithë këtë? Do të dalim me një fjalë të re! Do të përfundojë me "Ops" dhe problemi është zgjidhur.
Kështu që unë e quaj këtë qasje - "Ops, dhe problemi është zgjidhur".
E gjithë kjo zbehet në plan të dytë nëse i kujtojmë vetes se përse dolëm me gjithë këtë. Ne dolëm me të gjithë këtë gjë të DevOps për ta bërë shpërndarjen e softuerit dhe punën tonë në këtë proces sa më të papenguar, pa dhimbje, efikase dhe më e rëndësishmja, sa më të këndshme.
DevOps u rrit nga dhimbja. Dhe ne jemi të lodhur nga vuajtjet. Dhe në mënyrë që e gjithë kjo të ndodhë, ne mbështetemi në praktikat me gjelbërim të përhershëm: bashkëpunim efektiv, praktika rrjedhëse dhe më e rëndësishmja, të menduarit sistematik, sepse pa të asnjë DevOps nuk funksionon.
Cili është sistemi?
Dhe nëse tashmë po flasim për të menduarit sistematik, le t'i kujtojmë vetes se çfarë është një sistem.
Nëse jeni një haker revolucionar, atëherë për ju sistemi është qartësisht i keq. Është një re që varet mbi ju dhe ju detyron të bëni gjëra që nuk dëshironi t'i bëni.
Nga pikëpamja e të menduarit sistematik, një sistem është një tërësi që përbëhet nga pjesë. Në këtë kuptim, secili prej nesh është një sistem. Organizatat në të cilat punojmë janë sisteme. Dhe ajo që ju dhe unë po ndërtojmë quhet sistem.
E gjithë kjo është pjesë e një sistemi të madh socio-teknologjik. Dhe vetëm nëse kuptojmë se si funksionon së bashku ky sistem socio-teknologjik, vetëm atëherë do të jemi në gjendje të optimizojmë vërtet diçka në këtë çështje.
Nga perspektiva e të menduarit sistematik, një sistem ka veti të ndryshme interesante. Së pari, ai përbëhet nga pjesë, që do të thotë se sjellja e tij varet nga sjellja e pjesëve. Për më tepër, të gjitha pjesët e tij janë gjithashtu të ndërvarura. Rezulton se sa më shumë pjesë të ketë një sistem, aq më e vështirë është të kuptosh ose parashikosh sjelljen e tij.
Nga pikëpamja e sjelljes, ka një tjetër fakt interesant. Sistemi mund të bëjë diçka që asnjë nga pjesët e tij individuale nuk mund ta bëjë.
Siç tha Dr. Russell Ackoff (një nga themeluesit e të menduarit sistematik), kjo është mjaft e lehtë të vërtetohet me një eksperiment mendimi. Për shembull, kush në dhomë di të shkruajë kodin? Ka shumë duar dhe kjo është normale, sepse kjo është një nga kërkesat kryesore për profesionin tonë. A dini të shkruani, por a mund të shkruajnë duart tuaja kod veçmas nga ju? Ka njerëz që do të thonë: "Nuk janë duart e mia ato që shkruajnë kodin, është truri im që shkruan kodin." A mundet truri juaj të shkruajë kode veçmas nga ju? Epo, ndoshta jo.
Truri është një makinë e mahnitshme, ne nuk e dimë as 10% se si funksionon atje, por nuk mund të funksionojë veçmas nga sistemi që është trupi ynë. Dhe kjo është e lehtë për t'u provuar: hapni kafkën tuaj, nxirrni trurin, vendoseni para kompjuterit, lëreni të përpiqet të shkruajë diçka të thjeshtë. "Përshëndetje, botë" në Python, për shembull.
Nëse një sistem mund të bëjë diçka që asnjë nga pjesët e tij nuk mund ta bëjë veçmas, atëherë kjo do të thotë se sjellja e tij nuk përcaktohet nga sjellja e pjesëve të tij. Nga çfarë përcaktohet atëherë? Ajo përcaktohet nga ndërveprimi midis këtyre pjesëve. Dhe në përputhje me rrethanat, sa më shumë pjesë, sa më komplekse të jenë ndërveprimet, aq më e vështirë është të kuptosh dhe të parashikosh sjelljen e sistemit. Dhe kjo e bën një sistem të tillë kaotik, sepse çdo ndryshim, madje edhe më i parëndësishëm, i padukshëm në çdo pjesë të sistemit mund të çojë në rezultate krejtësisht të paparashikueshme.
Kjo ndjeshmëri ndaj kushteve fillestare u zbulua dhe u studiua për herë të parë nga meteorologu amerikan Ed Lorenz. Më pas, ai u quajt "efekti i fluturës" dhe çoi në zhvillimin e një lëvizjeje të mendimit shkencor të quajtur "teoria e kaosit". Kjo teori u bë një nga ndryshimet kryesore të paradigmës në shkencën e shekullit të 20-të.
Teoria e kaosit
Njerëzit që studiojnë kaosin e quajnë veten kaosologë.
Në fakt, arsyeja e këtij raporti ishte se, duke punuar me sisteme komplekse të shpërndara dhe organizata të mëdha ndërkombëtare, në një moment kuptova se kjo është ajo që ndihem. Unë jam një kaosolog. Kjo është në thelb një mënyrë e zgjuar për të thënë: "Unë nuk e kuptoj se çfarë po ndodh këtu dhe nuk di çfarë të bëj për këtë."
Unë mendoj se shumë prej jush gjithashtu ndihen shpesh kështu, kështu që jeni edhe kaosologë. Ju ftoj në repartin e kaosologëve. Sistemet që ju dhe unë, të dashur kolegë kaosologë, do të studiojmë quhen "sisteme komplekse adaptive".
Çfarë është përshtatshmëria? Përshtatshmëria nënkupton që sjellja individuale dhe kolektive e pjesëve në një sistem të tillë adaptiv ndryshon dhe vetëorganizohet, duke iu përgjigjur ngjarjeve ose zinxhirëve të mikro-ngjarjeve në sistem. Domethënë, sistemi i përshtatet ndryshimeve nëpërmjet vetëorganizimit. Dhe kjo aftësi për t'u vetëorganizuar bazohet në bashkëpunimin vullnetar, plotësisht të decentralizuar të agjentëve të lirë autonome.
Një veçori tjetër interesante e sistemeve të tilla është se ato janë të shkallëzueshme lirisht. Çfarë duhet të na interesojë padyshim ne, si kaosologë-inxhinierë. Pra, nëse themi se sjellja e një sistemi kompleks përcaktohet nga ndërveprimi i pjesëve të tij, atëherë çfarë duhet të na interesojë? Ndërveprim.
Ka dy gjetje më interesante.
Së pari, ne kuptojmë se një sistem kompleks nuk mund të thjeshtohet duke thjeshtuar pjesët e tij. Së dyti, mënyra e vetme për të thjeshtuar një sistem kompleks është thjeshtimi i ndërveprimeve ndërmjet pjesëve të tij.
Si ndërveprojmë? Ju dhe unë jemi të gjithë pjesë e një sistemi të madh informacioni të quajtur shoqëri njerëzore. Ne ndërveprojmë përmes një gjuhe të përbashkët, nëse e kemi, nëse e gjejmë.
Por gjuha në vetvete është një sistem kompleks adaptiv. Prandaj, për të bashkëvepruar në mënyrë më efikase dhe më të thjeshtë, ne duhet të krijojmë një lloj protokolli. Domethënë, disa sekuencë simbolesh dhe veprimesh që do ta bëjnë shkëmbimin e informacionit mes nesh më të thjeshtë, më të parashikueshëm, më të kuptueshëm.
Dua të them se tendencat drejt kompleksitetit, drejt përshtatshmërisë, drejt decentralizimit, drejt kaosit mund të gjurmohen në çdo gjë. Dhe në sistemet që ju dhe unë po ndërtojmë, dhe në ato sisteme ku ne jemi pjesë.
Dhe për të mos qenë të pabazë, le të shohim se si po ndryshojnë sistemet që ne krijojmë.
Ju e prisnit këtë fjalë, e kuptoj. Jemi në një konferencë DevOps, sot kjo fjalë do të dëgjohet rreth njëqind mijë herë dhe më pas do ta ëndërrojmë natën.
Microservices janë arkitektura e parë e softuerit që u shfaq si një reagim ndaj praktikave të DevOps, e cila është krijuar për t'i bërë sistemet tona më fleksibël, më të shkallëzuar dhe për të siguruar shpërndarje të vazhdueshme. Si e bën ajo këtë? Duke ulur volumin e shërbimeve, duke reduktuar shtrirjen e problemeve që procesojnë këto shërbime, duke ulur kohën e dorëzimit. Kjo do të thotë, ne zvogëlojmë dhe thjeshtojmë pjesë të sistemit, rrisim numrin e tyre, dhe në përputhje me rrethanat, kompleksiteti i ndërveprimeve midis këtyre pjesëve rritet pa ndryshim, domethënë lindin probleme të reja që duhet t'i zgjidhim.
Mikroshërbimet nuk janë fundi, mikroshërbimet janë, në përgjithësi, tashmë dje, sepse Serverless po vjen. Të gjithë serverët janë djegur, asnjë server, asnjë sistem operativ, vetëm kod i pastër i ekzekutueshëm. Konfigurimet janë të ndara, shtetet janë të ndara, gjithçka kontrollohet nga ngjarjet. Bukuri, pastërti, heshtje, asnjë ngjarje, asgjë nuk ndodh, rregull i plotë.
Ku është kompleksiteti? Vështirësia, natyrisht, është në ndërveprimet. Sa mund të bëjë një funksion më vete? Si ndërvepron me funksione të tjera? Radhët e mesazheve, bazat e të dhënave, balancuesit. Si të rikrijoni një ngjarje kur ndodhi një dështim? Shumë pyetje dhe pak përgjigje.
Microservices dhe Serverless janë ato që ne hipsterët geek i quajmë Cloud Native. Gjithçka ka të bëjë me renë. Por cloud është gjithashtu i kufizuar në thelb në shkallëzueshmërinë e saj. Jemi mësuar ta mendojmë atë si një sistem të shpërndarë. Në fakt, ku jetojnë serverët e ofruesve të cloud? Në qendrat e të dhënave. Domethënë, ne këtu kemi një lloj modeli të centralizuar, shumë të kufizuar, të shpërndarë.
Sot kuptojmë se Interneti i Gjërave nuk është më vetëm fjalë të mëdha që edhe sipas parashikimeve modeste, miliarda pajisje të lidhura me internetin na presin në pesë deri në dhjetë vitet e ardhshme. Një sasi e madhe të dhënash të dobishme dhe të padobishme që do të shkrihen në cloud dhe do të ngarkohen nga cloud.
Reja nuk do të zgjasë, kështu që ne po flasim gjithnjë e më shumë për diçka të quajtur edge computing. Ose më pëlqen gjithashtu përkufizimi i mrekullueshëm i "përllogaritjes së mjegullës". Ajo është e mbështjellë me misticizmin e romantizmit dhe misterit.
Llogaritja e mjegullës. Çështja është se retë janë grumbullime të centralizuara uji, avulli, akulli dhe gurësh. Dhe mjegulla janë pika uji që shpërndahen rreth nesh në atmosferë.
Në paradigmën e mjegullës, pjesa më e madhe e punës bëhet nga këto pika plotësisht në mënyrë autonome ose në bashkëpunim me pikat e tjera. Dhe ata kthehen në re vetëm kur janë vërtet të shtypur.
Kjo është, përsëri decentralizimi, autonomia dhe, natyrisht, shumë prej jush tashmë e kuptoni se ku po shkon e gjithë kjo, sepse nuk mund të flisni për decentralizim pa përmendur blockchain.
Ka nga ata që besojnë, këta janë ata që kanë investuar në kriptomonedhë. Ka nga ata që besojnë por kanë frikë, si unë p.sh. Dhe ka nga ata që nuk besojnë. Këtu mund të trajtoni ndryshe. Ka teknologji, një çështje e re e panjohur, ka probleme. Si çdo teknologji e re, ajo ngre më shumë pyetje sesa përgjigje.
Hipja rreth blockchain është e kuptueshme. Duke lënë mënjanë nxitimin e arit, vetë teknologjia ka premtime të jashtëzakonshme për një të ardhme më të ndritshme: më shumë liri, më shumë autonomi, besim të shpërndarë global. Çfarë nuk duhet të dëshironi?
Prandaj, gjithnjë e më shumë inxhinierë në mbarë botën po fillojnë të zhvillojnë aplikacione të decentralizuara. Dhe kjo është një fuqi që nuk mund të hidhet poshtë thjesht duke thënë: "Ahh, blockchain është thjesht një bazë të dhënash e shpërndarë keq e zbatuar." Ose siç duan të thonë skeptikët: "Nuk ka aplikacione reale për blockchain". Nëse mendoni pak, 150 vjet më parë ata thanë të njëjtën gjë për energjinë elektrike. Madje në një farë mënyre kishin të drejtë, sepse ajo që e bën të mundur sot energjia elektrike nuk ishte aspak e mundur në shekullin e 19-të.
Nga rruga, kush e di se çfarë lloj logoje është në ekran? Ky është Hyperledger. Ky është një projekt që po zhvillohet nën kujdesin e The Linux Foundation dhe përfshin një sërë teknologjish blockchain. Kjo është me të vërtetë forca e komunitetit tonë me burim të hapur.
Inxhinieri Kaosi
Pra, sistemi që ne po zhvillojmë po bëhet gjithnjë e më kompleks, gjithnjë e më shumë kaotik dhe gjithnjë e më shumë adaptues. Netflix janë pionierë të sistemeve të mikroshërbimit. Ata ishin ndër të parët që e kuptuan këtë, ata zhvilluan një grup mjetesh që i quajtën Ushtria Simian, më e famshmja prej të cilave ishte . Ai përcaktoi atë që u bë e njohur si .
Nga rruga, në procesin e punës për raportin, ne madje e përkthejmë këtë tekst në Rusisht, kështu që shkoni te , lexoni, komentoni, qortoni.
Shkurtimisht, parimet e inxhinierisë së kaosit thonë si më poshtë. Sistemet komplekse të shpërndara janë në thelb të paparashikueshme dhe në thelb të trasha. Gabimet janë të pashmangshme, që do të thotë se ne duhet t'i pranojmë këto gabime dhe të punojmë me këto sisteme në një mënyrë krejtësisht të ndryshme.
Ne vetë duhet të përpiqemi t'i fusim këto gabime në sistemet tona të prodhimit në mënyrë që të testojmë sistemet tona për të njëjtën përshtatshmëri, pikërisht këtë aftësi për vetëorganizim, për mbijetesë.
Dhe kjo ndryshon gjithçka. Jo vetëm si i lëshojmë sistemet në prodhim, por edhe si i zhvillojmë, si i testojmë ato. Nuk ka asnjë proces stabilizimi apo ngrirjeje të kodit, përkundrazi ka një proces të vazhdueshëm destabilizimi. Ne po përpiqemi të vrasim sistemin dhe ta shohim atë të vazhdojë të mbijetojë.
Protokollet e Integrimit të Sistemit të Shpërndara
Prandaj, kjo kërkon që sistemet tona të ndryshojnë disi. Në mënyrë që ato të bëhen më të qëndrueshme, ata kanë nevojë për disa protokolle të reja për ndërveprimin midis pjesëve të tyre. Në mënyrë që këto pjesë të bien dakord dhe të vijnë në një lloj vetëorganizimi. Dhe lindin lloj-lloj mjetesh të reja, protokolle të reja, të cilat unë i quaj "protokolle për ndërveprimin e sistemeve të shpërndara".
Për çfarë po flas? Së pari, projekti . Disa përpiqen të krijojnë një protokoll të përgjithshëm të përcjelljes së shpërndarë, i cili është një mjet absolutisht i domosdoshëm për korrigjimin e sistemeve komplekse të shpërndara.
Me tutje - . Ne themi se nuk mund të parashikojmë se çfarë do të ndodhë me sistemin, domethënë duhet të rrisim vëzhgueshmërinë, vëzhgueshmërinë e tij. Opentracing i përket një familjeje mjetesh që u japin vëzhgueshmëri sistemeve tona. Por ne kemi nevojë për vëzhgim për të përcaktuar nëse sistemi sillet ashtu siç e presim ne apo jo. Si e përkufizojmë sjelljen e pritur? Duke përcaktuar një lloj politike, disa rregulla. Projekti Open Policy Agent është duke punuar për të përcaktuar këtë grup rregullash në një spektër që varion nga qasja deri te shpërndarja e burimeve.
Siç thamë, sistemet tona drejtohen gjithnjë e më shumë nga ngjarjet. Pa server është një shembull i shkëlqyer i sistemeve të drejtuara nga ngjarjet. Në mënyrë që ne të transferojmë ngjarjet midis sistemeve dhe t'i gjurmojmë ato, na duhet një gjuhë e përbashkët, një protokoll i përbashkët për mënyrën se si flasim për ngjarjet, si ia transmetojmë ato njëri-tjetrit. Kështu e quajti një projekt .
Rrjedha e vazhdueshme e ndryshimeve që lajnë sistemet tona, duke i destabilizuar vazhdimisht ato, është një rrjedhë e vazhdueshme e artefakteve softuerike. Në mënyrë që ne të ruajmë këtë rrjedhë të vazhdueshme ndryshimesh, ne kemi nevojë për një lloj protokolli të përbashkët përmes të cilit mund të flasim se çfarë është një artefakt softuer, si testohet, çfarë verifikimi ka kaluar. Kështu e quajti një projekt . Kjo do të thotë, një protokoll i zakonshëm i meta të dhënave për artefaktet e softuerit.
Dhe së fundi, nëse duam që sistemet tona të jenë plotësisht të pavarura, adaptive dhe të vetëorganizuara, duhet t'u japim atyre të drejtën e vetëidentifikimit. Projekti i thirrur Kjo është pikërisht ajo që ai bën. Ky është gjithashtu një projekt nën kujdesin e Cloud Native Computing Foundation.
Të gjitha këto projekte janë të reja, të gjitha kanë nevojë për dashurinë tonë, për vërtetimin tonë. E gjithë kjo është me burim të hapur, testimi ynë, zbatimi ynë. Ata na tregojnë se ku po shkon teknologjia.
Por DevOps kurrë nuk ka qenë kryesisht për teknologjinë, ka qenë gjithmonë për bashkëpunimin mes njerëzve. Dhe, në përputhje me rrethanat, nëse duam që sistemet që zhvillojmë të ndryshojnë, atëherë ne vetë duhet të ndryshojmë. Në fakt, ne po ndryshojmë gjithsesi; ne nuk kemi shumë zgjedhje.
Ka një të mrekullueshme Shkrimtarja britanike Rachel Botsman, në të cilën ajo shkruan për evolucionin e besimit gjatë historisë njerëzore. Ajo thotë se fillimisht në shoqëritë primitive besimi ka qenë lokal, pra ne i kemi besuar vetëm atyre që i njohim personalisht.
Pastaj ishte një periudhë shumë e gjatë - një kohë e errët kur besimi ishte i centralizuar, kur filluam t'u besojmë njerëzve të cilët nuk i njohim për shkak të faktit se i përkasim të njëjtit institucion publik ose shtetëror.
Dhe kjo është ajo që shohim në botën tonë moderne: besimi po shpërndahet dhe decentralizohet gjithnjë e më shumë, dhe bazohet në lirinë e rrjedhës së informacionit, në disponueshmërinë e informacionit.
Nëse mendoni për këtë, pikërisht kjo aksesueshmëri, që e bën të mundur këtë besim, është ajo që ju dhe unë po zbatojmë. Kjo do të thotë se si mënyra si ne bashkëpunojmë ashtu edhe mënyra se si e bëjmë atë duhet të ndryshojë, sepse organizatat e centralizuara, hierarkike të TI-së të dikurshme nuk funksionojnë më. Ata fillojnë të vdesin.
Bazat e Organizatës DevOps
Organizimi ideal i DevOps i së ardhmes është një sistem i decentralizuar, adaptiv i përbërë nga ekipe autonome, secila e përbërë nga individë autonome. Këto ekipe janë të shpërndara nëpër botë, duke bashkëpunuar në mënyrë efektive me njëra-tjetrën duke përdorur komunikimin asinkron, duke përdorur protokolle komunikimi shumë transparente. Shumë e bukur, apo jo? Një e ardhme shumë e bukur.
Sigurisht, asnjë nga këto nuk është e mundur pa ndryshime kulturore. Duhet të kemi udhëheqje transformuese, përgjegjësi personale, motivim të brendshëm.
Kjo është baza e organizatave DevOps: transparenca e informacionit, komunikimet asinkrone, udhëheqja transformuese, decentralizimi.
Digjem
Sistemet ku ne jemi pjesë dhe ato që ndërtojmë janë gjithnjë e më kaotike dhe është e vështirë për ne njerëzit të përballemi me këtë mendim, është e vështirë të heqim dorë nga iluzioni i kontrollit. Ne përpiqemi të vazhdojmë t'i kontrollojmë ato, dhe kjo shpesh çon në djegie. Këtë e them nga përvoja ime, edhe unë jam djegur, jam invaliduar edhe nga dështime të paparashikuara në prodhim.
Djegia ndodh kur përpiqemi të kontrollojmë diçka që është në thelb e pakontrollueshme. Kur digjemi, çdo gjë humbet kuptimin e saj sepse humbasim dëshirën për të bërë diçka të re, bëhemi mbrojtës dhe fillojmë të mbrojmë atë që kemi.
Profesioni i inxhinierit, siç më pëlqen ta kujtoj shpesh veten, është para së gjithash një profesion krijues. Nëse humbasim dëshirën për të krijuar diçka, atëherë shndërrohemi në hi, shndërrohemi në hi. Njerëzit digjen, organizata të tëra digjen.
Për mendimin tim, vetëm pranimi i fuqisë krijuese të kaosit, vetëm ndërtimi i bashkëpunimit sipas parimeve të tij është ajo që do të na ndihmojë të mos humbasim atë që është e mirë në profesionin tonë.
Kjo është ajo që unë uroj për ju: ta doni punën tuaj, ta doni atë që bëjmë. Kjo botë ushqehet me informacion, ne kemi nderin ta ushqejmë atë. Pra, le të studiojmë kaosin, të jemi kaosologë, të sjellim vlerë, të krijojmë diçka të re, mirë, problemet, siç e kemi kuptuar tashmë, janë të pashmangshme dhe kur të shfaqen, thjesht do të themi "Ops!" Dhe problemi zgjidhet.
Çfarë tjetër përveç majmunit të kaosit?
Në fakt, të gjitha këto instrumente janë kaq të reja. I njëjti Netflix ndërtoi mjete për veten e tyre. Ndërtoni mjetet tuaja. Lexoni parimet e inxhinierisë së kaosit dhe zbatoni ato parime në vend që të përpiqeni të gjeni mjete të tjera që dikush tjetër i ka ndërtuar tashmë.
Mundohuni të kuptoni se si sistemet tuaja prishen dhe filloni t'i prishni ato dhe shikoni se si qëndrojnë. Kjo vjen e para. Dhe mund të kërkoni mjete. Ka të gjitha llojet e projekteve.
Nuk e kuptova fare momentin kur thatë se sistemi nuk mund të thjeshtohet duke thjeshtuar komponentët e tij dhe menjëherë kalova te mikroshërbimet, të cilat thjeshtojnë sistemin duke thjeshtuar vetë komponentët dhe duke ndërlikuar ndërveprimet. Këto janë në thelb dy pjesë që kundërshtojnë njëra-tjetrën.
Është e drejtë, mikroshërbimet janë një temë shumë e diskutueshme në përgjithësi. Në fakt, thjeshtimi i pjesëve rrit fleksibilitetin. Çfarë ofrojnë mikroshërbimet? Ato na japin fleksibilitet dhe shpejtësi, por sigurisht që nuk na japin thjeshtësi. Ata rrisin vështirësinë.
Pra, në filozofinë DevOps, mikroshërbimet nuk janë një gjë aq e mirë?
Çdo e mirë ka një anë të kundërt. Përfitimi është se rrit fleksibilitetin, duke na lejuar të bëjmë ndryshime më shpejt, por rrit kompleksitetin dhe rrjedhimisht brishtësinë e të gjithë sistemit.
Megjithatë, çfarë është më shumë theksi: në thjeshtimin e ndërveprimit apo në thjeshtimin e pjesëve?
Theksi, natyrisht, është në thjeshtimin e ndërveprimeve, sepse nëse e shikojmë këtë nga këndvështrimi se si punojmë me ju, atëherë, para së gjithash, duhet t'i kushtojmë vëmendje thjeshtimit të ndërveprimeve, dhe jo thjeshtimit të punës. të secilit prej nesh veç e veç. Sepse thjeshtimi i punës do të thotë të shndërrohesh në robotë. Këtu në McDonald's funksionon normalisht kur keni udhëzime: këtu vendosni burgerin, këtu hidhni salcën mbi të. Kjo nuk funksionon fare në punën tonë krijuese.
A është e vërtetë që gjithçka që thatë jeton në një botë pa konkurrencë, dhe kaosi atje është aq i sjellshëm, dhe nuk ka kontradikta brenda këtij kaosi, askush nuk dëshiron të hajë apo të vrasë njeri? Si duhet të shkojnë konkurrenca dhe DevOps?
Epo, varet se për çfarë lloj konkurrence po flasim. Bëhet fjalë për konkurrencën në vendin e punës apo konkurrencën mes kompanive?
Për konkurrencën e shërbimeve që ekzistojnë sepse shërbimet nuk janë disa kompani. Ne po krijojmë një lloj të ri mjedisi informacioni dhe çdo mjedis nuk mund të jetojë pa konkurrencë. Kudo ka konkurrencë.
Të njëjtin Netflix, ne i marrim si model. Pse erdhën me këtë? Sepse ata duhej të ishin konkurrues. Ky fleksibilitet dhe shpejtësi lëvizjeje është pikërisht kërkesa shumë konkurruese; ajo fut kaos në sistemet tona. Kjo do të thotë, kaosi nuk është diçka që ne e bëjmë me vetëdije sepse e duam, është diçka që ndodh sepse e kërkon bota. Duhet vetëm të përshtatemi. Dhe kaosi, është pikërisht rezultat i konkurrencës.
A do të thotë kjo kaos është mungesa e golave, si të thuash? Apo ato objektiva që nuk duam t'i shohim? Jemi në shtëpi dhe nuk i kuptojmë qëllimet e të tjerëve. Konkurrenca, në fakt, është për faktin se ne kemi synime të qarta dhe e dimë se ku do të përfundojmë në çdo moment të ardhshëm. Ky, nga këndvështrimi im, është thelbi i DevOps.
Gjithashtu një vështrim në pyetjen. Unë mendoj se ne të gjithë kemi të njëjtin qëllim: të mbijetojmë dhe ta bëjmë atë
kënaqësia më e madhe. Dhe qëllimi konkurrues i çdo organizate është i njëjtë. Mbijetesa shpesh ndodh përmes konkurrencës, nuk mund të bësh asgjë për të.
Konferenca e këtij viti do të zhvillohet më 7 dhjetor në Technopolis. Do të pranojmë aplikime për raporte deri më 11 nëntor. ne nëse dëshironi të flisni.
Regjistrimi për pjesëmarrësit është i hapur, biletat kushtojnë 7000 rubla. Bashkohu me ne!
Burimi: www.habr.com