မိဘမဲ့ဝန်ဆောင်မှုများ- (မိုက်ခရို) ဝန်ဆောင်မှုဗိသုကာ၏ အားနည်းချက်

Banki.ru ပေါ်တယ်၏ လည်ပတ်မှု ဒါရိုက်တာ Andrey Nikolsky သည် ယမန်နှစ် ကွန်ဖရင့်တွင် ဟောပြောခဲ့သည်။ DevOpsDays မော်စကို မိဘမဲ့ဝန်ဆောင်မှုများအကြောင်း- အခြေခံအဆောက်အအုံရှိ မိဘမဲ့တစ်ဦးကို ခွဲခြားသတ်မှတ်နည်း၊ မိဘမဲ့ဝန်ဆောင်မှုများ အဘယ်ကြောင့် ညံ့ဖျင်းသနည်း၊ ၎င်းတို့နှင့် မည်သို့လုပ်ဆောင်ရမည်၊ ဘာမှမကူညီပါက ဘာလုပ်ရမည်နည်း။

ဖြတ်တောက်မှုအောက်တွင် အစီရင်ခံစာ၏ စာသားဗားရှင်းတစ်ခုဖြစ်သည်။

မင်္ဂလာပါ လုပ်ဖော်ကိုင်ဖက်များ။ ကျွန်တော့်နာမည် Andrey ပါ၊ Banki.ru မှာ လည်ပတ်နေပါတယ်။

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

ဝန်ဆောင်မှုများ၏အားသာချက်များ

ဝန်ဆောင်မှုတွေရဲ့ အားသာချက်တွေကို မြန်မြန်ကျော်သွားမယ်။

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

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

အသင်းတွေနဲ့ ကွဲလွဲမှုတွေရှိတယ်။ Developer တွေက မတူပါဘူး။ ဥပမာ ရှိတယ်၊ နှင်းပွင့်လူတွေ. ဒါကို Maxim Dorofeev နဲ့ ပထမဆုံးမြင်ဖူးတယ်။ တစ်ခါတစ်ရံတွင် နှင်းပွင့်များသည် အချို့အဖွဲ့များတွင်ရှိပြီး အခြားသူများအပေါ်တွင် မရှိပါ။ ၎င်းသည် ကုမ္ပဏီအနှံ့အသုံးပြုသည့် မတူညီသောဝန်ဆောင်မှုများကို အနည်းငယ်မညီမညာဖြစ်စေသည်။

ပုံကိုကြည့်ပါ- ဒါက developer ကောင်းကောင်းပါ၊ သူ့မှာ လက်ကြီးတယ်၊ သူအများကြီးလုပ်နိုင်တယ်။ အဓိကပြဿနာက ဒီလက်တွေ ဘယ်ကလာတာလဲ။

ဝန်ဆောင်မှုများသည် မတူညီသောလုပ်ငန်းဆောင်တာများအတွက် ပိုမိုသင့်လျော်သော ကွဲပြားသော ပရိုဂရမ်းမင်းဘာသာစကားများကို အသုံးပြုရန် ဖြစ်နိုင်ချေရှိသည်။ ဝန်ဆောင်မှုအချို့သည် Go တွင်ရှိပြီး အချို့မှာ Erlang တွင်ရှိပြီး အချို့မှာ Ruby တွင်ရှိပြီး၊ တစ်ခုခုသည် PHP ရှိ၊ တစ်ခုခုသည် Python တွင်ရှိသည်။ ယေဘုယျအားဖြင့် သင်သည် အလွန်ကျယ်ပြန့်စွာ ချဲ့ထွင်နိုင်သည်။ ဤနေရာတွင်လည်း ကွဲလွဲမှုများရှိပါသည်။

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

ဥပမာအားဖြင့်၊ သင့်တွင် ဝန်ဆောင်မှု 20 ခုရှိပြီး လက်ဖြင့်အသုံးချရန် လိုအပ်သည်၊ သင့်တွင် ကွန်ဆိုးလ် 20 ရှိပြီး နင်ဂျာကဲ့သို့ "enter" ကို တပြိုင်နက်နှိပ်ပါ။ သိပ်မကောင်းဘူး။

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

