DevOps и Chaos: доставка на софтуер в децентрализирания свят

Основателят и директор на "Otomato Software", един от инициаторите и инструкторите на първата DevOps сертификация в Израел, Антон Вайс, разказа на миналогодишното DevOpsDays Москва за теорията на хаоса и основните принципи на хаосната инженерия, както и обясни как изглежда идеалната DevOps организация на бъдещето.

Подготвихме текстова версия на доклада.

Добро утро!

DevOpsDays в Москва вече втора поредна година, аз за втори път на тази сцена, много от вас също вече са тук за втори път. Какво значи това? Това означава, че DevOps движението в Русия расте, множи се и най-важното, означава, че е време да поговорим за това какво всъщност е DevOps през 2018 година.

Повдигнете ръце тези, които мислят, че през 2018 година DevOps вече е професия? Има ли такива. Има ли в залата DevOps инженери, чийто служебен описания включва "DevOps инженер"? Има ли в залата DevOps мениджъри? Такива няма. DevOps архитекти? Също няма. Не е много. Наистина ли никой от вас не е написал, че е DevOps инженер?

Значи, повечето от вас мислят, че това е антипатерн? Че такава професия не трябва да съществува? Можем да мислим каквото си искаме, докато индустрията тържествено напредва под звуците на DevOps трубите.

Кой е чул за новата тема, наречена DevDevOps? Това е нова методика, която позволява ефективно сътрудничество между разработчиците и DevOps специалистите. Въпреки че не е съвсем нова. Ако съдим по Twitter, вече преди 4 години са започнали да говорят за това. И интересът към него нараства и нараства, което означава, че проблемът съществува. Проблемът трябва да бъде решен.

Ние сме творчески хора, трудно се успокояваме. Казваме: DevOps е недостатъчно обхватна дума, липсват му различни интересни елементи. И отиваме в нашите тайни лаборатории и започваме да създаваме любопитни мутации: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.

Логиката е ясна, нали? Имаме система за доставка, която не е функционална, системите ни са нестабилни и потребителите са недоволни, не успяваме да пускаме софтуера навреме, не се вписваме в бюджета. Как ще решим всичко това? Ще измислим нова дума! Тя ще завършва на "Ops" и проблемът е решен.

Така наричам този подход — "Ops, и проблемът е решен."

Всичко това излиза на заден план, когато си напомняме защо сме създали всичко това. Създадохме целия този DevOps, за да направим доставката на софтуер и собствената ни работа в този процес възможно най-безпроблемна, безболезнена, ефективна и, най-важното, приятна.

DevOps израсна от болка. И ни омръзна да страдаме. За да се осъществи всичко това, се основаваме на вечнозелени практики: ефективно сътрудничество, практики на потока и, най-важното, системно мислене, защото без него никакъв DevOps не работи.

Какво е система?

И ако говорим за системно мислене, нека си припомним какво е система.

Ако сте хакер-революционер, то за вас системата е очевидно зло. Това е облак, който надвисва над вас и ви принуждава да правите неща, които не искате.

От гледна точка на системното мислене, системата е цяло, което се състои от части. В този смисъл, всеки от нас е система. Организациите, в които работим, са системи. И това, което строим, се нарича система.

Всичко това е част от една голяма социотехнологична система. И само ако разберем как работи тази социотехнологична система заедно, тогава можем наистина да оптимизираме нещо в тази област.

От гледна точка на системното поведение, системата има различни интересни свойства. Първо, тя се състои от части, което означава, че поведението й зависи от поведението на частите. В същото време всички нейни части са взаимозависими. Така че, колкото повече части има системата, толкова по-трудно е да се разбере или предвиди поведението й.

От гледна точка на поведението, има и един интересен факт. Системата може да прави неща, които никоя от отделните й части не може да направи.

Както казва доктор Ръсел Аккоф (един от основоположниците на системното мислене), това е доста лесно да се докаже с помощта на мисловен експеримент. Например, кой в залата умее да пише код? Много ръце, и това е нормално, защото това е едно от основните изисквания за нашата професия. Вие умеете да пишете, но вашите ръце отделно от вас могат ли да пишат код? Има хора, които биха казали: «Не ръцете ми пишат код, а мозъкът ми пише код». А мозъкът може ли отделно от вас да пише код? Е, вероятно не.

Мозъкът е удивителна машина, не знаем дори 10% от това как функционира, но не може да работи независимо от системата, наречена нашето тяло. И това е лесно да се докаже: отворете черепа си, извадете мозъка, поставете го пред компютър и вижте дали може да напише нещо простичко. Например, „Hello, world“ на Python.

