Пытанне "як укараніць у сябе дэвопс" стаіць не першы год, але добрых матэрыялаў не так шмат. Часам вы становіцеся ахвярай рэкламы не асабліва разумных кансультантаў, якім трэба прадаць свой час, усё роўна як. Часам гэта каламутныя, вельмі агульныя словы аб тым, як караблі мегакарпарацый барозняць прасторы сусвету. Узнікае пытанне: а нам з гэтага што? Паважаны аўтар, можаце выразна спісачкам сфармуляваць свае ідэі?
Усё гэта паходзіць ад таго, што рэальнай практыкі і разумення зыходу трансфармацый культуры кампаніі назапасілася не так шмат. Змены ў культуры - гэта доўгаіграюць штукі, вынікі якіх выявяцца не праз тыдзень і не праз месяц. Нам патрэбен хтосьці дастаткова старажытны, які пабачыў, як ствараліся і разбураліся кампаніі на працягу многіх гадоў.
Джон Уіліс - Адзін з бацькоў DevOps. За плячыма ў Джона – дзясяткі гадоў працы з велізарнай колькасцю кампаній. У апошні час Джон стаў для сябе заўважаць спецыфічныя патэрны, якія маюць месца быць у працы з кожнай з іх. Выкарыстоўваючы гэтыя архетыпы, Джон навучае кампаніі на праўдзівы шлях DevOps-трансфармацыі. Больш падрабязна пра гэтыя архетыпы — у перакладзе яго даклада з канферэнцыі DevOops 2018.
Аб дакладчыку:
Больш за 35 гадоў у IT-кіраванні, удзельнічаў у стварэнні папярэдніка OpenCloud у Canonical, прымаў удзел у 10 стартапах, два з якіх прадаў Dell і Docker. Цяпер з'яўляецца Vice President of DevOps і 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. У вялікай арганізацыі гэта выдатны варыянт распаўсюджвання ведаў. Акрамя таго, можна праводзіць унутраныя devopsdays, хакатоны і гэтак далей.
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 гэта называюць two 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