Засновник та директор «Otomato Software», один із ініціаторів та інструкторів першої в Ізраїлі DevOps-сертифікації Антон Вайс розповів минулого року про теорію хаосу та головні принципи хаосної інженерії, а також пояснив, як влаштовано ідеальну DevOps-організацію майбутнього.
Ми підготували текстову версію доповіді.
Доброго ранку!
DevOpsDays в Москві другий рік поспіль, я вдруге на цій сцені, багато хто з вас вдруге в цьому залі. А що це означає? Це означає, що DevOps-рух у Росії зростає, множиться, а головне, це означає, що настав час поговорити про те, що таке DevOps у 2018 році.
Підніміть руки ті, хто вважає, що в 2018 році DevOps — це вже професія? Є такі. Чи є в залі DevOps-інженери, у кого в описі посади написано «DevOps-інженер»? Чи є в залі DevOps-менеджери? Таких немає. DevOps-архітектори? Теж немає. Замало. Що дійсно ні в кого не написано, що він DevOps-інженер?
Значить, більшість із вас вважає, що це антипаттерн? Що такої професії не повинно бути? Думати ми можемо все, що завгодно, а поки що ми думаємо, індустрія урочисто рухається вперед під звуки DevOps-труби.
Хто чув про нову тему, яка називається DevDevOps? Це така нова методика, яка дозволяє забезпечити ефективну співпрацю між розробниками та девопсами. Причому не така нова. Якщо судити з твіттера, то 4 роки тому вже почали про це розмовляти. І досі інтерес до цього зростає та зростає, тобто проблема є. Проблему треба вирішувати.
Ми люди творчі, то просто не заспокоюємося. Ми говоримо: DevOps - це недостатньо всеосяжне слово, там не вистачає ще всякого різного, цікавих елементів. І ми йдемо у свої секретні лабораторії та починаємо плодити цікаві мутації: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Логіка залізна, так? У нас система доставки не функціональна, у нас системи нестабільні та користувачі незадоволені, ми не встигаємо викочувати програмне забезпечення вчасно, не вкладаємося до бюджету. Як ми все це вирішуватимемо? Ми вигадаємо нове слово! Воно буде закінчуватися на 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, найвідомішим з яких став . Він визначив те, що стало відомо як .
До речі, у процесі роботи над доповіддю ми навіть переклали цей текст російською мовою, тож заходьте по , читайте, коментуйте, лайте.
Коротко принципи хаосної інженерії свідчать про таке. Складні розподілені системи за своєю суттю непередбачувані, і за своєю суттю в них є помилки. Помилки неминучі, а це означає, що нам потрібно ці помилки прийняти та працювати з цими системами зовсім по-іншому.
Ми повинні самі намагатися вносити ці помилки в наші продакшн системи, щоб відчувати наші системи на цю саму адаптивність, на цю здатність до самоорганізації, до виживання.
І це змінює все. Не тільки те, як ми запускаємо систему в продакшн, а й як ми їх розробляємо, як ми їх тестуємо. Немає жодного процесу стабілізації, заморожування коду, навпаки, є постійний процес дестабілізації. Ми намагаємося вбити систему та побачити, що вона продовжує виживати.
Distributed System Integration Protocols
Відповідно це вимагає від наших систем, щоб вони теж якось змінилися. Для того, щоб вони стали більш стійкими, їм потрібні деякі нові протоколи взаємодії між їх частинами. Щоб ці частини могли домовлятися та приходити до якоїсь самоорганізації. І виникають різні нові інструменти, нові протоколи, які я так і називаю «протоколи взаємодії розподілених систем».
Про що я говорю? По-перше, проект . Якась спроба створити загальний протокол розподіленого відстеження, який є незамінним інструментом для налагодження складних розподілених систем.
Далі . Ми говоримо, що ми не можемо передбачити те, що станеться із системою, тобто нам необхідно підвищити її observability, спостережуваність. Opentracing відноситься до сім'ї інструментів, що дають спостереження наших систем. Але спостережуваність нам потрібна для того, щоб визначити, чи поводиться система так, як ми від неї очікуємо, чи ні. Як нам визначити очікувану поведінку? За рахунок визначення в ній якоїсь політики, якогось склепіння правил. Проект Open Policy Agent займається визначенням цього зводу правил широкого спектру: від доступу до розміщення ресурсів.
Як ми сказали, наші системи все більш подієво керовані. Serverless - це чудовий приклад систем, що подієво керуються. Для того, щоб ми могли передавати події між системами та відстежувати їх, нам потрібна якась спільна мова, якийсь загальний протокол того, як ми розмовляємо про події, як ми їх передаємо один одному. Цим займається проект під назвою .
Безперервний потік змін, який омиває наші системи, постійно дестабілізуючи їх, це безперервний потік програмних артефактів. Для того, щоб ми могли підтримувати цей постійний потік змін, нам потрібен спільний протокол, за допомогою якого ми зможемо говорити про те, що таке програмний артефакт, як він перевірений, яку верифікацію він пройшов. Цим займається проект під назвою . Тобто, загальний протокол метаданих програмних артефактів.
І, нарешті, якщо ми хочемо, щоб наші системи були повністю самостійними, адаптивними, самоорганізовувалися, ми повинні дати їм право на самоідентифікацію. Проект під назвою саме цим займається. Це також проект під егідою Cloud Native Computing Foundation.
Всі ці проекти молоді, їм усім потрібне наше кохання, наша перевірка. Це все відкритий код, наше тестування, наша імплементація. Вони показують нам, у який бік рухається технологія.
Але DevOps ніколи не був насамперед про технологію, насамперед він завжди був про співпрацю між людьми. І, відповідно, якщо ми хочемо, щоб системи, які ми розробляємо, змінилися, то маємо змінитися ми самі. Насправді, ми і так змінюємося, у нас немає особливого вибору.
Є чудова британської письменниці Рейчел Ботсман, де вона пише про еволюцію довіри протягом людської історії. Вона каже, що спочатку, у первісних суспільствах, довіра була локальною, тобто ми довіряли лише тим, кого ми знаємо особисто.
Далі був дуже довгий період — темний час, коли довіра була централізована, коли ми почали довіряти людям, яких ми не знаємо на підставі того, що ми з ними належимо до одного громадського чи державного інституту.
І ось, що ми бачимо в нашому сучасному світі: довіра стає все більш розподіленою та децентралізованою, і заснована вона на свободі інформаційних потоків, на доступності інформації.
Якщо вдуматися, то цю саму доступність, яка робить цю довіру можливою, ми з вами і здійснюємо. Це означає, що має змінюватися і те, як ми співпрацюємо, і те, як ми це робимо, тому що централізовані ієрархічні IT-організації старого штибу перестають працювати. Вони починають відмирати.
Основи DevOps-організації
Ідеальна DevOps-організація майбутнього - це децентралізована, адаптивна система, що складається з автономних команд, кожна з яких складається з автономних індивідуумів. Ці команди розкидані по всьому світу, вони ефективно співпрацюють одна з одною за допомогою асинхронної комунікації, за допомогою прозорих протоколів обміну інформацією. Дуже красиво, правда? Дуже красиве майбутнє.
Звісно, це все неможливо без культурних змін. У нас має бути трансформаційне лідерство, особиста відповідальність, внутрішня мотивація.
Це основа DevOps-організацій: прозорість інформації, асинхронні комунікації, трансформаційне лідерство, децентралізація.
вигорання
Системи, частиною яких ми є, і ті, які ми будуємо, вони дедалі хаотичніші, і нам, людям, важко впоратися з цією думкою, важко відмовитися від ілюзії контролю. Ми намагаємось продовжувати їх контролювати, і це часто призводить до вигоряння. Я це говорю на власному досвіді, я теж обпікся, теж інвалід непередбачених збоїв у продакшні.
Вигоряння відбувається тоді, коли ми намагаємося контролювати те, що контролю за своєю суттю не піддається. Коли ми вигоряємо, то все втрачає сенс, тому що ми втрачаємо бажання робити щось нове, ми встаємо у захисну позицію та починаємо захищати те, що є.
Інженерна професія, як часто люблю собі нагадувати, це насамперед творча професія. Якщо ми втрачаємо бажання щось створювати, то ми перетворюємося на попіл, перетворюємося на золу. Вигоряють люди, вигоряють цілі організації.
На мій погляд, лише прийняття творчої сили хаосу, тільки побудова співпраці за його принципами — це те, що допоможе нам не розгубити те, що є в нашій професії.
Чого я вам бажаю: любити свою роботу, любити те, що ми робимо. Цей світ харчується інформацією, нам дісталася честь його годувати. Тож давайте вивчати хаос, будемо хаосологами, приноситимемо цінність, створюватимемо щось нове, ну, а проблеми, як ми вже з'ясували, неминучі, і коли вони з'являться, то ми скажемо просто «Ops!», і проблема вирішена.
Що крім Chaos Monkey?
Насправді всі ці інструменти, вони такі молоді. Ті самі Netflix будували інструменти під себе. Будуйте інструменти під себе. Читайте принципи хаосної інженерії та відповідайте цим принципам, а не намагайтеся шукати інші інструменти, які хтось інший уже збудував.
Намагайтеся зрозуміти, як ваші системи ламаються і починайте їх ламати та дивитися, як вони витримують удари. Це насамперед. А інструменти можна пошукати. Усі є проекти.
Я не зовсім зрозумів момент, коли ви говорили про те, що систему не можна спрощувати, спрощуючи її компоненти, і відразу ж перейшли до мікросервісів, які спрощують систему спрощенням самих компонентів і ускладнюючи взаємодії. Це по суті дві частини, що суперечать одна одній.
Так, мікросервіси - дуже суперечлива тема взагалі. Насправді спрощення частин підвищує гнучкість. Що мікросервіси пропонують? Вони дають нам гнучкість і швидкість, але простоти вони нам точно не дають ніяк. Вони підвищують складність.
Тобто у філософії DevOps мікросервіси – це не таке вже й благо?
У будь-якого блага є виворот. Є благо: це підвищує гнучкість, дає нам можливість вносити зміни швидше, але підвищує складність і, відповідно, крихкість усієї системи.
Все-таки на що більше наголос: на спрощення взаємодії або на спрощення частин?
Наголос, безперечно, на спрощення взаємодії, тому що якщо ми дивимося на це з точки зору того, як ми з вами працюємо, то, насамперед, потрібно звертати увагу на спрощення взаємодій, а не на спрощення роботи кожного з нас окремо. Тому що спрощення роботи — це перетворення на роботів. Ось у Макдональдсі це нормально працює, коли в тебе наказано: тут бургер поклав, тут на нього налив соус. Це у нашій творчій роботі не працює зовсім.
Чи правда, що все, що ви розповіли, живе у світі без конкуренції, і хаос там такий добрий, і немає протиріч усередині цього хаосу, ніхто нікого не хоче з'їсти, вбити? Як конкуренція та DevOps повинні жити?
Ну, це дивлячись про яку конкуренцію ми говоримо. Про конкуренцію на робочому місці чи конкуренцію між компаніями?
Про конкуренцію сервісів, які існують, тому що сервіси — це кілька компаній. Ми створюємо новий тип інформаційного середовища, і будь-яке середовище не може жити без конкуренції. Скрізь є конкуренція.
Ті самі Netflix, беремо їх за рольову модель. Вони це вигадали чому? Тому що їм потрібно було бути конкурентоспроможними. Ось ця гнучкість і швидкість руху, вона є саме тією конкурентною вимогою, вона вносить хаотичність в наші системи. Тобто хаос — це не те, що ми свідомо робимо, тому що ми його хочемо, це те, що відбувається через те, що цього вимагає світ. Нам просто доводиться адаптуватись. І хаос, він якраз результат конкуренції.
Це означає, що хаос це відсутність цілей як би? Чи ті цілі, яких ми не хочемо бачити? Ми в будиночку і не розуміємо інших цілей. Конкуренція, насправді, вона за рахунок того, що маємо чіткі цілі, і ми знаємо, куди прийдемо в кожний наступний момент часу. У цьому, на мій погляд, суть DevOps.
Теж погляд на запитання. Я думаю, що мета у нас усіх одна: виживати і робити це з
найбільшим задоволенням. І конкурентна мета у будь-якої організації така сама. Виживання відбувається часто в конкурентній боротьбі, тут нічого не вдієш.
Цього року конференція пройде 7 грудня у «Технополісі». До 11 листопада ми приймаємо заявки на доповіді. нам, якщо ви бажаєте виступити.
Реєстрація для учасників відкрита, квиток коштує 7000 рублів. Приєднуйтесь!
Джерело: habr.com