Мен жакында Logrocon тарабынан уюштурулган DevOpsForum 2019га катыштым. Бул конференцияда катышуучулар бизнес жана өнүгүү жана маалыматтык технологиялар кызматынын адистеринин ортосундагы эффективдүү өз ара аракеттенүү үчүн чечимдерди жана жаңы инструменттерди табууга аракет кылышты.
Конференция ийгиликтүү өттү: чынында эле көптөгөн пайдалуу баяндамалар, кызыктуу презентация форматтары жана баяндамачылар менен көп баарлашуу болду. Жана эч ким мага эч нерсе сатууга аракет кылбаганы өзгөчө маанилүү, бул чоң жыйындарда сүйлөгөндөр акыркы убакта күнөөлүү.
Raiffeisenbank, Alfastrakhovanie, Mango Telecom компаниясынын автоматташтыруу жана башка майда-чүйдөсүнө чейин ишке ашыруу тажрыйбасынын сөзүнөн үзүндү.
Менин атым Яна, мен сыноочу болуп иштейм, автоматташтыруу, ошондой эле DevOps менен алектенем жана конференцияларга жана жолугушууларга барганды жакшы көрөм. Акыркы эки жылда мен Олег Буниндин конференцияларына (HighLoad++, TeamLead Conf), Jug окуяларына (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow катыштым.
Биринчи кезекте мен конференциянын программасына көңүл бурам. Мен доклад эмне жөнүндө болорун азыраак, баяндамачыга көбүрөөк карайм. Доклад абдан технологиялык жана кызыктуу болуп чыкса да, отчеттун кээ бир алдыңкы тажрыйбасын өзүңүздүн компанияңызда колдоно ала турганыңыз чындык эмес. Анан спикер керек.
Райффайзенбанктагы түтүктүн аягында жарык
Көбүнчө, мен өзүмө кызыккан спикерлерди издейм. DevOpsForum 2019да Райффайзенбанктын спикери Михаил Бижан мени кызыктырды. Сөзүнүн жүрүшүндө ал акырындык менен өз командаларын DevOps менен кантип байланыштырып жатканы, бул эмне үчүн керек жана DevOps трансформациясынын идеясын бизнеске кантип сатуу керектиги жөнүндө айтып берди. Ооба, жалпысынан, түтүктүн аягында жарыкты кантип көрүү керектиги жөнүндө айттым.
Михаил Бижан, Райффайзенбанктын автоматташтыруу боюнча директору
Эми алардын компаниясында "DevOps" жок. Башкача айтканда, ал иштейт, бирок бардык коллективдерде эмес. DevOpsти ишке ашырууда алар конкреттүү инженерлер жагынан да, продукттун муктаждыгы жана бул продукт курулган платформанын жетилгендиги жагынан да командалардын даярдыгына таянышат. Миша DevOps эмне үчүн керек экенин бизнеске кантип түшүндүрүүнү айтты.
Банк сегментинде өсүштүн бир нече драйверлери бар: кызмат көрсөтүүлөрдүн наркы жана кардар базасын кеңейтүү. Кызматтардын баасын көтөрүү абдан жакшы драйвер эмес, бирок кардар базасынын өсүшү тескерисинче. Эгерде атаандаштар объективдүү салкын продуктуну чыгарса, бардык кардарлар ал жакка барышат, андан кийин убакыттын өтүшү менен рыноктун деңгээли көтөрүлөт. Ошондуктан рынокко жаңы продуктыларды киргизүү жана аларды киргизүүнүн ылдамдыгы банктар көңүл бурган негизги нерсе. Дал ушул DevOps үчүн жана бизнес муну түшүнөт.
Кийинки маанилүү эскертүү: DevOps рынокко чыгуу убактысын дайыма эле кыскарта бербейт. DevOps жалгыз иштей албайт, бул өнүмдү иштеп чыгуудан өндүрүшкө (коддон кардарга) чейин түзүү жана рынокко алып чыгуу процессинин бир бөлүгү. Бирок коддон мурун бардыгы DevOps менен түздөн-түз байланыштуу эмес. Башкача айтканда, маркетологдор рынокту көп жылдар бою изилдеп, бүт өмүрүн атаандаштарын кууп чыгууга жумшай алышат. Кардарга эмне керек экенин тез түшүнүү жана тигил же бул функцияны ишке ашырууну пландаштыруу керек - көбүнчө DevOps иштеши жана компаниянын максатына жетиши үчүн бул жетишсиз. Ошондуктан, биринчи кезекте, Raiffeisenbank DevOps колдонууну үйрөнүү зарыл экенин бизнес менен макулдашты. Автоматташтыруу үчүн автоматташтыруу жаңы кардарлар үчүн күрөштө көп жардам бербейт.
Жалпысынан алганда, Миша DevOps ишке ашырылышы керек деп эсептейт, бирок акылдуулук менен. Ал эми кайра куруунун башталышында команданын өндүрүмдүүлүгү төмөндөп, азыраак акча табат, бирок андан кийин аны актай турганына даяр болушубуз керек.
Mango Telecom компаниясында тестирлөө автоматташтырылган
Сыноочу катары мен үчүн дагы бир кызыктуу отчетту Mango Telecom компаниясынан Егор Маслов берди. Презентация "SCRUM командасында толук тестирлөө циклин автоматташтыруу" деп аталды. Егор DevOps атайын SCRUM үчүн түзүлгөн деп эсептейт, бирок ошол эле учурда DevOpsти SCRUM командасына киргизүү абдан көйгөйлүү. Бул SCRUM командасы дайыма бир жерде иштеп жүргөндүктөн болот, инновацияларга алаксып, процессти кайра курууга убакыт жок. Көйгөй ошондой эле SCRUM командадагы суб-командаларды (сыноочу топ, өнүктүрүү тобу ж.б.у.с.) бөлүүнү камтыбайт. Мындан тышкары, иштеп жаткан процессти автоматташтыруу үчүн документация керек, ал эми SCRUMда көбүнчө эч кандай документация жок - "продукт кандайдыр бир жазууга караганда маанилүү."
SCRUMга өткөндөн кийин, тестирлөөчүлөр иштеп чыгуучулар менен функцияларды кантип сынап көрүү боюнча кеңеше башташты. Бара-бара функционалдуулуктун көлөмү көбөйдү, эч кандай документация жок жана алар тесттер менен камтылбаган функциядагы көптөгөн мүчүлүштүктөрдү кармай башташты жана жалпысынан аны ким жана качан сынаганы белгисиз. Кыскача айтканда - башаламандык жана олку-солкулук. Биз сыноону автоматташтырууга өтүүнү чечтик. Бирок ошондо да толук ийгиликсиздик болгон. Алар аутсорсингге алынган автоматташтыруу боюнча адистерди жалдашты, алар үйдөгү тестерлерге белгисиз стекке жазган. Албетте, автотесттердин негизи иштеди, бирок аутсорсерлор кеткенден кийин ал эки жумага созулду. Кийинки автотесттин экинчи номерин киргизүү аракети болду. Бул бардыгын компаниянын ичинде, өз алдынча (туура вектор: ички экспертизаны түзүү), SCRUM алкагында куруу жана процессте документтерди түзүү керек дегенден башталды. Автоматташтыруу үчүн стек продукттун стекине барабар болушу керек (бул жерде мен аны кошуп жатам, JavaScript долбооруңузду башка эч нерсе менен сынабаңыз). Спринттин аягында алар автотест бүт команда менен кантип иштээри жөнүндө демонстрация жасашты (пайдалуу). Ошентип, автоматташтыруу процессине команданын бардык мүчөлөрүнүн катышуусу көбөйдү, ошондой эле автотесттерге болгон ишеним жана бул автотесттин сөзсүз түрдө колдонулушу ыктымалдыгы көбөйдү (жана дайыма катачылыктардан улам бир айдан кийин комментарий берилбейт).
Айтмакчы, DevOpsForum 2019да ачык микрофон болгон - көптөн бери белгилүү жана менин оюмча, сүйлөөлөрдүн пайдалуу форматы. Сиз ушинтип кыдырып жүрүп, докладдарды угуп, анан конференцияда белгилүү бир теманы же көйгөйдү талкуулоо, көйгөйдү чечүүдө тиешелүү тажрыйба менен бөлүшүү керек деген чечимге келесиз.
Уюштуруучулар кыскача баяндамалардын агымын жасашканын да байкадым. Ар бир отчет 10 мүнөттөн ашпайт, андан кийин суроолор берилет. Ушундай жол менен сиз бир эле учурда көптөгөн темаларды камтый аласыз жана сизди кызыктырган баяндамачыларга суроолорду бере аласыз.
Презентациялардын ортосунда мен конференциянын өнөктөштөрүнүн кабиналарын кыдырып, көп нерселерди уурдап/утуп алгам. О, мен таратканды жакшы көрөм!
Alfastrakhovanie боюнча өнүктүрүү директору менен тегерек стол жана DevOps маселелери
DevOpsForum 2019 тортундагы глазурь мен үчүн DevOps эксперттери менен бир саатка созулган пленардык сессия болду. Сессиянын төрт катышуучусу DevOps программасын ар кандай өңүттөн кароого чакырылды: Антон Исанин (Альфастрахование, өнүктүрүү боюнча директор), Наиля Замашкина (Fintech Lab, операциялык директор), Олег Егоркин (Ростелеком, Agile тренери) жана Антон Мартьянов (көз карандысыз эксперт, DevOps карап чыкты. бизнес көз карашынан).
Эксперттер элге жакыныраак отурушту жана андан кийин окуялар боло баштады: бир саат бою аудиториядан келген катышуучулар өздөрүнүн суроолорун беришти, ал эми эксперттер рэп алышты. Кээде чыныгы талаш-тартыштар болгон. Суроолор такыр башкача болчу, мисалы: DevOps инженерлери таптакыр керекпи, эмне үчүн аларды системалык администратор катары окута алышпайт, DevOps баарына сунушталышы керекпи, анын мааниси эмнеде жана башкалар.
Анан Антон Исанин менен жеке сүйлөштүм. Биз DevOps маданиятын ар бир үйгө алып келүү зарылдыгын талкууладык жана DevOps трансформациясынын караңгы жактарын ачтык.
Келгиле, баары чогулуп, DevOps өнүмгө да, бизнеске жана командага да керек деп чечишти деп элестетип көрөлү. Аны ишке ашыралы. Баары ойдогудай болду. Биз дем чыгардык. DevOps бизди кардарга жакындатты, эми биз анын бардык каалоолорун тез арада аткара алабыз. Натыйжада, бизде катуу эрежелери жана талаптары бар чоң Ops бөлүмү бар жана ал дайыма буюмдун кемчиликтерин таап, көптөгөн суроо-талаптарды жаратат. Мындан тышкары, кардар күтүлбөгөн жерден баскычты жашыл эмес, сары түскө боёгусу келсе да, бардык кемчиликтерге "шашылыш" статусу ыйгарылат. Долбоор өсүп жатат, релиздердин саны өсүүдө жана, ошого жараша, кардарлар тарабынан жаңы функцияларды кемчиликтер жана түшүнбөстүктөрдүн саны өсүүдө. Ops кемчиликтерди билдирүү үчүн дагы 10 адамды, ал эми өнүктүрүү аларды жабуу үчүн дагы 15 адамды жалдайт. Жана жаңы функцияларды киргизүүнүн ордуна, команда чексиз SD'лер менен иштейт, колдонуучуга функцияны түшүндүрүп, ошол эле учурда колдоо көрсөтөт. Натыйжада, Ops да, өнүгүү да бизнесте, бирок кардар жана бизнес нааразы: жаңы функциялар тыгылып калат. Көрсө, DevOps бар окшойт, бирок ал жок окшойт.
DevOpsти ишке ашыруу зарылдыгына байланыштуу, Антон бул бизнестин масштабынан түздөн-түз көз каранды экенин ачык айтты. Эгерде жылына бир кардарды тейлөө компанияга миллиард доллар алып келсе, DevOps талап кылынбайт (эгерде бул кардарга жаңы өзгөртүүлөрдү дайыма киргизип туруунун кереги жок болсо). Баары шоколад менен капталган. Бирок бизнес өсүп, көбүрөөк кардарлар пайда болсо, анда сиз баш ийишиңиз керек. Эреже катары, компанияда башында эч кандай сонун Ops жок. Адегенде биз продуктту кесип, андан кийин гана биз продукт иштеши үчүн, биз серверлерге көз салып, камсыз кылуу керек экенин түшүнөбүз. Мына ошондо Ops пайда болот. Ops өзүнчө бөлүм катары өнүгүүгө бир топ тоскоолдуктарды коё баштайт жана бардык жеткирүүлөр токтой баштайт деп түшүнүү керек. Башкача айтканда, бул учурда, DevOps маданияты буга чейин актуалдуу, бирок биз анын караңгы жактарын унутпашыбыз керек.
Source: www.habr.com