Որբ ծառայություններ. (միկրո)ծառայությունների ճարտարապետության բացասական կողմը

Անցյալ տարվա համաժողովում ելույթ ունեցավ Banki.ru պորտալի գործառնությունների տնօրեն Անդրեյ Նիկոլսկին DevOpsDays Մոսկվա ծնողազուրկ ծառայությունների մասին. ինչպես բացահայտել որբին ենթակառուցվածքում, ինչու են ծնողազուրկ ծառայությունները վատ, ինչ անել դրանց հետ և ինչ անել, եթե ոչինչ չի օգնում:

Կտրվածքի ներքևում ներկայացված է զեկույցի տեքստային տարբերակը:

Բարև գործընկերներ: Ես Անդրեյն եմ, ղեկավարում եմ Banki.ru-ի գործառնությունները:

Մենք ունենք մեծ ծառայություններ, սրանք այնպիսի միաձույլ ծառայություններ են, կան ծառայություններ ավելի դասական իմաստով, և կան շատ փոքր։ Իմ բանվոր-գյուղացիական տերմինաբանությամբ ասում եմ, որ եթե ծառայությունը պարզ է ու փոքր, ուրեմն միկրո է, իսկ եթե շատ պարզ ու փոքր չէ, ապա դա ընդամենը ծառայություն է։

Ծառայությունների դրական կողմերը

Ես արագ կանդրադառնամ ծառայությունների առավելություններին:

Առաջինը մասշտաբն է: Դուք կարող եք արագ ինչ-որ բան անել ծառայության վրա և սկսել արտադրությունը: Դուք ստացել եք տրաֆիկ, դուք կլոնավորել եք ծառայությունը։ Դուք ունեք ավելի շատ տրաֆիկ, դուք կլոնավորել եք այն և ապրում եք դրա հետ: Սա լավ բոնուս է, և, սկզբունքորեն, երբ մենք սկսեցինք, մեզ համար ամենագլխավորն էր համարվում, թե ինչու ենք այս ամենն անում։

Երկրորդ՝ մեկուսացված զարգացում, երբ ունես մի քանի ծրագրավորող թիմեր, մի քանի տարբեր ծրագրավորողներ յուրաքանչյուր թիմում, և յուրաքանչյուր թիմ զարգացնում է իր սեփական ծառայությունը։

Թիմերի հետ մի նրբերանգ կա. Մշակողները տարբեր են. Եվ կան, օրինակ, ձյան փաթիլ մարդիկ. Ես սա առաջին անգամ տեսա Մաքսիմ Դորոֆեևի մոտ։ Երբեմն ձյան փաթիլ մարդիկ որոշ թիմերում են, իսկ մյուսներում՝ ոչ: Սա ընկերությունում օգտագործվող տարբեր ծառայությունները մի փոքր անհավասար է դարձնում:

Նայեք նկարին. սա լավ մշակող է, նա մեծ ձեռքեր ունի, շատ բան կարող է անել։ Հիմնական խնդիրն այն է, թե որտեղից են այս ձեռքերը:

Ծառայությունները հնարավորություն են տալիս օգտագործել տարբեր ծրագրավորման լեզուներ, որոնք ավելի հարմար են տարբեր առաջադրանքների համար: Որոշ ծառայություն Go-ում է, մի մասը՝ Erlang-ում, մի մասը՝ Ruby-ում, ինչ-որ բան՝ PHP-ում, ինչ-որ բան՝ Python-ում: Ընդհանուր առմամբ, դուք կարող եք շատ լայնորեն ընդլայնվել: Այստեղ էլ կան նրբերանգներ։

Ծառայության վրա հիմնված ճարտարապետությունը հիմնականում վերաբերում է devops-ին: Այսինքն, եթե դուք չունեք ավտոմատացում, չկա տեղակայման գործընթաց, եթե այն կարգավորեք ձեռքով, ձեր կոնֆիգուրացիան կարող է փոխվել ծառայության օրինակից օրինակ, և դուք պետք է գնաք այնտեղ ինչ-որ բան անելու համար, ապա դուք դժոխքում եք:

Օրինակ, դուք ունեք 20 ծառայություն, և դուք պետք է գործարկեք ձեռքով, ունեք 20 կոնսուլ և միաժամանակ սեղմում եք «enter»՝ նինջայի պես: Դա այնքան էլ լավ չէ:

