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

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

လီယွန်သည် ရုရှားဘာသာဖြင့် အရောင်အသွေးစုံလင်စွာပြောတတ်သောကြောင့် သင့်တွင် 35-40 မိနစ်ရှိပါက ဗီဒီယိုကိုကြည့်ရန် အကြံပြုအပ်ပါသည်။ အချိန်ကုန်သက်သာစေရန် စာသားဗားရှင်းကို အောက်တွင်ဖော်ပြထားသည်။

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

တစ်လအလို

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

Teaching Strategies သည် မွေးစမှ သုံးနှစ်အထိ ကလေးများအတွက် သင်ရိုးညွှန်းတမ်းတွင် စျေးကွက်ခေါင်းဆောင်ဖြစ်သည်။ သမားရိုးကျ “စက္ကူ” ကုမ္ပဏီသည် သက်တမ်း 40 ရှိပြီဖြစ်ပြီး ပလပ်ဖောင်း၏ ဒစ်ဂျစ်တယ် SaaS ဗားရှင်းသည် 10 နှစ်ဖြစ်သည်။ မကြာသေးမီက၊ ကုမ္ပဏီစံချိန်စံညွှန်းများနှင့် လိုက်လျောညီထွေဖြစ်အောင် ဒစ်ဂျစ်တယ်နည်းပညာကို ပြောင်းလဲခြင်းလုပ်ငန်းစဉ် စတင်ခဲ့သည်။ "အသစ်" ဗားရှင်းသည် 2017 တွင်ထွက်ရှိခဲ့ပြီး ယခင်ဗားရှင်းကဲ့သို့နီးပါးဖြစ်ခဲ့သော်လည်း ပိုဆိုးသွားခဲ့သည်။

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

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

သက်တမ်း 2 နှစ်သာရှိပုံရသော ပလပ်ဖောင်းတွင် ထူးထူးခြားခြား အစုအပုံပါရှိသည်- ColdFusion & SQL Server 2008။ ColdFusion ၊ သင်မသိပါက၊ သင်မသိနိုင်ချေများသောအားဖြင့်၊ သည် 90s အလယ်ပိုင်းတွင်ထွက်ရှိသောလုပ်ငန်း PHP တစ်ခုဖြစ်ပြီး ထိုအချိန်မှစ၍ ၎င်းကိုကျွန်ုပ်မကြားဖူးပါ။ Ruby၊ MySQL၊ PostgreSQL၊ Java၊ Go၊ Python တို့လည်း ပါ၀င်ပါတယ်။ သို့သော် ပင်မကျောက်တုံးသည် ColdFusion နှင့် SQL Server တွင် လည်ပတ်နေသည်။

ပြဿနာများ

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

အစဉ်အလာအားဖြင့် သူတို့၏နည်းပညာများသည် ထောင့်တွင်ထိုင်ပြီး အလုပ်တစ်မျိုးလုပ်ကြသည်။ သို့သော် ဒစ်ဂျစ်တယ်ဗားရှင်းဖြင့် လုပ်ငန်းပို၍တိုးလာသည်။ ထို့ကြောင့် ကျွန်တော်အလုပ်မစမီ နောက်ဆုံးနှစ်တွင် ဒါရိုက်တာဘုတ်အဖွဲ့၊ CTO၊ CPO နှင့် QA ဒါရိုက်တာအသစ်များ ပေါ်လာခဲ့သည်။ ဆိုလိုသည်မှာ ကုမ္ပဏီသည် နည်းပညာကဏ္ဍတွင် စတင်ရင်းနှီးမြှုပ်နှံခြင်း ဖြစ်သည်။

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

ရှေ့နှစ်ရက်

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

ဂရပ်ဖြင့် အကဲဖြတ်ရာတွင် တစ်စုံတစ်ရာ ပြတ်ပြတ်သားသား ဖြစ်ပျက်ခဲ့ပြီး၊ ၎င်းသည် ဘာလဲ မရှင်းလင်းပါ။ ပြဿနာမှာ ဒေတာစင်တာရှိ ကွန်ရက်အတွင်းကြာချိန်ဖြစ်သည်- ဒေတာစင်တာရှိ 5 ms latency သည် သုံးစွဲသူများအတွက် 2 s ဖြစ်လာသည်။ ဘာ့ကြောင့်ဒီလိုဖြစ်သွားတာလဲ ကျွန်တော်မသိပေမယ့် ဘယ်လိုအခြေအနေမျိုးမှာပဲဖြစ်ဖြစ် ပြဿနာက ဒေတာစင်တာမှာ ရှိနေတယ်ဆိုတာ သိလာရတယ်။

