Антон Вайсс, Otomato Software компаниясынын негиздөөчүсү жана директору, Израилдеги биринчи DevOps сертификациясынын демилгечилеринин жана инструкторлорунун бири, былтыркы хаос теориясы жана хаос инженериясынын негизги принциптери жөнүндө, ошондой эле келечектеги идеалдуу DevOps уюму кантип иштээрин түшүндүрдү.
Биз докладдын тексттик вариантын даярдадык.
Кутман таң!
Москвадагы DevOpsDays экинчи жыл катары менен, мен бул сахнага экинчи жолу чыгып жатам, сиздердин көбүңүздөр экинчи жолу бул бөлмөдө отурасыз. Ал эмнени билдирет? Бул Орусиядагы DevOps кыймылы өсүп, көбөйүп жатканын жана эң негизгиси, 2018-жылы DevOps деген эмне экенин айтууга убакыт келди дегенди билдирет.
DevOps 2018-жылы эле кесип деп ойлогон колуңузду көтөрүңүз? Андайлар бар. Бөлмөдө жумуш сүрөттөмөсү "DevOps инженери" деп жазылган DevOps инженерлери барбы? Бөлмөдө DevOps менеджерлери барбы? Андай жок. DevOps архитекторлору? Дагы жок. жетишсиз. Эч ким DevOps инженери деп айтпаганы чынбы?
Демек, көпчүлүгүңүздөр бул анти-үлгү деп ойлойсузбу? Мындай кесип болбошу керекпи? Биз каалаган нерсени ойлоно алабыз, бирок биз ойлонуп жатканда, өнөр жай DevOps сурнайынын үнүнө салтанаттуу түрдө жылып баратат.
DevDevOps деген жаңы тема тууралуу ким укту? Бул иштеп чыгуучулар менен devops ортосунда натыйжалуу кызматташууга мүмкүндүк берген жаңы ыкма. Жана анчалык деле жаңы эмес. Твиттерге караганда, алар бул тууралуу 4 жыл мурун эле айта башташкан. Ал эми ушул убакка чейин буга кызыгуу күчөп, өсүп жатат, башкача айтканда, көйгөй бар. Маселени чечүү керек.
Биз чыгармачыл адамдарбыз, жөн эле эс ала бербейбиз. Биз мындай дейбиз: DevOps - бул жетиштүү камтылган сөз эмес; ага дагы эле ар кандай, кызыктуу элементтер жок. Жана биз жашыруун лабораторияларыбызга барып, кызыктуу мутацияларды чыгара баштайбыз: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Логика темирдей, туурабы? Биздин жеткирүү системабыз иштебейт, системаларыбыз туруксуз жана колдонуучуларыбыз нааразы, программалык камсыздоону өз убагында чыгарууга үлгүрбөйбүз, бюджетке туура келбейт. Мунун баарын кантип чечебиз? Биз жаңы сөз менен чыгабыз! Ал "Ops" менен бүтөт жана маселе чечилет.
Ошентип, мен бул ыкманы - "Ops, жана маселе чечилди" деп атайм.
Эгерде биз мунун баарын эмне үчүн ойлоп тапканыбызды эстесек, мунун баары арткы планга өтөт. Программалык камсыздоону жеткирүү жана бул процессте өзүбүздүн ишибизди тоскоолдуксуз, оорутпай, эффективдүү жана эң негизгиси, мүмкүн болушунча жагымдуу кылуу үчүн биз DevOps нерсени ойлоп таптык.
DevOps оорудан өсүп чыкты. А биз азап-тозоктон чарчадык. Мунун баары ишке ашуусу үчүн биз дайыма жашыл практикаларга таянабыз: эффективдүү кызматташуу, агымдык практика жана эң негизгиси системалык ой жүгүртүү, анткени ансыз DevOps иштебейт.
Система деген эмне?
Эгерде биз системалык ой жүгүртүү жөнүндө айтып жаткан болсок, анда система деген эмне экенин эстеп көрөлү.
Эгер сиз революциячыл хакер болсоңуз, анда система сиз үчүн ачык эле жаман. Бул сиздин үстүңүзгө илинип турган жана сиз каалабаган нерселерди жасоого мажбурлаган булут.
Системалык ой жүгүртүүнүн көз карашы боюнча, система бөлүктөн турган бүтүндүк. Бул жагынан алганда ар бирибиз системабыз. Биз иштеген уюмдар система. Ал эми сен экөөбүз куруп жаткан нерсе система деп аталат.
Мунун баары бир чоң социалдык-технологиялык системанын бир бөлүгү. Жана бул социалдык-технологиялык система кантип чогуу иштээрин түшүнсөк гана, ошондо гана биз бул маселеде бир нерсени чындап оптималдаштыра алабыз.
Системалык ой жүгүртүүнүн көз карашынан алганда, система ар кандай кызыктуу касиеттерге ээ. Биринчиден, ал бөлүктөрдөн турат, демек, анын жүрүм-туруму бөлүктөрдүн жүрүм-турумуна жараша болот. Мындан тышкары, анын бардык бөлүктөрү да бири-бирине көз каранды. Системанын бөлүктөрү канчалык көп болсо, анын жүрүм-турумун түшүнүү же алдын ала айтуу ошончолук кыйын болот экен.
Жүрүм-турум жагынан дагы бир кызыктуу факт бар. Система анын айрым бөлүктөрүнүн эч бири жасай албаган нерсени жасай алат.
Доктор Рассел Аккофф (системалык ой жүгүртүүнүн негиздөөчүлөрүнүн бири) айткандай, муну ой жүгүртүү эксперименти менен далилдөө абдан оңой. Мисалы, бөлмөдө ким код жазууну билет? Колдор көп, бул нормалдуу көрүнүш, анткени бул биздин кесипке коюлган негизги талаптардын бири. Сиз жазганды билесизби, бирок колуңуз сизден өзүнчө код жаза алабы? "Кодду менин колум эмес, мээм жазат" деген адамдар бар. Мээңиз сизден өзүнчө код жаза алабы? Ооба, балким, жок.
Мээ укмуштуудай машина, биз ал жерде анын кантип иштээрин 10% да билбейбиз, бирок ал биздин денебиз болгон системадан өзүнчө иштей албайт. Ал эми муну далилдөө оңой: баш сөөгүңдү ачып, мээңди чыгарып, компьютердин алдына кой, жөнөкөй нерсе жазганга аракет кылсын. Мисалы, Python тилиндеги "Салам, дүйнө".
Эгерде система өзүнүн бөлүктөрү өз алдынча жасай албаган нерсени жасай алса, анда бул анын жүрүм-туруму анын бөлүктөрүнүн жүрүм-туруму менен аныкталбайт дегенди билдирет. Анда эмне менен аныкталат? Бул бөлүктөрүнүн ортосундагы өз ара аракеттенүү менен аныкталат. Жана ошончолук көп бөлүкчөлөр, өз ара аракеттенишүүлөр канчалык татаал болсо, системанын жүрүм-турумун түшүнүү жана алдын ала айтуу ошончолук кыйын болот. Жана бул мындай системаны башаламандыкка алып келет, анткени системанын кайсы бир бөлүгүндөгү ар кандай, атүгүл эң маанилүү эмес, көзгө көрүнбөгөн өзгөрүү таптакыр күтүүсүз натыйжаларга алып келиши мүмкүн.
Баштапкы шарттарга бул сезгичтик биринчи жолу америкалык метеоролог Эд Лоренц тарабынан ачылган жана изилденген. Кийинчерээк ал "бабочка эффектиси" деп аталып, "хаос теориясы" деп аталган илимий ойдун кыймылынын өнүгүшүнө алып келген. Бул теория 20-кылымдын илиминдеги негизги парадигмалардын бири болуп калды.
Башаламандык теориясы
Хаосту изилдеген адамдар өздөрүн хаосолог деп аташат.
Чындыгында, бул отчеттун себеби, татаал бөлүштүрүлгөн системалар жана ири эл аралык уюмдар менен иштешип, бир убакта мен өзүмдү ушундай сезип калганымды түшүндүм. Мен хаосологмун. Бул негизинен: "Мен бул жерде эмне болуп жатканын түшүнгөн жокмун жана бул жөнүндө эмне кылышты билбейм" деп айтуунун акылдуу жолу.
Менимче, силердин көбүңөр да ушундай сезимде болушат, ошондуктан силер да хаосологсуңар. Сиздерди хаосологдордун гильдиясына чакырам. Сиз жана мен, урматтуу хаосологдор, изилдей турган системалар "татаал адаптацияланган системалар" деп аталат.
Адаптация деген эмне? Адаптациялоо мындай адаптациялык системадагы бөлүктөрдүн жеке жана жамааттык жүрүм-турумунун системадагы окуяларга же микро окуялардын чынжырларына жооп берип, өзгөрүшүн жана өзүн өзү уюштуруусун билдирет. Башкача айтканда, система өзүн-өзү уюштуруу аркылуу өзгөрүүлөргө ыңгайлашат. Ал эми бул өзүн-өзү уюштуруу жөндөмү эркин автономдуу агенттердин ыктыярдуу, толугу менен борбордон ажыратылган кызматташтыгына негизделген.
Мындай системалардын дагы бир кызыктуу касиети, алар эркин масштабда болот. Бизди хаосолог-инженерлер катары эмне кызыктырышы шексиз. Демек, татаал системанын жүрүм-туруму анын бөлүктөрүнүн өз ара аракети менен аныкталат десек, анда бизди эмне кызыктырышы керек? Өз ара аракеттенүү.
Дагы эки кызыктуу табылгалар бар.
Биринчиден, татаал системаны анын бөлүктөрүн жөнөкөйлөтүү менен жөнөкөйлөтүү мүмкүн эмес экенин түшүнөбүз. Экинчиден, татаал системаны жөнөкөйлөштүрүүнүн бирден бир жолу - анын бөлүктөрүнүн ортосундагы өз ара аракеттенүүнү жөнөкөйлөтүү.
Биз кантип өз ара аракеттенебиз? Сиз экөөбүз тең адам коому деп аталган чоң маалымат системасынын бөлүктөрүбүз. Биз орток тил аркылуу өз ара аракеттенебиз, эгер бизде бар болсо, аны тапсак.
Бирок тилдин өзү татаал адаптациялык система. Демек, эффективдүү жана жөнөкөй өз ара аракеттенүү үчүн биз кандайдыр бир протоколдорду түзүшүбүз керек. Башкача айтканда, кандайдыр бир символдордун жана аракеттердин ырааттуулугу, алар биздин ортобуздагы маалымат алмашууну жөнөкөй, алдын ала айтууга болот, түшүнүктүү кылат.
Татаалдуулукка, ыңгайлашууга, децентрализацияга, башаламандыкка карай тенденцияларды бардыгында байкоого болот деп айткым келет. Жана сиз жана мен куруп жаткан системаларда жана биз бир бөлүгү болгон системаларда.
Жана негизсиз болбош үчүн, келгиле, биз түзгөн системалар кандай өзгөрүп жатканын карап көрөлү.
Бул сөздү күттүңүз, түшүндүм. Биз DevOps конференциясындабыз, бүгүн бул сөз болжол менен жүз миң жолу угулат, анан биз бул тууралуу түнү менен түшүнөбүз.
Микросервистер DevOps практикасына реакция катары пайда болгон программалык камсыздоонун биринчи архитектурасы болуп саналат, ал системаларыбызды ийкемдүү, масштабдуураак кылуу жана үзгүлтүксүз жеткирүү үчүн иштелип чыккан. Ал муну кантип кылат? Кызмат көрсөтүүлөрдүн көлөмүн кыскартуу, бул кызматтар иштеп жаткан көйгөйлөрдүн көлөмүн кыскартуу, жеткирүү убактысын кыскартуу аркылуу. Башкача айтканда, биз системанын бөлүктөрүн кыскартабыз жана жөнөкөйлөтөбүз, алардын санын көбөйтөбүз, ошого жараша бул бөлүктөрдүн ортосундагы өз ара аракеттенүүнүн татаалдыгы дайыма көбөйөт, башкача айтканда, биз чечишибиз керек болгон жаңы маселелер пайда болот.
Микросервистер аягы эмес, микросервистер жалпысынан кечээ эле, анткени Serverless келе жатат. Бардык серверлер күйүп кетти, серверлер жок, операциялык системалар жок, жөн гана таза аткарылуучу код. Конфигурациялар өзүнчө, штаттар өзүнчө, бардыгы окуялар менен башкарылат. Сулуулук, тазалык, жымжырттык, эч кандай окуя, эч нерсе болбойт, толук тартип.
Татаалдуулук кайда? Кыйынчылык, албетте, өз ара аракеттенүүдө. Бир функция өз алдынча канча кыла алат? Ал башка функциялар менен кандай байланышта болот? Кабар кезектери, маалымат базалары, баланстоочулар. Катачылык болгондо кандайдыр бир окуяны кантип кайра түзүү керек? Суроолор көп жана жооптор аз.
Микросервистер жана серверсиз - бул биз хипстер Cloud Native деп атаган нерсе. Мунун баары булут жөнүндө. Бирок булут өзүнүн масштабдуулугу менен чектелүү. Биз аны бөлүштүрүлгөн система катары ойлоп көнүп калганбыз. Чынында, булут провайдерлеринин серверлери кайда жашашат? Маалымат борборлорунда. Башкача айтканда, бизде борборлоштурулган, өтө чектелген, бөлүштүрүлгөн моделдин түрү бар.
Бүгүнкү күндө биз нерселердин Интернети бул жөн гана чоң сөздөр эмес экенин түшүнүп жатабыз, ал тургай жөнөкөй божомолдор боюнча да, интернетке туташкан миллиарддаган түзмөктөр бизди алдыдагы беш-он жылда күтүп турат. Булутка бириктирилип, булуттан жүктөлө турган көп сандагы пайдалуу жана пайдасыз маалыматтар.
Булут узакка созулбайт, ошондуктан биз барган сайын четтөөчү эсептөөлөр деп аталган нерсе жөнүндө сүйлөшүп жатабыз. Же мага "туманды эсептөө" деген сонун аныктама да жагат. Ал романтизмдин жана сырдын мистицизми менен капталган.
Туманды эсептөө. Кеп булуттардын борборлоштурулган суунун, бууунун, муздун жана таштардын топтомдорунда. Ал эми туман – бул атмосферада айланабызга чачыраган суунун тамчылары.
Туман парадигмасында иштин көбү бул тамчылар тарабынан толугу менен автономдуу же башка тамчылар менен биргеликте аткарылат. Жана алар чындап кысып калганда гана булутка кайрылышат.
Башкача айтканда, кайра децентралдаштыруу, автономия жана, албетте, көпчүлүгүңүздөр мунун баары кайда кетип жатканын түшүнүп жатасыздар, анткени блокчейн жөнүндө айтпай туруп, борбордон ажыратуу жөнүндө сөз кыла албайсыз.
ишенгендер бар, бул cryptocurrency жумшаган адамдар. Мага окшоп ишенип бирок корккондор бар. Жана ишенбегендер бар. Бул жерде сиз башкача мамиле кыла аласыз. Технология бар, жаңы белгисиз нерсе, көйгөйлөр бар. Ар кандай жаңы технология сыяктуу, ал жооп бергенге караганда көбүрөөк суроолорду жаратат.
Блокчейндин айланасындагы дүрбөлөң түшүнүктүү. Алтынга шашылууну четке кагып, технологиянын өзү жаркын келечек үчүн укмуштуудай убадаларды берет: көбүрөөк эркиндик, көбүрөөк автономия, бөлүштүрүлгөн глобалдык ишеним. Эмне каалабайт?
Демек, дүйнө жүзү боюнча барган сайын көбүрөөк инженерлер борбордон ажыратылган тиркемелерди иштеп чыга башташты. Бул жөн гана: "Ахх, блокчейн - бул начар ишке ашырылган бөлүштүрүлгөн маалымат базасы" деп эле четке кагууга болбойт. Же скептиктер айткандай: "Блокчейн үчүн реалдуу тиркемелер жок". Ойлоп көрсөңөр, 150 жыл мурун эле электр энергиясы жөнүндө да айтышкан. Жана алар кандайдыр бир жагынан туура эле, анткени бүгүнкү күндө электр энергиясы 19-кылымда мүмкүн эмес болчу.
Баса, экранда кандай логотип турганын ким билет? Бул Hyperledger. Бул Linux Фондунун колдоосу астында иштелип жаткан долбоор жана блокчейн технологияларынын топтомун камтыйт. Бул, чынында эле, биздин ачык булак коомчулугунун күчү.
Chaos Engineering
Ошентип, биз иштеп жаткан система уламдан-улам татаал, баш аламан, адаптациялуу болуп баратат. Netflix микросервис системаларынын пионерлери. Алар муну биринчилерден болуп түшүнүшкөн, алар Simian Army деп аталган куралдардын топтомун иштеп чыгышкан, алардын эң белгилүүсү болгон. . Ал белгилүү болгон нерсени аныктады .
Баса, докладдын үстүндө иштөө процессинде биз бул текстти орус тилине да которгонбуз, андыктан барыңыз , окуңуз, комментарий бериңиз, урушуңуз.
Кыскача айтканда, хаос инженериясынын принциптери төмөнкүлөрдү айтат. Татаал бөлүштүрүлгөн системалар табиятынан күтүүсүз жана табиятынан катаал. Каталар сөзсүз болот, демек, бул каталарды кабыл алып, бул системалар менен такыр башка жол менен иштешибиз керек.
Биз өзүбүздүн системабызды дал ушул адаптация, өзүн өзү уюштуруу, жашоо үчүн сынап көрүү үчүн бул каталарды өндүрүш системаларыбызга киргизүүгө аракет кылышыбыз керек.
Жана бул баарын өзгөртөт. Системаларды өндүрүшкө кантип киргизебиз гана эмес, ошондой эле аларды кантип өнүктүрөбүз, кантип сынайбыз. Кодду турукташтыруу же тоңдуруу процесси жок, тескерисинче, туруктуу дестабилдештирүү процесси жүрүп жатат. Биз системаны өлтүрүп, анын аман калышын көрүүгө аракет кылып жатабыз.
Бөлүштүрүлгөн системалык интеграция протоколдору
Демек, бул биздин системалардын кандайдыр бир жол менен өзгөрүшүн талап кылат. Алар туруктуураак болушу үчүн, алардын бөлүктөрүнүн ортосундагы өз ара аракеттенүү үчүн жаңы протоколдор керек. Бул бөлүктөр макул болуп, кандайдыр бир өзүн-өзү уюштурууга келиши үчүн. Жана ар кандай жаңы инструменттер, жаңы протоколдор пайда болот, аларды мен “бөлүштүрүлгөн системалардын өз ара аракеттенүүсүнүн протоколдору” деп атайм.
Мен эмне жөнүндө айтып жатам? Биринчиден, долбоор . Кээ бирлери жалпы бөлүштүрүлгөн көзөмөлдөө протоколун түзүүгө аракет кылышат, ал татаал бөлүштүрүлгөн системаларды оңдоо үчүн таптакыр алмаштырылгыс курал болуп саналат.
Андан ары - . Система эмне болорун алдын ала айта албайбыз, башкача айтканда, анын байкалышын, байкалышын жогорулатуу керек деп жатабыз. Opentracing биздин системаларыбызга байкоо мүмкүнчүлүгүн берген куралдардын үй-бүлөсүнө кирет. Бирок система биз күткөндөй иш кылабы же жокпу, аныктоо үчүн байкоого муктажбыз. Биз күтүлгөн жүрүм-турумду кантип аныктайбыз? Кандайдыр бир саясатты, кандайдыр бир эрежелерди аныктоо менен. Open Policy Agent долбоору бул эрежелердин топтомун мүмкүндүк алуудан ресурстарды бөлүштүрүүгө чейин аныктоо үчүн иштеп жатат.
Биз айткандай, биздин системалар барган сайын окуяларга негизделген. Serverless окуяга негизделген системалардын сонун үлгүсү. Окуяларды системалар арасында өткөрүп берүү жана аларга көз салуу үчүн бизге кандайдыр бир жалпы тил керек, окуялар жөнүндө кантип сүйлөшөбүз, аларды бири-бирибизге кантип өткөрөбүз. Бул долбоор деп аталат .
Биздин системалардын үстүнөн жууп, аларды тынымсыз туруксуздаштыруучу өзгөрүүлөрдүн тынымсыз агымы программалык артефакттардын үзгүлтүксүз агымы болуп саналат. Өзгөртүүлөрдүн тынымсыз агымын кармап туруу үчүн бизге кандайдыр бир жалпы протокол керек, ал аркылуу биз программалык камсыздоонун артефакты деген эмне, ал кантип текшерилет, кандай текшерүүдөн өткөнү жөнүндө сүйлөшө алабыз. Бул долбоор деп аталат . Башкача айтканда, программалык артефакттар үчүн жалпы метадайындар протоколу.
Акыр-аягы, эгерде биз системаларыбыз толугу менен көз карандысыз, ыңгайлашкан жана өз алдынча уюшулган болушун кааласак, аларга өзүн-өзү идентификациялоо укугун беришибиз керек. Долбоор чакырды Ал так ушундай кылат. Бул ошондой эле Cloud Native Computing Фондунун колдоосу астындагы долбоор.
Бул долбоорлордун баары жаш, алардын бардыгы биздин сүйүүбүзгө, ырастообузга муктаж. Мунун баары ачык булак, биздин сыноо, биздин ишке ашыруу. Алар бизге технологиянын кайда баратканын көрсөтөт.
Бирок DevOps эч качан биринчи кезекте технология жөнүндө болгон эмес, ал ар дайым адамдардын ортосундагы кызматташуу жөнүндө болгон. Жана ошого жараша биз иштеп чыккан системалардын өзгөрүшүн кааласак, анда өзүбүз да өзгөрүшүбүз керек. Чынында, биз баары бир өзгөрүп жатабыз; бизде тандоо көп эмес.
Керемет бар Британиялык жазуучу Рэйчел Ботсман, анда ал адамзат тарыхындагы ишеним эволюциясы жөнүндө жазган. Анын айтымында, алгач примитивдүү коомдордо ишеним жергиликтүү болгон, башкача айтканда, биз өзүбүздүн тааныштарга гана ишенчүбүз.
Анан абдан узак мезгил – ишеним борборлоштурулган караңгы мезгил болду, ошол эле коомдук же мамлекеттик мекемеге таандык экенибиздин негизинде биз тааныбаган адамдарга ишене баштаганбыз.
Ал эми биздин азыркы дүйнөбүздө мына ушуну көрүп турабыз: ишеним барган сайын көбүрөөк бөлүштүрүлүп, борбордон ажыратылууда жана ал маалымат агымынын эркиндигине, маалыматтын жеткиликтүүлүгүнө негизделет.
Эгерде сиз ойлонуп көрсөңүз, бул ишенимди мүмкүн кылган дал ушул жеткиликтүүлүк, сиз жана мен ишке ашырып жатабыз. Бул биздин кызматташуу ыкмасы да, аны жасоо ыкмасы да өзгөрүшү керек дегенди билдирет, анткени эски борборлоштурулган, иерархиялык IT уюмдары иштебей калды. Алар өлүп баштайт.
DevOps уюмунун негиздери
Келечектин идеалдуу DevOps уюму - бул ар бири автономдуу адамдардан турган автономдуу командалардан турган борбордон ажыратылган, адаптацияланган система. Бул командалар дүйнө жүзү боюнча чачырап, бири-бири менен асинхрондук байланышты колдонуу менен эффективдүү кызматташып, өтө ачык-айкын байланыш протоколдорун колдонушат. Абдан сулуу, туурабы? Абдан сонун келечек.
Албетте, булардын бири да маданий өзгөрүүлөрсүз мүмкүн эмес. Бизде трансформациялык лидерлик, жеке жоопкерчилик, ички мотивация болушу керек.
Бул DevOps уюмдарынын негизин түзөт: маалыматтын ачыктыгы, асинхрондук байланыш, трансформациялык лидерлик, децентралдаштыруу.
чарчоо
Биз курамына кирген жана биз курган системалар барган сайын башаламан болуп баратат жана биз адамдар үчүн бул ой менен күрөшүү кыйын, башкаруу иллюзиясынан баш тартуу кыйын. Биз аларды көзөмөлдөөнү улантууга аракет кылабыз, бул көбүнчө күйүп калууга алып келет. Муну мен өз тажрыйбамдан айтып жатам, мен да күйүп кеттим, өндүрүштөгү күтүүсүз кемчиликтерден улам майып болдум.
Күйүү, биз башкарууга мүмкүн болбогон нерсени башкарууга аракет кылганда пайда болот. Биз күйүп калганда баары маанисин жоготот, анткени биз жаңы нерсе жасоого болгон каалообузду жоготуп, коргонууга өтүп, колубуздагыны коргой баштайбыз.
Инженердик кесип, мен өзүмө көп ирет эскертип тургандай, биринчи кезекте чыгармачылык кесип. Эгерде биз бир нерсени жаратууга болгон каалообузду жоготсок, анда күлгө, күлгө айланабыз. Эл күйүп кетти, бүтүндөй уюмдар күйүп кетти.
Менимче, баш аламандыктын жаратман күчүн кабыл алуу гана, анын принциптерине ылайык кызматташууну куруу гана кесибибиздеги жакшы нерселерди жоготпоого жардам берет.
Менин сага тилегеним ушул: өз жумушуңду сүйгүлө, биздин ишибизди сүйсөң. Бул дүйнө маалымат менен азыктанат, биз аны азыктандыруу сыймыгына ээбиз. Андыктан келгиле, баш аламандыкты изилдейли, келгиле хаосолог бололу, баалуулук алып келели, жаңы нерсени түзөлү, жакшы, көйгөйлөр, биз буга чейин эле байкаганыбыздай, сөзсүз болот, алар пайда болгондо, биз жөн эле «Оп!» деп айтабыз жана маселе чечилди.
Chaos Monkey башка эмне?
Чынында, бул аспаптардын баары абдан жаш. Ошол эле Netflix өздөрү үчүн куралдарды курган. Өз куралдарыңызды түзүңүз. Башка бирөө курган башка куралдарды табууга аракет кылбастан, хаос инженериясынын принциптерин окуп чыгыңыз жана ошол принциптерге ылайык жашаңыз.
Сиздин системаларыңыздын кандайча бузулуп жатканын түшүнүүгө аракет кылыңыз жана аларды бузуп баштаңыз жана алардын кандайча туруштук берерин көрүңүз. Бул биринчи келет. Жана сиз куралдарды издей аласыз. Ар кандай долбоорлор бар.
Системаны анын компоненттерин жөнөкөйлөтүү менен жөнөкөйлөштүрүү мүмкүн эмес деп айткан учурду мен такыр түшүнгөн жокмун жана дароо микросервистерге өткөн, алар компоненттердин өзүн жөнөкөйлөштүрүү жана өз ара аракеттенүүнү татаалдаштыруу аркылуу системаны жөнөкөйлөштүрүү. Булар бири-бирине карама-каршы келген эки бөлүктөн турат.
Туура, микросервистер жалпысынан абдан талаштуу тема. Чынында, бөлүктөрүн жөнөкөйлөтүү ийкемдүүлүктү жогорулатат. Микросервис эмнени камсыз кылат? Алар бизге ийкемдүүлүктү жана ылдамдыкты берет, бирок алар, албетте, бизге жөнөкөйлүк бербейт. Алар кыйынчылыкты жогорулатат.
Демек, DevOps философиясында микросервистер жакшы нерсе эмеспи?
Ар бир жакшылыктын тескери жагы болот. Пайдасы - бул ийкемдүүлүктү жогорулатып, тезирээк өзгөртүүлөрдү киргизүүгө мүмкүндүк берет, бирок ал бүт системанын татаалдыгын, демек, морттугун жогорулатат.
Ошентсе да эмнеге көбүрөөк басым жасалат: өз ара аракеттенүүнү жөнөкөйлөштүрүүбү же бөлүктөрүн жөнөкөйлөштүрүүгөбы?
Баса, албетте, өз ара аракеттенүүнү жөнөкөйлөштүрүүгө басым жасалат, анткени муну биз сиздер менен кантип иштешкенибиздин көз карашы менен карасак, анда биринчи кезекте ишти жөнөкөйлөтүүгө эмес, өз ара аракеттенүүнү жөнөкөйлөштүрүүгө көңүл бурушубуз керек. ар бирибизден өзүнчө. Анткени жумушту жөнөкөйлөтүү роботко айлануу дегенди билдирет. Бул жерде McDonald's, сизде инструкция болгондо кадимкидей иштейт: бул жерде гамбургерди саласыз, бул жерде ага соусту куясыз. Бул биздин чыгармачылык ишибизде такыр иштебейт.
Сиз айткандардын баары атаандашсыз дүйнөдө жашайт, ал жердеги башаламандык ушунчалык боорукер, бул башаламандыктын ичинде эч кандай карама-каршылык жок, эч ким эч кимди жегиси же өлтүргүсү келбейт деген чынбы? Атаандаштык жана DevOps кандай болушу керек?
Мейли, бул кандай атаандаштык жөнүндө сөз болуп жатканыбызга жараша болот. Кеп жумуштагы атаандаштыкпы же компаниялар арасындагы атаандаштыкпы?
Кызматтардын атаандаштыгы жөнүндө, анткени кызматтар бир нече компания эмес. Биз жаңы типтеги маалыматтык чөйрөнү түзүп жатабыз жана эч кандай чөйрө атаандаштыксыз жашай албайт. Бардык жерде атаандаштык бар.
Ошол эле Netflix, биз аларды үлгү катары алабыз. Эмне үчүн алар муну ойлоп табышты? Анткени алар атаандаштыкка жөндөмдүү болушу керек болчу. Бул ийкемдүүлүк жана кыймылдын ылдамдыгы так атаандаштык талап болуп саналат; ал биздин системаларыбызга баш аламандыкты киргизет. Башкача айтканда, башаламандык – бул биз каалагандыктан аң-сезимдүү түрдө жасаган нерсе эмес, бул дүйнө талап кылгандыктан болуп жаткан нерсе. Биз жөн гана көнүшүбүз керек. Ал эми башаламандык, бул так атаандаштыктын натыйжасы.
Бул башаламандык максаттардын жоктугу дегенди билдиреби? Же биз көргүбүз келбеген максаттарбы? Биз үйдөбүз жана башкалардын максаттарын түшүнбөйбүз. Атаандаштык, чындыгында, биздин так максаттарыбыз бар жана биз убакыттын ар бир кийинки көз ирмеминде кайда барарыбызды билебиз. Бул, менин көз карашым боюнча, DevOpsтин маңызы.
Ошондой эле суроону карап көрөлү. Менимче, баарыбыздын максатыбыз бир: аман калуу жана аны менен бирге
эң чоң ырахат. Ал эми ар бир уюмдун атаандаштык максаты бир. Жашоо көбүнчө атаандаштык аркылуу болот, бул тууралуу эч нерсе кыла албайсың.
Быйылкы конференция 7-декабрда Технополисте өтөт. Отчетторго арыздарды 11-ноябрга чейин кабыл алып жатабыз. сүйлөгүң келсе бизге.
Катышуучуларды каттоо ачык, билеттердин баасы 7000 рубль. Бизге кошул!
Source: www.habr.com