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

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

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

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

За докладчика:

С над 35 години опит в IT управлението, той е участвал в създаването на предшественика на OpenCloud в Canonical, и е участвал в 10 стартапа, два от които е продал на Dell и Docker. В момента е Вицепрезидент по DevOps и цифрови практики в SJ Technologies.

Сега — разказът от лице на Джон.

Казвам се Джон Уиллис и можете да ме намерите в Туитър, @botchagalupe. Същият псевдоним имам и в Gmail и GitHub. А тук можете да намерите видеозаписи на моите доклади и презентации към тях.

Имам много срещи с ИТ директори на големи компании. Те често се оплакват, че не разбират какво е DevOps, а всички, които се опитват да им го обяснят, говорят за неща, които са само техни. Друга често срещана оплакване е, че DevOps не работи, въпреки че директорите изглежда правят всичко, както им е обяснено. Става дума за големи компании, които съществуват по над сто години. След като разговарях с тях, стигнах до извода, че за много от проблемите по-добре подхождат не високи технологии, а относително нискотехнологични решения. Седмици наред просто общувах с хора от различни отдели. Това, което виждате на самата първа снимка в поста — последният ми проект, стаята изглеждаше така след три дни работа.

Какво е DevOps?

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

Сега имаме много данни, пет години академични изследвания, проверка на теории на индустриално ниво. Тези изследвания ни казват следното: ако в организационната култура съчетаем определени поведенчески модели, можем да постигнем ускорение от 2000 пъти. На това ускорение отговаря и съответното подобрение в устойчивостта. Това е количествено измерение на това предимство, което DevOps може да даде на всяка компания. Преди няколко години разказвах за DevOps на главния изпълнителен директор на компания от списъка Fortune 5000. Когато се подготвях за презентацията, страшно се притеснявах, защото трябваше да изложа многогодишния си опит за 5 минути.

В крайна сметка дадох следното определение на DevOps: това е набор от практики и модели, които позволяват да се превърне човешкият капитал в високо производителен организационен капитал. Пример — как Toyota работи през последните 50 или 60 години.

(Тук и по-надолу такива схеми се предоставят не като справочен материал, а като илюстрация. Съдържанието им ще се различава за всяка нова компания. Въпреки това, картинката може да бъде видяна и увеличена отделно, чрез тази връзка.)

Една от най-успешните такива практики е value stream mapping. За това са написани няколко добри книги, авторът на най-успешната от тях е Карен Мартин (Karen Martin). Но през последната година достигнах до извода, че дори този подход е прекалено високотехнологичен. Той, без съмнение, има множество предимства, които съм използвал много. Но когато главният изпълнителен директор те пита защо компанията му не може да премине на нови релси, за value stream mapping разговорът е още рано. Има много значително по-фундаментални въпроси, на които предварително трябва да намерим отговори.

Мисля, че грешката на много мои колеги е, че те просто дават на компанията ръководство от пет точки, а след това се връщат след шест месеца и виждат какво се е случило. Дори и добрата схема като value stream mapping има, да кажем, мъртви зони (blind spots). След стотици интервюта с директори на различни компании разработих определен шаблон, който позволява да се разложи проблемът на съставни части, и в момента по ред ще обсъдим всяка от тези съставни части. Преди да приложа каквито и да е технологични решения, използвам този шаблон, и в резултат всичките ми стени се оказват покрити със схеми. Наскоро работих с един взаимно фонд, и накрая резултатът беше, че имах 100-150 такива схеми.

Лошата култура яде добрите подходи за закуска.

Основната идея е следната: никакви Lean, Agile, SAFE и DevOps не могат да помогнат, ако самата култура на организацията е лоша. Това е все едно да се гмуркаш на дълбочина без акваланг или да оперираш без рентгенова снимка. Иначе казано, перефразирайки Друкера и Деминга: лошата организационна култура ще погълне всяка добра система и няма да се задави.

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

Make All Work Visible: необходимо е да направим цялата работа видима. Не в смисъл, че непременно трябва да се показва на някакъв екран, а в смисъл, че тя трябва да бъде наблюдавана.
Consolidate Work Management Systems: необходимо консолидиране на системите за управление. В проблема «племенно» знание и институционално знание в 9 от 10 случая ограничението са хората. В книгата «Phoenix Project» проблемата беше в един единствен човек, Брент, заради когото проектът изостава с три години. И на такива «Брентове» се натъквам навсякъде. За разрешаване на тези ограничения използвам следните две точки от нашия списък.
Methodology of Theory of Constraints: теория на ограниченията.
Collaboration hacks: хаки на сътрудничеството.
Toyota Kata (Coaching Kata): за Toyota Kata няма да говоря много. Ако ви интересува, в моя GitHub има презентации почти по всяка от тези теми.
Market Oriented Organization: организация, ориентирана към пазара.
Shift-left auditors: одит в ранните етапи на цикъла.

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

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

Моят подход е основан на работата на Уилям Шнайдер (William Schneider, The Reengineering Alternative). В основата на подхода е мисълта, че всяка организация може да бъде разложена на четири квадрата. Тази схема обикновено е резултат от работата с онези стотици други схеми, които възникват при анализа на организацията. Да предположим, че имаме организация с висок контрол, но с ниска компетентност. Това е изключително нежелателен вариант: когато всички вървят по струнка, но никой не знае какво трябва да се прави.