အကယ်၍ သင်သည် ရုရှားတွင် သီးခြား Amazon ဝန်ဆောင်မှုများနှင့် အလုပ်များကို အားကိုးပါက၊ လွန်ခဲ့သော နှစ်လခန့်က သင့်တွင် "အားလုံး မီးပျက်နေပြီ၊ ငါ အဆင်ပြေပါတယ်၊ အရာအားလုံး အေးဆေးပါပဲ"

ကျွန်ုပ်တို့သည် ဖြန့်ကျက်မှုကို အလိုအလျောက်လုပ်ဆောင်ရန် Ansible၊ Puppet for convergence၊ Bamboo သည် အလိုအလျောက်ဖြန့်ကျက်ရန်၊ နှင့် မြစ်ဆုံအားလုံးကို တစ်နည်းနည်းဖြင့် ဖော်ပြရန်အတွက် ကျွန်ုပ်တို့အသုံးပြုပါသည်။

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

ဥပမာအားဖြင့်၊ ဆာဗာပေါ်ရှိ Puppet သည် Ruby 2 နှင့် အလုပ်လုပ်သည့် ပြဿနာများ ရှိသော်လည်း အချို့သော အပလီကေးရှင်းများသည် Ruby 1.8 အတွက် ရေးသားထားသောကြောင့် ၎င်းတို့သည် အတူတူ အလုပ်မလုပ်ပါ။ အဲဒီမှာ တစ်ခုခုမှားနေပြီ။ စက်တစ်ခုတည်းတွင် Ruby ဗားရှင်းများစွာကို သင် run ရန် လိုအပ်သောအခါတွင် သင်သည် ပြဿနာများ စတင်တတ်သည်။

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

အဲဒီမှာ တစ်ခုခုအတွက် ပံ့ပိုးမှုနဲ့အတူ အထူးစုစည်းထားတဲ့ ပက်ကေ့ချ်အချို့ကို သင်လိုအပ်ပါတယ်။ တော်တော်ကြမ်းတယ်။ Docker ပုံသည် 45 GB အလေးချိန်ရှိသည့် အစီရင်ခံစာကို နားထောင်ခဲ့သည်။ Linux တွင်၊ ဟုတ်ပါတယ်၊ ၎င်းသည်ပိုမိုရိုးရှင်းသည်၊ အရာအားလုံးသည်သေးငယ်သည်၊ သို့သော်၊ နေရာအလုံအလောက်ရှိမည်မဟုတ်ပါ။

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

ကျွန်ုပ်တို့တွင် PHP 5.6 တွင် ဆိုက်များနှင့် ဝန်ဆောင်မှုများ ရှိသည်၊ ၎င်းတို့ကို ရှက်မိသော်လည်း ကျွန်ုပ်တို့ ဘာလုပ်နိုင်မည်နည်း။ ဤသည်မှာ ကျွန်ုပ်တို့၏ ဆိုဒ်တစ်ခုဖြစ်သည်။ PHP 7 တွင် ဆိုက်များနှင့် ဝန်ဆောင်မှုများ ရှိသည်၊ ၎င်းတို့တွင် ပိုများသည်၊ ၎င်းတို့ကို ကျွန်ုပ်တို့ မရှက်ပါ။ ပြီးတော့ developer တစ်ယောက်ချင်းစီမှာ သူပျော်ရွှင်စွာမြင်ရတဲ့ သူ့ကိုယ်ပိုင်အခြေခံရှိတယ်။

ကုမ္ပဏီတစ်ခုတွင် ဘာသာစကားတစ်ခုတည်းဖြင့် ရေးသားပါက developer တစ်ဦးလျှင် virtual machines သုံးလုံးသည် ပုံမှန်ဖြစ်သည်။ သင့်တွင် မတူညီသော ပရိုဂရမ်းမင်းဘာသာစကားများရှိပါက အခြေအနေ ပိုဆိုးလာသည်။

