DevOps и Хаос: Испорака на софтвер во децентрализиран свет

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

Подготвивме текстуална верзија на извештајот.

Добро утро!

DevOpsDays во Москва втора година по ред, ова е мојот втор пат на оваа сцена, многумина од вас се во оваа просторија по втор пат. Што значи тоа? Ова значи дека движењето DevOps во Русија расте, се размножува и што е најважно, значи дека дојде време да се зборува за тоа што е DevOps во 2018 година.

Крени раце кои мислат дека DevOps е веќе професија во 2018 година? Има такви. Дали има некои инженери DevOps во просторијата чиј опис на работното место вели „DevOps Engineer“? Дали има менаџери на DevOps во собата? Не постои таков. Архитекти на DevOps? Исто така бр. Недоволно. Дали е навистина точно дека никој не вели дека е инженер за DevOps?

Значи, повеќето од вас мислат дека ова е анти-шаблон? Дека таква професија не треба да постои? Можеме да размислуваме што сакаме, но додека размислуваме, индустријата свечено се движи напред кон звукот на трубата на DevOps.

Кој слушнал за нова тема наречена DevDevOps? Ова е нова техника која овозможува ефикасна соработка помеѓу програмерите и devops. И не толку ново. Судејќи по Твитер, тие веќе почнаа да зборуваат за ова пред 4 години. И до сега интересот за ова расте и расте, односно има проблем. Треба да се реши проблемот.

Ние сме креативни луѓе, не само што се смируваме. Велиме: DevOps не е доволно сеопфатен збор, сè уште му недостасуваат секакви различни, интересни елементи. И ние одиме во нашите тајни лаборатории и почнуваме да произведуваме интересни мутации: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.

Логиката е железна, нели? Нашиот систем за испорака не е функционален, нашите системи се нестабилни, а нашите корисници се незадоволни, немаме време да пуштаме софтвер навреме, не се вклопуваме во буџетот. Како ќе го решиме сето ова? Ќе смислиме нов збор! Ќе заврши со „Опс“ и проблемот е решен.

Така, јас го нарекувам овој пристап - „Оп, и проблемот е решен“.

Сето ова паѓа во втор план ако се потсетиме зошто го смисливме сето ова. Ја смисливме целата оваа работа на DevOps за да ја направиме испораката на софтвер и нашата сопствена работа во овој процес што е можно понепречено, безболно, ефикасно и што е најважно, попријатно.

DevOps порасна од болка. И ние сме уморни од страдање. И за да се случи сето ова, ние се потпираме на зимзелени практики: ефективна соработка, практики на проток и што е најважно, системско размислување, бидејќи без тоа ниту еден DevOps не функционира.

Што е системот?

И ако веќе зборуваме за системско размислување, да се потсетиме што е систем.

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

Од гледна точка на системското размислување, систем е целина која се состои од делови. Во оваа смисла, секој од нас е систем. Организациите во кои работиме се системи. А тоа што јас и ти го градиме се вика систем.

Сето ова е дел од еден голем социо-технолошки систем. И само ако разбереме како функционира овој социо-технолошки систем заедно, само тогаш ќе можеме вистински да оптимизираме нешто во ова прашање.

Од аспект на системско размислување, системот има различни интересни својства. Прво, се состои од делови, што значи дека неговото однесување зависи од однесувањето на деловите. Покрај тоа, сите негови делови се меѓусебно зависни. Излегува дека колку повеќе делови има еден систем, толку е потешко да се разбере или да се предвиди неговото однесување.

Од гледна точка на однесување, постои уште еден интересен факт. Системот може да направи нешто што ниту еден од неговите поединечни делови не може да го направи.

Како што рече д-р Расел Акоф (еден од основачите на системското размислување), тоа е прилично лесно да се докаже со мисловен експеримент. На пример, кој во собата знае да напише код? Има многу раце, и тоа е нормално, бидејќи ова е еден од главните барања за нашата професија. Дали знаете да пишувате, но дали вашите раце можат да пишуваат код одделно од вас? Има луѓе кои ќе речат: „Не се моите раце тие што го пишуваат кодот, мојот мозок е тој што го пишува кодот“. Дали вашиот мозок може да напише код одделно од вас? Па, веројатно не.

Мозокот е неверојатна машина, не знаеме ни 10% од тоа како функционира таму, но не може да функционира одвоено од системот што е нашето тело. И ова е лесно да се докаже: отворете го черепот, извадете го мозокот, ставете го пред компјутерот, нека се обиде да напише нешто едноставно. „Здраво, свет“ во Пајтон, на пример.

