DevOps анықтамасы өте күрделі, сондықтан біз бұл туралы талқылауды әр уақытта басынан бастауымыз керек. Тек Хабреде осы тақырып бойынша мыңдаған жарияланымдар бар. Бірақ егер сіз мұны оқып жатсаңыз, DevOps не екенін білетін шығарсыз. Өйткені мен олай емеспін. Сәлем менің атым Александр Титов (@) және біз тек DevOps туралы сөйлесеміз, мен өз тәжірибеммен бөлісемін.
Мен өз әңгімемді қалай пайдалы ету керектігі туралы ұзақ уақыт бойы ойладым, сондықтан мұнда көптеген сұрақтар болады - мен өзіме қоятын сұрақтар мен біздің компанияның клиенттеріне қоятын сұрақтарым. Осы сұрақтарға жауап беру арқылы түсіну жақсарады. Мен сізге DevOps не үшін қажет екенін, менің көзқарасым бойынша, бұл не екенін және менің көзқарасым бойынша қайтадан DevOps-ке өтіп жатқаныңызды қалай түсінуге болатынын айтамын. Соңғы нүкте сұрақтар арқылы болады. Оларға өзіңіз жауап бере отырып, сіз компанияңыздың DevOps-ке көшіп жатқанын немесе қандай да бір жолмен проблемалардың бар-жоғын түсіне аласыз.
Бір кездері мен қосылулар мен қосылулар толқынында болдым. Алдымен мен Qik деп аталатын шағын стартапта жұмыс істедім, содан кейін оны Skype деп аталатын сәл үлкенірек компания сатып алды, содан кейін оны Microsoft деп аталатын сәл үлкенірек компания сатып алды. Сол кезде мен DevOps идеясының әртүрлі көлемдегі компанияларда қалай өзгеретінін көре бастадым. Осыдан кейін мен DevOps-ті нарық тұрғысынан қарауға қызығушылық таныттым, мен әріптестеріммен Express 42 компаниясын құрдық. 6 жыл бойы біз нарық толқынымен жүріп келеміз.
Басқа нәрселермен қатар, мен DevOps Мәскеу қауымдастығын ұйымдастырушылардың бірімін және DevOps-Days 2017 ұйымдастырушысымын, бірақ мен 2018-ді ұйымдастырған жоқпын. Express 42 көптеген компаниялармен жұмыс істейді. Біз сол жерде DevOps-ті өсіреміз, оның қалай болатынын бақылаймыз, қорытынды жасаймыз, талдаймыз, қорытындыларымызды барлығына айтып береміз және адамдарды DevOps тәжірибесіне үйретеміз. Жалпы, біз бұл тұрғыда тәжірибеміз бен тәжірибемізді арттыруға бар күшімізді салып жатырмыз.
Неліктен DevOps
Барлығын мазалайтын бірінші сұрақ - неге? Көптеген адамдар DevOps бұл жай ғана автоматтандыру немесе әр компанияда болған ұқсас нәрсе деп ойлайды.
— Бізде үздіксіз интеграция болды - бұл бізде DevOps бұрыннан болғанын білдіреді және мұның бәрі не үшін қажет? Олар шетелде көңіл көтеруде, бірақ жұмыс істеуімізге кедергі жасайды!
Қауымдастық пен әдістеменің 9 жыл бойы дамуы, бұл әлі де маркетингтік жылтыр емес екені белгілі болды, бірақ оның не үшін қажет екені әлі толық түсініксіз. Кез келген құрал мен процесс сияқты, DevOps-тың нақты мақсаттары бар, ол сайып келгенде қол жеткізеді.
Осының барлығы дүниенің өзгеріп жатқандығынан. Компаниялар арманға тіке қарай жылжыған кезде, ол біздің Петербургтік классик жырлағандай, А нүктесінен В нүктесіне белгілі бір стратегия бойынша, осы үшін құрылған белгілі құрылыммен, кәсіпорындық көзқарастан алшақтайды.
Негізінде, АТ-дағы барлық нәрсе осы тәсілге сәйкес құрылуы керек. Мұнда АТ тек процестерді автоматтандыру үшін қолданылады.
Автоматтандыру жиі өзгермейді, өйткені компания жақсы басылған жолға түскенде, нені өзгерту керек? Ол жұмыс істейді - оған қол тигізбеңіз. Қазір әлемдегі тәсілдер өзгеруде және Agile деп аталатын әдіс В соңғы нүктесі бірден көрінбейді деп болжайды.
Компания нарықтан өткенде, клиентпен жұмыс істегенде, ол нарықты үнемі зерттеп, соңғы В нүктесін өзгертеді. Оның үстіне компания өз бағытын жиі өзгерткен сайын, соңында ол табысты болады, өйткені ол көбірек нарықты таңдайды. тауашалар.
Стратегияны мен жақында білген қызықты компания көрсетеді. One Box Shave — қораптағы ұстаралар мен қырыну керек-жарақтарына жазылуды жеткізу қызметі. Олар әртүрлі клиенттер үшін өздерінің «қораптарын» қалай реттеуге болатынын біледі. Бұл белгілі бір бағдарламалық жасақтама арқылы жасалады, содан кейін ол тапсырысты өнімді шығаратын корей зауытына жібереді.
Бұл өнімді Unilever 1 миллиард долларға сатып алған. Қазір ол Gillette-пен бәсекеге түсіп, американдық нарықтағы тұтынушылардың айтарлықтай үлесін тартып алды. One Box Shave былай дейді:
— 4 пышақ? Шынайысың ба? Бұл не үшін қажет - бұл қырыну сапасын жақсартпайды. Арнайы таңдалған крем, хош иіс және екі жүзі бар жоғары сапалы ұстара сол ақымақ 4 Gillette жүзіне қарағанда әлдеқайда көп мәселені шешеді! Жақында 10-ға жетеміз бе?
Дүние осылай өзгереді. Unilever оларда мұны істеуге мүмкіндік беретін керемет IT жүйесі бар деп мәлімдейді. Соңында бұл тұжырымдамаға ұқсайды Нарыққа шығу уақыты, бұл туралы ешкім әлі айтпаған.
Уақытты нарыққа шығарудың мәні біз қаншалықты жиі орналастыратынымызда емес. Сіз жиі қолдануға болады, бірақ шығару циклдері ұзақ болады. Егер үш айлық босату циклдері бір-бірінің үстіне қойылса, оларды аптасына ауыстырса, компания аптасына бір рет орналастырып жатқан сияқты көрінеді. Ал идеядан түпкілікті жүзеге асыруға дейін 3 ай уақыт кетеді.
Нарыққа дейін уақыт – идеядан түпкілікті іске асыруға дейінгі уақытты азайту.
Бұл жағдайда бағдарламалық қамтамасыз ету нарықпен өзара әрекеттеседі. One Box Shave веб-сайты клиентпен осылай әрекеттеседі. Олардың сатушылары жоқ - келушілер басатын және тілектерін қалдыратын веб-сайт. Тиісінше, сайтта үнемі жаңа нәрсе жарияланып, тілектерге сәйкес жаңартылуы керек. Мысалы, Оңтүстік Кореяда олар Ресейге қарағанда басқаша қырынады және олар қарағайдың емес, мысалы, сәбіз мен ванильдің иісін ұнатады.
Сайттың мазмұнын жылдам өзгерту қажет болғандықтан, бағдарламалық жасақтаманы әзірлеу айтарлықтай өзгереді. Бағдарламалық құрал арқылы біз клиенттің не қалайтынын білуіміз керек. Бұрын біз мұны кейбір айналмалы жолдар арқылы, мысалы, бизнесті басқару арқылы білдік. Содан кейін біз оны жобалап, IT жүйесіне талаптарды енгіздік және бәрі керемет болды. Енді бәрі басқаша - бағдарламалық қамтамасыз етуді процеске қатысатын барлық адамдар, соның ішінде инженерлер әзірлейді, өйткені техникалық сипаттамалар арқылы олар нарықтың қалай жұмыс істейтінін біледі, сонымен қатар бизнеспен өз түсініктерімен бөліседі.
Мысалы, Qik-те біз адамдар серверге контактілер тізімдерін жүктеп салуды ұнататынын кенет білдік және олар бізге қосымшаны берді. Бастапқыда біз бұл туралы ойламадық. Классикалық компанияда бәрі бұл қате деп шешкен болар еді, өйткені спецификация оның керемет жұмыс істеуі керек екенін айтпады және әдетте тізеде орындалды, олар мүмкіндікті өшіріп: «Бұл ешкімге керек емес, Ең бастысы, негізгі функция жұмыс істейді.» . Ал технологиялық компания мұны мүмкіндік ретінде қарастырып, соған сәйкес бағдарламалық жасақтаманы өзгертуге кіріседі.
1968 жылы көреген жігіт Мелвин Конуэй келесі идеяны тұжырымдады.
Жүйені жасайтын ұйым сол ұйымның коммуникациялық құрылымын қайталайтын дизайнмен шектеледі.
Толығырақ айтсақ, басқа типтегі жүйелерді шығару үшін сізде басқа типтегі компанияда байланыс құрылымы болуы керек. Егер сіздің коммуникация құрылымыңыз жоғары иерархиялық болса, онда бұл өте жоғары нарыққа дейінгі уақыт көрсеткішін қамтамасыз ете алатын жүйелерді құруға мүмкіндік бермейді.
Оқы болады . Бұл DevOps мәдениетін немесе философиясын түсіну үшін маңызды, өйткені DevOps-та түбегейлі өзгеретін жалғыз нәрсе - командалар арасындағы байланыс құрылымы.
Процесс тұрғысынан, DevOps-қа дейін барлық кезеңдер: аналитика, әзірлеу, тестілеу, пайдалану сызықты болды.
DevOps жағдайында бұл процестердің барлығы бір уақытта орын алады.
Уақытты нарыққа шығару - мұны істеудің жалғыз жолы. Ескі процесте жұмыс істеген адамдар үшін бұл біршама ғарыштық және әдетте солай көрінеді.
Неліктен сізге DevOps керек?
Сандық өнімді әзірлеу үшін. Егер сіздің компанияңызда цифрлық өнім болмаса, DevOps қажет емес - бұл өте маңызды.
DevOps бағдарламалық қамтамасыз етуді дәйекті өндірудің жылдамдық шектеулерін еңсереді. Онда барлық процестер бір уақытта жүреді.
Қиындық артады. DevOps евангелистері сізге бағдарламалық жасақтаманы шығаруды жеңілдететінін айтқанда, бұл бос сөз.
DevOps көмегімен істер күрделене түседі.
Avito стендіндегі конференцияда сіз Docker контейнерін орналастырудың қандай екенін көре аласыз - бұл шындыққа жанаспайтын тапсырма. Күрделілігі қиын болады; бір уақытта көптеген доптарды жонглёрлеуге тура келеді.
DevOps компаниядағы процесс пен ұйымды толығымен өзгертеді — дәлірек айтқанда, DevOps емес, цифрлық өнім өзгереді. DevOps-ке келу үшін сізге әлі де бұл процесті толығымен өзгерту керек.
Маманға арналған сұрақтар
Сенде не бар? Компанияда жұмыс істеп, маман ретінде даму барысында өзіңізге қоятын сұрақтар.
Сізде цифрлық өнімді жасау стратегиясы бар ма? Егер бар болса, бұл қазірдің өзінде жақсы. Бұл сіздің компанияңыздың DevOps-ке көшіп жатқанын білдіреді.
Сіздің компанияңыз цифрлық өнімді жасап жатыр ма? Бұл DevOps тұрғысынан тағы да басқа деңгейге көтеріліп, қызықтырақ әрекет жасай алатыныңызды білдіреді. Мен тек осы тұрғыдан айтып отырмын.
Сіздің компанияңыз цифрлық өнім тауашасында нарық көшбасшыларының бірі ме? Spotify, Yandex, Uber – қазір технологиялық прогрестің шыңында тұрған компаниялар.
Өзіңізге осы сұрақтарды қойыңыз, егер барлық жауаптар жоқ болса, онда бұл компанияда DevOps қолданбауыңыз керек шығар. Егер сіз үшін DevOps тақырыбы шынымен қызықты болса, мүмкін... басқа компанияға ауысуыңыз керек пе? Егер сіздің компанияңыз DevOps-ке кіргісі келсе, бірақ сіз барлық сұрақтарға «Жоқ» деп жауап берсеңіз, бұл ешқашан өзгермейтін әдемі мүйізтұмсық сияқты.
ұйым
Мен айтқанымдай, Конвей заңына сәйкес компанияның ұйымы өзгереді. Мен DevOps-тың ұйымдық тұрғыдан компанияға енуіне не кедергі болатынынан бастайын.
«Ұңғымалар» мәселесі
Ағылшынның «Сило» сөзі мұнда орыс тіліне «well» деп аударылған. Бұл мәселенің мәні мынада командалар арасында ақпарат алмасу жоқ. Әрбір команда шарлау үшін ортақ карта жасамай-ақ, өз тәжірибесін терең зерттейді.
Бұл маған Мәскеуге жаңадан келген және метро картасын қалай шарлау керектігін әлі білмейтін адамды еске түсіреді. Мәскеуліктер әдетте өз аймағын өте жақсы біледі және бүкіл Мәскеуде метро картасы арқылы шарлай алады. Мәскеуге бірінші рет келгенде, сізде мұндай дағды жоқ және сіз жай ғана бағдарсыз қаласыз.
DevOps осы бағдарсыздық сәтінен өтуді және барлық бөлімдердің ортақ өзара әрекеттесу картасын құру үшін бірге жұмыс істеуін ұсынады.
Бұған екі фактор кедергі келтіреді.
Корпоративтік басқару жүйесінің салдары. Ол жеке иерархиялық «ұңғымаларда» салынған. Мысалы, бұл жүйені қолдайтын компанияларда белгілі бір KPI бар. Екінші жағынан, өз тәжірибесінің шегінен шығу және бүкіл жүйені шарлау қиынға соғатын адамның миы кедергі жасайды. Бұл жай ғана ыңғайсыз. Бангкок әуежайында екеніңізді елестетіп көріңіз - сіз тез арада жол таба алмайсыз. DevOps-ті шарлау да қиын, сондықтан адамдар оған жету үшін нұсқаулық табу керек дейді.
Ең бастысы, DevOps рухымен сусындаған, Фаулерді және басқа да көптеген кітаптарды оқыған инженер үшін «ұңғыма» мәселесі мынада көрінеді: «ұңғымалар» сізге «айқын» нәрселерді жасауға мүмкіндік бермейді. Біз DevOps Мәскеуден кейін жиі жиналамыз, бір-бірімізбен сөйлесеміз және адамдар шағымданады:
— Біз жай ғана CI-ді іске қосқымыз келді, бірақ бұл менеджментке қажет емес болып шықты.
Бұл дәл болғандықтан болады CI и Үздіксіз жеткізу процесі көптеген емтихандардың шекарасында. Ұйымдастыру деңгейіндегі «құдық» мәселесін жай ғана еңсермей, сіз не істесеңіз де, қаншалықты қайғылы болса да алға баса алмайсыз.
Компаниядағы процестің әрбір қатысушысы: бэкенд және фронтенді әзірлеушілер, тестілеу, DBA, операция, желі, өз бағытында қазып алады және менеджерден басқа ешкімде ортақ карта жоқ, ол қандай да бір жолмен оларды бақылайды және «бөлу» көмегімен басқарады. және жеңу» әдісі.
Адамдар кейбір жұлдыздар немесе жалаулар үшін күресуде, әркім өз тәжірибесін қазып жатыр.
Нәтижесінде, осының бәрін біріктіріп, ортақ құбыр салу міндеті туындап, жұлдыздар мен жалаулар үшін күресудің қажеті жоқ болғанда, сұрақ туындайды - бәрібір не істеу керек? Біз қандай да бір жолмен келісімге келуіміз керек, бірақ мұны мектепте ешкім үйреткен жоқ. Бізді мектептен оқытты: сегізінші сынып – уау! - жетінші сыныппен салыстырғанда! Бұл жерде де солай.
Сіздің компанияңызда да солай ма?
Мұны тексеру үшін өзіңізге келесі сұрақтарды қоюға болады.
Топтар жалпы құралдарды пайдаланады және сол жалпы құралдарға өзгерістер енгізуге үлес қосады ма?
Командалар қаншалықты жиі қайта құрылады — бір команданың кейбір мамандары басқа командаға ауысады? Бұл DevOps ортасында қалыпты жағдайға айналады, өйткені кейде адам басқа сараптама саласы не істеп жатқанын түсінбейді. Ол басқа бөлімге ауысады, екі апта бойы сол жерде жұмыс істейді, өзіне бағдар және осы бөліммен өзара әрекеттесу картасын жасайды.
Өзгеріс комитетін құрып, өзгертуге бола ма? Әлде жоғары басшылық пен бағыттың мықты қолын қажет ете ме? Мен жақында Facebook-те бір аз танымал банк құралдарды тапсырыстар арқылы қалай жүзеге асырып жатқанын жаздым: біз тапсырыс жазамыз, оны бір жылға орындаймыз және не болатынын көреміз. Бұл, әрине, ұзақ және қайғылы.
Менеджерлер үшін компанияның жетістіктерін ескермей, жеке жетістіктерді алу қаншалықты маңызды?
Егер сіз осы сұрақтарға өзіңіз жауап берсеңіз, сіздің компанияңызда мұндай мәселе бар-жоғы анық болады.
Инфрақұрылым код ретінде
Бұл мәселе шешілгеннен кейін, DevOps-та онсыз алға жылжу қиын болатын бірінші маңызды тәжірибе инфрақұрылым код ретінде.
Көбінесе инфрақұрылым код ретінде келесідей қабылданады:
— Барлығын bash-та автоматтандырайық, админдердің қолмен жұмысы аз болуы үшін өзімізді сценарийлермен жабамыз!
Бірақ бұл олай емес.
Инфрақұрылым код ретінде сіз жұмыс істейтін АТ жүйесін оның күйін үнемі түсіну үшін код түрінде сипаттайтыныңызды білдіреді.
Басқа командалармен бірге сіз барлығы түсінетін және шарлау мен шарлай алатын код түрінде карта жасайсыз. Оның не істегені маңызды емес - Chef, Ansible, Salt немесе Kubernetes-те YAML файлдарын пайдалану - ешқандай айырмашылық жоқ.
Конференцияда 2GIS әріптесі Кубернетес үшін жеке жүйелердің құрылымын сипаттайтын өздерінің ішкі заттарын қалай жасағанын айтты. 500 жүйені сипаттау үшін оларға осы сипаттаманы жасайтын бөлек құрал қажет болды. Бұл сипаттама болған кезде, әркім бір-бірімен тексере алады, өзгерістерді бақылай алады, оны қалай өзгертуге және жақсартуға болады, не жетіспейді.
Келісемін, жеке bash сценарийлері әдетте бұл түсінікті қамтамасыз етпейді. Мен жұмыс істеген компаниялардың бірінде тіпті «тек жазу» сценарийінің атауы болды - сценарий жазылған кезде, бірақ оны оқу мүмкін емес. Менің ойымша, бұл сізге де таныс.
Инфрақұрылым код сияқты инфрақұрылымның ағымдағы күйін сипаттайтын код. Көптеген өнім, инфрақұрылым және қызмет көрсету топтары осы кодта бірге жұмыс істейді және ең бастысы, олардың барлығы осы кодтың қалай жұмыс істейтінін түсінуі керек.
Код ең жақсы кодтық тәжірибелерге сәйкес сақталады: бірлескен әзірлеу, кодты шолу, XP-бағдарламалау, тестілеу, тарту сұраулары, кодтық инфрақұрылымдарға арналған CI - мұның бәрі қолайлы және пайдалануға болады.
Код барлық инженерлер үшін ортақ тілге айналады.
Кодтағы инфрақұрылымды өзгерту көп уақытты қажет етпейді. Иә, инфрақұрылымдық кодтың техникалық қарызы да болуы мүмкін. Әдетте командалар оны спагетти коды сияқты жазатын сценарийлер немесе тіпті Ansible түрінде «инфрақұрылымды код ретінде» енгізе бастағаннан кейін бір жарым жылдан кейін кездестіреді, сонымен қатар олар араласуға bash сценарийлерін тастайды!
маңызды: Егер сіз бұл материалды әлі қолданып көрмесеңіз, оны есте сақтаңыз Ansible bash емес! Құжаттаманы мұқият оқып шығыңыз, олар туралы не жазғанын зерттеңіз.
Инфрақұрылым код ретінде инфрақұрылымдық кодты бөлек қабаттарға бөлу болып табылады.
Біздің компанияда біз 3 негізгі қабатты ажыратамыз, олар өте түсінікті және қарапайым, бірақ олардың саны көбірек болуы мүмкін. Сіз өзіңіздің инфрақұрылымдық кодыңызды қарап, сізде бұл жағдайдың бар-жоғын айта аласыз. Ешбір қабат ерекшеленбесе, біраз уақыт алып, аздап қайта өңдеу керек.
негізгі қабат - осылайша ОЖ, сақтық көшірмелер және басқа да төмен деңгейлі заттар конфигурацияланады, мысалы, Kubernetes базалық деңгейде қалай орналастырылады.
Қызмет көрсету деңгейі - бұл сіз әзірлеушіге ұсынатын қызметтер: қызмет ретінде тіркеу, қызмет ретінде мониторинг, қызмет ретінде деректер базасы, қызмет ретінде балансизатор, қызмет ретінде кезек, қызмет ретінде үздіксіз жеткізу - жеке командалар көрсететін қызметтер жиынтығы дамуын қамтамасыз ете алады. Мұның барлығы конфигурацияны басқару жүйесіндегі бөлек модульдерде сипатталуы керек.
Қолданбалар жасалатын қабат және олардың алдыңғы екі қабаттың үстіне қалай ашылатынын сипаттайды.
Бақылау сұрақтары
Сіздің компанияңыздың жалпы инфрақұрылымдық репозиторийі бар ма? Сіз өзіңіздің инфрақұрылымыңыздағы техникалық қарызды басқарасыз ба? Сіз инфрақұрылым репозиторийінде әзірлеу тәжірибесін пайдаланасыз ба? Сіздің инфрақұрылымыңыз қабаттарға бөлінген бе? Base-service-APP диаграммасын тексеруге болады. Өзгеріс жасау қаншалықты қиын?
Өзгерістерді енгізу үшін бір жарым күн қажет болғанын байқасаңыз, бұл сіздің техникалық қарызыңыз бар екенін және онымен жұмыс істеу керек екенін білдіреді. Сіз инфрақұрылымдық кодыңыздағы техникалық қарызға тап болдыңыз. Кейбір CCTL-ді өзгерту үшін инфрақұрылымдық кодтың жартысын қайта жазу керек болған кездегі көптеген оқиғалар есімде, өйткені шығармашылық пен бәрін автоматтандыруға деген ұмтылыс барлық жерде барлық жерде коррозияға ұшырап, барлық тұтқалар алынып тасталды және қайта өңдеу қажет.
Үздіксіз жеткізу
Дебет пен кредитті салыстырайық. Алдымен инфрақұрылымның сипаттамасы келеді, ол өте қарапайым болуы мүмкін. Барлығын егжей-тегжейлі сипаттаудың қажеті жоқ, бірақ онымен жұмыс істеу үшін кейбір негізгі сипаттама қажет. Әйтпесе, одан әрі үздіксіз жеткізумен не істеу керек екені белгісіз. Бұл тәжірибелердің барлығы DevOps-ке келген кезде бір уақытта пайда болады, бірақ ол сізде не бар екенін және оны қалай басқару керектігін түсінуден басталады. Бұл код ретінде инфрақұрылымның дәл тәжірибесі.
Сізде бар екені және оны қалай басқаруға болатыны белгілі болғаннан кейін, әзірлеуші кодын өндіріске мүмкіндігінше тезірек жіберу жолын анықтауға кірісесіз. Әзірлеушімен бірге айтқым келеді - біз «ұңғыма» мәселесі туралы есімізде, яғни мұны жеке адамдар емес, команда ойлап табады.
Біз бірге болғанда Ваня Евтухович бірінші кітабын көрді Джез Кішіпейіл және авторлар топтары «Үздіксіз жеткізу», 2009 жылы шыққан, біз оның атауын орыс тіліне қалай аударуға болатынын ұзақ ойладық. Олар оны «Үнемі жеткізу» деп аударғысы келді, бірақ, өкінішке орай, «Үздіксіз жеткізу» деп аударылды. Меніңше, біздің атымызда қысыммен орысша бірдеңе бар сияқты.
Тұрақты жеткізу құралдары
Өнім репозиторийіндегі кодты әрқашан өндіріске жүктеп алуға болады. Ол дефляцияға ұшырамауы мүмкін, бірақ ол әрқашан оған дайын. Тиісінше, сіз әрқашан құйрық сүйегіңіздің астындағы кейбір алаңдаушылықты түсіндіру қиын сезіммен код жазасыз. Ол көбінесе инфрақұрылым кодын шығарған кезде пайда болады. Бұл қандай да бір алаңдаушылық сезімі болуы керек - бұл кодты сәл басқаша жазуға мүмкіндік беретін ми процестерін іске қосады. Бұл әзірлеу барысындағы ережелерде жазылуы керек.
Жүйелі түрде жеткізу үшін сізге инфрақұрылым платформасы арқылы жұмыс істейтін артефакт пішімі қажет. Егер сіз инфрақұрылымдық платформаға әртүрлі форматтағы «өмірлік қалдықтарды» тастасаңыз, онда ол біртұтас болады, оны ұстау қиынға соғады және техникалық қарыз мәселесі туындайды. Артефакттың пішімін теңестіру керек - бұл да ұжымдық міндет: бәріміз жиналып, миымызды шуылдатып, осы форматты ойлап табуымыз керек.
Артефакт үздіксіз жетілдіріліп отырады және жеткізу құбыры арқылы қозғалған кезде өндіріс ортасына сәйкес өзгереді. Артефакт құбыр бойымен қозғалғанда, ол үнемі өндіріске енгізген артефакт кездесетін нәрсеге ұқсас кейбір қолайсыз нәрселерге тап болады. Егер классикалық дамуда мұны шығаруды жүзеге асыратын жүйелік әкімші жасаса, онда DevOps процесінде бұл үнемі орын алады: мұнда олар оны кейбір сынақтармен сынады, мұнда олар оны Kubernetes кластеріне тастады, ол азды-көпті ұқсас. өндіріске, содан кейін олар кенеттен жүктеме сынағы бастады.
Бұл Pac-Man ойынын еске түсіреді - артефакт қандай да бір оқиғадан өтеді. Сонымен қатар, кодтың шын мәнінде оқиға арқылы өтетінін және оның сіздің өндірісіңізге қандай да бір түрде қатысты екенін бақылау маңызды. Өндірістегі оқиғаларды Үздіксіз жеткізу процесіне апаруға болады: бірдеңе құлаған кезде осылай болды, енді осы сценарийді жүйе ішінде бағдарламалайық. Әр жолы код осы сценарийден өтеді және келесі жолы бұл мәселеге тап болмайсыз. Сіз бұл туралы клиентке жеткеннен әлдеқайда ерте біле аласыз.
Әртүрлі орналастыру стратегиялары. Мысалы, кодты әртүрлі клиенттерде әртүрлі сынау, кодтың қалай жұмыс істейтіні туралы ақпарат алу және 100 миллион пайдаланушыға шығарылғаннан әлдеқайда ертерек алу үшін AB тестілеуін немесе канарлық орналастыруларды пайдаланасыз.
«Дәйекті түрде жеткізу» осылай көрінеді.
Жеткізу процесі Dev, CI, Test, PreProd, Prod жеке орта емес, бұл артефакт өтетін отқа төзімді қосындылары бар сатылар немесе станциялар.
Егер сізде Base Service APP ретінде сипатталған инфрақұрылым коды болса, ол көмектеседі барлық сценарийлерді ұмытпаңыз, және оларды осы артефакт үшін код ретінде жазыңыз, артефакті насихаттау және оны барған сайын өзгертіңіз.
Өзін-өзі тексеру сұрақтары
95% жағдайда мүмкіндікті сипаттаудан бастап өндіріске шығаруға дейінгі уақыт бір аптадан аз? Құбырдың әрбір сатысында артефакттың сапасы жақсара ма? Оның басынан өткен оқиға бар ма? Сіз әртүрлі орналастыру стратегияларын қолданасыз ба?
Егер барлық жауаптар иә болса, онда сіз кереметсіз! Жауаптарыңызды түсініктемелерде жазыңыз - мен қуаныштымын).
кері байланыс
Бұл ең қиын тәжірибе. DevOpsConf конференциясында Infobip әріптесі бұл туралы айтып, сөзінде аздап шатастырды, өйткені бұл шынымен де бәрін бақылау керек екендігі туралы өте күрделі тәжірибе!
Мысалы, бұрыннан мен Qik-те жұмыс істегенімде, біз бәрін бақылау керек екенін түсіндік. Біз мұны жасадық және қазір Zabbix-те 150 000 зат бар, олар үнемі бақыланады. Бұл қорқынышты болды, техникалық директор саусағын ғибадатханасына бұрады:
- Балалар, неге түсініксіз нәрсемен серверді зорлап жатырсыңдар?
Бірақ содан кейін бұл өте керемет стратегия екенін көрсететін оқиға болды.
Қызметтердің бірі үнемі істен шыға бастады. Бастапқыда ол бұзылған жоқ, бұл қызық, онда код қосылмаған, өйткені ол іс жүзінде ешқандай іскерлік функционалдығы жоқ негізгі брокер болды - ол жай ғана жеке қызметтер арасында хабарламалар жіберді. Қызмет 4 ай бойы өзгермеді және кенеттен ол «Сегментация ақауы» қателігімен бұзыла бастады.
Біз таң қалдық, диаграммаларымызды Zabbix-те аштық және бір жарым апта бұрын осы брокер пайдаланатын API қызметіндегі сұраулардың әрекеті қатты өзгергені белгілі болды. Әрі қарай белгілі бір хабарлама түрін жіберу жиілігі өзгергенін көрдік. Кейінірек бұл Android клиенттері екенін білдік. Біз сұрадық:
— Балалар, бір жарым апта бұрын сендерге не болды?
Жауап ретінде біз олардың UI дизайнын қалай өзгерткені туралы қызықты оқиғаны естідік. Біреу HTTP кітапханасын өзгертті деп бірден айтуы екіталай. Android тұтынушылары үшін бұл ваннада сабынды ауыстыру сияқты - олар жай ғана есіне алмайды. Нәтижесінде 40 минуттық әңгімеден кейін біз олардың HTTP кітапханасын өзгерткенін және оның әдепкі уақыттарының өзгергенін білдік. Бұл API серверіндегі трафик әрекетінің өзгеруіне әкелді, бұл брокер ішінде жарысты тудырған жағдайға әкелді және ол бұзыла бастады.
Терең бақылаусыз мұны ашу әдетте мүмкін емес. Егер ұйымда «құдық» мәселесі әлі де болса, бәрі бір-біріне ақша лақтырса, бұл жылдар бойы өмір сүре алады. Сіз жай ғана серверді қайта іске қосасыз, себебі мәселені шешу мүмкін емес. Сізде бар барлық оқиғаларды бақылағанда, қадағалағанда, бақылағанда және бақылауды тестілеу ретінде пайдаланған кезде - кодты жазыңыз және оны қалай бақылау керектігін бірден код түрінде көрсетіңіз (бізде код ретінде инфрақұрылым бар), бәрі анық болады алақанда. Тіпті мұндай күрделі мәселелер оңай қадағаланады.
Өндірісте емес, жеткізу процесінің әр кезеңінде артефактпен не болатыны туралы барлық ақпаратты жинаңыз.
Мониторингті CI жүйесіне жүктеңіз, сонда кейбір негізгі нәрселер сонда көрінеді. Кейінірек сіз оларды Test, PredProd және жүктеу сынақтарында көресіз. Барлық кезеңдерде ақпаратты жинаңыз, тек метрика, статистика ғана емес, сонымен қатар журналдар: қолданбаның қалай шығарылғаны, ауытқулар - барлығын жинаңыз.
Әйтпесе, оны анықтау қиын болады. Мен DevOps күрделірек екенін айттым. Бұл күрделілікпен күресу үшін сізде қалыпты аналитика болуы керек.
Өзін-өзі бақылауға арналған сұрақтар
Бақылау және тіркеу сіз үшін әзірлеу құралы ма? Кодты жазу кезінде әзірлеушілеріңіз, соның ішінде сіз оны қалай бақылауға болатынын ойлайсыз ба?
Сіз тұтынушылардан проблемалар туралы естідіңіз бе? Сіз клиентті бақылау мен тіркеуден жақсы түсінесіз бе? Сіз жүйені бақылау мен тіркеуден жақсы түсінесіз бе? Жүйедегі тренд өсіп келе жатқанын көріп, тағы 3 аптадан кейін бәрі өлетінін түсінгеніңіз үшін жүйені өзгертесіз бе?
Осы үш құрамдас бөлікке ие болғаннан кейін сіз өзіңіздің компанияңызда қандай инфрақұрылымдық платформа бар екенін ойлай аласыз.
Инфрақұрылымдық платформа
Мәселе бұл әр компанияда бар әр түрлі құралдар жиынтығында емес.
Инфрақұрылымдық платформаның мәні мынада: барлық командалар осы құралдарды пайдаланады және оларды бірге жасайды.
Инфрақұрылымдық платформаның жеке бөліктерін дамытуға жауапты жеке командалар бар екені анық. Бірақ сонымен бірге әрбір инженер инфрақұрылымдық платформаны дамытуға, орындауға және жылжытуға жауапты. Ішкі деңгейде ол жалпы құралға айналады.
Барлық командалар инфрақұрылымдық платформаны әзірлейді және оны жеке IDE ретінде мұқият қарастырады. IDE-де сіз бәрін жақсы және жылдам ету үшін әртүрлі плагиндерді орнатасыз және жылдам пернелерді конфигурациялайсыз. Sublime, Atom немесе Visual Studio Code қолданбаларын ашқанда, код қателері пайда болады және сіз мүлдем жұмыс істеу мүмкін емес екенін түсінесіз, сіз бірден қайғырасыз және IDE-ді жөндеуге жүгіресіз.
Инфрақұрылымдық платформаңызды дәл осылай өңдеңіз. Егер сізде ақау бар екенін түсінсеңіз, оны өзіңіз түзете алмасаңыз, өтініш қалдырыңыз. Қарапайым нәрсе болса, оны өзіңіз өңдеңіз, тарту сұрауын жіберіңіз, жігіттер оны қарастырып, қосады. Бұл әзірлеушінің басындағы инженерлік құралдарға сәл басқаша көзқарас.
Инфрақұрылымдық платформа сапаны үнемі жақсарта отырып, артефактты әзірлеуден клиентке беруді қамтамасыз етеді. IP өндірісте кодпен болатын оқиғалар жиынтығымен бағдарламаланған. Даму жылдарында мұндай әңгімелер өте көп, олардың кейбіреулері бірегей және тек сізге қатысты - оларды Google арқылы іздеу мүмкін емес.
Бұл кезде инфрақұрылымдық платформа сіздің бәсекелестік артықшылығыңызға айналады, өйткені оның ішінде бәсекелестің құралында жоқ нәрсе бар. IP неғұрлым тереңірек болса, нарыққа шығу уақыты бойынша бәсекелестік артықшылығыңыз соғұрлым жоғары болады. Осы жерде пайда болады жеткізушінің құлыптау мәселесі: Сіз басқа біреудің платформасын ала аласыз, бірақ басқа біреудің тәжірибесін пайдалана отырып, оның сізге қаншалықты маңызды екенін түсінбейсіз. Иә, әрбір компания Amazon сияқты платформа құра алмайды. Бұл компанияның тәжірибесі оның нарықтағы позициясына сәйкес келетін қиын сызық және сіз онда сатушы құлпын пайдалана алмайсыз. Бұл туралы ойлану да маңызды.
Схема
Бұл DevOps компаниясында барлық тәжірибелер мен процестерді орнатуға көмектесетін инфрақұрылымдық платформаның негізгі диаграммасы.
Оның неден тұратынын қарастырайық.
Ресурстарды басқару жүйесі, ол процессорды, жадты, дискіні қолданбаларды және басқа қызметтерді қамтамасыз етеді. Мұның үстіне - төмен деңгейдегі қызметтер: мониторинг, тіркеу, CI/CD қозғалтқышы, артефакттарды сақтау, жүйелік код ретінде инфрақұрылым.
Жоғары деңгейдегі қызметтер: қызмет ретінде дерекқор, қызмет ретінде кезек, қызмет ретінде жүктеме балансы, қызмет ретінде кескін өлшемін өзгерту, қызмет ретінде үлкен деректер зауыты. Мұның үстіне - клиентке үнемі өзгертілетін кодты жеткізетін құбыр желісі.
Сіз бағдарламалық құралдың клиент үшін қалай жұмыс істейтіні туралы ақпаратты аласыз, оны өзгертесіз, осы кодты қайта енгізесіз, ақпарат аласыз - осылайша сіз инфрақұрылымдық платформаны да, бағдарламалық құралды да үнемі дамытасыз.
Диаграммада жеткізу құбыры көптеген кезеңдерден тұрады. Бірақ бұл мысал ретінде келтірілген схемалық диаграмма - оны бір-бірлеп қайталаудың қажеті жоқ. Кезеңдер қызметтермен қызметтер сияқты өзара әрекеттеседі — платформаның әрбір кірпішінің өзіндік тарихы бар: ресурстар қалай бөлінген, қолданба қалай іске қосылған, ресурстармен жұмыс істейді, бақыланады және өзгереді.
Платформаның әрбір бөлігінің оқиғасы бар екенін түсіну маңызды және өзіңізден бұл кірпіштің қандай оқиғаны көтеретінін сұраңыз, мүмкін оны лақтырып, үшінші тарап қызметімен ауыстыру керек. Мысалы, кірпіштің орнына Окметрді орнатуға болады ма? Мүмкін, жігіттер бұл тәжірибені бізден әлдеқайда көп дамытқан шығар. Бірақ мүмкін емес - мүмкін бізде бірегей тәжірибе бар, біз Prometheus орнатып, оны одан әрі дамытуымыз керек.
Платформаны құру
Бұл күрделі коммуникациялық процесс. Сізде негізгі тәжірибелер болған кезде, сіз талаптар мен стандарттарды әзірлейтін әртүрлі инженерлер мен мамандар арасындағы байланысты бастайсыз және оларды әртүрлі құралдар мен тәсілдерге үнемі өзгерте аласыз. Бұл жерде бізде DevOps-та бар мәдениет маңызды.
Мәдениетпен бәрі өте қарапайым - бұл ынтымақтастық пен қарым-қатынас туралы, яғни бір-бірімен ортақ салада жұмыс істеуге, бір аспапты бірге ұстауға деген ұмтылыс. Мұнда зымыран туралы ғылым жоқ - бәрі өте қарапайым, банальды. Мәселен, бәріміз кіреберісте тұрып, оны таза ұстаймыз – мәдениеттің осындай деңгейі.
Сенде не бар?
Тағы да, өзіңізге сұрақтар қоюға болады.
Инфрақұрылымдық платформа арналды ма? Оның дамуына кім жауапты? Сіз өзіңіздің инфрақұрылымдық платформаңыздың бәсекелестік артықшылықтарын түсінесіз бе?
Сіз өзіңізге осы сұрақтарды үнемі қойып отыруыңыз керек. Егер бірдеңе үшінші тарап қызметтеріне берілуі мүмкін болса, оны беру керек; егер үшінші тарап қызметі сіздің қозғалысыңызға тосқауыл қоя бастаса, онда сіз өз ішінде жүйені құруыңыз керек.
Сонымен, DevOps...
... бұл күрделі жүйе, ол болуы керек:
- Сандық өнім.
- Осы сандық өнімді әзірлейтін бизнес модульдері.
- Код жазатын өнім топтары.
- Үздіксіз жеткізу тәжірибелері.
- Платформалар қызмет ретінде.
- Инфрақұрылым қызмет ретінде.
- Инфрақұрылым код ретінде.
- DevOps жүйесіне енгізілген сенімділікті сақтауға арналған бөлек тәжірибелер.
- Барлығын сипаттайтын кері байланыс тәжірибесі.
Сіз бұл диаграмманы пайдалана аласыз, онда сіздің компанияңызда қандай да бір түрде бар нәрсені бөлектей аласыз: ол әзірленді ме немесе әлі де әзірлеу керек.
Бір-екі аптада бітеді . RIT++ бөлігі ретінде. Конференцияға келіңіз, онда сіз үздіксіз жеткізу, код ретінде инфрақұрылым және DevOps трансформациясы туралы көптеген керемет есептер таба аласыз. , соңғы баға мерзімі 20 мамыр
Ақпарат көзі: www.habr.com