သင့်တွင် ဤဆိုက်များနှင့် ဝန်ဆောင်မှုများ ရှိပြီး၊ ၎င်းတွင် Go အတွက် အခြားဆိုက်၊ Ruby အတွက် ဆိုက်တစ်ခုနှင့် အခြား Redis တစ်ဖက်တွင် ရှိနေပါသည်။ ရလဒ်အနေဖြင့်၊ ဤအရာအားလုံးသည် အထောက်အပံ့အတွက် ကြီးမားသောနယ်ပယ်တစ်ခုအဖြစ်သို့ ပြောင်းလဲသွားပြီး အချို့သောအချိန်တိုင်း ကွဲသွားနိုင်သည်။

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

ဝန်ဆောင်မှုတစ်ခုစီတွင် ၎င်း၏ကိုယ်ပိုင်အဖွဲ့ရှိသည်။

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

ပံ့ပိုးကူညီမှုမှ အလုပ်များကို အလွယ်တကူ တင်သွင်းနိုင်သည်။ ဥပမာ အာမခံဝန်ဆောင်မှု ပျက်သွားတယ်။ ပြီးတော့ အာမခံနဲ့ ပတ်သက်တဲ့ အဖွဲ့ကလည်း ချက်ချင်း ပြင်ပေးတယ်။

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

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

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

အကယ်၍ အသင်းများသည် ရေပေါ်နေပါက (ကျွန်ုပ်တို့သည် တစ်ခါတစ်ရံ ၎င်းကိုအသုံးပြုသည်)၊ “ကြယ်မြေပုံ” ဟုခေါ်သော နည်းလမ်းကောင်းတစ်ခုရှိပါသည်။

သင့်တွင် ဝန်ဆောင်မှုများနှင့် လူများစာရင်းရှိသည်။ ခရေပွင့်ဆိုသည်မှာ လူသည် ဤဝန်ဆောင်မှုတွင် ကျွမ်းကျင်သူဖြစ်သည်၊ စာအုပ်ဆိုသည်မှာ လူသည် ဤဝန်ဆောင်မှုကို လေ့လာနေသည်ဟု ဆိုလိုသည်။ လူ၏တာဝန်မှာ ခရေပွင့်အတွက် စာအုပ်ငယ်ကို ပြောင်းရန်ဖြစ်သည်။ ဝန်ဆောင်မှု၏ရှေ့တွင် မည်သည့်အရာမျှ မရေးထားပါက ပြဿနာများ စတင်တော့မည်၊ ဆက်လက်၍ ဆွေးနွေးပါမည်။

မိဘမဲ့ဝန်ဆောင်မှုများ မည်သို့ပေါ်လာသနည်း။

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

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

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

မိဘမဲ့တစ်ဦးကို ဘယ်လိုခွဲခြားသိနိုင်မလဲ။

ဒီစာရင်းက အခြေအနေတွေကို ကောင်းကောင်းဖော်ပြတယ်။ သူတို့ရဲ့ အခြေခံအဆောက်အအုံနဲ့ ပတ်သက်ပြီး ဘယ်သူတွေ လေ့လာခဲ့လဲ။

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

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

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

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

မိဘမဲ့ဖြစ်စေမယ့် နောက်တစ်နည်းကတော့ "ကျွန်ုပ်တို့ အဲဒါကို အရင်းအနှီးနဲ့ လုပ်မယ်၊ ပိုမြန်မယ်၊ ပြီးရင် အဖွဲ့ကို လွှဲပေးမယ်။" လူတိုင်းမှာ အဖွဲ့ထဲမှာ အစီအစဥ်တွေရှိတယ်ဆိုတာ ရှင်းပါတယ်။ မကြာခဏဆိုသလို လုပ်ငန်းဖောက်သည်တစ်ဦးသည် ကုမ္ပဏီတွင်ရှိသော နည်းပညာဆိုင်ရာဌာနကဲ့သို့ ပြင်ပအရင်းအမြစ်ကို ဆောင်ရွက်ပေးမည်ဟု ထင်မြင်လေ့ရှိသည်။ သို့ပေမယ့်လည်း သူတို့ရဲ့ စိတ်အားထက်သန်မှုက ကွဲပြားပါတယ်။ Outsourcing တွင် ထူးဆန်းသော နည်းပညာဆိုင်ရာ ဖြေရှင်းချက်များနှင့် ထူးဆန်းသော အယ်လ်ဂိုရီသမ်ဖြေရှင်းနည်းများ ရှိပါသည်။

ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့တွင် မထင်မှတ်ထားသောနေရာများတွင် Sphinx ပါရှိသည့် ဝန်ဆောင်မှုတစ်ခုရှိသည်။ ငါဘာလုပ်ရမယ်ဆိုတာ နောက်မှပြောပြမယ်။

