Седем архетипа на трансформация, базирани на принципите на DevOps

Въпросът „как да внедрим devops“ стои от години, но няма много добри материали. Понякога ставате жертва на реклами от не толкова умни консултанти, които трябва да продадат времето си, независимо как. Понякога това са неясни, изключително общи думи за това как корабите на мегакорпорациите плуват в просторите на Вселената. Възниква въпросът какво ни засяга това? Уважаеми авторе, можете ли ясно да формулирате идеите си в списък?

Всичко това произтича от факта, че не е натрупана много реална практика и разбиране за резултата от трансформациите на културата на компанията. Промените в културата са дългосрочни неща, чиито резултати няма да се появят след седмица или месец. Имаме нужда от някой достатъчно възрастен, който да е видял как компаниите са били изградени и провалени през годините.

Джон Уилис - един от бащите на DevOps. Джон има десетилетия опит в работата с огромен брой компании. Напоследък Джон започна да забелязва специфични модели, които се случват при работа с всеки от тях. Използвайки тези архетипи, Джон насочва компаниите по истинския път на трансформацията на DevOps. Прочетете повече за тези архетипи в превода на неговия доклад от конференцията DevOops 2018.

За говорителя:

Повече от 35 години в ИТ управлението, участва в създаването на предшественика на OpenCloud в Canonical, участва в 10 стартиращи компании, два от които бяха продадени на Dell и Docker. В момента той е вицепрезидент на DevOps и цифрови практики в SJ Technologies.

Следва историята от гледната точка на Джон.

Казвам се Джон Уилис и най-лесното място да ме намерите е в Twitter, @botchagalupe. Имам същия псевдоним в 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 няма да помогнат, ако самата култура на организацията е лоша. Това е като да се гмуркате на дълбочина без водолазна екипировка или да работите без рентген. С други думи, перифразирайки Дракър и Деминг: лошата организационна култура ще погълне всяка добра система, без да я задуши.

За да разрешите този основен проблем, трябва да предприемете следните стъпки:

1. Направете цялата работа видима: трябва да направите цялата работа видима. Не в смисъл, че непременно трябва да се показва на някакъв екран, а в смисъл, че трябва да може да се наблюдава.
2. Консолидирани системи за управление на работата: системите за управление трябва да бъдат консолидирани. В проблема за „племенното” знание и институционалното познание в 9 от 10 случая тясното място са хората. В книгата "Проект Феникс" проблемът беше с един-единствен човек, Брент, който причини три години изоставане на проекта от графика. И се сблъсквам с тези „Брент“ навсякъде. За да разреша тези затруднения, използвам следващите два елемента от нашия списък.
3. Методология на теорията на ограниченията: теория на ограниченията.
4. Хакове за сътрудничество: хакове за сътрудничество.
5. Тойота Ката (Треньорска ката): Няма да говоря много за Toyota Kata. При интерес в моя github има презентации по почти всяка една от тези теми.
6. Пазарно ориентирана организация: пазарно ориентирана организация.
7. Shift-left одитори: одит в ранните етапи на цикъла.

Започвам работа с организация много просто: отивам в компанията и говоря със служителите. Както можете да видите, няма високи технологии. Всичко, от което се нуждаете, е нещо, върху което да пишете. Събирам няколко екипа в една стая и анализирам какво ми казват от гледна точка на моите 7 архетипа. След това им давам маркер и ги карам да запишат на дъската всичко, което са казали на глас досега. Обикновено при този тип срещи има един човек, който записва всичко и в най-добрия случай той може да запише 10% от дискусията. С моя метод тази цифра може да бъде увеличена до около 40%.

(Тази илюстрация може да се види отделно виж връзката)

Моят подход се основава на работата на Уилям Шнайдер. Алтернативата за реинженеринг). Подходът се основава на идеята, че всяка организация може да бъде разделена на четири квадрата. Тази схема за мен обикновено е резултат от работата с онези стотици други схеми, които възникват при анализиране на една организация. Да предположим, че имаме организация с високо ниво на контрол, но с ниска компетентност. Това е крайно нежелан вариант: когато всички се придържат към линията, но никой не знае какво да прави.

