DevOpsDays မော်စကိုကွန်ဖရင့်၏ ခြုံငုံသုံးသပ်ချက်- အစီရင်ခံစာ 6 ခုမှ ထိုးထွင်းအမြင်များ

တတိယအကြိမ် ညီလာခံကို ဒီဇင်ဘာ ၇ ရက်တွင် ကျင်းပခဲ့သည်။ DevOpsDays မော်စကိုMail.ru Cloud Solutions ၏ပံ့ပိုးမှုဖြင့် Moscow DevOps အသိုင်းအဝိုင်းမှ စီစဉ်မှု။ ထိပ်တန်း DevOps လေ့ကျင့်သူများထံမှ အစီရင်ခံစာများအပြင် ပါဝင်သူများသည် Lightning လှုံ့ဆော်ပေးသည့် တိုတောင်းသော ဆွေးနွေးပွဲများ၊ အလုပ်ရုံဆွေးနွေးပွဲများနှင့် ပွင့်လင်းသောနေရာများတွင် စကားပြောခန်းများကို တက်ရောက်နိုင်ပါသည်။

ကျွန်ုပ်တို့သည် ဆွေးနွေးပွဲခြောက်ခုမှ အဓိကကျသော ထိုးထွင်းသိမြင်မှုကို စုဆောင်းပြီး ဆွေးနွေးပွဲများကျော်လွန်သွားသည်များကို ပိုမိုလေ့လာရန် စပီကာများစွာကို တွေ့ဆုံမေးမြန်းခဲ့ပါသည်။

အတွင်း-

1. Baruch Sadogursky, JFrog- "ဆော့ဖ်ဝဲလ်ကို ရောင်းချသူမှ အရည်ကဲ့သို့ အသုံးပြုသူဆီသို့ စီးဆင်းပါစေ"
2. Pavel Selivanov၊ Southbridge - "Dev နှင့် Ops တို့သည် အလုပ်ဖြစ်နိုင်သော ထုတ်ကုန်တစ်ခုဖန်တီးရန် ဘုံအလုပ်တစ်ခုရှိသည်"
3. Vladimir Utratenko, X5 လက်လီရောင်းချမှုအုပ်စု- "လုပ်ငန်းတွင်းရှိ DevOps သည် နာကျင်မှုနှင့် မီးကင်းစင်သော ဖွံ့ဖြိုးတိုးတက်မှုဖြစ်သည်"
4. Sergey Puzyrev, Facebook - "ထုတ်လုပ်မှုအင်ဂျင်နီယာတစ်ဦးသည် ဝန်ဆောင်မှုတစ်ခုလုံးကို ဂရုစိုက်သည်- သုံးစွဲသူနှင့် developer နှစ်ဦးစလုံး စိတ်ချမ်းသာစေရန်"
5. Mikhail Chinkov, AMBOSS - "ဌာနတစ်ခုက DevOps လမ်းကြောင်းကို မလိုက်နိုင်ဘူး၊ ကုမ္ပဏီတစ်ခုလုံးက အဲဒါကို လိုက်နာရမယ်"
6. Rosbank DevOps စိတ်အားထက်သန်သူများ- "သွေးစွန်းသောလုပ်ငန်းတွင် DevOps အကောင်အထည်ဖော်ရန် ရက်ပေါင်း 1000"

1. Baruch Sadogursky, JFrog - "ဆော့ဖ်ဝဲကို ရောင်းချသူထံမှ အရည်ကဲ့သို့ သုံးစွဲသူထံသို့ စီးဆင်းစေပါ"

ဆော့ဖ်ဝဲလ်မွမ်းမံမှု ချို့ယွင်းချက်များသည် နာရီတိုင်းနှင့် လူတိုင်းအတွက် ဖြစ်တတ်ပါသည်။ ဤတွင်တင်ဆက်မှုမှကြောက်စရာကောင်းသောဇာတ်လမ်းတစ်ပုဒ်သာဖြစ်သည်- Knight Capital သည် မအောင်မြင်သောအပ်ဒိတ်တစ်ခုပြီးနောက်တစ်နာရီအတွင်းဒေါ်လာသန်း ၄၄၀ ဆုံးရှုံးခဲ့သည်။

Baruch သည် မအောင်မြင်မှုများနှင့် အသုံးပြုသူမုန်းတီးမှုကို ရှောင်ရှားရန် ကူညီပေးမည့် စဉ်ဆက်မပြတ် မွမ်းမံမှုများ၏ DevOps ပုံစံများအကြောင်း ပြောဆိုခဲ့သည်

ပြည်တွင်းပြန်လှည့် — တစ်ခုခုဖြစ်သွားပါက ပြန်လှည့်ရန် သင့်စက်တွင် ဆော့ဖ်ဝဲ၏ ယခင်ဗားရှင်းကို ထားရှိပါ။ လေထဲတွင် patch မပို့နိုင်လောက်အောင် ဆိုးရွားလာပါက ၎င်းသည် သင့်အား ကာကွယ်ပေးပါသည်။

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