Outsourcers များတွင် ကိုယ်တိုင်ရေးထားသော မူဘောင်များရှိသည်။ ၎င်းသည် ယခင်ပရောဂျက်တစ်ခုမှ ကော်ပီကူးထည့်ထားသော PHP သက်သက်ဖြစ်ပြီး၊ အရာမျိုးစုံကို သင်ရှာဖွေနိုင်မည်ဖြစ်သည်။ ဖိုင်အချို့တွင် စာကြောင်းများစွာကို ပြောင်းလဲရန်အတွက် ရှုပ်ထွေးသော Bash scripts အချို့ကို အသုံးပြုရန် လိုအပ်သည့်အခါတွင် အသုံးချခြင်း scripts များသည် ကြီးမားသောအားနည်းချက်တစ်ခုဖြစ်ပြီး အဆိုပါ deployment scripts များကို တတိယမြောက် script ဟုခေါ်ပါသည်။ ရလဒ်အနေဖြင့် သင်သည် ဖြန့်ကျက်မှုစနစ်ကို ပြောင်းလဲပါ၊ အခြားတစ်ခုခုကို ရွေးချယ်ပါ၊ ခုန်ပါသော်လည်း သင့်ဝန်ဆောင်မှုသည် အလုပ်မဖြစ်ပါ။ အဘယ်ကြောင့်ဆိုသော် ထိုနေရာတွင် မတူညီသောဖိုင်တွဲများကြားတွင် နောက်ထပ်လင့်ခ် ၈ ခုကို ထည့်ထားရန် လိုအပ်သောကြောင့်ဖြစ်သည်။ သို့မဟုတ် မှတ်တမ်းတစ်ထောင် အလုပ်လုပ်သော်လည်း သိန်းတစ်ထောင် အလုပ်မဖြစ်တော့ပါ။

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

ဝန်ဆောင်မှုကို စစ်ဆေးရန် လိုအပ်ပြီး၊ ဝန်ဆောင်မှုကို ပြန်လည်သုံးသပ်ရန် လိုအပ်ပြီး၊ စကားဝှက်များကို ပြောင်းလဲရန် လိုအပ်ပါသည်။ ဝန်ဆောင်မှုတစ်ခုပေးသောအခါတွင် ကျွန်ုပ်တို့တွင် ကိစ္စတစ်ခုရှိပါသည်၊ "အကောင့်ဝင်မည်ဆိုပါက == 'admin' && password == 'admin'...'၊ ကုဒ်တွင် မှန်ကန်စွာရေးထားသည်။ ငါတို့ထိုင်ပြီးတွေးပြီး 2018 မှာ လူတွေရေးကြမလား။

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

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

ရှေ့ပြေးပရောဂျက်တစ်ခုကို ထုတ်ယူရန် ဆုံးဖြတ်သောအခါတွင် ကျွန်ုပ်တို့တွင် ကိစ္စတစ်ခုရှိသည်။

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

