ကြုံတွေ့ရသမျှ Network Automation အနုပညာ အပိုင်း(၁)

Automation နဲ့ Orchestration ဆိုတဲ့ အသုံးအနှုံးက အခုနောက်ပိုင်းရှောင်လို့ မရအောင် နေရာတိုင်းမှာတွေ့ရလို့ ဒီတစ်နှစ် နှစ်နှစ်လောက်မှာ စာရေးသူလိုက်ပြီးတော့ လေ့လာကြည့်ပါတယ်။ တော်ရုံဟို script ဒီ script လောက်လိုက်ရေးရာကနေပြီးတော့ ပိုပြီးတော့သိချင်လို့ လေ့လာရင်း လေ့လာရင်းကနေပြီးတော့ automation နဲ့ orchestration ရဲ့ rabbit-hole အတိုင်းဟိုရောက်လိုက် ဒီရောက်လိုက်နဲ့ တစ်နေ့တစ်နေ့ကို ဖြတ်သန်းရပါတယ်။ စာရေးသူဟာ အလုပ်အကိုင်အားဖြင့်တော့ IT Support ယောင်ယောင်၊ Sysadmin ယောင်ယောင်၊ Systems Engineer ယောင်ယောင်၊ Network Engineer ယောင်ယောင် ဟိုယောင်ယောင် ဒီယောင်ယောင်နဲ့ နေရာမျိုးစုံမှာ ကြုံသလို ဝင်ရောက် လုပ်ကိုင်စားသောက်ပြီးတော့ အသက်မွေးဝမ်းကျောင်းပြုရပါတယ်။ အချိန်ရရင်ရသလောက်လည်း ကိုယ်လေ့လာချင်တာတွေကို ရှာကြံပြီး လိုက်လံဖတ်ရှုခြင်းနဲ့ နည်းပညာဆိုင်ရာ လက်တွေ့စမ်းသပ်မှုမျိုးတွေနဲ့ အချိန်အတော်များများကို ကုန်ဆုံးစေတတ်ပါတယ်။ ဒါကြောင့်လည်း ကိုယ်အိပ်တဲ့ နေရာဘေးမှာ ကွန်ပြုတာအစုတ်အဟောင်းလေးတွေ အချို့နဲ့ စမ်းလို့မပြီးသေးတဲ့ project တဝက်တပျက် များဝန်းရံပြီးတော့ ညအတော်များများကို ဖြတ်သန်းလေ့ရှိပါတယ်။ အဲ့ဒါမှ အချိန်ထပ်ပြီးတော့ ပိုနေသေးရင်ဖြင့် စာရေးရတာကိုလည်း ကြိုက်ပါတယ်။ မြန်မာစာရေးခြင်းကို ကြိုက်နှစ်သက်တာကတော့ စာရေးသူ သတိထားမိသလောက် ၁၀တန်းလောက်ကတည်း ဖြစ်မယ်ထင်ပါတယ်။ စာရေးခြင်းကို ကြိုက်သော်လည်း ဘာခေါင်းစဥ်နဲ့ ဘာစာရေးစရမလဲဆိုတာကိုတော့ အချိန်အများကြီးယူပြီးတော့ တော်တော်လေးရှာဖွေလိုက်ရပါတယ်။ အသက်တွေအရမ်းကြီးသွားတဲ့အချိန် လောကကြီးကို ငြီးငွေ့လာရင် စာရေးခြင်းဖြင့် အပျင်းဖြေမယ်လို့လည်း စိတ်ကူးကြည့်မိပါတယ်။ ကိုယ့်အရှေ့မှာလူကြီးတွေ အသက်ကြီးလာရင် ပျင်းပြီး ဘာသာရေးကြီးပဲလိမ့်လုပ်တာတွေကို တွေ့တိုင်း ငါတော့ဖြင့် သူတို့လို မပျင်းရလေအောင် အသက်ကြီးလာတဲ့ အထိလုပ်လို့ရတဲ့ ဝါသနာလေးတစ်ခုနှစ်ခုလောက်တော့ ရအောင်လုပ်ထားမယ်လို့ အတွေးရှိမိပါတယ်။ စာရေးသူအထင်ကတော့ ဘဝမှာကိုယ်ဘာလုပ်ချင်သလဲဆိုတာကို ရှာဖွေနေရတာကိုက ကိုယ့်အသက်ရဲ့ ၈၀ရာခိုင်နှုန်းကနေ ၉၀ ရာခိုင်နှုန်းလောက်ကုန်ဆုံး သွားလေသတည်းလို့ ကောက်ချက်ချမိပါတယ်။ အချို့လည်း ကိုယ့်ဘဝမှာ ကိုယ်ဘာလုပ်ချင်သလဲဆိုတာကို စောစောစီးစီးသိပြီးတော့ အဲ့ဒီတစ်ခုကိုပဲလုပ်ရင်းကိုင်ရင်းနဲ့ တသက်တာဖြတ်သန်းမှုတွေ မြင်တိုင်းတွေ့တိုင်းတော့ အားကျမိပါတယ်။ ကိုယ်ကမှ သူတို့လောက်မစွမ်းပဲလေ၊ နှိုင်းမကောင်းပါဘူးလို့ ကိုယ်ဟာကို ဖြေသိမ့်ရပါတယ်။ မည်သို့ပင်ဖြစ်စေ စာရေးသူ အနေနဲ့ ကိုယ်လေ့လာချင်တာကို အချိန်ပေးပြီးတော့ လေ့လာတယ်၊ သိသလောက်လေးနည်းနည်း မျှဝေနိုင်သလောက် ပြန်လည်မျှဝေရတာနဲ့ပဲ ကိုယ်တိုင်စိတ်ကျေနပ်မှုရလို့ နေပျော်ပါတယ်။ post ရဲ့ ခေါင်းစဉ်နဲ့ ဆက်နွယ်မှု မရှိသော်လည်း အခုလို စိတ်ရှုပ်ရတဲ့ COVID-19 ရာသီမှာ စာရေးသူ လက်ရှိသုံးသပ်ကြည့်မိတဲ့ ကိုယ့်ရဲ့ ဘဝပေးအခြေအနေတရပ်ပဲဖြစ်ပါတယ်။