Ако системата може да извърши нещо, което нито една от частите ѝ не може да направи сама, това означава, че поведението ѝ не се определя от поведението на частите. А от какво тогава се определя? От взаимодействието между тези части. И съответно, колкото повече части има, толкова по-сложни са взаимодействията и толкова по-трудно е да се разбере и предвиди поведението на системата. И това я прави хаотична, защото всяка, дори най-незначителна, невидима за окото промяна в която и да е част от системата може да доведе до напълно непредсказуеми последствия.

Тази чувствителност към началните условия е открита и проучена за първи път от американския метеоролог Ед Лоренц. По-късно тя получава името „ефект на пеперудата“ и води до развитието на движение на научната мисъл, наречено „теория на хаоса“. Тази теория става един от основните парадигмални преврати в науката на 20-ти век.

Теория на хаоса

Хората, които се занимават с изследване на хаоса, се наричат хаосолози.

Истинската причина за това заседание е, че работейки със сложни разпределени системи и големи международни организации, в определен момент разбрах, че това е, каквото аз съм. Аз съм хаосолог. По същество това е хитроумно изразяване на усещането: „Не разбирам какво става тук и не знам какво да правя с това.“

Мисля, че много от вас също често се чувстват така, затова и вие сте хаосолози. Каня ви в гилдията на хаосолозите. Системите, които ще изучаваме заедно, скъпи колеги хаосолози, се наричат „сложни адаптивни системи“.

Какво е адаптивност? Адаптивността означава, че индивидуалното и колективното поведение на частите в такава адаптивна система се променя и самоорганизира в отговор на събития или вериги от микросъбития в системата. Тоест системата се адаптира към промените чрез самоорганизация. И тази способност за самоорганизация е основана на доброволно, напълно децентрализирано сътрудничество на свободни автономни агенти.

Още едно интересно свойство на такива системи е, че те са свободно мащабируеми. Това, което безспорно трябва да ни интересува като хаосолози-инженери. Така че, ако кажем, че поведението на сложна система се определя от взаимодействието между нейните части, какво трябва да ни интересува? Взаимодействието.

Има още две интересни извода.


На първо място, разбираме, че сложна система не може да бъде опростена чрез опростяване на частите й. На второ място, единственият начин да simplify сложна система е чрез опростяване на взаимодействията между частите й.

Как взаимодействаме? Ние всички сме части от една голяма информационна система, наречена човешко общество. Взаимодействаме чрез общ език, ако такъв имаме, и ако го намираме.

Но езикът сам по себе си е сложна адаптивна система. Съответно, за да взаимодействаме по-ефективно и лесно, трябва да създадем определени протоколи. Тоест, трябва да има последователност от символи и действия, които да направят обмена на информация между нас по-лесен, по-предсказуем и по-разбираем.

Искам да кажа, че тенденциите към усложняване, адаптивност, децентрализация и хаотичност могат да се наблюдават навсякъде. И в системите, които създаваме, и в системите, част от които сме.

И за да не бъда неубедителен, нека разгледаме как се променят системите, които създаваме.

Очаквахте тази дума, разбирам. Ние сме на конференция DevOps, днес тази дума ще звучи някъде стотици хиляди пъти и после ще ни се присъни през нощта.

Микросервизите са първата софтуерна архитектура, която възниква като реакция на практиките на DevOps, предназначена да направи нашите системи по-гъвкави, по-мащабируеми и да осигури непрекъсната доставка. Как го постига? Чрез намаляване на обема на услугите, стесняване на границите на проблемите, които тези услуги обработват, и съкращаване на времето за доставка. Тоест, намаляваме и опростяваме частите на системата, увеличаваме тяхното количество, което неизменно повишава сложността на взаимодействията между тези части, а именно възникват нови проблеми, които ние трябва да решим.

Микросервизите не са краят, те всъщност са вече вчерашния ден, тъй като идва Serverless. Всички сървъри изгоряха, няма повече сървъри, няма операционни системи, само чист код за изпълнение. Конфигурации отделно, състояние отделно, всичко се управлява чрез събития. Красота, чистота, тишина, няма събития, нищо не се случва, пълен ред.

Къде е сложността? Сложността, разбира се, е във взаимодействията. Колко една функция може да направи сама? Как взаимодействува с другите функции? Опашки от съобщения, бази данни, балансировачи. Как да възстановим някакво събитие, когато се случи срив? Много въпроси и малко отговори.