ဆက်တိုက်မွမ်းမံမှုများ — အင်္ဂါရပ်အသစ်တစ်ခုအဆင်သင့်ဖြစ်ပြီဆိုသည်နှင့် ဆော့ဖ်ဝဲကို စဉ်ဆက်မပြတ် အပ်ဒိတ်လုပ်ပါ။ ရှားပါးသောအပ်ဒိတ်များဖြင့်၊ အင်္ဂါရပ်များကို အုပ်စုဖွဲ့ထားသည်၊ အရေးကြီးသောအပ်ဒိတ်တစ်ခုသည် အရေးပါသောမွမ်းမံမှုများကို စောင့်နိုင်သည်။ Tesla ကဲ့သို့ပင် — ကျပန်းနှေးကွေးမှုများကို ပြုပြင်ရန် အပ်ဒိတ်တစ်ခုသည် စစ်တုရင်ဂိမ်းအတွက် အပ်ဒိတ်တစ်ခုကို စောင့်ဆိုင်းနေပါသည်။

အလိုအလျောက် ဖြန့်ကျက်မှု - လူတွေက လုပ်ရိုးလုပ်စဉ်အလုပ်တွေကို ညံ့ဖျင်းတာကြောင့် လူတွေကို စက်တွေနဲ့ အစားထိုးပါ။

မကြာခဏ အပ်ဒိတ်များ - အလေ့အကျင့်ကို မွေးမြူပြီး အကြောက်တရား ကင်းဝေးအောင် ကူညီပေးပါ။ ရှားပါးသောအပ်ဒိတ်များသည် အရေးပေါ်ဖြစ်ရပ်အဖြစ်သို့ ပြောင်းလဲသွားသည်။

စက်၏အခြေအနေကိုသိခြင်း။ - စမ်းသပ်အပ်ဒိတ်များကို အစမှ မတပ်ဆင်ပါ။ အပ်ဒိတ်များသည် စက်၏အခြေအနေပေါ်မူတည်၍ ကွဲပြားစွာလုပ်ဆောင်နိုင်သောကြောင့် ၎င်းသည် အရေးကြီးပါသည်။

Canary ထုတ်ဝေမှုများ - သုံးစွဲသူအနည်းစုထံသို့ အပ်ဒိတ်များကို ထုတ်ပြီး ကြည့်ရှုပါ။ ၎င်းသည် တစ်ခုခု မှားယွင်းပါက ပျက်စီးမှုကို လျော့နည်းစေသည်။

အပ်ဒိတ်များ မရရှိနိုင်ပါ။ — သုံးစွဲသူများသည် အင်္ဂါရပ်အသစ်များကိုသာ သတိပြုမိစေကာ၊ သင် အပ်ဒိတ်တစ်ခုထုတ်နေစဉ် ရက်သတ္တပတ်များစွာကြာအောင် ဝန်ဆောင်မှုမပါဘဲ ချန်မထားပါနှင့်။

DevOps ၏ ရုရှားနှင့် အနောက်တိုင်း IT တွင် ကွဲပြားသည့် အမြင်သည် Barukh Sadogursky နှင့် Cloud သည် မကြာမီ ကျွန်ုပ်တို့အတွက် အရာအားလုံးကို လုပ်ဆောင်ပေးမည်၊ ဆော့ဖ်ဝဲလ်ဝန်ဆောင်မှုများအားလုံး aaS အစီအစဉ်သို့ လျှောကျလာမလား၊ အင်တာဗျူးကို ကြည့်ပါ-

2. Pavel Selivanov၊ Southbridge- "Dev နှင့် Ops တို့သည် အလုပ်ဖြစ်နိုင်သော ထုတ်ကုန်တစ်ခုကို ဖန်တီးရန် ဘုံတာဝန်တစ်ခုရှိသည်"

Kubernetes ကို အကောင်အထည်ဖော်ခြင်းသည် သင့်အား DevOps အောင်မြင်စေရန် မကူညီနိုင်သည့်အပြင်၊ ၎င်းသည် အရာအားလုံးကို ချိုးဖျက်နိုင်သည်။ Pavel မှ နည်းပညာများ (အမိုက်ဆုံးများပင်) သင့်ပြဿနာအားလုံးကို မဖြေရှင်းနိုင်ရခြင်းအကြောင်း ရှင်းပြခဲ့သည်-

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

DevOps အကောင်အထည်ဖော်ပြီးနောက် developer များသည် အပြောင်းအလဲများကို မလိုချင်ကြပါ။. ရလဒ်အနေဖြင့် Kubernetes နှင့် အလုပ်အသွားအလာသည် Dev မှ Ops ဆီသို့ အလုပ်များကို နံရံတစ်ခုပေါ်သို့ ပစ်ချခြင်းကဲ့သို့ ဆက်လက်တည်ရှိနေကာ၊ စံပြတစ်ခုမဟုတ်တော့ဘဲ — Git သည် ထိုကဲ့သို့ နံရံတစ်ခုဖြစ်လာသည်။ ဆော့ဖ်ဝဲအင်ဂျင်နီယာသည် ကုဒ်ကို ထိုနေရာတွင် ထားကာ ယခင်ကဲ့သို့ အလုပ်လုပ်ကာ စီမံခန့်ခွဲသူများတွင် Kubernetes၊ CI/CD နှင့် အခြားအရာအားလုံး ရှိသည်။

