Ansible ဖြင့် ဒစ်ခ်အစားထိုးခြင်းကို အလိုအလျောက်လုပ်ဆောင်ခြင်း။

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

ဤဆောင်းပါးသည် ဘာသာပြန်တစ်မျိုးဖြစ်သည်။ ဖျော်ဖြေပွဲ HighLoad+ 2018 တွင်

disk အစားထိုးခြင်းလုပ်ငန်းစဉ်ကိုတည်ဆောက်ခြင်း။

ပထမဆုံး ဂဏန်းအချို့

OK သည် လူသန်းပေါင်းများစွာအသုံးပြုသည့် ဧရာမဝန်ဆောင်မှုတစ်ခုဖြစ်သည်။ မတူညီသောဒေတာစင်တာ 7 ခုတွင်တည်ရှိသောဆာဗာ 4 ခန့်ကဝန်ဆောင်မှုပေးသည်။ ဆာဗာများတွင် disk ပေါင်း 70 ကျော်ပါဝင်သည်။ ၎င်းတို့ကို တစ်ခုနှင့်တစ်ခု ထိပ်တွင် ချိတ်ထားပါက သင်သည် အမြင့် 1 ကီလိုမီတာထက် ပိုသော တာဝါတစ်ခု ရရှိမည်ဖြစ်သည်။

ဟာ့ဒ်ဒရိုက်များသည် မကြာခဏဆိုသလို ပျက်ကွက်သည့် ဆာဗာအစိတ်အပိုင်းများဖြစ်သည်။ ထိုသို့သော volumes များဖြင့် ကျွန်ုပ်တို့သည် တစ်ပတ်လျှင် disk 30 ခန့်ကို ပြောင်းလဲရမည်ဖြစ်ပြီး၊ ဤလုပ်ထုံးလုပ်နည်းသည် အလွန်သာယာသော လုပ်ရိုးလုပ်စဉ်တစ်ခု ဖြစ်လာပါသည်။

အဖြစ်အပျက်များ

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

သိုလှောင်ကိရိယာများသည် ချွင်းချက်မရှိပါ။ သူတို့ရဲ့ အခြေအနေကို Zabbix က စောင့်ကြည့်နေပါတယ်။ ကျွန်ုပ်တို့သည် Syslog တွင် စာရေးခြင်း/ဖတ်ရှုခြင်း အမှားအယွင်းများအတွက် စောင့်ကြည့်စစ်ဆေးခြင်း၊ HW/SW စီးနင်းမှုများ၏ အခြေအနေကို ခွဲခြမ်းစိတ်ဖြာခြင်း၊ SMART စောင့်ကြည့်ခြင်းနှင့် SSDs အတွက် ဝတ်ဆင်မှုကို တွက်ချက်ပါသည်။

အရင်တုံးက ဘယ်လိုပြောင်းလဲ။

Zabbix တွင် အစပျိုးမှုတစ်ခု ဖြစ်ပေါ်သည့်အခါ Jira တွင် အဖြစ်အပျက်တစ်ခုကို ဖန်တီးပြီး ဒေတာစင်တာများရှိ သင့်လျော်သော အင်ဂျင်နီယာများထံ အလိုအလျောက် သတ်မှတ်ပေးပါသည်။ ကျွန်ုပ်တို့သည် HW ဖြစ်ရပ်များအားလုံး၊ ဆိုလိုသည်မှာ ဒေတာစင်တာရှိ စက်ကိရိယာများနှင့် မည်သည့်ရုပ်ပိုင်းဆိုင်ရာလုပ်ဆောင်မှုမဆို လိုအပ်သည့်အရာများနှင့် လုပ်ဆောင်သည်။
ဒေတာစင်တာ အင်ဂျင်နီယာသည် ဟာ့ဒ်ဝဲနှင့် ပတ်သက်သည့် ပြဿနာများကို ဖြေရှင်းပေးသည့် ပုဂ္ဂိုလ်ဖြစ်ပြီး ဆာဗာများကို တပ်ဆင်ခြင်း၊ ထိန်းသိမ်းခြင်းနှင့် ဖျက်သိမ်းခြင်းတို့အတွက် တာဝန်ရှိပါသည်။ လက်မှတ်ရပြီး အင်ဂျင်နီယာက အလုပ်ဝင်တယ်။ ဒစ်ခ်စင်များတွင် သူသည် ဒစ်ခ်များကို လွတ်လပ်စွာပြောင်းသည်။ သို့သော် လိုအပ်သောစက်ပစ္စည်းကို သုံးစွဲခွင့်မရပါက၊ အင်ဂျင်နီယာသည် တာဝန်ကျသော စနစ်စီမံခန့်ခွဲသူများထံ အကူအညီတောင်းခံသည်။ ပထမဦးစွာ၊ သင်လည်ပတ်မှုမှ disk ကိုဖယ်ရှားရန်လိုအပ်သည်။ ၎င်းကိုလုပ်ဆောင်ရန်၊ သင်သည် ဆာဗာပေါ်တွင် လိုအပ်သောပြောင်းလဲမှုများပြုလုပ်ရန်၊ အပလီကေးရှင်းများကိုရပ်တန့်ရန်နှင့် disk ကိုဖြုတ်ချရန် လိုအပ်သည်။

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

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

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

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

