«Девопсты қалай енгізу керек» деген сұрақ көп жылдар бойы болды, бірақ жақсы материалдар көп емес. Кейде сіз өз уақытын қалай болса да сатуды қажет ететін ақылды емес кеңесшілердің жарнамаларының құрбаны боласыз. Кейде бұл мегакорпорациялардың кемелері ғаламның кеңістігін қалай жыртатыны туралы бұлыңғыр, өте жалпы сөздер. Сұрақ туындайды: мұның бізге не қатысы бар? Құрметті автор, сіз өз идеяларыңызды тізімде нақты тұжырымдай аласыз ба?
Мұның бәрі компания мәдениетін өзгерту нәтижесі туралы нақты тәжірибе мен түсініктің көп жинақталмағандығынан туындайды. Мәдениеттегі өзгерістер - бұл ұзақ мерзімді нәрселер, оның нәтижесі бір аптада немесе бір айда пайда болмайды. Бізге компаниялардың жылдар бойы қалай құрылып, сәтсіздікке ұшырағанын көру үшін жеткілікті жастағы адам керек.
Джон Уиллис - DevOps әкелерінің бірі. Джонның көптеген компаниялармен жұмыс істеген ондаған жылдық тәжірибесі бар. Жақында Джон олардың әрқайсысымен жұмыс істеу кезінде орын алатын нақты үлгілерді байқай бастады. Осы архетиптерді пайдалана отырып, Джон компанияларды DevOps трансформациясының шынайы жолына бағыттайды. Бұл архетиптер туралы оның DevOops 2018 конференциясындағы баяндамасының аудармасынан оқыңыз.
Спикер туралы:
IT-менеджментінде 35 жылдан астам, Canonical-те OpenCloud предшественнигінің құрылуына қатысты, 10 стартапқа қатысты, оның екеуі Dell және Docker-ке сатылды. Қазіргі уақытта ол SJ Technologies компаниясының DevOps және цифрлық тәжірибелер жөніндегі вице-президенті.
Келесі Джонның көзқарасы бойынша оқиға.
Менің атым Джон Уиллис және мені табудың ең оңай жері - Twitter, . Менің Gmail және GitHub-да бірдей бүркеншік атым бар. А Сіз менің есептерімнің бейне жазбаларын және оларға арналған презентацияларды таба аласыз.
Мен әртүрлі ірі компаниялардың CIO-ларымен көптеген кездесулер өткіземін. Олар DevOps дегеннің не екенін түсінбейтініне жиі шағымданады және оларға түсіндіруге тырысатындардың бәрі басқа нәрсе туралы айтады. Тағы бір жиі кездесетін шағым - DevOps жұмыс істемейді, бірақ директорлар бәрін түсіндірілгендей істеп жатқан сияқты. Біз жүз жылдан асқан ірі компаниялар туралы айтып отырмыз. Олармен сөйлескеннен кейін мен көптеген мәселелер үшін жоғары технология емес, салыстырмалы түрде төмен технологиялық шешімдер қолайлы деген қорытындыға келдім. Апталар бойы мен әртүрлі бөлімдердің адамдарымен сөйлестім. Посттағы ең бірінші суретте көріп тұрғандарыңыз менің соңғы жобам, үш күн жұмыс істегеннен кейін бөлме осылай болды.
DevOps дегеніміз не?
Расында, 10 түрлі адамнан сұрасаңыз, олар 10 түрлі жауап береді. Бірақ бір қызығы, осы он жауаптың барлығы дұрыс болады. Мұнда қате жауап жоқ. Мен шамамен 10 жыл бойы DevOps-пен өте терең айналыстым және бірінші DevOpsDay күнінде бірінші американдық болдым. Мен DevOps-пен айналысатындардың барлығынан ақылдымын деп айтпаймын, бірақ оған көп күш жұмсаған ешкім жоқ. Менің ойымша, DevOps адам капиталы мен технология біріктірілген кезде пайда болады. Біз мәдениеттің барлық түрлері туралы көп айтқанымызбен, адами өлшемді ұмытып кетеміз.
Қазір бізде көптеген деректер, бес жылдық академиялық зерттеулер, теорияларды өнеркәсіптік ауқымда сынау бар. Бұл зерттеулер бізге ұйымдық мәдениеттегі кейбір мінез-құлық үлгілерін біріктірсеңіз, 2000 есе жылдамдатуға қол жеткізе аласыз. Бұл жеделдету тұрақтылықтың бірдей жақсаруымен сәйкес келеді. Бұл DevOps кез келген компанияға әкелетін пайданың сандық өлшемі. Бір-екі жыл бұрын мен Fortune 5000 компаниясының бас директорына DevOps туралы айтқан болатынмын.Тұсаукесерге дайындалып жатқанда мен қатты қобалжыдым, өйткені көп жылғы тәжірибемді 5 минутта қорытындылауға тура келді.
Соңында мен мынаны бердім DevOps анықтамасы: Бұл адами капиталды жоғары тиімді ұйымдық капиталға айналдыруға мүмкіндік беретін тәжірибелер мен үлгілердің жиынтығы. Мысалы, Toyota-ның соңғы 50 немесе 60 жылдағы жұмыс істеу тәсілі.
(Бұдан әрі мұндай диаграммалар анықтамалық материал ретінде емес, иллюстрациялар ретінде беріледі. Олардың мазмұны әрбір жаңа компания үшін әр түрлі болады. Дегенмен суретті бөлек көруге және үлкейтуге болады.
Мұндай тәжірибелердің ең сәтті бірі құнды ағынды салыстыру. Бұл туралы бірнеше жақсы кітаптар жазылған, олардың ең сәттісі Карен Мартин. Бірақ соңғы бір жылда мен бұл тәсілдің өзі тым жоғары технологиялық деген қорытындыға келдім. Әрине, оның көптеген артықшылықтары бар және мен оны көп қолдандым. Бірақ бас директор сізден оның компаниясы неге жаңа рельстерге ауыса алмайтынын сұрағанда, құн ағынын салыстыру туралы айту әлі ерте. Алдымен жауап беруі керек көптеген іргелі сұрақтар бар.
Менің ойымша, көптеген әріптестерімнің қателігі - олар компанияға бес тармақтан тұратын нұсқаулық беріп, содан кейін алты айдан кейін оралып, не болғанын көру. Тіпті құн ағынын салыстыру сияқты жақсы схемада, айталық, соқыр нүктелер бар. Әртүрлі компаниялардың директорларымен жүздеген сұхбаттардан кейін мен мәселені оның құрамдас бөліктеріне бөлуге мүмкіндік беретін белгілі бір үлгіні әзірледім, енді біз осы компоненттердің әрқайсысын рет-ретімен талқылаймыз. Кез келген технологиялық шешімдерді қолданбас бұрын, мен осы үлгіні қолданамын, нәтижесінде менің барлық қабырғаларым диаграммалармен жабылған. Жақында мен пай қорымен жұмыс істеп, 100-150 осындай схемамен аяқтадым.
Нашар мәдениет таңғы асқа жақсы тәсілдерді жейді
Негізгі идея мынада: ұйым мәдениетінің өзі нашар болса, Lean, Agile, SAFE және DevOps ешбір көмек бермейді. Бұл аквалангсыз тереңдікке сүңгу немесе рентгенсіз операция сияқты. Басқаша айтқанда, Друкер мен Демингті қайталап айтсақ: нашар ұйымдық мәдениет кез келген жақсы жүйені тұншықтырмай жұтып қояды.
Бұл негізгі мәселені шешу үшін келесі қадамдарды орындау қажет:
- Барлық жұмыстарды көрінетін ету: барлық жұмысты көрінетін етіп жасау керек. Ол міндетті түрде қандай да бір экранда көрсетілуі керек деген мағынада емес, ол бақыланатын болуы керек деген мағынада.
- Жұмысты басқарудың шоғырландырылған жүйелері: басқару жүйелерін біріктіру қажет. «Рулық» білім мен институционалдық білім проблемасында 9 жағдайдың 10-ында тығырықтан шыққан адамдар. Кітапта мәселе жобаның үш жылға кешіктірілуіне себеп болған жалғыз адам Брентте болды. Мен осы «Бренттерді» кез келген жерде кездестіремін. Осы кедергілерді шешу үшін мен тізімдегі келесі екі элементті қолданамын.
- Шектеу теориясының әдістемесі: шектеулер теориясы.
- Ынтымақтастық хакерлері: ынтымақтастық хакерлері.
- Toyota Kata (): Мен Toyota Kata туралы көп айтпаймын. Қызықтырса, менің github-да осы тақырыптардың әрқайсысында дерлік.
- Нарыққа бағытталған ұйым: нарыққа бағытталған ұйым.
- Солға ауысатын аудиторлар: циклдің бастапқы кезеңдеріндегі аудит.
Мен ұйыммен жұмыс істей бастаймын: мен компанияға барып, қызметкерлермен сөйлесемін. Көріп отырғаныңыздай, жоғары технология жоқ. Сізге тек жазу керек нәрсе. Мен бірнеше команданы бір бөлмеге жинап, олардың маған айтқанын 7 архетипім тұрғысынан талдаймын. Сосын мен оларға маркер беріп, осы уақытқа дейін дауыстап айтқандарының барлығын тақтаға жазуын сұраймын. Әдетте мұндай кездесулерде барлығын жазып алатын бір адам болады, ең жақсы жағдайда ол талқылаудың 10% жазып алады. Менің әдісіммен бұл көрсеткішті шамамен 40% дейін көтеруге болады.
(Бұл суретті бөлек көруге болады )
Менің көзқарасым Уильям Шнайдердің жұмысына негізделген. ). Бұл тәсіл кез келген ұйымды төрт шаршыға бөлуге болады деген идеяға негізделген. Мен үшін бұл схема әдетте ұйымды талдау кезінде пайда болатын жүздеген басқа схемалармен жұмыс істеудің нәтижесі болып табылады. Бізде бақылау деңгейі жоғары, бірақ құзыреттілігі төмен ұйым бар делік. Бұл өте қолайсыз нұсқа: бәрі сызыққа барғанда, бірақ ешкім не істеу керектігін білмейді.
Сәл жақсырақ нұсқа - бақылаудың да, құзыреттің де жоғары деңгейі бар нұсқа. Егер мұндай компания пайдалы болса, онда оған DevOps қажет емес шығар. Бақылау деңгейі жоғары, құзыреттілігі мен ынтымақтастығы төмен, бірақ сонымен бірге мәдениеті (өсіру) жоғары компаниямен жұмыс істеу ең қызықты. Демек, кәсіпорында жұмыс істеуді ұнататындар көп және еңбек айналымы төмен.
(Бұл суретті бөлек көруге болады )
Менің ойымша, қатаң нұсқаулары бар әдістер шындыққа жету жолында кедергі жасайды. Атап айтқанда, мәндер ағынын салыстыруда ақпараттың құрылымына қатысты көптеген ережелер бар. Мен қазір айтып отырған жұмыстың бастапқы кезеңдерінде бұл ережелер ешкімге қажет емес. Егер қолында маркер бар адам тақтада компаниядағы нақты жағдайды сипаттайтын болса, бұл жағдайды түсінудің ең жақсы жолы. Мұндай ақпарат директорларға жетпейді. Осы сәтте адамның сөзін бөліп, жебенің бір түрін қате тартты деп айту ақымақтық. Бұл кезеңде қарапайым ережелерді қолданған дұрыс, мысалы: көп деңгейлі абстракцияны көп түсті маркерлерді қолдану арқылы ғана жасауға болады.
Қайталап айтамын, жоғары технология жоқ. Қара маркер бәрі қалай жұмыс істейтіні туралы объективті шындықты бейнелейді. Қызыл маркермен адамдар қазіргі жағдайдың өздеріне ұнамайтынын белгілейді. Мұны мен емес, олардың жазғаны маңызды. Кездесуден кейін CIO-ға барғанда, мен түзетуді қажет ететін 10 нәрсенің тізімін ұсынбаймын. Мен компаниядағы адамдардың айтқандары мен бұрыннан бар дәлелденген үлгілер арасындағы байланыстарды табуға тырысамын. Соңында, көк маркер мәселенің ықтимал шешімдерін ұсынады.
(Бұл суретті бөлек көруге болады )
Бұл тәсілдің мысалы қазір жоғарыда сипатталған. Осы жылдың басында мен бір банкпен жұмыс істедім. Ондағы қауіпсіздік қызметкерлері дизайнға және талаптарға шолу жасауға келмеуі керек екеніне сенімді болды.
(Бұл суретті бөлек көруге болады )
Содан кейін біз басқа бөлімшелердің адамдарымен сөйлестік және шамамен 8 жыл бұрын бағдарламалық жасақтаманы әзірлеушілер жұмысты баяулатып жатқан қауіпсіздік қызметкерлерін жұмыстан шығарғаны белгілі болды. Содан кейін ол тыйымға айналды, бұл әдеттегідей қабылданады. Шындығында ешқандай тыйым болмағанымен.
Біздің кездесуіміз өте түсініксіз түрде өтті: шамамен үш сағат бойы бес түрлі команда маған кодекс пен жиналыс арасында не болып жатқанын түсіндіре алмады. Және бұл ең қарапайым нәрсе болып көрінеді. DevOps кеңесшілерінің көпшілігі мұны бәрі біледі деп есептейді.
Содан төрт сағат бойы үнсіз отырған IT-басқаруға жауапты адам біз оның тақырыбына жеткенде кенет өмірге келіп, бізді өте ұзақ уақыт мазалап жүрді. Соңында мен одан кездесу туралы не ойлайтынын сұрадым және оның жауабын ешқашан ұмытпаймын. Ол былай деді: «Мен біздің банкте бағдарламалық қамтамасыз етуді жеткізудің тек екі жолы бар деп ойлайтынмын, бірақ қазір олардың бесеуі бар екенін білемін, мен үшеуі туралы тіпті білмедім».
(Бұл суретті бөлек көруге болады )
Бұл банктегі соңғы кездесу инвестициялық бағдарламалық жасақтама командасымен болды. Онымен бірге қағаз парағына маркермен диаграмма жазу тақтаға қарағанда жақсырақ, тіпті смарт тақтаға қарағанда жақсырақ екені анықталды.
Сіз көріп отырған фотосуреттер біздің кездесудің төртінші күнінде қонақүйдің конференц-залының көрінісі. Ал біз бұл схемаларды үлгілерді, яғни архетиптерді іздеу үшін пайдаландық.
Сонымен, мен жұмысшыларға сұрақтар қоямын, олар жауаптарын үш түсті маркерлермен (қара, қызыл, көк) жазады. Мен олардың жауаптарын архетиптерге талдаймын. Енді барлық архетиптерді ретімен талқылайық.
1. Барлық жұмысты көрінетін ету: жұмысты көрінетін ету
Мен жұмыс істейтін компаниялардың көпшілігінде белгісіз жұмыстардың өте жоғары пайызы бар. Мысалы, бұл бір қызметкер екіншісіне келіп, жай ғана бірдеңе істеуді сұрайды. Ірі ұйымдарда 60% жоспардан тыс жұмыс болуы мүмкін. Ал жұмыстың 40 пайызға дейіні ешқандай құжатталмаған. Егер бұл Boeing болса, мен өмірімде ешқашан олардың ұшағына отырмас едім. Жұмыстың жартысы ғана құжатталған болса, бұл жұмыс дұрыс орындалып жатыр ма, жоқ па белгісіз. Барлық басқа әдістер пайдасыз болып шығады - ештеңені автоматтандыруға тырысудың қажеті жоқ, өйткені белгілі 50% жұмыстың ең үйлесімді және анық бөлігі болуы мүмкін, оны автоматтандыру үлкен нәтиже бермейді, ал ең нашар. заттар көрінбейтін жартысында. Құжаттама болмаған жағдайда, мен айтқан «Бренттерді» табу емес, әртүрлі бұзулар мен жасырын жұмыстарды табу мүмкін емес. Доминика ДеГрандистің тамаша кітабы бар . Ол ашады бес түрлі «уақыттың ағуы» (уақыт ұрылары):
- Процесстегі тым көп жұмыс (WIP)
- Белгісіз тәуелділіктер
- Жоспарланбаған жұмыс
- Қайшылықты басымдықтар
- Елеусіз жұмыс
Бұл өте құнды талдау және кітап тамаша, бірақ деректердің тек 50% ғана көрінетін болса, бұл кеңестердің бәрі пайдасыз. Доминика ұсынған әдістер 90%-дан жоғары дәлдікке қол жеткізілген жағдайда қолданылуы мүмкін. Мен бастық бағынушыға 15 минуттық тапсырма беретін, бірақ оған үш күн кететін жағдайларды айтып отырмын; бірақ бұл бағыныштының төрт-бес адамға тәуелді екенін бастық шынымен де білмейді.
Феникс жобасы - бұл үш жыл кешіктірілген жоба туралы тамаша оқиға. Кейіпкерлердің бірі осыған байланысты жұмыстан босатылады және ол Сократтың бір түрі ретінде ұсынылған басқа кейіпкермен кездеседі. Ол ненің дұрыс емес екенін анықтауға көмектеседі. Компанияда бір жүйелік әкімші бар екен, оның аты Brent және барлық жұмыс әйтеуір сол арқылы өтеді. Жиналыстардың бірінде бағыныштылардың біріне сұрақ қойылады: неге әрбір жарты сағаттық тапсырма бір аптаға созылады? Жауап кезек теориясының және Литтл заңының өте жеңілдетілген презентациясы болып табылады және бұл презентацияда 90% толтыру кезінде әрбір жұмыс сағаты 9 сағатты алады. Әрбір тапсырманы жеті басқа адамға жіберу керек, осылайша бұл сағат 63 сағат, 7 есе 9 болады. Менің айтайын дегенім, Кіші заңын немесе кез келген күрделі кезек теориясын пайдалану үшін, кем дегенде, деректер болуы керек.
Сондықтан мен көріну туралы айтатын болсам, мен бәрі экранда екенін білдірмеймін, бірақ сізде кем дегенде деректер бар. Олар жасаған кезде, қажет болмаған кезде Brent-ке қандай да бір жолмен жіберілетін жоспардан тыс жұмыстардың өте үлкен көлемі жиі кездеседі. Ал Брент керемет жігіт, ол ешқашан жоқ деп айтпайды, бірақ ол өз жұмысын қалай істейтінін ешкімге айтпайды.
Жұмыс көрініп тұрғанда, деректерді ұқыпты түрде жіктеуге болады (фотода Доминика осылай істеп жатыр), бес уақыт ағып кетуінің абстракциясын қолдануға болады және автоматтандыруды қолдануға болады.
2. Жұмысты басқару жүйелерін біріктіру: Тапсырмаларды басқару
Мен айтып отырған архетиптер пирамиданың бір түрі. Біріншісі дұрыс жасалса, екіншісі қазірдің өзінде қосымшаның бір түрі болып табылады. Бұлардың көпшілігі стартаптар үшін жұмыс істемейді, оларды Fortune 5000 сияқты ірі компаниялар үшін есте ұстау керек. Мен жұмыс істеген соңғы компанияда 10 билет жүйесі болды. Бір командада Remedy болды, екіншісі өз жүйесінің қандай да бір түрін жазды, үшіншісі Jira-ны пайдаланды, ал кейбіреулері электрондық поштамен айналысты. Егер компанияда 30 түрлі құбыр болса, дәл осындай мәселе туындайды, бірақ менде мұндай жағдайлардың барлығын талқылауға уақытым жоқ.
Мен адамдармен билеттер қалай жасалатынын, олармен не болатынын және оларды қалай айналып өтетінін талқылаймын. Ең қызығы, біздің басқосулардағы адамдар шын жүректен сөйлейді. Мен қанша адам билеттерге «шамамен / әсер етпеді» деп сұрадым, олар шын мәнінде «үлкен әсер» берілуі керек. Мұны барлығы дерлік жасайтыны белгілі болды. Мен айыптаумен айналыспаймын және адамдарды анықтауға тырыспаймын. Егер олар маған шын жүректен бірдеңе мойындаса, мен оны бермеймін. Бірақ барлығы дерлік жүйені айналып өткенде, бұл барлық қауіпсіздік шын мәнінде терезені безендіру екенін білдіреді. Сондықтан бұл жүйенің деректерінен ешқандай қорытынды шығаруға болмайды.
Билет мәселесін шешу үшін бір негізгі жүйені таңдау керек. Jira пайдалансаңыз, оны Jira сақтаңыз. Қандай да бір балама болса, жалғыз болсын. Қорытындысы, билеттерді әзірлеу үдерісіндегі тағы бір қадам ретінде қарастыру керек. Әрбір әрекетте әзірлеу жұмыс процесі арқылы өтуі тиіс билет болуы керек. Билеттер командаға жіберіледі, олар оларды сюжеттер тақтасында орналастырады, содан кейін олар үшін жауапкершілік алады.
Бұл барлық бөлімдерге, соның ішінде инфрақұрылым мен операцияларға қатысты. Бұл жағдайда, кем дегенде, істің жай-күйі туралы ақылға қонымды идеяны қалыптастыруға болады. Бұл процесс орнатылғаннан кейін кенеттен әрбір қолданбаға кім жауапты екенін анықтау оңай болады. Өйткені қазір біз жаңа қызметтердің 50 пайызын емес, 98 пайызын аламыз. Бұл негізгі процесс жұмыс істесе, дәлдік бүкіл жүйеде жақсарады.
Қызметтер құбыры
Бұл тағы да тек ірі корпорацияларға қатысты. Егер сіз жаңа саладағы жаңа компания болсаңыз, жеңдеріңізді жинап, Travis CI немесе CircleCI-мен жұмыс жасаңыз. Fortune 5000 компанияларына келетін болсақ, мен жұмыс істеген банкте болған жағдай. Оларға Google келді және оларға ескі IBM жүйелерінің диаграммалары көрсетілді. Google жігіттері абдырап сұрады - бұл үшін бастапқы код қайда? Бірақ бастапқы код, тіпті GUI де жоқ. Бұл үлкен ұйымдармен күресуге тура келетін шындық: 40-жылдық банк жазбалары ежелгі негізгі фреймде. Менің клиенттерімнің бірі Circuit Breaker үлгілері бар Kubernetes контейнерлерін, сонымен қатар Chaos Monkey, барлығы KeyBank қолданбасы үшін пайдаланады. Бірақ бұл контейнерлер ақыр соңында COBOL қолданбасына қосылады.
Google жігіттері менің клиентімнің барлық мәселелерін шешетініне толық сенімді болды, содан кейін олар сұрақтар қоя бастады: IBM datapipe дегеніміз не? Оларға айтады: бұл қосқыш. Ол немен байланысты? Sperry жүйесіне. Ал бұл не? Тағыда басқа. Бір қарағанда: қандай DevOps болуы мүмкін? Бірақ іс жүзінде бұл мүмкін. Жұмыс процесін жеткізу топтарына беруге мүмкіндік беретін жеткізу жүйелері бар.
3. Шектеу теориясы: Шектеу теориясы
Үшінші архетипке көшейік: институционалдық/"тайпалық" білім. Әдетте, кез келген ұйымда бәрін білетін және бәрін басқаратын бірнеше адам болады. Бұл ұйымда ең ұзақ болған және барлық шешімдерді білетін адамдар.
Бұл диаграммада пайда болған кезде, мен мұндай адамдарды маркермен арнайы дөңгелектеймін: мысалы, барлық жиналыстарда белгілі бір Лу бар екен. Маған түсінікті: бұл жергілікті Брент. CIO футболка мен кроссовкадағы мен мен костюм киген IBM жігітін таңдағанда, мен директорға басқа жігіт айтпайтын және директордың естігісі келмейтін нәрселерді айта аламын. . Мен оларға компаниядағы тығырықтың Фред және Лу есімді біреу екенін айтамын. Бұл тығырықты ашу керек, олардың білімін олардан бір жолмен алу керек.
Мұндай мәселені шешу үшін, мысалы, Slack пайдалануды ұсына аламын. Ақылды директор сұрайды - неге? Әдетте, мұндай жағдайларда DevOps кеңесшілері жауап береді: өйткені бәрі мұны істейді. Егер директор шынымен ақылды болса: сонда не болады. Міне, диалог аяқталады. Бұған менің жауабым: өйткені компанияда Фред, Лу, Сюзи және Джейн деген төрт кедергі бар. Олардың білімін институттандыру үшін алдымен Slack енгізу керек. Сіздің барлық викилеріңіз мүлдем нонсенс, өйткені олардың бар екенін ешкім білмейді. Егер инженерлік топ фронт-end және back-end әзірлеуге қатысатын болса және барлығы сұрақтар бойынша фронт-end әзірлеу тобына немесе инфрақұрылым тобына хабарласа алатынын білуі керек. Сол кезде Лу немесе Фредтің викиге қосылуға уақыты болуы мүмкін. Содан кейін Slack қолданбасында біреу 5-қадам неге жұмыс істемей тұрғанын сұрауы мүмкін. Содан кейін Лу немесе Фред викидегі нұсқауларды түзетеді. Егер сіз осы процесті орнатсаңыз, онда көп нәрсе өздігінен орын алады.
Бұл менің негізгі ойым: кез келген жоғары технологияларды ұсыну үшін алдымен олардың негізін ретке келтіру керек және мұны жоғарыда сипатталған төмен технологиялық шешімдер арқылы жасауға болады. Егер сіз жоғары технологиялардан бастасаңыз және олардың не үшін қажет екенін түсіндірмесеңіз, онда, әдетте, бұл жақсы аяқталмайды. Біздің клиенттеріміздің бірі өте арзан және қарапайым шешім Azure ML пайдаланады. Олардың сұрақтарының 30%-ға жуығына өзін-өзі оқыту аппаратының өзі жауап берді. Және бұл нәрсені деректер ғылымымен, статистикамен немесе математикамен айналыспаған операторлар жазған. Бұл маңызды. Мұндай шешімнің құны минималды.
4. Ынтымақтастықты бұзу: Бірлескен әрекетті бұзу
Төртінші архетип - оқшауланумен күресу қажеттілігі. Көптеген адамдар мұны қазірдің өзінде біледі: оқшаулану дұшпандық тудырады. Егер әр бөлім өз қабатында болса және адамдар лифттен басқа ешқандай жолмен бір-бірімен қиылыспаса, олардың арасындағы дұшпандық өте оңай туындайды. Бірақ, керісінше, адамдар бір-бірімен бір бөлмеде болса, ол бірден кетеді. Біреу жалпы айыптауды тастаған кезде, мысалы, мұндай интерфейс ешқашан жұмыс істемейді, мұндай айыптауды деконструкциялау оңайырақ ештеңе жоқ. Интерфейсті жазған бағдарламашылар нақты сұрақтар қоя бастауы керек, және көп ұзамай, мысалы, пайдаланушы құралды дұрыс пайдаланбағаны белгілі болады.
Оқшаулануды жеңудің көптеген жолдары бар. Бірде маған Австралиядағы банкке кеңес беруді өтінді, бірақ мен одан бас тарттым, өйткені менің екі балам мен әйелім бар. Мен оларға көмектесу үшін қолымнан келгеннің бәрі графикалық әңгімелерді ұсыну болды. Бұл жұмыс істейтіні дәлелденген нәрсе. Тағы бір қызықты әдіс - майсыз кофе кездесулері. Үлкен ұйымда бұл білімді таратудың тамаша нұсқасы. Сонымен қатар, сіз ішкі девопсдейлерді, хакатондарды және т.б.
5. Коучинг Ката
Басында ескерткенімдей, мен бүгін бұл туралы айтпаймын. Егер сізді қызықтырса, қарап шығуға болады .
Майк Ротердің осы тақырыпта жақсы әңгімесі бар:
6. Нарыққа бағдарланған: нарыққа бағытталған ұйым
Мұнда әртүрлі мәселелер бар. Мысалы, «Мен» адамдары, «Т» адамдары және «Е» адамдары. «Мен» адамдар – бір ғана нәрсені істейтін адамдар. Әдетте олар оқшауланған бөлімшелері бар ұйымдарда болады. «Т» - бұл адамның бір нәрседе жақсы, бірақ басқа нәрселерде де жақсы болуы. «Е» немесе тіпті «тарақ» - адамның көптеген дағдылары болған кезде.
Мұнда Конуэй заңы жұмыс істейді (), оны барынша жеңілдетілген түрде келесідей айтуға болады: егер компиляторда үш команда жұмыс істесе, онда нәтиже үш бөліктен тұратын компилятор болады. Сондықтан, егер ұйымда оқшауланудың жоғары деңгейі болса, онда бұл ұйымдағы Kubernetes, автоматты ажыратқыш, API кеңейтімі және басқа да сәнді нәрселер ұйымның өзі сияқты реттеледі. Қатаң Конуэйге сәйкес және барлық жас гектерге ренжіу үшін.
Бұл мәселенің шешімі бірнеше рет сипатталған. Мысалы, Фернандо Фернандес сипаттаған ұйымдық архетиптер бар. Мен жаңа ғана айтқан проблемалық архитектура оқшауланған, функцияға бағытталған архитектура. Екінші түрі - ең нашар, матрицалық архитектура, қалған екеуінің шатастырылуы. Үшіншісі - стартаптардың көпшілігінде кездесетін нәрсе және ірі компаниялар да осы түрге сәйкес келуге тырысады. Бұл нарыққа бағытталған ұйым. Мұнда біз тұтынушылардың сұраныстарына ең жылдам жауап беру үшін оңтайландырамыз. Мұны кейде жалпақ ұйым деп те атайды.
Көптеген адамдар бұл құрылымды әртүрлі тәсілдермен сипаттайды, маған тұжырымы ұнайды командаларды құру/жүргізу, Amazon-да олар оны атайды екі пицца командасы. Бұл құрылымда барлық «I» типті адамдар бір қызмет төңірегінде топтастырылып, бірте-бірте олар «Т» типіне жақындай түседі, егер дұрыс менеджмент орын алса, тіпті «Е» болуы мүмкін. Мұндағы бірінші қарсы аргумент - мұндай құрылымның қажетсіз элементтері бар. Арнайы тестерлер бөлімі бола алатын болса, әр бөлімге тестілеуші не үшін қажет? Мен жауап беремін: бұл жағдайда қосымша шығындар бүкіл ұйымның болашақта «Е» түріне айналуы үшін баға болып табылады. Бұл құрылымда тестілеуші бірте-бірте желілерді, архитектураны, дизайнды және т.б. Нәтижесінде ұйымның әрбір қатысушысы ұйымда болып жатқан барлық нәрселерден толық хабардар болады. Бұл схема өнеркәсіпте қалай жұмыс істейтінін білгіңіз келсе, оқыңыз .
7. Ауысымның сол жақ аудиторлары: циклдің басында аудит. Көрмеде қауіпсіздік ережелерін сақтау
Бұл сіздің әрекеттеріңіз, былайша айтқанда, иіс сынағынан өтпейді. Сіз үшін жұмыс істейтін адамдар ақымақ емес. Егер жоғарыдағы мысалдағыдай олар барлық жерде шамалы/жоқ әсер етпесе, бұл үш жылға созылды және ешкім ештеңе байқамаса, жүйе жұмыс істемейтінін бәрі жақсы біледі. Немесе басқа мысал - өзгерістер бойынша консультативтік кеңес, онда есептер әр сәрсенбіде ұсынылуы керек. Онда жұмыс істейтін адамдар тобы бар (айтпақшы, жалақысы онша емес), олар теориялық тұрғыдан алғанда жүйенің қалай жұмыс істейтінін білуі керек. Соңғы бес жылда сіз біздің жүйелеріміздің керемет күрделі екенін байқаған боларсыз. Ал бес-алты адам өзі жасамаған және ештеңе білмейтін өзгеріс туралы шешім қабылдауы керек.
Әрине, бұл әдіс жұмыс істемейді. Мен мұндай нәрселерден құтылуым керек, өйткені бұл адамдар жүйені қорғамайды. Шешімді команда өзі қабылдауы керек, өйткені оған команда жауапты болуы керек. Әйтпесе, өмірінде ешқашан код жазбаған менеджер бағдарламашыға кодты жазу үшін қанша уақыт қажет екенін айтқан кезде парадоксалды жағдай туындайды. Мен жұмыс істеген бір компанияда әрбір өзгерісті қарастыратын 7 түрлі кеңестер болды, соның ішінде архитектуралық тақта, өнім тақтасы және т.б. Тіпті міндетті күту кезеңі болды, дегенмен бір қызметкер он жыл жұмыс істегенде, осы міндетті мерзімде бұл адам жасаған өзгертуден ешқашан бас тартпағанын айтты.
Аудиторларды олардан құтылмай, бізге қосылуға шақыру керек. Оларға өзгермейтін екілік контейнерлерді жазатыныңызды айтыңыз, егер олар барлық сынақтардан өтсе, мәңгілік өзгермейтін болып қалады. Сізде код ретінде құбыр бар екенін айтыңыз және бұл нені білдіретінін түсіндіріңіз. Оларға келесі схеманы көрсетіңіз: барлық осалдық сынақтарынан өтетін контейнердегі өзгермейтін тек оқуға арналған екілік; содан кейін оған ешкім тиіп қана қоймайды, олар құбырды жасайтын жүйеге де қол тигізбейді, өйткені ол динамикалық түрде жасалады. Менің Capital One клиенттерім бар, олар блокчейн сияқты нәрсені жасау үшін Vault-ты пайдаланады. Аудиторға аспазшыдан «рецепттерді» көрсетудің қажеті жоқ, өндірісте Jira билетімен не болғаны және оған кім жауапты екені анық болатын блокчейнді көрсету жеткілікті.
бойынша , 2018 жылы Sonatype жасаған, 2017 жылы 87 миллиард OSS жүктеу сұрауы болды.
Осалдықтарға байланысты келтірілген шығындар өте жоғары. Оның үстіне, қазір жоғарыда көріп отырған сандар мүмкіндік шығындарды қамтымайды. Қысқаша айтқанда DevSecOps дегеніміз не? Бірден айта кетейін, бұл атаудың қаншалықты сәтті болғаны туралы айту маған қызық емес. Мәселе мынада, DevOps өте сәтті болғандықтан, біз бұл құбырға қауіпсіздікті қосуға тырысуымыз керек.
Бұл тізбектің мысалы:
Бұл нақты өнімдерге арналған ұсыныс емес, бірақ маған олардың барлығы ұнайды. Бастапқыда саладағы ұйымдастыру парадигмасына негізделген DevOps өнімдегі жұмыстың әрбір кезеңін автоматтандыруға мүмкіндік беретінін көрсету үшін мен оларды мысал ретінде келтірдім.
Қауіпсіздікке де дәл осындай көзқарасты ұстана алмауымызға еш себеп жоқ.
Нәтиже
Қорытынды ретінде мен DevSecOps үшін кейбір кеңестер беремін. Жүйелерді құру процесіне аудиторларды қосып, оларды оқытуға уақыт бөлу керек. Аудиторлармен жұмыс істеу керек. Әрі қарай, сіз жалған позитивтерге қарсы мүлдем аяусыз күресуіңіз керек. Тіпті ең қымбат осалдықты сканерлеу құралымен, сигнал-шуыл арақатынасы қандай екенін білмесеңіз, әзірлеушілер арасында өте жаман әдеттер тудыруы мүмкін. Әзірлеушілер оқиғаларға толы болады және оларды жай ғана жояды. Егер сіз Equifax оқиғасы туралы естіген болсаңыз, бұл жерде ең жоғары ескерту деңгейі еленбейтін оқиға болды. Бұған қоса, осалдықтарды олардың бизнеске қалай әсер ететінін түсіндіретін етіп түсіндіру қажет. Мысалы, бұл Equifax оқиғасындағыдай осалдық деп айта аласыз. Қауіпсіздік осалдықтары басқа бағдарламалық қамтамасыз ету мәселелерімен бірдей қарастырылуы керек, яғни олар жалпы DevOps процесіне қосылуы керек. Сіз олармен Jira, Kanban және т.б. арқылы жұмыс істеуіңіз керек. Әзірлеушілер мұны басқа біреу жасайды деп ойламауы керек - керісінше, мұны бәрі істеу керек. Ақырында, адамдарды оқытуға күш жұмсау керек.
Пайдалы сілтемелер
DevOops конференциясының сізге пайдалы болуы мүмкін бірнеше баяндамасы:
- Сергей Бердников, Артём Каличкин - Сәттілік тарихы немесе «Dev+DevOps+Ops» (, )
- Барух Садогурский, Леонид Игольник - масштабтағы DevOps: үш актідегі грек трагедиясы (, )
- Александр Титов, Кирилл Толкачев -
- Тимоти Листер -
Мұнымен танысыңыз DevOops 2020 Мәскеу — Онда да қызық дүниелер көп.
Ақпарат көзі: www.habr.com