Чат талқылауына негізделген
Жақында DevOps және SRE анықтамасына қатысты нағыз шайқастар өршіп кетті.
Осы тақырыптағы пікірталас көптеген жолдармен менің тістерімнен шығып кеткеніне қарамастан, соның ішінде мен де, мен бұл тақырып бойынша өз көзқарасымды Хабра қауымдастығының сотына жеткізуді шештім. Қызығушылық танытқандар үшін мысыққа қош келдіңіз. Және бәрі жаңадан басталсын!
тарихын
Сонымен, ежелгі уақытта бағдарламалық жасақтаманы әзірлеушілер мен сервер әкімшілерінің командасы бөлек өмір сүрді. Біріншісі кодты сәтті жазды, екіншісі біріншісіне бағытталған әртүрлі жылы, мейірімді сөздерді қолданып, серверлерді орнатып, әзірлеушілерге мерзімді түрде келіп, жауап ретінде «менің машинамда бәрі жұмыс істейді» деген жан-жақты жауап алды. Бизнес бағдарламалық қамтамасыз етуді күтті, бәрі бос болды, ол мезгіл-мезгіл бұзылды, бәрі қобалжыды. Әсіресе, осы бейберекетсіздікті төлеген адам. Даңқты шам дәуірі. Сіз DevOps қайдан келетінін білесіз.
DevOps тәжірибелерінің пайда болуы
Сосын байсалды жігіттер келіп, бұл сала емес, олай жұмыс істей алмайсың, деді. Және олар өмірлік цикл үлгілерін әкелді. Міне, мысалы, V-моделі.
Сонымен не көріп тұрмыз? Бизнес концепциямен келеді, сәулетшілер дизайн шешімдерін жасайды, әзірлеушілер код жазады, содан кейін ол сәтсіздікке ұшырайды. Біреу әйтеуір өнімді сынап көреді, біреу әйтеуір оны соңғы тұтынушыға жеткізеді және осы ғажайып модельдің бір жерінде теңіз жағасында уәде етілген ауа-райын күтіп тұрған жалғыз іскер тұтынушы отырады. Біз бұл процесті орнатуға мүмкіндік беретін әдістер қажет деген қорытындыға келдік. Және біз оларды жүзеге асыратын тәжірибелер жасауды шештік.
Тәжірибе дегеніміз не деген тақырыпқа лирикалық шегініс
Тәжірибе деп мен технология мен тәртіптің үйлесімін айтамын. Мысал ретінде терраформалық кодты пайдаланып инфрақұрылымды сипаттау тәжірибесін келтіруге болады. Пән - бұл инфрақұрылымды кодпен сипаттау, ол әзірлеушінің басында, ал технология - бұл терраформаның өзі.
Және олар оларды DevOps тәжірибесі деп атауға шешім қабылдады - менің ойымша, олар әзірлеуден операцияға дейін дегенді білдіреді. Біз әртүрлі ақылды нәрселерді ойлап таптық - CI/CD тәжірибелері, IaC принципіне негізделген тәжірибелер, олардың мыңдағаны. Біз кетеміз, әзірлеушілер код жазады, DevOps инженерлері жүйенің сипаттамасын код түріндегі жұмыс жүйелеріне түрлендіреді (иә, код, өкінішке орай, жай сипаттама, бірақ жүйенің іске асуы емес), жеткізу жалғасуда, және тағы басқа. Кешегі әкімшілер жаңа тәжірибелерді игеріп, DevOps инженерлері ретінде мақтанышпен қайта даярлықтан өтті және бәрі сол жерден шықты. Ал кеш болды, таң болды... кешіріңіз, ол жақтан емес.
Қайта бәрі жақсы емес, Құдайға шүкір
Барлығы тынышталып, әртүрлі айлакер «әдіскерлер» DevOps тәжірибесі туралы қалың кітаптар жаза бастағанда, әйгілі DevOps инженерінің кім екендігі және DevOps - өндірістік мәдениет екендігі туралы даулар тыныштықта өршіп кетті, наразылық қайтадан пайда болды. Кенеттен бағдарламалық қамтамасыз етуді жеткізу мүлдем тривиальды емес міндет екені белгілі болды. Әрбір даму инфрақұрылымының өз стекі бар, оны бір жерде жинау керек, бір жерде сізге қоршаған ортаны орналастыру керек, мұнда сізге Tomcat керек, мұнда оны іске қосудың айлакер және күрделі әдісі қажет - жалпы алғанда, сіздің басыңыз шаншып тұр. Бір қызығы, мәселе, ең алдымен, процестерді ұйымдастыруда болды - бұл жеткізу функциясы, тығырық сияқты, процестерді бұғаттай бастады. Сонымен қатар, ешкім Операцияларды тоқтатқан жоқ. Ол V-модельде көрінбейді, бірақ оң жақта әлі де бүкіл өмірлік цикл бар. Нәтижесінде қандай да бір жолмен инфрақұрылымды ұстап тұру, мониторингті бақылау, инциденттерді шешу, сондай-ақ жеткізумен айналысу қажет. Анау. әзірлеуде де, жұмыс істеуде де бір аяқпен отырыңыз - кенеттен ол әзірлеу және операциялар болып шықты. Содан кейін микросервистерге арналған жалпы шу болды. Және олармен бірге жергілікті машиналардан әзірлемелер бұлтқа ауыса бастады - жергілікті түрде бірдеңені жөндеуге тырысыңыз, егер ондаған және жүздеген микросервистер болса, тұрақты жеткізу өмір сүру құралына айналады. «Шағын қарапайым компания» үшін бәрі жақсы болды, бірақ бәрібір? Google ше?
Google ұсынған SRE
Google келді, ең үлкен кактустарды жеді және шешім қабылдады - бізге бұл қажет емес, бізге сенімділік керек. Және сенімділікті басқару керек. Мен сенімділікті басқаратын мамандар қажет деп шештім. Мен оларды SR инженерлері деп атадым және бұл сізге арналған, мұны әдеттегідей жақсы орындаңыз дедім. Міне SLI, міне SLO, міне мониторинг. Және ол операцияға мұрынды тықты. Және ол өзінің «сенімді DevOps» SRE деп атады. Барлығы жақсы сияқты, бірақ Google-дың қолынан келетін бір лас хак бар - SR инженерлері лауазымына білікті әзірлеушілер болған, сонымен қатар аздап үй тапсырмасын орындаған және жұмыс жүйелерінің жұмысын түсінетін адамдарды жалдаңыз. Оның үстіне, Google-дың өзінде мұндай адамдарды жұмысқа алуда қиындықтар бар - бұл жерде ол өзімен бәсекелесетіндіктен - біреуге бизнес логикасын сипаттау керек. Жеткізу инженерлерді босатуға тағайындалды, SR - инженерлер сенімділікті басқарады (әрине, тікелей емес, бірақ инфрақұрылымға әсер ету, архитектураны өзгерту, өзгерістер мен көрсеткіштерді қадағалау, инциденттермен күресу арқылы). Жақсы, сіз аласыз . Бірақ егер сіз Google болмасаңыз, бірақ сенімділік әлі де қандай да бір алаңдаушылық туғызса ше?
DevOps идеяларын дамыту
Дәл осы кезде lxc-тен шыққан Докер келді, содан кейін Docker Swarm және Kubernetes сияқты әртүрлі оркестрлік жүйелер және DevOps инженерлері дем шығарды - тәжірибелерді біріктіру жеткізуді жеңілдетеді. Бұл оны әзірлеушілерге жеткізуді аутсорсингпен қамтамасыз ету мүмкін болатын дәрежеде жеңілдетілді - deployment.yaml деген не. Контейнерлеу мәселені шешеді. Ал CI/CD жүйелерінің жетілу мерзімі қазірдің өзінде бір файлды жазу деңгейінде және біз оны аяқтаймыз - әзірлеушілер оны өздері шеше алады. Содан кейін біз өзіміздің SRE-ді қалай жасауға болатыны туралы сөйлесе бастаймыз, ... немесе кем дегенде біреумен.
SRE Google-да жоқ
Жарайды, біз жеткізуді жеткіздік, біз дем шығара алатын сияқтымыз, админдер процессордың жүктелуін бақылап, жүйелерді баптап, тыныштықта және тыныштықта кружкалардан түсініксіз нәрсені үнсіз жұтып қойған ескі жақсы күндерге ораламыз ... Тоқта. Біз бәрін бастадық (бұл өкінішті!). Кенеттен Google-дың көзқарасында біз тамаша тәжірибелерді оңай қабылдай алатынымыз белгілі болды - бұл процессордың жүктемесі емес, дискілерді қаншалықты жиі ауыстыратынымыз немесе бұлттағы шығындарды оңтайландыратынымыз емес, бірақ бизнес көрсеткіштері бірдей танымал. SLx. Ешкім олардан инфрақұрылымдық басқаруды алып тастаған жоқ және олар инциденттерді шешіп, мерзімді түрде кезекшілікте болуы керек және әдетте бизнес-процестердің басында тұруы керек. Ал, балалар, бірте-бірте жақсы деңгейде бағдарламалауды бастаңыз, Google сізді күтуде.
Қорытындылау үшін. Кенеттен, бірақ сіз оқудан шаршадыңыз және мақалаға түсініктемеде авторға түкіруді және жазуды күте алмайсыз. DevOps жеткізу тәжірибесі ретінде әрқашан болған және болады. Және ол ешқайда кетпейді. SRE операциялық тәжірибелер жиынтығы ретінде бұл жеткізуді сәтті етеді.
Ақпарат көзі: www.habr.com