လုပ်ငန်းခွင်ဆိုင်ရာ လုပ်ငန်းစဉ်အကြောင်း တစေ့တစောင်း

ကဲ… အစပိုင်းမှာ ပျိုးထားတဲ့ Automation နဲ့ Orchestration အကြောင်းဆက်လိုက်ရအောင်။ အထက်မှာပြောသလိုပဲ စာရေးသူဟာ လက်ရှိမှာတော့ ဖားတပိုင်း ငါးတပိုင်း Systems တဝက်၊ Network တဝက်ကို ထိန်းသိမ်းရတဲ့ Network Systems Engineer တစ်ယောက်လို့တော့ ခေါင်းစဉ်တက်လို့ရမယ်ထင်ပါတယ်။ Systems နဲ့ ပတ်သတ်ရင်တော့ Windows ကစ Linux အဆုံး manage လုပ်ရပါတယ်။ Virtualisation မှာလည်း VMware product တွေနဲ့ အများကြီးလုပ်ငန်းခွင်မှာ ထိတွေ့ရပါတယ်။ ဒါ့အပြင် VMware product နဲ့ တွဲပြီးတော့ Veeam Backup product တွေနဲ့လည်း ဟိုစပ်စပ် ဒီစပ်စပ်လုပ်ရပါတယ်။ Storage နဲ့ Infrastructure hardware တွေပိုင်းမှာတော့ အထိအတွေ့နည်းတယ်လို့ ထင်သလောက် ခရီးမပေါက်ပါဘူး။ အထူးသဖြင့် Storage infrastructure ပိုင်းမှာ တော်တော်လေးအားနည်း တာကို သတိထားမိပါတယ်။ Network ပိုင်းမှာဆိုရင်တော့ routing / switching ကစ network security အဆုံးအကုန်လုပ်ရပါတယ်။ Vendor တွေဆိုရင်လည်း Cisco ရဲ့ routing / switching နဲ့ Security ပိုင်းမှာ FortiGate နဲ့ Cisco ASA တွေနဲ့ ထိတွေ့ခွင့်ရပါတယ်။ ဒါ့အပြင် HPE ရဲ့ Procurve နဲ့ Huawei ရဲ့ routing / switching platform တွေကိုလည်း လုပ်ငန်းခွင်မှာ တွင်တွင်ကျယ်ကျယ် နေ့စဉ် ထိတွေ့ရပါတယ်။ Customer တွေအတွက် edge device မှာ စျေးနည်းနည်း ပေါတဲ့ MikroTik ရဲ့ routing ဖြစ်တဲ့ RouterOS platform ကို သုံးပြန်ပါတယ်။ စာရေးသူအတွက်တော့ နေ့စဉ်လေ့လာ လို့မကုန်နိုင်လောက်အောင် platform မျိုးစုံနဲ့ နပမ်းလုံးရပါတယ်။