Ако системот може да направи нешто што ниту еден од неговите делови не може да го направи одделно, тогаш тоа значи дека неговото однесување не е одредено од однесувањето на неговите делови. Со што тогаш се одредува? Тоа е одредено од интеракцијата помеѓу овие делови. И соодветно, колку повеќе делови, колку покомплексни се интеракциите, толку е потешко да се разбере и предвиди однесувањето на системот. И ова го прави таквиот систем хаотичен, бидејќи секоја, дури и најнезначајната, невидлива промена во кој било дел од системот може да доведе до целосно непредвидливи резултати.

Оваа чувствителност на почетните услови првпат ја открил и проучувал американскиот метеоролог Ед Лоренц. Потоа, тој беше наречен „ефект на пеперутка“ и доведе до развој на движење на научната мисла наречено „теорија на хаосот“. Оваа теорија стана една од главните промени на парадигмата во науката во 20 век.

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

Луѓето кои го проучуваат хаосот се нарекуваат себеси хаосолози.

Всушност, причината за овој извештај беше тоа што работејќи со сложени дистрибуирани системи и големи меѓународни организации, во одреден момент сфатив дека тоа е она што го чувствувам. Јас сум хаосолог. Ова во основа е паметен начин да се каже: „Не разбирам што се случува овде и не знам што да правам во врска со тоа“.

Мислам дека и многумина од вас често се чувствуваат вака, па и вие сте хаозолози. Ве поканувам во еснафот на хаосолозите. Системите што вие и јас, драги колеги хаозолози, ќе ги проучуваме се нарекуваат „комплексни адаптивни системи“.

Што е приспособливост? Приспособливост значи дека индивидуалното и колективното однесување на деловите во таков адаптивен систем се менува и самоорганизира, одговарајќи на настани или синџири на микро-настани во системот. Односно, системот се прилагодува на промените преку самоорганизирање. И оваа способност за самоорганизирање се заснова на доброволна, целосно децентрализирана соработка на слободните автономни агенти.

Друга интересна карактеристика на таквите системи е тоа што тие се слободно скалабилни. Она што несомнено треба да не интересира нас, како хаозолози-инженери. Значи, ако рековме дека однесувањето на сложениот систем е одредено од интеракцијата на неговите делови, тогаш што треба да не интересира? Интеракција.

Има уште две интересни наоди.


Прво, разбираме дека сложениот систем не може да се поедностави со поедноставување на неговите делови. Второ, единствениот начин да се поедностави сложениот систем е со поедноставување на интеракциите помеѓу неговите делови.

Како да комуницираме? Ти и јас сме сите делови од голем информациски систем наречен човечко општество. Ние комуницираме преку заеднички јазик, ако го имаме, ако го најдеме.

Но самиот јазик е комплексен адаптивен систем. Според тоа, за поефикасно и поедноставно интеракција, треба да создадеме некакви протоколи. Односно, некаков редослед на симболи и дејства што ќе ја направат размената на информации меѓу нас поедноставна, попредвидлива, поразбирлива.

Сакам да кажам дека во сè може да се следат трендовите кон сложеност, кон приспособливост, кон децентрализација, кон хаос. И во системите што јас и ти ги градиме, и во тие системи од кои ние сме дел.

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

Го чекавте овој збор, разбирам. Ние сме на конференција на DevOps, денес овој збор ќе се слушне околу сто илјади пати, а потоа ќе го сонуваме ноќе.

Микросервисите се првата софтверска архитектура која се појави како реакција на практиките на DevOps, која е дизајнирана да ги направи нашите системи пофлексибилни, поскалабилни и да обезбеди континуирана испорака. Како таа го прави ова? Со намалување на обемот на услуги, намалување на обемот на проблеми кои овие услуги ги обработуваат, намалување на времето за испорака. Односно, ние ги намалуваме и поедноставуваме деловите од системот, го зголемуваме нивниот број и соодветно на тоа, комплексноста на интеракциите помеѓу овие делови непроменливо се зголемува, односно се појавуваат нови проблеми што треба да ги решиме.

Микросервисите не се крај, микросервисите се, генерално, веќе вчера, затоа што доаѓа без сервер. Сите сервери изгореа, нема сервери, нема оперативни системи, само чист извршен код. Конфигурациите се одвоени, состојбите се посебни, сè е контролирано од настани. Убавина, чистота, тишина, никакви настани, ништо не се случува, целосен ред.