အသစ်အစားထိုးခြင်းလုပ်ငန်းစဉ်

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

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

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

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

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

အရင်တုန်းက ဒီလိုမျိုး

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

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

အဆင့်အတန်းကိုလည်း ထည့်သွင်းထားပါတယ်။ အဆင်သင့်. ဒစ်ကို အစားထိုးပြီးနောက် လက်မှတ်ကို ၎င်းထံ လွှဲပြောင်းပေးသည်။ ဆိုလိုသည်မှာ၊ အားလုံးပြီးပြီးဖြစ်သည်၊ သို့သော် HW/SW RAID ကို ဆာဗာပေါ်တွင် ထပ်တူပြုထားသည်။ ဒါက တော်တော်ကြာနိုင်ပါတယ်။

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

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

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

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

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

ချတ်လုပ်ရန် မလိုအပ်ပါ။ ဟုတ်ပါတယ်၊ အက်ဒမင်က အင်ဂျင်နီယာကို “ဒါကို ပိုမြန်အောင် အစားထိုးဖို့လိုတယ်” ဒါမှမဟုတ် “ညနေပိုင်းရောက်နေပြီ၊ အစားထိုးဖို့ အချိန်ရှိလား” လို့ အင်ဂျင်နီယာထံ စာရေးနိုင်ပါတယ်။ သို့သော် ဤပြဿနာများအတွက် ကျွန်ုပ်တို့သည် နေ့စဉ်နှင့်အမျှ chats တွင် မဆက်သွယ်တော့ပါ။

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

Workflow တည်ဆောက်တဲ့အခါ သင်ခန်းစာများ

• လုပ်ထုံးလုပ်နည်းတစ်ခုတည်ဆောက်သောအခါ၊ ကွဲပြားခြားနားသောအရင်းအမြစ်များမှအချက်အလက်များကိုစုဆောင်းရန်လိုအပ်သည်။
  ကျွန်ုပ်တို့၏ စီမံခန့်ခွဲသူအချို့သည် အင်ဂျင်နီယာသည် ဒစ်ခ်များကို သူ့ကိုယ်သူ ပြောင်းလဲကြောင်း မသိပါ။ အချို့သောလူများက MD RAID ထပ်တူပြုခြင်းအား အင်ဂျင်နီယာများက ကိုင်တွယ်သည်ဟု ထင်ခဲ့ကြသော်လည်း အချို့မှာ ထိုသို့လုပ်ဆောင်ရန် အခွင့်မရှိကြပေ။ ထိပ်တန်းအင်ဂျင်နီယာအချို့က ထိုသို့လုပ်ဆောင်ခဲ့သော်လည်း မည်သည့်နေရာတွင်မှ ဖော်ပြခြင်းမရှိသောကြောင့် အမြဲတမ်းမဟုတ်ပေ။