နောက်ထပ် ကြီးကျယ်သော အယူအဆတစ်ခု ရှိသေးသည် - ပြောက်ကျား ဖွံ့ဖြိုးတိုးတက်ရေး။ အချို့သောဌာန၊ များသောအားဖြင့် စျေးကွက်ရှာဖွေရေးဌာနသည် ယူဆချက်တစ်ခုကို စမ်းသပ်လိုပြီး ဝန်ဆောင်မှုတစ်ခုလုံးကို ပြင်ပမှ မှာယူသည့်အခါတွင် ဖြစ်သည်။ ယာဉ်အသွားအလာတွေ တဖွဲဖွဲကျလာပြီး စာရွက်စာတမ်းတွေကို ပိတ်လိုက်၊ ကန်ထရိုက်တာနဲ့ စာရွက်စာတမ်းတွေ လက်မှတ်ထိုးပြီး လုပ်ငန်းစပြီး “ဟေ့ကောင်၊ ငါတို့မှာ ဝန်ဆောင်မှုတစ်ခုရှိတယ်၊ လမ်းကြောင်းရှိနေပြီ၊ ငါတို့ကို ပိုက်ဆံယူတယ်၊ လက်ခံရအောင်” လို့ပြောလိုက်တယ်။ "Oppa ဘယ်လိုဖြစ်ရတာလဲ"

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

မိဘမဲ့ကလေးတွေမှာ ဘာပြဿနာရှိလဲ။

ဘယ်သူမသိဘူး၊ ဒါက ပစ်လွှတ်ပြီး ၅ မိနစ်အကြာမှာ နစ်မြုပ်သွားတယ်ဆိုတဲ့ အချက်ကြောင့် ဆွီဒင်မှာ မွေးမြူထားတဲ့ Wasa စစ်သင်္ဘော ဖြစ်ပါတယ်။ ဆွီဒင်ဘုရင်သည် ဤကိစ္စအတွက် ဘယ်သူ့ကိုမှ ကွပ်မျက်ခြင်းမပြုခဲ့ပေ။ ယင်းသင်္ဘောကို မည်သို့တည်ဆောက်ရမည်ကို မသိသော အင်ဂျင်နီယာမျိုးဆက်နှစ်ဆက်က တည်ဆောက်ခဲ့ခြင်းဖြစ်သည်။ သဘာဝအကျိုးသက်ရောက်မှု။

ဥပမာအားဖြင့်၊ ဘုရင်ကြီးသည် မုန်တိုင်းတစ်ခု တိုက်ခတ်နေချိန်တွင် သင်္ဘောသည် ပို၍ဆိုးရွားသောနည်းဖြင့် နစ်မြုပ်သွားနိုင်သည်။ Agile အဆိုအရ စောစောစီးစီး ကျရှုံးတာ ကောင်းပါတယ်။

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

မိဘမဲ့ဝန်ဆောင်မှုများသည် အဘယ်ကြောင့် အန္တရာယ်ရှိသနည်း။

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

မိဘမဲ့ဝန်ဆောင်မှုတွေနဲ့ ဘာလုပ်ရမလဲ။

ငါဘာလုပ်ရမလဲ ထပ်ပြောမယ်။ ပထမအချက်က စာရွက်စာတမ်းရှိရမယ်။ Banki.ru တွင် ၇ နှစ်ကြာ စမ်းသပ်သူများသည် developer များ၏ နှုတ်ကပတ်တော်များကို မယူသင့်ကြောင်း၊ လုပ်ငန်းဆောင်ရွက်မှုများသည် လူတိုင်း၏စကားကို မယူသင့်ကြောင်း သင်ကြားပေးခဲ့သည်။ စစ်ဆေးဖို့လိုတယ်။

ဒုတိယအနေဖြင့်၊ ကောင်းမွန်စွာလက်ခံရရှိခြင်းမရှိသောဝန်ဆောင်မှုများတွင်မည်သူမျှမဖော်ပြထားသောမှီခိုမှုများပါရှိသောကြောင့်အပြန်အလှန်ဆက်သွယ်မှုပုံကြမ်းများရေးသားရန်လိုအပ်သည်။ ဥပမာအားဖြင့်၊ developer များသည် Yandex.Maps သို့မဟုတ် Dadata အချို့တွင် ၎င်းတို့၏သော့ပေါ်တွင် ဝန်ဆောင်မှုကို ထည့်သွင်းခဲ့သည်။ သင်သည် အလကား ကန့်သတ်ချက် ပြည့်သွားပြီ၊ အရာအားလုံး ပျက်သွားကာ ဘာဖြစ်သွားသည်ကို လုံးဝ မသိပါ။ ထိုကဲ့သို့သော ကောက်နုတ်ချက်များအားလုံးကို ဖော်ပြရပါမည်- ဝန်ဆောင်မှုသည် Dadata၊ SMS၊ အခြားအရာများကို အသုံးပြုပါသည်။

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

