တစ်ဖန် DevOps နှင့် SRE အကြောင်း

ဆွေးနွေးချက်တစ်ခုအပေါ်အခြေခံသည်။ AWS Minsk အသိုင်းအဝိုင်း

မကြာသေးမီက၊ DevOps နှင့် SRE တို့၏ အဓိပ္ပါယ်ဖွင့်ဆိုချက်ကြောင့် စစ်မှန်သော တိုက်ပွဲများ ပေါ်ပေါက်လာသည်။
ဤအကြောင်းအရာအပေါ် ဆွေးနွေးမှုများသည် နည်းလမ်းများစွာဖြင့် ကျွန်ုပ်အပါအဝင် ကျွန်ုပ်၏အံသွားများကို စွန်းထင်းနေပြီဖြစ်သော်လည်း၊ ဤအကြောင်းအရာနှင့် ပတ်သက်၍ ကျွန်ုပ်၏အမြင်ကို Habra အသိုက်အဝန်းတရားရုံးသို့ တင်ပြရန် ဆုံးဖြတ်ခဲ့သည်။ စိတ်ပါဝင်စားသူများအတွက်ကြောင်မှကြိုဆိုပါတယ်။ ပြီးတော့ အရာအားလုံးကို အသစ်တစ်ဖန်စတင်ပါစေ။

စောပိုငျးကာလ

ထို့ကြောင့် ရှေးခေတ်က ဆော့ဖ်ဝဲလ်တီထွင်သူများနှင့် ဆာဗာစီမံခန့်ခွဲသူများအဖွဲ့တစ်ဖွဲ့ သီးခြားစီ နေထိုင်ခဲ့ကြသည်။ ပထမတစ်ခုက ကုဒ်ကို အောင်မြင်စွာရေးသားခဲ့ပြီး၊ ဒုတိယမှာ ပထမဦးစွာထံသို့ နွေးထွေးပြီး ချစ်ခင်ကြင်နာသော စကားလုံးအမျိုးမျိုးကို အသုံးပြုကာ ဆာဗာများကို စနစ်ထည့်သွင်းခြင်း၊ ဆော့ဖ်ဝဲရေးသားသူများထံ အခါအားလျော်စွာ လာရောက်ခြင်းနှင့် တုံ့ပြန်မှုဖြင့် လက်ခံခြင်းတို့တွင် ကျယ်ကျယ်ပြန့်ပြန့် "ကျွန်ုပ်၏စက်တွင် အရာအားလုံး အလုပ်လုပ်သည်" ဖြစ်သည်။ လုပ်ငန်းသည် ဆော့ဖ်ဝဲလ်ကို စောင့်ဆိုင်းနေချိန်၊ အရာအားလုံး မလှုပ်မရှား ဖြစ်နေသည်၊ အခါအားလျော်စွာ ပျက်သွားသည်၊ လူတိုင်းက စိုးရိမ်နေကြသည်။ အထူးသဖြင့် ဒီအရှုပ်အထွေးအတွက် ပေးဆပ်ခဲ့သူပါ။ ဘုန်းကြီးဆီမီးခေတ်။ ကောင်းပြီ၊ DevOps ဘယ်ကလာတယ်ဆိုတာ သင်သိပြီးသားပါ။

DevOps အလေ့အကျင့်များမွေးဖွားခြင်း။

အဲဒီအခါမှာ အလေးအနက် ယောက်ျားတွေက လာပြီးပြောတယ် - ဒါက စက်မှုလုပ်ငန်းမဟုတ်ဘူး၊ မင်းအဲဒီလို လုပ်လို့မရဘူး။ သူတို့သည် ဘဝစက်ဝန်းပုံစံများကို ယူဆောင်လာကြသည်။ ဥပမာ၊ ဒီနေရာမှာ V-model ပါ။