• လုပ်ထုံးလုပ်နည်းသည် ရိုးရှင်းပြီး နားလည်နိုင်သည်။
  အဆင့်များစွာကို မှတ်ထားရန် လူတစ်ယောက်အတွက် ခက်ခဲသည်။ Jira ရှိ အရေးကြီးဆုံး အိမ်နီးချင်း အခြေအနေများကို ပင်မစခရင်ပေါ်တွင် ထားရှိသင့်သည်။ သင်သည် ၎င်းတို့အား အမည်ပြောင်းနိုင်သည်၊ ဥပမာ၊ ပြောင်းလဲရန် အသင့်ဖြစ်နေပြီဟု ကျွန်ုပ်တို့ခေါ်ဆိုပါသည်။ နှင့် အခြားအခြေအနေများကို မျက်စိညောင်းခြင်းမဖြစ်စေရန် drop-down menu တွင် ဝှက်ထားနိုင်ပါသည်။ ဒါပေမယ့် လူတွေကို ကန့်သတ်မထားဘဲ အသွင်ကူးပြောင်းရေးလုပ်ဖို့ အခွင့်အရေးပေးလိုက်တာ ပိုကောင်းပါတယ်။
  ဆန်းသစ်တီထွင်မှု၏တန်ဖိုးကို ရှင်းပြပါ။ လူတွေနားလည်လာတဲ့အခါ လုပ်ငန်းစဉ်အသစ်ကို ပိုလက်ခံလာကြတယ်။ လူများသည် လုပ်ငန်းစဉ်တစ်ခုလုံးကို မနှိပ်ဘဲ လိုက်နာရန် ကျွန်ုပ်တို့အတွက် အလွန်အရေးကြီးပါသည်။ ထို့နောက် ကျွန်ုပ်တို့သည် ဤအရာကို automation တည်ဆောက်ခဲ့သည်။
• စောင့်ပါ၊ ခွဲခြမ်းစိတ်ဖြာပါ၊ အဖြေရှာပါ။
  လုပ်ထုံးလုပ်နည်း၊ နည်းပညာပိုင်းဆိုင်ရာ အကောင်အထည်ဖော်မှု၊ အစည်းအဝေးများနှင့် ဆွေးနွေးမှုများ တည်ဆောက်ရန် အချိန်တစ်လခန့် အချိန်ယူခဲ့ရသည်။ အကောင်အထည်ဖော်ရန် သုံးလကျော်ကြာသည်။ လူတွေက ဆန်းသစ်တီထွင်မှုကို ဖြည်းဖြည်းချင်း စတင်အသုံးပြုလာကြတာကို ကျွန်တော်မြင်တယ်။ အစောပိုင်းအဆင့်တွေမှာ အဆိုးမြင်မှုတွေ အများကြီးရှိခဲ့တယ်။ သို့သော် ၎င်းသည် လုပ်ထုံးလုပ်နည်းကိုယ်တိုင်နှင့် ၎င်း၏နည်းပညာပိုင်းဆိုင်ရာ အကောင်အထည်ဖော်မှုတို့နှင့် လုံးဝကင်းကွာပါသည်။ ဥပမာအားဖြင့်၊ အက်ဒမင်တစ်ဦးသည် Jira ကိုအသုံးမပြုသော်လည်း မြစ်ဆုံရှိ Jira ပလပ်အင်ကို အသုံးပြု၍ အချို့အရာများသည် သူ့အတွက် မရနိုင်ပါ။ Jira ကို ကျွန်ုပ်တို့ပြသခဲ့ပြီး စီမံခန့်ခွဲသူ၏ ကုန်ထုတ်စွမ်းအားသည် ယေဘူယျအလုပ်များအတွက်ရော ဒစ်များကို အစားထိုးခြင်းအတွက်ရော တိုးမြှင့်ပေးပါသည်။

ဒစ်ခ်အစားထိုးခြင်းကို အလိုအလျောက်လုပ်ဆောင်ခြင်း။

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

ယခု ကျွန်ုပ်တို့၏ အစားထိုးခြင်းလုပ်ငန်းစဉ်ကို အဆင့်များအဖြစ် ပိုင်းခြားထားပြီး၊ တစ်ခုစီတွင် တိကျသောလုပ်ဆောင်သူနှင့် လုပ်ဆောင်ချက်များစာရင်းပါရှိသည့် အဆင့်များအတိုင်း ကျွန်ုပ်တို့သည် အဆင့်ဆင့်တွင် အလိုအလျောက်လုပ်ဆောင်ခြင်းကို လုပ်ဆောင်နိုင်သော်လည်း အားလုံးကို တစ်ပြိုင်နက် လုပ်ဆောင်နိုင်မည်မဟုတ်ပေ။ ဥပမာအားဖြင့်၊ အရိုးရှင်းဆုံးအဆင့် - Ready (RAID/data synchronization ကိုစစ်ဆေးခြင်း) ကို bot တစ်ခုသို့ အလွယ်တကူလွှဲအပ်နိုင်ပါသည်။ bot သည် အနည်းငယ်လေ့လာပြီးသောအခါ၊ သင်သည် ၎င်းကို ပို၍အရေးကြီးသောအလုပ်တစ်ခု ပေးနိုင်သည်။