Малко по-добър вариант е този с високо ниво както на контрол, така и на компетентност. Ако такава компания е печеливша, тогава може би няма нужда от DevOps. Най-интересно е да се работи с компания, която има високо ниво на контрол, ниска компетентност и сътрудничество, но в същото време високо ниво на култура (култивиране). Това означава, че във фирмата има много хора, които обичат да работят там и текучеството на работна ръка е ниско.

(Тази илюстрация може да се види отделно виж връзката)

Струва ми се, че методите с твърди указания в крайна сметка пречат на пътя към постигането на истината. По-специално при картографирането на потока от стойност има много правила относно това как информацията трябва да бъде структурирана. В ранните етапи на работа, за които говоря сега, никой не се нуждае от тези правила. Ако човек с маркер в ръцете си описва реалната ситуация в компанията на дъската, това е най-добрият начин да разберете състоянието на нещата. Такава информация не достига до директорите. В този момент е глупаво да прекъснеш човека и да кажеш, че е нарисувал някаква стрелка неправилно. На този етап е по-добре да използвате прости правила, например: многостепенна абстракция може да бъде създадена просто с помощта на многоцветни маркери.

Повтарям, никакви високи технологии. Черният маркер изобразява обективната реалност на това как работи всичко. С червен маркер хората отбелязват какво не им харесва в текущото състояние на нещата. Важно е те да пишат това, а не аз. Когато отида при CIO след среща, не предлагам списък с 10 неща, които трябва да бъдат коригирани. Стремя се да намеря връзки между това, което казват хората в компанията, и съществуващите доказани модели. Накрая син маркер предлага възможни решения на проблема.

(Тази илюстрация може да се види отделно виж връзката)

Пример за този подход е изобразен по-горе. В началото на тази година работих с една банка. Хората от сигурността там бяха убедени, че не трябва да идват за прегледи на проекти и изисквания.

(Тази илюстрация може да се види отделно виж връзката)

И тогава говорихме с хора от други отдели и се оказа, че преди около 8 години разработчиците на софтуер са уволнявали служители по сигурността, защото забавят работата. И тогава се превърна в забрана, която се приемаше за даденост. Въпреки че в действителност нямаше забрана.

Срещата ни протече по изключително объркващ начин: около три часа пет различни екипа не можаха да ми обяснят какво се случва между кода и асемблирането. И това изглежда най-простото нещо. Повечето консултанти на DevOps предполагат предварително, че всички вече знаят това.

Тогава човекът, отговарящ за ИТ управлението, който беше мълчалив четири часа, изведнъж се оживи, когато стигнахме до неговата тема, и ни занимаваше много дълго време. Накрая го попитах какво мисли за срещата и никога няма да забравя отговора му. Той каза: „Мислех, че нашата банка има само два начина за доставка на софтуер, но сега знам, че има пет от тях, а дори не знаех за три.“

(Тази илюстрация може да се види отделно виж връзката)

Последната среща в тази банка беше с екипа по инвестиционен софтуер. Именно с нея се оказа, че писането на диаграми с маркер върху лист е по-добро от това на дъска и дори по-добро от смарт дъска.

Снимките, които виждате, показват как изглеждаше конферентната зала на хотела на четвъртия ден от нашата среща. И използвахме тези схеми, за да търсим модели, тоест архетипи.

И така, задавам въпроси на работниците, те записват отговорите с маркери от три цвята (черен, червен и син). Анализирам техните отговори за архетипи. Сега нека обсъдим всички архетипи по ред.

1. Направете цялата работа видима: Направете работата видима

Повечето компании, с които работя, имат много висок процент непозната работа. Например, това е, когато един служител идва при друг и просто го моли да направи нещо. В големите организации може да има 60% непланирана работа. И до 40% от работата не е документирана по никакъв начин. Ако беше Боинг, никога повече в живота си нямаше да се кача на техния самолет. Ако само половината от работата е документирана, тогава не се знае дали тази работа се извършва правилно или не. Всички други методи се оказват безполезни - няма смисъл да се опитваме да автоматизираме каквото и да било, защото известните 50% може да са най-последователната и ясна част от работата, чиято автоматизация няма да даде големи резултати и всичко най-лошо нещата са в невидимата половина. При липса на документация е невъзможно да се намерят всякакви хакове и скрита работа, да не се намерят тесни места, тези същите „Brents“, за които вече говорих. Има една прекрасна книга от Доминика Де Грандис „Да направим работата видима“. Тя разкрива пет различни "изтичане на време" (крадци на време):