သို့သော် developer များသည် ပြောင်းလဲမှုများကို လက်ခံရန် လိုအပ်သည်။အက်ဒ်မင်များ ဘာလုပ်နေသည်ကို developer များက မသိကြပြီး၊ အက်ဒ်မင်များသည် developer များနှင့် ဘာဖြစ်နေသည်ကို မသိသောအခါတွင် ပြဿနာများ ဖန်တီးသည်။

developer များအတွက် ဘာမှမပြောင်းလဲခဲ့ပါက၊ အက်ပလီကေးရှင်း၏လုပ်ဆောင်ချက်သည် ၎င်းတို့၏တာဝန်ဖြစ်ကြောင်း သဘောပေါက်မည်မဟုတ် - အမျိုးမျိုးသောနည်းပညာဆိုင်ရာလှည့်ကွက်များသည် အလုပ်မဖြစ်ပါ။

DevOps နှင့် Kubernetes များ ထွန်းကားလာသည်နှင့်အမျှ၊ ဖွံ့ဖြိုးတိုးတက်မှုတွင် များစွာပြောင်းလဲသွားမည်ဖြစ်သည်။ Devs များသည် Ops တွင် အရည်အချင်းရှိသင့်ပြီး အပြန်အလှန်အားဖြင့် ကျွမ်းကျင်ရမည်။ ဤအထူးကုဆရာဝန်များသည် ၎င်းတို့၏ ကိုယ်ပိုင်အရည်အချင်းများ ရှိသော်လည်း ၎င်းတို့သည် တစ်ဦးနှင့်တစ်ဦး၏ အလုပ်ကို သတိပြုသင့်သည်။ Dev နှင့် Ops တို့သည် Kubernetes ကို အကောင်အထည်မဖော်မီ မိတ်ဆွေများဖြစ်ရန် လိုအပ်သည်၊ မဟုတ်ပါက သင့်တွင်ရှိသောအရာများကို ချိုးဖျက်သွားမည်ဖြစ်သည်။

Pavel Selivanov သည် 5 နှစ်အတွင်း Kubernetes တွင်ဖြစ်ပျက်လာမည့်အရာများနှင့်ခေတ်မီသောလုပ်ငန်းစဥ်တစ်ခုသည်နည်းပညာကိုတည်ဆောက်သင့်သည်အကြောင်းကိုပြောခဲ့သည် — အင်တာဗျူးကိုကြည့်ပါ-

3. Vladimir Utratenko, X5 လက်လီရောင်းချသည့်အုပ်စု- "လုပ်ငန်းတွင်းရှိ DevOps သည် နာကျင်မှုနှင့် မီးကင်းစင်သော ဖွံ့ဖြိုးတိုးတက်မှုဖြစ်သည်"

ကုမ္ပဏီများသည် ဖွံ့ဖြိုးတိုးတက်မှု နှေးကွေးလွန်းပြီး လက်တွေ့ဘဝနှင့် မကိုက်ညီကြောင်း သိရှိလာသောအခါတွင် ကုမ္ပဏီများ ပိုမိုကောင်းမွန်လာပြီး ပိုမိုမြန်ဆန်စွာ အကောင်အထည်ဖော်လိုသော ဆန္ဒရှိကြသည်။

ဗလာဒီမာက ၎င်းသည် မည်သို့ဖြစ်ပျက်ပုံနှင့် ဖမ်းမိခြင်းဖြစ်သည်ကို ရှင်းပြခဲ့သည်။

1. ပထမဦးစွာ ကုမ္ပဏီများသည် DevOps အင်ဂျင်နီယာကို ငှားရမ်းကြသည်။ ၎င်းသည် Senior System Administrator ဖြစ်သည်၊ သူသည် ထုတ်လုပ်မှုတွင် ဖြန့်ချိခြင်း၊ ဖွံ့ဖြိုးတိုးတက်မှုပတ်ဝန်းကျင်ကို စံချိန်စံညွှန်းသတ်မှတ်ခြင်း၊ အခြေခံအဆောက်အဦများသတ်မှတ်ခြင်း၊ အမျိုးမျိုးသောပြဿနာများကို ရှာဖွေခြင်းနှင့် ပြုပြင်ခြင်း၊ အလိုအလျောက်လုပ်ဆောင်ခြင်းလုပ်ငန်းစဉ်များနှင့် အခြားနည်းပညာဆိုင်ရာအလုပ်များကို လုပ်ဆောင်ခြင်းတွင် ပါ၀င်သည်။
2. ထို့နောက် DevOps အင်ဂျင်နီယာတစ်ဦးသည် မလုံလောက်တော့ဘဲ ကုမ္ပဏီမှ DevOps အဖွဲ့ကို ငှားရမ်းခဲ့သည်။ ဤသည်မှာ မတူကွဲပြားသော အင်ဂျင်နီယာများ၏ ကြိုးပမ်းအားထုတ်မှုများကို တစ်နေရာတည်းတွင် အာရုံစိုက်နိုင်စေမည့် အရည်အချင်းပြည့်မီသော ဗဟိုဌာနတစ်ခုဖြစ်သည်။
3. တကယ်တော့၊ DevOps အင်ဂျင်နီယာနှင့် DevOps အဖွဲ့များသည် DevOps အသွင်ပြောင်းခြင်း၏ ဆန့်ကျင်ဘက်ပုံစံများဖြစ်သည်။ DevOps သည် အလေ့အကျင့်များနှင့် ယဉ်ကျေးမှုအကြောင်းဖြစ်သောကြောင့်၊ နည်းပညာကုမ္ပဏီများ (SRE၊ Production Engineering) တွင်လည်း DevOps အကောင်အထည်ဖော်မှုများလည်း ရှိပါသည်။

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

