Акыркы убакта интернетти мындай жарнактар каптап кетти. Жагымдуу айлыкка карабай, ичинде жапайы бидъат жазылганына уялбай коё албайсың. Адегенде "DevOps" жана "инженер" кандайдыр бир жол менен бир сөзгө жабыштырылышы мүмкүн деп болжолдонууда, андан кийин талаптардын кокустук тизмеси бар, алардын айрымдары системанын вакансиясынан так көчүрүлгөн.
Бул постто мен бул жашоого кантип жеткенибиз, DevOps деген эмне жана азыр аны менен эмне кылуу керектиги жөнүндө бир аз сүйлөшкүм келет.
Мындай бош орундарды ар тараптан айыптоого болот, бирок факт бойдон калууда: алардын көбү бар жана учурда базар ушундай иштеп жатат. Биз devops конференциясын өткөрдүк жана ачык айттык: " - DevOps инженерлери үчүн эмес." Бул көпчүлүк үчүн кызыктай жана жапайы көрүнөт: эмне үчүн толугу менен коммерциялык иш-чара жасап жаткан адамдар базарга каршы чыгышат. Эми баарын түшүндүрүп беребиз.
Маданият жана процесстер жөнүндө
DevOps инженердик дисциплина эмес экенинен баштайлы. Мунун баары тарыхый калыптанган ролдорду бөлүштүрүү продукциянын сапаты үчүн иштебей жатканынан башталды. Программисттер гана программалашканда, бирок тестирлөө жөнүндө эч нерсе уккусу келбесе, программа мүчүлүштүктөргө толгон. Администраторлор программалык камсыздоонун кантип же эмне үчүн жазылганына маани бербесе, колдоо тозокко айланат.
Мисалы, системалык администратор менен SRE кызматын башкаруунун ортосундагы айырманы сүрөттөп берүү . ичинде кызыктуу изилдөөлөр жүргүзүлгөн — Мыкты иштеп чыгуучулар кандайдыр бир жол менен өндүрүшкө жаңы өзгөртүүлөрдү саатына бир жолудан тезирээк киргизүүгө жетише турганы түшүнүктүү. Алар 10% дан ашпаган колдору менен сынашат (бул жерден көрүүгө болот ). Алар муну кантип кылышат? Отчеттун рубрикаларынын биринде "Excel же өл" деп айтылат. Бул статистиканы тестирлөөнүн контекстинде кеңири талкуулоо үчүн Барух Садогурскийдин негизги баяндамасына кайрылсаңыз болот. башка конференциябызда, Heisenbug.
«Жолдоштордун ортосунда макулдашуу болбосо,
Алар үчүн баары жакшы болбойт,
Ошондон эч нерсе чыкпайт, бир гана азап.
Илгери-илгери Аккуу, Рая, шортан..."
Сиздин оюңузча, веб-программисттердин кайсы бөлүгү алардын тиркемелери өндүрүштө колдонулган шарттарды чындап түшүнөт? Алардын канчасы администраторлорго барып, маалымат базасы бузулса эмне болорун аныктоого аракет кылат? Анан кимиси тестиерлерге барып, тестти туура жазганды үйрөтүүнү суранат? Ошондой эле күзөтчүлөр, продукт менеджерлери жана башка бир топ адамдар бар.
DevOps'тун жалпы идеясы - ролдор менен бөлүмдөрдүн ортосунда кызматташтыкты түзүү. Биринчиден, бул кандайдыр бир акылдуу конфигурацияланган программалык камсыздоонун жардамы менен эмес, баарлашуу практикасы аркылуу ишке ашат. DevOps маданият, практика, методология жана процесстер жөнүндө. Бул суроолорго жооп бере турган инженердик адистик жок.
Каардуу чөйрө
Анда “девопс инженерия” дисциплина кайдан пайда болгон? Бизде версия бар! DevOps идеялары жакшы болгон — ушунчалык жакшы болгондуктан, алар өздөрүнүн ийгилигинин курмандыгы болушкан. Өзүнүн атмосферасы бар кээ бир көмүскө жалдоочулар жана адам сатуучулар бул теманын айланасында айланта башташты.
Элестетиңиз: кечээ сиз Химкиде шаурма жасап жатсаңыз, бүгүн сиз чоң адамсыз, улук жалдоочусуз. Талапкерлерди издөөнүн жана тандоонун бүтүндөй процесси бар, баары оңой эмес, түшүнүү керек. Бөлүмдүн башчысы айтат дейли: X боюнча адисти табыңыз. Биз X деген сөздү “инженер” деп ыйгарабыз, биз бүттүк. Linux керекпи? Бул, албетте, Linux инженери, эгер сиз DevOps кааласаңыз, анда DevOps инженери. Вакансия аталыштан гана эмес, ичине кандайдыр бир текст киргизилиши керек. Эң оңой жолу - кыялыңызга жараша Google'дан ачкыч сөздөрдүн топтомун киргизүү. DevOps эки сөздөн турат - "Dev" жана "Ops", бул биз иштеп чыгуучуларга жана администраторлорго тиешелүү ачкыч сөздөрдү бир үймөктө бириктиришибиз керек дегенди билдирет. 42 программалоо тилин билүү жана Kubernetes менен Swarm бир эле учурда 20 жыл колдонуу боюнча бош орундар ушундайча пайда болот. Иш диаграммасы.
Ошентип, адамдардын аң-сезиминде белгилүү бир "девопс" суперкаарманынын маанисиз жана ырайымсыз образы орноду, ал бардыгын Дженкинске жайгаштырууга конфигурациялайт жана бакыт келет. Эх, баары ушунчалык жөнөкөй болсо кана. "Ошондой эле сиз системалык администраторлорду кантип издей аласыз", - деп ойлойт HR, "бул модалуу сөз, ачкыч сөздөр бирдей, алар жемди алышы керек."
Суроо-талап сунушту жаратат жана бул таштанды бош орундарынын баары акылга сыйбаган сандагы системалык администраторлорго толду, алар түшүнүштү: сиз бардыгын мурункудай кыла аласыз, бирок өзүңүздү "девоптор" деп атоо менен бир нече эсе көп ала аласыз. SSH аркылуу серверлерди бирден конфигурациялагандай эле, аларды конфигурациялоону улантасыз, бирок азыр бул devops практикасы деп болжолдонууда. Бул кандайдыр бир татаал феномен, жарым-жартылай классикалык администраторлорду баалабагандык жана DevOps айланасындагы ызы-чуу менен байланышкан, бирок жалпысынан эмне болду.
Демек, бизде суроо-талап жана сунуш бар. Өзүн-өзү азыктандырган каардуу чөйрө. Биз ушуга каршы күрөшүп жатабыз (анын ичинде DevOops конференциясын түзүү менен).
Албетте, өздөрүн "девоптор" деп өзгөрткөн системалык администраторлордон тышкары, башка катышуучулар да бар - мисалы, кесипкөй SREs же Infrastructure-as-Code иштеп чыгуучулар.
DevOps'та адамдар эмне кылышат (чындыгында)
Ошентип, сиз DevOps тажрыйбаларын үйрөнүүдө жана колдонууда алдыга умтулгуңуз келет. Бирок муну кантип жасоо керек, кайсы тарапты караш керек? Албетте, сиз популярдуу ачкыч сөздөргө сокур түрдө ишенбешиңиз керек.
Жумуш бар болсо, аны бирөө жасашы керек. Булар "девопс инженерлери" эмес экенин биз мурунтан эле билдик, анда кимдер? Муну позициялар боюнча эмес, иштин конкреттуу багыттары боюнча формулировкалоо туурараак окшойт.
Биринчиден, сиз DevOps'тун жүрөгүнө — процесстерге жана маданиятка кайрыла аласыз. Маданият жай жана татаал бизнес, ал салттуу түрдө менеджерлердин жоопкерчилиги болсо да, программисттерден баштап администраторлорго чейин ар бир адам тигил же бул тармакта иштешет. Бир нече ай мурун Тим Листер :
«Маданият уюмдун негизги баалуулуктары менен аныкталат. Көбүнчө эл муну байкабайт, бирок көп жылдар бою консалтингде иштегендиктен, байкап көнүп калганбыз. Сиз компанияга кирип, бир нече мүнөттүн ичинде эмне болуп жатканын сезе баштайсыз. Биз муну "даам" деп атайбыз. Кээде бул жыт абдан жакшы болот. Кээде жүрөк айланууга алып келет. (...) Белгилүү иш-аракеттердин артында турган баалуулуктар жана ишенимдер түшүнүлмөйүнчө, сиз маданиятты өзгөртө албайсыз. Жүрүм-турумун байкоо оңой, бирок ишенимди издөө кыйын. DevOps - бул нерселер барган сайын татаалдашып баратканынын сонун мисалы."
Албетте, маселенин техникалык жагы да бар. Эгерде сиздин жаңы кодуңуз бир айдын ичинде сыналып, бирок бир жылдан кийин гана чыгарылса жана анын баарын тездетүү физикалык жактан мүмкүн болбосо, сиз жакшы тажрыйбаларды аткарбай калышыңыз мүмкүн. Жакшы тажрыйбалар жакшы куралдар менен колдоого алынат. Мисалы, Infrastructure-as-Code идеясын эске алуу менен, сиз AWS CloudFormation жана Terraformтен баштап Chef-Ansible-Puppetке чейин каалаган нерсени колдоно аласыз. Сиз мунун баарын билип, жасай алышыңыз керек жана бул инженердик дисциплина. Себеп менен натыйжаны чаташтырбоо маанилүү: адегенде сиз SRE принциптери боюнча иштейсиз жана андан кийин гана бул принциптерди кандайдыр бир конкреттүү техникалык чечимдер түрүндө ишке ашырасыз. Ошол эле учурда, SRE бул абдан комплекстүү методология, анда Дженкинсти кантип орнотуу керектиги айтылбайт, бирок беш негизги принцип:
- Ролдор менен бөлүмдөрдүн ортосундагы байланыш жакшырды
- Каталарды жумуштун ажырагыс бөлүгү катары кабыл алуу
- Акырындык менен өзгөрүүлөрдү жасоо
- инструменттерди жана башка автоматташтырууларды колдонуу
- Өлчөөгө боло турган нерселердин баарын өлчөө
Бул кээ бир билдирүүлөрдүн жыйындысы эмес, конкреттүү . Мисалы, каталарды кабыл алуу жолунда сиз тобокелдиктерди түшүнүп, SLI сыяктуу нерсени колдонуп кызматтардын жеткиликтүүлүгүн жана жеткиликсиздигин өлчөшүңүз керек болот.) жана SLO (), өлгөндөн кийин жазганды үйрөнүп, аларды жазууну коркутуу эмес.
SRE дисциплинасында инструменттерди колдонуу маанилүү болсо да, ийгиликтин бир гана бөлүгү. Биз тынымсыз техникалык жактан өнүгүп, дүйнөдө эмне болуп жатканын жана аны биздин ишибизде кантип колдонууга болоорун карап турушубуз керек.
Өз кезегинде, Cloud Native чечимдери азыр абдан популярдуу болуп калды. Cloud Native Computing Foundation бүгүн аныктагандай, Cloud Native технологиялары уюмдарга коомдук, жеке жана гибриддик булуттар сыяктуу бүгүнкү динамикалык чөйрөлөрдө масштабдуу тиркемелерди иштеп чыгууга жана иштетүүгө мүмкүндүк берет. Мисалдарга контейнерлер, тейлөө тармактары, микросервистер, өзгөрүлбөс инфраструктура жана декларативдик API кирет. Бул ыкмалардын баары эркин туташкан системалардын ийкемдүү, башкарылуучу жана өтө байкала турган бойдон калышына мүмкүндүк берет. Жакшы автоматташтыруу инженерлерге чоң өзгөрүүлөрдү тез-тез жана алдын ала айтууга мүмкүн болгон жыйынтыктарды жасоого мүмкүндүк берет. Мунун бардыгын Docker жана Kubernetes сыяктуу белгилүү инструменттердин топтому колдойт.
Бул кыйла татаал жана кенен аныктама аймактын да бир топ татаал экендигине байланыштуу. Бир жагынан алганда, бул системага жаңы өзгөртүүлөр абдан жөнөкөй кошулушу керек деп ырасташат. Экинчи жагынан, программалык камсыздоо менен аныкталган инфраструктурада эркин туташтырылган кызматтар жашаган жана ал жерде үзгүлтүксүз CI/CD аркылуу жеткирилген контейнердик чөйрөнү кантип түзүү керектигин аныктоо жана мунун бардыгынын тегерегинде DevOps практикасын куруу - мунун бардыгы көбүрөөк талап кылат. ит жегенден көрө.
Ушунун бардыгын эмне кылуу керек
Бул маселелерди ар ким өз жолу менен чечет: мисалы, катаал чөйрөнү бузуу үчүн кадимки вакансияларды жарыялай аласыз. DevOps жана Cloud Native сыяктуу сөздөр эмнени билдирерин билип, аларды туура жана максатка ылайык колдоно аласыз. Сиз DevOps программасында өнүгүп, өзүңүздүн үлгүңүз менен туура ыкмаларды көрсөтө аласыз.
Биз конференция өткөрүп жатабыз , бул биз айтып өткөн нерселерге тереңирээк киришүүгө мүмкүнчүлүк берет. Бул үчүн отчеттордун бир нече топтору бар:
- Процесстер жана маданият;
- Сайттын ишенимдүүлүгү инженериясы;
- Cloud Native;
Каякка барарын кантип тандоо керек? Бул жерде бир тымызын жагдай бар. Бир жагынан, DevOps өз ара аракеттенүү жөнүндө жана биз сиздин ар кандай блоктордун презентацияларына катышууңузду каалайбыз. Экинчи жагынан, эгерде сиз конференцияга бир конкреттүү тапшырмага көңүл топтоо үчүн келген өнүгүү боюнча менеджер болсоңуз, анда сизди эч ким чектебейт - албетте, бул процесстер жана маданият жөнүндө блок болот. Конференциядан кийин жаздыруулар болоорун унутпаңыз (пикир формасын толтургандан кийин), андыктан анча маанилүү эмес презентацияларды кийинчерээк көрө аласыз.
Албетте, конференциянын өзүндө сиз бир эле учурда үч жолго чыга албайсыз, ошондуктан биз программаны ар бир убакыт аралыгы ар бир табитке ылайык темаларды камтыгандай уюштурабыз.
Эгер сиз DevOps инженери болсоңуз, эмне кылуу керектигин түшүнүү гана калды! Биринчиден, эмне кылып жатканыңызды аныктоого аракет кылыңыз. Көбүнчө алар бул сөздү:
- Инфраструктурада иштеген иштеп чыгуучулар. SRE жана Cloud Native жөнүндө отчеттордун топтору сизге эң ылайыктуу.
- Системалык администраторлор. Бул жерде татаалыраак. DevOops системаны башкаруу жөнүндө эмес. Бактыга жараша, системалык башкаруу темасында көптөгөн сонун конференциялар, китептер, макалалар, Интернетте видеолор ж.б. Башка жагынан алганда, эгер сиз өзүңүздү маданиятты жана процесстерди түшүнүү, булут технологиялары жана Cloud Native менен жашоонун деталдары менен таанышууга кызыкдар болсоңуз, анда биз сизди көргүбүз келет! Бул жөнүндө ойлонуп көрүңүз: сиз башкарууну аткарып жатасыз, анан эмне кыласыз? Күтүлбөгөн жерден жагымсыз кырдаалга туш болбоо үчүн, азыр үйрөнүшүңүз керек.
Дагы бир вариант бар: сиз өжөрлүгүңүздү уланта бересиз өзгөчө DevOps инженери жана башка эч нерсе, бул эмнени билдирет. Анда биз сиздин көңүлүңүздү калтырышыбыз керек, DevOops DevOps инженерлери үчүн конференция эмес!
Слайддан Мюнхенде
DevOops 2020 Moscow 29-30-апрелде Москвада өтөт, билеттер буга чейин эле жеткиликтүү .
Мындан тышкары, мүмкүн 8-февралга чейин. Сураныч, форманы толтурууда сиз отчетуңуздан көбүрөөк пайда ала турган максаттуу аудиторияны тандооңуз керек экенин эске алыңыз (тизменин ичинде сюрприз көмүлгөн).
Source: www.habr.com