Антон Вайсс, Otomato Software компаниясының негізін қалаушы және директоры, Израильдегі алғашқы DevOps сертификатының бастамашылары мен нұсқаушылардың бірі өткен жылғы конференцияда сөз сөйледі. хаос теориясы және хаос инженериясының негізгі принциптері туралы, сондай-ақ болашақтың идеалды DevOps ұйымы қалай жұмыс істейтінін түсіндірді.
Біз баяндаманың мәтіндік нұсқасын дайындадық.
Қайырлы таң!
Мәскеудегі DevOpsDays екінші жыл қатарынан, мен бұл сахнаға екінші рет шықтым, көпшілігіңіз осы бөлмеде екінші рет отырсыз. Ол нені білдіреді? Бұл Ресейдегі DevOps қозғалысының өсіп, көбейіп келе жатқанын білдіреді және ең бастысы, 2018 жылы DevOps қандай екендігі туралы айтатын уақыт келді дегенді білдіреді.
2018 жылы DevOps қазірдің өзінде кәсіп деп ойлайтындар қолыңызды көтеріңіз? Ондайлар бар. Бөлмеде жұмыс сипаттамасында «DevOps инженері» деп жазылған DevOps инженерлері бар ма? Бөлмеде DevOps менеджерлері бар ма? Ондай жоқ. DevOps сәулетшілері? Жоқ. Жеткіліксіз. Ешкім өзін DevOps инженері деп айтпайтыны рас па?
Сіздердің көпшілігіңіз бұл анти-үлгі деп ойлайсыз ба? Мұндай мамандық болмауы керек пе? Біз қалағанымызды ойлай аламыз, бірақ біз ойлаған кезде сала DevOps кернейінің дыбысына салтанатты түрде алға жылжуда.
DevDevOps деп аталатын жаңа тақырып туралы кім естіді? Бұл әзірлеушілер мен әзірлеушілер арасында тиімді ынтымақтастыққа мүмкіндік беретін жаңа әдіс. Және соншалықты жаңа емес. Twitter-ге қарағанда, олар бұл туралы 4 жыл бұрын айта бастады. Ал осы уақытқа дейін қызығушылық артып, өсіп келеді, яғни мәселе бар. Мәселені шешу керек.
Біз шығармашыл адамдармыз, жай ғана тыныштық танытпаймыз. Біз айтамыз: DevOps - бұл жеткілікті толық сөз емес; оған әлі де әртүрлі, қызықты элементтердің барлық түрлері жоқ. Біз құпия зертханаларымызға барып, қызықты мутацияларды жасай бастаймыз: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Логика темірдей, солай емес пе? Жеткізу жүйеміз жұмыс істемейді, жүйелеріміз тұрақсыз және пайдаланушыларымыз қанағаттанбайды, бағдарламалық қамтамасыз етуді уақытында шығаруға уақытымыз жоқ, бюджетке сәйкес келмейді. Осының бәрін қалай шешеміз? Біз жаңа сөз ойлап табамыз! Ол «Ops» деп аяқталады және мәселе шешілді.
Сондықтан мен бұл тәсілді «Опс, және мәселе шешілді» деп атаймын.
Егер біз мұның бәрін не үшін ойлап тапқанымызды еске түсірсек, мұның бәрі фонға түседі. Бағдарламалық жасақтаманы жеткізуді және осы процестегі өз жұмысымызды кедергісіз, ауыртпалықсыз, тиімді және ең бастысы, мүмкіндігінше жағымды ету үшін біз DevOps туралы осы мәселені ойлап таптық.
DevOps аурудан пайда болды. Ал біз азаптан шаршадық. Мұның бәрі орын алу үшін біз мәңгі жасыл тәжірибелерге сүйенеміз: тиімді ынтымақтастық, ағындық тәжірибелер және ең бастысы жүйелік ойлау, өйткені онсыз DevOps жұмыс істемейді.
Жүйе дегеніміз не?
Егер біз жүйелік ойлау туралы айтатын болсақ, жүйенің не екенін еске түсірейік.
Егер сіз революциялық хакер болсаңыз, онда жүйе сіз үшін анық зұлым. Бұл сіздің үстіңізге ілінетін және сізді қаламайтын нәрселерді жасауға мәжбүрлейтін бұлт.
Жүйелік ойлау тұрғысынан жүйе бөліктерден тұратын тұтастық болып табылады. Осы тұрғыдан алғанда әрқайсымыз жүйеміз. Біз жұмыс істейтін ұйымдар жүйе. Ал сіз бен біз құрып жатқан нәрсе жүйе деп аталады.
Мұның бәрі бір үлкен әлеуметтік-технологиялық жүйенің бір бөлігі. Егер біз осы әлеуметтік-технологиялық жүйенің қалай бірге жұмыс істейтінін түсінсек, сонда ғана біз бұл мәселеде бір нәрсені шынымен оңтайландыра аламыз.
Жүйелік ойлау тұрғысынан жүйе әртүрлі қызықты қасиеттерге ие. Біріншіден, ол бөліктерден тұрады, яғни оның әрекеті бөліктердің мінез-құлқына байланысты. Оның үстіне, оның барлық бөліктері де өзара тәуелді. Жүйенің бөліктері неғұрлым көп болса, оның әрекетін түсіну немесе болжау қиынырақ болады.
Мінез-құлық тұрғысынан тағы бір қызықты факт бар. Жүйе оның жеке бөліктерінің ешқайсысы жасай алмайтын нәрсені жасай алады.
Доктор Рассел Аккофф (жүйелік ойлаудың негізін қалаушылардың бірі) айтқандай, мұны ойлау экспериментімен дәлелдеу өте оңай. Мысалы, бөлмеде кім код жазуды біледі? Қолдар көп, бұл қалыпты жағдай, өйткені бұл біздің мамандыққа қойылатын негізгі талаптардың бірі. Сіз жазуды білесіз бе, бірақ сіздің қолыңыз сізден бөлек код жаза ала ма? «Кодты менің қолым емес, менің миым жазады» деп айтатын адамдар бар. Сіздің миыңыз кодты сізден бөлек жаза ала ма? Жақсы, мүмкін емес.
Ми - таңғажайып машина, біз оның қалай жұмыс істейтінін тіпті 10% білмейміз, бірақ ол біздің денеміз болып табылатын жүйеден бөлек жұмыс істей алмайды. Ал мұны дәлелдеу оңай: бас сүйегіңді аш, миыңды шығар, компьютердің алдына қой, қарапайым нәрсе жазып көрсін. Мысалы, Python тіліндегі «Сәлем, әлем».
Егер жүйе оның бөліктерінің ешқайсысы жеке орындай алмайтын нәрсені жасай алса, онда бұл оның әрекеті оның бөліктерінің әрекетімен анықталмағанын білдіреді. Сонда ол немен анықталады? Ол осы бөліктердің өзара әрекеттесуімен анықталады. Және сәйкесінше, бөліктер неғұрлым көп болса, өзара әрекеттесу неғұрлым күрделі болса, жүйенің әрекетін түсіну және болжау соғұрлым қиын болады. Және бұл мұндай жүйені хаотикалық етеді, өйткені жүйенің кез келген бөлігіндегі кез келген, тіпті ең елеусіз, көзге көрінбейтін өзгерістер мүлдем болжау мүмкін емес нәтижелерге әкелуі мүмкін.
Бұл бастапқы жағдайларға сезімталдықты алғаш рет американдық метеоролог Эд Лоренц ашты және зерттеді. Кейіннен ол «көбелек әсері» деп аталды және «хаос теориясы» деп аталатын ғылыми ой қозғалысының дамуына әкелді. Бұл теория 20 ғасыр ғылымындағы негізгі парадигма өзгерістерінің біріне айналды.
Хаос теориясы
Хаосты зерттейтін адамдар өздерін хаосологтар деп атайды.
Шындығында, бұл есептің себебі күрделі бөлінген жүйелермен және ірі халықаралық ұйымдармен жұмыс істей отырып, бір сәтте мен өзімді дәл осылай сезінетінімді түсіндім. Мен хаосологпын. Бұл негізінен: «Мен мұнда не болып жатқанын түсінбеймін және бұл туралы не істеу керектігін білмеймін» деп айтудың ақылды тәсілі.
Менің ойымша, сіздердің көпшілігіңіз де жиі осылай сезінесіз, сондықтан сіз де хаосологсыз. Мен сізді хаосологтар гильдиясына шақырамын. Сіз және мен, құрметті хаосологтар, зерттейтін жүйелер «күрделі бейімделу жүйелері» деп аталады.
Бейімделу дегеніміз не? Бейімделушілік жүйедегі оқиғаларға немесе микро-оқиғалар тізбегіне жауап бере отырып, мұндай бейімделу жүйесіндегі бөліктердің жеке және ұжымдық мінез-құлқының өзгеруін және өзін-өзі ұйымдастыруын білдіреді. Яғни, жүйе өзін-өзі ұйымдастыру арқылы өзгерістерге бейімделеді. Және бұл өзін-өзі ұйымдастыру қабілеті еркін автономды агенттердің ерікті, толығымен орталықтандырылмаған ынтымақтастығына негізделген.
Мұндай жүйелердің тағы бір қызықты қасиеті - олардың еркін масштабталатындығы. Бізді хаосолог-инженерлер ретінде не қызықтыратыны сөзсіз. Сонымен, егер күрделі жүйенің әрекеті оның бөліктерінің өзара әрекеттесуімен анықталады десек, онда бізді не қызықтыру керек? Өзара әрекеттесу.
Тағы екі қызықты қорытынды бар.
Біріншіден, күрделі жүйені оның бөліктерін жеңілдету арқылы оңайлатуға болмайтынын түсінеміз. Екіншіден, күрделі жүйені жеңілдетудің бірден-бір жолы - оның бөліктері арасындағы өзара әрекеттесулерді жеңілдету.
Біз қалай әрекеттесеміз? Сіз бен біз адам қоғамы деп аталатын үлкен ақпараттық жүйенің бір бөлігіміз. Бізде бар болса, табылса, ортақ тіл арқылы араласамыз.
Бірақ тілдің өзі күрделі бейімделгіш жүйе. Тиісінше, тиімдірек және қарапайым әрекеттесу үшін бізге қандай да бір хаттамалар жасау керек. Яғни, біздің арамыздағы ақпарат алмасуды қарапайым, болжамды, түсінікті ететін белгілер мен әрекеттердің кейбір тізбегі.
Күрделілікке, бейімделуге, орталықсыздандыруға, хаосқа қарай тенденцияларды барлығында байқауға болатынын айтқым келеді. Сіз бен біз құрып жатқан жүйелерде және біз бөлігі болып табылатын жүйелерде.
Ал негізсіз болмас үшін, біз жасайтын жүйелердің қалай өзгеріп жатқанын қарастырайық.
Сіз бұл сөзді күткен едіңіз, түсіндім. Біз DevOps конференциясындамыз, бүгін бұл сөз шамамен жүз мың рет естіледі, содан кейін түнде бұл туралы армандаймыз.
Микросервистер - DevOps тәжірибесіне реакция ретінде пайда болған алғашқы бағдарламалық жасақтама архитектурасы, ол біздің жүйелерімізді икемді, масштабталатын және үздіксіз жеткізуді қамтамасыз етуге арналған. Ол мұны қалай істейді? Қызметтер көлемін қысқарту, осы қызметтер өңдейтін мәселелердің көлемін азайту, жеткізу уақытын қысқарту арқылы. Яғни, біз жүйенің бөліктерін қысқартамыз және жеңілдетеміз, олардың санын көбейтеміз, сәйкесінше бұл бөліктер арасындағы өзара әрекеттесулердің күрделілігі үнемі артады, яғни біз шешуге тура келетін жаңа мәселелер туындайды.
Микросервистердің соңы емес, микросервистер, жалпы алғанда, кеше ғана, өйткені серверсіз келеді. Барлық серверлер өртеніп кетті, серверлер, операциялық жүйелер жоқ, тек таза орындалатын код. Конфигурациялар бөлек, күйлер бөлек, барлығы оқиғалар арқылы басқарылады. Сұлулық, тазалық, тыныштық, ешқандай оқиға, ештеңе болмайды, толық тәртіп.
Күрделілік қайда? Қиындық, әрине, өзара әрекеттесуде. Бір функция өз бетімен қанша орындай алады? Ол басқа функциялармен қалай әрекеттеседі? Хабарламалар кезегі, мәліметтер базасы, балансирлер. Сәтсіздік орын алған кезде кейбір оқиғаны қалай қайта құруға болады? Сұрақтар көп, жауаптар аз.
Микросервистер және серверсіз - бұл біз хипстерлер бұлтты Native деп атайтын нәрсе. Мұның бәрі бұлтқа қатысты. Бірақ бұлт сонымен бірге оның ауқымдылығы жағынан шектеулі. Біз оны бөлінген жүйе ретінде қарастыруға дағдыланғанбыз. Шын мәнінде, бұлттық провайдерлердің серверлері қайда тұрады? Деректер орталықтарында. Яғни, бұл жерде бізде орталықтандырылған, өте шектеулі, бөлінген үлгі түрі бар.
Бүгінде біз заттар интернеті енді жай ғана үлкен сөздер емес екенін түсінеміз, тіпті қарапайым болжамдарға сәйкес, Интернетке қосылған миллиардтаған құрылғылар бізді алдағы бес-он жылда күтеді. Бұлтқа біріктірілетін және бұлттан жүктелетін пайдалы және пайдасыз деректердің үлкен көлемі.
Бұлт ұзаққа созылмайды, сондықтан біз шеткі есептеулер деп аталатын нәрсе туралы көбірек айтып жатырмыз. Немесе маған «тұманды есептеу» керемет анықтамасы ұнайды. Ол романтизм мен тылсым мистицизммен көмкерілген.
Тұманды есептеу. Мәселе мынада: бұлттар орталықтандырылған су, бу, мұз және тастар шоғырлары. Ал тұман – атмосферада айналамызға шашылып жатқан су тамшылары.
Тұман парадигмасында жұмыстың көп бөлігін осы тамшылар толығымен автономды түрде немесе басқа тамшылармен бірлесіп жасайды. Және олар шынымен басылғанда ғана бұлтқа бұрылады.
Яғни, тағы да орталықсыздандыру, автономия және, әрине, көпшілігіңіз мұның қайда жатқанын түсіндіңіз, өйткені сіз блокчейнді айтпай-ақ орталықсыздандыру туралы айта алмайсыз.
Сенетіндер бар, бұл криптовалютаға инвестиция салғандар. Мен сияқты сенетін, бірақ қорқатындар бар. Ал сенбейтіндер бар. Мұнда сіз басқаша емдеуге болады. Технология бар, жаңа белгісіз мәселе, проблемалар бар. Кез келген жаңа технология сияқты, ол жауап бергеннен гөрі көп сұрақтар тудырады.
Блокчейннің төңірегіндегі дүрбелең түсінікті. Алтынға асығуды былай қойғанда, технологияның өзі жарқын болашаққа керемет уәде береді: көбірек еркіндік, көбірек автономия, бөлінген жаһандық сенім. Нені қаламау керек?
Тиісінше, бүкіл әлемде көбірек инженерлер орталықтандырылмаған қосымшаларды жасай бастайды. Бұл жай ғана: «Ахх, блокчейн - бұл нашар енгізілген таратылған дерекқор» деп айту арқылы жоққа шығаруға болмайтын күш. Немесе скептиктер: «Блокчейнге арналған нақты қолданбалар жоқ» деп айтқысы келеді. Ойлап қарасаңыз, осыдан 150 жыл бұрын электр энергиясы туралы да солай айтқан. Және олар тіпті кейбір жағынан дұрыс болды, өйткені бүгінгі күні электр қуаты 19 ғасырда мүмкін емес еді.
Айтпақшы, экранда қандай логотип тұрғанын кім біледі? Бұл Hyperledger. Бұл Linux Foundation демеушілігімен әзірленіп жатқан және блокчейн технологияларының жиынтығын қамтитын жоба. Бұл шын мәнінде біздің ашық бастапқы қауымдастықтың күші.
Хаос инженериясы
Демек, біз жасап жатқан жүйе барған сайын күрделеніп, бейберекет, бейімделгіш болып барады. Netflix микросервис жүйелерінің пионерлері болып табылады. Олар мұны алғашқылардың бірі болып түсінді, олар Simian Army деп аталатын құралдар жиынтығын жасады, олардың ең танымалы болды. . Ол белгілі болған нәрсені анықтады .
Айтпақшы, баяндамамен жұмыс істеу барысында біз бұл мәтінді тіпті орыс тіліне аудардық, сондықтан өтіңіз , оқу, пікір айту, ұрысу.
Қысқаша айтқанда, хаос инженериясының принциптері мынаны айтады. Күрделі үлестірілген жүйелер табиғи түрде болжау мүмкін емес және табиғи түрде қате. Қателер болмай қоймайды, яғни біз бұл қателерді қабылдап, бұл жүйелермен мүлдем басқаша жұмыс істеуіміз керек.
Жүйелерімізді дәл осы бейімделу қабілетіне, өзін-өзі ұйымдастыруға, өмір сүруге қабілеттілігін сынау үшін біз осы қателерді өндірістік жүйелерімізге енгізуге тырысуымыз керек.
Және бұл бәрін өзгертеді. Жүйені өндіріске қалай енгізетініміз ғана емес, сонымен бірге оларды қалай дамытамыз, қалай сынаймыз. Кодты тұрақтандыру немесе мұздату процесі жоқ, керісінше тұрақты тұрақсыздану процесі жүреді. Біз жүйені өлтіріп, оның аман қалуын көруге тырысамыз.
Бөлінген жүйені біріктіру хаттамалары
Тиісінше, бұл біздің жүйелеріміздің қандай да бір түрде өзгеруін талап етеді. Олардың тұрақты болуы үшін олардың бөліктері арасындағы өзара әрекеттесу үшін жаңа хаттамалар қажет. Бұл бөліктер келісіп, өзін-өзі ұйымдастырудың қандай да бір түріне келуі үшін. Әр түрлі жаңа құралдар, жаңа хаттамалар пайда болады, мен оларды «үлестірілген жүйелердің өзара әрекеттесу хаттамалары» деп атаймын.
Мен не туралы айтып отырмын? Біріншіден, жоба . Кейбіреулер күрделі үлестірілген жүйелерді жөндеу үшін таптырмас құрал болып табылатын жалпы бөлінген бақылау протоколын жасауға әрекет жасайды.
Әрі қарай - . Жүйенің не болатынын болжай алмаймыз, яғни оның бақылануын, байқағыштығын арттыру керек дейміз. Opentracing жүйелерімізге бақылау мүмкіндігін беретін құралдар тобына жатады. Бірақ жүйе біз күткендей әрекет ете ме, жоқ па анықтау үшін бізге бақылау қажет. Күтілетін мінез-құлықты қалай анықтаймыз? Қандай да бір саясатты, кейбір ережелер жинағын анықтау арқылы. Ашық саясат агенті жобасы осы ережелер жинағын қатынастан ресурсты бөлуге дейінгі спектрде анықтау үшін жұмыс істейді.
Жоғарыда айтқанымыздай, біздің жүйелеріміз оқиғаларға негізделген. Серверсіз - оқиғаға негізделген жүйелердің тамаша үлгісі. Жүйелер арасында оқиғаларды тасымалдау және оларды қадағалау үшін бізге кейбір ортақ тіл, оқиғалар туралы қалай сөйлесетініміз, оларды бір-бірімізге қалай беретініміз туралы ортақ протокол қажет. Бұл жоба деп аталады .
Жүйелерімізді үнемі тұрақсыздандыратын өзгерістердің тұрақты ағыны бағдарламалық жасақтама артефактілерінің үздіксіз ағыны болып табылады. Өзгерістердің осы тұрақты ағынын сақтау үшін бізге бағдарламалық жасақтама артефакті деген не, оның қалай тексерілетіні, қандай тексеруден өткені туралы сөйлесуге болатын қандай да бір ортақ хаттама қажет. Бұл жоба деп аталады . Яғни, бағдарламалық жасақтама артефактілеріне арналған жалпы метадеректер протоколы.
Соңында, егер біз жүйелеріміздің толық тәуелсіз, бейімделгіш және өздігінен ұйымдастырылғанын қаласақ, біз оларға өзін-өзі сәйкестендіру құқығын беруіміз керек. Жоба шақырылды Ол дәл осылай істейді. Бұл сонымен қатар Cloud Native Computing Foundation қамқорлығындағы жоба.
Бұл жобалардың барлығы жас, олардың барлығы біздің сүйіспеншілігімізді, растауымызды қажет етеді. Мұның бәрі ашық дереккөз, біздің тестілеуіміз, жүзеге асыруымыз. Олар бізге технологияның қайда бара жатқанын көрсетеді.
Бірақ DevOps ешқашан технология туралы болған емес, ол әрқашан адамдар арасындағы ынтымақтастық туралы болды. Соған сәйкес, біз әзірлейтін жүйелердің өзгергенін қаласақ, өзіміз де өзгеруіміз керек. Шындығында, біз бәрібір өзгереміз; бізде таңдау көп емес.
Керемет бар Британдық жазушы Рэйчел Ботсман, онда ол адамзат тарихындағы сенім эволюциясы туралы жазады. Оның айтуынша, бастапқыда қарабайыр қоғамдарда сенім жергілікті болған, яғни біз өзіміз білетін адамдарға ғана сенетінбіз.
Содан кейін өте ұзақ кезең болды – сенім орталықтандырылған зұлмат заман, біз бір қоғамдық немесе мемлекеттік мекемеге жататындығымызды негізге ала отырып, өзіміз танымайтын адамдарға сене бастадық.
Біздің қазіргі әлемде мынаны көреміз: сенім барған сайын таралып, орталықсыздандырылған және ол ақпарат ағындарының еркіндігіне, ақпараттың қолжетімділігіне негізделген.
Ойлап қарасаңыз, бұл сенімді мүмкін ететін дәл осы қолжетімділік сіз бен біз жүзеге асырып жатқан нәрсе. Бұл біздің бірлесіп жұмыс істеу тәсіліміз де, оны жасау тәсілі де өзгеруі керек дегенді білдіреді, өйткені бұрынғы орталықтандырылған, иерархиялық АТ ұйымдары енді жұмыс істемейді. Олар өле бастайды.
DevOps ұйымының негіздері
Болашақтың идеалды DevOps ұйымы - әрқайсысы автономды адамдардан тұратын автономды командалардан тұратын орталықтандырылмаған, бейімделген жүйе. Бұл командалар асинхронды байланысты пайдалана отырып, жоғары мөлдір байланыс хаттамаларын пайдалана отырып, бір-бірімен тиімді ынтымақтаса отырып, бүкіл әлем бойынша шашыраңқы. Өте әдемі, солай емес пе? Өте әдемі болашақ.
Әрине, мұның ешқайсысы мәдени өзгерістерсіз мүмкін емес. Бізде трансформациялық көшбасшылық, жеке жауапкершілік, ішкі мотивация болуы керек.
Бұл DevOps ұйымдарының негізі: ақпараттық ашықтық, асинхронды коммуникациялар, трансформациялық көшбасшылық, орталықсыздандыру.
Жанып кету
Біз құрайтын және біз құрайтын жүйелер барған сайын хаотикалық болып табылады және біз адамдарға бұл оймен күресу қиын, басқару иллюзиясынан бас тарту қиын. Біз оларды бақылауды жалғастыруға тырысамыз, бұл жиі күйіп қалуға әкеледі. Мұны өз тәжірибемнен айтып отырмын, мен де күйдім, өндірістегі күтпеген сәтсіздіктерден мүгедек болдым.
Күйіп қалу табиғи түрде бақыланбайтын нәрсені басқаруға тырысқанда пайда болады. Біз күйіп қалсақ, бәрі мағынасын жоғалтады, өйткені біз жаңа нәрсе жасауға деген құлшынысымызды жоғалтып, қорғанысқа көшеміз және бізде бар нәрсені қорғай бастаймыз.
Инженерлік мамандық, мен жиі еске түсіремін, бұл ең алдымен шығармашылық мамандық. Егер біз бірдеңе жасауға деген құштарлықты жоғалтсақ, күлге айналамыз, күлге айналамыз. Адамдар күйіп кетті, бүкіл ұйымдар өртеніп кетті.
Менің ойымша, тек хаостың жасампаз күшін қабылдау, оның принциптері бойынша ынтымақтастықты құру ғана біздің мамандығымыздағы жақсы нәрсені жоғалтпауға көмектеседі.
Саған тілерім мынау: өз жұмысыңды жақсы көр, біздің ісімізді жақсы көр. Бұл әлем ақпаратпен қоректенеді, біз оны тамақтандыру құрметіне ие боламыз. Олай болса, хаосты зерттейік, хаосолог болайық, құндылық әкелейік, жаңа нәрсе жасайық, жақсы, проблемалар, біз бұрыннан белгілі болғандай, сөзсіз, олар пайда болған кезде біз жай ғана «Оп!» деп айтамыз және мәселе шешілді.
Хаос маймылынан басқа не?
Шындығында, бұл аспаптардың бәрі өте жас. Дәл сол Netflix өзі үшін құралдар құрастырды. Өз құралдарыңызды жасаңыз. Хаос инженериясының принциптерін оқып шығыңыз және басқа біреу құрастырған басқа құралдарды табуға тырыспай, сол принциптерге сай өмір сүріңіз.
Жүйелеріңіздің қалай бұзылатынын түсінуге тырысыңыз және оларды бұзуды бастаңыз және олардың қалай жұмыс істейтінін көріңіз. Бұл бірінші келеді. Және құралдарды іздеуге болады. Жобаның барлық түрі бар.
Жүйені оның құрамдас бөліктерін жеңілдету арқылы оңайлатуға болмайтынын айтқан кезде мен бірден микросервистерге көшкеніңізді түсінбедім, ол компоненттердің өзін жеңілдету және өзара әрекеттесулерді қиындату арқылы жүйені жеңілдетеді. Бұл негізінен бір-біріне қайшы келетін екі бөлік.
Дұрыс, микросервистер жалпы өте даулы тақырып. Шын мәнінде, бөлшектерді жеңілдету икемділікті арттырады. Микросервис не береді? Олар бізге икемділік пен жылдамдық береді, бірақ олар бізге қарапайымдылық бермейді. Олар қиындықты арттырады.
Сонымен, DevOps философиясында микросервистер соншалықты жақсы нәрсе емес пе?
Кез келген жақсылықтың кері жағы болады. Артықшылығы мынада, ол икемділікті арттырады, тезірек өзгерістер жасауға мүмкіндік береді, бірақ ол бүкіл жүйенің күрделілігін, демек, сынғыштығын арттырады.
Дегенмен, не нәрсеге көбірек көңіл бөлінеді: өзара әрекеттесуді жеңілдетуге немесе бөліктерді жеңілдетуге?
Әрине, өзара әрекеттесуді жеңілдетуге баса назар аударылады, өйткені егер біз мұны сізбен қалай жұмыс істейтініміз тұрғысынан қарастыратын болсақ, онда, ең алдымен, жұмысты жеңілдетуге емес, өзара әрекеттесуді жеңілдетуге назар аудару керек. әрқайсымыздан бөлек. Өйткені жұмысты жеңілдету – роботқа айналу деген сөз. Міне, McDonald's-те нұсқаулар болған кезде ол қалыпты жұмыс істейді: мұнда сіз гамбургерді қоясыз, мұнда сіз оған соусты құясыз. Бұл біздің шығармашылық жұмысымызда мүлдем жұмыс істемейді.
Сіз айтқанның бәрі бәсекесіз әлемде өмір сүреді, ал ондағы хаос сондай мейірімді және бұл хаостың ішінде ешқандай қарама-қайшылықтар жоқ, ешкім ешкімді жегісі немесе өлтіргісі келмейтіні рас па? Бәсекелестік пен DevOps қалай бағалануы керек?
Жарайды, бұл қандай жарыс туралы айтатынымызға байланысты. Бұл жұмыс орнындағы бәсекелестік немесе компаниялар арасындағы бәсекелестік туралы ма?
Қызметтер бәсекелестігі туралы, өйткені қызметтер бірнеше компания емес. Біз ақпараттық ортаның жаңа түрін жасап жатырмыз, кез келген орта бәсекесіз өмір сүре алмайды. Барлық жерде бәсекелестік бар.
Сол Netflix, біз оларды үлгі ретінде аламыз. Неліктен олар мұны ойлап тапты? Өйткені олар бәсекеге қабілетті болуы керек еді. Бұл икемділік пен қозғалыс жылдамдығы дәл бәсекеге қабілетті талап болып табылады; ол біздің жүйелерімізге хаос енгізеді. Яғни, хаос - біз оны қалағандықтан саналы түрде жасайтын нәрсе емес, бұл әлем оны талап еткендіктен болатын нәрсе. Біз жай ғана бейімделуіміз керек. Ал хаос, бұл бәсекелестіктің нәтижесі.
Бұл хаос - мақсаттың жоқтығын білдіре ме? Әлде біз көргіміз келмейтін мақсаттар ма? Біз үйдеміз және басқалардың мақсатын түсінбейміз. Бәсекелестік, шын мәнінде, біздің айқын мақсаттарымыз бар және біз әр келесі сәтте қайда болатынымызды білеміз. Бұл, менің көзқарасым бойынша, DevOps-тың мәні.
Сондай-ақ сұраққа қараңыз. Менің ойымша, бәріміздің мақсатымыз бір: аман қалу және онымен бірге істеу
ең үлкен қуаныш. Ал кез келген ұйымның бәсекелестік мақсаты бір. Тірі қалу көбінесе бәсекелестік арқылы жүзеге асады, сіз бұл туралы ештеңе істей алмайсыз.
Биылғы конференция 7 желтоқсанда Технополисте өтеді. Біз 11 қарашаға дейін есептер қабылдауға өтінімдерді қабылдаймыз. сөйлегіңіз келсе бізге.
Қатысушыларды тіркеу ашық, билеттер құны 7000 рубль. Бізге қосылыңыздар!
Ақпарат көзі: www.habr.com