Микросервизите и Serverless са всичко, което ние, компютърните хипстери, наричаме Cloud Native. Всичко това е свързано с облака. Но облакът по същество също е ограничен в мащабируемостта. Привикнали сме да мислим за него като разпределена система. А всъщност, къде живеят сървърите на облачните доставчици? В дата центрове. Тоест, имаме известна централизирана, много ограничена разпределена модел.

Днес разбираме, че интернет на вещите вече не е само луксозни думи за това, че дори по скромните прогнози, през следващите пет до десет години ни очакват милиарди устройства, свързани с интернет. Огромно количество полезни и безполезни данни, които ще се стичат в облака и ще се изтеглят от облака.

Облакът няма да издържи, затова все повече говорим за това, което се нарича "периферни изчисления". Или пък на мен ми харесва чудесното определение "fog computing". То е обвито в мистика, романтизъм и загадъчност.

Мъгливи изчисления. Става въпрос за това, че облаците са централизирани струпвания на вода, пара, лед и камъни. А мъглата е капки вода, разпръснати около нас в атмосферата.

В мъгливата парадигма голяма част от работата се изпълнява от тези капки напълно автономно или в сътрудничество с други капки. Те се обръщат към облака само когато наистина е спешно.

Тоест отново децентрализация, автономност, и, разбира се, много от вас вече разбират накъде води всичко това, защото не може да се говори за децентрализация, без да се спомене блокчейн.

Има хора, които вярват, това са онези, които са инвестирали в криптовалута. Има и такива, които вярват, но се притесняват, като мен например. А има и такива, които не вярват. Мнението тук може да бъде различно. Има технология, ново неизяснено нещо, има и проблеми. Както всяка нова технология, тя поставя повече въпроси, отколкото да дава отговори.

Хайпът около блокчейн е разбираем. Дори и да отстраним златната лихорадка, самата технология обещава светло бъдеще: повече свобода, повече автономия, дистрибутирано глобално доверие. Какво да не искаме?

Съответно, все повече инженери по целия свят започват да разработват децентрализирани приложения. И това е сила, която не може да бъде игнорирана, просто казвайки: "Ааа, блокчейн е просто лошо имплементирана разпределена база данни". Или както скептиците обичат да казват: "За блокчейн няма реални приложения". Ако се замислим, преди 150 години те казваха същото за електричеството. И дори бяха прави по някакъв начин, защото това, което електричеството е способно да прави днес, през 19-ти век е било съвсем немислимо.

Между другото, кой знае какво представлява логото на екрана? Това е Hyperledger. Това е проект, разработван под егидата на The Linux Foundation, включващ набор от блокчейн технологии. Това наистина е силата на нашата общност с отворен код.

Хаотична инженерия

Така че, системата, която разработваме, става все по-сложна, все по-хаотична и все по-адаптивна. Netflix са пионери в микросервизните системи. Те бяха едни от първите, които разбраха това, и разработиха набор от инструменти, наречени Simian Army, от които най-известният е Chaos Monkey. Той определи това, което стана известно като „принципи на хаосна инженерия“.

Между другото, по време на работата върху доклада, дори преведохме този текст на руски, така че можете да посетите връзката, четете, коментирайте, критикувайте.

Накратко, принципите на хаосната инженерия говорят за следното. Сложните разпределени системи по същество са непредсказуеми и в тях винаги има грешки. Грешките са неизбежни, а това означава, че трябва да приемем тези грешки и да работим с тези системи по съвсем различен начин.

Ние трябва сами да се опитваме да внасяме тези грешки в нашите продукционни системи, за да тестваме нашите системи на тази адаптивност, на тази способност за самоорганизация и оцеляване.

И това променя всичко. Не само как пускаме системата в продукция, но и как я разработваме, как я тестваме. Няма процес на стабилизация, замразяване на кода, а напротив, има постоянен процес на дестабилизация. Опитваме се да убиваме системата и да видим, че тя продължава да оцеляват.

Протоколи за интеграция на разпределени системи

Съответно, това изисква от нашите системи да се променят. За да станат по-устойчиви, им трябват нови протоколи за взаимодействие между частите им. За да може тези части да се договарят и да достигат до някаква самоорганизация. Появяват се различни нови инструменти, нови протоколи, които наричам „протоколи за взаимодействие на разпределени системи“.