တစ်နေ့တစ်ဦးက

နှစ်ရက်ကြာပြီး အလုပ်စစချင်းမှာ ပြဿနာက မပျောက်သေးတာကို သိလိုက်ရတယ်။

နှစ်ရက်တာအတွင်း သုံးစွဲသူများ၏ စာမျက်နှာများကို ပျမ်းမျှအားဖြင့် 4 စက္ကန့်အတွင်း တင်ပေးသည်။ ဘာပြဿနာရှိလို့လဲလို့ မေးကြည့်တယ်။

- ဟုတ်ကဲ့၊ ကျွန်တော်တို့ လက်မှတ်ဖွင့်ထားပါတယ်။
- AND?
- အင်း၊ သူတို့က ငါတို့ကို မဖြေသေးဘူး။

နောက်တော့ ငါအရင်ကပြောဖူးတဲ့ အရာအားလုံးဟာ ငါတိုက်ရမဲ့ ရေခဲတောင်ရဲ့ ထိပ်ဖျားလေးပဲဆိုတာ ငါသိလိုက်ရတယ်။

ဤအရာနှင့် အလွန်လိုက်ဖက်သော ကိုးကားချက်ကောင်းတစ်ခု ရှိပါသည်။

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

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

တစ်နေ့သုံး

ထို့ကြောင့်၊ တင်ခြင်းသည် 4 စက္ကန့်ကြာပြီး အကြီးဆုံးတောင်ထိပ် 13 မှ 15 အထိဖြစ်သည်။

ဤအချိန်ကာလအတွင်း တတိယမြောက်နေ့တွင်၊ ဒေါင်းလုဒ်အမြန်နှုန်းသည် ဤကဲ့သို့ဖြစ်သည်-

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

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

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

- မေးရမှာရှက်တယ် ဒါပေမယ့် 150 နဲ့ 17 က 8 လောက်ပေးတယ်။ ဆာဗာတစ်ခုစီသည် တစ်စက္ကန့်လျှင် တောင်းဆိုမှု 8 ခုခွင့်ပြုသည်ဟု သင်ပြောနေသလား၊ မနက်ဖြန်တွင် တစ်စက္ကန့်လျှင် တောင်းဆိုချက် 160 ရှိသည်ဆိုလျှင်၊ ကျွန်ုပ်တို့သည် နောက်ထပ်ဆာဗာ 2 ခု လိုအပ်မည်ဖြစ်သည်။

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

var currentClass = classes.getCurrentClass();
return currentClass;

လုပ်ဆောင်ချက်တစ်ခုရှိခဲ့သည်။ getCurrentClass()site ပေါ်ရှိအရာအားလုံးသည် class တစ်ခု၏အခြေအနေတွင်အလုပ်လုပ်သောကြောင့်၊ မှန်ပါသည်။ စာမျက်နှာတစ်ခုစီတွင် ဤလုပ်ဆောင်ချက်တစ်ခုစီရှိခဲ့သည်။ တောင်းဆိုချက် 200+.

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

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

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

သို့သော် ဤပထမပြဿနာကို ဖြေရှင်းလိုက်ခြင်းဖြင့် ဂရပ်သည် များစွာနိမ့်ကျသွားသည်။

တစ်ချိန်တည်းမှာပင်၊ ကျွန်ုပ်တို့သည် အခြားသော ပိုမိုကောင်းမွန်အောင် လုပ်ဆောင်နေပါသည်။ ပြင်လို့ရတဲ့ အရာတွေ အများကြီးရှိခဲ့တယ်။ ဥပမာအားဖြင့်၊ သုံးရက်မြောက်သောနေ့၌ပင် အားလုံးပြီးနောက် system တွင် ကက်ရှ်တစ်ခုရှိသည်ကို ကျွန်ုပ်တွေ့ရှိခဲ့သည် (အစတွင် တောင်းဆိုမှုအားလုံးသည် ဒေတာဘေ့စ်မှ တိုက်ရိုက်လာသည်ဟု ကျွန်တော်ထင်ခဲ့သည်)။ ကက်ရှ်တစ်ခုအကြောင်း စဉ်းစားသောအခါ၊ စံ Redis သို့မဟုတ် Memcached ကို တွေးသည်။ ဒါပေမယ့် အဲဒီစနစ်က MongoDB နဲ့ SQL Server ကို ကက်ချဖို့အတွက် အသုံးပြုခဲ့တာဖြစ်လို့ ဒီစနစ်က ဒေတာကိုဖတ်လိုက်ရုံနဲ့ အတူတူပါပဲ။