• Твърде много работа в процес (WIP)
• Неизвестни зависимости
• Непланирана работа
• Конфликтни приоритети
• Занемарена работа

Това е много ценен анализ и книгата е страхотна, но всички тези съвети са безполезни, ако само 50% от данните са видими. Методите, предложени от Dominica, могат да се използват, ако се постигне точност над 90%. Говоря за ситуации, в които шеф дава на подчинен 15-минутна задача, но тя му отнема три дни; но шефът всъщност не знае, че този подчинен е зависим от още четирима или петима души.

Проектът Феникс е прекрасна история за проект, който е закъснял с три години. Един от героите е изправен пред уволнение заради това и той се среща с друг герой, който е представен като своеобразен Сократ. Той помага да се разбере какво точно се е объркало. Оказва се, че компанията има един системен администратор, който се казва Брент и цялата работа по някакъв начин минава през него. На една от срещите един от подчинените е попитан: защо всяка половинчасова задача отнема седмица? Отговорът е много опростено представяне на теорията на опашките и закона на Литъл и в това представяне се оказва, че при 90% заетост всеки час работа отнема 9 часа. Всяка задача трябва да бъде изпратена на седем други души, така че този час става 63 часа, 7 пъти по 9. Това, което казвам е, че за да използвате закона на Литъл или която и да е сложна теория за опашката, трябва поне да имате данни.

Така че, когато говоря за видимост, нямам предвид, че всичко е на екрана, а че поне имате данни. Когато го направят, често се оказва, че има много голямо количество непланирана работа, която по някакъв начин се изпраща на Brent, когато няма нужда от нея. А Брент е страхотен човек, той никога няма да каже „не“, но не казва на никого как си върши работата.

Когато работата е видима, данните могат да бъдат спретнато класифицирани (това прави Доминика на снимката), може да се приложи абстракцията на петте изтичания на време и може да се приложи автоматизация.

2. Консолидирайте системи за управление на работата: Управление на задачи

Архетипите, за които говоря, са вид пирамида. Ако първият е направен правилно, тогава вторият вече е вид добавка. Много от тях не работят за стартиращи фирми, трябва да се имат предвид за по-големи компании като Fortune 5000. Последната компания, за която работих, имаше 10 системи за билети. Един екип имаше Remedy, друг написа някаква своя собствена система, трети използва Jira, а някои се задоволиха с имейл. Същият проблем възниква, ако компанията има 30 различни тръбопровода, но нямам време да обсъждам всички такива случаи.

Обсъждам с хората как точно се създават тикетите, какво се случва след това с тях и как се заобикалят. Най-интересното е, че хората на нашите срещи говорят съвсем искрено. Попитах колко хора поставят „незначително/без въздействие“ върху билети, на които всъщност трябва да се даде „голямо въздействие“. Оказа се, че почти всички правят това. Не се занимавам с доноси и се опитвам по всякакъв начин да не идентифицирам хората. Когато искрено ми признаят нещо, не го издавам. Но когато почти всички заобикалят системата, това означава, че цялата сигурност е по същество оформяне на витрини. Следователно не могат да се правят заключения от данните на тази система.

За да разрешите проблема с билетите, трябва да изберете една основна система. Ако използвате Jira, запазете го Jira. Ако има алтернатива, нека е единствената. Основното е, че билетите трябва да се разглеждат като още една стъпка в процеса на разработка. Всяко действие трябва да има билет, който трябва да преминава през работния процес на разработка. Билетите се изпращат на екипа, който ги публикува в сценария и след това поема отговорност за тях.

Това се отнася за всички отдели, включително инфраструктурата и операциите. В този случай е възможно да се формира поне някаква правдоподобна представа за състоянието на нещата. След като този процес бъде установен, изведнъж става лесно да се идентифицира кой е отговорен за всяко приложение. Защото сега получаваме не 50%, а 98% нови услуги. Ако този основен процес работи, тогава точността се подобрява в цялата система.