စီးပွားရေးလုပ်ငန်းတစ်ခုသည် ဂိမ်းထဲသို့ဝင်ရောက်ပြီး DevOps တွင် ရင်းနှီးမြှုပ်နှံသည့်အခါ၊ ဖြစ်နိုင်ခြေရလဒ်များစွာရှိသည်- ထွက်ခွာချိန်တွင် အရာအားလုံးသည် ကွဲသွားလိမ့်မည်; ၎င်းသည် SRE/Production Engineering သို့မဟုတ် Embedded Ops အဖြစ် ကျန်ရှိနေမည်ဖြစ်သည်။ လုပ်ငန်းစဉ်များသည် လုပ်ငန်းမက်ထရစ်များအပေါ် အခြေခံသည့်အခါ ၎င်းသည် BizOps သို့ ရွှေ့သွားမည်ဖြစ်သည်။

ဗလာဒီမာ Utratenko က လုပ်ငန်းတွင်းရှိ DevOps အမှန်တကယ်မည်မျှ “သွေးထွက်သံယို” ဖြစ်နေကြောင်းနှင့် လက်လီအရောင်းဆိုင်ကြီးများတွင် လက်တွေ့လုပ်ဆောင်ပုံကို ပြောပြသည် — အင်တာဗျူးကို ကြည့်ရှုပါ။

4. Sergey Puzyrev၊ Facebook - "ထုတ်လုပ်မှုအင်ဂျင်နီယာတစ်ဦးသည် ဝန်ဆောင်မှုတစ်ခုလုံးကို ဂရုစိုက်သည်- သုံးစွဲသူများနှင့် developer နှစ်ဦးစလုံး စိတ်ချမ်းသာစေရန်"

Facebook သည် အစိတ်အပိုင်းများ၊ ဆာဗာများ၊ လူများ၊ ဒေတာစင်တာများ အများအပြားရှိသော ကုမ္ပဏီကြီးတစ်ခုဖြစ်သည်။ ၎င်း၏အရွယ်အစားကြီးမားသော်လည်း၊ ၎င်းသည်အလွန်မြန်ဆန်သည် - developer များသည်ဝန်ဆောင်မှုများကိုတစ်နေ့လျှင်အကြိမ်များစွာထုတ်နိုင်သည်။ Facebook သည်လည်း လျင်မြန်စွာ ကြီးထွားလာနေပြီး ၎င်းသည် သုံးစွဲသူများနှင့် ဆာဗာများ တိုးပွားလာရုံသာမက၊ developer အရေအတွက်လည်း တိုးလာကာ လုပ်ငန်းစဉ်များကို ရှုပ်ထွေးစေပါသည်။

Sergey က Facebook မှာ Production Engineer လုပ်နေတာတွေကို ရှင်းပြခဲ့ပါတယ်။

