Дефиницијата за DevOps е многу сложена, па мораме секој пат да ја започнуваме дискусијата за тоа одново. Само на Хабре има илјада публикации на оваа тема. Но, ако го читате ова, веројатно знаете што е DevOps. Затоа што не сум. Здраво Моето име е Александар Титов (@), а ние само ќе разговараме за DevOps и ќе го споделам моето искуство.
Долго време размислував како да ја направам мојата приказна корисна, така што тука ќе има многу прашања - оние што си ги поставувам себеси и оние што им ги поставувам на клиентите на нашата компанија. Со одговарање на овие прашања, разбирањето станува подобро. Ќе ви кажам зошто е потребен DevOps од моја гледна точка, што е тоа, повторно, од моја гледна точка и како да разберете дека повторно се движите кон DevOps од моја гледна точка. Последната точка ќе биде преку прашања. Со тоа што ќе одговорите сами на нив, можете да разберете дали вашата компанија се движи кон DevOps или дали има проблеми на некој начин.
Едно време ги возев брановите на спојувања и превземања. Прво, работев за мал стартап наречен Qik, потоа го купи малку поголема компанија наречена Skype, која потоа беше купена од малку поголема компанија наречена Microsoft. Во тој момент, почнав да гледам како идејата за DevOps се трансформира во компании со различна големина. После тоа, се заинтересирав да го гледам DevOps од пазарна гледна точка, а со моите колеги ја основавме компанијата Express 42. Веќе 6 години се движиме по брановите на пазарот.
Меѓу другото, јас сум еден од организаторите на заедницата DevOps Москва и организатор на DevOps-Days 2017, но јас не ја организирав 2018 година. Експрес 42 работи со многу компании. Таму растеме DevOps, гледаме како се случува, извлекуваме заклучоци, анализираме, им кажуваме на сите нашите заклучоци и ги обучуваме луѓето за практиките на DevOps. Генерално, правиме се од себе да го зголемиме нашето искуство и експертиза во овој поглед.
Зошто DevOps
Првото прашање што ги прогонува сите и секогаш е - зошто? Многу луѓе мислат дека DevOps е само автоматизација или слично нешто што веќе го имаше секоја компанија.
— Имавме континуирана интеграција - ова значи дека веќе имавме DevOps, и зошто се потребни сите овие работи? Во странство се забавуваат, но не спречуваат да работиме!
Во текот на 9 години развој на заедницата и методологијата, веќе стана јасно дека ова сè уште не е маркетиншки сјај, но сè уште не е сосема јасно зошто е потребно. Како и секоја алатка и процес, DevOps има специфични цели што на крајот ги постигнува.
Сето ова се должи на фактот дека светот се менува. Тој се оддалечува од пристапот на претпријатието, кога компаниите се движат директно кон сон, како што пееше нашиот класик од Санкт Петербург, од точка А до точка Б според одредена стратегија, со одредена структура изградена за ова.
Во принцип, сè во ИТ треба да биде изградено според овој пристап. Овде ИТ се користи исклучиво за автоматизирање на процесите.
Автоматизацијата не се менува често, затоа што кога една компанија оди по добро изгазена рутина, што треба да се промени? Работи - не го допирајте. Сега пристапите во светот се менуваат, а оној наречен Agile сугерира дека крајната точка Б не е веднаш видлива.
Кога компанијата оди низ пазарот, работи со клиент, таа постојано го истражува пазарот и ја менува крајната точка Б. Освен тоа, колку почесто компанијата ја менува својата насока, толку е поуспешна на крајот, бидејќи избира повеќе пазар ниши.
Стратегијата ја демонстрира интересна компанија за која неодамна дознав. One Box Shave е услуга за испорака на претплата за жилети и додатоци за бричење во кутија. Тие знаат како да ја прилагодат својата „кутија“ за различни клиенти. Тоа го прави одреден софтвер, кој потоа ја испраќа нарачката до корејската фабрика која го произведува производот.
Овој производ го купи Unilever за 1 милијарда долари. Сега се натпреварува со Gillette и одзеде значителен дел од потрошувачите на американскиот пазар. One Box Shave велат:
- 4 сечила? Дали си сериозен? Зошто ви е потребно ова - не го подобрува квалитетот на бричењето. Специјално избраниот крем, мирис и висококвалитетен брич со две сечила решаваат многу повеќе проблеми од оние глупавите 4 сечила Gillette! Дали наскоро ќе стигнеме до 10?
Така се менува светот. Од Unilever тврдат дека имаат кул ИТ систем кој ви го овозможува тоа. На крајот изгледа како концепт Време на пазарот, за што веќе никој не зборувал.
Поентата на Time-to-market не е колку често се распоредуваме. Често може да се распоредите, но циклусите на ослободување ќе бидат долги. Ако тримесечните циклуси на издавање се надредени еден на друг, поместувајќи ги за една недела, излегува дека компанијата се чини дека се распоредува еднаш неделно. А од идејата до финалната имплементација потребни се 3 месеци.
Времето до пазар е за минимизирање на времето од идеја до финална имплементација.
Во овој случај, софтверот е во интеракција со пазарот. Вака веб-локацијата One Box Shave комуницира со клиентот. Тие немаат продавачи - само веб-страница на која посетителите кликнуваат и оставаат желби. Според тоа, нешто ново мора постојано да се објавува на страницата и да се ажурира во согласност со желбите. На пример, во Јужна Кореја тие се бричат поинаку отколку во Русија, и го сакаат мирисот не на бор, туку, на пример, на моркови и ванила.
Бидејќи е неопходно брзо да се промени содржината на страницата, развојот на софтвер во голема мера се менува. Преку софтвер мора да дознаеме што сака клиентот. Претходно, ова го научивме преку некои кружни начини, на пример, преку бизнис менаџмент. Потоа го дизајниравме, ги ставивме барањата во ИТ системот и сè беше кул. Сега е поинаку - софтверот е дизајниран од сите кои се вклучени во процесот, вклучително и инженерите, бидејќи преку техничките спецификации тие учат како функционира пазарот и исто така ги споделуваат своите сознанија со бизнисот.
На пример, во 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 Moscow, разговараме едни со други и луѓето се жалат:
- Сакавме само да го лансираме CI, но се покажа дека на менаџментот тоа не му треба.
Ова се случува токму затоа што CI и Процес на континуирана испорака се на граница на многу прегледи. Едноставно без да го надминете проблемот со „бунарите“ на организациско ниво, нема да можете да продолжите напред, што и да правите и колку и да е тажно.
Секој учесник во процесот во компанијата: backend и frontend програмери, тестирање, DBA, операција, мрежа, копа во сопствена насока и никој нема заедничка карта освен менаџерот, кој некако ги следи и управува со нив користејќи ја „поделбата и освојувај“ метод.
Луѓето се борат за некои ѕвезди или знамиња, секој си ја копа својата стручност.
Како резултат на тоа, кога ќе се појави задачата да се поврзе сето ова заедно и да се изгради заеднички гасовод, а веќе нема потреба да се бориме за ѕвезди и знамиња, се поставува прашањето - што да се прави сепак? Треба некако да се договориме, но никој не не научи како се прави ова на училиште. Од училиште нè учат: осмо одделение - леле! - во споредба со седмо одделение! Исто е и овде.
Дали е истото и во вашата компанија?
За да го проверите ова, можете да си ги поставите следните прашања.
Дали тимовите користат заеднички алатки и придонесуваат за промени на тие заеднички алатки?
Колку често тимовите се реорганизираат - некои специјалисти од еден тим се префрлаат во друг тим? Во DevOps околина тоа станува нормално, затоа што понекогаш едно лице едноставно не може да разбере што прави друга област на експертиза. Тој се преселува во друг оддел, работи таму две недели за да си создаде мапа на ориентација и интеракција со овој оддел.
Дали е можно да се формира комисија за промени и да се сменат работите? Или бара силна рака на највисокото раководство и насока? Неодамна напишав на Фејсбук како една малку позната банка спроведува алатки преку нарачки: пишуваме налог, го спроведуваме една година и видете што ќе се случи. Ова, се разбира, е долго и тажно.
Колку е важно менаџерите да добиваат лични достигнувања без да ги земат предвид достигнувањата на компанијата?
Доколку сами одговорите на овие прашања, ќе ви стане појасно дали имате таков проблем во вашата компанија.
Инфраструктурата како код
Откако ќе се помине овој проблем, првата важна практика, без која е тешко да се напредува понатаму во DevOps, е инфраструктура како код.
Најчесто, инфраструктурата како код се перцепира на следниов начин:
— Ајде да автоматизираме сè во баш, да се покриеме со скрипти за администраторите да имаат помалку рачна работа!
Но, тоа не е вистина.
Инфраструктурата како код значи дека го опишувате ИТ системот со кој работите во форма на код за постојано да ја разбирате неговата состојба.
Заедно со другите тимови, креирате мапа во форма на код што секој може да го разбере и може да се движи и да се движи. Не е важно на што се прави - готвач, Ansible, Salt или користење YAML датотеки во Kubernetes - нема разлика.
На конференцијата, колега од 2GIS раскажа како тие направиле сопствена внатрешна работа за Kubernetes, која ја опишува структурата на индивидуалните системи. За да опишат 500 системи, им требаше посебна алатка која го генерира овој опис. Кога постои овој опис, секој може да се провери меѓу себе, да ги следи промените, како да го промени и подобри, што недостасува.
Се согласувам, индивидуалните баш скрипти обично не го обезбедуваат ова разбирање. Во една од компаниите каде што работев, имаше дури и име за скрипта „само пишување“ - кога е напишано сценариото, но веќе не може да се прочита. Мислам дека ова ви е познато и вам.
Инфраструктурата како што е кодот код кој ја опишува моменталната состојба на инфраструктурата. Многу тимови за производи, инфраструктура и услуги работат заедно на овој код, и што е најважно, сите тие треба да разберат како всушност функционира овој код.
Кодот се одржува според најдобрите практики на кодот: заеднички развој, преглед на код, XP-програмирање, тестирање, барања за повлекување, CI за инфраструктури на код - сето ова е соодветно и може да се користи.
Кодот станува заеднички јазик за сите инженери.
Промената на инфраструктурата во кодот не одзема многу време. Да, инфраструктурниот код може да има и технички долг. Обично тимовите го среќаваат година и пол откако почнаа да ја имплементираат „инфраструктурата како код“ во форма на куп скрипти или дури и Ansible, кои ги пишуваат како код за шпагети, а исто така фрлаат и баш скрипти во мешавината!
Важно е: Ако сè уште не сте ги пробале овие работи, запомнете го тоа Ansible не е баш! Прочитајте ја внимателно документацијата, проучете што пишуваат за неа.
Инфраструктурата како код е раздвојување на инфраструктурниот код во посебни слоеви.
Во нашата компанија разликуваме 3 основни слоеви, кои се многу јасни и едноставни, но може да ги има повеќе. Можете да го погледнете вашиот инфраструктурен код и да кажете дали ја имате оваа состојба или не. Ако ниеден слој не е означен, тогаш треба да одвоите малку време и малку да рефакторирате.
основен слој - вака се конфигурираат оперативниот систем, резервните копии и другите работи на ниско ниво, на пример, како Kubernetes се распоредува на основно ниво.
Ниво на услуга - ова се услугите што му ги давате на развивачот: евиденција како услуга, следење како услуга, база на податоци како услуга, балансер како услуга, редица како услуга, Континуирана испорака како услуга - куп услуги што ги поединечни тимови може да обезбеди за развој. Сето ова треба да се опише во посебни модули во вашиот систем за управување со конфигурации.
Слојот каде што се прават апликациите и опишува како тие ќе се расплетуваат врз претходните два слоја.
Контролни прашања
Дали вашата компанија има заедничко инфраструктурно складиште? Дали управувате со технички долг во вашата инфраструктура? Дали користите развојни практики во инфраструктурно складиште? Дали вашата инфраструктура е поделена на слоеви? Може да го проверите дијаграмот Base-service-APP. Колку е тешко да се направи промена?
Ако сте доживеале дека ви требале ден и половина за да направите промени, тоа значи дека имате технички долг и треба да работите со него. Штотуку наидовте на гребло за технички долг во вашиот инфраструктурен код. Се сеќавам на многу такви приказни кога, за да смените некој CCTL, треба да препишете половина од инфраструктурниот код, бидејќи креативноста и желбата да се автоматизира сè, доведе до тоа дека сè е кородирано насекаде, сите рачки се отстранети и потребно е да се рефакторира.
Континуирана испорака
Ајде да споредиме дебит со кредит. Прво доаѓа опис на инфраструктурата, што може да биде сосема основно. Не мора да опишувате сè во детали, но потребен е основен опис за да можете да работите со него. Инаку, не е јасно што понатаму со континуирана испорака. Сите овие практики се одвиваат истовремено кога ќе дојдете на DevOps, но започнува со разбирање што имате и како да управувате со него. Ова е токму практиката на инфраструктурата како код.
Откако ќе стане јасно дека го имате и како да управувате со него, почнувате да сфаќате како да го испратите кодот на развивачот до производство што е можно побрзо. Мислам заедно со развивачот - се сеќаваме на проблемот со „бунарите“, односно, не се поединечни луѓе кои го смислуваат ова, туку тим.
Кога сме со Вања Евтухович ја виде првата книга Џез Смирен и групи на автори „Континуирана испорака“, кој беше објавен во 2009 година, долго размислувавме како да го преведеме неговиот наслов на руски. Сакаа да го преведат како „Постојано достава“, но, за жал, беше преведен како „Континуирана испорака“. Ми се чини дека има нешто руско во наше име, со притисок.
Постојано доставување средства
Кодот што се наоѓа во складиштето на производи секогаш може да се преземе во производството. Можеби не е издувен, но секогаш е подготвен за тоа. Соодветно на тоа, секогаш пишувате код со тешко објаснето чувство на некаква вознемиреност под вашата опашка. Често се појавува кога ќе го објавите инфраструктурниот код. Ова чувство на одредена вознемиреност треба да биде присутно - предизвикува мозочни процеси кои ви дозволуваат да пишувате код малку поинаку. Ова треба да биде запишано во правилата во рамките на развојот.
За постојано испорачување, потребен ви е формат на артефакт што се протега низ инфраструктурна платформа. Ако фрлите „животен отпад“ од различни формати низ инфраструктурна платформа, тогаш таа станува обединета, тешко е да се одржува и се појавува проблемот со техничкиот долг. Форматот на артефактот треба да се усогласи - ова е исто така колективна задача: сите ние треба да се собереме, да го шушкаме мозокот и да го смислиме овој формат.
Артефактот постојано се подобрува и се менува за да одговара на производствената средина додека се движи низ цевководот за испорака. Кога некој артефакт се движи по цевководот, постојано наидува на некои незгодни работи за него, кои се слични на она што го среќава артефактот што го ставате во производство. Ако во класичниот развој тоа го прави системски администратор кој го прави rollout, тогаш во процесот DevOps тоа се случува цело време: овде го тестираа со некои тестови, овде го фрлија во кластерот Kubernetes, кој е повеќе или помалку сличен. до производство, а потоа одеднаш почнаа со тестирање на оптоварување.
Ова донекаде потсетува на играта Pac-Man - артефактот поминува низ некаква приказна. Во исто време, важно е да контролирате дали кодот навистина поминува низ приказната и дали е некако поврзан со вашата продукција. Приказните од производството може да се влечат во процесот на континуирана испорака: вака беше кога нешто падна, сега само да го програмираме ова сценарио во системот. Секој пат кога кодот ќе помине и низ ова сценарио, и следниот пат нема да наидете на овој проблем. Ќе дознаете за тоа многу порано отколку што ќе стигне до вашиот клиент.
Различни стратегии за распоредување. На пример, користите AB тестирање или распоредувања на канари за да го тестирате кодот поинаку на различни клиенти, да добивате информации за тоа како функционира кодот и многу порано отколку кога ќе биде претставен на 100 милиони корисници.
„Постојано испорачај“ изгледа вака.
Процесот на испорака Dev, CI, Test, PreProd, Prod не е посебна средина, тоа се фази или станици со огноотпорни суми низ кои поминува вашиот артефакт.
Ако имате инфраструктурен код кој е опишан како Base Service APP тогаш тоа ви помага не заборавајте ги сите сценаријаи запишете ги како код за овој артефакт, промовираат артефакт и менувајте го додека одите.
Прашања за самотестирање
Времето од описот на функцијата до пуштањето во производство во 95% од случаите е помалку од една недела? Дали квалитетот на артефактот се подобрува во секоја фаза од гасоводот? Дали има приказна низ која поминува? Дали користите различни стратегии за распоредување?
Ако сите одговори се да, тогаш сте неверојатно кул! Напишете ги вашите одговори во коментари - ќе ми биде драго).
повратна информација
Ова е најтешката практика од сите. На конференцијата DevOpsConf, еден колега од Infobip, зборувајќи за тоа, беше малку збунет во неговите зборови, бидејќи ова е навистина многу сложена практика за тоа дека треба да следите сè!
На пример, многу одамна, кога работев во Qik и сфативме дека треба да следиме сè. Го направивме ова и сега имаме 150 артикли во Zabbix, кои постојано се следат. Беше страшно, техничкиот директор го заврте прстот во слепоочницата:
- Момци, зошто го силувате серверот со нешто нејасно?
Но, тогаш се случи инцидент кој покажа дека ова е навистина многу кул стратегија.
Една од сервисите почна постојано да паѓа. Првично, не се урна, што е интересно, кодот не беше додаден таму, бидејќи беше основен брокер, кој практично немаше никаква деловна функционалност - едноставно испраќаше пораки помеѓу поединечни сервиси. Услугата не се смени 4 месеци и одеднаш почна да се урива со грешката „Грешка на сегментација“.
Бевме шокирани, ги отворивме нашите графикони во Zabbix и се покажа дека пред една и пол недела, однесувањето на барањата во услугата API што ја користи овој брокер многу се промени. Следно, видовме дека фреквенцијата на испраќање одреден тип на порака е променета. Подоцна дознавме дека тоа се андроид клиенти. Прашавме:
- Момци, што се случи со вас пред недела и половина?
Како одговор, слушнавме интересна приказна за тоа како тие го редизајнирале интерфејсот. Малку е веројатно дека некој веднаш ќе каже дека ја сменил библиотеката HTTP. За клиентите на Android, тоа е како менување сапун во бањата - тие едноставно не се сеќаваат. Како резултат на тоа, по 40 минути разговор, дознавме дека тие ја смениле библиотеката HTTP и нејзините стандардни тајминзи се сменија. Ова доведе до промена на сообраќајното однесување на серверот API, што доведе до ситуација што предизвика трка во брокерот и тој почна да се урива.
Без длабок мониторинг генерално е невозможно да се отвори ова. Ако организацијата сè уште го има проблемот со „бунарите“, кога сите си фрлаат пари еден на друг, тоа може да живее со години. Едноставно го рестартирате серверот затоа што е невозможно да се реши проблемот. Кога ги следите, следите, следите сите настани што ги имате и го користите следењето како тестирање - напишете код и веднаш посочете како да го следите, исто така во форма на код (инфраструктурата веќе ја имаме како код), се станува јасно како на дланката. Дури и таквите сложени проблеми лесно се следат.
Соберете ги сите информации за тоа што се случува со артефактот во секоја фаза од процесот на испорака - не во производство.
Поставете го мониторингот на CI, и некои основни работи веќе ќе бидат видливи таму. Подоцна ќе ги видите во тест, PredProd и оптоварување. Соберете информации во сите фази, не само метрика, статистика, туку и дневници: како се појави апликацијата, аномалии - соберете сè.
Во спротивно ќе биде тешко да се сфати. Веќе реков дека DevOps е покомплексен. За да се справите со оваа сложеност, треба да имате нормална аналитика.
Прашања за самоконтрола
Дали вашето следење и евиденција е алатка за развој за вас? Кога пишувате код, дали вашите програмери, вклучително и вас, размислуваат како да го следат?
Дали слушате за проблеми од клиентите? Дали подобро го разбирате клиентот од следењето и евиденцијата? Дали подобро го разбирате системот од следење и евидентирање? Дали го менувате системот само затоа што видовте дека трендот во системот расте и разбирате дека за уште 3 недели сè ќе умре?
Откако ќе ги имате овие три компоненти, можете да размислите каква инфраструктурна платформа имате во вашата компанија.
Инфраструктурна платформа
Поентата не е дека тоа е збир на различни алатки што ги има секоја компанија.
Поентата на инфраструктурната платформа е дека сите тимови ги користат овие алатки и ги развиваат заедно.
Јасно е дека постојат посебни тимови кои се одговорни за развој на поединечни делови од инфраструктурната платформа. Но, во исто време, секој инженер сноси одговорност за развојот, перформансите и промоцијата на инфраструктурната платформа. На внатрешно ниво станува вообичаена алатка.
Сите тимови ја развиваат инфраструктурната платформа и внимателно ја третираат како сопствен IDE. Во вашиот IDE инсталирате различни приклучоци за да направите сè да биде убаво и брзо и да ги конфигурирате кратенки копчиња. Кога ќе ги отворите Sublime, Atom или Visual Studio Code, се појавуваат грешки во кодот и сфаќате дека воопшто е невозможно да се работи, веднаш се чувствувате тажно и трчате да го поправите вашиот IDE.
Третирајте ја вашата инфраструктурна платформа на ист начин. Ако разбирате дека нешто не е во ред со тоа, оставете барање ако не можете сами да го поправите. Ако има нешто едноставно, уредете го сами, пратете барање за повлекување, момците ќе го разгледаат и ќе го додадат. Ова е малку поинаков пристап кон инженерските алатки во главата на развивачот.
Инфраструктурната платформа обезбедува пренос на артефактот од развој на клиентот со постојано подобрување на квалитетот. IP е програмиран со збир на приказни што се случуваат со кодот во производството. Со текот на годините на развој, има многу од овие приказни, некои од нив се уникатни и се однесуваат само на вас - не може да се пребаруваат на Google.
Во овој момент, инфраструктурната платформа станува ваша конкурентна предност, бидејќи има нешто вградено во него што не е во алатката на конкурентот. Колку е подлабока вашата IP адреса, толку е поголема вашата конкурентна предност во однос на Времето до пазар. Се појавува овде проблем со заклучување на продавачот: Можете да земете туѓа платформа, но користејќи туѓо искуство, нема да разберете колку е тоа релевантно за вас. Да, не секоја компанија може да изгради платформа како Amazon. Ова е тешка линија каде што искуството на компанијата е релевантно за нејзината позиција на пазарот и таму не можете да користите брава за продавач. Ова е исто така важно да се размислува.
Шемата
Ова е основен дијаграм на инфраструктурна платформа која ќе ви помогне да ги поставите сите практики и процеси во компанијата DevOps.
Ајде да погледнеме од што се состои.
Систем за оркестрација на ресурси, кој обезбедува процесор, меморија, диск на апликации и други услуги. Згора на ова - услуги на ниско ниво: следење, логирање, CI/CD мотор, складирање на артефакти, инфраструктура како системски код.
Услуги од повисоко ниво: база на податоци како услуга, редици како услуга, Load Balance како услуга, промена на големината на сликата како услуга, фабрика за големи податоци како услуга. Згора на ова - цевковод кој доставува постојано модифициран код до вашиот клиент.
Добивате информации за тоа како вашиот софтвер работи за клиентот, го менувате, повторно го снабдувате овој код, добивате информации - и така постојано ја развивате и инфраструктурната платформа и вашиот софтвер.
На дијаграмот, цевководот за испорака се состои од многу фази. Но, ова е шематски дијаграм што е даден како пример - нема потреба да се повторува еден по еден. Фазите комуницираат со услугите како да се услуги - секоја тула на платформата носи своја приказна: како се распределуваат ресурсите, како се активира апликацијата, како работи со ресурси, се следи и се менува.
Важно е да разберете дека секој дел од платформата носи приказна и запрашајте се каква приказна носи оваа тула, можеби треба да се фрли и да се замени со услуга од трета страна. На пример, дали е можно да се инсталира Okmeter наместо цигла? Можеби момците веќе ја имаат развиено оваа експертиза многу повеќе од нас. Но, можеби не - можеби имаме единствена експертиза, треба да го инсталираме Prometheus и да го развиеме понатаму.
Создавање на платформата
Ова е сложен процес на комуникација. Кога имате основни практики, започнувате комуникација помеѓу различни инженери и специјалисти кои развиваат барања и стандарди и постојано ги менувате на различни алатки и пристапи. Културата што ја имаме во DevOps е важна овде.
Со културата сè е многу едноставно - се работи за соработка и комуникација, односно желбата да се работи на заедничко поле едни со други, желбата да се ракува со еден инструмент заедно. Овде нема ракетна наука - сè е многу едноставно, банално. На пример, сите живееме во влезот и го одржуваме чист - такво ниво на култура.
Што имаш?
Повторно, прашања што можете да си ги поставите.
Дали е посветена инфраструктурната платформа? Кој е одговорен за неговиот развој? Дали ги разбирате конкурентните предности на вашата инфраструктурна платформа?
Треба постојано да си ги поставувате овие прашања. Ако нешто може да се пренесе на услуги од трети лица, треба да се пренесе; ако услуга од трета страна почне да го блокира вашето движење, тогаш треба да изградите систем во себе.
Значи, DevOps...
... ова е сложен систем, мора да има:
- Дигитален производ.
- Деловни модули кои го развиваат овој дигитален производ.
- Тимови на производи кои пишуваат код.
- Практики за континуирана испорака.
- Платформите како услуга.
- Инфраструктурата како услуга.
- Инфраструктурата како код.
- Посебни практики за одржување на доверливоста, вградени во DevOps.
- Практика за повратни информации што го опишува сето тоа.
Можете да го користите овој дијаграм, истакнувајќи го во него она што веќе го имате во вашата компанија во некоја форма: дали е развиено или сè уште треба да се развива.
Ќе биде готово за неколку недели . како дел од RIT++. Дојдете на конференцијата, каде што ќе најдете многу интересни извештаи за континуирана испорака, инфраструктура како код и трансформација на DevOps. , последен рок за цена е 20 мај
Извор: www.habr.com