Тръбопровод за услуги

Това отново се отнася само за големите корпорации. Ако сте нова компания в нова област, запретнете ръкави и работете с вашия Travis CI или CircleCI. Що се отнася до компаниите от Fortune 5000, примерен случай се случи в банката, в която работех. Google дойде при тях и им бяха показани диаграми на стари IBM системи. Момчетата от Google попитаха объркано - къде е изходният код за това? Но няма изходен код, дори GUI. Това е реалността, с която големите организации трябва да се справят: 40-годишни банкови записи на древен мейнфрейм. Един от моите клиенти използва контейнери на Kubernetes с модели на прекъсвач, плюс Chaos Monkey, всичко това за приложението KeyBank. Но тези контейнери в крайна сметка се свързват с COBOL приложение.

Момчетата от Google бяха напълно уверени, че ще решат всички проблеми на моя клиент, а след това започнаха да задават въпроси: какво е IBM datapipe? Казват им: това е конектор. С какво се свързва? Към системата на Спери. И какво е това? И така нататък. На пръв поглед изглежда: какъв вид DevOps може да има? Но всъщност е възможно. Има системи за доставка, които ви позволяват да предадете работния процес на екипите за доставка.

3. Теория на ограниченията: Теория на ограниченията

Да преминем към третия архетип: институционално/"племенно" знание. По правило във всяка организация има няколко души, които знаят всичко и управляват всичко. Това са тези, които са били в организацията най-дълго и които знаят всички заобиколни решения.

Когато това се появи на диаграмата, аз специално ограждам такива хора с маркер: например се оказва, че определен Лу присъства на всички срещи. И ми е ясно: това е местен брент. Когато CIO избира между мен с тениска и маратонки и момчето от IBM с костюм, аз съм избран, защото мога да кажа на директора неща, които другият човек няма да каже и които директорът може да не иска да чуе . Казвам им, че тясното място в тяхната компания са някой на име Фред и някой на име Лу. Това тясно място трябва да се развърже, знанията им трябва да бъдат получени от тях по един или друг начин.

За разрешаване на този вид проблем мога например да предложа използването на Slack. Един умен директор ще попита - защо? Обикновено в такива случаи консултантите на DevOps отговарят: защото всички го правят. Ако директорът е наистина умен, ще каже: какво от това. И тук диалогът свършва. И моят отговор на това е: защото има четири тесни места в компанията, Фред, Лу, Сузи и Джейн. За да се институционализира тяхното знание, първо трябва да се въведе Slack. Всичките ви уикита са пълни глупости, защото никой не знае за съществуването им. Ако инженерният екип участва в разработката на предния и задния край и всички трябва да знаят, че могат да се свържат с екипа за разработка на предния край или с екипа за инфраструктура с въпроси. Тогава вероятно Лу или Фред ще имат време да се присъединят към уикито. И тогава в Slack някой може да попита защо, да речем, не работи стъпка 5. И тогава Лу или Фред ще коригират инструкциите в wiki. Ако установите този процес, тогава много неща ще си дойдат на мястото от само себе си.

Това е основната ми гледна точка: за да препоръчате някакви високи технологии, първо трябва да поставите основата за тях, а това може да стане с току-що описаните нискотехнологични решения. Ако започнете с високи технологии и не обясните защо са необходими, тогава, като правило, това не свършва добре. Един от нашите клиенти използва Azure ML, много евтино и просто решение. На около 30% от въпросите им отговори самата самообучаваща се машина. И това нещо е написано от оператори, които не са се занимавали с наука за данни, статистика или математика. Това е много важно. Цената на такова решение е минимална.

4. Хакове за сътрудничество: Хакове за сътрудничество