1. Production Engineer သည် ကုဒ်များစွာကို ရေးပေးသည်၊ သူ့တွင် system knowledge ရှိသည်- လည်ပတ်မှုစနစ်များ၊ ဖိုင်စနစ်များ၊ ဒေတာဘေ့စ်များ၊ ကွန်ရက်များနှင့် အခြားအရာများ ရှိရမည်။ သူသည် ဖြန့်ဝေသည့်စနစ်များနှင့် Reliability Engineering၊ ဆိုလိုသည်မှာ ထုတ်ကုန်၏ယုံကြည်စိတ်ချရမှုကို ပံ့ပိုးပေးရာတွင် အတွေ့အကြုံရှိရမည်။ သူသည် အချိန်မရွေး ဖုန်းခေါ်ဆိုနိုင်သည်ဟု ဆိုလိုသည်။
2. ထုတ်လုပ်မှု အင်ဂျင်နီယာသည် အဆင့်မြင့် ကျွမ်းကျင်မှုတွင် ဆော့ဖ်ဝဲအင်ဂျင်နီယာနှင့် ကွဲပြားသော်လည်း၊ အမှန်တကယ်တော့ Software Engineer ၏ မျိုးစိတ်ခွဲတစ်ခုဖြစ်သည်။ ဆော့ဖ်ဝဲအင်ဂျင်နီယာများသည် ကုဒ်များ ပိုများလာသဖြင့် ၎င်းတို့တွင် ဥပမာအားဖြင့် ဒေတာလုပ်ဆောင်ခြင်းဆိုင်ရာ အပိုကျွမ်းကျင်မှုများနှင့် ပတ်သက်နိုင်ပါသည်။ Facebook တွင်၊ ထိုကဲ့သို့သော အထူးကျွမ်းကျင်သူများထံ ဖုန်းခေါ်ဆိုရမည်ဖြစ်ပြီး လူအများအတွက် မနှစ်မြို့ဖွယ် အံ့သြစရာတစ်ခုဖြစ်လာသည်။
3. ကုမ္ပဏီတစ်ခုရှိ Production Engineer ၏ လိုအပ်ချက်များ၏ ပိရမစ်သည် ဆာဗာများကို စောင့်ကြည့်ခြင်းနှင့် ၎င်းတို့၏ ဘဝသံသရာ၊ ဆိုလိုသည်မှာ ဟာ့ဒ်ဝဲအသစ်များကို လက်ခံရရှိခြင်း၊ ၎င်းကို စတင်သတ်မှတ်ခြင်း၊ လည်ပတ်လုပ်ဆောင်ခြင်းတို့ဖြင့် စတင်သည်။ နောက်တစ်ဆင့်သည် ဝန်ဆောင်မှုအဆင့်တွင် အတူတူပင်ဖြစ်သည်- စောင့်ကြည့်ရေးဝန်ဆောင်မှုများနှင့် ၎င်းတို့၏ဘဝစက်ဝန်း။ ထို့နောက် ချောမွေ့သော အတိုင်းအတာနှင့် အဆင့်မြင့် စောင့်ကြည့်ခြင်း ထွက်ပေါ်လာသည်။ ဝန်ဆောင်မှုဘဝစက်ဝန်းကို အလိုအလျောက်လုပ်ဆောင်ပြီးနောက် ၎င်းတို့သည် အလိုအလျောက် အရွယ်အစားပြောင်းလဲခြင်းသို့ ဆက်သွားကြသည်။ နောက်ဆုံးအနေနဲ့၊ အတိုင်းအတာကိုထိရောက်စွာနဲ့ ကုမ္ပဏီက ငွေကြေးနဲ့ အရင်းအမြစ်တွေကို ချွေတာနိုင်အောင် ချိန်ညှိခြင်းကို လုပ်ဆောင်ရပါမယ်။

5. Mikhail Chinkov, AMBOSS - "DevOps လမ်းကြောင်းသည် ဌာနတစ်ခုတည်းဖြင့် လိုက်၍မရပါ၊ ကုမ္ပဏီတစ်ခုလုံးသည် ၎င်းကို လိုက်နာရမည်"

DevOps သည် စဉ်ဆက်မပြတ် ဖွံ့ဖြိုးတိုးတက်လာသည်ဟု Mikhail က ယုံကြည်သည်။ သင်သည် အချို့သောကိရိယာများကို အကောင်အထည်ဖော်ပြီး ထိုနေရာတွင် ရပ်၍မရပါ။ ကုမ္ပဏီများသည် DevOps ဖြစ်လာခြင်းမှ တားဆီးခြင်းနှင့် အလေ့အကျင့်များကို မည်သို့အကောင်အထည်ဖော်ရမည်နည်း။

DevOps နားလည်ခြင်းဆိုင်ရာ ကွဲပြားမှုများဧဝံဂေလိဆရာများမြင်သည့်အတိုင်း Canonical devops သည် မဏ္ဍိုင်ကြီး ၅ ခုပေါ်တွင် တည်သည်၊

• ယဉ်ကျေးမှု - လူများနှင့် ပူးပေါင်းဆောင်ရွက်ခြင်း၊
• အလိုအလျောက်စနစ် - ပုံမှန်လုပ်ငန်းဆောင်တာများကို လုပ်ငန်းအသွားအလာသို့ လွှဲအပ်ခြင်း၊
• ပျော့ပျောင်းသည် - အသုံးပြုသူထံသို့တန်ဖိုးများပေးပို့ရန်အာရုံစိုက်;
• မျှဝေခြင်း - စဉ်ဆက်မပြတ်အသိပညာဖလှယ်မှု;
• တိုင်းတာမှုများနှင့် ၎င်းတို့၏အကူအညီဖြင့် တုံ့ပြန်ချက်ရယူခြင်း။

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