Եթե ​​թեստավորումից հետո ծառայություն ունես (եթե իհարկե թեստավորում կա), ու դեռ պետք է ֆայլով ավարտես, որ արտադրության մեջ աշխատի, քեզ համար նույնպես վատ լուր ունեմ։

Եթե ​​դուք ապավինում եք Amazon-ի հատուկ ծառայություններին և աշխատում եք Ռուսաստանում, ապա երկու ամիս առաջ նաև ունեիք «Շուրջը ամեն ինչ վառվում է, ես լավ եմ, ամեն ինչ լավ է»:

Մենք օգտագործում ենք Ansible-ը՝ տեղակայումը ավտոմատացնելու համար, Puppet-ը՝ կոնվերգենցիայի համար, Bamboo-ը՝ տեղակայումը ավտոմատացնելու համար, և Confluence-ը՝ ինչ-որ կերպ նկարագրելու այդ ամենը:

Ես սրա վրա մանրամասն չեմ անդրադառնա, քանի որ զեկույցն ավելի շատ փոխգործակցության պրակտիկայի մասին է, այլ ոչ թե տեխնիկական իրականացման:

Օրինակ, մենք խնդիրներ ենք ունեցել, երբ Puppet-ը սերվերի վրա աշխատում է Ruby 2-ի հետ, բայց որոշ հավելվածներ գրված են Ruby 1.8-ի համար, և դրանք միասին չեն աշխատում: Այնտեղ ինչ-որ բան այն չէ: Եվ երբ դուք պետք է աշխատեք Ruby-ի մի քանի տարբերակներ մեկ մեքենայի վրա, սովորաբար սկսում եք խնդիրներ ունենալ:

Օրինակ՝ յուրաքանչյուր ծրագրավորողի տալիս ենք հարթակ, որի վրա կա մոտավորապես այն ամենը, ինչ մենք ունենք, բոլոր ծառայությունները, որոնք կարելի է զարգացնել, որպեսզի նա ունենա մեկուսացված միջավայր, կարողանա կոտրել այն և կառուցել այն, ինչպես ուզում է։

Պատահում է, որ ձեզ անհրաժեշտ է հատուկ կազմված փաթեթ՝ այնտեղ ինչ-որ բանի աջակցությամբ։ Դա բավականին կոշտ է: Ես լսեցի մի զեկույց, որտեղ Docker պատկերը կշռում է 45 ԳԲ: Linux-ում, իհարկե, ավելի պարզ է, այնտեղ ամեն ինչ ավելի փոքր է, բայց, այնուամենայնիվ, բավարար տարածք չի լինի:

Դե, կան հակասական կախվածություններ, երբ նախագծի մի մասը կախված է մի տարբերակի գրադարանից, նախագծի մեկ այլ մասը կախված է մեկ այլ տարբերակից, և գրադարաններն ընդհանրապես չեն տեղադրվում միասին:

Մենք PHP 5.6-ով կայքեր ու ծառայություններ ունենք, ամաչում ենք դրանցից, բայց ի՞նչ անենք։ Սա մեր մեկ կայքն է: PHP 7-ում կան կայքեր և ծառայություններ, դրանք ավելի շատ են, մենք չենք ամաչում դրանցից: Եվ յուրաքանչյուր մշակող ունի իր սեփական բազան, որտեղ նա ուրախությամբ տեսնում է:

Եթե ​​ընկերությունում գրում եք մեկ լեզվով, ապա յուրաքանչյուր մշակողի համար երեք վիրտուալ մեքենա նորմալ է հնչում: Եթե ​​ունես ծրագրավորման տարբեր լեզուներ, ապա իրավիճակը վատանում է։

Դուք ունեք կայքեր և ծառայություններ այս, սրա վրա, այնուհետև մեկ այլ կայք Go-ի համար, մեկ կայք Ruby-ի համար և մի քանի այլ Redis կողքին: Արդյունքում այս ամենը վերածվում է աջակցության մեծ դաշտի, և անընդհատ դրա մի մասը կարող է կոտրվել։