Четвъртият архетип е необходимостта от борба с изолацията. Повечето хора вече знаят това: изолацията поражда враждебност. Ако всеки отдел е на свой собствен етаж и хората не се пресичат помежду си по никакъв начин, освен в асансьора, тогава враждебността между тях възниква много лесно. Но ако, напротив, хората са в една стая един с друг, тя веднага си тръгва. Когато някой хвърли някакво общо обвинение, например такъв и такъв интерфейс никога не работи, няма нищо по-лесно да се деконструира такова обвинение. Програмистите, които са написали интерфейса, просто трябва да започнат да задават конкретни въпроси и скоро ще стане ясно, че например потребителят просто е използвал инструмента неправилно.

Има много начини за преодоляване на изолацията. Веднъж ме помолиха да се консултирам за банка в Австралия, но аз отказах да го направя, защото имам две деца и жена. Всичко, което можех да направя, за да им помогна, беше да препоръчам графично разказване на истории. Това е нещо, което доказано работи. Друг интересен начин са постните срещи на кафе. В голяма организация това е отличен вариант за разпространение на знания. Освен това можете да провеждате вътрешни devopsdays, хакатони и т.н.

5. Треньорско ката

Както предупредих в самото начало, днес няма да говоря за това. При интерес може да разгледате някои от моите презентации.

Има и добра беседа по тази тема от Майк Ротер:

6. Пазарно ориентирана: пазарно ориентирана организация

Тук има различни проблеми. Например хора „I“, хора „T“ и хора „E“. „Аз“ хората са тези, които правят само едно нещо. Обикновено те съществуват в организации с изолирани отдели. „Т“ е, когато човек е добър в едно нещо, но е добър и в някои други неща. „Е“ или дори „гребен“ е, когато човек има много умения.

Законът на Конуей работи тук (Законът на Конуей), което в най-опростен вид може да се изрази по следния начин: ако три екипа работят върху компилатора, тогава резултатът ще бъде компилатор от три части. Следователно, ако има високо ниво на изолация в рамките на една организация, тогава дори Kubernetes, прекъсвачът на веригата, разширяемостта на API и други фантастични неща в тази организация ще бъдат подредени по същия начин като самата организация. Строго според Конуей и напук на всички вас, млади маниаци.

Решението на този проблем е описано многократно. Има например организационни архетипи, описани от Фернандо Фернандес. Тази проблемна архитектура, за която току-що говорих, с изолация, е функционално ориентирана архитектура. Вторият тип е най-лошият, матрична архитектура, бъркотия от другите два. Третото е това, което се вижда в повечето стартиращи компании, а големите компании също се опитват да съответстват на този тип. Това е пазарно ориентирана организация. Тук оптимизираме, за да постигнем най-бърз отговор на клиентските заявки. Това понякога се нарича плоска организация.

Много хора описват тази структура по различни начини, харесва ми формулировката изграждане/ръководство на екипи, в Amazon го наричат два отбора за пица. В тази структура всички хора от тип „I” са групирани около една служба и постепенно се доближават до тип „T”, а при правилен мениджмънт могат дори да станат „E”. Първият контрааргумент тук е, че такава структура има ненужни елементи. Защо имате нужда от тестер във всеки отдел, ако можете да имате специален отдел от тестери? На което отговарям: допълнителните разходи в този случай са цената цялата организация да стане тип „Е” в бъдеще. В тази структура тестерът постепенно научава за мрежи, архитектура, дизайн и т.н. В резултат на това всеки участник в организацията е напълно наясно с всичко, което се случва в организацията. Ако искате да знаете как работи тази схема в индустрията, прочетете Майк Ротер, Тойота Ката.

7. Shift-left одитори: одит в началото на цикъла. Спазване на правилата за безопасност на дисплея

Това е, когато вашите действия не преминават теста за миризма, така да се каже. Хората, които работят за вас, не са глупави. Ако, както в примера по-горе, зададат незначително/без въздействие навсякъде, това продължи три години и никой не забеляза нищо, тогава всички знаят много добре, че системата не работи. Или друг пример - консултативен съвет за промяна, където докладите трябва да се подават всяка, да речем, сряда. Там работят група хора (между другото не много добре платени), които на теория трябва да знаят как работи системата като цяло. И през последните пет години вероятно сте забелязали, че нашите системи са невероятно сложни. И пет-шест души трябва да вземат решение за промяна, която не са правили и за която не знаят нищо.