ဆယ်ရက်

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

စိတ်ဝင်စားစရာကောင်းတဲ့ အရာတစ်ခုကို ထပ်မံတွေ့ရှိခဲ့ပါတယ်။ အဖွဲ့တွင် developer 18 ယောက်ပါဝင်ပါသည်။ 8 စမ်းသပ်သူများ; 3 မန်နေဂျာ; ဗိသုကာပညာရှင် ၂။ ပြီးတော့ သူတို့အားလုံးဟာ ရိုးရာဓလေ့ထုံးစံတွေမှာ ပါဝင်ခဲ့ကြတယ် ဆိုလိုတာက မနက်တိုင်း လူ 2 ကျော်က မတ်တပ်ရပ်ပြီး သူတို့လုပ်ခဲ့တာတွေကို ပြောပြတယ်။ အစည်းအဝေးသည် ၅ မိနစ် သို့မဟုတ် ၁၅ မိနစ်မျှ မကြာမြင့်ကြောင်း ထင်ရှားသည်။ လူတိုင်းက မတူညီတဲ့ စနစ်တွေမှာ အလုပ်လုပ်တဲ့အတွက် ဘယ်သူ့စကားကိုမှ နားမထောင်ဘူး။ ဤပုံစံတွင်၊ တစ်နာရီလျှင် လက်မှတ် ၂-၃ စောင်သည် ကောင်းသောရလဒ်ဖြစ်နေပြီဖြစ်သည်။

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

ရလဒ်အဖြစ် ကျွန်ုပ်တို့ ရရှိခဲ့သည်

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

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

ဆယ့်တစ်ရက်

အသင်းဖွဲ့စည်းပုံပြောင်းလဲခြင်းလုပ်ငန်းစဉ်တွင် ရေတွက်နည်းကို ကျွန်ုပ်ရှာဖွေတွေ့ရှိခဲ့သည်။ အကွောငျးအရာရမှတ်. 1 SP သည် တစ်ရက်နှင့် ညီမျှပြီး လက်မှတ်တစ်ခုစီတွင် တိုးတက်မှုနှင့် QA နှစ်ခုလုံးအတွက် SP ပါရှိသည်၊ ဆိုလိုသည်မှာ အနည်းဆုံး 2 SP ဖြစ်သည်။

ဒါကို ဘယ်လိုရှာဖွေတွေ့ရှိခဲ့တာလဲ။

ကျွန်ုပ်တို့သည် ချွတ်ယွင်းချက်တစ်ခုကို တွေ့ရှိသည်- အစီရင်ခံစာအတွက် လိုအပ်သည့်ကာလ၏ အစနှင့် အဆုံးရက်စွဲကို ထည့်သွင်းသည့် အစီရင်ခံစာတစ်ခုတွင်၊ နောက်ဆုံးနေ့ကို ထည့်သွင်းစဉ်းစားမည်မဟုတ်ပါ။ ဆိုလိုတာက တောင်းဆိုမှုမှာ တစ်နေရာရာမှာ <= မရှိပေမယ့် ရိုးရိုး <။ ဒါက Story Points သုံးခုပါလို့ ပြောခဲ့တယ်။ 3 ရက်ပေါင်း.

ဒီနောက်မှာတော့ ကျွန်တော်တို့

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

နှစ်ဆယ်မြောက်နေ့

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

ရေရှည်ရည်မှန်းချက်များ

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

အရင်တုန်းကတော့ မကြာခဏပြောဖူးတယ်။ "[ဘာသာစကား/ဘောင်] ဖြင့် အရာအားလုံးကို ပြန်ရေးကြပါစို့၊ အရာအားလုံး ပိုကောင်းလာမည်!"

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

• ပရောဂျက်၏ ရည်မှန်းချက်များနှင့် ရည်မှန်းချက်များကို ထင်ဟပ်စေခြင်း၊
• အဓိကပန်းတိုင်များကို ဦးစားပေးသည်။
• ၎င်းတို့ကို အောင်မြင်ရန် အချိန်ဇယားပါရှိသည်။

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

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

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

ထုတ်ကုန်အသစ်များ ပိုမိုရရှိရန် ရည်မှန်းချက်ကို သင်မည်သို့ပံ့ပိုးနိုင်မည်နည်း။

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

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

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

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

နေ့သုံးဆယ်

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

