Питання «як впровадити у себе девопс» стоїть не перший рік, але добрих матеріалів не так багато. Іноді ви стаєте жертвою реклами не особливо розумних консультантів, яким потрібно продати свій час, байдуже як. Іноді це каламутні, вкрай загальні слова про те, як кораблі мегакорпорацій борознять простори всесвіту. Виникає питання: а нам із цього що? Шановний авторе, можете виразно списочком сформулювати свої ідеї?
Все це походить від того, що реальної практики та розуміння результату трансформацій культури компанії накопичилося не так багато. Зміни в культурі - це довгограючі штуки, результати яких виявляться не через тиждень і не через місяць. Нам потрібен хтось досить древній, який побачив, як створювалися та руйнувалися компанії протягом багатьох років.
Джон Вілліс - Один з батьків DevOps. За плечима Джон — десятки років роботи з величезною кількістю компаній. Останнім часом Джон став для себе помічати специфічні патерни, які мають бути в роботі з кожною з них. Використовуючи ці архетипи, Джон наставляє компанії на справжній шлях трансформації DevOps. Докладніше про ці архетипи — переклад його доповіді з конференції DevOops 2018.
Про доповідача:
Більше 35 років в IT-управлінні, брав участь у створенні попередника OpenCloud у Canonical, брав участь у 10 стартапах, два з яких продав Dell та Docker. Зараз є Vice President of DevOps and Digital Practices у SJ Technologies.
Далі - розповідь від імені Джона.
Мене звуть Джон Вілліс, і мене найпростіше знайти в Твіттері, . Той самий псевдонім у мене на Gmail і GitHub. А ви можете знайти відеозаписи моїх доповідей та презентації до них.
У мене багато зустрічей із CIO різних великих компаній. Вони дуже часто скаржаться, що не розуміють, що таке DevOps, а всі, хто їм намагається це пояснити, говорять про щось своє. Інша часта скарга — DevOps не працює, хоча як би директори все роблять так, як їм пояснили. Йдеться про великі компанії, яким по сто років. Поспілкувавшись із ними, я дійшов висновку, що для багатьох проблем найкраще підходять не високі технології, а відносно низькотехнологічні рішення. Тижнями я просто спілкувався з людьми із різних відділів. Те, що ви бачите на першому малюнку в пості — останній мій проект, кімната так виглядала після трьох днів роботи.
Що таке DevOps?
Справді, якщо спитати 10 різних людей, вони дадуть 10 різних відповідей. Але що цікаво: всі ці десять відповідей будуть правильними. Неправильної відповіді тут немає. Я дуже глибоко займався DevOps, приблизно 10 років, був першим американцем на першому DevOpsDay. Не скажу, що я розумніший за всіх, хто займається DevOps, але навряд чи є хтось, хто витратив на це стільки ж сил. Я вважаю, що DevOps виникає тоді, коли з'єднується людський капітал та технологія. Ми часто забуваємо про людський вимір, хоч і говоримо багато про всілякі культури.
Зараз у нас багато даних, п'ять років академічних досліджень, перевірка теорій налагоджена в промислових масштабах. Ці дослідження говорять нам таке: якщо в організаційній культурі поєднати деякі поведінкові патерни, можна отримати прискорення у 2000 разів. Цьому прискоренню відповідає таке ж покращення у стійкості. Це кількісний вимір тієї переваги, яку DevOps може дати будь-якій компанії. Кілька років тому я розповідав про DevOps генерального директора компанії зі списку Fortune 5000. Коли я готувався до презентації, я сильно нервував, бо мені потрібно було за 5 хвилин викласти свій багаторічний досвід.
У результаті я дав таке визначення DevOps: це набір практик і патернів, що дозволяють перетворити людський капітал на високопродуктивний організаційний капітал. Приклад — те, як останні 50 чи 60 років працює Toyota.
(Тут і далі такі схеми наводяться не як довідковий матеріал, а як ілюстрація. Їх зміст відрізнятиметься для кожної нової компанії. Тим не менш, картинку можна окремо подивитися та збільшити
Одна з найуспішніших таких практик — картування потоку створення цінності. Про це написано кілька хороших книг, автор найуспішніших із них — Карен Мартін (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 вузьким місцем є люди. У книзі проблема була в одній-єдиній людині, Бренті, через яку проект відставав на три роки. І на таких «Брентів» я натрапляю всюди. Для розв'язки цих вузьких місць я використовую два пункти в нашому списку.
- Theory of Constraints Methodology: теорія обмежень.
- Collaboration hacks: хакі співпраці.
- Toyota Kata (): про Toyota Kata я багато говорити не буду. Якщо цікаво, на моєму гітхабі майже з кожної з цих тем.
- Market Oriented Organization: орієнтована ринку організація.
- Shift-left auditors: аудит на ранніх етапах циклу.
Починаю роботу з організацією я дуже просто: йду до компанії та розмовляю зі співробітниками. Як бачимо, жодних високих технологій. Все, що потрібно, — щоб було на чому писати. Я збираю кілька команд в одній кімнаті та аналізую те, що вони мені кажуть, з погляду моїх 7 архетипів. А потім я даю їм самим маркер і прошу викласти на дошці письмово все те, що вони досі говорили вголос. Зазвичай на таких зустрічах є одна людина, яка все записує, і в кращому випадку у неї виходить записати 10% дискусії. При моєму методі цей показник вдається підняти десь 40%.
(окремо цю ілюстрацію можна )
Мій підхід ґрунтується на роботі Вільяма Шнайдера (William Schneider, ). В основі підходу лежить думка, що будь-яку організацію можна розкласти на чотири квадрати. Ця схема зазвичай є результатом роботи з тими сотнями інших схем, які виникають при аналізі організації. Припустимо, ми маємо організацію з високим рівнем контролю, але з низькою компетенцією. Це вкрай небажаний варіант: коли всі ходять стрункою, але при цьому ніхто не знає, що потрібно робити.
Дещо кращий варіант з високим рівнем і контролю, і компетенції. Якщо така компанія має прибуток, то можливо DevOps їй і не потрібен. Найцікавіше працювати з компанією, яка має високий рівень контролю, низьку компетенцію та співпрацю, але при цьому високий рівень культури (cultivation). Це означає, що у компанії багато людей, яким подобається там працювати, оборот робочої сили низький.
(окремо цю ілюстрацію можна )
Мені здається, що методи з жорстко заданими рекомендаціями зрештою заважають досягти істини. Зокрема у value stream mapping є багато правил щодо того, як потрібно структурувати інформацію. На ранніх етапах роботи, про які я зараз говорю, ці правила нікому не потрібні. Якщо людина з маркером в руках описує на дошці реальну ситуацію в компанії, це найкращий спосіб розібратися в стані справ. Така інформація не доходить до директорів. У цей момент безглуздо обривати людину і говорити, що вона неправильно намалювала якусь стрілку. На цьому етапі краще користуватися простими правилами, наприклад: багаторівневу абстракцію можна створити просто використовуючи різнокольорові маркери.
Повторюю, жодних високих технологій. Чорним маркером зображується об'єктивна реальність, як усе працює. Червоним маркером люди наголошують, що саме їм у існуючому стані речей не подобається. Важливо, що вони пишуть, а не я. Коли після зборів я йду до директора з інформаційних технологій, я не пропоную перелік із 10 речей, які потрібно виправити. Я прагну знайти зв'язки між тим, що говорять люди з компанії, та існуючими перевіреними патернами. Зрештою, синім маркером пропонуються можливі вирішення проблеми.
(окремо цю ілюстрацію можна )
Приклад такого підходу зараз зображено вище. На початку цього року я працював із одним банком. Працівники з відділу безпеки там були переконані, що їм не можна приходити на перевірки вимог та проектування (design and requirement reviews).
(окремо цю ілюстрацію можна )
А потім ми поговорили з людьми з інших відділів і з'ясувалося, що десь 8 років тому розробники програмного забезпечення виставили працівників безпеки, бо ті сповільнювали роботу. А потім це перетворилося на заборону, яка сприймалася як даність. Хоча насправді жодної заборони не було.
Наша зустріч йшла вкрай заплутаним ходом: протягом десь трьох годин п'ять різних команд ніяк не могли мені пояснити, що відбувається між кодом та складанням. А це, здавалося б, найпростіша річ. Більшість консультантів DevOps наперед припускають, що це вже всім відомо.
Потім людина, яка відповідала за регулювання IT (IT governance), мовчала протягом чотирьох годин, раптом ожила, коли ми дійшли до його теми, і зайняла нас ще досить тривалий час. Насамкінець я запитав його, що він думає про зустріч, і я ніколи не забуду його відповіді. Він сказав: «Раніше я думав, що в нашому банку всього два способи постачання софту, а тепер я знаю, що їх цілих п'ять, і про три я навіть не підозрював».
(окремо цю ілюстрацію можна )
Остання зустріч у цьому банку була з командою, що займається програмним забезпеченням для інвестицій. Саме з нею з'ясувалося, що писати схеми маркером на аркуші краще, ніж на дошці, і навіть краще, ніж на смартборді.
Фотографії, які Ви бачите, — це те, як виглядав конференц-зал готелю на четвертий день нашої зустрічі. І ці схеми ми використовували для пошуку патернів, тобто архетипів.
Отже, я запитую працівників, вони записують відповіді маркерами трьох кольорів (чорним, червоним і синім). Їхні відповіді я аналізую на предмет архетипів. Зараз обговоримо всі архетипи по порядку.
1. Make All Work Visible: Зробити роботу видимою
У більшості компаній, з якими працюю, дуже високий відсоток невідомої роботи. Наприклад, коли один співробітник приходить до іншого і просто просить щось зробити. У великих організаціях може бути 60% незапланованої роботи. І аж до 40% роботи не задокументовано. Якби це був Boeing, то я в житті жодного разу більше не сів би на їхній літак. Якщо документується лише половина роботи, то невідомо, чи правильно ця робота виконується чи ні. Всі інші методи виявляються марними — немає жодного сенсу намагатися щось автоматизувати, тому що відомі 50% можуть бути якраз найбільш злагодженою і чіткою частиною роботи, автоматизація якої великих результатів не дасть, а найстрашніше — у невидимій половині. За відсутності документації неможливо знайти всякого роду хакі та приховану роботу, не знайти вузьких місць, тих самих «Брентів», про які я вже говорив. Є чудова книга Домініки Де Грандіс (Dominica DeGrandis) . Вона виявляє п'ять різних «витік часу» (thieves of time):
- Too Much Work in Process (WIP)
- Unknown Dependencies
- Unplanned Work
- Conflicting priorities
- Neglected Work
Це дуже цінний аналіз, і книга чудова, але всі ці поради марні, якщо видно лише 50% даних. Застосовувати методи, запропоновані Домінікою, можна, якщо досягнуто точність вище 90%. Я говорю про ситуації, коли начальник дає підлеглому 15-хвилинну задачу, а вона займає у того три дні; але начальник насправді не знає, що цей підлеглий залежить від чотирьох чи п'яти інших людей.
Phoenix Project - це чудова розповідь про проект, який запізнився на три роки. Одному з героїв через це загрожує звільнення, і він зустрічається з іншим персонажем, представленим як свого роду Сократ. Той допомагає розібратися, що пішло не так. З'ясовується, що у компанії є один сисадмін, якого звуть Брент, і вся робота так чи інакше проходить через нього. На одній із зустрічей одного з підлеглих запитують: чому кожне півгодинне завдання займає тиждень? У відповідь слідує дуже спрощене виклад теорії черг і закону Літтла, і в цьому викладі виявляється, що при 90% зайнятості кожну годину роботи займає 9 годин. Кожне завдання потрібно відправити семи іншим людям, тому ця година перетворюється на 63 години, 7 помножити на 9. Я це кажу до того, що, щоб використовувати закон Літтла або складну теорію черг, потрібно хоча б мати дані.
Тому коли я говорю про видимість, я маю на увазі не щоб все було на екрані, а що потрібно хоча б мати дані. Коли вони є, найчастіше з'ясовується, що є дуже великий обсяг незапланованої роботи, яка чомусь спрямовується до Брента, хоча в цьому немає потреби. А Брент - чудовий хлопець, він ніколи не скаже "ні", але при цьому він нікому не розповідає, як він робить свою роботу.
Коли робота видно, можна акуратно класифікувати дані (саме цим Домініка займається на фото), можна застосовувати абстракцію п'яти витоків часу та автоматизувати.
2. Consolidate Work Management Systems: Управління завданнями
Архетипи, про які я говорю, являють собою свого роду піраміду. Якщо перший виконаний правильно, другий вже є свого роду надбудовою. Багато хто з них не працює для стартапів, їх потрібно мати на увазі у разі великих компаній, таких, які потрапляють до списку Fortune 5000. В останній компанії, де я працював, було 10 систем відстеження помилок (ticketing system). В одній команді був Remedy, інша написала свою систему, третя користувалася Jira, хтось зовсім обходився електронною поштою. Та сама проблема виникає, якщо в компанії 30 різних пайплайнів, але часу на те, щоб обговорити всі подібні випадки, у мене немає.
Я обговорюю з людьми, як саме створюються тікети, що з ними далі відбувається, як їх оминають. Найцікавіше те, що люди на наших зустрічах говорять досить щиро. Я запитав, скільки людей виставляють «minor/no impact» для тикетів, яким насправді слід було привласнити «major impact». З'ясувалося, що так роблять багато. Я не займаюся доносом і всіляко намагаюся не виявляти людей. Коли мені щось щиро зізнаються, я не видаю людину. Але коли практично всі обходять систему, це означає, що вся безпека є декорацією. Тому жодних висновків із даних цієї системи робити не можна.
Щоб вирішити проблему з тикетами, потрібно вибрати одну головну систему. Якщо ви користуєтеся Jira, нехай буде лише Jira. Якщо є якась альтернатива, то нехай буде тільки вона. Суть у цьому, що тикети слід як ще один етап процесу розробки. Будь-яка дія має мати тикет, який повинен проходити через робочий процес розробки. Тикети відправляються команді, яка викладає їх на storyboard, а потім несе відповідальність за них.
Це стосується всіх відділів, у тому числі і інфраструктурного та операційного. У такому разі можна скласти бодай скільки-небудь правдоподібне уявлення про стан речей. Коли цей процес налагоджений, раптом виявляється, що можна легко встановити, хто несе відповідальність за кожну програму. Тому що тепер ми маємо не 50%, а 98% нових сервісів. Якщо цей основний процес працює, то точність підвищується у всій системі.
Пайплайн сервісів
Це знову ж таки стосується лише великих корпорацій. Якщо ви нова компанія в новій області - закатайте рукави та працюйте зі своїм Travis CI або CircleCI. Що ж до компаній Fortune 5000, показовим є випадок, який стався з банком, де я працював. До них прийшли з Google і їм показали діаграми зі старими системами IBM. Хлопці з Google з нерозумінням запитали, а де для цього вихідний код? А жодного вихідного коду немає, немає навіть GUI. Це та реальність, з якою доводиться працювати великим організаціям: 40-річні банківські записи на стародавньому мейнфреймі. Один з моїх клієнтів використовує контейнери 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. Collaboration hacks: Хакі співпраці
Четвертий архетип у тому, що необхідно боротися з ізоляцією. Більшість людей про це вже знає: ізоляція породжує ворожнечу. Якщо кожен відділ на своєму поверсі, і люди один з одним ніяк не перетинаються, окрім як у ліфті, ворожнеча між ними зароджується дуже легко. А якщо, навпаки, люди знаходяться в одному приміщенні один з одним, вона відразу йде. Коли хтось кидає якесь загальне звинувачення, наприклад, такий інтерфейс ніколи не працює — немає нічого простішого, щоб таке звинувачення деконструювати. Програмістам, які написали інтерфейс, достатньо почати ставити конкретні питання, і скоро з'ясується, що, наприклад, користувач просто неправильно використовував інструмент.
Є багато способів подолати ізоляцію. Мене якось просили консультувати банк в Австралії, я відмовився це робити, бо маю двох дітей і дружину. Все, чим я міг їм допомогти, я порекомендував їм graphical storytelling. Це річ, яка доказово працює. Інший цікавий спосіб – зустрічі формату lean coffee. У великій організації це чудовий варіант поширення знання. Крім того, можна проводити внутрішні девопсдні, хакатони і так далі.
5. Coaching Kata
Як я вже попереджав на самому початку, сьогодні я про це не розповідатиму. Якщо цікаво, то можете подивитися .
Є також гарна доповідь на цю тему від Mike Rother:
6. Market Oriented: орієнтована ринку організація
Тут існують різні проблеми. Наприклад, люди "I", люди "T" та люди "E". Люди «I» – це ті, хто займається лише чимось одним. Зазвичай вони існують саме в організаціях із ізольованими підрозділами. "T" - це якщо людина добре знає щось одне, але також процвітає і в деяких інших речах. «E» або навіть «гребінець» — це коли людина має багато навичок.
Тут працює закон Конвею (), який у максимально спрощеній формі можна викласти так: якщо три команди займаються компілятором, то в результаті вийде компілятор із трьох частин. Тому, якщо всередині організації високий рівень ізоляції, то навіть Kubernetes, Circuit breaker, API extensibility та інші модні речі в цій організації будуть влаштовані так само, як і сама організація. Строго за Конвеєм і на зло всім вам, юні гіки.
Вирішення цієї проблеми було описано багато разів. Існують, наприклад, організаційні архетипи, описані Фернандо Фернандезом (Fernando Fernandez). Та проблемна архітектура, про яку я щойно говорив, із ізоляцією — це функціонально-орієнтована архітектура. Другий тип — найгірший, матрична архітектура, там каша із двох інших. Третій - це те, що спостерігається в більшості стартапів, і великі компанії також намагаються відповідати цьому типу. Це орієнтована ринку організація. Тут іде оптимізація для досягнення найшвидшого відгуку на запити клієнтів. Іноді це називається плоскою організацією.
Цю структуру багато хто описує по-різному, мені подобається формулювання build/run teams, в Amazon це називають XNUMX pizza teams. У цій структурі всі люди типу «I» групуються навколо одного сервісу, і поступово вони стають ближчими до типу «T», а якщо налагоджено правильний менеджмент, можуть стати навіть «E». Перший контраргумент тут – у такій структурі є зайві елементи. Навіщо потрібний тестер у кожному відділенні, якщо можна мати спеціальний відділ тестувальників? На що я відповідаю: зайві витрати в цьому випадку — це ціна за те, щоб у майбутньому вся організація стала на кшталт «Е». У такій структурі тестувальник поступово дізнається про мережі, архітектуру, проектування тощо. У результаті кожен учасник організації виявляється повністю обізнаний про все, що в організації відбувається. Якщо хочете дізнатися, як ця схема працює у промисловості, почитайте .
7. Shift-left auditors: аудит на ранніх етапах циклу. Дотримання правил безпеки напоказ
Це коли ваші дії не проходять перевірку на запах. Люди, які працюють на вас, не дурні. Якщо вони, як у прикладі вище, скрізь виставляли minor/no impact, це тривало три роки, і ніхто нічого не помітив, то всі чудово знають, що система не працює. Або інший приклад - порада зі змін (change advisory board), куди кожну, скажімо, середу, потрібно подавати звіти. Там працює група людей (до речі, не надто добре оплачуваних), які в теорії повинні знати, як працює система в цілому. А за останні років п'ять ви, напевно, помітили, що наші системи дуже складні. І п'ять-шість осіб мають ухвалити рішення щодо зміни, яку не вони внесли і про яку вони нічого не знають.
Звісно, такий підхід не працює. Мені таких речей доводиться позбуватися, бо ці люди не захищають систему. Рішення має приймати сама команда, тому що команда має бути відповідальною за нього. В іншому випадку виникає парадоксальна ситуація, коли менеджер, що ніколи в житті не писав коду, повідомляє програмісту, скільки часу має зайняти написання коду. В одній компанії, з якою я працював, було 7 різних порад, які розглядали кожну зміну, у тому числі раду з архітектури, продуктів і т.п. Існував навіть обов'язковий період очікування, хоча один співробітник мені сказав, що за десять років роботи ніхто жодного разу в цей обов'язковий період не відхилив змін, внесених цією людиною.
Аудиторів потрібно кликати до себе, а не позбавлятися їх. Розкажіть їм, що ви пишете іммутабельні бінарні контейнери, які, якщо пройдуть усі тести, залишаються незмінними назавжди. Розкажіть їм, що у вас є pipeline as code, і поясніть, що це означає. Покажіть їм наступну схему: іммутабельний binary тільки для читання в контейнері, який проходить всі тести на вразливості; а далі не тільки до нього ніхто не торкається — не торкаються навіть системи, яка створює пайплайн, оскільки вона також створюється динамічно. У мене є клієнти, Capital One, які за допомогою Vault створюють щось на кшталт блокчейну. Аудитору можна не показувати «рецептів» із Chef, достатньо показати блокчейн, з якого ясно, що сталося з тикетом Jira у продакшені та хто за нього відповідальний.
Згідно з , Створеному в 2018 році Sonatype, в 2017 році було 87 мільярдів запитів на завантаження OSS.
Збитки, зазнані через уразливість, виявляються непомірно високими. Причому ті цифри, які ви бачите вище, не включають альтернативні витрати. Двома словами про те, що таке DevSecOps. Відразу хочу сказати, що мене не цікавлять розмови про те, наскільки вдала ця назва. Сенс у тому, що, якщо DevOps були досить успішними, потрібно спробувати додати до цього пайплайну безпеку.
Приклад такої послідовності:
Це не рекомендація певних продуктів, хоч мені вони всі подобаються. Я привів їх як приклад, щоб показати, що DevOps, заснований спочатку на парадигмі організації в промисловості, дозволяє автоматизувати кожен етап роботи над продуктом.
І немає жодної причини, через яку ми не могли б застосувати той самий підхід до безпеки.
Підсумок
Як висновок дам кілька порад для DevSecOps. Потрібно включити аудиторів у процес створення ваших систем, витратити час на їхню освіту. З аудиторами треба співпрацювати. Далі, потрібно вести абсолютно безжальну боротьбу з хибними спрацьовуваннями. Навіть з найдорожчим інструментом сканування на вразливості можна створити шкідливі звички у ваших розробників, якщо ви не знаєте, яке відношення сигналу до шуму. Розробники виявляться перевантажені подіями, і вони просто видалятимуть їх. Якщо ви чули про історію з Equifax, то приблизно це і сталося, там був проігнорований сигнал найвищого рівня небезпеки. Крім того, вразливості слід пояснювати так, щоб було зрозуміло, як вони впливають на бізнес. Наприклад, можна сказати, що це та ж уразливість, що й в історії з Equifax. Уразливості, що стосуються безпеки, потрібно розглядати так само, як і інші проблеми із софтом, тобто їх потрібно включити до загального процесу DevOps. З ними потрібно працювати через Jira, Kanban тощо. Розробники не повинні думати, що цим займеться хтось інший - навпаки, цим мають займатися всі. Зрештою, потрібно витрачати сили на те, щоби навчати людей.
Корисні посилання
Ось кілька доповідей з конференції DevOops, які можуть здатися вам корисними:
- Сергій Бердников, Артем Каличкін - Історія успіху, або «Dev+DevOps+Ops» (, )
- Барух Садогурський, Леонід Ігольник – DevOps у масштабі: грецька трагедія у трьох актах (, )
- Олександр Тітов, Кирило Толкачов
- Timothy Lister -
Загляньте в DevOops 2020 Moscow - Там теж багато чого цікавого.
Джерело: habr.com