Каде е сложеноста? Тешкотијата, се разбира, е во интеракциите. Колку една функција може да направи сама? Како е во интеракција со други функции? Редици за пораки, бази на податоци, балансери. Како да се рекреира некој настан кога се случил неуспех? Многу прашања и малку одговори.

Микроуслугите и без сервери се она што ние хипстерите ги нарекуваме Cloud Native. Се е до облакот. Но, облакот е исто така инхерентно ограничен во неговата приспособливост. Навикнати сме да го мислиме како дистрибуиран систем. Всушност, каде живеат серверите на давателите на облак? Во центрите за податоци. Односно, овде имаме еден вид централизиран, многу ограничен, дистрибуиран модел.

Денес разбираме дека Интернетот на нештата повеќе не е само големи зборови дека дури и според скромните предвидувања нè очекуваат милијарди уреди поврзани на Интернет во следните пет до десет години. Огромна количина на корисни и бескорисни податоци кои ќе се спојат во облакот и ќе бидат поставени од облакот.

Облакот нема да издржи, па сè почесто зборуваме за нешто што се нарекува раб компјутери. Или, исто така, ми се допаѓа прекрасната дефиниција за „пресметување со магла“. Таа е обвиткана во мистицизмот на романтизмот и мистеријата.

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

Во парадигмата за магла, најголемиот дел од работата ја вршат овие капки целосно автономно или во соработка со други капки. И тие се свртуваат кон облакот само кога навистина ќе бидат притиснати.

Тоа е, повторно децентрализација, автономија и, се разбира, многумина од вас веќе разбираат каде оди сето ова, бидејќи не можете да зборувате за децентрализација без да го споменете блокчејнот.

Има и такви кои веруваат, тоа се оние кои инвестирале во криптовалути. Има и такви кои веруваат, но се плашат, како мене на пример. А има и такви кои не веруваат. Овде можете да се однесувате поинаку. Има технологија, нова непозната материја, има проблеми. Како и секоја нова технологија, таа покренува повеќе прашања отколку што одговара.

Возбудата околу блокчејнот е разбирлива. Настрана златната треска, самата технологија носи извонредни ветувања за посветла иднина: повеќе слобода, поголема автономија, дистрибуирана глобална доверба. Што не треба да се сака?

Соодветно на тоа, се повеќе и повеќе инженери ширум светот почнуваат да развиваат децентрализирани апликации. И ова е моќ што не може да се отфрли со едноставно велејќи: „Ах, блокчејн е само лошо имплементирана дистрибуирана база на податоци“. Или како што сакаат да кажат скептиците: „Нема вистински апликации за блокчејн“. Ако размислите добро, пред 150 години истото го кажаа за струјата. И тие дури на некој начин беа во право, бидејќи она што електричната енергија го овозможува денес, во никој случај не беше возможно во 19 век.

Патем, кој знае какво лого има на екранот? Ова е Hyperledger. Ова е проект кој се развива под покровителство на Фондацијата Линукс и вклучува сет на блокчејн технологии. Ова е навистина силата на нашата заедница со отворен код.

Хаос инженеринг

Значи, системот што го развиваме станува се покомплексен, сè похаотичен и сè поприлагодлив. Нетфликс се пионери на микросервисните системи. Тие беа меѓу првите што го разбраа ова, тие развија збир на алатки што ги нарекоа Симска армија, од кои најпозната беше Хаос мајмун. Тој го дефинираше она што стана познато како „принципи на хаос инженеринг“.

Патем, во процесот на работа на извештајот, дури и го преведовме овој текст на руски, па одете на врска, читај, коментирај, кара.

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

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

И тоа менува сè. Не само како ги лансираме системите во производство, туку и како ги развиваме, како ги тестираме. Нема процес на стабилизација или замрзнување на кодот, напротив, има постојан процес на дестабилизација. Се обидуваме да го убиеме системот и да видиме дека тој продолжува да опстојува.

Дистрибуирани протоколи за системска интеграција

Според тоа, ова бара нашите системи некако да се променат. За да станат постабилни, потребни им се некои нови протоколи за интеракција помеѓу нивните делови. За да можат овие делови да се договорат и да дојдат до некакво самоорганизирање. И се појавуваат секакви нови алатки, нови протоколи, кои јас ги нарекувам „протоколи за интеракција на дистрибуирани системи“.