DevOps စံသတ်မှတ်ခြင်း၏စိန်ခေါ်မှုများ. ထုတ်ကုန်ပန်းတိုင်များသည် ကုမ္ပဏီတိုင်းအတွက် ကွဲပြားပြီး စံသတ်မှတ်၍မရပါ။ ကုမ္ပဏီတစ်ခုရှိ DevOps ၏အခြေအနေသည် ကုမ္ပဏီကိုယ်တိုင်အပေါ်တွင်မူတည်သော်လည်း အတော်များများက ၎င်းကို နားမလည်ကြပြီး DevOps အင်ဂျင်နီယာတစ်ဦးကို ငှားရမ်းရန် လုံလောက်သည်ဟု ယုံကြည်ကြသည်။

ငါတို့ ဘာကြောင့် DevOps မဖြစ်သေးတာလဲ။ အဓိကပြဿနာနှစ်ခုရှိသည်။ Enterprise တွင်၎င်းသည်အဖွဲ့အစည်း၏ဖွံ့ဖြိုးတိုးတက်မှုနှေးကွေးခြင်းနှင့် ၀ န်ထမ်းထောင်ပေါင်းများစွာ၏ဦးခေါင်းရှိ vector ကိုပြောင်းလဲရန်အခက်အခဲရှိသည်။ စတင်တည်ထောင်သူများတွင် အသိပညာရင်းမြစ်များမရှိခြင်း၊ အသွင်ပြောင်းရန်အတွက် အရင်းအမြစ်များခွဲဝေပေးခြင်းဆိုင်ရာ ပြဿနာဖြစ်သည်။

ကုမ္ပဏီတစ်ခုရှိ DevOps ဖွံ့ဖြိုးတိုးတက်မှု အဆင့်များ:

• ပထမအချက်မှာ အခြေခံအဆောက်အအုံသည် cloud တွင်ရှိသော်လည်း၊ စီမံခန့်ခွဲသူ တစ်ဦး သို့မဟုတ် နှစ်ဦးမှလွဲ၍ မည်သူမျှ မည်သို့အလုပ်လုပ်သည်ကို မသိနိုင်ပါ။
• ဒုတိယအချက်မှာ အခြေခံအဆောက်အအုံသည် ပွင့်လင်းမြင်သာမှုရှိ၍ အင်ဂျင်နီယာများအားလုံး နားလည်နိုင်သော်လည်း လုပ်ငန်းစဉ်များသည် ချောမွေ့ခြင်းမရှိပေ။
• တတိယ - အင်ဂျင်နီယာများသည် တိုက်ရိုက်ဝန်ဆောင်မှုများကို လွတ်လပ်စွာဖွင့်ပြီး ပြုပြင်ခြင်း၊
• စတုတ္ထ - အင်ဂျင်နီယာများသည် ပင်မအခြေခံအဆောက်အအုံ၊ cloud တွင် ပွင့်လင်းမြင်သာသောကုဒ်အတွက် ဆန္ဒအလျောက် ပံ့ပိုးပေးကြပြီး ခလုတ်တစ်ချက်နှိပ်ခြင်းဖြင့် အသုံးပြုနိုင်မည်ဖြစ်သည်။

စံပြသတ်မှတ်မှုမှာ လူတိုင်းသည် အခြေခံအဆောက်အအုံကို ညီတူညီမျှဝင်ရောက်ခွင့်၊ အင်ဂျင်နီယာများအားလုံးသည် ထုတ်ကုန်ကို အသုံးပြုခွင့်ရှိပြီး ၎င်းတို့လုပ်ဆောင်နေသည်ကို နားလည်ရန်ဖြစ်သည်။

ယဉ်ကျေးမှုနှင့် နည်းပညာဆိုင်ရာ အင်္ဂါရပ်များအားလုံးကို ပိတ်ခြင်းဖြင့် ကုမ္ပဏီ၏ DevOps အသွင်ပြောင်းမှုသည် လုပ်ငန်းနှင့် ပလက်ဖောင်းမက်ထရစ်များမှ တုံ့ပြန်ချက်များကို ထည့်သွင်းစဉ်းစားမည်ဖြစ်သည်။

6. Rosbank DevOps ဝါသနာအိုးများ- "DevOps ကို သွေးစွန်းသော လုပ်ငန်းတွင် အကောင်အထည်ဖော်ရန် ရက်ပေါင်း 1000"

Rosbank မှ Yuri Bulich၊ Dina Maltseva၊ Evgeniy Pankov က ၎င်းတို့သည် သုံးနှစ်အတွင်း DevOps သို့ ရောက်ရှိလာပုံကို ပြောပြခဲ့သည်။ ပန်းတိုင်နှစ်ခုရှိသည်- သီးခြားအသင်းများတွင် ပြဿနာများကိုဖြေရှင်းရန်နှင့် ဗဟိုချုပ်ကိုင်မှုဆိုင်ရာကိရိယာများကို အကောင်အထည်ဖော်ရန်။

ဤသည်မှာ အောင်မြင်သောရလဒ်များဖြစ်သည်။

ထုတ်ကုန်အဖွဲ့များအတွက် ရလဒ်များ- အဆ 30 ပိုမြန်သော တပ်ဆင်မှု၊ တပ်ဆင်မှု 6 ဆ ပိုမြန်သည်၊ လည်ပတ်မှုအပြည့်တွင် 30% အထိ ချွေတာနိုင်သည်။ ခလုတ်တစ်ချက်နှိပ်ရုံဖြင့် ထုတ်လုပ်မှုသို့ ကူးပြောင်းနိုင်သည့် စွမ်းရည်ရှိသည်။

