Top-Down Or Bottom-Up

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

တစ်ယောက်က လင့်အတွက် အရန်လင့်(Backup) တစ်ခုလိုအပ်မယ်ထင်တယ်ဆိုပြီး အကြံပြုတယ်။ ဒီတော့ ရုံးချုပ်နဲ့ ရုံးခွဲကြားမှာ လင့်၂လင့်ထားမယ်။ ဒါဆို လင့်နဲ့ပတ်သက်ပြီး ပူစရာ မလိုတော့ဘူး။ Link redundancy ရသွားပြီ။ ဒါပေမဲ့ ရုံးခွဲမှာ Router ကတစ်လုံးပဲဆိုတော့ အဲဒီ Router ပျက်သွား ရင် လင့် ၂ လင့်ရှိလဲ အလကားပဲ ဆိုတော့ Router နောက်တလုံးထပ်ထည့်ဖို့ လုပ်ကြတယ်။ ဒါဆို Hardware redundancy ပါရသွား ပြီ။ နောက်ဆက်တွဲ ထပ်ပေါ်လာတာက Router ၂ လုံးနဲ့ အတွင်းက LAN ကိုဘယ်လိုပြန်ပေးကြမလဲ။ ၁ လုံး ပဲဆိုရင် LAN interface ကို Default gateway အနေနဲ့ ထောက်လိုက်ရုံပဲ၊ အဆင်ပြေတယ်။ ၂ လုံးဆိုတော့ ဒီအတိုင်းမရတော့ဘူး။ HSRP ဖြစ်ဖြစ်၊ GLBP ဖြစ်သုံးပြီး အတွင်းက Switch ကိုချိတ်ရမယ်။ Switch ၁ လုံး နဲ့ဆိုရင် Redundancy ပျက်သွား နိုင်တဲ့ အတွက် Switch လည်း ၂ လုံးပေါ့။ ဒါဆိုရင်တော့ အတော် ဟုတ်သွားပြီး အားလုံး ၂ခုနဲ့ Full redundancy ရပြီပေါ့။

Network Design ရဲ့ အရေးကြီးတဲ့ အောက်က အချက်သုံးချက်နဲ့ ကိုက်ညီသွားပြီလို့ဆိုလို့ရတယ်။
-    Network must be reliable and resilient
-    Network must be manageable
-    Network must be scalable

ဒါပေမဲ့ အခုလို၂ စုံသုံးလိုက်လို့ အားလုံးအဆင်ပြေသွားပြီလို့တော့ ဆိုလို့မရသေးဘူး။ Single point of failure မရှိတော့ပေမယ့် Point of failure တွေများလာတာကို သတိထားရမယ်။ ပြီးရင် အသုံးပြုထားတဲ့ configuration ကိုသေချာ ကိုင်တွယ်နိုင်တဲ့ နားလည်နိုင်တဲ့ Network Admin တယောက်လိုလာမယ်။ Static route နဲ့ Plug-n-Play မဟုတ်တော့ဘူး။ တနေရာရာ မှာ တခုခုဖြစ် ရင် ကိုယ့် Network အခြေအနေဟာ ဘယ်လိုဖြစ်နိင်တယ် ဆိုတာ ကြိုတင်မြင်ထားရမယ်။ အဲဒါကို Daily operation ကိုင်ရမယ့် အခုနက Network Admin ကသိရမယ်။ (Security နဲ့ network monitoring ကိစ္စထည့်မပြောသေးဘူး။)