တိရစ္ဆာန်ရုံ ဆက်တင်များ

ဘော့တ်အကြောင်း မပြောမီ၊ ကျွန်ုပ်တို့၏ တိရစ္ဆာန်ရုံများတွင် တပ်ဆင်မှုဆိုင်ရာ လေ့လာရေးခရီးတိုကို ကြည့်ကြပါစို့။ ပထမဦးစွာ၊ ကျွန်ုပ်တို့၏ အခြေခံအဆောက်အအုံ၏ ကြီးမားသော အရွယ်အစားကြောင့်ဖြစ်သည်။ ဒုတိယအနေဖြင့်၊ ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုတစ်ခုစီအတွက် အကောင်းဆုံးသော ဟာ့ဒ်ဝဲလ်ဖွဲ့စည်းမှုပုံစံကို ရွေးချယ်ရန် ကြိုးစားပါသည်။ ကျွန်ုပ်တို့တွင် ဟာ့ဒ်ဝဲ RAID မော်ဒယ် 20 ခန့်ရှိပြီး အများစုမှာ LSI နှင့် Adaptec ဖြစ်သော်လည်း မတူညီသော ဗားရှင်း HP နှင့် DELL များလည်း ရှိပါသည်။ RAID controller တစ်ခုစီတွင် ၎င်း၏ကိုယ်ပိုင်စီမံခန့်ခွဲမှု utility ရှိသည်။ အမိန့်အစုံနှင့် ၎င်းတို့ကိုထုတ်ပေးသည့် RAID ထိန်းချုပ်ကိရိယာတစ်ခုစီအတွက် ဗားရှင်းတစ်ခုနှင့်တစ်ခု ကွဲပြားနိုင်သည်။ HW-RAID ကို အသုံးမပြုပါက mdraid ကို အသုံးပြုနိုင်ပါသည်။

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

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

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

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

အထွေထွေအစီအစဉ်

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

Python ဖြင့်ရေးသားထားသော DiskoBot အပလီကေးရှင်းသည် လက်မှတ်အသစ်များအတွက် Jira ကို အခါအားလျော်စွာ စစ်တမ်းကောက်ယူသည်။ လုပ်ဆောင်နေသည့် လက်မှတ်အသစ်တစ်ခု ပေါ်လာသည်ကို သတိပြုမိသည်၊ ၎င်းသည် Ansible တွင် playbook ကိုဖွင့်ပေးသည် (၎င်းသည် Jira ရှိ အခြေအနေတစ်ခုစီအတွက် လုပ်ဆောင်သည်) နှင့်သက်ဆိုင်သော thread ကို အစပျိုးသည်။ ဤကိစ္စတွင်, Ready2change ကိုစတင်ခဲ့သည်။

Ansible သည် host သို့ပို့သည်၊ လည်ပတ်မှုမှ disk ကိုဖယ်ရှားပြီး Callbacks မှတဆင့်အပလီကေးရှင်းသို့အခြေအနေအားသတင်းပို့သည်။

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

အထက်တွင်ဖော်ပြထားသောအစီအစဉ်အရ၊ လက်မှတ်သည် အခြား playbook ကိုဖွင့်သည့် bot သို့ပြန်သွားကာ host သို့သွားကာ disk ကို လည်ပတ်စေပါသည်။ ဘော့တ်သည် လက်မှတ်ကို ပိတ်သည်။ ဟူး!

အခု System ရဲ့ အစိတ်အပိုင်းတစ်ချို့အကြောင်း ပြောကြည့်ရအောင်။

Diskobot