Հետևաբար, մենք ծրագրավորման լեզվի առավելությունները փոխարինեցինք տարբեր շրջանակների կիրառմամբ, քանի որ PHP շրջանակները բավականին տարբեր են, նրանք ունեն տարբեր հնարավորություններ, տարբեր համայնքներ և տարբեր աջակցություն: Եվ դուք կարող եք գրել ծառայություն, որպեսզի դրա համար արդեն ինչ-որ բան պատրաստ լինի:

Յուրաքանչյուր ծառայություն ունի իր թիմը

Մեր հիմնական առավելությունը, որը բյուրեղացել է մի քանի տարիների ընթացքում, այն է, որ յուրաքանչյուր ծառայություն ունի իր թիմը: Սա հարմար է մեծ նախագծի համար, դուք կարող եք ժամանակ խնայել փաստաթղթերի վրա, ղեկավարները լավ գիտեն իրենց նախագիծը:

Դուք կարող եք հեշտությամբ առաջադրանքներ ներկայացնել աջակցությունից: Օրինակ՝ ապահովագրական ծառայությունը խափանվեց։ Եվ անմիջապես այն թիմը, որը զբաղվում է ապահովագրությամբ, գնում է այն ուղղելու։

Նոր հնարավորություններ են ստեղծվում արագ, քանի որ երբ դուք ունեք մեկ ատոմային ծառայություն, դուք կարող եք արագ ինչ-որ բան պտտել դրա մեջ:

Եվ երբ դուք խախտում եք ձեր ծառայությունը, և դա անխուսափելիորեն տեղի է ունենում, դուք չեք ազդել այլ մարդկանց ծառայությունների վրա, և այլ թիմերի մշակողները չեն վազում ձեզ մոտ և ասում. «Այ-այ, մի արա դա»:

Ինչպես միշտ, կան նրբերանգներ. Մենք ունենք կայուն թիմեր, մենեջերները գամված են թիմին։ Կան հստակ փաստաթղթեր, մենեջերները ուշադիր հետեւում են ամեն ինչին։ Մենեջեր ունեցող յուրաքանչյուր թիմ ունի մի քանի ծառայություններ, և կա իրավասության որոշակի կետ:

Եթե ​​թիմերը լողում են (մենք նույնպես երբեմն օգտագործում ենք սա), կա լավ մեթոդ, որը կոչվում է «աստղային քարտեզ»:

Դուք ունեք ծառայությունների և մարդկանց ցուցակ: Աստղանիշը նշանակում է, որ անձը փորձագետ է այս ծառայության մեջ, գիրքը նշանակում է, որ անձը ուսումնասիրում է այս ծառայությունը: Անձի խնդիրն է բուկլետը փոխել աստղանիշով: Իսկ եթե ծառայության դիմաց ոչինչ գրված չէ, ապա սկսվում են խնդիրներ, որոնց մասին կխոսեմ հետագա։

Ինչպե՞ս են հայտնվում որբերի ծառայությունները:

Առաջին խնդիրը, ձեր ենթակառուցվածքում ծնողազուրկ ծառայություն ստանալու առաջին միջոցը մարդկանց աշխատանքից հեռացնելն է: Արդյո՞ք որևէ մեկը երբևէ եղե՞լ է, որ բիզնեսը համապատասխանի վերջնաժամկետներին՝ նախքան առաջադրանքների գնահատումը: Երբեմն պատահում է, որ վերջնաժամկետները սեղմվում են, և փաստաթղթերի համար պարզապես ժամանակ չի մնում: «Պետք է ծառայությունը հանձնենք արտադրությանը, հետո կավելացնենք»։

Եթե ​​թիմը փոքր է, պատահում է, որ կա մեկ մշակող, ով գրում է ամեն ինչ, մնացածը թեւերում են: «Ես գրել եմ հիմնական ճարտարապետությունը, եկեք ավելացնենք միջերեսները»: Հետո ինչ-որ պահի մենեջերը, օրինակ, հեռանում է։ Եվ այս ընթացքում, երբ մենեջերը հեռացել է, և դեռ նորը չի նշանակվել, մշակողները իրենք են որոշում, թե ուր է գնում ծառայությունը և ինչ է կատարվում այնտեղ։ Եվ ինչպես գիտենք (եկեք մի քանի սլայդ հետ գնանք), որոշ թիմերում կան ձյան փաթիլ մարդիկ, երբեմն՝ ձյան փաթիլ թիմի ղեկավար։ Հետո նա թողնում է, և մենք ստանում ենք որբերի ծառայություն:

Միևնույն ժամանակ, աջակցության և բիզնեսի առաջադրանքները չեն անհետանում, դրանք հայտնվում են հետաձգված վիճակում: Եթե ​​ծառայության մշակման ընթացքում եղել են ճարտարապետական ​​սխալներ, ապա դրանք նույնպես հայտնվում են հետնախույզի մեջ։ Ծառայությունը կամաց-կամաց վատանում է.

Ինչպե՞ս ճանաչել որբին:

Այս ցուցակը լավ նկարագրում է իրավիճակը։ Ո՞վ է ինչ-որ բան իմացել իրենց ենթակառուցվածքի մասին:

Փաստաթղթավորված աշխատանքների շուրջ. կա ծառայություն և, ընդհանուր առմամբ, այն աշխատում է, ունի երկու էջանոց ձեռնարկ, թե ինչպես աշխատել դրա հետ, բայց ոչ ոք չգիտի, թե ինչպես է այն աշխատում ներսում:

Կամ, օրինակ, կա ինչ-որ կապի կրճատող: Օրինակ, մենք ներկայումս ունենք երեք հղումների կրճատիչներ, որոնք օգտագործվում են տարբեր նպատակներով տարբեր ծառայություններում: Սրանք ընդամենը հետևանքներն են։

Հիմա ես կլինեմ ակնհայտի կապիտանը։ Ի՞նչ է պետք անել։ Նախ, մենք պետք է ծառայությունը փոխանցենք մեկ այլ մենեջերի, մեկ այլ թիմի: Եթե ​​ձեր թիմի առաջատարը դեռ չի հեռացել, ապա այս մյուս թիմում, երբ հասկանում եք, որ ծառայությունը նման է որբի, դուք պետք է ներառեք մեկին, ով գոնե ինչ-որ բան հասկանում է դրա մասին:

Գլխավորը՝ դուք պետք է արյունով գրված ունենաք փոխանցման ընթացակարգերը։ Մեր դեպքում ես սովորաբար վերահսկում եմ դա, քանի որ ինձ անհրաժեշտ է, որ այդ ամենը աշխատի: Մենեջերներին անհրաժեշտ է, որ այն արագ հասցվի, և այն, ինչ տեղի կունենա հետագայում, նրանց համար այլևս այդքան կարևոր չէ:

Որբ դարձնելու հաջորդ ձևն է՝ «Մենք դա կանենք աութսորսինգով, դա կլինի ավելի արագ, այնուհետև մենք այն կհանձնենք թիմին»: Հասկանալի է, որ թիմում բոլորն էլ ինչ-որ ծրագրեր ունեն, շրջադարձ։ Հաճախ բիզնես հաճախորդը կարծում է, որ աութսորսերը կանի նույնը, ինչ ընկերության տեխնիկական բաժինը: Չնայած նրանց դրդապատճառները տարբեր են։ Աութսորսինգում կան տարօրինակ տեխնոլոգիական լուծումներ և տարօրինակ ալգորիթմական լուծումներ։

Օրինակ, մենք ունեինք մի ծառայություն, որն ուներ Սֆինքս տարբեր անսպասելի վայրերում: Ես ձեզ ավելի ուշ կասեմ, թե ինչ պետք է անեի:

Աութսորսորներն ունեն ինքնուրույն գրավոր շրջանակներ: Սա պարզապես մերկ PHP է նախորդ նախագծի պատճենով, որտեղ դուք կարող եք գտնել բոլոր տեսակի բաներ: Տեղակայման սկրիպտները մեծ թերություն են, երբ դուք պետք է օգտագործեք որոշ բարդ Bash սկրիպտներ՝ որոշ ֆայլում մի քանի տող փոխելու համար, և տեղակայման այս սկրիպտները կանչվում են ինչ-որ երրորդ սկրիպտով: Արդյունքում, դուք փոխում եք տեղակայման համակարգը, ընտրում եք այլ բան, ցատկում, բայց ձեր ծառայությունը չի աշխատում: Որովհետև այնտեղ պետք էր ևս 8 հղում դնել տարբեր թղթապանակների միջև։ Կամ պատահում է, որ հազար ձայնագրություն է աշխատում, իսկ հարյուր հազարն արդեն չի աշխատում։