စာရေးသူရဲ့ team ကတော့ MPLS network နဲ့ Segment Routing ကို customer တွေအတွက် manage လုပ်ရပါတယ်။ ISP တစ်ခုလည်းဖြစ်လို့ provisioning ပိုင်းမှာ အိမ်သုံး Internet connection ကစလို့ Enterprise IP Transit သို့မဟုတ် Direct Internet Access (DIA) တွေအထိ ရှိပါတယ်။ Enterprise နည်းပညာပိုင်းမှာ အစုံမြင်ရပြီးတော့ တော်တော်လေးလည်း လေ့လာရတာတော့ နေ့စဉ်လိုပါ။ Upstream / downstream မှာလည်း vendor ပေါင်းစုံနဲ့ SLA / uptime / downtime ကိစ္စမှာ နှစ်ပါးသွားရပါတယ်။ ဒီကြားထဲမှာ documentation တွေကို ကိုယ်သိသလောက်ပြန်ရေးပြီးတော့ ကိုယ့်ရဲ့ junior engineerတွေ နဲ့ အခြားသော engineer တွေသိအောင် လေ့လာနိုင်အောင် publish လုပ်ရပါတယ်။ အချိန်တန်လို့ architectural network design ပြောင်းရင် ပြောင်းသလို လိုက်ပြီးတော့ ကိုယ့် documentation တွေကို maintain လုပ်ရပါတယ်။ အချို့နေ့တွေဆိုရင် documentation တစ်ခုတည်းနဲ့ပဲ တနေကုန်သွားတာမျိုးလည်း ရှိပါတယ်။ Documentation တွေလုပ်တာများတဲ့အတွက် ကိုယ့်မှာလည်း လုပ်ငန်းခွင်ဆိုင်ရာမှာ အများကြီး သိခွင့်လေ့လာခွင့်ရခဲ့ပါတယ်။ စာရေးသူအတွက်တော့ အခြားသူတွေကို ကူညီရင်းနဲ့ ကိုယ်အမြတ်ထွက်ရတဲ့ ကိန်းပါ။ Documentation လို့ဆိုရာမှာလည်း network diagram တွေနဲ့ အခြားသော technical documentation ကိုရေးပြီးတော့ maintain လုပ်ရပါတယ်။ အပြောလွယ်သလောက် အလုပ်တော့နည်းနည်းခက်ပါတယ်။

ဒါတွေအပြင် network monitoring system တွေဖြစ်တဲ့ PRTG နဲ့ SolarWinds ကိုလည်း လက်ရှိ MPLS network နဲ့ integrate လုပ်ရပါတယ်။ လိုအပ်ရင် လိုအပ်သလို RADIUS တို့ TACACS+ တို့လိုမျိုး service တွေကိုလည်း စလယ်ဆုံး ကိုယ်တိုင် setup လုပ်ပြီးတော့ network မှာ integrate လုပ်ရတာမျိုးလည်းရပါတယ်။ အကုန်လုံးကို ခြုံငုံပြီးတော့ ကြည့်လိုက်ရင်တော့ လုပ်ငန်းခွင်မှာလုပ်ရတဲ့ လုပ်ငန်းစဉ်နဲ့ vendor တွေတော့တော်တော်လေးစုံပါတယ်။ နေ့စဉ်လုပ်ရတဲ့ အချို့အလုပ်လေးတွေတော့ ပျင်းသလိုလိုဖြစ်လာပါတယ်။ အသစ်အသစ်တွေ လေ့လာခွင့်ရတိုင်းတော့ လေ့လာတန်သလောက် လေ့လာမိပါတယ်။ ပြီးပြည့်စုံတယ်လို့တော့ မရှိပါဘူး။ ပျင်းသလိုလိုရှိလာတဲ့ အလုပ်လေးတွေကတော့ ဒီတစ်ခုတည်းကိုပဲ ထပ်ကာထပ်ကာ လုပ်ရဖန်များလို့လည်းဖြစ်နိုင်ပါတယ်။ ဒီလိုမျိုးပျင်းသလိုလိုရှိလာရင် စာရေးသူ အဲ့ဒီ workflow ကို ရှောင်လို့ရအောင် ဘယ်လိုမျိုး automate လုပ်ရပါ့မလဲဆိုတာ စပြီးတွေးပါတယ်။ ကိုယ်တိုင်က လူပျင်းမို့ workflow တော်တော်များများကို automate လုပ်လို့ရအောင် အမြဲတမ်းကြိုးစားလေ့ရှိပါတယ်။ Automated workflow တစ်ခုချင်းစီကိုလည်း အားရင်အားသလို လက်ရှိထက်ကောင်းအောင် ပြင်ဆင်ပြီးတော့ စမ်းသပ်လေ့ရှိပါတယ်။ ဒါနဲ့ပဲ တစ်နေ့တာ သံသရာလည်ရပါတော့တယ်။