ဤလျှောက်လွှာကို Python ဖြင့်ရေးသားထားသည်။ JQL အရ Jira မှ လက်မှတ်များကို ရွေးချယ်သည်။ လက်မှတ်၏အခြေအနေပေါ် မူတည်၍ နောက်တစ်ခုသည် အခြေအနေနှင့်သက်ဆိုင်သည့် Ansible playbook ကိုဖွင့်ပေးသည့်သက်ဆိုင်ရာကိုင်တွယ်သူထံသို့သွားပါသည်။

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

jira_states:
  investigate:
    jql: '… status = Open and "Disk Size" is EMPTY'
    interval: 180

  inprogress:
    jql: '…  and "Disk Size" is not EMPTY and "Device Name" is not EMPTY'
 
  ready:
    jql: '… and (labels not in ("dbot_ignore") or labels is EMPTY)'
    interval: 7200

ဥပမာအားဖြင့်၊ လုပ်ဆောင်ဆဲအခြေအနေရှိ လက်မှတ်များကြားတွင်၊ ဖြည့်သွင်းထားသည့် Disk အရွယ်အစားနှင့် စက်ပစ္စည်းအမည်အကွက်များကိုသာ ရွေးချယ်ထားသည်။ စက်ပစ္စည်းအမည်သည် ပလေးစာအုပ်ကို လုပ်ဆောင်ရန် လိုအပ်သော ပိတ်ဆို့ကိရိယာ၏ အမည်ဖြစ်သည်။ အင်ဂျင်နီယာသည် မည်သည့်အရွယ်အစား disk လိုအပ်သည်ကို သိစေရန် ဒစ်ခ်အရွယ်အစား လိုအပ်သည်။

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

playbook တစ်ခု အဆင်မပြေပါက Jira သည် dbot_failed အညွှန်းကို နောက်မှ ခွဲခြမ်းစိတ်ဖြာနိုင်စေရန် ပြုလုပ်ပေးပါသည်။

Ansible နှင့် အပြန်အလှန်လုပ်ဆောင်နိုင်မှု

လျှောက်လွှာသည် Ansible မှတဆင့်ဆက်သွယ်သည်။ Ansible Python API. playbook_executor သို့ ကျွန်ုပ်တို့သည် ဖိုင်အမည်နှင့် variables အစုံကို ပေးပို့ပါသည်။ ၎င်းသည် သင့်အား Python ကုဒ်တွင် ဖော်ပြမည့်အစား Ansible ပရောဂျက်ကို ပုံမှန် yml ဖိုင်များအဖြစ် ထားရှိနိုင်စေမည်ဖြစ်သည်။

Ansible တွင်လည်း *extra_vars*၊ ပိတ်ဆို့ကိရိယာ၏အမည်၊ လက်မှတ်အခြေအနေအပြင် ပြဿနာသော့ပါရှိသော callback_url မှတဆင့် - ၎င်းကို HTTP တွင် ပြန်ခေါ်ရန်အတွက် အသုံးပြုပါသည်။

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

ဤသည်မှာ HTTP ပြန်ခေါ်ခြင်းကို အကောင်အထည်ဖော်သည့် အလုပ်တစ်ခု၏ ဥပမာတစ်ခုဖြစ်သည်။

callaback(s) ကို အသုံးပြု၍ playbook များကို လုပ်ဆောင်ခြင်း၏ ရလဒ်ကို ကျွန်ုပ်တို့ ရရှိပါသည်။ ၎င်းတို့သည် အမျိုးအစားနှစ်မျိုးရှိသည်။

• မရှိနိုင်သော ဖုန်းခေါ်ဆိုမှု ပလပ်အင်၊ ၎င်းသည် playbook ကွပ်မျက်မှုရလဒ်များအပေါ်ဒေတာကိုပေးသည်။ ၎င်းသည် စတင်လုပ်ဆောင်ခဲ့သော၊ အောင်မြင်စွာ ပြီးမြောက်ခဲ့သည် သို့မဟုတ် မအောင်မြင်ခဲ့သော အလုပ်များကို ဖော်ပြသည်။ ပလေးစာအုပ်ကို ဖွင့်ပြီးသောအခါ ဤပြန်ခေါ်ခြင်းကို ခေါ်သည်။
• ပလေးစာအုပ်ကို ဖွင့်နေစဉ် အချက်အလက်များ လက်ခံရရှိရန် HTTP ဖုန်းခေါ်ဆိုမှု။ Ansible လုပ်ငန်းဆောင်တာတွင် ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏လျှောက်လွှာအတွက် POST/GET တောင်းဆိုချက်ကို လုပ်ဆောင်ပါသည်။