Ես կշարունակեմ ավագ լինել. Աութսորսավորված ծառայության ընդունումը պարտադիր ընթացակարգ է: Որևէ մեկին երբևէ պատահե՞լ է, որ աութսորսավորված ծառայությունը հասնի և որևէ տեղ չընդունվի: Սա ոչ այնքան հայտնի է, իհարկե, որքան որբ ծառայությունը, բայց դեռ:

Ծառայությունը պետք է ստուգվի, ծառայությունը վերանայվի, գաղտնաբառերը պետք է փոխվեն։ Մենք ունեցել ենք դեպք, երբ մեզ ծառայություն են տվել, կա ադմինիստրատորի վահանակ «if login == 'admin' && password == 'admin'...», գրված է հենց կոդի մեջ։ Մենք նստած մտածում ենք, իսկ մարդիկ սա գրում են 2018թ.

Պահպանման հզորության փորձարկումը նույնպես անհրաժեշտ բան է։ Դուք պետք է նայեք, թե ինչ է լինելու հարյուր հազար ձայնագրությունների վրա, նույնիսկ նախքան ինչ-որ տեղ այս ծառայությունը արտադրության մեջ դնելը:

Ծառայությունը կատարելագործման ուղարկելու մեջ ամոթ չպետք է լինի: Երբ ասում եք. «Չենք ընդունի այս ծառայությունը, 20 խնդիր ունենք, արեք, հետո կընդունենք», սա նորմալ է։ Ձեր խիղճը չպետք է ցավի այն փաստից, որ դուք մենեջեր եք ստեղծում կամ բիզնեսը փող է վատնում։ Այդ դեպքում բիզնեսն ավելի շատ կծախսի:

Մենք ունեինք դեպք, երբ որոշեցինք աութսորսինգ անել պիլոտային ծրագիր։

Այն առաքվել է ժամանակին, և սա որակի միակ չափանիշն էր։ Այդ իսկ պատճառով մենք պատրաստեցինք ևս մեկ փորձնական նախագիծ, որն այլևս նույնիսկ իրականում պիլոտային չէր: Այս ծառայություններն ընդունվեցին, վարչական ճանապարհով ասացին՝ ահա քո կոդը, ահա թիմը, ահա քո մենեջերը։ Ծառայությունները փաստացի արդեն սկսել են շահույթ ստանալ։ Միևնույն ժամանակ, փաստորեն, նրանք դեռ որբ են, ոչ ոք չի հասկանում, թե ինչպես են նրանք աշխատում, և մենեջերներն ամեն ինչ անում են, որ հրաժարվեն իրենց առաջադրանքներից:

Կա ևս մեկ հիանալի հայեցակարգ՝ պարտիզանական զարգացում։ Երբ որոշ բաժին, սովորաբար մարքեթինգի բաժինը, ցանկանում է ստուգել վարկածը և պատվիրում է ամբողջ ծառայությունն արտապատվիրել: Երթևեկությունը սկսում է լցվել մեջը, փակում են փաստաթղթերը, կապալառուի հետ ստորագրում, շահագործման են հանձնում և ասում. «Ժողովուրդ, մենք այստեղ ծառայություն ունենք, արդեն երթևեկություն ունի, փող է բերում, եկեք ընդունենք»։ Մենք ասում էինք՝ «Օպա, ինչպե՞ս կարող է դա լինել»:

Եվ որբ ծառայություն ստանալու ևս մեկ միջոց. երբ ինչ-որ թիմ հանկարծ հայտնվում է ծանրաբեռնված վիճակում, ղեկավարությունն ասում է. Եվ հետո մենք այն կտեղափոխենք երրորդ թիմ և կփոխենք մենեջերին: Եվ վերջում նորից որբ ենք ունենում։

Ո՞րն է որբերի խնդիրը:

Ով չգիտի, սա Շվեդիայում բարձրացված Wasa մարտանավն է, որը հայտնի է նրանով, որ խորտակվել է արձակումից 5 րոպե անց: Իսկ Շվեդիայի թագավորը, ի դեպ, սրա համար ոչ մեկին մահապատժի չի ենթարկել։ Այն կառուցել են ինժեներների երկու սերունդ, ովքեր չգիտեին, թե ինչպես կառուցել նման նավեր։ Բնական ազդեցություն.