ဗိသုကာအလုပ်များဖြင့် Sphinx အကြောင်း ဇာတ်လမ်းတစ်ပုဒ်ရှိခဲ့ပါသည်။ စာရင်းများထည့်ရန် ဝန်ဆောင်မှုများထဲမှတစ်ခုသည် Sphinx ကိုအသုံးပြုသည်။ အမျိုးအစားခွဲထားသောစာရင်းတစ်ခုမျှသာဖြစ်သော်လည်း ၎င်းကို ညတိုင်း ပြန်လည်ထည့်သွင်းထားသည်။ ၎င်းကို အညွှန်းနှစ်ခုမှ စုစည်းထားပါသည်- အကြီးကြီးတစ်ခုသည် ညတိုင်း အညွှန်းခံရပြီး ၎င်းနှင့် ကပ်ထားသော အညွှန်းငယ်တစ်ခုလည်း ရှိနေပါသည်။ နေ့တိုင်း၊ ဗုံးပေါက်ကွဲနိုင်သည်ဖြစ်စေ မဖြစ်စေရန် ဖြစ်နိုင်ခြေ 50% ဖြင့် တွက်ချက်နေစဉ်အတွင်း အညွှန်းသည် ပျက်သွားကာ ကျွန်ုပ်တို့၏သတင်းသည် ပင်မစာမျက်နှာတွင် မွမ်းမံမှုများ ရပ်သွားသည်။ အစပိုင်းတွင် အညွှန်းကို ပြန်လည်အညွှန်းပြုလုပ်ရန် 5 မိနစ်ကြာပြီးနောက် အညွှန်းကိန်းသည် ကြီးထွားလာပြီး တစ်ချိန်ချိန်တွင် ပြန်လည်ညွှန်းကိန်းပြုလုပ်ရန် မိနစ် 40 ကြာလာသည်။ ဒါကို ဖြတ်လိုက်တဲ့အခါ အချိန်နည်းနည်းကြာပြီး ကျွန်တော်တို့ရဲ့ အညွှန်းကိန်းကို အချိန်ပြည့် ပြန်ညွှန်းသွားမယ်ဆိုတာ ထင်ရှားတဲ့အတွက် သက်ပြင်းတစ်ချက်ချလိုက်ပါတယ်။ ဤသည်မှာ ကျွန်ုပ်တို့၏ ပေါ်တယ်အတွက် ပျက်ကွက်မှုဖြစ်လိမ့်မည်၊ ရှစ်နာရီကြာသည့်သတင်းမျှ မကြားရတော့ပါ - ဒါပဲ၊ လုပ်ငန်းက ရပ်တန့်သွားပါပြီ။

မိဘမဲ့ ဝန်ဆောင်မှုဖြင့် လုပ်ဆောင်ရန် စီစဉ်ပါ။

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

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

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

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

Yii 1 တွင် ဝန်ဆောင်မှုတစ်ခုကို ရယူလိုက်သောအခါတွင် ကျွန်ုပ်တို့သည် ၎င်းကို ဆက်လက်မဖွံ့ဖြိုးနိုင်တော့ကြောင်း သိရှိလိုက်ရပါသည်။ အကြောင်းမှာ Yii 1 တွင် ကောင်းမွန်စွာရေးနိုင်သော developer များ မကျန်တော့သောကြောင့် ဖြစ်သည်။ developer များအားလုံးသည် Symfony XNUMX တွင် ကောင်းမွန်စွာရေးကြသည်။ ဘာလုပ်မလဲ? ကျွန်ုပ်တို့သည် အချိန်ခွဲဝေပေးသည်၊ အဖွဲ့တစ်ဖွဲ့ကို ခွဲဝေပေးသည်၊ မန်နေဂျာတစ်ဦးကို ခွဲဝေပေးသည်၊ ပရောဂျက်ကို ပြန်လည်ရေးသားကာ ၎င်းသို့ ချောမွေ့စွာ လမ်းကြောင်းပြောင်းသွားပါသည်။