Playbook ၏လုပ်ဆောင်မှုအတွင်းသတ်မှတ်ထားသော HTTP callback(များ) မှတဆင့်ပြောင်းလဲနိုင်သည်နှင့်ကျွန်ုပ်တို့သည်နောက်ဆက်တွဲလုပ်ဆောင်မှုများတွင်သိမ်းဆည်းပြီးအသုံးပြုလိုသောပြောင်းလဲမှုများကိုဖြတ်သန်းကြသည်။ ဒီဒေတာကို sqlite နဲ့ရေးပါတယ်။

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

HTTP ပြန်ခေါ်ခြင်း။

# Make callback to Diskobot App
# Variables:
#    callback_post_body: # A dict with follow keys. All keys are optional
#       msg: If exist it would be posted to Jira as comment
#       data: If exist it would be saved in Incident.variables
#       desire_state: Set desire_state for incident
#       status: If exist Proceed issue to that status

  - name: Callback to Diskobot app (jira comment/status)
    uri:
      url: "{{ callback_url }}/{{ devname }}"
      user: "{{ diskobot_user }}"
      password: "{{ diskobot_pass }}"
      force_basic_auth: True
      method: POST
      body: "{{ callback_post_body | to_json }}"
      body_format: json
    delegate_to: 127.0.0.1

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

ဤသည်မှာ ကျွန်ုပ်တို့သည် MD စက်တစ်ခုမှ disk တစ်ခုကို ထုတ်လွှတ်သည့် playbook မှ ဥပမာတစ်ခုဖြစ်သည်။

  # Save mdadm configuration
  - include: common/callback.yml
    vars:
      callback_post_body:
        status: 'Ready to change'
        msg: "Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}"
        data:
          mdadm_data: "{{ mdadm_remove_disk.removed }}"
          parted_info: "{{ parted_info | default() }}"
    when:
      - mdadm_remove_disk | changed
      - mdadm_remove_disk.removed

ဤလုပ်ဆောင်စရာသည် Jira လက်မှတ်ကို "ပြောင်းလဲရန် အသင့်ဖြစ်နေပြီ" အခြေအနေသို့ လွှဲပြောင်းပြီး မှတ်ချက်တစ်ခု ထည့်ပေးသည်။ ထို့အပြင်၊ mdam_data variable သည် disk ကိုဖယ်ရှားလိုက်သော md စက်ပစ္စည်းများစာရင်းကို သိမ်းဆည်းထားပြီး parted_info သည် partition dump ကိုခွဲပြီးမှခွဲထားခြင်းဖြစ်သည်။

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

စစ်ဆေးနိုင်သော မုဒ်

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

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

ပထမဦးစွာ၊ ၎င်းသည် bot နှင့် playbooks များ၏အလုပ်လုပ်ပုံကိုအတည်ပြုနိုင်စေခဲ့သည်။ ဒုတိယအနေဖြင့်၊ ၎င်းသည် bot ကိုစီမံခန့်ခွဲသူများ၏ယုံကြည်မှုကိုတိုးပွားစေသည်။

ကျွန်ုပ်တို့သည် တရားဝင်မှုကို ကျော်ဖြတ်ပြီး Ansible ကို အခြောက်အပြေးမုဒ်တွင်သာမက သင်သုံးနိုင်သည်ကို သိရှိလာသောအခါတွင်၊ တူညီသော host တစ်ခုတည်းတွင် တူညီသော variable များဖြင့် တူညီသော playbook ကိုဖွင့်ရန် Jira ရှိ Run Diskobot ခလုတ်ကို ပြုလုပ်ခဲ့သည်။

ထို့အပြင်၊ ပျက်စီးသွားပါက playbook ကိုပြန်လည်စတင်ရန်ခလုတ်ကိုအသုံးပြုသည်။

ပလေးစာအုပ်များဖွဲ့စည်းပုံ

Jira လက်မှတ်၏ အခြေအနေပေါ်မူတည်၍ bot သည် မတူညီသော playbooks များကို ထုတ်လွှတ်ကြောင်း ကျွန်ုပ်ပြောခဲ့ပြီးဖြစ်သည်။