За што зборувам? Прво, проектот Отворена трага. Некои се обидуваат да создадат општ дистрибуиран протокол за следење, што е апсолутно незаменлива алатка за дебагирање на сложени дистрибуирани системи.

Понатаму - Отворете го агентот за политика. Ние велиме дека не можеме да предвидиме што ќе се случи со системот, односно треба да ја зголемиме неговата набљудуваност, набљудуваност. Opentracing припаѓа на фамилија на алатки кои даваат можност за набљудување на нашите системи. Но, ни треба набљудување за да утврдиме дали системот се однесува како што очекуваме или не. Како да го дефинираме очекуваното однесување? Со дефинирање на некаква политика, некаков збир на правила. Проектот Отворена политика Агент е посветен на дефинирање на овој сет на правила низ спектарот кој се движи од пристап до распределба на ресурси.

Како што рековме, нашите системи се повеќе се водени од настани. Без сервер е одличен пример за системи управувани од настани. За да можеме да пренесуваме настани помеѓу системи и да ги следиме, потребен ни е заеднички јазик, заеднички протокол за тоа како зборуваме за настаните, како ги пренесуваме еден на друг. Така се нарекуваше еден проект Cloudevents.

Постојаниот тек на промени што ги обзема нашите системи, постојано дестабилизирајќи ги, е континуиран прилив на софтверски артефакти. За да го одржиме овој постојан тек на промени, потребен ни е некој вид заеднички протокол преку кој можеме да зборуваме што е софтверски артефакт, како се тестира, каква верификација поминал. Така се нарекуваше еден проект Графеи. Односно, заеднички протокол за метаподатоци за софтверски артефакти.

И конечно, ако сакаме нашите системи да бидат целосно независни, адаптивни и самоорганизирани, мора да им дадеме право на самоидентификација. Повикан проект шпиф Токму тоа го прави. Ова е исто така проект под покровителство на Фондацијата Cloud Native Computing.

Сите овие проекти се млади, на сите им треба нашата љубов, нашата потврда. Сето ова е со отворен код, наше тестирање, наша имплементација. Тие ни покажуваат каде оди технологијата.

Но, DevOps никогаш не бил првенствено за технологија, туку отсекогаш бил за соработка меѓу луѓето. И, соодветно, ако сакаме да се променат системите што ги развиваме, тогаш ние самите мора да се промениме. Всушност, ние сепак се менуваме, немаме многу избор.

Постои прекрасен книга Британската писателка Рејчел Ботсман, во која пишува за еволуцијата на довербата низ историјата на човештвото. Таа вели дека првично, во примитивните општества довербата била локална, односно им верувавме само на оние што лично ги познававме.

Потоа имаше многу долг период - мрачно време кога довербата беше централизирана, кога почнавме да им веруваме на луѓе кои не ги познаваме врз основа на фактот дека припаѓаме на иста јавна или државна институција.

И ова е она што го гледаме во нашиот модерен свет: довербата станува се повеќе и повеќе дистрибуирана и децентрализирана, и таа се заснова на слободата на протокот на информации, на достапноста на информациите.

Ако размислите за тоа, токму оваа пристапност, што ја прави оваа доверба можна, е она што вие и јас го спроведуваме. Ова значи дека и начинот на кој соработуваме и начинот на кој го правиме тоа мора да се сменат, бидејќи централизираните, хиерархиски ИТ организации од старите повеќе не функционираат. Тие почнуваат да изумираат.

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

Идеалната организација на DevOps на иднината е децентрализиран, адаптивен систем составен од автономни тимови, од кои секој се состои од автономни поединци. Овие тимови се расфрлани низ светот, ефикасно соработуваат едни со други користејќи асинхрона комуникација, користејќи високо транспарентни протоколи за комуникација. Многу убава, нели? Многу убава иднина.

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

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

Изгори

Системите од кои сме дел и оние што ги градиме се сè похаотични, а на нас луѓето ни е тешко да се справиме со оваа мисла, тешко е да се откажеме од илузијата на контрола. Се трудиме да продолжиме да ги контролираме, а тоа често води до исцрпеност. Ова го кажувам од сопствено искуство, изгорев и јас, исто така бев онеспособен од непредвидени неуспеси во производството.

Исцрпеноста се јавува кога се обидуваме да контролираме нешто што е инхерентно неконтролирано. Кога ќе изгориме, сè го губи своето значење затоа што ја губиме желбата да направиме нешто ново, стануваме одбранбени и почнуваме да го браниме она што го имаме.

