Питање „како имплементирати девопс” постоји већ годинама, али нема много добрих материјала. Понекад постанете жртва реклама не баш паметних консултаната који морају да продају своје време, без обзира на то како. Понекад су то нејасне, крајње опште речи о томе како бродови мегакорпорација ору пространства универзума. Поставља се питање: шта нас то занима? Поштовани ауторе, можете ли јасно формулисати своје идеје у листу?
Све ово произилази из чињенице да се није накупило много праве праксе и разумевања исхода трансформација културе компаније. Промене у култури су дугорочне ствари, чији се резултати неће појавити за недељу или месец. Потребан нам је неко довољно стар да би видео како су се компаније градиле и пропадале годинама.
Јохн Виллис - један од очева ДевОпс-а. Џон има вишедеценијско искуство у раду са огромним бројем компанија. Недавно је Џон почео да примећује специфичне обрасце који се дешавају када ради са сваким од њих. Користећи ове архетипове, Џон води компаније на прави пут ДевОпс трансформације. Прочитајте више о овим архетиповима у преводу његовог извештаја са конференције ДевОопс 2018.
О говорнику:
Више од 35 година у ИТ менаџменту, учествовао у креирању претходника ОпенЦлоуд-а у компанији Цаноницал, учествовао у 10 стартапова, од којих су два продата Делл-у и Доцкер-у. Тренутно је потпредседник ДевОпс-а и дигиталних пракси у СЈ Тецхнологиес.
Следећа је прича из Џонове тачке гледишта.
Зовем се Џон Вилис и најлакше ме пронаћи је на Твитеру, . Имам исти алиас на Гмаил-у и ГитХуб-у. А можете пронаћи видео снимке мојих извештаја и презентација за њих.
Имам много састанака са ЦИО-овима разних великих компанија. Врло често се жале да не разумеју шта је ДевОпс, а свако ко покуша да им то објасни прича о нечем другом. Још једна уобичајена замерка је да ДевОпс не ради, иако се чини да директори раде све како им је објашњено. Реч је о великим компанијама старим више од сто година. Након разговора са њима, дошао сам до закључка да за многе проблеме није најприкладнија висока технологија, већ релативно нискотехнолошка решења. Недељама сам само разговарао са људима из различитих одељења. Оно што видите на првој слици у посту је мој последњи пројекат, овако је соба изгледала након три дана рада.
Шта је ДевОпс?
Заиста, ако питате 10 различитих људи, они ће дати 10 различитих одговора. Али ево занимљивости: свих десет ових одговора ће бити тачни. Овде нема погрешног одговора. Био сам прилично дубоко у ДевОпс-у, око 10 година, и био сам први Американац на првом ДевОпсДаи-у. Нећу рећи да сам паметнији од свих који су укључени у ДевОпс, али тешко да постоји неко ко је уложио толико труда на то. Верујем да се ДевОпс дешава када се људски капитал и технологија споје. Често заборављамо на људску димензију, иако много причамо о свим врстама култура.
Сада имамо пуно података, пет година академског истраживања, тестирање теорија на индустријском нивоу. Оно што нам ове студије говоре јесте да ако комбинујете неке обрасце понашања у организационој култури, можете постићи 2000 пута убрзање. Ово убрзање је праћено једнаким побољшањем стабилности. Ово је квантитативно мерење користи коју ДевОпс може донети било којој компанији. Пре пар година сам разговарао о ДевОпс-у са директором компаније Фортуне 5000. Када сам се припремао за презентацију, био сам веома нервозан јер сам морао да сумирам своје дугогодишње искуство у 5 минута.
На крају сам дао следеће Дефиниција ДевОпс-а: То је скуп пракси и образаца који омогућавају трансформацију људског капитала у организациони капитал високих перформанси. Пример је начин на који је Тојота радила у последњих 50 или 60 година.
(У даљем тексту овакви дијаграми нису дати као референтни материјал, већ као илустрације. Њихов садржај ће се разликовати за сваку нову компанију. Међутим, слика се може погледати засебно и увећати
Једна од најуспешнијих оваквих пракси је вредност поток мапирање. О томе је написано неколико добрих књига, од којих су најуспешније Карен Мартин. Али током протекле године, дошао сам до закључка да је чак и овај приступ превише високотехнолошки. Сигурно има много предности и много сам га користио. Али када вас извршни директор пита зашто његова компанија не може да пређе на нове шине, прерано је говорити о мапирању токова вредности. Постоји много много фундаменталнијих питања на која се прво мора одговорити.
Мислим да је грешка коју праве многе моје колеге што једноставно дају компанији водич од пет тачака, а затим се врате шест месеци касније и виде шта се догодило. Чак и добра шема као што је мапирање токова вредности има, рецимо, слепе тачке. Након стотина интервјуа са директорима разних компанија, развио сам одређени образац који нам омогућава да проблем разбијемо на његове компоненте, а сада ћемо разговарати о свакој од ових компоненти по реду. Пре примене било каквих технолошких решења, користим овај образац, и као резултат, сви моји зидови су прекривени дијаграмима. Недавно сам радио са заједничким фондом и завршио сам са 100-150 таквих шема.
Лоша култура једе добре приступе за доручак
Главна идеја је следећа: никаква количина Леан, Агиле, САФЕ и ДевОпс-а неће помоћи ако је сама култура организације лоша. То је као роњење у дубину без ронилачке опреме или рад без рендгенског снимка. Другим речима, да парафразирам Друцкера и Деминга: лоша организациона култура ће прогутати сваки добар систем без да се угуши.
Да бисте решили овај главни проблем, потребно је да предузмете следеће кораке:
- Учините све радове видљивим: потребно је да сав рад буде видљив. Не у смислу да мора нужно бити приказан на неком екрану, већ у смислу да мора бити видљив.
- Консолидовани системи управљања радом: системе управљања треба консолидовати. У проблему „племенског” знања и институционалног знања, у 9 од 10 случајева уско грло су људи. У књизи проблем је био са једном једином особом, Брентом, због чега је пројекат каснио три године. И свуда наилазим на ове "бренте". Да бих решио ова уска грла, користим следеће две ставке на нашој листи.
- Методологија теорије ограничења: Теорија ограничења.
- Хакови за сарадњу: хакови за сарадњу.
- Тоиота Ката (): Нећу много да причам о Тојоти Ката. Ако сте заинтересовани, на мом гитхуб-у на скоро сваку од ових тема.
- Тржишно оријентисана организација: тржишно оријентисана организација.
- Схифт-лево ревизори: ревизија у раним фазама циклуса.
Почињем да радим са организацијом врло једноставно: одем у компанију и разговарам са запосленима. Као што видите, нема високе технологије. Све што вам треба је нешто на чему ћете писати. Окупљам неколико тимова у једној просторији и анализирам оно што ми говоре из перспективе мојих 7 архетипова. А онда им сам дам фломастер и замолим их да запишу на табли све што су до сада наглас рекли. Обично на оваквим састанцима постоји једна особа која све записује, а у најбољем случају може да запише 10% дискусије. Са мојом методом, ова цифра се може подићи на око 40%.
(Ова илустрација се може погледати засебно )
Мој приступ је заснован на делу Вилијама Шнајдера. ). Приступ се заснива на идеји да се свака организација може поделити на четири квадрата. Ова шема за мене је обично резултат рада са оним стотинама других шема које се јављају приликом анализе организације. Претпоставимо да имамо организацију са високим нивоом контроле, али са ниском компетентношћу. Ово је крајње непожељна опција: када се сви држе границе, али нико не зна шта да ради.
Нешто боља опција је она са високим нивоом контроле и компетенције. Ако је таква компанија профитабилна, онда јој можда није потребан ДевОпс. Најинтересантније је радити са компанијом која има висок ниво контроле, ниску компетентност и сарадњу, али у исто време висок ниво културе (култивације). То значи да компанија има много људи који тамо воле да раде и да је флуктуација радне снаге мала.
(Ова илустрација се може погледати засебно )
Чини ми се да методе са ригидним смерницама на крају стоје на путу да се дође до истине. Нарочито у мапирању токова вредности, постоје многа правила која се односе на то како информације треба да буду структурисане. У раним фазама рада, о којима сада говорим, ова правила никоме нису потребна. Ако особа са маркером у рукама на табли описује стварно стање у компанији, ово је најбољи начин да се разуме стање ствари. Такве информације не допиру до директора. У овом тренутку је глупо прекинути особу и рећи да је погрешно нацртао некакву стрелу. У овој фази, боље је користити једноставна правила, на пример: вишеслојна апстракција се може креирати једноставно коришћењем вишебојних маркера.
Понављам, без високе технологије. Црни маркер приказује објективну стварност како све функционише. Црвеним маркером људи означавају оно што им се не свиђа у тренутном стању ствари. Важно је да ово пишу они, а не ја. Када одем до ЦИО-а након састанка, не нудим листу од 10 ствари које треба поправити. Настојим да пронађем везе између онога што људи у компанији говоре и постојећих доказаних образаца. На крају, плави маркер сугерише могућа решења проблема.
(Ова илустрација се може погледати засебно )
Пример овог приступа је сада приказан горе. Почетком ове године радио сам са једном банком. Тамошњи људи из обезбеђења су били уверени да не би требало да долазе на преглед дизајна и захтева.
(Ова илустрација се може погледати засебно )
А онда смо разговарали са људима из других одељења и испоставило се да су пре отприлике 8 година програмери софтвера отпустили раднике обезбеђења јер су успоравали рад. А онда се то претворило у забрану, што се подразумевало. Иако у стварности није било забране.
Наш састанак је протекао на крајње конфузан начин: око три сата пет различитих тимова није могло да ми објасни шта се дешава између кодекса и скупштине. А ово би се чинило најједноставније. Већина ДевОпс консултаната унапред претпоставља да сви то већ знају.
Онда је особа задужена за ИТ управљање, која је ћутала четири сата, одједном оживела када смо дошли до његове теме, и заокупила нас веома дуго. На крају сам га питао шта мисли о састанку и никада нећу заборавити његов одговор. Рекао је: „Раније сам мислио да наша банка има само два начина за испоруку софтвера, али сада знам да их има пет, а нисам ни знао за три.
(Ова илустрација се може погледати засебно )
Последњи састанак у овој банци био је са тимом за инвестициони софтвер. Са њом се показало да је писање дијаграма маркером на листу папира боље него на табли, па чак и боље него на паметној табли.
Фотографије које видите су како је изгледала хотелска конференцијска сала четвртог дана нашег састанка. И користили смо ове шеме за тражење образаца, односно архетипова.
Дакле, постављам питања радницима, они записују одговоре маркерима од три боје (црна, црвена и плава). Анализирам њихове одговоре за архетипове. Хајде сада да разговарамо о свим архетиповима по реду.
1. Учините сав посао видљивим: Учините рад видљивим
Већина компанија са којима радим има веома висок проценат непознатог посла. На пример, ово је када један запослени дође другом и једноставно тражи да нешто уради. У великим организацијама може бити 60% непланираних послова. А до 40% радова није ни на који начин документовано. Да је у питању Боинг, никада се више у животу не бих укрцао на њихов авион. Ако је документовано само половина посла, онда се не зна да ли се овај посао ради како треба или не. Све друге методе се испостављају бескорисним - нема смисла покушавати било шта да аутоматизујете, јер познатих 50% може бити најкохерентнији и најјаснији део посла, чија аутоматизација неће дати сјајне резултате, а све најгоре ствари су у невидљивој половини. У недостатку документације, немогуће је пронаћи све врсте хакова и скривених послова, а не пронаћи уска грла, баш оне „бренте“ о којима сам већ говорио. Постоји дивна књига Доминике ДеГрандис . Она открива пет различитих "временских цурења" (лопови времена):
- Превише посла у процесу (ВИП)
- Непознате зависности
- Непланирани рад
- Сукобни приоритети
- Занемарени рад
Ово је веома вредна анализа и књига је одлична, али сви ови савети су бескорисни ако је видљиво само 50% података. Методе које је предложила Доминика могу се користити ако се постигне тачност изнад 90%. Говорим о ситуацијама у којима шеф задаје подређеном 15-минутни задатак, али му треба три дана; али шеф заправо не зна да овај подређени зависи од четири или пет других људи.
Пројекат Феникс је дивна прича о пројекту који је каснио три године. Једног од ликова због тога чека отказ, а он се сусреће са другим ликом који је представљен као нека врста Сократа. Он помаже да се схвати шта је тачно пошло по злу. Испоставило се да компанија има једног систем администратора, који се зове Брент, и сав посао некако иде преко њега. На једном од састанака, једног од потчињених питају: зашто сваки задатак од пола сата траје недељу дана? Одговор је веома поједностављен приказ теорије чекања и Литловог закона, а у овој презентацији се испоставља да при 90% попуњености сваки сат рада траје 9 сати. Сваки задатак треба послати још седам људи, тако да тај сат постане 63 сата, 7 пута 9. Поента коју желим да кажем је да, да бисте користили Литтлеов закон или било коју сложену теорију чекања, морате барем имати податке.
Дакле, када говорим о видљивости, не мислим да је све на екрану, већ да бар имате податке. Када то ураде, често се испостави да постоји јако велика количина непланираног посла који се некако шаље Бренту када за тим нема потребе. А Брент је сјајан момак, никада неће рећи не, али никоме не говори како ради свој посао.
Када је рад видљив, подаци се могу уредно класификовати (то Доминика ради на фотографији), применити апстракцију пет временских цурења и применити аутоматизацију.
2. Консолидовати системе управљања радом: управљање задацима
Архетипови о којима говорим су нека врста пирамиде. Ако је први урађен исправно, онда је други већ нека врста додатка. Многи од њих не раде за стартапове, треба их имати на уму за веће компаније као што је Фортуне 5000. Последња компанија у којој сам радио имала је 10 система за продају карата. Један тим је имао Ремеди, други је написао неку врсту сопственог система, трећи је користио Јира, а неки су се задовољили електронском поштом. Исти проблем настаје ако компанија има 30 различитих цевовода, али ја немам времена да расправљам о свим таквим случајевима.
Разговарам са људима како тачно настају карте, шта им се даље дешава и како их се заобилази. Најинтересантније је да људи на нашим састанцима говоре сасвим искрено. Питао сам колико људи ставља „мањи/без утицаја“ на карте којима би заправо требало дати „велики утицај“. Испоставило се да скоро сви то раде. Не упуштам се у денунцијације и покушавам на све могуће начине да не идентификујем људе. Када ми нешто искрено признају, не одајем ту особу. Али када скоро сви заобиђу систем, то значи да је сва безбедност у суштини излога. Стога се из података овог система не могу изводити закључци.
Да бисте решили проблем са улазницама, потребно је да изаберете један главни систем. Ако користите Јира, задржите га Јира. Ако постоји нека алтернатива, нека буде једина. Суштина је да тикете треба посматрати као још један корак у процесу развоја. Свака акција мора имати карту, која мора да тече кроз развојни радни ток. Улазнице се шаљу тиму, који их објављује на сторибоард-у и затим преузима одговорност за њих.
Ово се односи на сва одељења, укључујући инфраструктуру и операције. У овом случају, могуће је формирати бар неку уверљиву идеју о стању ствари. Када се овај процес успостави, одједном постаје лако идентификовати ко је одговоран за сваку апликацију. Јер сада добијамо не 50%, већ 98% нових услуга. Ако овај основни процес функционише, онда се прецизност побољшава у целом систему.
Сервицес пипелине
Ово се опет односи само на велике корпорације. Ако сте нова компанија у новој области, засучите рукаве и радите са својим Травис ЦИ или ЦирцлеЦИ. Када је реч о компанијама са листе Фортуне 5000, пример који се догодио у банци у којој сам радио. Гугл је дошао до њих и показали су им дијаграме старих ИБМ система. Момци из Гугла су збуњено питали – где је изворни код за ово? Али не постоји изворни код, чак ни ГУИ. Ово је реалност са којом велике организације морају да се суоче: 40 година стари банковни записи на древном мејнфрејму. Један од мојих клијената користи Кубернетес контејнере са Цирцуит Бреакер шаблонима, плус Цхаос Монкеи, све за апликацију КеиБанк. Али ови контејнери се на крају повезују са ЦОБОЛ апликацијом.
Момци из Гугла су били потпуно уверени да ће решити све проблеме мог клијента, а онда су почели да постављају питања: шта је ИБМ датапипе? Речено им је: ово је конектор. Са чиме се повезује? У систем Сперри. И шта је то? И тако даље. На први поглед изгледа: какав ДевОпс може бити? Али у ствари, могуће је. Постоје системи испоруке који вам омогућавају да предате ток посла тимовима за испоруку.
3. Теорија ограничења: Теорија ограничења
Пређимо на трећи архетип: институционално/„племенско“ знање. По правилу, у било којој организацији постоји неколико људи који све знају и управљају свиме. То су они који су најдуже у организацији и који знају сва решења.
Када се ово појави на дијаграму, ја посебно заокружим такве људе маркером: на пример, испоставило се да је одређени Лу присутан на свим састанцима. И јасно ми је: ово је локални Брент. Када ЦИО бира између мене у мајици и патикама и типа из ИБМ-а у оделу, ја сам изабран јер могу рећи директору ствари које други неће рећи и које директор можда не жели да чује . Кажем им да је уско грло у њиховом друштву неко по имену Фред и неко по имену Лу. Ово уско грло треба отклонити, од њих на овај или онај начин добити своја знања.
Да бих решио ову врсту проблема, могу, на пример, да предложим коришћење Слацк-а. Паметан директор ће питати – зашто? Типично, у таквим случајевима, ДевОпс консултанти одговарају: јер сви то раде. Ако је директор баш паметан, рећи ће: па шта. И ту се дијалог завршава. А мој одговор на ово је: зато што постоје четири уска грла у компанији, Фред, Лу, Сусие и Јане. Да би се институционализирало њихово знање, прво се мора увести Слацк. Све твоје викије су потпуне глупости јер нико не зна за њихово постојање. Ако је инжењерски тим укључен у фронт-енд и бацк-енд развој и сви морају да знају да могу да контактирају фронт-енд развојни тим или тим за инфраструктуру са питањима. Тада ће Лу или Фред вероватно имати времена да се придруже вики. А онда би у Слацк-у неко могао да пита зашто, рецимо, корак 5 не ради. А онда ће Лу или Фред исправити упутства на вики-ју. Ако успоставите овај процес, многе ствари ће доћи саме од себе.
Ово је моја главна поента: да бисте препоручили било коју високу технологију, прво морате да доведете у ред темељ за њих, а то се може урадити са управо описаним нискотехнолошким решењима. Ако почнете са високим технологијама и не објасните зашто су оне потребне, онда се, по правилу, ово не завршава добро. Један од наших клијената користи Азуре МЛ, веома јефтино и једноставно решење. На око 30% њихових питања одговарала је сама машина за самоучење. А ову ствар су написали оператери који нису били укључени у науку о подацима, статистику или математику. Ово је значајно. Трошкови таквог решења су минимални.
4. Хакови за сарадњу: Хакови за сарадњу
Четврти архетип је потреба за борбом против изолације. Већина људи то већ зна: изолација рађа непријатељство. Ако је свако одељење на свом спрату, а људи се ни на који начин не укрштају једни с другима, осим у лифту, онда врло лако настаје непријатељство међу њима. Али ако су, напротив, људи у истој просторији једни са другима, она одмах одлази. Када неко избаци неку општу оптужбу, на пример, такав и такав интерфејс никада не функционише, нема ништа лакше деконструисати такву оптужбу. Програмери који су писали интерфејс само треба да почну да постављају конкретна питања и ускоро ће постати јасно да је, на пример, корисник једноставно погрешно користио алат.
Постоји много начина да се превазиђе изолација. Једном су ме замолили да консултујем банку у Аустралији, али сам одбио да то урадим јер имам двоје деце и жену. Све што сам могао да урадим да им помогнем је да препоручим графичко приповедање. Ово је нешто што доказано функционише. Још један занимљив начин су састанци без кафе. У великој организацији, ово је одлична опција за ширење знања. Поред тога, можете водити интерне девопсдаје, хакатоне и тако даље.
5. Тренирање ката
Као што сам упозорио на самом почетку, нећу о томе данас. Ако сте заинтересовани, можете погледати .
Има и добар говор на ову тему од Мајка Ротера:
6. Тржишно оријентисана: тржишно оријентисана организација
Овде постоје различити проблеми. На пример, "И" људи, "Т" људи и "Е" људи. „Ја“ људи су они који раде само једну ствар. Обично постоје у организацијама са изолованим одељењима. "Т" је када је особа добра у једној ствари, али и у неким другим стварима. "Е" или чак "чешаљ" је када особа има много вештина.
Конвејев закон овде функционише (), што се у најједноставнијем облику може навести на следећи начин: ако на компајлеру раде три тима, онда ће резултат бити компајлер од три дела. Стога, ако постоји висок ниво изолације унутар организације, онда ће чак и Кубернетес, прекидач, АПИ проширивост и друге фенси ствари у овој организацији бити уређене на исти начин као и сама организација. Стриктно по Конвеју и у инат свим вама младим штреберима.
Решење овог проблема је описано много пута. Постоје, на пример, организациони архетипови које је описао Фернандо Фернандез. Та проблематична архитектура о којој сам управо говорио, са изолацијом, је архитектура оријентисана на функцију. Други тип је најгори, матрична архитектура, неред од друга два. Треће је оно што се види у већини стартапова, а велике компаније такође покушавају да парирају овом типу. То је тржишно оријентисана организација. Овде се оптимизујемо да бисмо постигли најбржи одговор на захтеве купаца. Ово се понекад назива равном организацијом.
Многи људи описују ову структуру на различите начине, свиђа ми се формулација изградити/покренути тимове, у Амазону то зову два пица тима. У овој структури, сви људи типа „И“ су груписани око једне услуге, и постепено се приближавају типу „Т“, а ако постоји прави менаџмент, могу постати и „Е“. Први контрааргумент овде је да таква структура има непотребне елементе. Зашто вам је потребан тестер у сваком одељењу ако можете имати посебно одељење тестера? На шта одговарам: додатни трошкови у овом случају су цена да цела организација у будућности постане тип „Е“. У овој структури, тестер постепено учи о мрежама, архитектури, дизајну итд. Као резултат тога, сваки учесник у организацији је у потпуности свестан свега што се дешава у организацији. Ако желите да знате како ова шема функционише у индустрији, прочитајте .
7. Ревизори Схифт-лево: ревизија у раној фази циклуса. Усклађеност са сигурносним правилима на екрану
Ово је када ваше радње не прођу тест мириса, да тако кажем. Људи који раде за вас нису глупи. Ако су, као у горњем примеру, свуда поставили мањи/без утицаја, то је трајало три године, а нико ништа није приметио, онда сви добро знају да систем не функционише. Или други пример – саветодавни одбор за промене, где извештаје треба подносити сваке, рецимо, среде. Тамо ради група људи (не баш добро плаћених, иначе) који би, у теорији, требало да знају како функционише систем у целини. И током протеклих пет година, вероватно сте приметили да су наши системи невероватно сложени. А пет-шест људи мора да донесе одлуку о промени коју нису направили и о којој ништа не знају.
Наравно, овај приступ не функционише. Морам да се отарасим таквих ствари јер ти људи не штите систем. Одлуку мора да донесе сам тим, јер тим мора да одговара за њу. У супротном, настаје парадоксална ситуација када менаџер који никада у животу није писао код каже програмеру колико времена треба да траје да напише код. Једна компанија са којом сам радио је имала 7 различитих одбора који су прегледали сваку промену, укључујући одбор за архитектуру, плочу производа итд. Чак је постојао и обавезни период чекања, иако ми је један службеник рекао да за десет година рада нико никада није одбио промену коју је извршила ова особа током овог обавезног рока.
Ревизоре треба позвати да нам се придруже, а не да их се отарасимо. Реците им да пишете непроменљиве бинарне контејнере који, ако прођу све тестове, остају непроменљиви заувек. Реците им да имате цевовод као код и објасните шта то значи. Покажите им следећу шему: непроменљиву бинарну датотеку само за читање у контејнеру која пролази све тестове рањивости; а онда не само да га нико не дира, него чак ни систем који креира цевовод, јер се и он ствара динамички. Имам клијенте, Цапитал Оне, који користе Ваулт да креирају нешто попут блоцкцхаина. Ревизор не мора да покаже „рецепте” од Цхефа, довољно је да покаже блокчејн из којег се јасно види шта се десило са Јира тикетом у производњи и ко је за то одговоран.
Према , који је Сонатипе креирао 2018. године, било је 2017 милијарди захтева за преузимање ОСС-а у 87. години.
Губици настали због рањивости су превисоки. Штавише, бројке које сада видите изнад не укључују опортунитетне трошкове. Шта је ДевСецОпс укратко? Одмах да кажем да ме не занима да причам о томе колико је ово име успешно. Поента је да пошто је ДевОпс био толико успешан, требало би да покушамо да додамо сигурност том цевоводу.
Пример овог низа:
Ово није препорука за одређене производе, иако ми се сви свиђају. Навео сам их као пример да покажем да ДевОпс, који је у почетку био заснован на организационој парадигми у индустрији, омогућава аутоматизацију сваке фазе рада на производу.
И нема разлога зашто не бисмо могли да заузмемо исти приступ безбедности.
Укупан
Као закључак, даћу неколико савета за ДевСецОпс. Морате укључити ревизоре у процес креирања ваших система и потрошити време на њихово образовање. Морате сарађивати са ревизорима. Затим, морате водити апсолутно немилосрдну борбу против лажних позитивних резултата. Чак и са најскупљим алатом за скенирање рањивости, можете створити изузетно лоше навике међу својим програмерима ако не знате који је ваш однос сигнал-шум. Програмери ће бити затрпани догађајима и једноставно ће их избрисати. Ако сте чули за причу о Екуифак-у, то се поприлично догодило тамо, где је највиши ниво упозорења игнорисан. Поред тога, рањивости треба да буду објашњене на начин да буде јасно како утичу на пословање. На пример, можете рећи да је ово иста рањивост као у Екуифак причи. Безбедносне рањивости треба третирати на исти начин као и друге софтверске проблеме, односно треба их укључити у целокупни ДевОпс процес. Са њима треба да радите преко Јира, Канбана итд. Програмери не би требало да мисле да ће то урадити неко други - напротив, сви би то требали да ураде. Коначно, морате потрошити енергију на обуку људи.
Корисни линкови
Ево неколико разговора са ДевОопс конференције који би вам могли бити корисни:
- Сергеј Бердников, Артјом Каличкин - Прича о успеху, или „Дев+ДевОпс+Опс“ (, )
- Барух Садогурски, Леонид Иголник - ДевОпс на скали: грчка трагедија у три чина (, )
- Александар Титов, Кирил Толкачев -
- Тимоти Листер -
Погледати у ДевОопс 2020 Москва — ту има и доста занимљивих ствари.
Извор: ввв.хабр.цом