အစဉ်အလာအရကြည့်မယ်ဆိုရင်တော့ စာရေးသူဟာ Operations လို့ခေါ်တဲ့ Ops ဘက်တော်သားလို့ ကိုယ့်ဟာကိုမြင်မိပါတယ်။ အလုပ်သဘောသဘာဝအရ change ဆိုတဲ့ အပြောင်းအလဲတစ်ခုခုကို လက်ရှိ operate ဖြစ်နေတဲ့ systems ထဲကိုထည့်ဖို့ဆိုတာ မလိုအပ်ရင်မလုပ်လိုပါဘူး။ Uptime ဘယ်လောက်များများရအောင်လုပ်နိုင်မလဲ ဆိုတာကို ဦးစားပေးပြီးတော့ နေ့စဉ် network နဲ့ systems တွေကို monitor လုပ်ရပါတယ်။ Change တစ်ခုအတွက် ပြင်ဆင်ရတဲ့အပိုင်းမှာ အချိန်အများကြီးပေးရလို့ အစကတည်းက သိပ်သဘောမတွေ့ပါဘူး။ သို့သော်လည်း change တစ်ခုအတွင်းမှာ တစ်ခုမှားသွားလို့ လွှဲသွားလို့ ချော်သွားလို့ကတော့ ကိုယ့်အထက်က အတွင်းပုတ်တဲ့ senior engineer အချို့နဲ့ ဘုမသိဘမသိ management က ခဏခဏ ကိုယ်ဆီပဲရောက်လာပြီးတော့ finger pointing လုပ်လိုက် blame game ဆော့လိုက်နဲ့ ဝိုင်းဝိုင်းသမကြသဖြင့်၊ အကြိမ်များလာလို့ သတိကပ်ပြီး ဘယ်သူကိုယ်မှ အယုံအကြည်မရှိနိုင်တာ second nature လိုဖြစ်လာပါတယ်။ Work culture ဟာ ကိုယ့်ရဲ့ workflow ကိုထိခိုက်လာတော့ senior ကောင်းတဲ့ team ကိုရောက်အောင် ကြိုးစားရပါတော့တယ်။ လက်ရှိ team မှာတော့ senior engineer တွေရဲ့ အထောက်အပံ့ကြောင့် ကိုယ့်အတွက် လမ်းအများကြီးပွင့်လာပါတယ်။ ကိုယ်နဲ့ အလုပ်လုပ်ရတဲ့ team မှာလည်း ဘိုးတူဘောင်ဘက် ဝိုင်းဝံ့လုပ်ကိုင်ကြလို့ ကိုယ့်အတွက်လည်း အလုပ်ပိုဖြစ်ပါတယ်။ သို့သော် management အပိုင်းမှာတော့ micro-manage လုပ်တဲ့ culture လေးတွေရှိနေသေးလို့ အနည်းငယ်တော့ စိတ်ရှုပ်ရတာတော့ အမှန်ပါ။ အခုနောက်ပိုင်း Dev culture နဲ့ DevOps evolution အကြောင်းလေးတွေ လိုက်လေ့လာဖြစ်တော့ ကိုယ်စိတ်ကူးထားတဲ့ ရွှေပြည်တော်လို့တောင် ထင်ရပါတယ်။ Agile methodology ကိုထဲထဲဝင်ဝင် လေ့လာလိုက်တော့မှ ဟာ… ဒါတော့ဖြင့်ငါနဲ့ တော်တော်လေးအဆင်ပြေလောက်တယ်ဆိုပြီးတော့ အားကျမိပါတယ်။ ဒါ့ကြောင့်လည်း အခုလောလောဆယ်မှာ DevOps နဲ့ပတ်သတ်တဲ့ tool set / too chain တွေအကြောင်း၊ DevNet ရဲ့ data modelling အကြောင်းတွေကို သဲကြီးမဲကြီးနဲ့ စမ်းတဝါးဝါးလိုက်ဖတ် လိုက်လေ့လာဖြစ်နေပါတယ်။ လက်ရှိ Ops ခြံထဲကနေပြီးတော့ Dev ခြံဘက်အခြမ်းကို ကူးလာခုန်သွားချင်နေတာကတော့ လက်ရှိမှာဖြစ်နေတဲ့ စာရေးသူရဲ့ ဆာလောင်မှုတစ်ခုပါ။

