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

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

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

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

За лекторa:

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

Следва разказ от името на Джон.

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

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

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

Направете цялата работа видима: трябва да направите цялата работа видима. Не в смисъл, че тя непременно трябва да се показва на някакъв екран, а в смисъл, че трябва да бъде наблюдаема.
Консолидиране на системите за управление на работа: необходимо консолидиране на управленските системи. В проблема с "племенните" знания и институционалните знания в 9 случая от 10 тесните места са хората. В книгата "Phoenix Project" проблемата беше в един единствен човек, Брент, заради когото проектът закъсня с три години. И на такива "Брентове" се натъквам навсякъде. За разрешаването на тези тесни места използвам следните две точки от нашия списък.
Методология на теорията на ограниченията: теория на ограниченията.
Хакове за сътрудничество: хаки на сътрудничество.
Toyota Kata (Coaching Kata): за Toyota Kata няма да говоря много. Ако ви интересува, в моя GitHub има презентации почти по всяка от тези теми.
Организация, ориентирана към пазара: ориентирана на пазара организация.
Аудитори на начало: аудит на ранните етапи на цикъла.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обсъждам с хората как точно се създават тикетите, какво става с тях после и как ги заобикалят. Най-интересното е, че хората на нашите срещи говорят доста искрено. Попитах колко хора поставят 'minor / no impact' на тикети, на които всъщност е трябвало да се присъди 'major impact'. Изясни се, че почти всички го правят. Не се занимавам с доноси и всячески се старая да не разкривам хора. Когато някой ми се признае искрено, не издавам лицето. Но когато почти всички заобикалят системата, това означава, че цялата безопасност по същество е просто декорация. Следователно не могат да се правят изводи от данните на тази система.

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

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

Пайплайн на услугите

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

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

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

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

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

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

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

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

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

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

5. Coaching Kata

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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