ဒါဆို ငါတို့ ဘာမြင်လဲ။ လုပ်ငန်းတစ်ခုသည် အယူအဆတစ်ခု၊ ဗိသုကာပညာရှင်များ၏ ဒီဇိုင်းဖြေရှင်းနည်းများ၊ developer များက ကုဒ်များရေးပြီးနောက် မအောင်မြင်ပါ။ တစ်စုံတစ်ဦးသည် ထုတ်ကုန်ကို တစ်နည်းနည်းဖြင့် စမ်းသပ်သည်၊ တစ်စုံတစ်ဦးသည် ၎င်းကို အသုံးပြုသူထံ တစ်နည်းနည်းဖြင့် ပို့ဆောင်ပေးပြီး၊ ဤအံ့ဖွယ်မော်ဒယ်၏ ထွက်ရှိမှုတစ်နေရာတွင် ပင်လယ်ကမ်းစပ်က ကတိပြုထားသည့် ရာသီဥတုကို စောင့်မျှော်နေသော အထီးကျန်စီးပွားရေးဖောက်သည်တစ်ဦးသည် ထိုင်နေပါသည်။ ဤလုပ်ငန်းစဉ်ကို ချမှတ်နိုင်စေမည့် နည်းလမ်းများ လိုအပ်ကြောင်း နိဂုံးချုပ်လာပါသည်။ ပြီးတော့ အဲဒါတွေကို အကောင်အထည်ဖော်မယ့် အလေ့အကျင့်တွေ ဖန်တီးဖို့ ဆုံးဖြတ်လိုက်တယ်။

အလေ့အကျင့်၏အကြောင်းအရာအပေါ် ကဗျာဆန်သော လွန်ကဲမှု
လက်တွေ့အားဖြင့် ကျွန်တော်ဆိုလိုသည်မှာ နည်းပညာနှင့် စည်းကမ်းကို ပေါင်းစပ်ခြင်းဖြစ်သည်။ ဥပမာတစ်ခုသည် terraform ကုဒ်ကိုအသုံးပြု၍ အခြေခံအဆောက်အအုံကိုဖော်ပြခြင်း၏အလေ့အကျင့်ဖြစ်သည်။ Discipline သည် အခြေခံအဆောက်အအုံကို ကုဒ်ဖြင့်ဖော်ပြပုံ၊ ၎င်းသည် developer ၏ခေါင်းထဲတွင်ရှိပြီး နည်းပညာသည် terraform ကိုယ်တိုင်ဖြစ်သည်။

ပြီးတော့ သူတို့က သူတို့ကို DevOps အလေ့အကျင့်လို့ ခေါ်ဖို့ ဆုံးဖြတ်လိုက်တယ် - သူတို့က Development ကနေ Operations အထိ ဆိုလိုတယ်လို့ ထင်ပါတယ်။ ကျွန်ုပ်တို့သည် အမျိုးမျိုးသော လိမ္မာပါးနပ်သော အရာများ ထွက်ပေါ်လာသည် - CI/CD အလေ့အကျင့်များ၊ IaC နိယာမအပေါ် အခြေခံထားသော အလေ့အကျင့်များ ထောင်ပေါင်းများစွာ။ ပြီးသွားတော့ developer များက ကုဒ်ရေးကြသည်၊ DevOps အင်ဂျင်နီယာများသည် စနစ်၏ဖော်ပြချက်အား ကုဒ်ပုံစံဖြင့် အလုပ်လုပ်သောစနစ်များအဖြစ်သို့ ပြောင်းလဲကြသည် (ဟုတ်ပါတယ်၊ ကုဒ်သည် ကံမကောင်းစွာဖြင့်၊ ဖော်ပြချက်တစ်ခုမျှသာဖြစ်သော်လည်း၊ စနစ်၏ သရုပ်သဏ္ဍာန်မဟုတ်ပါ) ပေးပို့မှု ဆက်လက်လုပ်ဆောင်သွားပါမည်။ နောက် ... ပြီးတော့။ ယမန်နေ့က စီမံခန့်ခွဲသူများသည် အလေ့အကျင့်အသစ်များကို ကျွမ်းကျင်ပြီး DevOps အင်ဂျင်နီယာများအဖြစ် ဂုဏ်ယူစွာ ပြန်လည်လေ့ကျင့်ခဲ့ပြီး အရာအားလုံးသည် ထိုနေရာမှ ထွက်ခွာသွားခဲ့သည်။ ညနေစောင်းပြီး မနက်ခင်းလည်း ဖြစ်ခဲ့တယ်... တောင်းပန်ပါတယ်၊ အဲဒီကနေ မဟုတ်ပါဘူး။

အားလုံးမကောင်းတော့ဘူး၊ ဘုရားသခင်ကို ကျေးဇူးတင်တယ်။