ပလက်ဖောင်းအသင်းများအတွက် ရလဒ်များတပ်ဆင်ခြင်းနှင့် တပ်ဆင်ခြင်း 10 ဆ ပိုမြန်သည်၊ တပ်ဆင်မှု အရေအတွက် 87% တိုးလာပြီး autotest ဖြင့် 46% လွှမ်းခြုံထားသည်။ ပေါင်းစည်းရေးအဖွဲ့သည် တစ်ဆို့ခြင်းမဟုတ်တော့ပါ။

ဒီတော့ သွေးထွက်သံယို လုပ်ငန်းတစ်ခုမှာ DevOps အလေ့အကျင့်တွေကို သင် ဘယ်လို အကောင်အထည်ဖော်မလဲ။

ပထမဦးစွာ ရှေ့ပြေးပရောဂျက်ကို အကောင်အထည်ဖော်ပါ။: အဖွဲ့များကိုရွေးချယ်ပါ၊ ဗိသုကာပညာကို မည်သို့အကောင်အထည်ဖော်ရမည်ကို ဆုံးဖြတ်ပြီး ကိရိယာများကို ရွေးချယ်ပါ။ ဘဏ်တွင် တပ်ဆင်ခြင်းနှင့် ၎င်းတို့နှင့် လုပ်ဆောင်ရာတွင် ကျွမ်းကျင်မှုများနှင့်အတူ ပွင့်လင်းလိုင်စင်ဖြင့် ကိရိယာများကို ရွေးချယ်ထားပါသည်။ Rosbank သည် DevOps ပလပ်ဖောင်းကဲ့သို့ တစ်ချိန်တည်းတွင် ကိုယ်ပိုင် cloud တစ်ခုကို ဖြန့်ကျက်ထားပြီး၊ ၎င်းသည် အစတွင် ကူညီပေးခဲ့သည်။ cloud တွင်၊ ခလုတ်တစ်ချက်နှိပ်ရုံဖြင့် 15 မိနစ်အတွင်း လိုအပ်သောအရင်းအမြစ်များကို ရနိုင်သည်၊ ယခင်က ထိုသို့သောလုပ်ငန်းစဉ်သည် တစ်ပတ်ကြာနိုင်သည်။

ဘဏ်များနှင့် အခြားသော လုပ်ငန်းများတွင် ကန့်သတ်ချက်များကို သတင်းအချက်အလက် လုံခြုံရေးအဖွဲ့နှင့် ကြိုတင်လုပ်ဆောင်ပြီး အပြောင်းအလဲများကို အကောင်အထည် ဖော်ခွင့်ပြုမည့် အဖြေကို ရှာဖွေရန် လိုအပ်ပါသည်။

လေယာဉ်မှူးပြီးနောက်၊ အောင်မြင်သောဖြေရှင်းချက်ကို အတိုင်းအတာတစ်ခုအထိ မြှင့်တင်ရန် လိုအပ်သည်။.