Նավը կարող էր խորտակվել, ի դեպ, շատ ավելի վատ ձևով, օրինակ, երբ թագավորն արդեն նստած էր դրա վրա ինչ-որ տեղ փոթորկի մեջ։ Եվ այսպես, նա անմիջապես խեղդվեց, ըստ Agile-ի՝ լավ է շուտ ձախողվելը։

Եթե ​​մենք շուտ ձախողվենք, սովորաբար խնդիրներ չեն լինում։ Օրինակ՝ ընդունման ժամանակ այն ուղարկվել է վերանայման։ Բայց եթե մենք արդեն թերանում ենք արտադրության մեջ, երբ գումար է ներդրվում, ապա կարող են խնդիրներ լինել։ Հետևանքները, ինչպես ասում են բիզնեսում։

Ինչու են ծնողազուրկ ծառայությունները վտանգավոր.

• Ծառայությունը կարող է հանկարծակի խզվել:
• Ծառայությունը երկար ժամանակ է պահանջում վերանորոգման համար կամ ընդհանրապես չի վերանորոգվում։
• Անվտանգության խնդիրներ.
• Բարելավումների և թարմացումների հետ կապված խնդիրներ:
• Եթե ​​որևէ կարևոր ծառայություն խափանում է, ընկերության հեղինակությունը տուժում է:

Ի՞նչ անել որբերի ծառայությունների հետ:

Կրկնեմ ինչ անել. Նախ, պետք է լինի փաստաթղթեր. Banki.ru-ում 7 տարին ինձ սովորեցրեց, որ փորձարկողները չպետք է ընդունեն մշակողների խոսքը, իսկ գործողությունները չպետք է ընդունեն բոլորի խոսքը: Մենք պետք է ստուգենք.

Երկրորդ, անհրաժեշտ է գրել փոխազդեցության դիագրամներ, քանի որ պատահում է, որ այնքան էլ լավ չընդունված ծառայությունները պարունակում են կախվածություններ, որոնց մասին ոչ ոք չի ասել։ Օրինակ՝ ծրագրավորողները ծառայությունը տեղադրել են իրենց բանալիների վրա՝ որոշ Yandex.Maps-ի կամ Dadata-ի վրա: Դուք սպառել եք անվճար սահմանաչափը, ամեն ինչ կոտրված է, և դուք ընդհանրապես չգիտեք, թե ինչ է տեղի ունեցել: Բոլոր նման փոցխերը պետք է նկարագրվեն՝ ծառայությունն օգտագործում է Dadata, SMS, այլ բան։

Երրորդ՝ տեխնիկական պարտքի հետ աշխատելը։ Երբ ինչ-որ հենակներ եք անում կամ ընդունում եք ծառայություն և ասում, որ ինչ-որ բան պետք է անել, պետք է համոզվեք, որ դա արված է: Որովհետև այդ դեպքում կարող է պարզվել, որ փոքր անցքը այնքան էլ փոքր չէ, և դուք ընկնեք դրա միջով։

Ճարտարապետական ​​առաջադրանքներով մենք պատմություն ունեցանք Սֆինքսի մասին: Ծառայություններից մեկն օգտագործեց Sphinx-ը ցուցակներ մուտք գործելու համար: Պարզապես էջանշված ցուցակ, բայց ամեն երեկո այն նորից ինդեքսավորվում էր: Այն հավաքվում էր երկու ցուցիչից. ամեն գիշեր ինդեքսավորվում էր մեկը մեծը, և կար նաև մի փոքր ցուցիչ, որը պտտվում էր դրա վրա: Ամեն օր, ռմբակոծելու կամ ոչ ռմբակոծելու 50% հավանականությամբ, ինդեքսը խափանում էր հաշվարկի ժամանակ, և մեր լուրերը դադարեցին թարմանալ գլխավոր էջում։ Սկզբում ինդեքսի վերաինդեքսավորման համար պահանջվեց 5 րոպե, հետո ինդեքսն աճեց, իսկ ինչ-որ պահի սկսեց 40 րոպե տևել վերաինդեքսավորման համար։ Երբ սա կտրեցինք, թեթևացած շունչ քաշեցինք, քանի որ պարզ էր, որ դեռ մի քիչ ժամանակ կանցնի, և մեր ցուցանիշը լրիվ դրույքով կվերինդեքսավորվի: Սա ձախողում կլինի մեր պորտալի համար, ութ ժամ նորություն չկա, վերջ, բիզնեսը կանգ է առել։

