Дефиниција ДевОпс-а је веома сложена, тако да сваки пут морамо да почнемо дискусију о томе изнова. Само на Хабреу постоји хиљаду публикација на ову тему. Али ако ово читате, вероватно знате шта је ДевОпс. Зато што нисам. Здраво, моје име је Александар Титов (@), а ми ћемо причати само о ДевОпс-у и поделићу своје искуство.
Дуго сам размишљао како да своју причу учиним корисном, тако да ће овде бити много питања – оних која постављам себи и оних које постављам клијентима наше компаније. Одговарајући на ова питања, разумевање постаје боље. Рећи ћу вам зашто је ДевОпс потребан са моје тачке гледишта, шта је то, опет, са моје тачке гледишта, и како да разумете да се поново крећете ка ДевОпс-у из моје тачке гледишта. Последња тачка ће бити низ питања. Ако сами одговорите на њих, можете разумети да ли се ваша компанија креће ка ДевОпс-у или на неки начин постоје проблеми.
Једно време сам јахао таласе спајања и аквизиција. Прво сам радио за мали стартап по имену Кик, затим га је купила мало већа компанија по имену Скипе, коју је потом купила мало већа компанија Мицрософт. У том тренутку сам почео да увиђам како се идеја о ДевОпс-у трансформише у компанијама различитих величина. Након тога сам се заинтересовао да сагледам ДевОпс са тржишне тачке гледишта, а моје колеге и ја смо основали компанију Екпресс 42. Већ 6 година се крећемо дуж таласа тржишта.
Између осталог, ја сам један од организатора заједнице ДевОпс Москва и организатор ДевОпс-Даис 2017, али 2018 нисам организовао. Екпресс 42 ради са многим компанијама. Тамо развијамо ДевОпс, гледамо како се то дешава, доносимо закључке, анализирамо, свима кажемо своје закључке и обучавамо људе у ДевОпс пракси. Уопштено говорећи, дајемо све од себе да повећамо наше искуство и стручност у овом погледу.
Зашто ДевОпс
Прво питање које прогања све и увек је – зашто? Многи људи мисле да је ДевОпс само аутоматизација или слична ствар коју је свака компанија већ имала.
— Имали смо континуирану интеграцију – то значи да смо већ имали ДевОпс, и зашто су све ове ствари потребне? У иностранству се забављају, а нас спречавају да радимо!
Током 9 година развоја заједнице и методологије, већ је постало јасно да ово још увек није маркетиншки сјај, али још увек није сасвим јасно зашто је то потребно. Као и сваки алат и процес, ДевОпс има специфичне циљеве које на крају постиже.
Све ово је због чињенице да се свет мења. Он се удаљава од предузетничког приступа, када компаније крећу право ка сну, како је певао наш петербуршки класик, од тачке А до тачке Б према одређеној стратегији, са одређеном структуром изграђеном за то.
У принципу, све у ИТ-у треба да се гради према овом приступу. Овде се ИТ користи искључиво за аутоматизацију процеса.
Аутоматизација се не мења често, јер када компанија крене утабаном колотечином, шта се ту мења? Ради - не дирај га. Сада се приступи у свету мењају, а онај који се зове Агиле сугерише да крајња тачка Б није одмах видљива.
Када компанија пролази кроз тржиште, ради са клијентом, она стално истражује тржиште и мења крајњу тачку Б. Штавише, што чешће компанија мења свој правац, то је на крају успешнија, јер бира више тржишта. нише.
Стратегију показује једна занимљива компанија за коју сам недавно сазнао. Оне Бок Схаве је претплатничка услуга доставе бријача и прибора за бријање у кутији. Они знају како да прилагоде своју „кутију“ за различите клијенте. То ради одређени софтвер, који затим шаље наруџбу корејској фабрици која производи робу.
Овај производ је купио Унилевер за милијарду долара. Сада се такмичи са Гиллетте-ом и одузео је значајан удео потрошача на америчком тржишту. Оне Бок Схаве каже:
— 4 оштрице? Јеси ли озбиљно? Зашто вам је ово потребно - не побољшава квалитет бријања. Посебно одабрана крема, мирис и висококвалитетни бријач са две оштрице решавају много више проблема од оних глупих 4 Гиллетте оштрице! Хоћемо ли ускоро стићи до 10?
Овако се свет мења. Унилевер тврди да имају кул ИТ систем који вам то омогућава. На крају то изгледа као концепт Време за стављање на тржиште, о чему нико већ није говорио.
Поента времена за стављање на тржиште није колико често примењујемо. Често можете да примените, али циклуси издавања ће бити дуги. Ако се тромесечни циклуси издавања преклапају један са другим, померајући их за недељу дана, испада да се чини да компанија примењује једном недељно. А од идеје до коначне реализације потребно је 3 месеца.
Време до изласка на тржиште се односи на минимизирање времена од идеје до коначне имплементације.
У овом случају, софтвер је у интеракцији са тржиштем. Овако веб локација Оне Бок Схаве комуницира са клијентом. Они немају продавце - само веб страницу на којој посетиоци кликну и оставе жеље. Сходно томе, нешто ново се мора стално постављати на сајт и ажурирати у складу са жељама. На пример, у Јужној Кореји се брију другачије него у Русији, а не воле мирис бора, већ, на пример, шаргарепе и ваниле.
Пошто је неопходно брзо променити садржај сајта, развој софтвера се у великој мери мења. Кроз софтвер морамо сазнати шта клијент жели. Раније смо то научили кроз неке заобилазне начине, на пример, кроз управљање пословањем. Онда смо то дизајнирали, убацили захтеве у ИТ систем и све је било кул. Сада је другачије - софтвер дизајнирају сви који су укључени у процес, укључујући инжењере, јер кроз техничке спецификације уче како тржиште функционише и такође деле своје увиде са пословањем.
На пример, у Кик-у смо изненада сазнали да људи заиста воле да отпремају листе контаката на сервер и дали су нам апликацију. У почетку нисмо размишљали о томе. У класичној компанији, сви би одлучили да је ово грешка, пошто спецификација није рекла да треба да ради одлично и генерално је имплементирана на колену, искључили би функцију и рекли: „Ово никоме не треба, најважније је да главна функционалност ради.” . А технолошка компанија то види као прилику и почиње да мења софтвер у складу са тим.
1968. визионар, Мелвин Конвеј, формулисао је следећу идеју.
Организација која креира систем је ограничена дизајном који реплицира структуру комуникације те организације.
Детаљније, да бисте произвели системе другачијег типа, морате имати и комуникацијску структуру унутар компаније другог типа. Ако је ваша комуникациона структура врхунска, онда вам то неће дозволити да креирате системе који могу да обезбеде веома висок индикатор времена до тржишта.
читати може се . Важно је за разумевање ДевОпс културе или филозофије јер једина ствар која се суштински мења у ДевОпс-у је структура комуникације између тимова.
Са тачке гледишта процеса, пре ДевОпс-а, све фазе: аналитика, развој, тестирање, рад, биле су линеарне.
У случају ДевОпс-а, сви ови процеси се одвијају истовремено.
Време изласка на тржиште је једини начин на који се то може учинити. За људе који су радили у старом процесу, ово изгледа некако космички, и генерално тако-тако.
Па зашто вам је потребан ДевОпс?
За развој дигиталних производа. Ако ваша компанија нема дигитални производ, ДевОпс није потребан – веома је важан.
ДевОпс превазилази ограничења брзине секвенцијалне производње софтвера. У њему се сви процеси одвијају истовремено.
Потешкоће се повећавају. Када вам ДевОпс еванђелисти кажу да ће вам то олакшати издавање софтвера, то је бесмислица.
Са ДевОпс-ом, ствари ће бити само компликованије.
На конференцији на Авито штанду, могли сте да видите како је било поставити Доцкер контејнер – нереални задатак. Сложеност постаје превисока; морате жонглирати са више лоптица у исто време.
ДевОпс у потпуности мења процес и организацију у компанији — тачније, не мења се ДевОпс, већ дигитални производ. Да бисте дошли у ДевОпс, и даље морате потпуно променити овај процес.
Питања за специјалисте
Шта имаш? Питања која можете себи поставити док радите у компанији и развијате се као специјалиста.
Да ли имате стратегију за креирање дигиталног производа? Ако постоји, то је већ добро. То значи да се ваша компанија креће ка ДевОпс-у.
Да ли ваша компанија већ ствара дигитални производ? То значи да се можете подићи још један ниво више и радити ствари занимљивије – опет са ДевОпс тачке гледишта. Ја само говорим са ове тачке гледишта.
Да ли је ваша компанија један од тржишних лидера у ниши дигиталних производа? Спотифај, Јандекс, Убер су компаније које су сада на врхунцу технолошког напретка.
Поставите себи ова питања, а ако су сви одговори не, онда можда не бисте требали радити ДевОпс у овој компанији. Ако вам је тема ДевОпс-а заиста интересантна, можда... треба да пређете у другу компанију? Ако ваша компанија жели да уђе у ДевОпс, али сте одговорили са „Не“ на сва питања, онда је то као онај прелепи носорог који се никада неће променити.
Организација
Као што сам рекао, према Конвејевом закону, организација компаније се мења. Почећу са оним што спречава ДевОпс да продре у компанију са организационе тачке гледишта.
Проблем "бунара"
Енглеска реч „Сило” овде је преведена на руски као „добро”. Поента овог проблема је у томе нема размене информација између тимова. Сваки тим дубоко копа у своју стручност, без прављења заједничке мапе за навигацију.
Ово ме на неки начин подсећа на особу која је управо стигла у Москву и још не зна како да се креће по мапи метроа. Московљани обично веома добро познају своју област, а широм Москве могу да се крећу помоћу мапе метроа. Када први пут дођете у Москву, немате ту вештину и једноставно сте дезоријентисани.
ДевОпс предлаже да се прође кроз овај тренутак дезоријентације и да сви одељења раде заједно на изградњи заједничке мапе интеракције.
Два фактора ометају ово.
Последица система корпоративног управљања. Изграђен је у одвојеним хијерархијским „бунарима“. На пример, постоје одређени КПИ у компанијама које подржавају овај систем. С друге стране, мозак особе којој је тешко да пређе границе своје стручности и да се креће кроз читав систем смета. Само је непријатно. Замислите да сте на аеродрому у Бангкоку - нећете се брзо снаћи. ДевОпс-ом је такође тешко навигирати и зато људи кажу да морате пронаћи водич да бисте тамо стигли.
Али најважније је да се проблем „бушотина“ за инжењера који је прожет духом ДевОпс-а, који је прочитао Фаулера и гомилу других књига, изражава у чињеници да „бунари“ вам не дозвољавају да радите „очигледне“ ствари. Често се окупљамо након ДевОпс Москва, разговарамо једни са другима и људи се жале:
— Само смо хтели да покренемо ЦИ, али се испоставило да менаџменту то није потребно.
Ово се дешава управо зато CI и Континуирани процес испоруке налазе се на граници многих испитивања. Једноставно без превазилажења проблема „бунара“ на нивоу организације, нећете моћи да идете напред, шта год да радите и колико год да је тужно.
Сваки учесник у процесу у компанији: бацкенд и фронтенд програмери, тестирање, ДБА, операција, мрежа, копа у свом правцу, а нико нема заједничку мапу осим менаџера, који их некако прати и управља њима користећи „дивиде“ и освоји” метод.
Људи се боре за неке звезде или заставе, свако копа своју стручност.
Услед тога, када се појави задатак да се све ово повеже и изгради заједнички цевовод, а више нема потребе да се бори за звезде и заставе, поставља се питање – шта уопште да се ради? Морамо некако да се договоримо, али нас нико није учио како се то ради у школи. Од школе су нас учили: осми разред – вау! - у поређењу са седмим разредом! И овде је исто.
Да ли је тако и у вашој компанији?
Да бисте то проверили, можете себи поставити следећа питања.
Да ли тимови користе заједничке алате и доприносе променама тих заједничких алата?
Колико често се тимови реорганизују — неки стручњаци из једног тима прелазе у други тим? У ДевОпс окружењу то постаје нормално, јер понекад особа једноставно не може да разуме шта друга област стручности ради. Прелази у друго одељење, тамо ради две недеље да би себи направио мапу оријентације и интеракције са овим одељењем.
Да ли је могуће формирати одбор за промене и променити ствари? Или је за то потребна јака рука највишег менаџмента и руководства? Недавно сам писао на Фејсбуку како једна мало позната банка имплементира алате кроз налоге: напишемо налог, спроведемо га годину дана и видимо шта ће се десити. Ово је, наравно, дуго и тужно.
Колико је важно да менаџери примају лична достигнућа не узимајући у обзир достигнућа компаније?
Ако сами одговорите на ова питања, биће вам јасније да ли имате такав проблем у вашој компанији.
Инфраструктура као код
Након што се овај проблем реши, прва важна пракса без које је тешко напредовати у ДевОпс-у је инфраструктура као код.
Најчешће се инфраструктура као код доживљава на следећи начин:
— Хајде да аутоматизујемо све у басх-у, покријемо се скриптама како би администратори имали мање ручног рада!
Али то није истина.
Инфраструктура као код значи да ИТ систем са којим радите описујете у облику кода како бисте стално разумели његово стање.
Заједно са другим тимовима, ви креирате мапу у облику кода коју свако може да разуме и може да се креће и креће. Није важно на чему се ради – Цхеф, Ансибле, Салт или користећи ИАМЛ датотеке у Кубернетес-у – нема разлике.
На конференцији је колега из 2ГИС-а испричао како су направили своју интерну ствар за Кубернетес, која описује структуру појединачних система. Да би описали 500 система, био им је потребан посебан алат који генерише овај опис. Када постоји овај опис, сви могу да провере једни код других, да прате промене, како то променити и побољшати, шта недостаје.
Слажем се, појединачне басх скрипте обично не пружају ово разумевање. У једној од фирми у којој сам радио, постојао је чак и назив за „врите онли“ скрипту – када је скрипта написана, али је више није могуће прочитати. Мислим да је и вама ово познато.
Инфраструктура каква јесте код који описује тренутно стање инфраструктуре. Многи тимови за производе, инфраструктуру и услуге раде заједно на овом коду, и што је најважније, сви морају да разумеју како овај код заправо функционише.
Код се одржава у складу са најбољом праксом кода: заједнички развој, преглед кода, КСП-програмирање, тестирање, пулл захтеви, ЦИ за инфраструктуру кода - све ово је погодно и може се користити.
Код постаје заједнички језик за све инжењере.
Промена инфраструктуре у коду не одузима много времена. Да, инфраструктурни код може имати и технички дуг. Обично се тимови са тим сусрећу годину и по дана након што су почели да имплементирају „инфраструктуру као код“ у облику гомиле скрипти или чак Ансибле-а, који пишу као шпагети код, а такође убацују и басх скрипте!
То је важно: Ако још нисте пробали ове ствари, запамтите то Ансибле није басх! Пажљиво прочитајте документацију, проучите шта о њој пишу.
Инфраструктура као код је одвајање инфраструктурног кода у засебне слојеве.
У нашој компанији разликујемо 3 основна слоја, који су врло јасни и једноставни, али их може бити више. Можете погледати свој инфраструктурни код и рећи да ли имате ово стање или не. Ако ниједан слој није истакнут, потребно је да одвојите мало времена и мало га преправите.
Основни слој - овако се конфигуришу ОС, резервне копије и друге ствари ниског нивоа, на пример, како се Кубернетес примењује на основном нивоу.
Ниво услуге - ово су услуге које пружате програмеру: логовање као сервис, праћење као сервис, база података као услуга, балансер као услуга, ред као услуга, континуирана испорука као услуга - гомила услуга које поједини тимови може пружити развоју. Све ово треба да буде описано у посебним модулима у вашем систему за управљање конфигурацијом.
Слој на коме се праве апликације и описује како ће се одвијати на претходна два слоја.
Контролна питања
Да ли ваша компанија има заједничко складиште инфраструктуре? Да ли управљате техничким дугом у својој инфраструктури? Да ли користите развојне праксе у инфраструктурном репозиторијуму? Да ли је ваша инфраструктура исечена на слојеве? Можете проверити дијаграм Басе-сервице-АПП. Колико је тешко направити промену?
Ако сте искусили да је за измене требало дан и по, то значи да имате технички дуг и да морате да радите са њим. Управо сте налетели на техничку грабу дуга у вашем инфраструктурном коду. Сећам се много таквих прича када, да бисте променили неки ЦЦТЛ, треба да препишете пола инфраструктурног кода, јер је креативност и жеља да се све аутоматизује довели до тога да је све нагризало свуда, све ручке су уклоњене и потребно је рефакторисати.
Континуирана испорука
Хајде да упоредимо задужење са кредитом. Прво долази опис инфраструктуре, који може бити прилично једноставан. Не морате све детаљно описивати, али је потребан неки основни опис да бисте могли да радите са њим. Иначе, није јасно шта даље са континуираном испоруком. Све ове праксе се одвијају истовремено када дођете у ДевОпс, али почиње са разумевањем шта имате и како то да управљате. То је управо пракса инфраструктуре као кода.
Када постане јасно да га имате и како да њиме управљате, почињете да схватате како да пошаљете програмски код у производњу што је брже могуће. Мислим заједно са програмером - сећамо се проблема „бунара“, то јест, не долазе поједини људи, већ тим.
Када смо са Вања Евтухович видео прву књигу Јез Хумбле и групе аутора "Непрекидна испорука", који је изашао 2009. године, дуго смо размишљали како да преведемо његов наслов на руски. Хтели су да то преведу као „Константно испоруку“, али је, нажалост, преведено као „Непрекидна испорука“. Чини ми се да има нешто руско у нашем имену, са притиском.
Стално испоручујући средства
Код који се налази у спремишту производа увек се може преузети у производњу. Можда није издуван, али је увек спреман за то. Сходно томе, увек пишете код са тешко објашњивим осећајем неке анксиозности испод репа. Често се појављује када уведете инфраструктурни код. Овај осећај неке анксиозности би требало да буде присутан - он покреће мождане процесе који вам омогућавају да пишете код мало другачије. Ово треба да буде забележено у правилима у оквиру развоја.
Да бисте доследно испоручили, потребан вам је формат артефакта који ради на инфраструктурној платформи. Ако баците „животни отпад“ различитих формата преко инфраструктурне платформе, онда она постаје уједињена, тешко се одржава и јавља се проблем техничког дуга. Формат артефакта треба да се усклади - ово је такође колективни задатак: сви треба да се окупимо, зашушкамо и смислимо овај формат.
Артефакт се континуирано побољшава и мења како би одговарао производном окружењу док се креће кроз цевовод за испоруку. Када се артефакт креће дуж цевовода, он се стално сусреће са неким незгодним стварима за њега, које су сличне онима са којима се сусреће артефакт који ставите у продукцију. Ако у класичном развоју то ради систем администратор који ради роллоут, онда се у ДевОпс процесу то дешава стално: овде су га тестирали неким тестовима, овде су га бацили у Кубернетес кластер, који је мање-више сличан до производње, а онда су изненада почели тестирање оптерећења.
Ово донекле подсећа на игру Пац-Ман - артефакт пролази кроз неку врсту приче. Истовремено, важно је контролисати да ли код заиста пролази кроз причу и да ли је на неки начин повезан са вашом продукцијом. Приче из продукције се могу увући у процес континуиране испоруке: било је овако када је нешто пало, сада само програмирајмо овај сценарио унутар система. Сваки пут ће код проћи и кроз овај сценарио, а следећи пут нећете наићи на овај проблем. Сазнаћете о томе много раније него што стигне до вашег клијента.
Различите стратегије примене. На пример, користите АБ тестирање или канаричке примене да бисте тестирали код на различите начине на различитим клијентима, добили информације о томе како код функционише и то много раније него када је уведен на 100 милиона корисника.
„Доследно испоручивање“ изгледа овако.
Процес испоруке Дев, ЦИ, Тест, ПреПрод, Прод није засебно окружење, то су фазе или станице са ватросталним сумама кроз које пролази ваш артефакт.
Ако имате инфраструктурни код који је описан као Басе Сервице АПП, онда то помаже не заборавите све скрипте, и запишите их као код за овај артефакт, промовисати артефакт и мењајте га док идете.
Питања за самотестирање
Време од описа функције до пуштања у производњу у 95% случајева је мање од недељу дана? Да ли се квалитет артефакта побољшава у свакој фази цевовода? Постоји ли прича кроз коју то пролази? Да ли користите различите стратегије примене?
Ако су сви одговори потврдни, онда сте невероватно кул! Напишите своје одговоре у коментарима - биће ми драго).
povratne информације
Ово је најтежа пракса од свих. На ДевОпсЦонф конференцији, колега из Инфобип-а, говорећи о томе, био је мало збуњен у својим речима, јер је ово заиста веома сложена пракса о томе да све треба да пратите!
На пример, давно, када сам радио у Кик-у и схватили смо да морамо све да пратимо. То смо урадили и сада имамо 150 артикала у Заббик-у, који се стално надгледају. Било је страшно, технички директор је заврнуо прстом на слепоочници:
- Људи, зашто силујете сервер нечим нејасним?
Али онда се догодио инцидент који је показао да је ово заиста веома кул стратегија.
Један од сервиса је почео стално да руши. У почетку се није срушио, што је занимљиво, ту није додат код, јер је то био основни брокер, који практично није имао никакву пословну функционалност – једноставно је слао поруке између појединачних сервиса. Услуга се није мењала 4 месеца, а изненада је почела да се руши са грешком „Крешка сегментације“.
Били смо шокирани, отворили наше графиконе у Заббик-у и испоставило се да се пре недељу и по дана понашање захтева у АПИ сервису који користи овај брокер у великој мери променило. Затим смо видели да се променила учесталост слања одређене врсте порука. Касније смо сазнали да су то били андроид клијенти. Питали смо:
— Људи, шта вам се десило пре недељу и по?
Као одговор, чули смо занимљиву причу о томе како су редизајнирали кориснички интерфејс. Мало је вероватно да ће неко одмах рећи да је променио ХТТП библиотеку. За Андроид клијенте, то је као да мењају сапун у купатилу - једноставно се не сећају. Као резултат тога, након 40 минута разговора, сазнали смо да су променили ХТТП библиотеку и да су се променила њена подразумевана времена. То је довело до промене понашања у саобраћају на АПИ серверу, што је довело до ситуације која је изазвала трку унутар брокера и он је почео да пада.
Без дубоког праћења, генерално је немогуће отворити ово. Ако организација и даље има проблем „бунара“, када сви бацају новац једни на друге, ово може да живи годинама. Једноставно рестартујете сервер јер је немогуће решити проблем. Када надгледате, пратите, пратите све догађаје које имате и користите праћење као тестирање – напишете код и одмах назначите како да га надгледате, такође у облику кода (инфраструктуру већ имамо као код), све постаје јасно како на длану. Чак и овако сложени проблеми се лако прате.
Прикупите све информације о томе шта се дешава са артефактом у свакој фази процеса испоруке - не у производњи.
Учитајте мониторинг у ЦИ и неке основне ствари ће већ бити видљиве тамо. Касније ћете их видети у Тесту, ПредПрод-у и тестирању оптерећења. Прикупљајте информације у свим фазама, не само метрику, статистику, већ и евиденцију: како се апликација појавила, аномалије - прикупите све.
У супротном, биће тешко то схватити. Већ сам рекао да је ДевОпс сложенији. Да бисте се носили са овом сложеношћу, морате имати нормалну аналитику.
Питања за самоконтролу
Да ли је ваше праћење и евидентирање развојни алат за вас? Када пишете код, да ли ваши програмери, укључујући и вас, размишљају о томе како да га надгледају?
Да ли чујете о проблемима од купаца? Да ли боље разумете клијента из надгледања и евидентирања? Да ли боље разумете систем из надгледања и евидентирања? Да ли мењате систем само зато што сте видели да тренд у систему расте и разумете да ће за још 3 недеље све умрети?
Када имате ове три компоненте, можете размишљати о томе какву инфраструктурну платформу имате у својој компанији.
Инфраструктурна платформа
Поента није у томе да је то скуп различитих алата које свака компанија има.
Поента инфраструктурне платформе је да сви тимови користе ове алате и развијају их заједно.
Јасно је да постоје одвојени тимови који су одговорни за развој појединачних делова инфраструктурне платформе. Али у исто време, сваки инжењер сноси одговорност за развој, перформансе и промоцију инфраструктурне платформе. На унутрашњем нивоу постаје уобичајено оруђе.
Сви тимови развијају инфраструктурну платформу и третирају је пажљиво као сопствени ИДЕ. У свом ИДЕ-у инсталирате различите додатке да све буде лепо и брзо и конфигуришете пречице. Када отворите Сублиме, Атом или Висуал Студио Цоде, хрле грешке кода и схватите да је уопште немогуће радити, одмах се осећате тужно и трчите да поправите свој ИДЕ.
Третирајте своју инфраструктурну платформу на исти начин. Ако разумете да нешто није у реду са тим, оставите захтев ако не можете сами да поправите. Ако постоји нешто једноставно, уредите сами, пошаљите пулл рекуест, момци ће то размотрити и додати. Ово је мало другачији приступ инжењерским алатима у глави програмера.
Инфраструктурна платформа обезбеђује пренос артефакта од развоја до клијента уз континуирано побољшање квалитета. ИП је програмиран скупом прича које се дешавају коду у производњи. Током година развоја, било је много ових прича, неке од њих су јединствене и односе се само на вас - не могу да се прогуглају.
У овом тренутку, инфраструктурна платформа постаје ваша конкурентска предност, јер има нешто уграђено у њега што није у алату конкурента. Што је ваш ИП дубљи, већа је ваша конкурентска предност у смислу времена до ступања на тржиште. Појављује се овде проблем са закључавањем добављача: Можете узети туђу платформу, али користећи туђе искуство, нећете схватити колико је то релевантно за вас. Да, не може свака компанија да направи платформу као што је Амазон. Ово је тешка линија у којој је искуство компаније релевантно за њену позицију на тржишту и тамо не можете користити закључавање добављача. О овоме је такође важно размислити.
Схема
Ово је основни дијаграм инфраструктурне платформе који ће вам помоћи да поставите све праксе и процесе у ДевОпс компанији.
Погледајмо од чега се састоји.
Систем оркестрације ресурса, који апликацијама и другим сервисима обезбеђује ЦПУ, меморију, диск. На врху овог - услуге ниског нивоа: праћење, евидентирање, ЦИ/ЦД Енгине, складиштење артефаката, инфраструктура као системски код.
Услуге вишег нивоа: база података као услуга, редови као услуга, баланс оптерећења као услуга, промена величине слике као услуга, фабрика великих података као услуга. На врху овог - цевовод који вашем клијенту испоручује стално модификовани код.
Добијате информације о томе како ваш софтвер ради за клијента, мењате га, поново дајете овај код, примате информације - и тако стално развијате и инфраструктурну платформу и свој софтвер.
На дијаграму, цевовод за испоруку се састоји од много фаза. Али ово је шематски дијаграм који је дат као пример - нема потребе да га понављате један по један. Фазе су у интеракцији са услугама као да су услуге—свака цигла платформе носи своју причу: како се додељују ресурси, како се апликација покреће, ради са ресурсима, надгледа се и мења.
Важно је схватити да сваки део платформе носи причу, и запитајте се коју причу носи ова цигла, можда би је требало бацити и заменити сервисом треће стране. На пример, да ли је могуће инсталирати Окметер уместо цигле? Можда су момци већ развили ову стручност много више од нас. Али можда и не – можда имамо јединствену експертизу, морамо да инсталирамо Прометхеус и да га даље развијамо.
Креирање платформе
Ово је сложен процес комуникације. Када имате основне праксе, започињете комуникацију између различитих инжењера и специјалиста који развијају захтеве и стандарде и стално их мењају у различите алате и приступе. Култура коју имамо у ДевОпс-у је овде важна.
Са културом је све врло једноставно - ради се о сарадњи и комуникацији, односно жеља да се међусобно ради на заједничком пољу, жеља да се заједно рукује једним инструментом. Овде нема ракетне науке - све је врло једноставно, банално. На пример, сви живимо у улазу и одржавамо га чистим – такав ниво културе.
Шта имаш?
Опет, питања која можете себи поставити.
Да ли је инфраструктурна платформа намењена? Ко је одговоран за њен развој? Да ли разумете конкурентске предности ваше инфраструктурне платформе?
Морате стално себи постављати ова питања. Ако се нешто може пренети на услуге трећих страна, то треба да се пренесе; ако услуга треће стране почне да блокира ваше кретање, онда морате да изградите систем у себи.
Дакле, ДевОпс...
... ово је сложен систем, мора да има:
- Дигитални производ.
- Пословни модули који развијају овај дигитални производ.
- Производни тимови који пишу код.
- Пракса континуиране испоруке.
- Платформе као услуга.
- Инфраструктура као услуга.
- Инфраструктура као код.
- Одвојене праксе за одржавање поузданости, уграђене у ДевОпс.
- Пракса повратних информација која све то описује.
Можете користити овај дијаграм, наглашавајући у њему оно што већ имате у својој компанији у неком облику: да ли је развијено или још треба да се развије.
Биће готово за пар недеља . као део РИТ++. Дођите на конференцију, где ћете наћи много цоол извештаја о континуираној испоруци, инфраструктури као коду и ДевОпс трансформацији. , последњи рок за цену је 20. мај
Извор: ввв.хабр.цом