အရာအားလုံး ငြိမ်သက်သွားကာ အမျိုးမျိုးသော ကောက်ကျစ်သော “နည်းစနစ်ပညာရှင်” များသည် DevOps အလေ့အကျင့်ဆိုင်ရာ စာအုပ်အထူများကို စတင်ရေးသားလာသည်နှင့်အမျှ နာမည်ဆိုးဖြင့်ကျော်ကြားသော DevOps အင်ဂျင်နီယာသည် မည်သူဖြစ်သည်နှင့် DevOps သည် ထုတ်လုပ်ရေးယဉ်ကျေးမှုတစ်ခုဖြစ်ကြောင်း တိတ်တဆိတ် ငြင်းခုံမှုများ ပေါ်ပေါက်လာသည်။ ရုတ်တရက်ဆိုသလိုပင် ဆော့ဖ်ဝဲလ်ပေးပို့ခြင်းသည် လုံးဝအသေးအဖွဲမဟုတ်သော အလုပ်တစ်ခုဖြစ်ကြောင်း ရုတ်တရက် ထွက်ပေါ်လာခဲ့သည်။ ဖွံ့ဖြိုးတိုးတက်မှုအခြေခံအဆောက်အအုံတစ်ခုစီတွင်၎င်း၏ကိုယ်ပိုင်အစုအပုံပါရှိပြီး၊ သင်စုစည်းရန်လိုအပ်သည့်နေရာ၊ ပတ်ဝန်းကျင်ကိုအသုံးပြုရန်လိုအပ်သည့်နေရာ၊ ဤနေရာတွင် Tomcat လိုအပ်သည်၊ ဤနေရာတွင် ၎င်းကိုစတင်ရန် လိမ္မာပြီး ရှုပ်ထွေးသောနည်းလမ်းတစ်ခု လိုအပ်သည် - ယေဘုယျအားဖြင့် သင့်ခေါင်းသည် တဒိန်းဒိန်းခုန်နေသည်။ ထူးဆန်းလောက်အောင်ပင် ပြဿနာသည် လုပ်ငန်းစဉ်များအဖွဲ့အစည်းတွင် အဓိကအားဖြင့် ပေါ်ပေါက်လာသည် - ဤပေးပို့ခြင်းလုပ်ဆောင်ချက်သည် တစ်ဆို့ခြင်းကဲ့သို့ လုပ်ငန်းစဉ်များကို ပိတ်ဆို့စပြုလာသည်။ ထို့အပြင် လည်ပတ်မှုများကို မည်သူမျှ ဖျက်သိမ်းခြင်းမရှိပေ။ V-model တွင် မမြင်နိုင်သော်လည်း ညာဘက်တွင် ဘဝစက်ဝန်းတစ်ခုလုံး ရှိနေသေးသည်။ ရလဒ်အနေဖြင့် အခြေခံအဆောက်အအုံကို တစ်နည်းနည်းဖြင့် ထိန်းသိမ်းရန်၊ စောင့်ကြည့်ကြပ်မတ်ရန်၊ အဖြစ်အပျက်များကို ဖြေရှင်းရန်နှင့် ပေးပို့ခြင်းကိုလည်း ကိုင်တွယ်ဖြေရှင်းရန် လိုအပ်ပါသည်။ အဲဒါတွေ။ ဖွံ့ဖြိုးတိုးတက်မှုနှင့် လည်ပတ်မှုနှစ်ခုစလုံးတွင် ခြေတစ်ဖက်ဖြင့်ထိုင်ပြီး ရုတ်တရက် ၎င်းသည် ဖွံ့ဖြိုးတိုးတက်ရေးနှင့် လည်ပတ်မှုဖြစ်လာသည်။ ထို့နောက် microservices များအတွက် ယေဘူယျ ကမောက်ကမ ဖြစ်ခဲ့ရသည်။ ၎င်းတို့နှင့်အတူ၊ ဒေသန္တရစက်များမှ ဖွံ့ဖြိုးတိုးတက်မှုသည် cloud သို့ ရွေ့လျားလာသည် - ဒေသအလိုက် တစ်ခုခုကို အမှားရှာကြည့်ရန်၊ အသေးစား ဝန်ဆောင်မှု ရာပေါင်းများစွာ ရှိနေပါက၊ အဆက်မပြတ် ပေးပို့ခြင်းသည် ရှင်သန်မှု နည်းလမ်းတစ်ခု ဖြစ်လာပါသည်။ “သေးငယ်တဲ့ ကုမ္ပဏီ” အတွက် အဆင်ပြေပေမယ့် ရှိသေးလား။ Google ကော။

Google မှ SRE

