Прашањето „како да се имплементира devops“ постои со години, но нема многу добри материјали. Понекогаш станувате жртва на реклами од не толку паметни консултанти кои треба да го продадат своето време, без разлика како. Понекогаш ова се нејасни, крајно општи зборови за тоа како бродовите на мегакорпорациите ги ораат пространствата на универзумот. Се поставува прашањето: што ни е важно ова? Почитуван автор, можете ли јасно да ги формулирате вашите идеи во список?
Сето ова произлегува од фактот дека не е акумулирано многу вистинска практика и разбирање на исходот од трансформациите на културата на компанијата. Промените во културата се долгорочни работи, чии резултати нема да се појават за една недела или еден месец. Ни треба некој доволно возрасен за да види како компаниите се граделе и пропаѓале низ годините.
Џон Вилис - еден од татковците на DevOps. Џон има децениско искуство со работа со огромен број компании. Неодамна, Џон почна да забележува специфични обрасци што се случуваат при работа со секој од нив. Користејќи ги овие архетипови, Џон ги води компаниите на вистинскиот пат на трансформацијата на DevOps. Прочитајте повеќе за овие архетипови во преводот на неговиот извештај од конференцијата DevOops 2018.
За говорникот:
Повеќе од 35 години во управувањето со ИТ, учествуваше во создавањето на претходникот на OpenCloud во Canonical, учествуваше во 10 стартапи, од кои два беа продадени на Dell и Docker. Во моментов тој е потпретседател на DevOps и дигитални практики во SJ Technologies.
Следна е приказната од гледна точка на Џон.
Јас се викам Џон Вилис и најлесно да ме најдете е на Твитер. . Го имам истиот псевдоним на Gmail и GitHub. А можете да најдете видео снимки од моите извештаи и презентации за нив.
Имам многу средби со директори на директори на различни големи компании. Тие често се жалат дека не разбираат што е тоа DevOps, а секој што се обидува да им објасни, зборува за нешто различно. Друга вообичаена поплака е дека DevOps не работи, иако се чини дека директорите прават сè како што им е објаснето. Станува збор за големи компании кои се стари повеќе од сто години. Откако разговарав со нив, дојдов до заклучок дека за многу проблеми не е најсоодветна високата технологија, туку релативно нискотехнолошките решенија. Со недели само разговарав со луѓе од различни оддели. Она што го гледате на првата слика во објавата е мојот последен проект, вака изгледаше собата после три дена работа.
Што е DevOps?
Навистина, ако прашате 10 различни луѓе, тие ќе дадат 10 различни одговори. Но, тука е интересното: сите десет од овие одговори ќе бидат точни. Тука нема погрешен одговор. Бев прилично длабоко во DevOps, околу 10 години, и бев првиот Американец на првиот DevOpsDay. Нема да кажам дека сум попаметен од сите вклучени во DevOps, но ретко кој има потрошено толку многу труд на тоа. Верувам дека DevOps се случува кога човечкиот капитал и технологијата се спојуваат. Често забораваме на човечката димензија, иако многу зборуваме за сите видови култури.
Сега имаме многу податоци, пет години академски истражувања, тестирање на теории на индустриски размери. Она што ни го кажуваат овие студии е дека ако комбинирате некои обрасци на однесување во организациската култура, можете да постигнете забрзување од 2000 пати. Ова забрзување се совпаѓа со подеднакво подобрување на стабилноста. Ова е квантитативно мерење на користа што може да ја донесе DevOps за секоја компанија. Пред неколку години разговарав за DevOps со извршниот директор на компанија од Fortune 5000. Кога се подготвував за презентацијата, бев многу нервозен бидејќи морав да го сумирам моето долгогодишно искуство во 5 минути.
На крајот го дадов следново Дефиниција на DevOps: Тоа е збир на практики и обрасци кои овозможуваат трансформација на човечкиот капитал во организациски капитал со високи перформанси. Пример е начинот на кој Toyota работи во последните 50 или 60 години.
(Во натамошниот текст, ваквите дијаграми се дадени не како референтен материјал, туку како илустрации. Нивната содржина ќе се разликува за секоја нова компанија. Сепак, сликата може да се гледа посебно и да се зголеми
Една од најуспешните вакви практики е вредност струја мапирање. За ова се напишани неколку добри книги, од кои најуспешни се на Карен Мартин. Но, во текот на изминатата година, дојдов до заклучок дека дури и овој пристап е премногу високо-технолошки. Сигурно има многу предности и јас го користев многу. Но, кога извршниот директор ќе ве праша зошто неговата компанија не може да се префрли на нови шини, прерано е да се зборува за мапирање на протокот на вредност. Има многу посуштински прашања на кои прво мора да се одговори.
Мислам дека грешката што ја прават многу мои колеги е тоа што тие едноставно ѝ даваат на компанијата водич од пет точки, а потоа се враќаат шест месеци подоцна и ќе видат што се случило. Дури и добра шема како мапирање на протокот на вредност има, да речеме, слепи точки. По стотици интервјуа со директори на различни компании, развив одредена шема која ни овозможува да го разложиме проблемот на неговите компоненти, а сега ќе разговараме за секоја од овие компоненти по редослед. Пред да применам какви било технолошки решенија, ја користам оваа шема, и како резултат на тоа, сите мои ѕидови се покриени со дијаграми. Неодамна работев со заеднички фонд и завршив со 100-150 такви шеми.
Лошата култура јаде добри пристапи за појадок
Главната идеја е следна: ниту една количина Lean, Agile, SAFE и DevOps нема да помогне ако самата култура на организацијата е лоша. Тоа е како нуркање до длабочина без опрема за нуркање или работа без рентген. Со други зборови, да ги парафразираме Дракер и Деминг: лошата организациска култура ќе го проголта секој добар систем без да се гуши во него.
За да го решите овој главен проблем, треба да ги преземете следниве чекори:
- Направете ја целата работа видлива: треба да ја направите целата работа видлива. Не во смисла дека мора нужно да се прикажува на некој екран, туку во смисла дека мора да биде набљудувано.
- Консолидирани системи за управување со работата: системите за управување треба да се консолидираат. Во проблемот со „племенското“ знаење и институционалното знаење, во 9 случаи од 10 тесно грло се луѓето. Во книгата проблемот беше со еден самец, Брент, кој предизвика проектот да задоцни три години. И секаде налетувам на овие „Бренти“. За да ги решам овие тесни грла, ги користам следните две ставки на нашата листа.
- Теорија на ограничувања Методологија: теорија на ограничувања.
- Хаки за соработка: хакови за соработка.
- Тојота Ката (): Нема да зборувам многу за Toyota Kata. Ако сте заинтересирани, на мојот github на речиси секоја од овие теми.
- Организација ориентирана кон пазарот: пазарно ориентирана организација.
- Смените лево ревизори: ревизија во раните фази на циклусот.
Почнувам да работам со организација многу едноставно: одам во компанијата и разговарам со вработените. Како што можете да видите, нема висока технологија. Се што ви треба е на што да пишувате. Собирам неколку тимови во една просторија и анализирам што ми кажуваат од перспектива на моите 7 архетипи. И тогаш самите им давам маркер и ги замолувам да запишат на табла сето она што досега гласно го кажале. Вообичаено на ваков тип на состаноци има еден човек кој запишува сè, а во најдобар случај може да запише 10% од дискусијата. Со мојот метод, оваа бројка може да се зголеми на околу 40%.
(Оваа илустрација може да се погледне одделно )
Мојот пристап се заснова на работата на Вилијам Шнајдер. ). Пристапот се заснова на идејата дека секоја организација може да се подели на четири квадрати. Оваа шема за мене обично е резултат на работа со оние стотици други шеми што се појавуваат кога се анализира една организација. Да претпоставиме дека имаме организација со високо ниво на контрола, но со ниска компетентност. Ова е крајно непожелна опција: кога сите се на линија, но никој не знае што да прави.
Нешто подобра опција е онаа со високо ниво на контрола и компетентност. Ако таква компанија е профитабилна, тогаш можеби не и треба DevOps. Најинтересно е да се работи со компанија која има високо ниво на контрола, ниска компетентност и соработка, но во исто време и високо ниво на култура (култивирање). Тоа значи дека компанијата има многу луѓе кои сакаат да работат таму и дека обртот на работната сила е низок.
(Оваа илустрација може да се погледне одделно )
Ми се чини дека методите со ригидни насоки завршуваат на патот кон постигнување на вистината. Особено во мапирањето на протокот на вредност, постојат многу правила во врска со тоа како треба да се структурираат информациите. Во раните фази на работа, за кои зборувам сега, никому не му требаат овие правила. Ако некое лице со маркер во рацете ја опишува реалната ситуација во компанијата на таблата, ова е најдобриот начин да се разбере состојбата на работите. Ваквите информации не стигнуваат до директорите. Во овој момент, глупаво е да се прекине личноста и да се каже дека неправилно нацртал некаква стрела. Во оваа фаза, подобро е да се користат едноставни правила, на пример: апстракцијата на повеќе нивоа може да се создаде едноставно со користење на повеќебојни маркери.
Повторувам, нема висока технологија. Црниот маркер ја прикажува објективната реалност за тоа како функционира сè. Со црвен маркер, луѓето означуваат што не им се допаѓа во моменталната состојба на работите. Важно е тие да го напишат ова, а не јас. Кога одам во ЦИО после состанок, не нудам список со 10 работи што треба да се поправат. Се стремам да најдам врски помеѓу она што го кажуваат луѓето во компанијата и постоечките докажани обрасци. Конечно, син маркер сугерира можни решенија за проблемот.
(Оваа илустрација може да се погледне одделно )
Пример за овој пристап сега е прикажан погоре. На почетокот на оваа година работев со една банка. Луѓето од обезбедувањето таму беа убедени дека не треба да доаѓаат на прегледи на дизајни и барања.
(Оваа илустрација може да се погледне одделно )
И тогаш разговаравме со луѓе од други оддели и се покажа дека пред околу 8 години, развивачите на софтвер отпуштија работници од обезбедувањето затоа што ја забавуваа работата. А потоа се претвори во забрана, која се зема здраво за готово. Иако во реалноста немаше забрана.
Нашиот состанок се одвиваше на крајно збунувачки начин: околу три часа, пет различни тимови не можеа да ми објаснат што се случува помеѓу кодот и собранието. И се чини дека ова е наједноставната работа. Повеќето консултанти на DevOps однапред претпоставуваат дека сите веќе го знаат ова.
Тогаш одговорниот за управување со ИТ, кој молчеше четири часа, наеднаш оживеа кога стигнавме до неговата тема и не окупираше многу долго. На крајот го прашав што мисли за средбата и никогаш нема да го заборавам неговиот одговор. Тој рече: „Порано мислев дека нашата банка има само два начини за испорака на софтвер, но сега знам дека има пет од нив, а јас не знаев ни за три“.
(Оваа илустрација може да се погледне одделно )
Последната средба во оваа банка беше со тимот за инвестициски софтвер. Со неа се покажа дека пишувањето дијаграми со маркер на лист хартија е подобро отколку на табла, па дури и подобро отколку на паметна табла.
Фотографиите што ги гледате се како изгледаше конференциската сала на хотелот на четвртиот ден од нашата средба. И ние ги користевме овие шеми за пребарување на обрасци, односно архетипови.
Така, на работниците им поставувам прашања, тие ги запишуваат одговорите со маркери од три бои (црна, црвена и сина). Ги анализирам нивните одговори за архетипови. Сега да разговараме за сите архетипови по ред.
1. Направете ја целата работа видлива: направете ја работата видлива
Повеќето компании со кои работам имаат многу висок процент на непозната работа. На пример, ова е кога еден вработен доаѓа кај друг и едноставно бара да направи нешто. Во големите организации, може да има 60% непланирана работа. И до 40% од работата не е документирана никако. Да беше Боинг, никогаш повеќе во животот не би се качил на нивниот авион. Ако е документирана само половина од работата, тогаш не се знае дали оваа работа се работи правилно или не. Сите други методи се покажаа бескорисни - нема смисла да се обидувате да автоматизирате нешто, бидејќи познатите 50% можеби се најкохерентниот и јасен дел од работата, чија автоматизација нема да даде одлични резултати, и сè најлошо. работите се во невидливата половина. Во отсуство на документација, невозможно е да се најдат секакви хакери и скриени работи, а не да се најдат тесни грла, токму оние „Бренти“ за кои веќе зборував. Има прекрасна книга од Доминика Де Грандис . Таа открива пет различни „временски протекувања“ (крадци на времето):
- Премногу работа во процес (WIP)
- Непознати зависности
- Непланирана работа
- Конфликтни приоритети
- Запоставена работа
Ова е многу вредна анализа и книгата е одлична, но сите овие совети се бескорисни ако се видливи само 50% од податоците. Методите предложени од Доминика може да се користат доколку се постигне точност од над 90%. Зборувам за ситуации кога шеф му дава на подредениот 15-минутна задача, но му требаат три дена; но газдата навистина не знае дека овој подреден е зависен од четири или пет други луѓе.
Проектот Феникс е прекрасна приказна за проект кој беше предоцна три години. Еден од ликовите поради тоа се соочува со отказ, а тој се среќава со друг лик кој е претставен како еден вид Сократ. Тој помага да се открие што точно тргнало наопаку. Излегува дека компанијата има еден системски администратор, чие име е Брент, и целата работа некако оди преку него. На еден од состаноците, еден од подредените се прашува: зошто секоја получасовна задача трае една недела? Одговорот е многу поедноставена презентација на теоријата на редици и законот на Литл, а во оваа презентација излегува дека при 90% зафатеност, секој час работа трае 9 часа. Секоја задача треба да се испрати до седум други луѓе, така што тој час ќе стане 63 часа, 7 пати по 9. Она што го велам е дека за да се користи Литловиот закон или која било сложена теорија на редици, барем треба да имаш податоци.
Значи, кога зборувам за видливост, не мислам дека се е на екранот, туку дека барем имаш податоци. Кога го прават тоа, често излегува дека има многу голема количина на непланирана работа што некако се испраќа до Брент кога нема потреба за тоа. И Брент е одлично момче, никогаш нема да каже не, но никому не кажува како си ја врши работата.
Кога работата е видлива, податоците може уредно да се класифицираат (тоа го прави Доминика на фотографијата), може да се примени апстракцијата на петте временски протекувања и да се примени автоматизација.
2. Консолидирај системи за управување со работата: Управување со задачи
Архетипите за кои зборувам се еден вид пирамида. Ако првото е направено правилно, тогаш вториот е веќе еден вид додаток. Многу од овие не работат за стартап, тие треба да се имаат на ум за поголеми компании како Fortune 5000. Последната компанија за која работев имаше 10 системи за издавање билети. Еден тим имаше Remedy, друг напиша некој свој сопствен систем, третиот користеше Jira, а некои се задоволуваа со е-пошта. Истиот проблем се јавува ако компанијата има 30 различни цевководи, но немам време да разговарам за сите такви случаи.
Разговарам со луѓето како точно се креираат билетите, што се случува со нив потоа и како се заобиколуваат. Најинтересно е што луѓето на нашите состаноци зборуваат доста искрено. Прашав колку луѓе ставаат „мало / без влијание“ на билетите на кои всушност треба да им се даде „големо влијание“. Се испостави дека скоро сите го прават тоа. Не се впуштам во осуда и се обидувам на секој можен начин да не идентификувам луѓе. Кога искрено ми признаат нешто, јас не ја давам личноста. Но, кога речиси сите го заобиколуваат системот, тоа значи дека целата безбедност во суштина е облекување на прозорецот. Затоа, не може да се извлечат заклучоци од податоците на овој систем.
За да го решите проблемот со билетите, треба да изберете еден главен систем. Ако користите Jira, чувајте го Jira. Ако има некаква алтернатива нека биде единствената. Во крајна линија е дека билетите треба да се гледаат како уште еден чекор во процесот на развој. Секоја акција мора да има билет, кој мора да тече низ работниот тек на развојот. Билетите се испраќаат до тимот, кој ги објавува на приказната и потоа презема одговорност за нив.
Ова се однесува на сите одделенија, вклучително и инфраструктура и операции. Во овој случај, можно е да се формира барем некоја веродостојна идеја за состојбата на работите. Откако ќе се воспостави овој процес, одеднаш станува лесно да се идентификува кој е одговорен за секоја апликација. Затоа што сега добиваме не 50%, туку 98% од новите услуги. Ако овој основен процес работи, тогаш точноста се подобрува низ целиот систем.
Цевковод за услуги
Ова повторно важи само за големите корпорации. Ако сте нова компанија во ново поле, засукајте ги ракавите и работете со вашиот Travis CI или CircleCI. Кога станува збор за Fortune 5000 компании, примерен случај што се случи во банката каде што работев. Гугл дошол кај нив и им биле прикажани дијаграми на стари IBM системи. Момците од Google збунето прашаа - каде е изворниот код за ова? Но, нема изворен код, дури ни GUI. Ова е реалноста со која треба да се справат големите организации: банкарски записи стари 40 години на антички мејнфрејм. Еден од моите клиенти користи Kubernetes контејнери со шеми на прекинувачот, плус Chaos Monkey, сите за апликацијата KeyBank. Но, овие контејнери на крајот се поврзуваат со апликацијата COBOL.
Момците од Google беа целосно уверени дека ќе ги решат сите проблеми на мојот клиент, а потоа почнаа да поставуваат прашања: што е IBM datapipe? Им се вели: ова е конектор. На што се поврзува? До системот Sperry. И што е тоа? И така натаму. На прв поглед се чини: каков вид DevOps може да има? Но, всушност, тоа е можно. Постојат системи за испорака кои ви дозволуваат да го предадете работниот тек на тимовите за испорака.
3. Теорија на ограничувања: Теорија на ограничувања
Да преминеме на третиот архетип: институционално/„племенско“ знаење. Како по правило, во секоја организација има неколку луѓе кои знаат сè и управуваат со сè. Тоа се оние кои се најдолго во организацијата и кои ги знаат сите решенија.
Кога ова ќе се појави на дијаграмот, јас конкретно ги заокружувам таквите луѓе со маркер: на пример, излегува дека одреден Лу е присутен на сите состаноци. И мене ми е јасно: ова е локалниот Брент. Кога ЦИО избира помеѓу мене во маица и патики и момчето од IBM во костум, јас сум избран затоа што можам да му кажам на директорот работи што другиот нема да ги каже и кои директорот можеби нема да сака да ги слушне. . Им велам дека тесно грло во нивната компанија е некој по име Фред и некој по име Лу. Ова тесно грло треба да се одврзе, од нив да се добие нивното знаење на овој или оној начин.
За да се реши овој вид на проблем, можам, на пример, да предложам користење на Slack. Паметниот режисер ќе праша - зошто? Вообичаено, во такви случаи, консултантите на DevOps одговараат: затоа што сите го прават тоа. Ако е навистина паметен директорот, ќе рече: па што. И тука завршува дијалогот. И мојот одговор на ова е: затоа што има четири тесни грла во компанијата, Фред, Лу, Сузи и Џејн. За да се институционализира нивното знаење, прво мора да се воведе Slack. Сите ваши вики се целосна глупост бидејќи никој не знае за нивното постоење. Ако инженерскиот тим е вклучен во развојот на предниот и заден дел и секој треба да знае дека може да го контактира тимот за развој на предниот дел или инфраструктурниот тим со прашања. Тогаш најверојатно Лу или Фред ќе имаат време да се приклучат на викито. И тогаш во Slack некој може да праша зошто, на пример, чекор 5 не функционира. А потоа Лу или Фред ќе ги поправат упатствата на викито. Ако го воспоставите овој процес, тогаш многу работи сами ќе си дојдат на свое место.
Ова е мојата главна поента: за да препорачате какви било високи технологии, прво мора да ја поставите основата за нив во ред, а тоа може да се направи со нискотехнолошките решенија што штотуку опишани. Ако започнете со високи технологии и не објасните зошто се потребни, тогаш, по правило, ова не завршува добро. Еден од нашите клиенти користи Azure ML, многу евтино и едноставно решение. Околу 30% од нивните прашања беа одговорени од самата машина за самоучење. И ова нешто е напишано од оператори кои не биле вклучени во науката за податоци, статистика или математика. Ова е значајно. Цената на таквото решение е минимална.
4. Хаки за соработка: Хаки за соработка
Четвртиот архетип е потребата за борба против изолацијата. Повеќето луѓе веќе го знаат ова: изолацијата раѓа непријателство. Ако секој оддел е на свој кат, а луѓето не се вкрстуваат едни со други на кој било начин, освен во лифтот, тогаш непријателството меѓу нив се појавува многу лесно. Но, ако, напротив, луѓето се во иста просторија едни со други, таа веднаш заминува. Кога некој ќе исфрли некое општо обвинување, на пример, таков и таков интерфејс никогаш не функционира, нема ништо полесно да се деконструира такво обвинение. Програмерите кои го напишаа интерфејсот треба само да почнат да поставуваат конкретни прашања, а наскоро ќе стане јасно дека, на пример, корисникот едноставно ја користел алатката погрешно.
Постојат многу начини да се надмине изолацијата. Еднаш ме замолија да се консултирам за банка во Австралија, но јас одбив да го направам тоа бидејќи имам две деца и сопруга. Сè што можев да направам за да им помогнам беше да препорачам графичко раскажување приказни. Ова е нешто што е докажано дека функционира. Друг интересен начин се состаноците со посно кафе. Во голема организација, ова е одлична опција за ширење на знаењето. Дополнително, можете да спроведувате интерни денови, хакатони и така натаму.
5. Тренерски ката
Како што предупредив на самиот почеток, нема да зборувам за ова денес. Ако сте заинтересирани, можете да погледнете .
Има и добар разговор на оваа тема од Мајк Ротер:
6. Пазарно ориентирано: пазарно ориентирана организација
Тука има различни проблеми. На пример, луѓе „јас“, луѓе „Т“ и луѓе „Е“. Луѓето „јас“ се оние кои прават само една работа. Обично тие постојат во организации со изолирани одделенија. „Т“ е кога човек е добар во една работа, но добар и во некои други работи. „Е“ или дури „чешел“ е кога човек има многу вештини.
Законот на Конвеј работи овде (), што во најпоедноставена форма може да се наведе на следниов начин: ако три тима работат на компајлерот, тогаш резултатот ќе биде компајлер од три дела. Затоа, ако постои високо ниво на изолација во една организација, тогаш дури и Kubernetes, прекинувачот на колото, проширливоста на API и други фенси работи во оваа организација ќе бидат подредени на ист начин како и самата организација. Строго според Конвеј и за инает сите вие млади гикови.
Решението за овој проблем е опишано многу пати. Постојат, на пример, организациски архетипови опишани од Фернандо Фернандез. Таа проблематична архитектура за која штотуку зборував, со изолација, е функционално ориентирана архитектура. Вториот тип е најлошата, матрична архитектура, хаос од другите две. Третото е она што се гледа кај повеќето стартапи, а големите компании исто така се обидуваат да се поклопат со овој тип. Тоа е пазарно ориентирана организација. Овде ние се оптимизираме за да постигнеме најбрз одговор на барањата на клиентите. Ова понекогаш се нарекува рамна организација.
Многу луѓе ја опишуваат оваа структура на различни начини, ми се допаѓа формулацијата изгради/води тимови, во Амазон го викаат два тима за пица. Во оваа структура, сите луѓе од типот „I“ се групирани околу една услуга, и постепено тие се приближуваат до типот „Т“ и ако се воспостави вистинското раководство, тие можат дури и да станат „Е“. Првиот контрааргумент овде е дека таквата структура содржи непотребни елементи. Зошто ви е потребен тестер во секој оддел ако можете да имате посебен оддел за тестери? На што одговарам: дополнителните трошоци во овој случај се цената за целата организација да стане тип „Е“ во иднина. Во оваа структура, тестерот постепено учи за мрежи, архитектура, дизајн итн. Како резултат на тоа, секој учесник во организацијата е целосно свесен за сè што се случува во организацијата. Ако сакате да знаете како функционира оваа шема во индустријата, прочитајте .
7. Сменети леви ревизори: ревизија на почетокот на циклусот. Усогласеност со безбедносните правила на екранот
Ова е кога вашите постапки не го поминуваат тестот за мирис, така да се каже. Луѓето кои работат за вас не се глупави. Ако, како во примерот погоре, секаде поставиле мало/нема влијание, ова траело три години, а никој ништо не забележал, тогаш сите добро знаат дека системот не работи. Или друг пример - советодавен одбор за промени, каде што треба да се поднесуваат извештаи секоја, да речеме, среда. Таму работи група луѓе (патем не многу добро платени) кои теоретски треба да знаат како функционира системот во целина. И во текот на изминатите пет години, веројатно сте забележале дека нашите системи се неверојатно сложени. А пет-шест луѓе треба да донесат одлука за промена што не ја направиле и за која ништо не знаат.
Се разбира, овој пристап не функционира. Морам да се ослободам од такви работи бидејќи овие луѓе не го штитат системот. Одлуката мора да ја донесе самиот тим, бидејќи тимот мора да биде одговорен за тоа. Инаку, парадоксална ситуација се јавува кога менаџер кој никогаш не напишал код во својот живот му кажува на програмерот колку време треба да потрае за да се напише код. Една компанија со која работев имаше 7 различни табли кои ја разгледуваа секоја промена, вклучувајќи табла за архитектура, табла за производи итн. Имаше дури и задолжителен период на чекање, иако една вработена ми кажа дека за десет години работа никој никогаш не одбил промена направена од оваа личност во овој задолжителен период.
Ревизорите треба да бидат поканети да ни се придружат, а не да се ослободат од нив. Кажете им дека пишувате непроменливи бинарни контејнери кои, доколку ги поминат сите тестови, остануваат непроменливи засекогаш. Кажете им дека имате шифра како код и објаснете што значи тоа. Покажете им ја следнава шема: непроменлив бинарен само за читање во контејнер што ги поминува сите тестови за ранливост; а потоа не само што никој не го допира, тие не го ни допираат системот што го создава гасоводот, бидејќи тој исто така се создава динамично. Имам клиенти, Capital One, кои користат Vault за да создадат нешто како блокчејн. Ревизорот не треба да покажува „рецепти“ од готвачот, доволно е да го прикаже блокчејнот, од кој е јасно што се случило со билетот Jira во производството и кој е одговорен за тоа.
Според , создадена во 2018 година од Sonatype, имаше 2017 милијарди барања за преземање OSS во 87 година.
Загубите настанати поради ранливости се огромни. Покрај тоа, бројките што сега ги гледате погоре не ги вклучуваат опортунитетните трошоци. Што е DevSecOps накратко? Веднаш да кажам дека не ме интересира да зборувам колку е успешно ова име. Поентата е дека бидејќи DevOps беше толку успешен, треба да се обидеме да додадеме безбедност на тој гасовод.
Пример за оваа низа:
Ова не е препорака за конкретни производи, иако сите ми се допаѓаат. Ги наведов како пример за да покажам дека DevOps, кој првично беше заснован на организациската парадигма во индустријата, ви овозможува да ја автоматизирате секоја фаза од работата на производот.
И нема причина зошто не би можеле да го преземеме истиот пристап кон безбедноста.
Вкупно
Како заклучок, ќе дадам неколку совети за DevSecOps. Треба да вклучите ревизори во процесот на креирање на вашите системи и да потрошите време за нивно едуцирање. Треба да соработувате со ревизори. Следно, треба да водите апсолутно безмилосна борба против лажни позитиви. Дури и со најскапата алатка за скенирање на ранливости, може да завршите со создавање екстремно лоши навики меѓу вашите програмери ако не знаете каков е вашиот сооднос сигнал-шум. Програмерите ќе бидат преоптоварени со настани и едноставно ќе ги избришат. Ако сте слушнале за приказната за Equifax, тоа е речиси она што се случи таму, каде што највисокото ниво на тревога беше игнорирано. Дополнително, ранливостите треба да се објаснат на начин што ќе биде јасно како тие влијаат на бизнисот. На пример, може да се каже дека ова е истата ранливост како во приказната за Equifax. Безбедносните пропусти треба да се третираат исто како и другите софтверски проблеми, односно да бидат вклучени во целокупниот процес на DevOps. Треба да работите со нив преку Jira, Kanban итн. Програмерите не треба да мислат дека некој друг ќе го направи ова - напротив, секој треба да го прави ова. Конечно, треба да потрошите енергија на обука на луѓе.
Корисни линкови
Еве неколку разговори од конференцијата DevOops кои можеби ќе ви бидат корисни:
- Сергеј Бердников, Артјом Каличкин - Успешна приказна или „Dev+DevOps+Ops“ (, )
- Барух Садогурски, Леонид Иголник - DevOps на скала: грчка трагедија во три чина (, )
- Александар Титов, Кирил Толкачев -
- Тимоти Листер -
Погледни во DevOops 2020 Москва — Таму има и многу интересни работи.
Извор: www.habr.com