Ծրագիր ծնողազուրկ ծառայության հետ աշխատելու համար

Իրականում դա շատ դժվար է անել, քանի որ devops-ը հաղորդակցության մասին է: Դուք ցանկանում եք լավ հարաբերությունների մեջ լինել ձեր գործընկերների հետ, և երբ կանոնակարգերով հարվածում եք ձեր գործընկերների և ղեկավարների գլխին, նրանք կարող են հակասական զգացմունքներ ունենալ այն մարդկանց նկատմամբ, ովքեր դա անում են:

Այս բոլոր կետերից բացի, կա ևս մեկ կարևոր բան. յուրաքանչյուր կոնկրետ ծառայության, տեղակայման ընթացակարգի յուրաքանչյուր կոնկրետ հատվածի համար պետք է պատասխանատու լինեն կոնկրետ մարդիկ։ Երբ մարդիկ չկան, և պետք է ուրիշներին գրավես այս ամբողջ հարցն ուսումնասիրելու համար, դա դժվարանում է։

Եթե ​​այս ամենը չօգնեց, և ձեր որբերի ծառայությունը դեռ որբ է, ոչ ոք չի ուզում դա վերցնել, փաստաթղթերը գրված չեն, թիմը, որը կանչվել է այս ծառայության մեջ, հրաժարվում է որևէ բան անել, կա մի պարզ միջոց՝ կրկնել: ամեն ինչ.

Այսինքն՝ դուք նորովի եք վերցնում ծառայության պահանջները և գրում եք նոր ծառայություն, ավելի լավ, ավելի լավ հարթակում, առանց տարօրինակ տեխնոլոգիական լուծումների։ Եվ դուք գաղթում եք այնտեղ ճակատամարտում:

Մենք ունեինք մի իրավիճակ, երբ մենք ծառայություն ընդունեցինք Yii 1-ում և հասկացանք, որ մենք չենք կարող այն ավելի զարգացնել, քանի որ մեզ սպառել են ծրագրավորողներ, ովքեր կարող էին լավ գրել Yii 1-ում: Բոլոր մշակողները լավ են գրում Symfony XNUMX-ում: Ինչ անել? Մենք ժամանակ հատկացրինք, թիմ հատկացրինք, մենեջեր հատկացրինք, վերաշարադրեցինք նախագիծը և սահուն կերպով անցանք երթևեկությունը դեպի այն:

Դրանից հետո հին ծառայությունը կարող է ջնջվել: Սա իմ սիրած պրոցեդուրան է, երբ պետք է կոնֆիգուրացիայի կառավարման համակարգից ինչ-որ ծառայություն վերցնել և մաքրել, հետո անցնել և տեսնել, որ արտադրության բոլոր մեքենաներն անջատված են, որպեսզի մշակողների հետքեր չմնան: Պահեստը մնում է Git-ում:

Սա այն ամենն է, ինչի մասին ուզում էի խոսել, ես պատրաստ եմ քննարկել, թեման հոլիվարն է, շատերը լողացել են դրա մեջ:

Սլայդներն ասում էին, որ դուք լեզուներ եք միավորել։ Օրինակ՝ նկարների չափափոխումը։ Իսկապե՞ս անհրաժեշտ է այն խստորեն սահմանափակել մեկ լեզվով: Քանի որ պատկերի չափափոխումը PHP-ում, դե, իրականում կարող էր կատարվել Golang-ում:

Փաստորեն, դա կամընտիր է, ինչպես բոլոր պրակտիկաները: Հնարավոր է, որոշ դեպքերում դա նույնիսկ անցանկալի է։ Բայց դուք պետք է հասկանաք, որ եթե դուք ունեք տեխնիկական բաժին 50 հոգանոց ընկերությունում, նրանցից 45-ը PHP մասնագետներ են, ևս 3-ը devops են, ովքեր գիտեն Python, Ansible, Puppet և նման բաներ, և նրանցից միայն մեկն է գրում որոշներում: ինչ-որ լեզու, Go image-ի չափափոխման ծառայություն, այնուհետև, երբ այն հեռանում է, փորձաքննությունն անցնում է դրա հետ: Եվ միևնույն ժամանակ, դուք պետք է փնտրեք շուկայական հատուկ մշակողի, ով գիտի այս լեզուն, հատկապես, եթե դա հազվադեպ է: Այսինքն՝ կազմակերպչական տեսանկյունից սա խնդրահարույց է։ Deops-ի տեսանկյունից ձեզ հարկավոր կլինի ոչ միայն կլոնավորել որոշ պատրաստի գրքույկներ, որոնք օգտագործում եք ծառայությունների տեղակայման համար, այլ դուք ստիպված կլինեք նորից գրել դրանք:

Ներկայումս մենք ծառայություն ենք կառուցում Node.js-ում, և սա կլինի մոտակա հարթակ յուրաքանչյուր մշակողի համար՝ առանձին լեզվով: Բայց մենք նստեցինք և մտածեցինք, որ խաղն արժե մոմը: Այսինքն՝ սա ձեզ համար նստելու և մտածելու հարց է։

Ինչպե՞ս եք վերահսկում ձեր ծառայությունները: Ինչպե՞ս եք հավաքում և վերահսկում տեղեկամատյանները:

Մենք Elasticsearch-ում տեղեկամատյաններ ենք հավաքում և դնում Kibana-ում, և կախված նրանից, թե դա արտադրական, թե փորձնական միջավայրեր են, այնտեղ օգտագործվում են տարբեր կոլեկցիոներներ։ Ինչ-որ տեղ Լոմբերջակ, մի տեղ այլ բան, ես չեմ հիշում: Իսկ որոշակի ծառայություններում դեռ որոշ տեղեր կան, որտեղ մենք տեղադրում ենք Telegraf-ը և առանձին-առանձին նկարում ենք մեկ այլ տեղ:

Ինչպե՞ս ապրել Տիկնիկի և Անսիբլի հետ նույն միջավայրում:

Փաստորեն, մենք հիմա ունենք երկու միջավայր՝ մեկը Տիկնիկային է, մյուսը՝ Անսիբլը։ Մենք աշխատում ենք դրանք հիբրիդացնելու ուղղությամբ։ Ansible-ը լավ շրջանակ է նախնական տեղադրման համար, Puppet-ը սկզբնական տեղադրման համար վատ շրջանակ է, քանի որ այն պահանջում է գործնական աշխատանք անմիջապես հարթակի վրա, իսկ Puppet-ն ապահովում է կոնֆիգուրացիայի կոնվերգենցիան: Սա նշանակում է, որ պլատֆորմը պահպանում է իրեն արդիական վիճակում, և որպեսզի անսիբիլիզացված մեքենան թարմացվի, դուք պետք է անընդհատ աշխատացնեք դրա վրա որոշակի հաճախականությամբ գրքույկներ: Սա է տարբերությունը:

Ինչպե՞ս եք պահպանում համատեղելիությունը: Դուք ունե՞ք կազմաձևեր ինչպես Ansible-ում, այնպես էլ Puppet-ում:

Սա մեր մեծ ցավն է, մենք ձեռքերի հետ համատեղելիություն ենք պահպանում և մտածում, թե ինչպես հիմա ինչ-որ տեղ այս ամենից առաջ շարժվել։ Պարզվում է, որ Puppet-ը փաթեթներ է գլորում և այնտեղ պահպանում է որոշ հղումներ, իսկ Ansible-ը, օրինակ, գլորում է կոդը և կարգավորում հավելվածների վերջին կոնֆիգուրացիաները:

Շնորհանդեսը Ռուբիի տարբեր տարբերակների մասին էր։ Ի՞նչ լուծում։

Մենք սրան հանդիպել ենք մեկ տեղում, և պետք է անընդհատ պահել մեր գլխում։ Մենք պարզապես անջատեցինք Ruby-ի վրա աշխատող այն մասը, որը անհամատեղելի էր հավելվածների հետ և պահեցինք այն առանձին:

Այս տարվա համաժողովը DevOpsDays Մոսկվա դեկտեմբերի 7-ին Տեխնոպոլիսում։ Հաշվետվությունների հայտերն ընդունում ենք մինչև նոյեմբերի 11-ը։ Գրել մեզ, եթե ցանկանում եք խոսել:

Մասնակիցների գրանցումը բաց է, միացե՛ք մեզ:

Source: www.habr.com