"Девопторду кантип ишке ашыруу керек" деген суроо көп жылдардан бери болуп келген, бирок жакшы материалдар көп эмес. Кээде кандай болбосун, өз убактысын сатууга муктаж болгон акылдуу эмес консультанттардын жарнамаларынын курмандыгы болуп каласыз. Кээде бул мегакорпорациялардын кемелери ааламдын мейкиндиктерин кантип айдаганы жөнүндө бүдөмүк, өтө жалпы сөздөр. Суроо туулат: мунун бизге кандай тиешеси бар? Урматтуу автор, сиз өз идеяларыңызды тизмеде так формулировкалай аласызбы?
Мунун баары компаниянын маданиятын өзгөртүүнүн натыйжасы жөнүндө реалдуу практика жана түшүнүү көп топтолбогондугунан келип чыгат. Маданияттагы өзгөрүүлөр узак мөөнөттүү нерселер, анын жыйынтыгы бир жумада же бир айда чыкпайт. Бизге көптөгөн жылдар бою компаниялар кандайча курулуп, ийгиликсиз болуп калганын көргөнгө жашы жеткен адам керек.
Джон Уиллис - DevOps аталарынын бири. Жон көптөгөн компаниялар менен иштеген ондогон жылдар бою тажрыйбасы бар. Жакында Жакан алардын ар бири менен иштөөдө орун алган конкреттүү үлгүлөрдү байкай баштады. Бул архетиптерди колдонуп, Джон компанияларды DevOps трансформациясынын чыныгы жолуна багыттайт. Бул архетиптер жөнүндө анын DevOops 2018 конференциясындагы баяндамасынын котормосунан окуңуз.
Баяндамачы жөнүндө:
IT-менеджментте 35 жылдан ашык иштеген, Canonical компаниясында OpenCloud предшечигин түзүүгө катышкан, 10 стартапка катышкан, алардын экөө Dell жана Dockerге сатылган. Учурда ал SJ Technologies компаниясынын DevOps жана Digital Practices боюнча вице-президенти.
Кийинки Жакандын көз карашы боюнча окуя.
Менин атым Джон Уиллис жана мени эң оңой таба турган жер Твиттерде, . Менде Gmail менен GitHubда ошол эле лакап атым бар. А Сиз менин баяндамаларымдын видео жазууларын жана алар үчүн презентацияларды таба аласыз.
Мен ар кандай ири компаниялардын CIOлору менен көп жолугуп турам. Алар көбүнчө DevOps деген эмне экенин түшүнбөгөнүнө нааразы болушат жана аларга түшүндүрүүгө аракет кылгандардын баары башка нерсе жөнүндө сүйлөшөт. Дагы бир кеңири таралган даттануу - DevOps иштебейт, бирок директорлор бардыгын түшүндүргөндөй кылып жатышат. Сөз жүз жылдан ашкан ири компаниялар жөнүндө болуп жатат. Алар менен сүйлөшкөндөн кийин, мен көптөгөн көйгөйлөргө жогорку технология эмес, салыштырмалуу төмөн технологиялуу чечимдер ылайыктуу деген жыйынтыкка келдим. Бир нече жума бою мен ар кандай бөлүмдөрдүн адамдары менен сүйлөштүм. Посттун эң биринчи сүрөттөгү менин акыркы долбоорум, үч күндүк жумуштан кийин бөлмө ушундай көрүндү.
DevOps деген эмне?
Чынында эле 10 түрдүү кишиден сурасаң, алар 10 түрдүү жооп беришет. Эмма шу ерде гызыклы зат: шол жогапларыц хеммеси догры болар. Бул жерде эч кандай туура эмес жооп жок. Мен DevOps менен 10 жылдай терең тааныштым жана биринчи DevOpsDayде биринчи америкалык болдум. Мен DevOps менен алектенгендердин баарынан акылдуумун деп айталбайм, бирок ага мынчалык көп күч жумшаган эч ким жок. Мен DevOps адамдык капитал жана технология бириккенде пайда болот деп ишенем. Биз маданияттын бардык түрлөрү жөнүндө көп айтсак да, адамдык өлчөмдү унутуп калабыз.
Азыр бизде көптөгөн маалыматтар бар, беш жылдык академиялык изилдөөлөр, теорияларды өнөр жайлык масштабда текшерүү. Бул изилдөөлөр бизге эмне дейт, эгерде сиз уюштуруу маданиятында кээ бир жүрүм-турум үлгүлөрүн бириктирсеңиз, анда сиз 2000 эсе ылдамдата аласыз. Бул тездетүү туруктуулуктун бирдей жакшыруусу менен дал келет. Бул DevOps каалаган компанияга бере турган пайданын сандык өлчөөсү. Бир-эки жыл мурун мен Fortune 5000 компаниясынын башкы директоруна DevOps жөнүндө сүйлөшүп жаткан элем.Презентацияга даярданып жатканда мен абдан толкундандым, анткени көп жылдык тажрыйбамды 5 мүнөттө жыйынтыктап беришим керек болчу.
Акырында мен төмөндөгүлөрдү бердим DevOps аныктамасы: Бул адамдык капиталды жогорку натыйжалуу уюштуруу капиталына айландырууга мүмкүндүк берүүчү практикалардын жана үлгүлөрдүн жыйындысы. Мисал катары Тойота акыркы 50 же 60 жылда кандай иштегенин айтса болот.
(Мындан ары мындай диаграммалар маалымдама материал катары эмес, иллюстрация катары берилет. Алардын мазмуну ар бир жаңы компания үчүн ар кандай болот. Бирок сүрөттү өзүнчө көрүп, чоңойтсо болот.
Эң ийгиликтүү тажрыйбалардын бири болуп саналат Наркы агым картасын түзүү. Бул тууралуу бир нече жакшы китептер жазылган, алардын эң ийгиликтүүсү Карен Мартин тарабынан жазылган. Бирок акыркы бир жылда мен бул ыкма да өтө жогорку технологиялуу деген тыянакка келдим. Албетте, анын көптөгөн артыкчылыктары бар жана мен аны көп колдондум. Бирок башкы директор сизден эмне үчүн анын компаниясы жаңы рельстерге өтө албайт деп сураганда, нарк агымынын картасы жөнүндө айтууга али эрте. Адегенде жооп бериши керек болгон дагы көптөгөн негизги суроолор бар.
Менин оюмча, менин көптөгөн кесиптештерим кетирген катасы, алар жөн гана компанияга беш пункттан турган көрсөтмө берип, анан алты айдан кийин кайтып келип, эмне болгонун көрүшөт. Нарк агымынын картасы сыяктуу жакшы схемада, айталы, сокур тактар бар. Ар кандай компаниялардын директорлору менен жүздөгөн интервьюлардан кийин мен көйгөйдү анын компоненттерине бөлүүгө мүмкүндүк берген белгилүү бир схеманы иштеп чыктым, эми биз бул компоненттердин ар бирин ирети менен талкуулайбыз. Кандайдыр бир технологиялык чечимдерди колдонуудан мурун, мен бул үлгүнү колдоном, натыйжада менин бардык дубалдарым схемалар менен капталган. Жакында эле мен пайлык фонд менен иштеп жүрүп, 100-150дөй схема менен аяктадым.
Начар маданият эртең мененки тамакка жакшы ыкмаларды жейт
Негизги идея бул: эгерде уюмдун маданияты начар болсо, эч кандай Lean, Agile, SAFE жана DevOps жардам бербейт. Бул аквалангсыз тереңдикке сүңгүүгө же рентгенсиз операцияга окшош. Башка сөз менен айтканда, Друкер менен Демингди кайра сөз менен айтсак: жаман уюштуруу маданияты бардык жакшы системаны муунтуп койбостон жутуп жиберет.
Бул негизги көйгөйдү чечүү үчүн, төмөнкү кадамдарды жасоо керек:
- Бардык иштерди көрүнүктүү кылуу: бардык ишти көрүнүктүү кылуу керек. Ал сөзсүз түрдө кандайдыр бир экранда көрсөтүлүшү керек деген мааниде эмес, бирок байкоого болот деген мааниде.
- Ишти башкаруунун консолидацияланган системалары: башкаруу системаларын консолидациялоо зарыл. «Уруулук» билимдин жана институттук билимдин проблемасында 9 учурдун 10унда тоскоолдуктар адамдар болуп саналат. Китепте көйгөй бир адам, Брент менен болгон, ал долбоордун үч жылга артта калышына себеп болгон. Жана мен бул "Бренттерге" бардык жерде чуркайм. Бул тоскоолдуктарды чечүү үчүн мен биздин тизмедеги кийинки эки нерсени колдоном.
- Чектөөлөр теориясынын методологиясы: чектөөлөр теориясы.
- Кызматташуу хакерлери: кызматташуу хакерлери.
- Toyota Kata (): Мен Тойота Ката жөнүндө көп сөз кылбайм. Кызык болсо, менин github'умда бул темалардын дээрлик ар бири боюнча.
- Базарга багытталган уюм: рынокко багытталган уюм.
- Солго жылган аудиторлор: циклдин алгачкы этаптарында аудит.
Мен бир уюм менен иштей баштайм: мен компанияга барып, кызматкерлер менен сүйлөшөм. Көрүнүп тургандай, жогорку технология жок. Сизге бир нерсе жазуу керек. Мен бир бөлмөдө бир нече командаларды чогултуп, алардын мага айткандарына менин 7 архетипимдин көз карашынан анализ жасайм. Анан мен аларга маркерди өзүм берип, ушул убакка чейин үн чыгарып айткандарынын баарын тактага жазууну суранам. Көбүнчө мындай жолугушууларда баарын жазып турган бир адам болот, эң жакшысы талкуунун 10% жазып алат. Менин ыкмам менен бул көрсөткүчтү 40% га чейин көтөрсө болот.
(Бул иллюстрацияны өзүнчө көрүүгө болот )
Менин мамилем Уильям Шнайдердин эмгегине негизделген. ). Бул ыкма ар бир уюмду төрт чарчыга бөлүүгө болот деген идеяга негизделген. Мен үчүн бул схема, адатта, уюмду талдоодо пайда болгон жүздөгөн башка схемалар менен иштөөнүн натыйжасы. Бизде контролдун деңгээли жогору, бирок компетенттүүлүгү төмөн уюм бар дейли. Бул өтө жагымсыз вариант: ар бир адам сызык сызыгын көтөрүп турганда, бирок эмне кыларын эч ким билбейт.
Бир аз жакшыраак вариант - бул башкаруунун жана компетенттүүлүктүн жогорку деңгээли. Мындай компания кирешелүү болсо, анда, балким, ага DevOps кереги жок. Башкаруу деңгээли жогору, компетенттүүлүгү жана кооперациясы төмөн, бирок ошол эле учурда маданияты (культивациясы) жогору компания менен иштөө эң кызыктуу. Демек, ишканада иштегенди жакшы көргөндөр көп жана жумушчу күчү аз.
(Бул иллюстрацияны өзүнчө көрүүгө болот )
Менимче, катаал көрсөтмөлөр бар ыкмалар чындыкка жетүү жолуна тоскоол болот. Айрыкча, нарк агымынын картасын түзүүдө маалымат кантип түзүлүшү керектиги боюнча көптөгөн эрежелер бар. Мен азыр айтып жаткан иштин алгачкы этаптарында бул эрежелер эч кимге керек эмес. Колунда маркери бар адам тактада ишканадагы чыныгы абалды сүрөттөп берсе, бул иштин абалын түшүнүүнүн эң жакшы жолу. Мындай маалымат директорлорго жетпейт. Ушул учурда адамдын сөзүн бөлүп, кандайдыр бир жебени туура эмес тартты деп айтуу – келесоолук. Бул этапта жөнөкөй эрежелерди колдонуу жакшы, мисалы: көп деңгээлдеги абстракцияны жөн гана көп түстүү маркерлерди колдонуу менен түзүүгө болот.
Кайталап айтам, жогорку технология жок. Кара маркер баары кандай иштээрин объективдүү чындыкты сүрөттөйт. Кызыл маркер менен адамдар учурдагы абалына эмне жакпай турганын белгилешет. Муну мен эмес, алар жазганы маанилүү. Мен жолугушуудан кийин CIOго барганда оңдоп түзөө керек болгон 10 нерсенин тизмесин сунуштабайм. Мен компаниядагы адамдардын айткандары менен болгон далилденген үлгүлөрдүн ортосундагы байланыштарды табууга аракет кылам. Акыр-аягы, көк маркер маселенин мүмкүн болгон чечимдерди сунуш кылат.
(Бул иллюстрацияны өзүнчө көрүүгө болот )
Бул ыкманын бир мисалы азыр жогоруда сүрөттөлгөн. Ушул жылдын башында бир банк менен иштештим. Ал жердеги коопсуздук кызматкерлери долбоорлоо жана талаптарды карап чыгууга келбеши керек деп ишенишкен.
(Бул иллюстрацияны өзүнчө көрүүгө болот )
Анан биз башка бөлүмдөрдүн адамдары менен сүйлөштүк жана 8 жылдай мурун программалык камсыздоону иштеп чыгуучулар коопсуздук кызматкерлерин жумушун жайлаткандыктан жумуштан бошотушкан экен. Анан тыйуу салууга айланды, бул кадимкидей эле кабыл алынды. Чындыгында эч кандай тыюу салынган эмес.
Биздин жолугушуу өтө чаташкан абалда өттү: үч саатка жакын беш башка команда мага кодекс менен ассамблеянын ортосунда эмне болуп жатканын түшүндүрө алышкан жок. Жана бул эң жөнөкөй нерсе окшойт. Көпчүлүк DevOps консультанттары муну баары билет деп ойлошот.
Анан төрт саат унчукпай отурган IT-башкаруу боюнча жооптуу адам биз анын темасына келгенде капысынан жанданып, бизди абдан көп убакыт ээлеп алды. Акырында мен андан жолугушуу тууралуу кандай ойдо экенин сурадым, анын жообун эч качан унутпайм. Ал мындай деди: "Мен биздин банкта программалык камсыздоону жеткирүүнүн эки гана жолу бар деп ойлочумун, бирок азыр алардын бешөө бар экенин билем, ал эми үчөө жөнүндө билген эмесмин".
(Бул иллюстрацияны өзүнчө көрүүгө болот )
Бул банктагы акыркы жолугушуу инвестициялык программалык камсыздоо командасы менен болгон. Ал кагаз бетине маркер менен диаграммаларды жазуу доскага караганда жакшыраак, ал тургай акылдуу тактага караганда жакшыраак экени аны менен болгон.
Сиз көрүп жаткан сүрөттөр мейманкананын конференц-залынын биздин жолугушуунун төртүнчү күнүндө кандай көрүнгөнү. Жана биз бул схемаларды үлгүлөрдү, башкача айтканда, архетиптерди издөө үчүн колдондук.
Ошентип, мен жумушчуларга суроолорду берем, алар жоопторду үч түстөгү (кара, кызыл жана көк) маркерлер менен жазышат. Мен алардын жоопторун архетиптерге талдайм. Эми бардык архетиптерди ирети менен талкуулайлы.
1. Бардык иштерди көрүнүктүү кылуу: Жумушту көрүнөө кылуу
Мен иштеген компаниялардын көпчүлүгүндө белгисиз жумуштун пайызы өтө жогору. Мисалы, бул бир кызматкер экинчисине келип, жөн гана бир нерсе кылууну суранганда. Чоң уюмдарда 60% пландан тышкаркы иштер болушу мүмкүн. Ал эми 40%га чейин жумуш эч кандай документтештирилбейт. Эгерде бул Боинг болсо, мен өмүрүмдө алардын учагына экинчи отурмак эмесмин. Иштин жарымы гана документтештирилсе, бул иш туура аткарылып жатабы же жокпу белгисиз. Бардык башка ыкмалар пайдасыз болуп чыгат - эч нерсени автоматташтырууга аракет кылуунун мааниси жок, анткени белгилүү 50% иштин эң ырааттуу жана айкын бөлүгү болушу мүмкүн, аны автоматташтыруу сонун натыйжаларды бербейт жана эң жаманы нерселер көрүнбөгөн жарымында. Документтин жоктугунан ар кандай бузукулуктарды жана жашыруун иштерди табуу мүмкүн эмес, бөтөлкөлөрдү, мен айтып өткөн "Бренттерди" табуу мүмкүн эмес. Доминика ДеГрандистин сонун китеби бар . Ал ачып берет беш түрдүү "убакыт агып" (убакыт уурулары):
- Өтө көп жумуш процессинде (WIP)
- Белгисиз көз карандылыктар
- Пландан тышкары иш
- Приоритеттердин карама-каршылыгы
- Каралбаган иш
Бул абдан баалуу талдоо жана китеп сонун, бирок бул кеңештердин бардыгы жараксыз, эгерде маалыматтардын 50% гана көрүнсө. Доминика сунуш кылган ыкмалар 90%дан жогору тактыкка жетишилсе колдонулушу мүмкүн. Мен начальник кол алдындагы адамга 15 мүнөттүк тапшырма берген жагдайлар жөнүндө айтып жатам, бирок ага үч күн талап кылынат; бирок начальник чындап эле бул кол алдындагы адам төрт-беш кишиге көз каранды экенин билбейт.
Phoenix долбоору үч жыл кеч болуп калган долбоор жөнүндө сонун окуя. Каармандардын бири ушундан улам кызматтан четтетилип, ал Сократтын бир түрү катары көрсөтүлгөн дагы бир каарманга жолугат. Ал эмне туура эмес болгонун аныктоого жардам берет. Көрсө, компаниянын бир системалык администратору бар экен, анын аты Brent жана бардык иштер кандайдыр бир жол менен ал аркылуу өтөт. Чогулуштардын биринде кол алдындагылардын бирине: эмне үчүн ар бир жарым сааттык тапшырма бир жумага созулат? Жооп кезек теориясынын жана Литл мыйзамынын абдан жөнөкөйлөштүрүлгөн презентациясы жана бул презентацияда 90% толгондо ар бир жумуш сааты 9 саатты талап кылат экен. Ар бир тапшырма башка жети адамга жөнөтүлүшү керек, ошондуктан ал саат 63 саатка, 7 эсеге 9 болуп калат. Мен айтып жаткан нерсе, Кичинекей мыйзамды же кандайдыр бир татаал кезек теориясын колдонуу үчүн, жок дегенде, маалымат болушу керек.
Ошентип, мен көрүнүү жөнүндө айтканда, мен баары экранда экенин билдирбейм, бирок сизде жок дегенде маалыматтар бар. Алар жасаганда, көп учурда пландан тышкаркы иштердин өтө чоң көлөмү бар экени белгилүү болот, ал кандайдыр бир жол менен Brent компаниясына муктаждык болбогондо жөнөтүлүп жатат. Ал эми Брент мыкты жигит, ал эч качан жок деп айтпайт, бирок өз ишин кантип аткарып жатканын эч кимге айтпайт.
Жумуш көрүнгөндө, маалыматтарды тыкан классификациялоого болот (сүрөттө Доминика ушундай кылып жатат), беш убакыттын агып кетишинин абстракциясы колдонулушу мүмкүн жана автоматташтыруу колдонулушу мүмкүн.
2. Иш башкаруу системаларын бириктирүү: Тапшырмаларды башкаруу
Мен айтып жаткан архетиптер пирамидалардын бир түрү. Биринчиси туура жасалган болсо, экинчиси буга чейин эле кошумча түрү болуп саналат. Булардын көбү стартаптар үчүн иштебейт, аларды Fortune 5000 сыяктуу ири компаниялар үчүн эстен чыгарбоо керек. Мен иштеген акыркы компанияда 10 билет системасы бар болчу. Бир командада Remedy бар, экинчиси кандайдыр бир системаны жазган, үчүнчүсү Jira колдонгон, ал эми кээ бирлери электрондук почта менен иштешкен. Компанияда 30 түрдүү түтүк бар болсо, ошол эле маселе жаралат, бирок менде мындай иштердин баарын талкуулоого убакыт жок.
Мен адамдар менен билеттер кантип түзүлөөрүн, андан кийин эмне болорун жана аларды кантип айланып өтүшкөнүн талкуулайм. Эң кызыгы, биздин жолугушууларыбызда адамдар чын ыкластан сүйлөп жатышат. Мен канча адам билеттерге "кичинекей / таасири жок" деп сурадым, алар чындыгында "чоң таасир" берилиши керек. Муну дээрлик бардыгы жасайт экен. Мен денонсациялоо менен алектенбейм жана адамдарды аныктап албоо үчүн ар кандай жолдор менен аракет кылам. Алар мага чын жүрөктөн бир нерсени мойнуна алганда, мен ал кишини бербейм. Бирок, дээрлик бардыгы системаны кыйгап өтсө, бул коопсуздуктун баары терезени жабуу экенин билдирет. Демек, бул системанын маалыматтарынан эч кандай жыйынтык чыгарууга болбойт.
Билет маселесин чечүү үчүн бир негизги системаны тандоо керек. Жираны колдонсоңуз, аны 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ти киргизүү керек. Сиздин бардык викилериңиз толук болбогон нерсе, анткени алардын бар экенин эч ким билбейт. Эгерде инженердик топ алдыңкы жана арткы өнүгүүгө катышса жана ар бир адам суроолору боюнча алдыңкы өнүктүрүү тобуна же инфраструктура командасына кайрыла аларын билиши керек. Мына ошондо Лу же Фред викиге кошулууга убакыт табат. Анан Slack'те кимдир бирөө эмне үчүн, айталы, 5-кадам иштебей жатканын сурашы мүмкүн. Анан Лу же Фред викидеги нускамаларды оңдоп беришет. Эгер сиз бул процессти орнотсоңуз, анда көп нерсе өзүнөн өзү ордуна келет.
Бул менин негизги оюм: ар кандай жогорку технологияларды сунуштоо үчүн, адегенде алардын пайдубалын иретке келтириш керек жана муну азыр эле сүрөттөлгөн аз технологиялык чечимдер менен жасоого болот. Эгер сиз жогорку технологиялардан баштасаңыз жана алар эмне үчүн керек экенин түшүндүрбөсөңүз, анда, эреже катары, мунун аягы жакшылык менен бүтпөйт. Биздин кардарлардын бири Azure ML колдонот, бул абдан арзан жана жөнөкөй чечим. Алардын суроолорунун 30%ке жакынына өзүн өзү үйрөнүүчү аппараттын өзү жооп берген. Жана бул нерсени маалымат илими, статистика же математика менен алектенбеген операторлор жазган. Бул маанилүү. Мындай чечимдин баасы минималдуу.
4. Кызматташуу хакерлери: Кызматташуу хакерлери
Төртүнчү архетип - обочолонуу менен күрөшүү зарылчылыгы. Көпчүлүк адамдар муну билишет: обочолонуу кастыкты пайда кылат. Эгерде ар бир бөлүм өз кабатында болуп, адамдар лифттен башка эч кандай жол менен бири-бири менен кесилишпесе, анда алардын ортосунда кастык абдан оңой пайда болот. Бирок, тескерисинче, адамдар бири-бири менен бир бөлмөдө болсо, ал дароо чыгып кетет. Кимдир бирөө кандайдыр бир жалпы айыптоолорду ыргытканда, мисалы, тигил же бул интерфейс эч качан иштебейт, мындай айыпты деконструкциялоо оңой нерсе жок. Интерфейсти жазган программисттер жөн гана конкреттүү суроолорду бере башташы керек жана жакында, мисалы, колдонуучу куралды жөн эле туура эмес колдонуп жатканы айкын болот.
Изоляцияны жеңүүнүн көптөгөн жолдору бар. Бир жолу Австралиядагы банкка кеңеш берүүмдү суранышты, бирок мен андан баш тарттым, анткени менин эки балам жана аялым бар. Мен аларга жардам берүү үчүн колумдан келгендин баары графикалык аңгемени сунуштоо эле. Бул иш далилденген нерсе. Дагы бир кызыктуу жолу - арык кофе жолугушуулар. Чоң уюмда бул билимди жайылтуу үчүн эң сонун вариант. Мындан тышкары, сиз ички девопсдейлерди, хакатондорду ж.б.у.с. өткөрө аласыз.
5. Ката машыктыруу
Мен башында эскерткенимдей, бүгүн бул тууралуу сөз кылбайм. Эгер кызыксаңыз, карап көрсөңүз болот .
Майк Ротердин бул темада жакшы баяндамасы бар:
6. Базарга багытталган: рынокко багытталган уюм
Бул жерде ар кандай көйгөйлөр бар. Мисалы, "мен" адамдар, "Т" адамдар жана "E" адамдар. "Мен" деген адамдар бир гана нерсени кылгандар. Адатта, алар обочолонгон бөлүмдөрү бар уюмдарда бар. "Т" - бул адам бир нерседе жакшы, бирок башка нерселерде да жакшы. "Э" же ал тургай, "тарак" адам көп өнөргө ээ болгондо.
Конвей мыйзамы бул жерде иштейт (), аны эң жөнөкөйлөштүрүлгөн түрдө төмөнкүчө айтууга болот: эгерде түзүүчүдө үч команда иштесе, натыйжада үч бөлүктөн турган компилятор чыгат. Демек, уюмда обочолонуунун жогорку деңгээли бар болсо, анда бул уюмдагы Kubernetes, Circuit breaker, API кеңейтүү жана башка кооз нерселер да уюмдун өзү сыяктуу уюштурулат. Катуу Конвейге ылайык жана бардык жаш геэктерге каршы.
Бул маселени чечүү жолу көп жолу сүрөттөлгөн. Мисалы, Фернандо Фернандес сүрөттөгөн уюштуруучулук архетиптер бар. Мен айтып өткөн көйгөйлүү архитектура, обочолонуу менен, функцияга багытталган архитектура. Экинчи түрү - эң начар, матрицалык архитектура, калган экөөнүн башаламандыгы. Үчүнчүсү, көпчүлүк стартаптарда байкалган нерсе жана ири компаниялар да ушул түргө дал келүүгө аракет кылып жатышат. Бул рынокко багытталган уюм. Бул жерде биз кардарлардын суроо-талаптарына тез жооп алуу үчүн оптималдаштырабыз. Бул кээде жалпак уюм деп аталат.
Көптөр бул структураны ар кандай сыпатташат, мага сөз жагат командаларды түзүү/башкаруу, Амазондо алар муну аташат эки пицца командасы. Бул түзүмдө бардык “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 Москва — Ал жерде да көп кызыктуу нерселер бар.
Source: www.habr.com