1. ပိုက်လိုင်းကို တတ်နိုင်သမျှ "ဖြောင့်" ရန်၊ မလိုအပ်သော လင့်ခ်များကို ဖယ်ရှားရန်၊ တန်ဖိုးပေးသူများကို ဖော်ထုတ်ရန်နှင့် ကျန်အစိတ်အပိုင်းများကို ဖယ်ရှားရန် အရေးကြီးသည်။ အလယ်အလတ်လင့်ခ်များသည် ဆန့်ကျင်ဘက်ပုံစံများဖြစ်သည်။ ဥပမာအားဖြင့်၊ Rosbank တွင် အသင်းအဖွဲ့အများအပြားတွင် အတွင်းပိုင်းဖွံ့ဖြိုးတိုးတက်မှု အဆင်မပြေခဲ့ဘဲ ပြင်ပဖွံ့ဖြိုးတိုးတက်မှုသာ ကျန်ရှိတော့သည်။ ယင်းကြောင့် ပြင်ပဆော့ဖ်ဝဲအင်ဂျင်နီယာများမှ ကုဒ်များကို အတွင်းပိုင်းသို့ လွှဲပြောင်းပေးသည့် သီးသန့် DevOps အဖွဲ့တစ်ခု ပေါ်ပေါက်လာခဲ့သည်။ ပြင်ပဖွံ့ဖြိုးမှုကို CI/CD တွင် ပေါင်းစပ်ခြင်းဖြင့် ပြဿနာကို ဖြေရှင်းနိုင်သည်၊ ထို့ကြောင့် ၎င်းတို့သည် ၎င်းတို့ကိုယ်မှ ဘဏ်သို့ ကုဒ်လွှဲပြောင်းရုံသာမက ၎င်း၏အောင်မြင်မှုအတွက်လည်း တာဝန်ရှိပါသည်။
2. ရင့်ကျက်မှုပုံစံတွင် DevOps အလေ့အကျင့်များ၊ စာရင်းသွင်းကိရိယာများပါ၀င်ပြီး ပြင်ပပေးသွင်းသူများနှင့် လက်တွဲလုပ်ဆောင်ခြင်းဆိုင်ရာ တိကျချက်များကို ထည့်သွင်းစဉ်းစားသည် - ၎င်းသည် နောက်ပိုင်းတွင် အဖွဲ့အသစ်များတွင် အကောင်အထည်ဖော်သည့်အခါ အလုပ်များ၏နောက်ကျောကို လျင်မြန်စွာဖြတ်တောက်နိုင်ခဲ့သည်။
3. ပျော့ပျောင်းသော ထိန်းချုပ်မှုပုံစံနှင့် အကြံပြုချက်များဖြင့် အုပ်ချုပ်မှု လိုအပ်ပါသည်။ DevOps လက်စွဲစာအုပ်သည် ကောင်းမွန်စွာအလုပ်လုပ်သည် - ၎င်းသည် အဖွဲ့များအား ပလက်ဖောင်းကို မှန်ကန်စွာအသုံးပြုရန် ကူညီပေးသည့် အဖွဲ့အစည်းဆိုင်ရာနှင့် တူရိယာလက္ခဏာများအစုအဝေးတစ်ခုဖြစ်သည်။
4. ယဉ်ကျေးမှုကို ချက်ခြင်းအာရုံစိုက်ပြီး အပြောင်းအလဲများစွာ မြန်ဆန်လွယ်ကူလာမည်ဖြစ်သည်။ အတွင်းအသိုက်အဝန်းတစ်ခု တိုးလာရန်၊ တွေ့ဆုံပွဲများ၊ နည်းပညာဆိုင်ရာ အလုပ်ရုံဆွေးနွေးပွဲများ၊ လေ့ကျင့်မှုများ၊ ပျော်ရွှင်စရာ လှုပ်ရှားမှုများ ပြုလုပ်ပါ။ ဤအရာသည် အသီးအနှံများဖြစ်သည်- လူအများသည် အလေ့အကျင့်များကို မျှဝေကြသည်၊ ဘယ်သူလုပ်ခဲ့သည်ကို မြင်သည်၊ ဘယ်ကိုသွားရမည်ကို သိသည်၊ ကုမ္ပဏီအတွင်းတွင် ဖောင်းပွနေပြီး ကျန်းမာသော ပြိုင်ဆိုင်မှုများ ရှိနေသည်။
5. လုပ်ငန်းစဉ်တွင် မပါဝင်သူများနှင့် လုံလောက်သော ရင့်ကျက်မှု မရှိသော အဖွဲ့များဖြင့် လုပ်ဆောင်ရာတွင် အရေးမကြီးပါ။ စိတ်ဝင်စားသောအသင်းများနှင့် သစ္စာရှိသူများ၌ ရင်းနှီးမြုပ်နှံခြင်းသည် ပိုကောင်းသည်။
6. ရွေးချယ်ထားသော ဖြေရှင်းနည်းသည် ၎င်းကိုအသုံးပြုသော အင်ဂျင်နီယာများအတွက် အဆင်ပြေစေရမည်။
7. ပြင်ပဖွံ့ဖြိုးတိုးတက်မှုသည် ပိတ်ဆို့တားဆီးမှုတစ်ခုမဟုတ်ပါ။ အလေ့အကျင့်များကို ထိုနေရာတွင်လည်း အကောင်အထည်ဖော်နိုင်သည်၊ အဓိကအချက်မှာ အသင်းကိုယ်တိုင်က ဆန္ဒရှိသည်။

နည်းနည်းလေး ပိုအကျိုးရှိတယ်။

Alexander Chistyakov, vdsina.ru မှ DevOps ရှိသူများအတွက် ဖတ်သင့်သော စာအုပ်များစာရင်း။

1. Irina Yakutenko "ဆန္ဒနှင့်ကိုယ်ပိုင်ထိန်းချုပ်မှု" ။
2. Daniel Kahneman "စဉ်းစားခြင်း၊ မြန်ခြင်းနှင့်နှေးကွေးခြင်း"။
3. Barbara Oakley "နံပါတ်များအတွက်စိတ်"
4. Maxim Dorofeev "Jedi နည်းပညာများ" ။
5. Viktor Frankl "လူသား၏အဓိပ္ပါယ်ကိုရှာဖွေခြင်း"

ဆက်ပြီးနားထောင်ပါ

ကျွန်ုပ်တို့လည်း DevOps ကိုနှစ်သက်သည်။ အပိုင်းကြေငြာချက်များကို စောင့်မျှော်ကြည့်ရှုပါ။ @DevOps ကျွန်ုပ်တို့၏ Telegram ချန်နယ်ရှိ အခြားသော Mail.ru Cloud Solutions ဖြစ်ရပ်များနှင့် @Kubernetes၊ t.me/k8s_mail

source: www.habr.com