Разбира се, този подход не работи. Трябва да се отърва от такива неща, защото тези хора не защитават системата. Решението трябва да бъде взето от самия отбор, защото екипът трябва да носи отговорност за него. В противен случай възниква парадоксална ситуация, когато мениджър, който никога през живота си не е писал код, казва на програмиста колко време трябва да отнеме, за да напише код. Една компания, с която работих, имаше 7 различни борда, които преглеждаха всяка промяна, включително архитектурен борд, продуктов борд и т.н. Имаше дори задължителен период на изчакване, въпреки че един служител ми каза, че за десет години работа никой никога не е отхвърлял промяна, направена от този човек през този задължителен период.

Одиторите трябва да бъдат поканени да се присъединят към нас, а не да се отърват от тях. Кажете им, че пишете неизменни двоични контейнери, които, ако преминат всички тестове, остават неизменни завинаги. Кажете им, че имате тръбопровод като код и обяснете какво означава това. Покажете им следната схема: неизменен двоичен файл само за четене в контейнер, който преминава всички тестове за уязвимост; и след това не само че никой не го докосва, те дори не докосват системата, която създава тръбопровода, тъй като той също се създава динамично. Имам клиенти, Capital One, които използват Vault, за да създадат нещо като блокчейн. Одиторът не трябва да показва „рецепти“ от главния готвач; достатъчно е да покаже блокчейна, от който става ясно какво се е случило с билета Jira в производството и кой е отговорен за него.

Според доклад, създаден през 2018 г. от Sonatype, имаше 2017 милиарда OSS заявки за изтегляне през 87 г.

Загубите, понесени поради уязвимости, са непосилни. Освен това цифрите, които сега виждате по-горе, не включват алтернативни разходи. Какво е DevSecOps накратко? Веднага да кажа, че не ми е интересно да говоря колко успешно е това име. Въпросът е, че тъй като DevOps е толкова успешен, трябва да се опитаме да добавим сигурност към този тръбопровод.

Пример за тази последователност:


Това не е препоръка за конкретни продукти, въпреки че харесвам всички. Цитирах ги като пример, за да покажа, че DevOps, който първоначално се основава на организационната парадигма в индустрията, ви позволява да автоматизирате всеки етап от работата по продукт.

И няма причина да не възприемем същия подход към сигурността.

Общо

Като заключение ще дам няколко съвета за DevSecOps. Трябва да включите одитори в процеса на създаване на вашите системи и да отделите време за тяхното обучение. Трябва да си сътрудничите с одитори. След това трябва да водите абсолютно безмилостна борба срещу фалшивите положителни резултати. Дори и с най-скъпия инструмент за сканиране на уязвимости, можете да създадете изключително лоши навици сред вашите разработчици, ако не знаете какво е вашето съотношение сигнал/шум. Разработчиците ще бъдат затрупани със събития и просто ще ги изтрият. Ако сте чули за историята с Equifax, това е почти това, което се е случило там, където най-високото ниво на предупреждение е пренебрегнато. Освен това уязвимостите трябва да бъдат обяснени по начин, който да изясни как влияят върху бизнеса. Например, можете да кажете, че това е същата уязвимост като в историята на Equifax. Уязвимостите в сигурността трябва да се третират по същия начин като други софтуерни проблеми, тоест те трябва да бъдат включени в цялостния процес на DevOps. Трябва да работите с тях чрез Jira, Kanban и т.н. Разработчиците не трябва да мислят, че някой друг ще направи това - напротив, всеки трябва да го направи. И накрая, трябва да изразходвате енергия за обучение на хора.

Полезни връзки

Ето няколко разговора от конференцията DevOops, които може да ви бъдат полезни:

• Сергей Бердников, Артьом Каличкин - История на успеха, или „Dev+DevOps+Ops” (видео, препис от доклада)
• Барух Садогурски, Леонид Иголник - DevOps в мащаб: гръцка трагедия в три действия (видео, препис от доклада)
• Александър Титов, Кирил Толкачов - DevOps, инженери и общност
• Тимъти Листър - Характер, общност и култура: Важни фактори за просперитет

Поглеждам в програмата DevOops 2020 Москва — там също има много интересни неща.

Източник: www.habr.com