За какво говоря? Първо, проектът Opentracing. Някаква опит за създаване на общ протокол за разпределено проследяване, който е абсолютно незаменим инструмент за отстраняване на проблеми в сложни разпределени системи.

Следва — Open Policy Agent. Казваме, че не можем да предвидим какво ще се случи със системата, тоест, необходимо е да увеличим нейното наблюдаемост. Opentracing принадлежи към семейството на инструментите, които дават наблюдаемост на нашите системи. Но наблюдаемостта ни е необходима, за да определим дали системата се държи по начин, по който я очакваме, или не. Как да определим очакваното поведение? Чрез определяне на някаква политика, набор от правила. Проектът Open Policy Agent работи по определянето на този набор от правила за широк спектър: от достъп до разпределение на ресурси.

Както казахме, нашите системи стават все по-управляеми от събития. Serverless е прекрасен пример за управляеми от събития системи. За да можем да предаваме събития между системите и да ги проследяваме, ни трябва общ език, общ протокол за това как говорим за събитията и как ги предаваме помежду си. С това се занимава проектът на име Cloudevents.

Непрекъснатият поток от промени, който обгръща нашите системи, постоянно ги дестабилизира, представлява непрекъснат поток от софтуерни артефакти. За да можем да поддържаме този постоянен поток от промени, ни трябва общ протокол, чрез който да говорим за това какво представлява софтуерният артефакт, как е проверен, каква верификация е преминал. С това се занимава проектът на име Grafeas. Тоест общ протокол за метаданни на софтуерни артефакти.

И накрая, ако искаме нашите системи да бъдат напълно самостоятелни, адаптивни и самоорганизиращи се, трябва да им дадем правото на самоидентификация. Проектът на име spiffe точно с това се занимава. Той е също проект под егидата на Cloud Native Computing Foundation.

Всички тези проекти са млади, имат нужда от нашата любов, нашето тестване. Това е всичко с отворен код, нашето тестване, нашата имплементация. Те ни показват в каква посока се движи технологията.

Но DevOps никога не е бил основно за технологии, той винаги е бил основно за сътрудничество между хората. И съответно, ако искаме системите, които разработваме, да се променят, трябва да се променим и ние самите. Всъщност, ние вече се променяме, нямаме особено избор.

Има чудесна книга британска писателка на име Рейчъл Ботсман, в която тя пише за еволюцията на доверието през историята на човечеството. Тя казва, че първоначално, в примитивните общества, доверието е било локално, т.е. ние сме се доверявали само на хора, които познаваме лично.

След това имаше много дълъг период - тъмен период, когато доверието беше централизирано, когато започнахме да се доверяваме на хора, които не познаваме, въз основа на това, че принадлежим към една и съща обществена или държавна институция.

И ето какво виждаме в съвременния свят: доверието става все по-разпределено и децентрализирано, основано на свободата на информационните потоци и достъпността на информацията.

Ако се замислим, именно тази достъпност, която прави доверието възможно, я осъществяваме ние. Това означава, че трябва да се променят и нашите начини на сътрудничество, както и как го правим, тъй като централизираните йерархични ИТ-организации от стария тип спират да функционират. Те започват да изчезват.

Основи на DevOps-организациите

Идеалната DevOps-организация на бъдещето е децентрализирана, адаптивна система, съставена от автономни екипи, всеки от които включва автономни индивиди. Тези екипи са разпространени по целия свят, те си сътрудничат ефективно помежду си чрез асинхронна комуникация и високо прозрачни протоколи за обмен на информация. Много красиво, нали? Много красиво бъдеще.

Разбира се, всичко това е невъзможно без културни промени. Трябва да имаме трансформационно лидерство, лична отговорност, вътрешна мотивация.

Това е основата на DevOps-организациите: прозрачност на информацията, асинхронна комуникация, трансформационно лидерство, децентрализация.

Изгаряне

Системите, част от които сме ние и които изграждаме, стават все по-хаотични и на нас, хората, ни е трудно да се справим с тази мисъл, трудно е да се откажем от илюзията за контрол. Опитваме се да продължим да ги контролираме и често това води до изгаряне. Говоря от личен опит, и аз съм пострадал, също съм жертва на неочаквани сривове в продукцията.

Изгарянето настъпва, когато се опитваме да контролираме неща, които по същността си не подлежат на контрол. Когато изгорим, всичко губи смисъл, защото губим желание да правим нещо ново, заемаме защитна позиция и започваме да защитаваме онова, което имаме.

