DevOps жөнүндө айтып жатканда негизги ойду түшүнүү кыйынбы? Биз сиздер үчүн айкын аналогияларды, таң калыштуу формулаларды жана адистердин кеңештерин чогулттук, алар да адис эместерге да ойго келүүгө жардам берет. Акыр-аягы, бонус Red Hat кызматкерлеринин өздөрүнүн DevOps болуп саналат.
DevOps термини 10 жыл мурун пайда болгон жана Twitter хэштегинен IT дүйнөсүндөгү күчтүү маданий кыймылга, иштеп чыгуучуларды иштерди тезирээк бүтүрүүгө, эксперимент жүргүзүүгө жана алдыга карай кайталоого үндөгөн чыныгы философияга өттү. DevOps санариптик трансформация концепциясы менен ажырагыс байланышта болуп калды. Бирок IT терминологиясы менен көп кездешкендей, акыркы он жыл ичинде DevOps өзү жөнүндө көптөгөн аныктамаларды, чечмелөөлөрдү жана туура эмес түшүнүктөрдү алды.
Ошондуктан, сиз DevOps жөнүндө суроолорду көп уга аласыз, бул agile менен бирдейби? Же бул кандайдыр бир өзгөчө методологиябы? Же бул "кызматташтык" деген сөздүн башка синонимиби?
DevOps көптөгөн түрдүү концепцияларды камтыйт (үзгүлтүксүз жеткирүү, үзгүлтүксүз интеграция, автоматташтыруу ж. Бирок, бул жөндөм, сиз өзүңүздүн идеяларыңызды жетекчиңизге жеткирүүгө аракет кылып жатасызбы же жөн гана үй-бүлөңүздөн же досторуңуздан кимдир бирөөгө жумушуңуз жөнүндө айтып берсеңиз да, абдан пайдалуу. Ошондуктан, келгиле, азыр DevOpsтин терминологиялык нюанстарын четке кагып, чоң сүрөткө токтололу.
DevOps деген эмне: 6 аныктамалар жана аналогиялар
Биз эксперттерден DevOpsтин маңызын мүмкүн болушунча жөнөкөй жана кыскача түшүндүрүп берүүсүн сурандык, андыктан анын мааниси ар кандай деңгээлдеги техникалык билими бар окурмандарга түшүнүктүү болуп калат. Бул сүйлөшүүлөрдүн жыйынтыгына таянып, биз DevOps жөнүндө окуяңызды түзүүгө жардам бере турган эң таң калыштуу аналогияларды жана таң калыштуу формулаларды тандап алдык.
1. DevOps - бул маданий кыймыл
"DevOps - бул маданий кыймыл, анда эки тарап тең (программалык камсыздоону иштеп чыгуучулар жана IT тутумунун иштеши боюнча адистер) программалык камсыздоо кимдир бирөө аны колдоно баштамайынча реалдуу пайда алып келбей турганын түшүнүшөт: кардарлар, кардарлар, кызматкерлер, маселе эмес," - дейт Эвелин Оэрлих, улук изилдөөчү. DevOps институтунун аналитиги. "Ошондуктан, бул эки тарап биргелешип программалык камсыздоонун тез жана сапаттуу жеткирилишин камсыз кылат."
2. DevOps иштеп чыгуучулардын мүмкүнчүлүктөрүн кеңейтүү жөнүндө.
"DevOps иштеп чыгуучуларга колдонмолорго ээлик кылууга, аларды иштетүүгө жана жеткирүүнү башынан аягына чейин башкарууга мүмкүнчүлүк берет."
"Адатта, DevOps автоматташтырылган процесстерди куруу жана ишке ашыруу аркылуу өндүрүшкө тиркемелерди жеткирүүнү тездетүүнүн бир жолу катары айтылат" дейт Джай Шниепп, Liberty Mutual камсыздандыруу компаниясынын DevOps платформаларынын директору. "Бирок мен үчүн бул бир топ негизги нерсе." DevOps иштеп чыгуучуларга тиркемелерге же программалык камсыздоонун белгилүү бир бөлүгүнө ээлик кылууга, аларды иштетүүгө жана алардын жеткирилишин башынан аягына чейин башкарууга мүмкүнчүлүк берет. DevOps жоопкерчиликтин башаламандыгын жок кылат жана автоматташтырылган, иштеп чыгуучуларга негизделген инфраструктураны түзүүгө катышкандардын бардыгын жетектейт.
3. DevOps тиркемелерди түзүү жана жеткирүү боюнча кызматташуу жөнүндө.
"Жөнөкөй сөз менен айтканда, DevOps - бул программалык камсыздоону өндүрүүгө жана жеткирүүгө болгон мамиле, анда бардыгы бирге иштешет", - дейт Гур Стаф, BMC компаниясынын санариптик бизнести автоматташтыруунун президенти жана жетекчиси.
4. DevOps - бул түтүк
"Конвейерди чогултуу бардык тетиктер бири-бирине туура келгенде гана мүмкүн."
"Мен DevOpsту унаа чогултуучу линияга салыштырат элем", - деп улантат Гур штабы. – Идея – бардык тетиктерди алдын ала долбоорлоо жана жасоо, анан аларды жекече жөнгө салбастан чогултууга болот. Конвейерди монтаждоо бардык бөлүктөрү бири-бирине туура келгенде гана мүмкүн. Кыймылдаткычты иштеп чыккандар жана кургандар аны кузовго же рамкага кантип орнотууну ойлонушу керек. Тормоз жасагандар дөңгөлөк жөнүндө ойлонушу керек ж.б.у.с. Ошол эле программалык камсыздоо менен да болушу керек.
Бизнес логикасын же колдонуучу интерфейсин түзүүчү иштеп чыгуучу кардар маалыматын сактаган маалымат базасы, колдонуучунун маалыматтарын коргоо үчүн коопсуздук чаралары жана бул кызмат чоң, балким, көп миллиондогон долларлык колдонуучулардын аудиториясына кызмат кыла баштаганда мунун баары кандай иштей турганы жөнүндө ойлонушу керек. ."
«Адамдарды өз милдеттерине гана көңүл бурбастан, башкалар аткарып жаткан жумуштун бөлүктөрүн биргелешип, ойлонууга мажбурлоо - бул жеңе турган эң чоң тоскоолдук. Эгер сиз муну кыла алсаңыз, сизде санариптик трансформацияга сонун мүмкүнчүлүк бар "деп кошумчалайт Гур Стафф.
5. DevOps – бул адамдардын, процесстердин жана автоматташтыруунун туура айкалышы
Джейн Гролл, DevOps институтунун аткаруучу директору, DevOpsту түшүндүрүү үчүн сонун аналогияны сунуштады. Анын сөзү боюнча, "DevOps ингредиенттердин үч негизги категориясы бар рецепт сыяктуу: адамдар, процесс жана автоматташтыруу. Бул ингредиенттердин көбү башка аймактардан жана булактардан алынышы мүмкүн: Lean, Agile, SRE, CI/CD, ITIL, лидерлик, маданият, аспаптар. DevOps сыры, ар кандай жакшы рецепт сыяктуу, тиркемелерди түзүүнүн жана чыгаруунун ылдамдыгын жана натыйжалуулугун жогорулатуу үчүн бул ингредиенттердин туура пропорцияларын жана аралашмасын кантип алууда.
6. DevOps - бул программисттердин Формула 1 командасы сыяктуу иштеши
"Жарыш башынан аягына чейин эмес, тескерисинче, марага чейин пландаштырылган."
"Мен DevOps демилгесинен эмнени күтүү керектиги жөнүндө айтканда, мен мисал катары NASCAR же Формула 1 жарыш командасын эстейм" дейт Крис Шорт, Red Hat компаниясынын булут платформасынын маркетингинин улук менеджери жана DevOps'ish маалымат бюллетенинин басып чыгаруучусу. – Мындай команданын лидеринин бир максаты бар: командада болгон ресурстарды жана анын башына түшкөн кыйынчылыктарды эске алуу менен жарыштын жыйынтыгында эң жогорку орунду ээлөө. Мында жарыш баштан-аяк эмес, тескерисинче, марага чейин пландалат. Алгач амбициялуу максат коюлуп, андан кийин ага жетүү жолдору аныкталат. Андан кийин алар кошумча тапшырмаларга бөлүнөт жана команда мүчөлөрүнө берилет».
«Команда жарыш алдында бир жума бою пит-стопту өркүндөтөт. Ал оор жарыш күнү формада калуу үчүн күч менен машыгуу жана кардио менен машыгат. Жарыш учурунда келип чыгышы мүмкүн болгон көйгөйлөрдү биргелешип чечүүгө машыгат. Ошо сыяктуу эле, иштеп чыгуу тобу жаңы версияларды тез-тез чыгарууга үйрөтүшү керек. Эгер сизде ушундай көндүмдөр жана жакшы иштеген коопсуздук системасы бар болсо, жаңы версияларды өндүрүшкө киргизүү дагы көп болот. Бул дүйнөгө көз карашта ылдамдыктын жогорулашы коопсуздуктун жогорулашын билдирет”, - дейт Шорт.
"Бул "туура нерсени" кылуу жөнүндө эмес, - деп кошумчалайт Шорт, - бул каалаган натыйжага тоскоол болгон мүмкүн болушунча көп нерселерди жок кылуу. Реалдуу убакытта алган пикириңиздин негизинде кызматташып, ыңгайлашыңыз. Аномалияларга даяр болуңуз жана алардын максатыңызга жетүүгө тийгизген таасирин азайтуу үчүн сапатты жакшыртууга аракет кылыңыз. Бул DevOps дүйнөсүндө бизди күтүп жаткан нерсе."
DevOps кантип масштабдуу: эксперттерден 10 кеңеш
Бул жөн гана DevOps жана массалык DevOps таптакыр башка нерселер. Биринчиден экинчисине чейинки жолдогу тоскоолдуктарды кантип жеңүү керектигин айтып беребиз.
Көптөгөн уюмдар үчүн DevOpsка саякат оңой жана жагымдуу башталат. Кичинекей жалындуу коллективдер тузулуп, эски процесстер жацылары менен алмашылып, алгачкы ийги-ликтер кеп узабайт.
Тилекке каршы, бул жөн гана жалган жаркылдоо, прогресстин иллюзиясы, дейт Бен Гриннелл, North Highland консультациясынын башкаруучу директору жана санариптик бөлүмүнүн башчысы. Алгачкы жеңиштер, албетте, кубаттайт, бирок алар DevOpsту уюм боюнча кеңири жайылтуу боюнча түпкү максатына жетүүгө жардам бербейт.
Жыйынтыгында “биз” менен “алар” деп бөлүнүү маданияты болуп жатканын көрүү оңой.
"Көп учурда уюмдар бул пионердик долбоорлорду ишке ашырышат, алар негизги DevOps үчүн жол ачат деп ойлоп, башкалар бул жолду басып кете алабы же ээрчий алабы же жокпу" деп түшүндүрөт Бен Гриннелл. – Мындай долбоорлорду ишке ашыруу үчүн командалар, адатта, башка жерлерде буга чейин ушундай иштерди жасаган, бирок сиздин уюмга жаңы келген, өзүнө ишенген «варжиялыктардан» алынат. Ошол эле учурда, алар башкалар үчүн милдеттүү бойдон калган эрежелерди бузууга жана жок кылууга үндөшөт. Натыйжада билим менен көндүмдөрдүн берилишине тоскоол болгон “биздин” жана “алардын” маданияты болуп жатканын көрүү оңой”.
«Бул маданий көйгөй DevOps масштабын көтөрүү кыйынга турган себептердин бири гана. DevOps командалары тез өнүгүп келе жаткан IT-биринчи компанияларга мүнөздүү болгон көбөйгөн техникалык кыйынчылыктарга туш болууда», - деди Стив Ньюман, Scalyr компаниясынын негиздөөчүсү жана төрагасы.
«Заманбап дүйнөдө кызматтар муктаждык жаралса эле өзгөрөт. Дайыма жаңы функцияларды ишке ашыруу жана ишке ашыруу сонун, бирок бул процессти координациялоо жана пайда болгон көйгөйлөрдү жоюу – бул чыныгы баш оору, деп кошумчалайт Стив Ньюман. – Өтө тез өнүгүп жаткан уюмдарда кайчылаш функционалдык командалардагы инженерлер өзгөрүүлөрдүн жана ал жараткан көз карандылык деңгээлиндеги каскаддык эффекттердин көрүнүүсүн сактап калуу үчүн күрөшүшөт. Анын үстүнө инженерлер бул мүмкүнчүлүктөн ажыратылганда сүйүнбөйт жана мунун натыйжасында келип чыккан көйгөйлөрдүн маңызын түшүнүү кыйындайт».
Кантип жогоруда сүрөттөлгөн бул кыйынчылыктарды жеңип, чоң уюмда DevOpsти массалык түрдө колдонууга өтүүгө болот? Эксперттер сиздин түпкү максатыңыз программалык камсыздоону иштеп чыгуу циклин жана бизнес процесстерди тездетүү болсо дагы, чыдамкайлыкка чакырат.
1. Маданиятты өзгөртүү убакытты талап кыларын унутпаңыз.
Джейн Гролл, DevOps институтунун аткаруучу директору: «Менин оюмча, DevOpsтун кеңейиши ийкемдүү өнүгүү сыяктуу (жана маданиятка да тиешелүү) кошумча жана итеративдик болушу керек. Agile жана DevOps чакан командаларга басым жасашат. Бирок бул командалардын саны жана интеграциясы көбөйгөн сайын, бизде жаңы иш ыкмаларын кабыл алган адамдар көбөйүп, натыйжада массалык маданий трансформация болуп жатат».
2. Пландаштырууга жана аянтчаны тандоого жетиштүү убакыт бөлүңүз
Эран Кинсбрунер, Perfecto компаниясынын башкы техникалык евангелисти: "Иштей турган масштабды кеңейтүү үчүн, DevOps командалары адегенде салттуу процесстерди, куралдарды жана көндүмдөрдү айкалыштырууга үйрөнүшү керек, андан кийин DevOpsтин ар бир жеке фазасын акырындык менен өркүндөтүп, турукташтыруу керек. Мунун баары колдонуучу окуяларын жана баалуулуктар агымдарын кылдат пландаштыруудан башталат, андан кийин программалык камсыздоону жазуу жана версияларды башкаруу магистралдык негизде иштеп чыгуу же кодду бутактап, бириктирүү үчүн эң ылайыктуу башка ыкмаларды колдонуу менен башталат.
«Андан кийин интеграция жана тестирлөө баскычы келет, анда автоматташтыруу үчүн масштабдуу платформа талап кылынат. Бул жерде DevOps командалары үчүн алардын чеберчилик деңгээлине жана долбоордун акыркы максаттарына туура келген платформаны тандоо маанилүү.
Кийинки этап - өндүрүшкө жайылтуу жана бул оркестрдик аспаптарды жана контейнерлерди колдонуу менен толугу менен автоматташтырылууга тийиш. DevOpsтин бардык этаптарында виртуалдаштырылган чөйрөлөргө ээ болуу маанилүү (өндүрүш симулятору, QA чөйрөсү жана чыныгы өндүрүш чөйрөсү) жана тиешелүү корутундуларды алуу үчүн ар дайым тесттер үчүн эң акыркы маалыматтарды колдонуу. Аналитика акылдуу болушу керек жана чоң маалыматтарды тез жана аракетке жарамдуу пикир менен иштетүүгө жөндөмдүү болушу керек.
3. Күнөөнү жоопкерчиликтен алып салуу.
Гордон Хафф, RedHat Evangelist: "Эксперимент жүргүзүүгө мүмкүндүк берүүчү жана шыктандырган системаны жана атмосфераны түзүү, ийкемдүү программалык камсыздоону иштеп чыгууда ийгиликтүү каталар деп аталган нерселерге жол берет. Бул катачылыктар үчүн башка эч ким жооптуу эмес дегенди билдирбейт. Чынында, ким жооптуу экенин аныктоо ого бетер жеңилдейт, анткени “жооптуу болуу” мындан ары “кырсыкка себеп болуу” дегенди билдирбейт. Башкача айтканда, жоопкерчиликтин маңызы сапаттык жактан өзгөрөт. Төрт фактор маанилүү болуп калат: үзгүлтүктүн көлөмү, ыкмалар, өндүрүш процесстери жана стимулдар». (Сиз Гордон Хаффтын "DevOps сабактары: дени сак эксперименттердин 4 аспектиси" деген макаласында бул факторлор жөнүндө көбүрөөк окуй аласыз.)
4. Алга карай жолду тазалаңыз
Бен Гриннелл, North Highland консалтингинин башкаруучу директору жана санариптик бөлүмүнүн башчысы: «Масштабга жетүү үчүн мен пионердик долбоорлор менен бирге «жолду тазалоо» программасын ишке киргизүүнү сунуштайм. Бул программанын максаты - DevOps пионерлери артта калган таштандыларды, мисалы, эскирген эрежелерди жана ушул сыяктуу нерселерди тазалоо, мындан ары карай жол ачык бойдон калууда."
«Иштин жаңы ыкмаларынын ийгиликтерин кеңири белгилөө менен, пионердик топтун чегинен ашкан байланыш аркылуу адамдарга уюштуруучулук колдоо жана дем бериңиз. DevOps долбоорлорунун кийинки толкунуна катышкан жана DevOpsту биринчи жолу колдонуудан чочулаган адамдарды машыктырыңыз. Жана бул адамдар пионерлерден таптакыр айырмаланарын унутпагыла».
5. Куралдарды демократиялаштыруу
Steve Newman, негиздөөчүсү жана Scalyr төрагасы: «Инструменттер адамдардан жашырылбашы керек жана алар убакытты өткөрүүнү каалагандар үчүн салыштырмалуу жеңил болушу керек. Эгерде журналдарды суроо мүмкүнчүлүгү куралды колдонууга "сертификатталган" үч адам менен чектелсе, сизде өтө чоң эсептөө чөйрөсү болсо дагы, көйгөйдү чечүү үчүн ар дайым эң көп үч адам болот. Башкача айтканда, бул жерде олуттуу (ишкердик) кесепеттерге алып келиши мүмкүн болгон бөтөлкө бар».
6. Командада иштөө үчүн идеалдуу шарттарды түзүү
Том Кларк, ITVдеги Common Platform уюмунун жетекчиси: «Сен баарын кыла аласың, бирок баарын бир эле учурда эмес. Андыктан алдыга чоң максаттарды коюп, кичинеден баштаңыз жана тез итерациялар менен алга жылыңыз. Убакыттын өтүшү менен сиз иштерди бүтүрүү боюнча репутацияга ээ болосуз, андыктан башкалар да сиздин ыкмаларыңызды колдонгусу келет. Жана жогорку эффективдүү команда түзүү жөнүндө кабатыр болбоңуз. Анын ордуна, адамдарды идеалдуу иштөө шарттарын камсыз кылыңыз жана эффективдүү болот.
7. Конвей мыйзамы жана Канбан такталары жөнүндө унутпаңыз
Логан Дэйгл, CollabNetVersionOne компаниясынын Программалык камсыздоону жеткирүү жана DevOps стратегиясынын директору: «Конвей мыйзамынын кесепеттерин түшүнүү маанилүү. Менин ачык сөз менен айтканда, бул мыйзам биз түзгөн өнүмдөр жана биз бул үчүн колдонгон процесстер, анын ичинде DevOps, биздин уюмга окшош структураланган деп айтылат.
«Эгерде уюмда силос көп болсо жана программалык камсыздоону пландаштырууда, курууда жана чыгарууда контроль бир нече жолу алмашса, масштабдын таасири нөлгө барабар же кыска мөөнөттүү болот. Эгер уюм рынокко багытталган өнүмдөрдүн айланасында кайчылаш функционалдык топторду түзсө, анда ийгиликке жетүү мүмкүнчүлүгү кескин жогорулайт.
"Масштабдын дагы бир маанилүү аспектиси - бүтүп жаткан иштерди (WIP, workinprogress) Канбан такталарында көрсөтүү. Уюмда адамдар бул нерселерди көрө турган жер болгондо, бул кызматташууга чоң түрткү берет, бул масштабга оң таасирин тийгизет.
8. Эски тырыктарды издеңиз
Manuel Pais, DevOps консультанты жана Team Topologies авторлорунун автору: "DevOps тажрыйбаларын Dev жана Ops'тун өзүнөн тышкары алып, аларды башка функцияларга колдонууга аракет кылуу оптималдуу ыкма эмес. Бул, албетте, кандайдыр бир таасирин тийгизет (мисалы, кол менен башкарууну автоматташтыруу жолу менен), бирок жеткирүү жана кайтарым байланыш процесстерин түшүнүүдөн баштасак, көп нерсеге жетишүүгө болот.
«Эгерде уюмдун IT тутумунда эски тырыктар бар болсо - өткөн окуялардын натыйжасында ишке ашырылган, бирок актуалдуулугун жоготкон процедуралар жана башкаруу механизмдери (өнүмдөрдүн, технологиялардын же процесстердин өзгөрүшүнө байланыштуу) - анда алар албетте жок кылынышы керек. же натыйжасыз же керексиз процесстерди автоматташтыруунун ордуна, тегизделди».
9. DevOps параметрлерин өстүрбөңүз
Энтони Эдвардс, Баклажандын операциялык директору: "DevOps - бул өтө бүдөмүк термин, ошондуктан ар бир команда DevOpsтин өзүнүн версиясы менен аяктайт. Уюмда күтүлбөгөн жерден 20 түрдүү DevOps пайда болгондо, андан жаман эч нерсе жок, алар бири-бири менен жакшы келишпейт. Үч иштеп чыгуучу топтун ар биринин иштеп чыгуу жана өнүмдөрдү башкаруу ортосунда өзүнүн өзгөчө интерфейси болушу мүмкүн эмес. Өндүрүштүк симуляторго өткөрүп бергенде, өнүмдөрдүн кайтарым байланышты башкаруу боюнча өзүнүн уникалдуу күтүүлөрү болбошу керек. Болбосо, сиз эч качан DevOps масштабын кеңейте албайсыз."
10. DevOps бизнестин баалуулугун кабарлаңыз
Steve Newman, негиздөөчүсү жана Scalyr төрагасы: "DevOpsтин баалуулугун таануу үчүн иштеңиз. Үйрөнүңүз жана жасаган ишиңиздин пайдасы жөнүндө эркин сүйлөшүңүз. DevOps - бул укмуштуудай убакытты жана акчаны үнөмдөөчү каражат (ойлонуп көрүңүз: иштебей калуу азыраак, калыбына келтирүү үчүн орточо убакыт кыскараак) жана DevOps командалары бизнестин ийгилиги үчүн бул демилгелердин маанилүүлүгүн талыкпай баса белгилеши (жана кабар айтуусу) керек. Ушундай жол менен сиз жактоочулар чөйрөсүн кеңейтип, уюмдагы DevOps таасирин арттыра аласыз."
BONUS
боюнча Биздин DevOps 13-сентябрда келет - ооба, Red Hat программалык камсыздоону өндүрүүчү катары өзүнүн DevOps командалары жана практикалары бар.
Уюмдун башка топтору үчүн ички автоматташтыруу кызматтарын иштеп чыккан биздин инженер Марк Биргер өзүнүн тарыхын таза орус тилинде айтып берет - Red Hat DevOps командасы Ansible тарабынан башкарылган Hat Virtualization виртуалдык чөйрөлөрүндөгү тиркемелерди толук кандуу контейнер форматына кантип көчүрүшкөн OpenShift платформасы.
Бирок бул баары эмес:
Уюмдар иш жүктөмдөрүн контейнерлерге көчүргөндөн кийин, колдонмону көзөмөлдөөнүн салттуу ыкмалары иштебей калышы мүмкүн. Экинчи баяндамада биз журналды каттоо ыкмасын өзгөртүүгө болгон мотивациябызды түшүндүрөбүз жана бизди заманбап жыгач кесүү жана мониторинг жүргүзүү ыкмаларына алып барган жолдун уландысын көрсөтөбүз.
Source: www.habr.com