Заснавальнік і дырэктар "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