ဒါတင်ပဲလားဆိုတော့ မဟုတ်သေးဘူး။ ဝယ်ရမဲ့ ပစ္စည်းအရေအတွက်အတွက် ကုန်ကျစရိတ်က ၂ ဆ မကတက်သွားတယ်။ ပြီးရင် လစဉ်ပေးရမဲ့ ထိန်းသိမ်းခ ဖြစ်တဲ့ Maintenance cost ကလည်း အရမ်း များသွားတယ်။ ဒီတော့ Business requirement အတွက် အဲဒီလောက် သုံးဖို့အတွက် လိုအပ်ရဲ့လားဆိုတာက ပြန်ပြီး စဉ်းစာ စရာဖြစ်လာပြန်တယ်။ Technical ဖက်ကနေ ဘယ်လောက်ပဲ သေချာတဲ့၊ ကောင်းတဲ့ ဒီဇိုင်း လုပ်ခဲ့ပေမယ့် အဲဒီ ဒီဇိုင်း ဟာ Business requirement နဲ့ မကိုက်ညီဘူး၊ မသင့်တော်ဘူးဆိုရင် ဒီ ဒီဇိုင်း ကိုပြီးပြည့်စုံပြီလို့ပြောလို့မရတော့ ဘူး။ ဒီ Network ပြတ်တောက်သွားခဲ့ရင် Business ဖက်က ဘယ်လောက် အထိတောင့်ခံနိုင်မလဲ။ ဘယ်နှစ်နာရီလောက် အထိပြတ်လို့ရသလဲ ဆိုတာတွေကို ချိန်ရတော့မယ်။ ဒါဆိုရင် တချို့နေရာတွေမှာ ကုန်ကျစရိတ်ကို လျော့သင့်တယ်ထင်ရင် လျော့လို့ရတာပေါ့။ ဥပမာ Hardware maintenance ယူတဲ့အခါ 24x7x4 လား x2 လား၊ ဒါမှမဟုတ် 8x5xNBD လား စသဖြင့်လျော့ချလို့ ရပါတယ်။ Hardware ရွေးတဲ့အခါမှာလည်း Backup device ကို ဈေးနိမ့်တာ ရွေးချယ်တာမျိုးပေါ့။

အခု အပေါ်က ဒီဇိုင်နာ တွေစဉ်းစားသွားတဲ့ပုံက Bottom-up approach လို့ဆိုရမှာပါ။ သူတို့ရဲ့ အတွေ့အကြုံရ လိုအပ်မယ်ထင်တာတွေကို Deign guideline အတွင်းကနေ အဆင်ပြေအောင်လုပ် သွားတာ။ Business requirement ကိုသေချာ မလေ့လာသွားဘူး။ ပြန်မမေးဘူး။ မြန်တော့မြန်တယ် ဒါပေမဲ့ Approval board ရောက်တဲ့ အချိန်မှာ Business unit နဲ့ Finance ဖက်က သူတို့လိုအပ်ချက်နဲ့ မကိုက်ရင် ကိုယ့် ဒီဇိုင်း ဟာ ရှေ့ဆက်ဖို့ ခက်သွားပါပြီ။ Technical goals တခုတည်း ပြည့်စုံတာနဲ့မလုံလောက်ပါဘူး။ ပိုသင့်တော်တာက တော့ Top-down approach နဲ့ Business requirement ကို သေချာနားလည်အောင် Big picture ကိုသိအောင် အရင်လုပ်ပြီးမှ ကိုယ့်ရဲ့ Final design နဲ့ BoM ကိုထုတ်ပေးသင့်ပါတယ်။ အချိန်တော့ ပိုကြာရင် ကြာမယ် ဒါပေမဲ့ ကိုယ့်တင်ပေးလိုက်တဲ့ ဒီဇိုင်း ဟာ ပိုပြီး အဆင်ပြေနိုင်ပြီး Business requirement နဲ့ ကိုက်ညီတဲ့ Design တစ်ခုအနေနဲ့ ထွက်ပေါ်လာမှာ ဖြစ်ပါတယ်။ Business unit ဖက်ကလည်း လိုအပ်တဲ့ အချက်အလက်ကို သေချာစုဆောင်ပီး Technical design team ဘက်ကို သူတို့ရဲ့ ရေတို ရေရှည် အစီအစဉ်တွေကို ပြောပြထားရမှာပါ။ အဓိက ဆိုချင်တာကတော့ Technical တစ်ခုတည်းသာမက တခြားကိစ္စတွေပါ ထည့်ပြီး စဉ်းစားသင့်တယ်ဆိုတဲ့ အကြောင်းပါ။ အားလုံးကို ၂စုံသုံးတိုင်း ရပီလို့ တွက်ထားလို့မရပါဘူး။

“Design a network that meet a customer’s business and technical goals.”

ကိုဖြိုး