• ပထမဦးစွာ SLA များကို စာချုပ်များတွင် သတ်မှတ်ထားသောကြောင့်ဖြစ်သည်။
• ဒုတိယအချက်မှာ SLA များသည် ကွဲပြားသည်။ ဖောက်သည်တစ်ဦးစီသည် ၎င်း၏လိုအပ်ချက်များနှင့်အတူ ရောက်ရှိလာပြီး အရောင်းဌာနမှ မကြည့်ဘဲ လက်မှတ်ထိုးခဲ့သည်။

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

အကယ်၍ ဇူလိုင်လတွင် လုံးဝ မပံ့ပိုးတော့သော ColdFusion နှင့် SQL Server 1 ကို အခြေခံထားမည်ဆိုပါက ကျွန်ုပ်တို့ n-2008 နှင့် မည်မျှဝေးကွာသည်ကို ရှင်းပါသည်။

လေးဆယ့်ငါးရက်

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

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

ဒီလိုလုပ်တဲ့အခါ နှစ်ခုလုံးက မျက်လုံးကို ဖမ်းမိသွားတယ်။

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

ပြဿနာမှာ ဤအရာများသည် နိဂုံးချုပ်ခြင်းဖြစ်သည်- အချိန်များစွာယူပုံရသည်၊ သို့သော်မည်မျှကြာမည်ကို ကျွန်ုပ်တို့မသိပါ။

"မတိုင်းတာနိုင်တဲ့အရာကို တိုးတက်အောင် မလုပ်နိုင်ဘူး။"

ပြဿနာ ဘယ်လောက် လေးနက်ကြောင်း တရားမျှတအောင် ဘယ်လိုလုပ်မလဲ။ ရက်တွေ နာရီတွေ ဖြုန်းနေသလား။

၎င်းကိုတိုင်းတာရန်အတွက် Jira လုပ်ငန်းစဉ်တွင် အဆင့်နှစ်ဆင့်ကို ပေါင်းထည့်ခဲ့သည်- "dev အတွက် အဆင်သင့်ဖြစ်နေပြီ" နှင့် "QA အတွက် အဆင်သင့်ဖြစ်နေပြီ" လက်မှတ်တစ်ခုစီသည် မည်မျှကြာကြာစောင့်ဆိုင်းရပြီး သတ်မှတ်ထားသောအဆင့်သို့ အကြိမ်မည်မျှပြန်လာသည်ကို တိုင်းတာရန်။

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

• လုပ်ငန်းစဉ်ထိရောက်မှု- စွမ်းဆောင်ရည်နှင့် စီစဉ်/ပေးပို့ခြင်း။
• လုပ်ငန်းစဉ်အရည်အသွေး- ချို့ယွင်းချက်များ၊ QA မှ ချို့ယွင်းချက်များ။

ဘယ်အရာက ကောင်းကောင်း အဆင်မပြေဘူးဆိုတာကို နားလည်ဖို့ တကယ်ကို ကူညီပေးပါတယ်။

ငါးဆယ်မြောက်နေ့

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

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

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

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

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

နေ့ငါးဆယ့်တစ်

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

“ပြဿနာအများစုဟာ လူတွေရဲ့ပြဿနာပါ။”

Dev နှင့် Ops နှစ်ခုလုံးတွင် ကြီးမားသော ပြဿနာသုံးခုရှိသည်ကို ကျွန်ုပ်တွေ့ရှိခဲ့သည်-

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

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

ဒါပေမယ့် ဘာမှ မပြောင်းလဲဘဲနဲ့ သင် ပိုကောင်းလာဖို့ မဖြစ်နိုင်ပါဘူး။

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

မေးခွန်းကောင်း - ဘာကြောင့်လဲ။ အခုက အရင်ထက် ပိုကောင်းလာသလိုပဲ၊ အားလုံးက လုံလောက်နေပါပြီ။ ယင်းသည် အခြေခံသဘောတရားအရ လုံးဝပုံမှန်မဟုတ်သော တာဝန်ကင်းမဲ့မှုကို ဖြစ်စေသည်။ ကျွန်တော်ပြောသလိုပဲ နည်းပညာအဖွဲ့ဟာ ဘေးနားက နည်းနည်းလေး ရှိတယ်။ ကုမ္ပဏီက ၎င်းတို့ တည်ရှိသင့်သည်ဟု ယုံကြည်သော်လည်း၊ ဘယ်သူကမှ စံချိန်စံညွှန်းမသတ်မှတ်ကြဘူး။. နည်းပညာပံ့ပိုးကူညီမှု SLA ကို တစ်ခါမှမမြင်ဖူးပါ၊ ထို့ကြောင့် ၎င်းသည် အဖွဲ့အတွက် အတော်လေး “လက်ခံနိုင်ဖွယ်” ဖြစ်ခဲ့သည် (၎င်းက ကျွန်ုပ်အား အများဆုံးထိမိသည်)။

