Кезінде бір нысандағы тұтынушыға электронды құжат айналымы жүйесін жеткізіп бердік. Содан кейін басқа нысанға. Және тағы біреуі. Ал төртінші, бесінші. Алып кеткеніміз сонша, 10 бөлінген нысанға жеттік. Бұл өте күшті болды... әсіресе өзгерістерді жеткізуге келгенде. Өндіріс тізбегіне жеткізу бөлігі ретінде тестілеу жүйесінің 5 сценарийі, сайып келгенде, 10 сағат пен 6-7 қызметкерді қажет етті. Мұндай шығындар бізді жеткізуді мүмкіндігінше сирек жасауға мәжбүр етті. Үш жыл жұмыс істегеннен кейін біз шыдай алмай, жобаны бір шымшым DevOps арқылы жақсартуға шешім қабылдадық.
Енді барлық тестілеу 3 сағатта өтеді, оған 3 адам қатысады: инженер және екі сынақшы. Жақсартулар сандармен анық көрсетілген және жақсы көретін TTM-нің төмендеуіне әкеледі. Біздің тәжірибемізге сүйенсек, DevOps-тан пайда алатын тұтынушылар тіпті бұл туралы білетіндерге қарағанда әлдеқайда көп. Сондықтан, DevOps-ті адамдарға жақындату үшін біз қарапайым конструкторды жасадық, ол туралы осы постта толығырақ айтатын боламыз.
Енді толығырақ айтып берейік. Бір энергетикалық кәсіпорын 10 ірі нысанға техникалық құжат айналымы жүйесін енгізуде. Мұндай ауқымдағы жобаларды DevOpsсыз шарлау оңай емес, өйткені қол еңбегінің көп бөлігі жұмысты едәуір кешіктіреді, сонымен қатар сапаны төмендетеді - барлық қолмен жұмыс қателерге толы. Екінші жағынан, бір ғана қондырғы бар жобалар бар, бірақ бәрі автоматты түрде, үнемі және ақаусыз жұмыс істеуі керек - мысалы, ірі монолитті ұйымдардағы бірдей құжат айналымы жүйелері. Әйтпесе, біреу параметрлерді қолмен жасайды, орналастыру нұсқауларын ұмытып кетеді - нәтижесінде өндірісте параметрлер жоғалады және бәрі құлап кетеді.
Әдетте біз тапсырыс берушімен келісім-шарт арқылы жұмыс істейміз және бұл жағдайда біздің мүдделеріміз аздап алшақтайды. Тапсырыс беруші жобаға қатаң түрде бюджет пен техникалық ерекшеліктер шегінде қарайды. Оған техникалық сипаттамаларға кірмейтін әртүрлі DevOps тәжірибелерінің артықшылықтарын түсіндіру қиын болуы мүмкін. Егер ол қосымша бизнес құны бар жылдам шығарылымдарға немесе автоматтандыру құбырын салуға қызығушылық танытса ше?
Өкінішке орай, алдын ала бекітілген құнмен жұмыс істегенде, бұл қызығушылық әрдайым табыла бермейді. Біздің тәжірибемізде жосықсыз және ұқыпсыз мердігердің дамуын көтеруге тура келген жағдай болды. Бұл қорқынышты болды: жаңартылған бастапқы кодтар болмады, бір жүйенің кодтық базасы әртүрлі қондырғыларда әртүрлі болды, құжаттама жартылай жоқ және ішінара қорқынышты сапа болды. Әрине, тұтынушы бастапқы кодты, құрастыруды, шығарылымдарды және т.б. бақылауға ие болмады.
Әзірге DevOps туралы бәрі біле бермейді, бірақ біз оның артықшылықтары туралы, нақты ресурстарды үнемдеу туралы сөйлескен кезде, барлық тұтынушылардың көздері жарқырайды. Осылайша, DevOps-ті қамтитын сұраулар саны уақыт өте келе артып келеді. Мұнда тұтынушылармен бір тілде оңай сөйлесу үшін бизнес мәселелері мен DevOps тәжірибелерін жылдам байланыстыру керек, бұл қолайлы даму құбырын құруға көмектеседі.
Сонымен, бізде бір жағынан көптеген мәселелер бар, екінші жағынан DevOps білімдері, тәжірибелері мен құралдары бар. Неге барлығымен тәжірибе бөліспеске?
DevOps конструкторын құру
Agile-дің өз манифесі бар. ITIL-тің өзіндік әдістемесі бар. DevOps аз бақыт - ол әлі үлгілер мен стандарттарды сатып алған жоқ. Дегенмен олардың дамуы мен операциялық тәжірибесін бағалау негізінде компаниялардың жетілу мерзімін анықтау.
Бақытымызға орай, әйгілі Gartner компаниясы 2014 ж және негізгі DevOps тәжірибелері мен олардың арасындағы байланыстарды талдады. Осының негізінде мен инфографика шығардым:
Біз оны өзімізге негіз етіп алдық . Төрт аймақтың әрқайсысында құралдар жиынтығы бар - біз оларды дерекқорға жинадық, ең танымалдарын анықтадық, интеграция нүктелерін және қолайлы оңтайландыру механизмдерін анықтадық. Барлығы шықты 36 тәжірибе және 115 құрал, оның төрттен бір бөлігі ашық бастапқы коды немесе тегін бағдарламалық құрал. Әрі қарай, біз әр салада қандай жетістіктерге қол жеткізгеніміз туралы және мысал ретінде бұл техникалық құжат айналымын құру жобасында қалай жүзеге асырылғандығы туралы сөйлесетін боламыз.
Процестер
Атышулы EDMS жобасында техникалық құжаттаманы басқару жүйесі 10 нысанның әрқайсысында бірдей схема бойынша орналастырылған. Орнату 4 серверді қамтиды: дерекқор сервері, қолданба сервері, толық мәтінді индекстеу және мазмұнды басқару. Орнату кезінде олар бір түйіннің ішінде жұмыс істейді және нысандардағы деректер орталығында орналасады. Барлық нысандар инфрақұрылымда аздап ерекшеленеді, бірақ бұл жаһандық өзара әрекеттесуге кедергі келтірмейді.
Алдымен, DevOps тәжірибесіне сәйкес біз инфрақұрылымды жергілікті түрде автоматтандырдық, содан кейін жеткізуді сынақ тізбегіне, содан кейін тұтынушы өніміне жеткіздік. Әрбір процесс кезең-кезеңімен әзірленді. Қоршаған орта параметрлері автоматты жаңарту үшін тарату жинағы құрастырылғанын ескере отырып, бастапқы код жүйесінде бекітіледі. Конфигурация өзгерген жағдайда, инженерлер нұсқаларды басқару жүйесіне сәйкес өзгертулер енгізуі керек - содан кейін автоматты жаңарту еш қиындықсыз өтеді.
Осы тәсілдің арқасында тестілеу процесі айтарлықтай жеңілдетілді. Бұрын жобада стендтерді қолмен жаңартқаннан басқа ештеңе істемейтін тестерлер болған. Енді олар келіп, бәрі жұмыс істеп жатқанын көріп, пайдалы істермен айналысады. Әрбір жаңарту автоматты түрде тексеріледі - беткі деңгейден бизнес сценарийін автоматтандыруға дейін. Нәтижелер TestRail ішінде бөлек есептер ретінде орналастырылады.
Мәдениет
Үздіксіз эксперимент сынақты жобалау мысалы арқылы жақсы түсіндіріледі. Әлі жоқ жүйені тестілеу – шығармашылық жұмыс. Сынақ жоспарын жазғанда, тестілеуді қалай дұрыс жүргізу керектігін және қандай салаларды ұстану керектігін түсіну керек. Сондай-ақ тексерулердің оңтайлы санын анықтау үшін уақыт пен бюджет арасындағы теңгерімді табыңыз. Қажетті сынақтарды дәл таңдау, пайдаланушының жүйемен қалай әрекеттесетіні туралы ойлану, қоршаған ортаны және ықтимал сыртқы факторларды ескеру маңызды. Үздіксіз экспериментсіз істеу мүмкін емес.
Енді өзара әрекеттесу мәдениеті туралы. Бұрын екі қарама-қарсы жақ болды - инженерлер мен әзірлеушілер. Әзірлеушілер былай деді: «Оның қалай іске қосылатыны бізге маңызды емес. Сіз инженерсіз, сіз ақылдысыз, оның ақаусыз жұмыс істейтініне көз жеткізіңіз». Инженерлер жауап берді: «Сіз әзірлеушілер тым абайсыз. Сақ болайық және шығарылымдарыңызды жиі ойнатамыз. Өйткені сіз бізге ағып кеткен кодты берген сайын, бізге қалай әрекет ету керектігі түсініксіз».. Бұл DevOps тұрғысынан басқаша құрылымдалған мәдени өзара әрекеттестік мәселесі. Мұнда инженерлер де, әзірлеушілер де үнемі өзгеретін, бірақ сонымен бірге сенімді бағдарламалық қамтамасыз етуге бағытталған біртұтас команданың бөлігі болып табылады.
Бір ұжымның ішінде мамандар бір-біріне көмектесуге бел буады. Бұрынғыдай? Мысалы, шамамен 50 бет болатын қалың орналастыру нұсқаулары дайындалып жатқан болатын.Инженер оны оқып, бірдеңені түсінбей, қарғыс айтып, түнгі сағат үште әзірлеушіден түсініктеме беруін сұрады. Әзірлеуші түсініктеме берді, сонымен қатар қарғыс айтты - соңында ешкім қуанбады. Сонымен қатар, әрине, кейбір қателер болды, өйткені нұсқаулардағы барлығын есте сақтау мүмкін емес. Ал қазір инженер әзірлеушімен бірге қолданбалы бағдарламалық қамтамасыз ету инфрақұрылымын автоматтандырылған орналастырудың сценарийін жазуда. Және олар бір-бірімен іс жүзінде бір тілде сөйлеседі.
адамдар
Команданың мөлшері жаңарту көлемімен анықталады. Команда жеткізуді қалыптастыру кезінде қабылданады, оған жобаның жалпы командасынан қызығушылық танытқандар кіреді. Содан кейін әр кезеңге жауапты адамдармен бірге жаңарту жоспары жазылады және топ оның орындалу барысын хабарлайды. Барлық топ мүшелері бір-бірін алмастырады. Команданың бір бөлігі ретінде бізде сақтық көшірме жасаушы да бар, бірақ ол ешқашан қосылмауы керек.
технология
Технологиялық диаграммада бірнеше тармақтар бөлектелген, бірақ олардың астында көптеген технологиялар бар - олардың сипаттамасымен толық кітапты басып шығаруға болады. Сондықтан біз ең қызықтысын атап өтеміз.
Код ретінде инфрақұрылым
Енді, бәлкім, бұл тұжырымдама ешкімді таң қалдырмаса керек, бірақ бұрын инфрақұрылымдардың сипаттамасы көп нәрсені қалаған болатын. , сынақ орталары ерекше болды, оларды қастерлеп, қадірлейтін, шаң бөлшектері ұшып кеткен.
Қазіргі уақытта ешкім тәжірибе жасаудан қорықпайды. Виртуалды машиналардың негізгі кескіндері және орталарды орналастыруға арналған дайын сценарийлер бар. Барлық үлгілер мен сценарийлер нұсқаларды басқару жүйесінде сақталады және дереу жаңартылады. Бұрын пакетті стендке жеткізу қажет болғанда, конфигурацияда бос орын пайда болды. Енді бастапқы кодқа жолды қосу керек.
Инфрақұрылымдық сценарийлер мен конвейерлерден басқа, құжаттама үшін код ретінде құжаттама да қолданылады. Осының арқасында жобаға жаңа адамдарды қосу оңай, мысалы, сынақ жоспарында сипатталған функциялар негізінде оларды жүйеге енгізу, сондай-ақ сынақ жағдайларын қайта пайдалану.
Үздіксіз жеткізу және бақылау
DevOps туралы біз үздіксіз жеткізу мен бақылауды жүзеге асыру үшін құралдарды қалай таңдағанымыз туралы сөйлестік. Көбінесе ештеңені қайта жазудың қажеті жоқ - бұрын жазылған сценарийлерді пайдалану, компоненттер арасындағы интеграцияны дұрыс құру және жалпы басқару консолін жасау жеткілікті. Және барлық процестерді бір түймені немесе кестені пайдаланып іске қосуға болады.
Ағылшын тілінде Үздіксіз жеткізу және Үздіксіз орналастыру деген әртүрлі ұғымдар бар. Екеуі де «үздіксіз жеткізу» деп аударуға болады, бірақ олардың арасында шамалы айырмашылық бар. Біздің жобада үлестірілетін энергетикалық компанияның техникалық құжат айналымына арналған, керісінше, жеткізу пайдаланылады - өндіріске орнату команда бойынша орын алған кезде. Орналастыруда орнату автоматты түрде орындалады. Бұл жобада Үздіксіз жеткізу әдетте айналды DevOps орталық бөлігі.
Жалпы алғанда, белгілі бір параметрлерді жинау арқылы DevOps тәжірибелерінің неліктен пайдалы екенін анық түсінуге болады. Мұны сандарды жақсы көретін басшылыққа жеткізіңіз. Іске қосулардың жалпы саны, сценарий кезеңдерінің орындалу уақыты, сәтті іске қосу үлесі - мұның бәрі нарыққа әркімнің сүйікті уақытына тікелей әсер етеді, яғни нұсқаларды басқару жүйесіне міндеттеме алудан бастап нұсқаны шығаруға дейінгі уақыт. өндірістік орта. Қажетті құралдарды енгізу арқылы инженерлер пошта арқылы құнды көрсеткіштерді алады, ал жоба менеджері оларды бақылау тақтасында көреді. Осылайша сіз жаңа құралдардың артықшылықтарын бірден бағалай аласыз. Сіз DevOps дизайнерінің көмегімен оларды инфрақұрылымыңызда сынап көре аласыз.
Біздің кімге керек болады ?
Алдындамай-ақ қояйық: ол бізге пайдалы болды. Жоғарыда айтқанымыздай, сіз тұтынушымен бір тілде сөйлесуіңіз керек және DevOps дизайнерінің көмегімен біз мұндай әңгіменің негізін тез сызып аламыз. Бизнес мамандары өздеріне қажет нәрсені бағалай алады және осылайша тезірек дамиды. Біз дизайнерді мүмкіндігінше егжей-тегжейлі жасауға тырыстық, кез келген пайдаланушы не таңдайтынын түсінуі үшін көптеген сипаттамалар қостық.
Дизайнердің пішімі компанияның құрылыс процестері мен автоматтандырудағы бар әзірлемелерін ескеруге мүмкіндік береді. Бар процестермен жақсы үйлесетін және олқылықтарды жай ғана толтыра алатын шешімдерді таңдай алсаңыз, бәрін қиратып, қайта құрудың қажеті жоқ.
Мүмкін сіздің дамуыңыз жоғары деңгейге көтерілді және біздің құрал тым «капитандық» болып көрінуі мүмкін. Бірақ біз оны өзімізге пайдалы деп санаймыз және кейбір оқырмандарға пайдалы болады деп үміттенеміз. Еске саламыз дизайнерге - егер бірдеңе болса, сіз диаграмманы бастапқы деректерді енгізгеннен кейін бірден аласыз. Пікірлеріңіз бен толықтыруларыңызға риза боламыз.
Ақпарат көзі: www.habr.com