Основателят и директор на «Otomato Software», един от инициаторите и инструкторите на първата в Израел DevOps сертификация, Антон Вайс, говори за миналогодишния теория на хаоса и основните принципи на хаосната инженерия, а също така обясни как функционира идеалната DevOps организация на бъдещето.
Подготвихме текстова версия на доклада.
Добро утро!
DevOpsDays в Москва за втори пореден път, аз за втори път на тази сцена, много от вас за втори път в тази зала. Какво означава това? Това означава, че DevOps движението в Русия расте, разраства се, и най-важното, означава, че е време да говорим за това какво представлява DevOps през 2018 година.
Повдигнете ръце онези, които смятат, че през 2018 година DevOps е вече професия? Има такива. Има ли в залата DevOps инженери, които имат в описанието на длъжността си написано «DevOps инженер»? Има ли в залата DevOps мениджъри? Такова няма. DevOps архитекти? Също няма. Малковато е. Наистина ли никой не си има написано, че е DevOps инженер?
Значи, повечето от вас считат, че това е антипаттерн? Че такава професия не би трябвало да съществува? Можем да мислим каквото си искаме, а докато мислим, индустрията тържествено се движи напред под звуците на DevOps трубы.
Кой е чувал за новата тема наречена DevDevOps? Това е такава нова методология, която позволява ефективно сътрудничество между разработчиците и девопсите. Всъщност не е такова ново. Ако съдим по твитър, 4 години назад вече са започнали да говорят за това. И до днес интересът към нея расте и расте, тоест проблемът си е тук. Проблемът трябва да бъде решен.
Ние сме творчески хора, не се успокояваме лесно. Казваме: DevOps е недостатъчно широкообхватна дума, не й достига разнообразие от интересни елементи. И отиваме в нашите тайни лаборатории и започваме да създаваме любопитни мутации: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Логиката е железна, нали? Нашата система за доставка не е функционална, нашите системи са нестабилни и потребителите недоволстват, не успяваме да пускаме софтуера навреме, не се ук fitваме в бюджета. Как ще решим всичко това? Ще измислим нова дума! Тя ще свършва на «Ops» и проблемът ще бъде решен.
Така наричам този подход — «Ops, и проблемът е решен».
Всичко останало на заден план, когато напомняме на себе си защо сме създали всичко това. Създадохме целия този DevOps, за да направим доставката на софтуер и собствената си работа в този процес максимално безпрепятствена, безболезнена, ефективна и, най-важното, приятна.
DevOps е израстнал от болка. Омръзна ни да търпим. За да се случи всичко това, се основаваме на вечнозелени практики: ефективно сътрудничество, практики на поток и, най-вече, системно мислене, защото без него DevOps не работи.
Какво е система?
Ако вече заговорихме за системно мислене, нека си припомним какво е система.
Ако си хакер-революционер, то за теб системата е недвусмислено зло. Това е облак, който надвиса над теб и те кара да правиш неща, които не искаш.
От гледна точка на системното мислене, системата е цяло, което се състои от части. В този смисъл, всеки от нас е система. Организациите, в които работим, са системи. И това, което изграждаме, се нарича система.
Всичко това е част от една голяма социотехнологична система. И само когато разберем как тази социотехнологична система работи заедно, ще можем да оптимизираме нещо истински.
От гледна точка на системното мислене, системата има различни интересни свойства. На първо място, тя се състои от части, което означава, че поведението ѝ зависи от поведението на частите. Освен това, всички нейни части също са взаимозависими. Получава се, че колкото повече части има системата, толкова по-сложно е да разберем или предскажем поведението ѝ.
От гледна точка на поведението, тук има още един интересен факт. Системата може да прави нещо такова, което нито една от нейните отделни части не може да направи.
Както казва доктор Ръсел Акоз, един от основателите на системното мислене, това е лесно доказуемо чрез мисловен експеримент. Например, кой в залата умее да пише код? Много ръце, и това е нормално, защото това е едно от основните изисквания за нашата професия. Вие умеете да пишете, а ръцете ви отделно от вас могат ли да пишат код? Има хора, които биха казали: "Не ръцете пишат код, а моят мозък пише код". А може ли мозъкът да пише код отделно от вас? Най-вероятно не.
Мозъкът е удивителна машина, ние не знаем дори 10% от начина, по който работи, но той не може да функционира отделно от системата, на която е част — нашия организъм. И това лесно се доказва: отворете черепната си кутия, извадете мозъка и го поставете пред компютър, нека се опита да напише нещо просто. Например, "Hello, world" на Python.
Ако системата може да направи нещо, което нито една от частите й не може да направи сама, това означава, че поведението й не се определя от поведението на частите. А от какво тогава се определя? То се определя от взаимодействията между тези части. И съответно, колкото повече части има, толкова по-сложни са взаимодействията, а колкото по-сложни са взаимодействията, толкова по-трудно е да се разбере и предвиди поведението на системата. И това я прави хаотична, защото дори най-незначителната, невидима за окото промяна в която и да е част от системата може да доведе до съвсем непредсказуеми резултати.
Тази чувствителност към началните условия беше открита и изследвана за първи път от американския метеоролог Ед Лорънс. Впоследствие тя получи името „ефект на пеперудата“ и доведе до развитието на интелектуално течение, наречено „теория на хаоса“. Тази теория стана един от основните парадигмени преходи в науката на 20-ти век.
Теория на хаоса
Хората, които се занимават с изучаването на хаоса, се наричат хаосолози.
Самата причина за този доклад е, че работейки със сложни разпределени системи и големи международни организации, в един момент осъзнах, че това е, какъвто се чувствам. Аз съм хаосолог. Това е всъщност хитроумен начин да кажа: „Не разбирам какво става тук и не знам какво да правя с това.“
Мисля, че много от вас също често се чувстват по този начин, така че и вие сте хаосолози. Каня ви в гилдията на хаосолозите. Системите, които ние, скъпи колеги хаосолози, ще изучаваме, се наричат „сложни адаптивни системи“.
Какво е адаптивност? Адаптивността означава, че индивидуалното и колективното поведение на частите в такава адаптивна система се променя и самоорганизира, реагирайки на събития или вериги от микросъбития в системата. Тоест, системата се адаптира към промените чрез самоорганизация. И тази способност за самоорганизация е основана на доброволно, напълно децентрализирано сътрудничество на свободни автономни агенти.
Още една интересна характеристика на такива системи е, че те са свободно мащабируеми. Това е нещо, което трябва да ни интересува като хаосолози-инженери. И така, ако казахме, че поведението на сложната система се определя от взаимодействието на нейните части, какво трябва да ни интересува? Взаимодействието.
Има още две интересни заключения.
На първо място, разбираме, че сложната система не може да бъде опростена чрез опростяване на нейните части. На второ място, единственият начин да опростим сложната система е чрез опростяване на взаимодействията между нейните части.
Как взаимодействаме? Всички ние сме части от голямата информационна система, наречена човешко общество. Взаимодействаме чрез общ език, ако имаме такъв, ако го намерим.
Но езикът сам по себе си е сложна адаптивна система. Следователно, за да взаимодействаме по-ефективно и лесно, е необходимо създаването на определени протоколи. Тоест, трябва да имаме определена последователност от символи и действия, които да направят обмена на информация между нас по-прост, по-предсказуем и по-разбираем.
Искам да кажа, че тенденциите към усложняване, адаптивност, децентрализация и хаотичност могат да бъдат проследени навсякъде. Както в системите, които изграждаме, така и в системите, част от които сме.
И за да не бъда голословен, нека да разгледаме как се променят системите, които създаваме заедно.
Чакахте това слово, разбирам. Ние сме на DevOps конференция, днес това слово ще се чуе около сто хиляди пъти и после ще ни се присъни през нощта.
Микросервисите са първата софтуерна архитектура, която възникна като реакция на практиките DevOps, целяща да направи нашите системи по-гъвкави, по-мащабируеми и да осигури непрекъсната доставка. Как го прави? Чрез намаляване на обема на услугите, ограничаване на границите на проблемите, които тези услуги обработват, и намаляване на времето за доставка. Тоест, ние намаляваме и опростяваме частите на системата, увеличаваме тяхното количество, съответно, неизменно се увеличава сложността на взаимодействията между тези части, тоест възникват нови проблеми, които трябва да решаваме.
Микросервизите не са края, те всъщност са вече от вчера, защото идва Serverless. Всички сървъри изгори, няма сървъри, няма операционни системи, само чист код за изпълнение. Конфигурации отделно, състояния отделно, всичко се управлява чрез събития. Красота, чистота, тишина, няма събития, нищо не се случва, пълен ред.
Къде е сложността? Сложността, разбира се, е във взаимодействията. Колко може да направи една функция сама по себе си? Как взаимодейства с другите функции? Опашки за съобщения, бази данни, балансьори. Как да възпроизведем събитие, когато се е случил срив? Много въпроси и малко отговори.
Микросервизите и Serverless са всичко, което ние, компютърните хипстъри, наричаме Cloud Native. Всичко е за облака. Но облакът по същество също е ограничен в мащабируемостта. Привикнали сме да мислим за него като разпределена система. Всъщност, къде живеят сървърите на облачните доставчици? В дата центрове. Тоест тук имаме нещо централизирано, много ограничено, разпределена модел.
Днес разбираме, че интернет на нещата не е само гласно изказване за това, че дори по скромни прогнози, в близките пет-десет години ни очакват милиарди устройства, свързани с интернет. Огромно количество полезни и безполезни данни, които ще се изливат в облака и ще се изтеглят от облака.
Облакът няма да издържи, затова все повече говорим за това, което наричаме "периферни изчисления". Или ми харесва прекрасно определение "fog computing". То е обвито в мистиката на романтизма и загадъчността.
Мъгливи изчисления. Става въпрос за това, че облаците са централизирани скупчвания на вода, пара, лед и камъни. А мъглата – това са капки вода, разпръснати около нас в атмосферата.
В мъгливата парадигма, по-голямата част от работата се извършва от тези капки напълно автономно или в сътрудничество с други капки. Те се обръщат към облака само когато наистина е наложително.
Тоест, отново децентрализация, автономност и, разбира се, много от вас вече разбират накъде води всичко това, защото не може да се говори за децентрализация, без да се спомене блокчейн.
Има хора, които вярват, това са тези, които са инвестирали в криптовалута. Има и такива, които вярват, но се страхуват, като мен, например. А има и такива, които не вярват. Отношението може да бъде различно. Има технология, ново неразбрано дело, има проблеми. Както всяка нова технология, тя повдига повече въпроси, отколкото дава отговори.
Хайпът около блокчейна е разбираем. Дори да оставим настрана златната треска, самата технология предлага чудесни обещания за светло бъдеще: повече свобода, повече автономия, разпределено глобално доверие. Какво не би искал?
Съответно, все повече инженери по целия свят започват да разработват децентрализирани приложения. И това е сила, от която не може просто да се отхвърли с думите: "Ааа, блокчейнът е просто слабо реализирана разпределена база данни". Или както скептиците обичат да казват: "Няма реални приложения за блокчейн". Ако се замислим, преди 150 години те също говореха същото за електричеството. И дори в някои отношения бяха прави, защото това, което електричеството прави днес, в 19-ти век беше напълно непостижимо.
Между другото, кой знае какво е логото на екрана? Това е Hyperledger. Това е проект, който се разработва под егидата на The Linux Foundation и включва набор от блокчейн технологии. Това е истинската сила на нашата общност с отворен код.
Хаосна инженерия
Така че, системата, която разработваме, става все по-сложна, все по-хаотична, все по-адаптивна. Netflix са пионери в микросервисните системи. Те бяха едни от първите, които го осъзнаха, и разработиха набор от инструменти, който нарекоха Simian Army, най-известният от които е . Той определи това, което стана известно като .
Между другото, в процеса на работа по доклада, ние дори преведохме този текст на български, така че можете да се запознаете по , чете, коментирайте, критикувайте.
Накратко, принципите на хаоса в инженерството говорят следното. Сложните разпределени системи в същността си са непредсказуеми и в тях непременно има грешки. Грешките са неизбежни, а това означава, че трябва да приемем тези грешки и да работим с тези системи по съвсем различен начин.
Трябва сами да се опитваме да внасяме тези грешки в нашите производствени системи, за да тестваме системите си за тази адаптивност, за тази способност за самоорганизиране, за оцеляване.
И това променя всичко. Не само начина, по който стартираме системата в продукция, но и начина, по който я разработваме и тестваме. Няма никакъв процес на стабилизиране, замразяване на кода, напротив, има постоянен процес на дестабилизиране. Опитваме се да убиваме системата и да видим как тя продължава да оцелял.
Протоколи за интеграция на разпределени системи
Съответно, това изисква от нашите системи да се променят. За да станат по-устойчиви, им трябват нови протоколи за взаимодействие между техните части. За да могат тези части да се споразумяват и да постигат някаква самоорганизация. Появяват се различни нови инструменти, нови протоколи, които аз наричам „протоколи за взаимодействие на разпределени системи“.
За какво говоря? На първо място, проектът . Някаква опит да се създаде общ протокол за разпределено проследяване, който е съвсем незаменим инструмент за отстраняване на грешки в сложни разпределени системи.
Нататък — . Казваме, че не можем да предвидим какво ще се случи със системата, тоест е необходимо да повишим нейната видимост. Opentracing е част от семейството на инструментите, които предоставят видимост на нашите системи. Но видимост ни е нужна, за да определим дали системата се държи така, както очакваме, или не. Как да определим очакваното поведение? Чрез определяне на някаква политика, някакъв набор от правила. Проектът Open Policy Agent се занимава с определянето на този набор от правила по широк спектър: от достъп до разпределение на ресурси.
Както казахме, нашите системи стават все по-управляеми от събития. Serverless е чудесен пример за системи, управлявани от събития. За да можем да предаваме събития между системите и да ги проследяваме, ни е необходим общ език, общ протокол за това как разговаряме за събитията и как си ги предаваме. С това се занимава проектът .
Непрекъснатият поток от промени, който залива нашите системи и постоянно ги дестабилизира, е непрекъснат поток от софтуерни артефакти. За да можем да поддържаме този постоянен поток от промени, ни е необходим общ протокол, чрез който можем да разговаряме какво представлява софтуерният артефакт, как е проверен и каква верификация е преминал. С това се занимава проектът . Тоест общ протокол за метаданни на софтуерни артефакти.
И накрая, ако искаме нашите системи да бъдат напълно самостоятелни, адаптивни и самоорганизиращи, трябва да им дадем правото на самоидентификация. Проектът точно това прави. Той също е проект под егидата на Cloud Native Computing Foundation.
Всички тези проекти са млади, те се нуждаят от нашата любов и проверка. Всичко е с отворен код, нашето тестване, нашата имплементация. Те ни показват в каква посока се движи технологията.
Но DevOps никога не е бил преди всичко за технологията, той винаги е бил за сътрудничество между хората. Следователно, ако искаме системите, които разработваме, да се променят, трябва да се променим и ние. Всъщност, ние вече се променяме, нямаме особено избор.
Има чудесна британска писателка Рейчъл Ботсман, която пише за еволюцията на доверието в човешката история. Тя казва, че първоначално, в примитивните общества, доверието е било локално, тоест ние сме вярвали само на тези, които познаваме лично.
След това имаше много дълъг период — тъмен период, когато доверието беше централно, когато започнахме да вярваме на хора, които не познаваме, на основание, че принадлежим на един и същ социален или държавен институт.
И ето, което виждаме в съвременния свят: доверието става все повече разпределено и децентрализирано, основава се на свободата на информационните потоци и достъпността на информацията.
Ако се замислите, именно тази достъпност, която прави това доверие възможно, ние осъществяваме. Това означава, че трябва да се променят и начините, по които сътрудничим, и начините, по които го правим, защото централизирани иерархични IT организации от старото поколение престават да функционират. Те започват да отмират.
Основи на DevOps организации
Идеалната DevOps организация на бъдещето е децентрализирана, адаптивна система, състояща се от автономни екипи, всеки от които се състои от автономни индивиди. Тези екипи са разпръснати по целия свят, те ефективно сътрудничат помежду си чрез асинхронна комуникация, благодарение на високо прозрачни протоколи за обмен на информация. Много красиво, нали? Много красиво бъдеще.
Разбира се, всичко това е невъзможно без културни промени. Трябва да имаме трансформационно лидерство, лична отговорност и вътрешна мотивация.
Ето това е основата на DevOps организациите: прозрачност на информацията, асинхронна комуникация, трансформационно лидерство, децентрализация.
Изгаряне
Системите, част от които сме ние, и тези, които изграждаме, стават все по-хаотични, и на нас, хората, е трудно да се справим с тази мисъл, трудно е да се откажем от илюзията за контрол. Опитваме се да продължим да ги контролираме, и това често води до изгаряне. Казвам го от опит, и аз съм се изгарял, също съм жертва на непредвидими неуспехи в продукция.
Изгарянето настъпва, когато опитваме да контролираме неща, които по своята същност не подлежат на контрол. Когато изгаряме, всичко губи смисъл, защото губим желание да създаде нещо ново, влизаме в защитна позиция и започваме да защитаваме това, което имаме.
Инженерната професия, както често обичам да си напомням, е преди всичко творческа професия. Ако загубим желание да създаваме нещо, превръщаме се в пепел, превръщаме се в зола. Хората изгарят, цели организации изгарят.
Според мен, само приемането на съзидателната сила на хаоса, само изграждането на сътрудничество на неговите принципи — това е, което ще ни помогне да не загубим всичко хубаво, което има в нашата професия.
Това, което ви пожелавам: да обичате работата си, да обичате това, което правим. Този свят се храни с информация, и ние имаме честта да го храним. Така че да изследваме хаоса, да станем хаосолози, да носим стойност, да създаваме нещо ново, а проблемите, както вече установихме, са неизменни, и когато се появят, просто ще кажем "Ops!", и проблемът е решен.
Какво има освен Chaos Monkey?
Всъщност, всички тези инструменти са толкова млади. Netflix също създава инструменти за себе си. Създавайте инструменти за себе си. Четете принципите на хаосната инженерия и ги спазвайте, а не се опитвайте да търсите други инструменти, които някой друг вече е построил.
Опитайте се да разберете как вашите системи се провалят и започнете да ги нарушавате и да наблюдавате как устояват на ударите. Това е най-важното. Инструментите могат да се търсят. Има всякакви проекти.
Не разбрах точно моментa, когато говорихте за това, че системата не може да се опростява, опростявайки нейните компоненти, и веднага преминахте към микросервизи, които именно опростяват системата чрез опростяване на самите компоненти и усложнява взаимодействията. Това по същество са две части, които си противоречат.
Точно така, микросервизите са много противоречива тема. Всъщност, опростяването на частите повишава гъвкавостта. Какво дават микросервизите? Те ни дават гъвкавост и бързина, но определено не ни дават простота. Те повишават сложността.
Тоест в философията на DevOps микросервизите не са чак такова благо?
Всяко благо има своята тъмна страна. Има благо: то увеличава гъвкавостта, дава ни възможност да правим промени по-бързо, но увеличава сложността и съответно крехкостта на цялата система.
Все пак на какво повече се акцентира: на опростяване на взаимодействието или на опростяване на частите?
Фокусирайки се върху опростяване на взаимодействията, защото когато разгледаме как работим заедно, основното внимание трябва да бъде насочено към опростяване на взаимодействията, а не на опрощаване на работата на всеки отделно. Защото опростяването на работата означава да се превърнем в роботи. В Макдоналдс това работи добре, тъй като имаш указание: сложи бургер тук, налей соса тук. Но в нашата креативна работа това въобще не работи.
Верно ли е, че всичко, което разказахте, съществува в свят без конкуренция, където хаосът е добър и няма противоречия в него, а никой не иска да изяде или убие другия? Как конкуренцията и DevOps трябва да съществуват?
Ами, зависи за каква конкуренция говорим. За конкуренцията на работното място или за конкуренцията между компаниите?
За конкуренцията на услугите, които съществуват, защото услугите не са само няколко компании. Създаваме нов тип информационна среда, и всяка среда не може да съществува без конкуренция. Конкуренцията е навсякъде.
Вземайки за пример Netflix, те го измислиха по каква причина? Защото имаше нужда да бъдат конкурентоспособни. Тази гъвкавост и скорост на движение е точно това конкурентно изискване, което внася хаотичност в нашите системи. Тоест, хаосът не е нещо, което умишлено правим, защото го искаме, а това, което се случва поради изискванията на света. Просто трябва да се адаптираме. И хаосът е резултат от конкуренцията.
Това означава, че хаосът е отсъствие на цели? Или целите, които не искаме да виждаме? Ние сме в къщичка и не разбираме целите на другите. Конкуренцията всъщност е в това, че имаме ясни цели и знаем къде ще пристигнем всеки следващ момент. Според мен, това е същността на DevOps.
Също така е едно гледище. Мисля, че целта на всички ни е една: да оцелеем и да го правим с
най-голямо удоволствие. И конкурентната цел на всяка организация е същата. Оцеляването често се случва в конкурентна борба, тук нищо не може да се направи.
Тази година конференцията ще се проведе на 7 декември в 'Технополис'. До 11 ноември приемаме предложения за доклади. ни, ако искате да говорите.
Регистрацията за участниците е отворена, билетът струва 7000 рубли. Присъединете се!
Източник: habr.com