По-добре е да се работи с компания с висок контрол и култура, но ниска компетентност. Ако такава компания генерира печалба, вероятно DevOps не е необходим. Най-интригуващо е да се работи с организация, в която хората обичат да работят и текучеството е ниско.

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

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

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

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

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

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

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

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

После човекът, отговарящ за ИТ регулирането (IT governance), който мълча четири часа, изведнъж оживя, когато стигнахме до неговата тема, и ни занимаваше още доста дълго време. В края на срещата го попитах какво мисли за срещата, и никога няма да забравя отговора му. Той каза: „По-рано мислех, че в нашата банка има само два начина за доставка на софтуер, а сега знам, че има цели пет, и за три от тях дори не подозирах.“

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

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

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

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

1. Make All Work Visible: Направете работата видима

В повечето компании, с които работя, процентът на неизвестната работа е много висок. Например, това е, когато един служител идва при друг и просто поиска нещо да се направи. В големите организации може да има 60% непланирана работа. И до 40% от работата не е документирана по никакъв начин. Ако това беше Boeing, никога повече не бих се качил на техен самолет. Ако само половината от работата е документирана, не е ясно дали тя се извършва правилно или не. Всички останали методи са безполезни — няма смисъл да се опитваме да автоматизираме нещо, заради известните 50%, които може да са най-координираната и ясна част от работата, чиято автоматизация няма да доведе до големи резултати, а всичко най-ужасно остава в невидимата половина. При отсъствието на документация е невъзможно да се намерят всякакви хакове и скрита работа, да се идентифицират слабите места, т.н. "Брентове", за които съм говорил. Съществува прекрасна книга на Доминика Де Грандис (Dominica DeGrandis) «Making Work Visible». Тя разкрива пет различни „кражби на време“ (thieves of time):

Прекалено много работа в процес (WIP)
Непознати зависимости
Непланирана работа
Противоречиви приоритети
Пренебрегвана работа

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

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

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

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

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

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

Обсуждая с людьми, как создаются тикеты и что с ними происходит дальше, я заметил, что наши встречи проходят довольно откровенно. Я задал вопрос о том, сколько людей ставят «незначительное / без влияния» на тикеты, которые на самом деле должны получить статус «значительное влияние». Оказалось, что почти все так делают. Я не занимаюсь разоблачениями и стараюсь не выявлять людей. Когда мне что-либо искренне признают, я не выношу человека на обсуждение. Однако, когда почти все игнорируют систему, это говорит о том, что сама безопасность, по сути, является лишь формальностью. Следовательно, делать выводы на основе этих данных нельзя.

Чтобы решить проблему с тикетами, необходимо выбрать одну основную систему. Если вы используете Jira, пусть это будет только Jira. Если есть альтернатива, выберите только её. Суть в том, что тикеты должны рассматриваться как еще один этап процесса разработки. Каждое действие должно иметь тикет, который проходит через процесс разработки. Тикеты передаются команде, которая размещает их на доске истории, и затем несет ответственность за их выполнение.

Это касается всех отделов, включая инфраструктурный и операционный. В таком случае можно составить достаточно достоверное представление о ситуации. Когда этот процесс налажен, становится очевидным, кто отвечает за каждое приложение. Теперь мы получаем не 50%, а 98% новых сервисов. Если этот основной процесс работает, точность информации будет увеличиваться по всей системе.

Сервисный пайплайн

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

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

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

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

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

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

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

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

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

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

5. Coaching Kata

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

Има също така добра лекция по темата от Mike Rother:

6. Market Oriented: ориентирана към пазара организация

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

Тук важи законът на Конвей (Conway’s law), който в максимално опростена форма може да се изложи така: ако три екипа работят по компилатор, в крайна сметка ще се получи компилатор от три части. Затова, ако вътре в организацията има висок ниво на изолация, дори Kubernetes, Circuit breaker, API extensibility и други модерни неща в тази организация ще бъдат структурирани по същия начин, по който е самата организация. Строго по Конвей и назло на вас, млади гикове.

Решението на този проблем е описано многократно. Има, например, организационни архетипи, описани от Фернандо Фернандез (Fernando Fernandez). Тази проблемна архитектура, за която току-що говорих, с изолация — това е функционално ориентирана архитектура. Вторият тип — най-лошият, матрична архитектура, там е каша от двете други. Третият — това, което наблюдаваме в повечето стартъпи, и големите компании също се опитват да се адаптират към този тип. Това е организация, ориентирана към пазара. Целта тук е оптимизация за постигане на най-бърза реакция на клиентските запитвания. Понякога това се нарича плоска организация.

Много хора описват тази структура по различен начин, но на мен ми харесва формулировката build/run teams, в Amazon това се нарича two pizza teams. В тази структура всички хора от тип „I“ се групират около една услуга и постепенно стават по-близки до типа „T“, а ако се прилага правилно управление, могат да станат дори „E“. Първият контрааргумент тук е, че в такава структура има излишни елементи. Защо да има тестер в всяко отделение, когато може да има специален отдел за тестване? На което отговарям: излишните разходи в този случай са цената, която трябва да платим, за да може в бъдеще цялата организация да стане тип „E“. В такава структура тестерът постепенно научава за мрежите, архитектурата, проектирането и т.н. В крайна сметка всеки участник в организацията се оказва напълно запознат с всичко, което се случва в нея. Ако искате да разберете как работи тази схема в индустрията, прочетете Mike Rother, Toyota Kata.

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

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

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

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

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

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

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

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

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

Резюме

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