၎င်းပြီးနောက်၊ ဝန်ဆောင်မှုဟောင်းကိုဖျက်နိုင်သည်။ စီစဉ်သတ်မှတ်မှု စီမံခန့်ခွဲမှုစနစ်မှ ဝန်ဆောင်မှုအချို့ကို ဖယ်ရှားရှင်းလင်းရန် လိုအပ်သည့်အခါတွင် ဤသည်မှာ ကျွန်ုပ်အနှစ်သက်ဆုံး လုပ်ငန်းစဉ်ဖြစ်သည်၊ ထို့ကြောင့် developer များသည် မည်သည့်သဲလွန်စမျှမကျန်စေရန်အတွက် ထုတ်လုပ်ရေးတွင်ရှိသော ကားအားလုံးကို ပိတ်ထားလိုက်ပြီဖြစ်သည်။ repository သည် Git တွင် ကျန်ရှိနေပါသည်။

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

သင်ပေါင်းစည်းထားသော ဘာသာစကားများဟု ဆလိုက်များက ပြောသည်။ ဥပမာတစ်ခုက ပုံများကို အရွယ်အစားပြောင်းခြင်း ဖြစ်သည်။ ဘာသာစကားတစ်ခုတည်းကို တင်းကျပ်စွာကန့်သတ်ရန် အမှန်တကယ်လိုအပ်ပါသလား။ PHP တွင် ပုံပြောင်းခြင်းအား Golang တွင် အမှန်တကယ်လုပ်ဆောင်နိုင်သောကြောင့်ဖြစ်သည်။

အမှန်မှာ၊ ကျင့်ထုံးအားလုံးကဲ့သို့ ရွေးချယ်နိုင်သည် ။ ဖြစ်ကောင်းဖြစ်နိုင်၊ အချို့ကိစ္စများတွင်၊ ၎င်းသည်ပင်မလိုလားအပ်ပေ။ ဒါပေမယ့် သင့်မှာ လူ 50 ရှိတဲ့ ကုမ္ပဏီမှာ နည်းပညာဌာနတစ်ခုရှိမယ်ဆိုရင် 45 က PHP အထူးကျွမ်းကျင်သူတွေဖြစ်ပြီး နောက်ထပ် 3 ယောက်ကတော့ Python, Ansible, Puppet နဲ့ အဲလိုမျိုးတွေကို သိနားလည်ထားဖို့ လိုပါတယ်၊ ပြီးတော့ သူတို့ထဲက တစ်ယောက်ကပဲ ရေးပေးတာပါ။ ဘာသာစကားတစ်မျိုးမျိုး Go image resizing service တစ်ချို့က ထွက်သွားတဲ့အခါ ကျွမ်းကျင်မှုတွေက ပါပါတယ်။ တစ်ချိန်တည်းမှာပင်၊ အထူးသဖြင့် ၎င်းသည် ရှားပါးပါက ဤဘာသာစကားကို သိသော စျေးကွက်-သတ်သတ်မှတ်မှတ် developer တစ်ဦးကို ရှာဖွေရန် လိုအပ်ပါသည်။ ဆိုလိုတာက အဖွဲ့အစည်းအမြင်အရ ဒါက ပြဿနာပါ။ ကျယ်ကျယ်ပြန့်ပြန့် ရှုထောင့်မှကြည့်လျှင် သင်သည် ဝန်ဆောင်မှုများကို အသုံးချရန် သင်အသုံးပြုသည့် အဆင်သင့်လုပ်ထားသော ပလေးစာအုပ်အချို့ကို ပုံတူကူးရန် မလိုအပ်ဘဲ ၎င်းတို့အားလုံးကို ထပ်မံရေးသားရမည်ဖြစ်ပါသည်။