Инженерската професија, како што често сакам да се потсетувам, е пред се креативна професија. Ако ја изгубиме желбата да создадеме нешто, тогаш се претвораме во пепел, се претвораме во пепел. Изгоруваат луѓе, изгоруваат цели организации.

Според мене, само прифаќањето на креативната моќ на хаосот, само градењето соработка според неговите принципи е она што ќе ни помогне да не го изгубиме она што е добро во нашата професија.

Ова е она што ти посакувам: да си ја сакаш работата, да го сакаш тоа што го работиме. Овој свет се храни со информации, ние ја имаме честа да ги храниме. Затоа, ајде да го проучуваме хаосот, да бидеме хаосолози, да донесеме вредност, да создадеме нешто ново, добро, проблемите, како што веќе дознавме, се неизбежни, а кога ќе се појават, едноставно ќе кажеме „Опс!“ И проблемот е решен.

Што друго освен мајмун хаос?

Всушност, сите овие инструменти се толку млади. Истиот Нетфликс изгради алатки за себе. Изградете свои алатки. Прочитајте ги принципите на инженерството за хаос и живејте според тие принципи наместо да се обидувате да најдете други алатки што некој друг веќе ги изградил.

Обидете се да разберете како се распаѓаат вашите системи и почнете да ги распаѓате и видете како се држат. Ова е на прво место. И можете да барате алатки. Има секакви проекти.

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

Така е, микросервисите се многу контроверзна тема воопшто. Всушност, поедноставувањето на делови ја зголемува флексибилноста. Што обезбедуваат микросервисите? Тие ни даваат флексибилност и брзина, но секако не ни даваат едноставност. Ја зголемуваат тешкотијата.

Значи, во филозофијата DevOps, микросервисите не се толку добра работа?

Секое добро има и обратна страна. Придобивката е што ја зголемува флексибилноста, овозможувајќи ни да правиме промени побрзо, но ја зголемува сложеноста и оттаму кревкоста на целиот систем.

Сепак, што е поголем акцент: на поедноставување на интеракцијата или на поедноставување на делови?

Акцентот, се разбира, е на поедноставување на интеракциите, бидејќи ако на ова гледаме од гледна точка на тоа како работиме со вас, тогаш, пред сè, треба да обрнеме внимание на поедноставување на интеракциите, а не на поедноставување на работата. на секој од нас посебно. Бидејќи поедноставувањето на работата значи претворање во роботи. Овде во Мекдоналдс работи нормално кога имаш инструкции: овде ја ставаш плескавицата, овде ја преливаш со сосот. Ова воопшто не функционира во нашата креативна работа.

Дали е вистина дека сето она што го кажа живее во свет без конкуренција, а хаосот таму е толку љубезен, и нема противречности во овој хаос, никој не сака да јаде или да убие некого? Како треба да се одвиваат конкуренцијата и DevOps?

Па, зависи за каква конкуренција зборуваме. Дали се работи за конкуренција на работното место или за конкуренција меѓу компаниите?

За конкуренцијата на услуги кои постојат бидејќи услугите не се неколку компании. Создаваме нов тип на информациско опкружување и секоја средина не може да живее без конкуренција. Конкуренција има насекаде.

Истиот Нетфликс, ги земаме за пример. Зошто го смислија ова? Затоа што требаше да бидат конкурентни. Оваа флексибилност и брзина на движење е токму конкурентниот услов што воведува хаос во нашите системи. Односно, хаосот не е нешто што свесно го правиме затоа што го сакаме, тоа е нешто што се случува затоа што светот го бара тоа. Треба само да се прилагодиме. А хаосот, тоа е токму резултат на конкуренцијата.

Дали ова значи дека хаос е отсуството на голови, како што беше? Или оние цели што не сакаме да ги видиме? Ние сме во куќата и не ги разбираме целите на другите. Конкуренцијата, всушност, се должи на тоа што имаме јасни цели и знаеме каде ќе стигнеме во секој нареден момент. Ова, од моја гледна точка, е суштината на DevOps.

Исто така, погледнете го прашањето. Мислам дека сите имаме иста цел: да преживееме и да го направиме тоа со
најголемо задоволство. И конкурентната цел на секоја организација е иста. Опстанокот често се случува преку конкуренција, не можете ништо да направите за тоа.

Конференцијата оваа година DevOpsDays Москва ќе се одржи на 7 декември во Технополис. Пријавите за пријави примаме до 11 ноември. Напиши нас ако сакате да зборуваме.

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

Извор: www.habr.com