ပထမဦးစွာ၊ ဝင်ပေါက်ကိုစီစဉ်ရန်ပိုမိုလွယ်ကူသည်။
ဒုတိယအချက်မှာ၊ အချို့ကိစ္စများတွင်၎င်းသည်ရိုးရှင်းစွာလိုအပ်သည်။

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

ကျွန်ုပ်တို့သည် ဆာဗာအုပ်စုတစ်ခုစီအတွက် Ansible အခန်းကဏ္ဍများကို အသုံးပြုပါသည်။ ဤနေရာတွင် ကစားစာအုပ်(များ)ကို ၎င်းတို့ထဲမှ တစ်ခုတွင် မည်သို့ဖွဲ့စည်းထားသည်ကို ဤနေရာတွင် ကြည့်ရှုနိုင်ပါသည်။

မည်သည့်အလုပ်များ တည်ရှိသည်ကို ချက်ချင်းရှင်းရှင်းလင်းလင်း သိနိုင်သောကြောင့် ၎င်းသည် အဆင်ပြေပါသည်။ Ansible အခန်းကဏ္ဍအတွက် ထည့်သွင်းမှုဖြစ်သည့် main.yml တွင်၊ ကျွန်ုပ်တို့သည် လူတိုင်းအတွက် လိုအပ်သော လက်မှတ်အခြေအနေ သို့မဟုတ် ယေဘူယျအလုပ်များအားဖြင့် ဥပမာအားဖြင့်၊ မှတ်ပုံတင်ခြင်းကို ဖြတ်ကျော်ခြင်း သို့မဟုတ် တိုကင်လက်ခံခြင်းတို့ကို ကျွန်ုပ်တို့ ရိုးရိုးရှင်းရှင်းထည့်သွင်းနိုင်သည်။

စုံစမ်းစစ်ဆေးမှု.yml

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

၎င်းကိုရယူရန် Zabbix အစပျိုးမှ နောက်ဆုံးတန်ဖိုး Jira အနှစ်ချုပ်ကို ပိုင်းခြားစိတ်ဖြာပါသည်။ ၎င်းတွင် ဘလောက်ကိရိယာ၏အမည်ပါရှိသည် - ကံကောင်းပါသည်။ သို့မဟုတ် ၎င်းတွင် mount point တစ်ခုပါ၀င်သည်၊ ထို့နောက် ဆာဗာသို့သွား၍ ခွဲခြမ်းစိပ်ဖြာပြီး လိုအပ်သော disk ကို တွက်ချက်ရန် လိုအပ်သည်။ အစပျိုးသည် scsi လိပ်စာ သို့မဟုတ် အခြားအချက်အလက်အချို့ကိုလည်း ပေးပို့နိုင်သည်။ ဒါပေမယ့်လည်း သဲလွန်စတွေ မရှိဘူး၊ ခွဲခြမ်းစိတ်ဖြာဖို့ လိုပါတယ်။

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

ပြင်ဆင်2change.yml

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

အရိုးရှင်းဆုံးအခြေအနေတွင်၊ ကျွန်ုပ်တို့သည် HW/MD RAID တစ်ခုမှ disk တစ်ခုကိုဖယ်ရှားခြင်းအကြောင်းပြောနေသည်။

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

ယခု ကျွန်ုပ်တို့သည် အစုလိုက်အပြုံလိုက် ပြောင်းရွှေ့နေပါသည်။ မိုဃ်းတိမ်ကိုအကယ်၍ ဆာဗာသည် cloud-based ဖြစ်ပါက Diskobot သည် cloud API ကိုခေါ်ဆိုပြီး၊ ၎င်းသည် ဤ minion နှင့်အလုပ်လုပ်မည့်ဆာဗာ-ကွန်တိန်နာများလည်ပတ်နေသည့်- "ဤ minion မှကွန်တိန်နာအားလုံးကိုရွှေ့ပြောင်းပါ" ဟုမေးသည်။ တစ်ချိန်တည်းမှာပင်၊ အင်ဂျင်နီယာသည် မည်သည့်အရာကို ဆွဲထုတ်ရမည်ကို ချက်ချင်းသိနိုင်စေရန် ဒစ်၏နောက်ခံအလင်းကို ဖွင့်ပေးသည်။