Google ကလာပြီး အကြီးဆုံး cacti ကိုစားပြီး ဆုံးဖြတ်ခဲ့တယ် - အဲဒါကို မလိုပါဘူး၊ စိတ်ချရဖို့ လိုတယ်။ ယုံကြည်စိတ်ချရမှုကို စီမံခန့်ခွဲရမည်။ ပြီးတော့ ယုံကြည်စိတ်ချရမှုကို စီမံခန့်ခွဲမယ့် အထူးကုဆရာဝန်တွေ လိုအပ်တယ်လို့ ကျွန်တော် ဆုံးဖြတ်ခဲ့ပါတယ်။ ငါသူတို့ကို SR အင်ဂျင်နီယာတွေခေါ်ပြီး ဒါ မင်းအတွက်ပဲ၊ ပုံမှန်အတိုင်း ကောင်းကောင်းလုပ်ပါလို့ ပြောလိုက်တယ်။ ဒီမှာ SLI၊ ဒီမှာ SLO၊ ဒီမှာ စောင့်ကြည့်နေပါတယ်။ ပြီးတော့ သူ့နှာခေါင်းကို ခွဲစိတ်တယ်။ ပြီးတော့ သူက သူ့ရဲ့ “ယုံကြည်စိတ်ချရတဲ့ DevOps” SRE လို့ခေါ်တယ်။ အားလုံးအဆင်ပြေပုံရတယ်၊ ဒါပေမယ့် Google တတ်နိုင်တဲ့ ညစ်ပတ်တဲ့ဟက်ခ်တစ်ခုရှိတယ် - SR အင်ဂျင်နီယာရာထူးအတွက်၊ အရည်အချင်းပြည့်မီတဲ့ developer တွေကို ငှားရမ်းပြီး အိမ်စာအနည်းငယ်လုပ်ကာ အလုပ်လုပ်တဲ့စနစ်တွေကို နားလည်ပါတယ်။ ထို့အပြင်၊ Google ကိုယ်တိုင်ကလည်း ထိုသို့သောလူများကို ငှားရမ်းရာတွင် ပြဿနာများ ရှိနေသည် - အဓိကအားဖြင့် ဤနေရာတွင် ၎င်းသည် သူ့ဘာသာသူ ယှဉ်ပြိုင်နိုင်သောကြောင့် - တစ်စုံတစ်ဦးအား စီးပွားရေးဆိုင်ရာ ယုတ္တိကို ဖော်ပြရန် လိုအပ်ပါသည်။ အင်ဂျင်နီယာများကို လွှတ်ပေးရန် တာဝန်ပေးအပ်ခြင်းခံရသည်၊ SR - အင်ဂျင်နီယာများသည် ယုံကြည်စိတ်ချရမှုကို စီမံခန့်ခွဲသည် (ဟုတ်ပါတယ်၊ တိုက်ရိုက်မဟုတ်ဘဲ အခြေခံအဆောက်အအုံကို လွှမ်းမိုးခြင်း၊ ဗိသုကာပညာကို ပြောင်းလဲခြင်း၊ အပြောင်းအလဲများကို ခြေရာခံခြင်းနှင့် ညွှန်းကိန်းများကို ကိုင်တွယ်ခြင်း၊ အဖြစ်အပျက်များကို ကိုင်တွယ်ဖြေရှင်းခြင်းဖြင့်)။ တော်တယ်၊ စာအုပ်များရေးပါ။. ဒါပေမယ့် သင်က Google မဟုတ်ပေမယ့် ယုံကြည်စိတ်ချရမှုက တစ်နည်းနည်းနဲ့ စိုးရိမ်စရာဖြစ်နေတုန်းပါပဲ။

DevOps စိတ်ကူးများ ဖွံ့ဖြိုးတိုးတက်ရေး

ထို့နောက်တွင် Docker ရောက်ရှိလာပြီး lxc မှ ပေါက်ဖွားလာသော၊ ထို့နောက် Docker Swarm နှင့် Kubernetes ကဲ့သို့သော အမျိုးမျိုးသော ကြိုးကိုင်မှုစနစ်များနှင့် DevOps အင်ဂျင်နီယာများက ရှူထုတ်လိုက်သည် - အလေ့အကျင့်များ၏ ပေါင်းစပ်မှုကို ရိုးရှင်းလွယ်ကူစေပါသည်။ deployment.yaml ဆိုသည်မှာ developer များထံသို့ outsource ပေးပို့ခြင်းပင် ဖြစ်နိုင်သည့်အတိုင်းအတာအထိ ရိုးရှင်းစေသည်။ Containerization သည် ပြဿနာကို ဖြေရှင်းပေးသည်။ ပြီးတော့ CI/CD စနစ်တွေရဲ့ ရင့်ကျက်မှုက ဖိုင်တစ်ဖိုင်ကို ရေးပြီးသွားပါပြီ - developer တွေက အဲဒါကို ကိုယ်တိုင် ကိုင်တွယ်နိုင်ပါတယ်။ ထို့နောက် ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ကိုယ်ပိုင် SRE ကို မည်သို့ပြုလုပ်ရမည်ကို ... သို့မဟုတ် အနည်းဆုံး တစ်စုံတစ်ဦးနှင့် စတင်ပြောဆိုကြသည်။