ကျွန်ုပ်တို့သည် လောလောဆယ် Node.js တွင် ဝန်ဆောင်မှုတစ်ခုကို တည်ဆောက်နေပြီး ၎င်းသည် သီးခြားဘာသာစကားဖြင့် developer တစ်ခုစီအတွက် အနီးနားရှိ ပလပ်ဖောင်းတစ်ခုသာဖြစ်ပါမည်။ ဒါပေမယ့် ငါတို့ထိုင်ပြီး ဒီဂိမ်းက ဆီမီးဖိုးပဲလို့ ထင်ခဲ့တာ။ ဆိုလိုတာက ဒီမေးခွန်းက မင်းထိုင်ပြီး စဉ်းစားရမယ့် မေးခွန်းပါ။

သင့်ဝန်ဆောင်မှုများကို သင်မည်ကဲ့သို့ စောင့်ကြည့်စစ်ဆေးသနည်း။ မှတ်တမ်းများကို သင်မည်ကဲ့သို့ စုဆောင်းပြီး စောင့်ကြည့်သနည်း။

ကျွန်ုပ်တို့သည် Elasticsearch တွင် မှတ်တမ်းများကို စုဆောင်းပြီး Kibana တွင် ထားရှိပြီး ၎င်းသည် ထုတ်လုပ်မှု သို့မဟုတ် စမ်းသပ်မှုပတ်ဝန်းကျင်အပေါ် မူတည်၍ မတူညီသော စုဆောင်းသူများကို ထိုနေရာတွင် အသုံးပြုပါသည်။ Lumberjack တစ်နေရာ၊ အခြားတစ်နေရာမှာ ကျွန်တော်မမှတ်မိဘူး။ Telegraf တပ်ဆင်ပြီး အခြားတစ်နေရာတွင် သီးခြားရိုက်ကူးသည့် ဝန်ဆောင်မှုအချို့တွင် အချို့နေရာများတွင် ရှိနေသေးသည်။

Puppet နှင့် Ansible တို့သည် တူညီသောပတ်ဝန်းကျင်တွင် မည်သို့နေထိုင်ကြမည်နည်း။

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

လိုက်ဖက်ညီအောင် ဘယ်လိုထိန်းသိမ်းမလဲ။ သင့်တွင် Ansible နှင့် Puppet နှစ်မျိုးလုံးတွင် configuration များ ရှိပါသလား။

ဒါဟာ ကျွန်တော်တို့ရဲ့ ကြီးမားတဲ့ နာကျင်မှုပါပဲ၊ ကျွန်တော်တို့ လက်တွေနဲ့ လိုက်ဖက်ညီအောင် ထိန်းသိမ်းထားပြီး အခု တစ်နေရာရာကနေ ဘယ်လို ရှေ့ဆက်ရမလဲ ဆိုတာ စဉ်းစားပါ။ Puppet သည် ပက်ကေ့ဂျ်များကို ထုတ်ပြီး ထိုနေရာတွင် လင့်ခ်အချို့ကို ထိန်းသိမ်းထားကာ ဥပမာအားဖြင့် Ansible သည် ကုဒ်ကို ထုတ်ကာ ထိုနေရာတွင် နောက်ဆုံးပေါ် အပလီကေးရှင်း configs များကို ချိန်ညှိပေးပါသည်။

တင်ဆက်မှုသည် Ruby ဗားရှင်းအမျိုးမျိုးအကြောင်းဖြစ်သည်။ ဘာဖြေရှင်းချက်လဲ။

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

ဒီနှစ်ညီလာခံ DevOpsDays မော်စကို ဒီဇင်ဘာလ (၇)ရက်နေ့တွင် Technopolis ၌ ကျင်းပမည်ဖြစ်သည်။ ကျွန်ုပ်တို့သည် နိုဝင်ဘာ ၁၁ ရက်အထိ အစီရင်ခံစာအတွက် လျှောက်လွှာများကို လက်ခံနေပါသည်။ ရေးပါ။ စကားပြောချင်ရင် ကျွန်တော်တို့ကို။

သင်တန်းသားများအတွက် မှတ်ပုံတင်ခြင်းဖွင့်ပြီ၊ ကျွန်ုပ်တို့နှင့် ပူးပေါင်းလိုက်ပါ။

source: www.habr.com