DevOps аныктамасы абдан татаал, ошондуктан биз бул тууралуу талкууну ар бир жолу кайра башынан баштообуз керек. Бул тема боюнча бир гана Хабреде миңдеген басылмалар бар. Бирок, эгер сиз муну окуп жатсаңыз, DevOps деген эмне экенин билесиз. Анткени мен андай эмесмин. Салам менин атым Александр Титов (@), биз жөн гана DevOps жөнүндө сүйлөшөбүз жана мен өз тажрыйбам менен бөлүшөм.
Мен өз окуямды кантип пайдалуу кылуу жөнүндө көптөн бери ойлонуп жүргөм, андыктан бул жерде көптөгөн суроолор пайда болот - мен өзүмө жана биздин компаниянын кардарларына берген суроолорум. Бул суроолорго жооп берүү менен, түшүнүү жакшыраак болот. Мен сизге DevOps эмне үчүн керек экенин, менин көз карашым боюнча, бул эмне экенин жана менин көз карашым боюнча кайрадан DevOpsка өтүп жатканыңызды кантип түшүнүү керектигин айтып берем. Акыркы пункт суроолор аркылуу болот. Аларга өзүңүз жооп берүү менен, сиз компанияңыз DevOps тарапка жылып жатабы же кандайдыр бир деңгээлде көйгөйлөр барбы, түшүнө аласыз.
Бир убакта мен биригүү жана кошулуу толкундарын айдап жүрдүм. Биринчиден, мен Qik деп аталган кичинекей стартапта иштедим, андан кийин аны Skype деп аталган бир аз чоңураак компания, андан кийин Microsoft деген бир аз чоңураак компания сатып алды. Ошол учурда мен DevOps идеясы ар кандай өлчөмдөгү компанияларда кандайча өзгөрүп жатканын көрө баштадым. Ошондон кийин мен DevOps'ту рыноктук көз караш менен кароого кызыгып, кесиптештерим менен Express 42 компаниясын негиздедик. 6 жылдан бери биз рыноктун толкундары менен бара жатабыз.
Башка нерселердин арасында мен DevOps Moscow коомчулугунун уюштуруучуларынын биримин жана DevOps-Days 2017нин уюштуруучусумун, бирок 2018-жылды уюштурган жокмун. Express 42 көптөгөн компаниялар менен иштейт. Биз ал жерде DevOps-ту өстүрөбүз, анын кандай болуп жатканын көрүп, жыйынтык чыгарабыз, талдап жатабыз, бардыгына өз тыянактарыбызды айтабыз жана адамдарды DevOps тажрыйбасына үйрөтөбүз. Жалпысынан биз бул жагынан тажрыйбабызды жана тажрыйбабызды арттырууга бардык кучубузду жумшап жатабыз.
Эмне үчүн DevOps
Баарын ойлондурган биринчи суроо - эмне үчүн? Көптөр DevOps бул жөн гана автоматташтыруу же ар бир компанияда болгон окшош нерсе деп ойлошот.
— Бизде Үзгүлтүксүз интеграция болгон - бул бизде DevOps болгон дегенди билдирет жана мунун баары эмне үчүн керек? Чет олкодо жыргап журушот, бирок иштешибизге тоскоол болуп жатышат!
Коомчулуктун жана методологиянын 9 жылдык өнүгүүсү, бул дагы эле маркетинг жаркырагы эмес экени айкын болду, бирок ал эмне үчүн керек экендиги дагы эле ачык-айкын эмес. Ар кандай инструмент жана процесс сыяктуу эле, DevOps да акыры жете турган конкреттүү максаттарга ээ.
Мунун баары дүйнөнүн өзгөрүп жатканына байланыштуу. Ал ишканалык мамиледен алыстап, компаниялар кыялга карай түз жылып кеткенде, биздин Санкт-Петербургдук классик ырдагандай, А чекитинен В чекитине белгилүү стратегия боюнча, бул үчүн курулган белгилүү структура менен.
Негизи, IT тармагында бардыгы ушул ыкмага ылайык түзүлүшү керек. Бул жерде IT процесстерди автоматташтыруу үчүн гана колдонулат.
Автоматташтыруу тез-тез өзгөрбөйт, анткени компания жакшы тепселген жолго түшкөндө, эмнени өзгөртүү керек? Ал иштейт - ага тийбеңиз. Азыр дүйнөдөгү ыкмалар өзгөрүүдө жана 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тин компаниянын ичине киришине эмне тоскоол болот дегенден баштайм.
"Кудуктар" маселеси
Англисче «Сило» деген сөз бул жерде орусчага «жакшы» деп которулат. Бул маселенин мааниси мына ушунда бригадалардын ортосунда маалымат алмашуу жок. Ар бир команда багыттоо үчүн жалпы карта түзбөстөн, өзүнүн тажрыйбасын терең изилдейт.
Кандайдыр бир мааниде бул мага Москвага жаңы келген жана метро картасында кантип багыт алууну билбеген адамды эске салат. Москвалыктар, адатта, өз аймагын абдан жакшы билишет, жана бүт Москва метро картасын колдонуу менен багыт алат. Сиз Москвага биринчи жолу келгенде, сизде мындай жөндөм жок, жөн гана ориентациядан адашасыз.
DevOps бул адашуу учурунан өтүүнү жана жалпы өз ара аракеттенүү картасын түзүү үчүн чогуу иштешүүнү сунуштайт.
Буга эки фактор тоскоол болууда.
Корпоративдик башкаруу системасынын натыйжасы. Ал өзүнчө иерархиялык "кудуктарга" курулган. Мисалы, бул системаны колдогон компанияларда белгилүү бир KPI бар. Башка жагынан алганда, өз тажрыйбасынын чегинен чыгуу жана бүт системаны башкаруу кыйынга турган адамдын мээси жолго чыгат. Бул жөн эле ыңгайсыз. Бангкоктун аэропортунда экениңизди элестетиңиз - тез эле жол таба албайсыз. DevOps менен багыттоо да кыйын, ошондуктан адамдар ал жакка жетүү үчүн жол көрсөтүүчү табышыңыз керек дешет.
Бирок эң негизгиси, DevOps духуна сугарылган, Фаулерди жана башка бир топ китептерди окуган инженер үчүн "кудуктар" көйгөйү мындайча чагылдырылган. «скважиналар» «ачык-айкын» нерселерди жасоого жол бербейт. Биз DevOps Москвадан кийин көп чогулуп, бири-бирибиз менен сүйлөшөбүз жана адамдар нааразы болушат:
— Биз жөн гана CIди ишке киргизели дедик, бирок башкарууга анын кереги жок экен.
Бул так себеби болуп саналат CI и Үзгүлтүксүз жеткирүү процесси көптөгөн экспертизалардын чегинде турат. Жөн эле уюштуруу деңгээлиндеги «скважина» маселесин жеңбей туруп, эмне кылсаң да, канчалык кейиштүү болсоң да алдыга жыла албайсың.
Компаниядагы процесстин ар бир катышуучусу: backend жана frontend иштеп чыгуучулар, тестирлөө, DBA, операция, тармак, өз багытында казышат жана менеджерден башка эч кимдин жалпы картасы жок, ал кандайдыр бир жол менен аларды көзөмөлдөп, аларды "бөлүү" аркылуу башкарат. жана жеңүү» ыкмасы.
Адамдар кандайдыр бир жылдыздар же желектер үчүн күрөшүп жатышат, ар ким өз тажрыйбасын казып жатат.
Натыйжада, ушунун баарын бириктирип, жалпы түтүк куруу милдети келип, жылдыздар жана желектер үчүн күрөштүн кереги жок болуп калганда, суроо туулат – баары бир эмне кылуу керек? Кандайдыр бир макулдашууга келишибиз керек, бирок мектепте муну эч ким үйрөткөн эмес. Бизди мектептен бери окутушат: сегизинчи класс - вах! — жетинчи класска салыштырганда! Бул жерде да ошондой.
Сиздин компанияда да ушундайбы?
Муну текшерүү үчүн сиз өзүңүзгө төмөнкү суроолорду берсеңиз болот.
Командалар жалпы куралдарды колдонуп, ошол жалпы куралдарды өзгөртүүгө салым кошобу?
Бригадалар канча жолу кайра уюшу-лат — бир бригаданын кээ бир адистери башка бригадага оту-рушат? Бул DevOps чөйрөсүндө бул кадыресе көрүнүшкө айланат, анткени кээде адам башка адистик чөйрөсү эмне кылып жатканын түшүнө албайт. Ал башка бөлүмгө өтөт, ал жерде эки жума иштеп, өзүнө багыт картасын түзүп, бул бөлүм менен иштешет.
Өзгөртүү комитетин түзүп, бир нерсени өзгөртүүгө болобу? Же жогорку жетекчиликтин жана багыттын күчтүү колун талап кылабы? Мен жакында эле Фейсбукта бир аз белгилүү банк инструменттерди заказдар аркылуу кантип ишке ашырып жатканын жаздым: биз буйрук жазабыз, аны бир жыл аткарабыз жана эмне болорун көрөбүз. Бул, албетте, узак жана кайгылуу.
Жетекчилер үчүн компаниянын жетишкендиктерин эске албай туруп, жеке жетишкендиктерди алуу канчалык маанилүү?
Бул суроолорго өзүңүз жооп берсеңиз, сиздин компанияңызда ушундай көйгөй бар же жок экендиги айкын болот.
Код катары инфраструктура
Бул маселе чечилгенден кийин, биринчи маанилүү практика болуп саналат, ансыз DevOps менен алдыга жылуу кыйын код катары инфраструктура.
Көбүнчө инфраструктура код катары төмөнкүдөй кабыл алынат:
— Келгиле, баарын bash менен автоматташтыралы, админдердин кол менен иштөөсү аз болушу үчүн өзүбүздү скрипттер менен жаап алалы!
Бирок бул андай эмес.
Код катары инфраструктура сиз иштеген IT тутумун анын абалын дайыма түшүнүү үчүн код түрүндө сүрөттөгөнүңүздү билдирет.
Башка командалар менен бирге сиз код түрүндөгү картаны түзөсүз, аны баары түшүнө алат жана багыттоого жана багыттоого болот. Анын эмне кылганы маанилүү эмес - Chef, Ansible, Salt же Kubernetesте YAML файлдарын колдонуу - эч кандай айырма жок.
Конференцияда 2GISтин кесиптеши жеке системалардын түзүлүшүн сүрөттөгөн Kubernetes үчүн өздөрүнүн ички нерсесин кантип жасаганын айтып берди. 500 системаны сүрөттөө үчүн, алар бул сүрөттөлүштү жаратуучу өзүнчө курал керек болчу. Бул сүрөттөмө болгондо, ар бир адам бири-бири менен текшерип, өзгөрүүлөрдү көзөмөлдөй алат, аны кантип өзгөртүү жана жакшыртуу керек, эмне жетишпейт.
Макул, жеке баш скрипттери, адатта, бул түшүнүктү камсыз кылбайт. Мен иштеген компаниялардын биринде ал тургай сценарий жазылганда "жана жаз" деген аталыш бар болчу, бирок аны окууга мүмкүн болбой калды. Бул сизге да тааныш деп ойлойм.
Код сыяктуу инфраструктура инфраструктуранын учурдагы абалын сүрөттөгөн код. Көптөгөн продукт, инфраструктура жана тейлөө топтору бул коддун үстүндө бирге иштешет жана эң негизгиси, алардын баары бул код чындыгында кантип иштээрин түшүнүшү керек.
Код мыкты код практикасына ылайык сакталат: биргелешкен иштеп чыгуу, кодду карап чыгуу, XP-программалоо, тестирлөө, тартуу сурамдары, код инфраструктуралары үчүн CI - мунун баары ылайыктуу жана колдонсо болот.
Код бардык инженерлер үчүн жалпы тил болуп калат.
Коддогу инфраструктураны өзгөртүү көп убакытты талап кылбайт. Ооба, инфраструктуралык коддун техникалык карызы да болушу мүмкүн. Адатта, командалар аны спагетти коду сыяктуу жаза турган бир топ скрипт же Ansible түрүндө "код катары инфраструктураны" ишке ашыра баштагандан кийин бир жарым жылдан кийин көрүшөт, ошондой эле баш скрипттерин аралаштырышат!
маанилүү: Эгер сиз бул нерсени сынап көрө элек болсоңуз, анда муну эстеңиз Ansible bash эмес! Документти кунт коюп окуп чыгыңыз, алар бул жөнүндө эмне жазат.
Код катары инфраструктура инфраструктуралык коддун өзүнчө катмарларга бөлүнүшү.
Биздин компанияда биз 3 негизги катмарды айырмалайбыз, алар абдан түшүнүктүү жана жөнөкөй, бирок алар дагы көп болушу мүмкүн. Сиз инфраструктуралык кодуңузду карап, сизде мындай абал бар же жок экенин айта аласыз. Эгерде эч кандай катмарлар баса белгиленбесе, анда сиз бир аз убакыт алып, бир аз рефакторациялооңуз керек.
негизги катмар - ОС, камдык көчүрмөлөр жана башка төмөнкү деңгээлдеги нерселер ушундай конфигурацияланат, мисалы, Kubernetes базалык деңгээлде кантип орнотулат.
Тейлөө деңгээли - бул сиз иштеп чыгуучуга көрсөткөн кызматтар: кызмат катары каттоо, кызмат катары мониторинг, кызмат катары маалымат базасы, кызмат катары балансизатор, кызмат катары кезек, кызмат катары үзгүлтүксүз жеткирүү - жеке командалар көрсөткөн кызматтардын топтому өнүгүүсүн камсыздай алат. Мунун баары конфигурацияны башкаруу тутумуңуздагы өзүнчө модулдарда сүрөттөлүшү керек.
Тиркемелер жасалган катмар жана алар мурунку эки катмардын үстүнө кантип ачыларын сүрөттөйт.
Контролдук суроолор
Сиздин компанияңызда жалпы инфраструктуралык репозиторий барбы? Сиз инфраструктураңыздагы техникалык карызды башкарып жатасызбы? Сиз инфраструктуралык репозиторийде өнүктүрүү тажрыйбаларын колдоносузбу? Сиздин инфраструктураңыз катмарларга бөлүнгөнбү? Сиз Base-service-APP диаграммасын текшере аласыз. Өзгөртүү канчалык кыйын?
Өзгөртүүлөрдү киргизүү үчүн бир жарым күн талап кылынганын байкасаңыз, бул сиздин техникалык карызыңыз бар экенин жана аны менен иштешиңиз керек экенин билдирет. Сиз жаңы эле инфраструктуралык кодексиңиздеги техникалык карызга туш болдуңуз. Мен кээ бир CCTLди өзгөртүү үчүн инфраструктуралык коддун жарымын кайра жазуу керек болгон көптөгөн окуяларды эстейм, анткени чыгармачылык жана бардыгын автоматташтыруу каалоосу бардык жерде дат басып, бардык туткаларды алып салууга алып келди жана кайра карап чыгуу зарыл.
Үзгүлтүксүз жеткирүү
Дебет менен кредитти салыштырып көрөлү. Биринчиден, инфраструктуранын сыпаттамасы келет, ал абдан жөнөкөй болушу мүмкүн. Баарын майда-чүйдөсүнө чейин сүрөттөп берүүнүн кереги жок, бирок аны менен иштөө үчүн кээ бир негизги сыпаттама талап кылынат. Болбосо, кийинки үзгүлтүксүз жеткирүү менен эмне кылуу керектиги түшүнүксүз. Бул практикалардын бардыгы сиз DevOpsке келгенде бир эле учурда ишке ашат, бирок бул сизде эмне бар экенин жана аны кантип башкарууну түшүнүүдөн башталат. Бул код катары инфраструктуранын так практикасы.
Сизде бар экени жана аны кантип башкаруу керектиги айкын болгондон кийин, иштеп чыгуучунун кодун өндүрүшкө мүмкүн болушунча тезирээк кантип жөнөтүүнү чече баштайсыз. Мен иштеп чыгуучу менен бирге айтып жатам - биз "скважиналардын" көйгөйүн эстейбиз, башкача айтканда, муну жеке адамдар эмес, команда ойлоп табышат.
Биз менен болгондо Ваня Евтухович биринчи китепти көрдүм Джез Момун жана авторлордун топтору "Үзгүлтүксүз жеткирүү", 2009-жылы чыккан, биз анын аталышын орус тилине кантип которууну көпкө ойлондук. Аны “Дайыма жеткирүү” деп которгулары келген, тилекке каршы, “Үзгүлтүксүз жеткирүү” деп которулган. Мага биздин атыбызда басым менен орусча бир нерсе бар окшойт.
Дайыма жеткирүү каражаттары
Продукт репозиторийиндеги кодду ар дайым өндүрүшкө жүктөп алса болот. Ал дефляты жок болушу мүмкүн, бирок ал ар дайым ага даяр. Демек, сиз ар дайым кодууңуздун астына кандайдыр бир тынчсыздануу сезими менен түшүндүрүүгө кыйын болосуз. Ал көбүнчө инфраструктуралык кодду чыгарганда пайда болот. Бул кандайдыр бир тынчсыздануу сезими болушу керек - бул кодду бир аз башкача жазууга мүмкүндүк берген мээ процесстерин козгойт. Бул иштеп чыгуунун ичиндеги эрежелерде жазылууга тийиш.
Ырааттуу жеткирүү үчүн сизге инфраструктуралык платформада иштеген артефакт форматы керек. Эгерде сиз инфраструктуралык платформа аркылуу ар кандай форматтагы “өмүр калдыктарын” ыргытсаңыз, анда ал бирдиктүү болуп калат, аны кармап туруу кыйынга турат жана техникалык карыз маселеси жаралат. Артефакттын форматын тегиздөө керек - бул дагы жамааттык милдет: баарыбыз чогулуп, мээбизди шыбырап, ушул форматты ойлоп табышыбыз керек.
Артефакт үзгүлтүксүз өркүндөтүлүп турат жана жеткирүү түтүгү аркылуу өткөндө өндүрүш чөйрөсүнө ылайыктап өзгөрүп турат. Артефакт түтүктү бойлой жылып баратканда, ал тынымсыз ага ыңгайсыз болгон нерселерге туш болот, алар сиз өндүрүшкө киргизген артефакт жолуккан нерсеге окшош. Эгерде классикалык иштеп чыгууда муну жайылтууну аткарган системалык администратор жасаса, анда DevOps процессинде бул дайыма болуп турат: бул жерде алар аны бир нече тесттер менен сынап көрүштү, бул жерде алар аны Kubernetes кластерине ыргытышты, ал аздыр-көптүр окшош. өндүрүшкө, андан кийин күтүлбөгөн жерден алар жүк тестирлөө баштады.
Бул бир аз Pac-Man оюнун эске салат - артефакт кандайдыр бир окуядан өтөт. Ошол эле учурда, бул код чындыгында окуя аркылуу өтүп же жокпу, жана кандайдыр бир түрдө сиздин өндүрүш менен байланыштуу экенин көзөмөлдөө үчүн маанилүү болуп саналат. Өндүрүштүн окуяларын Үзгүлтүксүз жеткирүү процессине тартууга болот: бир нерсе кулаганда ушундай болгон, эми бул сценарийди системанын ичинде программалайлы. Ар бир жолу код бул сценарийден өтөт жана кийинки жолу бул көйгөйгө туш болбойсуз. Сиз бул тууралуу кардарыңызга жеткенден алда канча эрте билесиз.
Ар кандай жайгаштыруу стратегиялары. Мисалы, сиз кодду ар кандай кардарларда ар кандай сынап көрүү үчүн AB тестирлөөсүн же канарлык жайылтууларды колдоносуз, код кандайча иштээри жөнүндө маалымат аласыз жана ал 100 миллион колдонуучуга жарыялангандан алда канча эртерээк.
"Ырааттуу түрдө жеткирүү" ушундай көрүнөт.
Dev, CI, Test, PreProd, Prod жеткирүү процесси өзүнчө чөйрө эмес, булар артефактыңыз өтө турган отко чыдамдуу суммалары бар этаптар же станциялар.
Эгер сизде Base Service APP катары сүрөттөлгөн инфраструктуралык код болсо, анда ал жардам берет бардык скрипттерди унутпа, жана аларды бул артефакттын коду катары жазыңыз, артефакты пропагандалоо жана барган сайын аны өзгөртүңүз.
Өзүн өзү текшерүү суроолору
Функциянын сүрөттөмөсүнөн өндүрүшкө чыгарууга чейинки убакыт 95% учурларда бир жумадан азбы? Артефакттын сапаты түтүктүн ар бир этабында жакшырып жатабы? Анын башынан өткөн окуя барбы? Сиз ар кандай жайгаштыруу стратегияларын колдоносузбу?
Эгерде бардык жооптор ооба болсо, анда сиз укмуштуудай сонунсуз! Жоопторуңузду комментарийге жазыңыз - мен кубанычтамын).
кайра Байланыш
Бул эң кыйын практика. DevOpsConf конференциясында, Infobip компаниясынын кесиптеши бул жөнүндө айтып жатып, анын сөздөрүндө бир аз чаташып кетти, анткени бул чындыгында бардыгына мониторинг жүргүзүү керек экендиги жөнүндө абдан татаал практика!
Мисалы, бир топ убакыт мурун, мен Qikте иштеп жүргөндө, биз бардыгын көзөмөлдөшүбүз керек экенин түшүндүк. Биз муну жасадык жана азыр Zabbixте 150 000 буюм бар, алар дайыма көзөмөлдөнүп турат. Коркунучтуу болду, техникалык директор манжасын ийбадатканага буруп:
- Балдар, эмне үчүн серверди түшүнүксүз нерсе менен зордуктап жатасыңар?
Бирок андан кийин бул чындап эле абдан сонун стратегия экенин көрсөткөн окуя болду.
Кызматтардын бири тынымсыз бузула баштады. Башында, ал бузулган жок, бул кызыктуу, код ал жерде кошулган эмес, анткени ал негизги брокер болгон, ал иш жүзүндө эч кандай бизнес функциясына ээ болгон эмес - ал жөн гана айрым кызматтардын ортосунда билдирүүлөрдү жөнөткөн. Кызмат 4 ай бою өзгөргөн жок, күтүлбөгөн жерден "Сегментация катасы" катасы менен бузула баштады.
Биз таң калып, диаграммаларыбызды Zabbixде ачтык жана бир жарым жума мурун бул брокер колдонгон API кызматындагы суроо-талаптардын жүрүм-туруму абдан өзгөргөн. Андан кийин биз кабардын белгилүү бир түрүн жөнөтүү жыштыгы өзгөргөнүн көрдүк. Кийинчерээк булар андроид кардарлары экенин билдик. Биз сурадык:
— Балдар, мындан бир жарым жума мурда сага эмне болду?
Жооп катары биз алар UIди кантип кайра иштеп чыккандыгы тууралуу кызыктуу окуяны уктук. Кимдир бирөө HTTP китепканасын өзгөрттү деп дароо айтышы күмөн. Android кардарлары үчүн бул ваннадагы самынды алмаштыруу сыяктуу - алар эсинде жок. Натыйжада, 40 мүнөттүк сүйлөшүүдөн кийин, алар HTTP китепканасын өзгөртүшкөнүн жана анын демейки убакыттары өзгөргөнүн билдик. Бул API сервериндеги трафиктин жүрүм-турумунун өзгөрүшүнө алып келди, бул брокердин ичинде жарышты пайда кылган кырдаалга алып келди жана ал бузула баштады.
Терең мониторингсиз муну ачуу жалпысынан мүмкүн эмес. Эгерде уюмда дагы эле "кудуктар" көйгөйү бар болсо, баары бири-бирине акча ыргытканда, бул көп жылдар бою жашай берет. Сиз жөн гана серверди өчүрүп күйгүзөсүз, анткени көйгөйдү чечүү мүмкүн эмес. Сизде болгон бардык окуяларга көз салып, көз салып, көз салып, мониторингди тестирлөө катары колдонгондо - код жазыңыз жана аны кантип көзөмөлдөө керектигин дароо эле код түрүндө көрсөтүңүз (бизде код катары инфраструктура бар), баары айкын болот. алаканга. Ал тургай мындай татаал көйгөйлөр оңой эле байкалат.
Өндүрүштө эмес, жеткирүү процессинин ар бир этабында артефактка эмне болору тууралуу бардык маалыматты чогултуңуз.
Мониторингди CIге жүктөңүз жана кээ бир негизги нерселер ал жерден көрүнүп калат. Кийинчерээк сиз аларды Test, PredProd жана жүктөө тесттеринде көрөсүз. Бардык этаптарда маалымат чогултуңуз, бир гана метрика, статистика эмес, ошондой эле журналдар: тиркеме кантип пайда болду, аномалиялар - бардыгын чогултуңуз.
Болбосо, аны аныктоо кыйын болот. Мен буга чейин эле DevOps татаалыраак экенин айттым. Бул татаалдык менен күрөшүү үчүн, сиз кадимки аналитикага ээ болушуңуз керек.
Өзүн өзү башкаруу үчүн суроолор
Сиздин мониторингиңиз жана журналыңыз сиз үчүн өнүгүү куралыбы? Код жазып жатканда, иштеп чыгуучуларыңыз, анын ичинде сиз, аны кантип көзөмөлдөө керектиги жөнүндө ойлонушабы?
Кардарлардан көйгөйлөр тууралуу угуп жатасызбы? Мониторинг жана каттоодон кардарды жакшыраак түшүнөсүзбү? Мониторингден жана журналдан системаны жакшыраак түшүнөсүзбү? Сиз системадагы тенденция өсүп жатканын көрүп, дагы 3 жумадан кийин баары өлөт деп түшүнгөнүңүз үчүн системаны өзгөртөсүзбү?
Бул үч компонентке ээ болгондон кийин, сиздин компанияңызда кандай инфраструктуралык платформа бар экендиги жөнүндө ойлонсоңуз болот.
Инфраструктура платформасы
Кеп бул ар бир компаниянын карама-каршы куралдарынын жыйындысы экендигинде эмес.
Инфраструктуралык платформанын мааниси - бардык командалар бул куралдарды колдонуп, аларды чогуу иштеп чыгышат.
Инфраструктуралык платформанын айрым бөлүктөрүн иштеп чыгуу үчүн жооптуу болгон өзүнчө командалар бар экени түшүнүктүү. Бирок ошол эле учурда ар бир инженер инфраструктуралык платформаны өнүктүрүү, аткаруу жана жылдыруу үчүн жоопкерчилик тартат. Ички деңгээлде ал жалпы куралга айланат.
Бардык командалар инфраструктуралык платформаны иштеп чыгышат жана ага өздөрүнүн IDE сыяктуу этияттык менен мамиле кылышат. IDE'иңизде бардыгын жакшы жана тез кылуу үчүн ар кандай плагиндерди орнотуп, ысык баскычтарды конфигурациялайсыз. Sublime, Atom же Visual Studio Code ачканыңызда, код каталары түшүп жатат жана такыр иштөө мүмкүн эмес экенин түшүнүп, дароо кайгырып, IDE түзмөгүңүздү оңдоого чуркайсыз.
Инфраструктура платформаңызга да ушундай мамиле кылыңыз. Эгер анда бир нерсе бар экенин түшүнсөңүз, аны өзүңүз оңдой албасаңыз, өтүнүч калтырыңыз. Жөнөкөй нерсе болсо, аны өзүңүз оңдоңуз, тартуу өтүнүчүн жөнөтүңүз, балдар карап, кошуп коюшат. Бул иштеп чыгуучунун башындагы инженердик куралдарга бир аз башкача мамиле.
Инфраструктуралык платформа артефакттын сапатын үзгүлтүксүз жакшыртуу менен иштеп чыгуудан кардарга өткөрүп берүүнү камсыз кылат. IP өндүрүштө код менен болгон окуялардын жыйындысы менен программаланган. Өнүгүү жылдарында мындай окуялар көп, алардын айрымдары уникалдуу жана сизге гана тиешелүү - аларды Google аркылуу издөө мүмкүн эмес.
Бул учурда, инфраструктуралык платформа сиздин атаандаштык артыкчылыгыңызга айланат, анткени анын ичинде атаандаштын куралында жок нерсе бар. Сиздин IP канчалык терең болсо, базарга чыгуу убактысы боюнча атаандаштык артыкчылыгыңыз ошончолук чоң болот. Бул жерде пайда болот сатуучу кулпу көйгөйү: Сиз башка бирөөнүн платформасын ала аласыз, бирок башка бирөөнүн тажрыйбасын колдонуп, анын сизге канчалык актуалдуу экенин түшүнбөй каласыз. Ооба, ар бир компания Amazon сыяктуу платформаны кура албайт. Бул компаниянын тажрыйбасы рыноктогу абалына тиешелүү болгон татаал линия жана ал жерде сатуучунун кулпусун колдоно албайсыз. Бул жөнүндө да ойлонуу маанилүү.
схемасы
Бул DevOps компаниясында бардык тажрыйбаларды жана процесстерди орнотууга жардам бере турган инфраструктуралык платформанын негизги диаграммасы.
Келгиле, анын эмнеден турганын карап көрөлү.
Ресурстарды башкаруу системасы, ал приложенияларды жана башка кызматтарды CPU, эс тутум, диск менен камсыз кылат. Мунун үстүнө - төмөн деңгээлдеги кызматтар: мониторинг, каттоо, CI/CD кыймылдаткычы, артефакттарды сактоо, тутумдук код катары инфраструктура.
Жогорку деңгээлдеги кызматтар: кызмат катары маалымат базасы, кызмат катары кезек, кызмат катары жүк балансы, кызмат катары сүрөттүн өлчөмүн өзгөртүү, кызмат катары Big Data фабрикасы. Мунун үстүнө - Сиздин кардарыңызга дайыма өзгөртүлгөн кодду жеткирүүчү түтүк.
Сиз программалык камсыздооңуздун кардар үчүн кандайча иштээри жөнүндө маалымат аласыз, аны өзгөртөсүз, бул кодду кайра киргизесиз, маалымат аласыз - ошентип сиз инфраструктуралык платформаны да, программалык камсыздоону да тынымсыз өнүктүрөсүз.
Диаграммада жеткирүү түтүктөрү көптөгөн этаптардан турат. Бирок бул мисал катары берилген схемалык диаграмма - аны бирден кайталоонун кереги жок. Этаптар кызматтар менен кызмат кылгандай иштешет — платформанын ар бир кирпичинин өз тарыхы бар: ресурстар кантип бөлүштүрүлөт, тиркеме кантип ишке киргизилет, ресурстар менен иштейт, көзөмөлдөнөт жана өзгөрөт.
Платформанын ар бир бөлүгүндө окуя бар экенин түшүнүү маанилүү жана бул кирпич кандай окуяны алып жүрөт деп өзүңдөн сура, балким аны ыргытып, үчүнчү тараптын кызматы менен алмаштыруу керек. Мисалы, Окметрди кирпичтин ордуна коюуга болобу? Балким, балдар бул тажрыйбаны бизден алда канча көп иштеп чыгышкандыр. Бирок, балким, андай эмес - балким, биз уникалдуу тажрыйбага ээ, биз Prometheus орнотуп, аны андан ары өнүктүрүү керек.
Платформаны түзүү
Бул татаал коммуникация процесси. Негизги тажрыйбага ээ болгондо, сиз талаптарды жана стандарттарды иштеп чыгуучу ар кандай инженерлер менен адистердин ортосунда байланышты баштайсыз жана аларды ар кандай инструменттерге жана ыкмаларга тынымсыз өзгөртөсүз. Бул жерде бизде DevOps болгон маданият маанилүү.
Маданият менен баары абдан жөнөкөй - бул кызматташуу жана байланыш жөнүндө. Бул жерде ракета илими жок - баары абдан жөнөкөй, баналдык. Маселен, баарыбыз кире бериште жашап, аны таза кармайбыз – маданияттын ушундай деңгээли.
Сенде эмне бар?
Дагы бир жолу, суроолорду өзүңүзгө бере аласыз.
Инфраструктуралык платформа арналганбы? Анын өнүгүшүнө ким жооптуу? Сиз инфраструктуралык платформаңыздын атаандаштык артыкчылыктарын түшүнөсүзбү?
Бул суроолорду өзүңүзгө дайыма берип туруу керек. Эгерде бир нерсе үчүнчү тараптын кызматтарына өткөрүлүп берилиши мүмкүн болсо, анда аны өткөрүп берүү керек, эгерде үчүнчү тараптын кызматы сиздин кыймылыңызды бөгөттөп баштаса, анда сиз өзүңүздүн системаңызды түзүшүңүз керек.
Ошентип, DevOps...
... бул татаал система, анда төмөнкүлөр болушу керек:
- Санарип продукт.
- Бул санарип продукт иштеп бизнес модулдары.
- Код жазган продукт командалары.
- Үзгүлтүксүз жеткирүү практикалары.
- Платформалар кызмат катары.
- Инфраструктура кызмат катары.
- Код катары инфраструктура.
- DevOps ичинде орнотулган ишенимдүүлүктү сактоо үчүн өзүнчө практикалар.
- Мунун баарын сүрөттөгөн пикир айтуу практикасы.
Сиз бул диаграмманы колдонуп, анда сиздин компанияңызда кандайдыр бир формада бар нерсени баса белгилесеңиз болот: ал иштелип чыктыбы же дагы эле иштеп чыгуу керек.
Бир-эки аптада бүтөт . RIT++ бөлүгү катары. Конференцияга келиңиз, анда сиз үзгүлтүксүз жеткирүү, код катары инфраструктура жана DevOps трансформациясы жөнүндө көптөгөн сонун отчетторду таба аласыз. , акыркы баанын мөөнөтү 20-майга чейин
Source: www.habr.com