SRE သည် Google တွင်မရှိပါ။

ကောင်းပြီ၊ ကျွန်ုပ်တို့ ပေးပို့လိုက်ပါပြီ၊ ရှူထုတ်လိုက်နိုင်ပုံရပြီး ကောင်းသောနေ့ဟောင်းများဆီသို့ ပြန်သွားသည့်အခါ၊ အက်ဒ်မင်များသည် ပရိုဆက်ဆာအား ကြည့်ရှုကာ စနစ်များကို ချိန်ညှိကာ မတ်ခွက်များမှ နားမလည်နိုင်သော အရာများကို တိတ်တဆိတ် ငုံ့သောက်လိုက်သောအခါတွင် ... ရပ်လိုက်ပါ ။ ဒါဘာကြောင့်လဲ ဆိုတော့ ငါတို့က အရာအားလုံးကို စလုပ်ခဲ့တာမဟုတ်ဘူး (သနားစရာပဲ။) Google ၏ချဉ်းကပ်ပုံတွင် ကျွန်ုပ်တို့သည် ကောင်းမွန်သောအလေ့အကျင့်များကို အလွယ်တကူလက်ခံနိုင်သည် - ၎င်းသည် အရေးကြီးသော ပရိုဆက်ဆာဝန်မဟုတ်ပါ၊ ၎င်းတွင် ကျွန်ုပ်တို့သည် disk များကို အကြိမ်ရေမည်မျှပြောင်းလဲခြင်း သို့မဟုတ် cloud တွင် ကုန်ကျစရိတ်ကို အကောင်းဆုံးဖြစ်အောင်ပြုလုပ်ခြင်းမဟုတ်သော်လည်း စီးပွားရေးမက်ထရစ်များသည် အလားတူနာမည်ဆိုးဖြင့်ကျော်ကြားပါသည်။ SLx ၎င်းတို့ထံမှ အခြေခံအဆောက်အအုံစီမံခန့်ခွဲမှုကို မည်သူမျှ ဖယ်ရှားထားခြင်း မရှိသေးဘဲ၊ ၎င်းတို့သည် အဖြစ်အပျက်များကို ဖြေရှင်းရန် လိုအပ်ပြီး အခါအားလျော်စွာ တာဝန်ကျေပွန်အောင် ဆောင်ရွက်ကြပြီး ယေဘုယျအားဖြင့် လုပ်ငန်းလုပ်ငန်းစဉ်များတွင် ထိပ်ဆုံးမှနေရန် လိုအပ်ပါသည်။ ယောက်ျားလေးတို့၊ ကောင်းမွန်တဲ့ အဆင့်မှာ ဖြည်းဖြည်းချင်း ပရိုဂရမ်ရေးခြင်းကို စတင်ပါ၊ Google က သင့်ကို စောင့်နေပြီ ဖြစ်ပါတယ်။

အကျဉ်းချုပ်ရန်။ ရုတ်တရက်၊ သို့သော် သင်သည် စာဖတ်ရန် ငြီးငွေ့နေပြီဖြစ်ပြီး ဆောင်းပါးပါ မှတ်ချက်တစ်ခုတွင် စာရေးဆရာထံ တံတွေးထွေးပြီး စာရေးရန် မစောင့်နိုင်တော့ပေ။ DevOps သည် ပို့ဆောင်မှုအလေ့အကျင့်တစ်ခုအဖြစ် အမြဲတမ်းရှိခဲ့ပြီး ဖြစ်လိမ့်မည်။ ပြီးတော့ ဘယ်မှမသွားဘူး။ SRE သည် လုပ်ငန်းလည်ပတ်မှုအလေ့အကျင့်အစုတစ်ခုအနေဖြင့် ဤပေးပို့မှုကို အလွန်အောင်မြင်စေသည်။

source: www.habr.com