ပြောင်းလဲခဲ့သည်။yml

ဒစ်တစ်ခုကို အစားထိုးပြီးနောက်၊ ကျွန်ုပ်တို့သည် ၎င်း၏ရရှိနိုင်မှုကို ဦးစွာစစ်ဆေးပါ။

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

ကျွန်ုပ်တို့သည် အဘယ်ဂုဏ်ရည်များကို ကြည့်ရှုနေသနည်း။နေရာချထားသောကဏ္ဍများ အရေအတွက် (၅) < 5
လက်ရှိ Pending Sector Count (107) == 0

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

ready.yml

အရိုးရှင်းဆုံး ကိစ္စ- HW/SW စီးနင်းမှု ထပ်တူပြုခြင်းအား စစ်ဆေးခြင်း သို့မဟုတ် အက်ပ်အတွင်း ဒေတာ ထပ်တူပြုခြင်းကို အပြီးသတ်ခြင်း။

လျှောက်လွှာ API

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

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

Ansible မှ သင်ခန်းစာများ

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

Ansible - modularity ၏အားသာချက်ကိုအသုံးပြု၍ အရာအားလုံးကိုတတ်နိုင်သမျှရိုးရှင်းအောင်ပြုလုပ်ရန်ဆုံးဖြတ်ခဲ့သည်။ အမြင့်ဆုံးအဆင့်တွင် Playbook များရှိသည်; ၎င်းတို့ကို Ansible အနည်းငယ်သိသော မည်သည့်အက်ဒမင်၊ ပြင်ပဆော့ဖ်ဝဲရေးသားသူမှ ရေးသားနိုင်သည်။

- name: Blink disk
  become: True
  register: locate_action
  disk_locate:
      locate: '{{ locate }}'
      devname: '{{ devname }}'
      ids: '{{ locate_ids | default(pd_id) | default(omit) }}'

အချို့သော ယုတ္တိဗေဒသည် ပလေးစာအုပ်များတွင် အကောင်အထည်ဖော်ရန် ခက်ခဲပါက၊ ၎င်းကို Ansible module သို့မဟုတ် filter တစ်ခုအဖြစ် ရွှေ့ထားပါသည်။ Script များကို Python သို့မဟုတ် အခြားဘာသာစကားဖြင့် ရေးသားနိုင်သည်။

ရေးရတာ လွယ်ပြီး မြန်တယ်။ ဥပမာ၊ အထက်တွင်ပြသထားသည့် ဥပမာတစ်ခုဖြစ်သော disk backlight module တွင် လိုင်း 265 ကြောင်းပါဝင်သည်။

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

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

Ansible API ဖြင့် ကျွန်ုပ်တို့၏အတွေ့အကြုံကို ထပ်ခါထပ်ခါပြုလုပ်လိုပါက၊ အချက်နှစ်ချက်ကို မှတ်သားထားပါ-

• ယေဘူယျအားဖြင့် Playbook_executor နှင့် playbooks များကို အချိန်ကုန်စေ၍မရပါ။ ssh စက်ရှင်တွင် အချိန်ကုန်သွားသော်လည်း playbook တွင် အချိန်ကုန်သွားခြင်း မရှိပါ။ ကျွန်ုပ်တို့သည် စနစ်တွင်မရှိတော့သောဒစ်ကို ဖြုတ်ချရန်ကြိုးစားပါက၊ ပလေးစာအုပ်သည် အဆုံးမရှိလည်ပတ်နေမည်ဖြစ်ပြီး၊ ထို့ကြောင့် ကျွန်ုပ်တို့သည် ၎င်း၏လွှင့်တင်ခြင်းကို သီးခြားထုပ်ပိုးမှုတစ်ခုဖြင့် ထုပ်ပိုးပြီး အချိန်ကုန်သွားပါသည်။
• Ansible သည် forked လုပ်ငန်းစဉ်များပေါ်တွင်အလုပ်လုပ်သည်၊ ထို့ကြောင့် ၎င်း၏ API သည် thread နှင့်မကင်းပါ။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ playbook အားလုံးကို ကြိုးတစ်ခုတည်းဖြင့် လုပ်ဆောင်ပါသည်။

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

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

source: www.habr.com