«DevOps-ті қалай енгізу керек» деген сұрақ көп жылдар бойы болды, бірақ жақсы материал көп емес. Кейде сіз өз уақытын қалай болса да сатуды қажет ететін сауатты емес кеңесшілердің айыбының құрбаны боласыз. Кейде бұл мега-корпорациялардың ғарыш кеңістігін қалай жүзетіні туралы бұлыңғыр, тым жалпы мәлімдемелер. Сұрақ туындайды: бұл бізге не береді? Құрметті автор, сіз өз идеяларыңызды тізімде нақты жеткізе аласыз ба?
Мұның бәрі компанияның мәдени өзгерістерінің нәтижелерін түсінудің және нақты тәжірибенің аздығынан туындайды. Мәдени өзгерістер - бұл ұзақ мерзімді процесс, оның нәтижесі бір аптада немесе бір айда білінбейді. Бізге жеткілікті тәжірибесі бар, компаниялардың жылдар бойы көтеріліп, құлдырауын көрген адам керек.
Джон Уиллис Джон - DevOps әкелерінің бірі. Джонның көптеген компаниялармен жұмыс істеген ондаған жылдық тәжірибесі бар. Соңғы уақытта ол олардың әрқайсысымен жұмысында пайда болатын нақты заңдылықтарды байқай бастады. Осы архетиптерді пайдалана отырып, Джон компанияларды DevOps трансформациясының шынайы жолына бағыттайды. Оның DevOops 2018 конференциясындағы баяндамасының аудармасынан осы архетиптер туралы көбірек біліңіз.
Спикер туралы:
IT-менеджментінде 35 жылдан астам уақыт бойы ол Canonical-те OpenCloud предшественнигін құруға көмектесті және 10 стартапта жұмыс істеді, оның ішінде екеуі Dell және Docker-ке сатты. Қазіргі уақытта ол SJ Technologies компаниясының DevOps және Digital Practices вице-президенті.
Төменде Джонның көзқарасы бойынша айтылған оқиға берілген.
Менің атым Джон Уиллис, мен Twitter-де ең жақсы табылдым, Менің Gmail және GitHub-да бірдей лақап атым бар. Сіз менің есептерімнің бейне жазбаларын және оларға арналған презентацияларды таба аласыз.
Мен әртүрлі ірі компанияларда CIO-лармен көптеген кездесулер өткіземін. Олар DevOps-ті түсінбейтініне жиі шағымданады және оларға түсіндіруге тырысатындардың бәрі мүлдем басқа нәрсе туралы айтады. Тағы бір жиі кездесетін шағым - директорлар түсіндірілгендей бәрін істеп жатқан сияқты болса да, DevOps жұмыс істемейді. Бұл жүз жылдан асқан ірі компаниялар. Олармен сөйлескеннен кейін мен көптеген мәселелерді жоғары технологиялық шешімдер емес, салыстырмалы түрде төмен технологиялық шешімдер жақсы шешеді деген қорытындыға келдім. Мен бірнеше апта бойы әртүрлі бөлімдердің адамдарымен сөйлестім. Осы посттағы ең бірінші суретте көріп тұрғандарыңыз менің ең соңғы жобам; Үш күн жұмыс істегеннен кейін бөлме осылай болды.
DevOps дегеніміз не?
Шынында да, 10 түрлі адамнан сұрасаңыз, олар 10 түрлі жауап береді. Бірақ бір қызығы, сол жауаптардың барлығы да дұрыс болады. Қате жауап жоқ. Мен шамамен 10 жыл бойы DevOps-пен өте терең айналыстым және бірінші DevOps күніне қатысқан алғашқы американдық болдым. Мен DevOps-тегі басқаларға қарағанда ақылдымын деп айтпас едім, бірақ оған ешкім көп күш салғанына күмәнім бар. Менің ойымша, DevOps адами капитал мен технология біріктірілген кезде пайда болады. Біз әр түрлі мәдениеттер туралы көп айтсақ та, адами өлшемді ұмытып кетеміз.
Қазір бізде көптеген деректер, бес жылдық академиялық зерттеулер және өнеркәсіптік ауқымда сыналған теориялар бар. Бұл зерттеу бізге мынаны айтады: егер белгілі бір мінез-құлық үлгілері ұйымдық мәдениетте біріктірілсе, сіз 2000 есе жылдамдатуға қол жеткізе аласыз. Бұл жеделдету тұрақтылықтың ұқсас жақсаруына сәйкес келеді. Бұл DevOps кез келген компанияға әкелетін пайданың сандық өлшемі. Бірнеше жыл бұрын мен Fortune 5000 компаниясының бас директорына DevOps ұсынған болатынмын. Тұсаукесерді дайындап жатқанда мен қатты қобалжыдым, өйткені көп жылғы тәжірибемді бес минутта қорытындылауым керек болды.
Соңында мен мынаны бердім DevOps анықтамасы: Бұл адами капиталды жоғары өнімді ұйымдық капиталға айналдыруға мүмкіндік беретін тәжірибелер мен үлгілердің жиынтығы. Мысалы, Toyota соңғы 50 немесе 60 жылда қалай жұмыс істеді.
(Осыдан бастап мұндай диаграммалар анықтамалық материал ретінде емес, иллюстрация ретінде беріледі. Олардың мазмұны әрбір жаңа компания үшін әр түрлі болады. Дегенмен суретті бөлек көруге және үлкейтуге болады.
Осы тәжірибелердің ішіндегі ең сәттісі құнды ағынды салыстыруБұл тақырып бойынша бірнеше жақсы кітаптар бар, олардың ең сәттісі Карен Мартин. Бірақ соңғы бір жылда мен бұл тәсілдің өзі тым жоғары технологиялық деген қорытындыға келдім. Әрине, оның көптеген артықшылықтары бар, мен оны кеңінен қолдандым. Бірақ бас директор сізден олардың компаниясы неге жаңа тәсілге ауыса алмайтынын сұрағанда, құн ағынын салыстыру туралы айту әлі ерте. Алдымен жауап беруді қажет ететін көптеген іргелі сұрақтар бар.
Менің ойымша, көптеген әріптестерім компанияға бес тармақтан тұратын нұсқаулық беріп, содан кейін не болғанын көру үшін алты айдан кейін оралу арқылы қателеседі. Тіпті құн ағынын салыстыру сияқты жақсы құрылымның, былайша айтқанда, соқыр нүктелері бар. Әртүрлі компаниялардың директорларымен жүздеген сұхбаттардан кейін мен мәселені оның құрамдас бөліктеріне бөлуге мүмкіндік беретін нақты үлгіні әзірледім, енді осы құрамдастардың әрқайсысын кезекпен талқылайтын боламыз. Кез келген технологиялық шешімдерді жүзеге асырмас бұрын, мен осы үлгіні қолданамын, нәтижесінде менің қабырғаларым диаграммалармен жабылған. Жақында мен пай қорымен жұмыс істеп, 100-150 осындай диаграммамен аяқтадым.
Нашар мәдениет таңғы асқа жақсы тәсілдерді жейді
Түпнұсқа мынада: ұйым мәдениеті нашар болса, Lean, Agile, SAFE немесе DevOps бағдарламасы көмектеспейді. Бұл аквалангсыз сүңгуір немесе рентгенсіз операция сияқты. Басқаша айтқанда, Друкер мен Демингті қайталап айтсақ: нашар ұйымдық мәдениет кез келген жақсы жүйені тұншықтырмай жұтып қояды.
Бұл негізгі мәселені шешу үшін келесі қадамдарды орындау қажет:
- Барлық жұмыстарды көрінетін ету: Барлық жұмыс көрінетін болуы керек. Ол қандай да бір экранда көрсетілуі керек деген мағынада емес, оны байқауға болатын мағынада.
- Жұмысты басқарудың шоғырландырылған жүйелері: Басқару жүйелерін шоғырландыру қажет. «Рулық» білім мен институционалдық білім мәселесінде 10 жағдайдың 9-ында адамдар тар жол болып табылады. Кітапта Мәселе жобаны үш жылға кейінге қалдырған жалғыз адам Брент болды. Мен барлық жерде осындай «Бренттерге» тап боламын. Осы кедергілерді шешу үшін мен тізімдегі келесі екі тармақты қолданамын.
- Шектеу теориясының әдістемесі: Шектеу теориясы.
- Ынтымақтастық хакерлері: ынтымақтастық хакерлері.
- Toyota Kata (): Мен Toyota Kata туралы көп айтпаймын. Егер сізді қызықтырса, бұл менің GitHub-да. осы тақырыптардың әрқайсысында дерлік.
- Нарыққа бағытталған ұйым: нарыққа бағытталған ұйым.
- Солға ауысатын аудиторлар: циклдің ерте кезеңдеріндегі аудит.
Мен ұйыммен жұмысты өте қарапайым бастаймын: мен компанияға барып, қызметкерлермен сөйлесемін. Көріп отырғаныңыздай, мұнда жоғары технология жоқ. Сізге тек жазу керек нәрсе. Мен бірнеше команданы бір бөлмеге жинап, олардың маған айтқан сөздерін менің жеті архетипім бойынша талдаймын. Содан кейін мен оларға маркер беремін және олардың осы уақытқа дейін дауыстап айтқандарының бәрін тақтаға жазуды сұраймын. Әдетте, мұндай кездесулерде бір адам жазып алады және ең жақсы жағдайда олар талқылаудың 10% жинай алады. Менің әдісіммен бұл көрсеткішті шамамен 40% дейін көтеруге болады.
(Бұл суретті бөлек көруге болады )
Менің көзқарасым Уильям Шнайдердің жұмысына негізделген (Уильям Шнайдер, ). Тәсіл кез келген ұйымды төрт квадрантқа бөлуге болады деген идеяға негізделген. Мен үшін бұл диаграмма әдетте ұйымды талдау кезінде пайда болатын жүздеген басқа диаграммалармен жұмыс істеудің нәтижесі болып табылады. Бізде бақылау деңгейі жоғары, бірақ құзыреті төмен ұйым бар делік. Бұл өте қолайсыз жағдай: бәрі шегелеп тұрған кезде, бірақ ешкім не істеу керектігін білмейді.
Сәл жақсырақ нұсқа - жоғары деңгейлі бақылау және құзыреттілік. Егер мұндай компания табысты болса, оған DevOps қажет болмауы мүмкін. Бірлескен жұмыс істеуге ең қызықты компаниялар – бұл бақылауы жоғары, құзыреттілігі мен ынтымақтастығы төмен, бірақ мәдениеті (өсіру) жоғары компаниялар. Бұл компанияда жұмыс істеуді ұнататын адамдар көп және айналым төмен дегенді білдіреді.
(Бұл суретті бөлек көруге болады )
Мен қатаң анықталған нұсқаулары бар әдістер ақыр соңында шындыққа жетуге кедергі келтіреді деп есептеймін. Құнды ағынды салыстыру, атап айтқанда, ақпаратты құрылымдау туралы көптеген ережелерге ие. Мен қазір айтып отырған жұмыстың бастапқы кезеңдерінде бұл ережелердің ешкімге пайдасы жоқ. Қолында маркері бар адам тақтада компанияның нақты жағдайын сызып тұрса, бұл жағдайды түсінудің ең жақсы жолы. Мұндай ақпарат басшыларға жетпейді. Осы кезде олардың сөзін бөліп, жебені дұрыс тартпағанын айту ақымақтық. Бұл кезеңде қарапайым ережелерді қолданған дұрыс, мысалы: көп деңгейлі абстракцияны әртүрлі түсті маркерлерді қолдану арқылы ғана жасауға болады.
Қайталап айтамын, мұнда жоғары технология жоқ. Заттардың қалай жұмыс істейтіні туралы объективті шындық қара маркерде бейнеленген. Адамдар қазіргі жағдайдың нені ұнатпайтынын көрсету үшін қызыл маркерді пайдаланады. Мұны мен емес, олардың жазғаны маңызды. Кездесуден кейін CIO-ға барғанда, мен түзетуді қажет ететін 10 нәрсенің тізімін ұсынбаймын. Мен компаниядағы адамдардың айтқандары мен бұрыннан бар дәлелденген үлгілер арасындағы байланыстарды табуға тырысамын. Соңында мәселенің ықтимал шешімдері көк маркермен ұсынылған.
(Бұл суретті бөлек көруге болады )
Бұл тәсілдің мысалы жоғарыда көрсетілген. Осы жылдың басында мен банкте жұмыс істедім. Қауіпсіздік департаменті олардың дизайн мен талаптарды тексеруге қатысуға рұқсат етілмегеніне сенімді болды.
(Бұл суретті бөлек көруге болады )
Одан кейін басқа бөлімшелердің адамдарымен сөйлестік, шамамен сегіз жыл бұрын бағдарламалық жасақтаманы әзірлеушілер жұмысты бәсеңдеткені үшін күзет қызметкерлерін жұмыстан шығарғаны белгілі болды. Содан кейін бұл әдеттегідей қабылданған тыйымға айналды. Шындығында, мүлде тыйым болған жоқ.
Біздің кездесуіміз керемет шатастырылды: шамамен үш сағат бойы бес түрлі команда маған код пен құрастыру арасында не болатынын түсіндіре алмады. Және бұл, меніңше, ең қарапайым нәрсе. DevOps кеңесшілерінің көпшілігі мұны бәрі біледі деп есептейді.
Содан кейін төрт сағат бойы үнсіз отырған ІТ басқаруға жауапты адам біз оның тақырыбына жеткенде кенет ашуланып, бізді біраз уақыт босата берді. Соңында мен одан кездесу туралы не ойлайтынын сұрадым, мен оның жауабын ешқашан ұмытпаймын. Ол: «Бұрын мен біздің банкте бағдарламалық қамтамасыз етуді жеткізудің екі жолы бар деп ойлайтынмын, бірақ қазір бесеуі бар екенін білемін, ал оның үшеуі туралы мен тіпті білмедім» деді.
(Бұл суретті бөлек көруге болады )
Менің осы банктегі соңғы кездесуім инвестициялық бағдарламалық жасақтамада жұмыс істейтін топпен болды. Олардың көмегімен мен маркермен қағаз парағына диаграмма жазу тақтаға қарағанда жақсырақ, тіпті смарт тақтаға қарағанда жақсырақ екенін білдім.
Сіз көріп отырған фотосуреттер біздің кездесудің төртінші күнінде қонақүйдің конференц-залының көрінісі. Біз бұл диаграммаларды үлгілерді немесе архетиптерді іздеу үшін қолдандық.
Сонымен, мен қызметкерлерге сұрақтар қоямын, олар жауаптарын маркерлермен үш түсті (қара, қызыл, көк) жазады. Мен олардың жауаптарын архетиптерге талдаймын. Енді әр архетипті кезекпен талқылайық.
1. Барлық жұмысты көрінетін ету: жұмысты көрінетін ету
Мен жұмыс істейтін компаниялардың көпшілігінде құжатсыз жұмыстың өте жоғары пайызы бар. Мысалы, бұл бір қызметкер екіншісіне келіп, олардан бірдеңе жасауды сұрайды. Ірі ұйымдарда жұмыстың 60% жоспардан тыс болуы мүмкін. Ал жұмыстың 40 пайызға дейіні мүлдем құжатсыз. Егер бұл Boeing болса, мен ешқашан олардың ұшағында ұшпас едім. Егер жұмыстың жартысы ғана құжатталған болса, оның дұрыс орындалғаны немесе орындалмағаны белгісіз. Барлық басқа әдістер пайдасыз болып шықты — ештеңені автоматтандыруға тырысудың қажеті жоқ, өйткені белгілі 50% жұмыстың ең оңтайландырылған және дәл бөлігі болуы мүмкін, оның автоматтандырылуы айтарлықтай нәтиже бермейді, ал ең нашарның бәрі құжатсыз жартысында жатыр. Құжаттамасыз әртүрлі бұзақылық пен жасырын жұмысты табу немесе мен жоғарыда айтқан «Бренттерді» табу мүмкін емес. Доминика ДеГрандистің тамаша кітабы бар Ол ашады бес түрлі «уақыттың ағуы» (уақыт ұрылары):
- Процесстегі тым көп жұмыс (WIP)
- Белгісіз тәуелділіктер
- Жоспарланбаған жұмыс
- Қайшылықты басымдықтар
- Елеусіз жұмыс
Бұл өте құнды талдау және кітап тамаша, бірақ бұл кеңестердің барлығы деректердің 50% ғана көрсеңіз, пайдасыз. Доминика әдістерін 90% жоғары дәлдікке қол жеткізген жағдайда ғана қолдануға болады. Мен бастық бағынушыға 15 минуттық тапсырма беретін жағдайларды айтып отырмын және оған үш күн кетеді; бірақ бастық бұл бағыныштының басқа төрт-бес адамға тәуелді екенін іс жүзінде білмейді.
Феникс жобасы - үш жылға кешігіп жатқан жоба туралы тамаша оқиға. Кейіпкерлердің бірі осыған байланысты жұмыстан босатылады және ол Сократтың бір түрі ретінде таныстырылған басқа кейіпкерді кездестіреді. Ол ненің дұрыс емес екенін анықтауға көмектеседі. Компанияның Брент атты жалғыз сисадмині бар және барлық жұмыс, бір жолмен, ол арқылы өтеді. Бір жиналыста бағыныштылардың біріне сұрақ қойылады: неге әрбір жарты сағаттық тапсырма бір аптаға созылады? Жауап - 90% пайдалану кезінде әрбір жұмыс сағаты тоғыз сағатты алатынын көрсететін кезек теориясы мен Кіші заңның өте жеңілдетілген түсіндірмесі. Әр тапсырманы жеті адамға жіберу керек, осылайша сағат 63 сағатқа, жеті есе тоғызға айналады. Менің ойымша, Кішкентай заңын немесе кез келген күрделі кезек теориясын пайдалану үшін сізде кем дегенде деректер болуы керек.
Сондықтан мен көріну туралы айтатын болсам, мен бәрі экранда болуы керек дегенді білдірмеймін, бірақ кем дегенде деректер сонда болуы керек. Бұл болған кезде, әдетте, мүлдем қажетсіз болса да, 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. Ынтымақтастықты бұзу: Ынтымақтастықты бұзу
Төртінші архетип - оқшауланумен күресу керек. Көптеген адамдар мұны қазірдің өзінде біледі: оқшаулану дұшпандық тудырады. Егер әрбір бөлім өз қабатында болса және адамдар лифттен басқа бір-бірімен араласпаса, олардың арасындағы дұшпандық өте оңай дамиды. Бірақ, керісінше, адамдар бір бөлмеде болса, ол бірден тарайды. Біреу жалпы айыптаған кезде, мысалы, мұндай интерфейс ешқашан жұмыс істемейді - оны деконструкциялау оңай. Интерфейсті жазған бағдарламашыларға нақты сұрақтар қоюды бастау керек және көп ұзамай, мысалы, пайдаланушы құралды дұрыс пайдаланбағаны белгілі болады.
Оқшаулануды жеңудің көптеген жолдары бар. Бірде маған Австралиядағы банкке кеңес беруді өтінді, бірақ мен бас тарттым, өйткені менің екі балам мен әйелім бар. Мен жасай алатын ең жақсы нәрсе графикалық әңгімелерді ұсыну болды. Бұл жұмыс істейтіні дәлелденген нәрсе. Тағы бір қызықты әдіс - майсыз кофе кездесулері. Үлкен ұйымда бұл білімді таратудың тамаша тәсілі. Сондай-ақ ішкі DevOpsDays, хакатон және т.б. өткізуге болады.
5. Коучинг Ката
Басында айтқанымдай, мен бұл туралы бүгін айтпаймын. Егер сізді қызықтырса, оны көруге болады. .
Майк Ротердің осы тақырып бойынша жақсы баяндамасы бар:
6. Нарыққа бағдарланған: нарыққа бағытталған ұйым
Мұнда әртүрлі мәселелер бар. Мысалы, «Мен» адамдары, «Т» адамдары және «Е» адамдары. «Мен» адамдар – бір ғана нәрсені істейтін адамдар. Олар әдетте оқшауланған бөлімшелері бар ұйымдарда болады. «Т» адамдар – бір нәрседе жақсы, бірақ бірнеше басқада жақсы адамдар. «Е» немесе тіпті «тарақ» - бұл көптеген дағдыларға ие адамдар.
Мұнда Конуэй заңы қолданылады (), оны ең жеңілдетілген түрінде былайша тұжырымдауға болады: егер компиляторда үш команда жұмыс істесе, нәтиже құрастырушы үш бөліктен тұрады. Сондықтан, егер ұйымда оқшауланудың жоғары деңгейі болса, тіпті Kubernetes, Circuit Breaker, API кеңейту мүмкіндігі және басқа да сәнді нәрселер ұйымның өзі сияқты құрылымдалады. Қатаң Конуэйге сәйкес, және сіздердің барлығыңызға жас гейктер.
Бұл мәселенің шешімі бірнеше рет сипатталған. Мысалы, Фернандо Фернандес сипаттаған ұйымдық архетиптер бар. Мен жаңа ғана айтқан проблемалық архитектура, оның оқшаулануы бар, функцияға бағытталған архитектура. Екінші түрі - ең нашар, матрицалық архитектура, ол қалған екеуінің үйлесімі болып табылады. Үшіншісі - біз көптеген стартаптарда көретін нәрсе және ірі компаниялар да осы түрге сәйкес келуге тырысады. Бұл нарыққа бағытталған ұйым. Мұнда тұтынушы сұрауларына ең жылдам жауап алу үшін оңтайландыру орын алады. Мұны кейде жалпақ ұйым деп те атайды.
Бұл құрылымды көптеген адамдар әртүрлі тәсілдермен сипаттайды, маған тұжырымы ұнайды құрастыру/іске қосу командалары, Amazon-да олар оны атайды екі пицца командасыБұл құрылымда барлық «мен» типті адамдар бір қызметтің төңірегінде топтастырылып, бірте-бірте «Т» типті адамдарға жақындай түседі, дұрыс басқарылатын болса, тіпті «Е» болуы мүмкін. Мұндағы бірінші қарсы аргумент – мұндай құрылымның артық екендігі. Егер бізде арнайы тестілеу бөлімі болса, неліктен әрбір бөлімге тестілеуші қажет? Мен жауап беремін: бұл жағдайда қосымша шығындар болашақта «Е» түріне айналатын бүкіл ұйымның бағасы болып табылады. Мұндай құрылымда тестілеуші бірте-бірте желілер, архитектура, дизайн және т.б. туралы біледі. Нәтижесінде ұйымның әрбір мүшесі ұйым ішінде болып жатқан барлық нәрселерден толық хабардар болады. Бұл схема өнеркәсіпте қалай жұмыс істейтінін білгіңіз келсе, оқыңыз. .
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