အသုံးတည့်တဲ့ Network Automation နဲ့ Orchestration tool set

Network automation နဲ့ orchestration အတွက် စာရေးသူကိုယ်တိုင် ကြုံတွေ့ ရတဲ့ ဖြစ်စဉ်တစ်ခုကို ပြန်လည်မျှဝေလိုပါတယ်။ အထက်မှာပြောခဲ့ပြီးသလိုပဲ… ထပ်ကာထပ်ကာလုပ်ရတဲ့ repetitive tasks တွေကို နေ့စဉ် workflow အနေနဲ့ လုပ်ရတာ စာရေးသူ မကြိုက်ပါဘူး။ အစပိုင်း process ကိုနားလည်အောင် လေ့လာတဲ့ အချိန်မှာပဲ လက်ကြောတင်းအောင်လုပ်ပြီးတော့ နည်းနည်းကြာလာလို့ရှိရင် ပျင်းလာတက်ပါတယ်။ ဘာမဆို ငြီးငွေ့လွယ်လွန်းတာတော့ စာရေးသူနဲ့ ဒိုးလုံးတော်တော်တူပါတယ်။ အဲ့ဒီအတွက် ပျင်းလာတဲ့ workflow အချို့ကို bash script လေးတွေရေးဖြစ်ပါတယ်။ bash ဟာ Unix-like platform ပေါ်ကနေမထွက်မချင်းတော့ ဒီကဟာ ဟိုဘက်မှာဆွဲသုံးလိုက် ဟိုကဟာ ဒီမှာထည့်သုံးလိုက်နဲ့ အစပိုင်းမှာ အဆင်ပြေသယောင်ယောင်ပါ။ ကိုယ်လုပ်ချင်တဲ့ဟာသိတောင်မှ ဘယ်ကနေဘယ်လိုစလုပ်လိုက်ရသလဲဆိုတာ မသိတဲ့အချိန်တွေ့လည်းရှိပါတယ်။ များသောအားဖြင့် အစကနေပြီး အဆုံတိုင်အောင် တစ်ခုချင်းစီတည်ဆောက်ယူရပါတယ်။ အဲ့ဒီကနေမှ ကိုယ်က အခြားသော network platform တွေနဲ့ တွဲသုံးဖို့ရာ bash တစ်ခုတည်းနဲ့ကတော့ တော်တော်လေးကို မလွယ်တဲ့ကိစ္စပါ။ ဒါ့ကြောင့် ရှာရင်းဖွေရင်းနဲ့ စာရေးသူ Ansible လိုမျိုး orchestration tool တစ်ခုကိုစတင်တွေ့ရှိခဲ့ပါတယ်။ တပြိုင်နက်တည်းမှာပဲ YAML ဆိုတဲ့ data format parsing နဲ့ Ansible playbook တွေအကြောင်း ထပ်ပြီးတော့ လေ့လာဖြစ်ပြန်ပါတယ်။ အနည်းဆုံးတော့ Ansible playbook နဲ့ inventory က device တွေကို စာရေးသူ စပြီးတော့ orchestrate လုပ်လို့ရလာပါတယ်။ ဥပမာ အရင်က network device တစ်ခုချင်းစီကို ssh နဲ့ လိုက်ဝင်ရပြီးတော့ configuration ကို တစ်ခုပြီးတစ်ခုလိုက်စစ်ရပါတယ်။ လိုအပ်ပါက configuration လေးနှစ်ကြောင်းသုံးကြောင်းကို တစ်ခုချင်းစီဝင်လိုက်ပြင်လိုက်နဲ့ တော်တော်လေးကို ပျင်းဖို့ကောင်းတဲ့ အလုပ်ပါ။ ဥပမာ ACL entry တွေကို ပြင်ဆင်တဲ့အချိန်မျိုးမှာကြုံရတတ်ပါတယ်။ Ansible playbook နဲ့ပြင်ဆင်စရာရှိတာ ပြင်ဆင်ပြီးတော့ command လေးတစ်ကြောင်း ရိုက်ထည့်ပြီးတော့ run လိုက်နိုင်တာ စိတ်ကျေနပ်စရာတစ်ခုပါ။ Ansible က agent-less ဖြစ်တဲ့အတွက် platform တော်တော်များများမှာ well-maintained လုပ်ထားတဲ့ Ansible module လေးတစ်ခုရှိရုံနဲ့ ကောက်ပြီး လိုအပ်တဲ့ဟာကို orchestrate လုပ်လို့ရပါတယ်။ အဲ့ဒီတော့ စာရေးသူ Ansible Adhoc command လေးတွေကို လိုအပ်သလို သုံးလို့ ရနိုင်သလို၊ သူ့ရဲ့ playbook နဲ့ bash shell script တွေကို ပေါင်းပြီးတော့ automate လုပ်ကြည့်၊ orchestrate လုပ်ကြည့်ပါတော့တယ်။ သင့်သင့်သလောက်တော့ ခရီးပေါက်ခဲ့ပါတယ်။