Инженерната професия, както често обичам да си напомням, е предимно творческа професия. Ако загубим желанието да създаваме нещо, ние се превръщаме в помощ, превръщаме се в прах. Хората изгарят, цели организации изгарят.

Според мен, само приемането на съзидателната сила на хаоса, само изграждането на сътрудничество по неговите принципи — това е, което ще ни помогне да не загубим доброто, което имаме в нашата професия.

Това, което ви пожелавам: да обичате работата си, да обичате това, което правим. Този свят се храни с информация и имаме честта да го храним. Нека изследваме хаоса, да бъдем хаосолози, да носим стойност, да създаваме нещо ново, а проблемите, както вече установихме, са неизбежни, и когато се появят, само ще кажем „Ops!“, и проблемът е решен.

Какво освен Chaos Monkey?

Всъщност, всички тези инструменти са толкова млади. Дори Netflix изграждаха инструменти за себе си. Създавайте инструменти за себе си. Четете принципите на хаосната инженерия и се съобразявайте с тях, а не се опитвайте да търсите други инструменти, които някой друг вече е изградил.

Опитайте се да разберете как вашите системи се повреждат и започнете да ги повреждате, за да видите как издържат на натиск. Това е на първо място. А инструментите могат да се потърсят. Има много проекти.

Не съвсем разбрах момента, когато говорехте за това, че системата не може да се опростява, като се опростяват нейните компоненти, и веднага преминахте към микросервизите, които именно опростяват системата чрез опростяване на самите компоненти, усложнявайки взаимодействията. Всъщност това са две части, които противоречат една на друга.

Точно така, микросервизите са много противоречиви теми изобщо. Всъщност, опростяването на части увеличава гъвкавостта. Какво осигуряват микросервизите? Те ни предлагат гъвкавост и бързина, но определено не ни дават простота. Те увеличават сложността.

Така че в философията на DevOps микросервизите не са чак толкова добро нещо?

Всяко добро има обратна страна. Има добро: увеличава гъвкавостта, дава ни възможност да правим промени по-бързо, но увеличава сложността и, съответно, крехкостта на цялата система.

На какво наистина трябва да се акцентира: на опростяването на взаимодействието или на опростяването на частите?

Определено акцентът е върху опростяване на взаимодействията, защото ако погледнем на това от гледна точка на работата, която вършим, на първо място, трябва да се обръща внимание на опростяването на взаимодействията, а не на опростяването на работата на всеки от нас поотделно. Защото опростяване на работата означава да се превърнем в роботи. В Макдоналдс това работи нормално, когато имаш предписано: тук сложи бургер, тук налей сос. Това не работи изобщо в нашата творческа работа.

Вярно ли е, че всичко, което споделихте, живее в свят без конкуренция, където хаосът е добър и няма противоречия в този хаос, никой не иска да изяде или убие никого? Как конкуренцията и DevOps трябва да съществуват?

Ами, зависи за каква конкуренция говорим. За конкуренция на работното място или между компаниите?

За конкуренцията на услугите, които съществуват, защото услугите не са просто няколко компании. Създаваме нов тип информационна среда, и всяка среда не може да съществува без конкуренция. Всякъде има конкуренция.

Същите Netflix, взимаме ги за ролев модел. Защо те го измислиха? Защото трябваше да бъдат конкурентоспособни. Тази гъвкавост и скорост на движение е именно това конкурентно изискване, което внася хаос в нашите системи. Тоест хаосът не е нещо, което правим съзнателно, защото го искаме, а е резултат от изискванията на света. Просто трябва да се адаптираме. И хаосът е резултат именно на конкуренцията.

Това значи, че хаосът е отсъствие на цели ли? Или цели, които не искаме да виждаме? Ние сме в уютна обстановка и не разбираме целите на другите. Конкуренцията всъщност е заради това, че имаме ясни цели и знаем накъде ще стигнем в следващия момент. В това, според мен, е същността на DevOps.

Също така, е един поглед на въпроса. Мисля, че нашата цел е една: да оцелеем и да направим това с
максимално удоволствие. И конкурентната цел на всяка организация е същата. Оцеляването често става в конкурентна борба, тук няма какво да се направи.

Тази година конференцията DevOpsDays Москва ще се проведе на 7 декември в "Технополиса". До 11 ноември приемаме заявки за доклади. Напишете на нас, ако искате да представите.

Регистрация за участници е отворена, билетът струва 7000 рубли. Присъединете се!

Източник: habr.com