• 12 စက္ကန့် loading;
• ထုတ်လွှင့်မှုတစ်ခုစီတိုင်း 5-10 မိနစ်ရပ်နား;
• အရေးကြီးသော ပြဿနာများကို ဖြေရှင်းရန် ရက်များနှင့် ရက်သတ္တပတ်များ ကြာသည်။
• ဝန်ထမ်းမရှိခြင်း 24x7 / on-call ။

ငါတို့ဘာလို့ ပိုကောင်းအောင် မလုပ်တာလဲလို့ ဘယ်သူကမှ မမေးဖူးသလို၊ ဒါက ဒီလိုဖြစ်စရာ မလိုဘူးလို့ ဘယ်သူမှ သဘောပေါက်ခဲ့ဖူးတာ မဟုတ်ဘူး။

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

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

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

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

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

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

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

ခြောက်ဆယ်ရက်

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

အထူးစိတ်ဝင်စားသည်မှာ cloud ဝန်ဆောင်မှုများအတွက် ဥပဒေကြမ်းဖြစ်သည်။ မြင့်မားသော cloud ဘေလ်အတွက် အဓိကအကြောင်းရင်းမှာ ၎င်းတို့၏ဘဝတွင် ပထမဆုံးအကြိမ် ဆာဗာများသို့ အကန့်အသတ်မရှိ ဝင်ရောက်အသုံးပြုနိုင်သည့် developer များဖြစ်သည်ဟု ကျွန်တော်ယုံကြည်ပါသည်။ သူတို့က "ကျေးဇူးပြု၍ စမ်းသပ်ဆာဗာတစ်ခုပေးပါ" ဟု ၎င်းတို့ကိုယ်တိုင် မေးမြန်းရန် မလိုအပ်ပါ။ ထို့အပြင်၊ ဆော့ဖ်ဝဲရေးသားသူများသည် Facebook နှင့် Netflix တို့ကို မနာလိုဖြစ်မည့် ဤကဲ့သို့သော အေးမြသောစနစ်တစ်ခုကို တည်ဆောက်လိုကြသည်။

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

စာရင်းရလဒ်များ-

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

ခုနစ်ဆယ့်ငါးရက်

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

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

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

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

ဆိုလိုသည်မှာ ColdFusion သည် Jetty နှင့် nginx ကိုဖြတ်၍ စာမျက်နှာများကိုဖွင့်သည်။ ပုံများ၊ JS နှင့် CSS တို့သည် ၎င်းတို့၏ကိုယ်ပိုင်ဖွဲ့စည်းပုံများဖြင့် သီးခြား nginx ကိုဖြတ်သန်းကြသည်။ ဒါက ကျွန်တော်ပြောနေတဲ့ စံနှုန်းတစ်ခုပါပဲ။ ငါရေးသားခဲ့သည် လွန်ခဲ့သောနှစ်အနည်းငယ်က ရလဒ်အနေဖြင့်၊ ပုံများပိုမိုမြန်ဆန်စွာတင်နိုင်ပြီး... ပျမ်းမျှ loading speed သည် 200 ms တိုးလာသည်။

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

ရှစ်ဆယ့်ငါးရက်

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

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

ကောက်ချက်

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

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

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

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

ဤအရာဖြင့် အခြားအရာအားလုံး ရောက်ရှိလာလိမ့်မည်။

လီယွန်မီး twitter ပေါ်မှာ, facebook နှင့် အလယ်အလတ်.

အမွေအနှစ်နှင့် ပတ်သက်သည့် နည်းဗျူဟာ နှစ်ခုရှိသည်- ၎င်းကို ကုန်ကျစရိတ်အားလုံးဖြင့် လုပ်ဆောင်ခြင်းမှ ရှောင်ကြဉ်ပါ သို့မဟုတ် ဆက်နွယ်နေသော အခက်အခဲများကို ရဲရင့်စွာ ကျော်ဖြတ်ပါ။ ကျွန်တော်တို c DevOpsConf ကျွန်ုပ်တို့သည် ဒုတိယလမ်းကြောင်း၊ လုပ်ငန်းစဉ်များနှင့် ချဉ်းကပ်မှုများကို ပြောင်းလဲနေသည်။ ကျွန်ုပ်တို့ကို ဆက်သွယ်လိုက်ပါ။ youtube က, စာပို့စာရင်း и ကြေးနန်းစာနှင့် DevOps ယဉ်ကျေးမှုကို အတူတကွ အကောင်အထည်ဖော်ပါမည်။

source: www.habr.com