Ansible ဟာ Red Hat ရဲ့ project တစ်ခုဖြစ်ပါတယ်။ အခုနောက်ပိုင်းမှာ DevOps သမားတွေအကြိုက်တွေ့တဲ့ orchestration tool ပါ။ အခြားသော Puppet၊ Chef နဲ့ Salt တို့လိုပဲ ကိုယ့်ရဲ့ environment နဲ့ setup ပေါ်မှာမူတည်ပြီးတော့ Ansible ကိုအသုံးပြုကြပါတယ်။ ပြဿနာက Ansible module တိုင်းဟာ ကိုယ်သုံးတဲ့ platform အတွက်အလုံးစုံ ပြည့်စုံဖို့တော့ မလွယ်ပါဘူး။ ဆိုကြပါတော့… စာရေးသူ အလုပ်မှာ အသုံးပြုတဲ့ အခြားသော networking platform တွေဖြစ်တဲ့ Huawei နဲ့ MikroTik တို့အတွက်တော့ ကိုယ်တိုင်စမ်းပြီးတော့ သုံးကြည့်သလောက်တော့ သိပ်အဆင်မပြေပါ။ Core network မှာသုံးတဲ့ Cisco networking platform အတွက်တော့ Ansible ဟာ စာရေးသူ အတွက် အားလုံးနီးပါး အဆင်ပြေပါတယ်။ Ansible module တွေကို ဟိုရှာဒီရှာနဲ့ Ansible ရဲ့ backend မှာ python code တွေကိုတွေ့ရပြန်ပါတယ်။ ဒါနဲ့ပဲ python ကို network automation မှာ တွဲပြီးတော့ သုံးဖို့အတွက် ထပ်တခါလေ့လာဖြစ်ပြန်ပါတယ်။ Python ဘက်အခြမ်းကိုရောက်လာတော့ သူ့မှာယူသုံးလို့ရတဲ့ library တွေအများကြီးရှိလို့ တော်တော်လေးကို အဆင်ပြေနေပါတယ်။ Network automation အတွက် python မှာ paramiko နဲ့ netmiko လို module တွေရှိရုံနဲ့ ကိုယ်ကြိုက်တဲ့ ဘယ် device ကိုမဆို ssh ဝင်လို့ရနိုင်ပါတယ်။ Python မှာ အဓိကအားသာချက်က သူ့ရဲ့ python community နဲ့ ပြီးပြည့်စုံလှတဲ့ python အတွက် documentation တွေပဲဖြစ်ပါတယ်။ မသိရင် ကိုယ်တိုင် ရှာဖတ် ရှာလေ့လာလို့ ရတဲ့အတွက် အဆင်ပြေပါတယ်။ Syntax ပိုင်းမှာလည်း အခြားသော high-level programming language တွေလောက် မရှုပ်ထွေးလှပါဘူး။ Python ရဲ့ ကိုယ်ပိုင်ဟန် ကိုယ်ပိုင်စည်းကမ်းလေးတွေကို သေချာလိုက်နာရုံနဲ့ ခရီးတော်တော်ရောက်နိုင်ပါတယ်။

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