ထိပ်တန်း fakapov အစိမ်းနုရောင်

အားလုံးအကောင်း! 

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

နိဒါန်း

ဟိုးရှေးရှေးတုန်းက Cian သည် monolith များပါ၀င်ပြီး microservices များ၏အရိပ်အမြွက်မျှမရှိသေးသောအခါ၊ စာမျက်နှာ 3-5 ကိုစစ်ဆေးခြင်းဖြင့် အရင်းအမြစ်တစ်ခု၏ရရှိနိုင်မှုကို တိုင်းတာပါသည်။ 

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

ဆိုက်၏ အဓိက စာမျက်နှာများ သို့မဟုတ် ကျွန်ုပ်တို့သည် အောက်ခြေကို ထိသွားကြောင်း ကျွန်ုပ်တို့ နားလည်ပုံ

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

ပင်မဝန်ဆောင်မှုအတွက် တာဝန်ရှိသော ဝဘ်ဆိုက်၏ အလွန်အရေးကြီးသော အပိုင်းများစွာရှိသည် - ကြော်ငြာများကို ရှာဖွေခြင်းနှင့် တင်သွင်းခြင်းတို့ကို တွေ့ရှိခဲ့သည်ဟုဆိုကြပါစို့။ ပျက်ကွက်သောတောင်းဆိုမှုအရေအတွက်သည် 1% ထက်ကျော်လွန်ပါက၊ ဤသည်မှာ အရေးကြီးသောဖြစ်ရပ်တစ်ခုဖြစ်သည်။ 15 မိနစ်အတွင်း error rate 0,1% ကျော်လွန်နေပါက၊ ၎င်းသည် အရေးကြီးသော ဖြစ်ရပ်တစ်ခုဟုလည်း ယူဆပါသည်။ ဤစံနှုန်းများသည် အဖြစ်အပျက်အများစုကို အကျုံးဝင်သည်၊ ကျန်အရာများသည် ဤဆောင်းပါး၏ ဘောင်ကျော်လွန်ပါသည်။

ထိပ်တန်းအကောင်းဆုံးဖြစ်ရပ်များ Cian

ဒါကြောင့် အဖြစ်အပျက်တစ်ခု ဖြစ်ခဲ့တယ်ဆိုတဲ့အချက်ကို သေချာဆုံးဖြတ်ဖို့ သင်ယူခဲ့ပါတယ်။ 

ယခုအဖြစ်အပျက်တိုင်းကို အသေးစိတ်ဖော်ပြပြီး Jira ဇာတ်လမ်းတွင် ထင်ဟပ်နေပါသည်။ စကားမစပ်၊ ဤအတွက် ကျွန်ုပ်တို့သည် FAIL ဟုခေါ်သော သီးခြားပရောဂျက်တစ်ခုကို စတင်ခဲ့သည် - ၎င်းတွင်သာ ဇာတ်လမ်းများကို ဖန်တီးနိုင်သည်။ 

လွန်ခဲ့သည့်နှစ်အနည်းငယ်အတွင်း ကျရှုံးမှုများအားလုံးကို စုဆောင်းထားမည်ဆိုလျှင် ခေါင်းဆောင်များသည်- 

• mssql ဆက်စပ်ဖြစ်ရပ်များ;
• ပြင်ပ အကြောင်းတရားများကြောင့် ဖြစ်ပေါ်လာသော အဖြစ်အပျက်များ၊
• admin အမှားများ။

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

ပဉ္စမနေရာ - "အရာများကို DNS တွင် စနစ်တကျထားရှိခြင်း"

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

DNS မှလွဲ၍ ဘာမှမရှိသော ဤအတွက် လုံး၀ သီးခြားဆာဗာများကို ခွဲဝေပေးကာ အတွင်း DNS ဆာဗာများကို bind မှ powerdns သို့ လွှဲပြောင်းပေးလိုပါသည်။ 

ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ DCs များ၏တည်နေရာတစ်ခုစီတွင် DNS ဆာဗာတစ်ခုထားရှိခဲ့ပြီး၊ အခိုက်အတန့်တွင် ဇုန်များကို bind မှ powerdns သို့ရွှေ့ကာ အခြေခံအဆောက်အအုံအား ဆာဗာအသစ်များသို့ပြောင်းရန် ရောက်လာခဲ့သည်။ 

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

ကောက်ချက်:

အကယ်၍ ကျွန်ုပ်တို့သည် အလုပ်အတွက် ပြင်ဆင်နေစဉ်အတွင်း ပြင်ပအချက်များ လျစ်လျူရှုထားပါက၊ ယခုအခါ ၎င်းတို့သည် ကျွန်ုပ်တို့အတွက် ပြင်ဆင်နေသည့်စာရင်းတွင် ပါဝင်နေပါသည်။ ယခု ကျွန်ုပ်တို့သည် အစိတ်အပိုင်းအားလုံးကို n-2 ကို သိမ်းဆည်းထားကြောင်း သေချာစေရန် ကျွန်ုပ်တို့ ကြိုးစားနေပြီး အလုပ်အတွင်းတွင် ဤအဆင့်ကို n-1 သို့ လျှော့ချနိုင်သည်။

• လုပ်ဆောင်ချက်အစီအစဥ်တစ်ခုရေးဆွဲသည့်အခါ၊ ဝန်ဆောင်မှုမအောင်မြင်နိုင်သည့်အချက်များကို အမှတ်အသားပြုပြီး အရာအားလုံး "ဆိုးမှဆိုးရွားသည်" ကို ကြိုတင်စဉ်းစားပါ။
• ကွဲပြားသော ပထဝီဝင်တည်နေရာများ/ဒေတာစင်တာ/ရက်ကွက်များ/ခလုတ်များ/ထည့်သွင်းမှုများဖြင့် အတွင်း DNS ဆာဗာများကို ဖြန့်ဝေပါ။
• ဆာဗာတစ်ခုစီတွင်၊ ပင်မ DNS ဆာဗာများသို့ တောင်းဆိုချက်များကို ပြန်လည်ညွှန်းပေးသည့် ဒေသတွင်း ကက်ရှ် DNS ဆာဗာကို ထည့်သွင်းပါ၊ ၎င်းသည် မရရှိနိုင်ပါက၊ ၎င်းသည် ကက်ရှ်မှ တုံ့ပြန်မည်ဖြစ်သည်။ 

စတုတ္ထနေရာ - "အရာများကို Nginx တွင် စနစ်တကျထားရှိခြင်း"

ကောင်းသောနေ့တွင်၊ ကျွန်ုပ်တို့၏အဖွဲ့သည် "ကျွန်ုပ်တို့၌ဤအလုံအလောက်ရှိသည်" ဟုဆုံးဖြတ်ခဲ့ပြီး nginx configs ပြန်လည်ပြင်ဆင်ခြင်းလုပ်ငန်းစဉ်စတင်ခဲ့သည်။ အဓိက ရည်မှန်းချက်မှာ configs များကို ပင်ကိုယ်ဖွဲ့စည်းပုံသို့ ယူဆောင်လာရန်ဖြစ်သည်။ ယခင်က၊ အရာအားလုံးသည် "သမိုင်းတွင်တည်သည်" ရှိပြီး မည်သည့်ယုတ္တိမျှမထားပါ။ ယခု server_name တစ်ခုစီကို နာမည်တူဖိုင်တစ်ခုသို့ ရွှေ့ပြီး configs အားလုံးကို folders များသို့ ဖြန့်ဝေထားသည်။ စကားမစပ်၊ config တွင် 253949 လိုင်းများ သို့မဟုတ် 7836520 စာလုံးများပါရှိပြီး 7 megabytes နီးပါးရှိသည်။ ဖွဲ့စည်းပုံ၏ ထိပ်တန်းအဆင့် 

Nginx ဖွဲ့စည်းပုံ

├── access
│   ├── allow.list
...
│   └── whitelist.conf
├── geobase
│   ├── exclude.conf
...
│   └── geo_ip_to_region_id.conf
├── geodb
│   ├── GeoIP.dat
│   ├── GeoIP2-Country.mmdb
│   └── GeoLiteCity.dat
├── inc
│   ├── error.inc
...
│   └── proxy.inc
├── lists.d
│   ├── bot.conf
...
│   ├── dynamic
│   └── geo.conf
├── lua
│   ├── cookie.lua
│   ├── log
│   │   └── log.lua
│   ├── logics
│   │   ├── include.lua
│   │   ├── ...
│   │   └── utils.lua
│   └── prom
│       ├── stats.lua
│       └── stats_prometheus.lua
├── map.d
│   ├── access.conf
│   ├── .. 
│   └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│   ├── cian.ru
│   │   ├── cian.ru.conf
│   │   ├── ...
│   │   └── my.cian.ru.conf
├── service.d
│   ├── ...
│   └── status.conf
└── upstream.d
    ├── cian-mcs.conf
    ├── ...
    └── wafserver.conf

၎င်းသည် များစွာပိုကောင်းလာသည်၊ သို့သော် configs အမည်ပြောင်းခြင်းနှင့် ဖြန့်ဝေခြင်းလုပ်ငန်းစဉ်တွင်၊ ၎င်းတို့ထဲမှ အချို့သည် မှားယွင်းသော extension ရှိပြီး *.conf ညွှန်ကြားချက်တွင် မပါဝင်ပါ။ ရလဒ်အနေဖြင့် အချို့သော host များ မရရှိနိုင်တော့ဘဲ 301 ကို ပင်မစာမျက်နှာသို့ ပြန်ပို့ပေးပါသည်။ တုံ့ပြန်ကုဒ်သည် 5xx/4xx မဟုတ်သောကြောင့်၊ ၎င်းကို ချက်ချင်းသတိမထားမိသော်လည်း နံနက်ပိုင်းသာဖြစ်သည်။ ထို့နောက် အခြေခံအဆောက်အအုံ အစိတ်အပိုင်းများကို စစ်ဆေးရန် စာရေးစမ်းသပ်မှုများ စတင်ခဲ့သည်။

ကောက်ချက်: 

• သင်၏ဖွဲ့စည်းပုံများကို မှန်ကန်စွာတည်ဆောက်ပါ (nginx မျှသာမဟုတ်) နှင့် ပရောဂျက်၏အစောပိုင်းအဆင့်တွင် ဖွဲ့စည်းပုံကို စဉ်းစားပါ။ ဤနည်းဖြင့် သင်သည် ၎င်းတို့အား အသင်းအား ပိုမိုနားလည်နိုင်စေမည်ဖြစ်ပြီး ၎င်းသည် TTM ကို လျှော့ချမည်ဖြစ်သည်။
• အချို့သော အခြေခံအဆောက်အဦ အစိတ်အပိုင်းများအတွက် စမ်းသပ်မှုများ ရေးသားပါ။ ဥပမာ- သော့ဆာဗာ_အမည်များအားလုံးသည် မှန်ကန်သောအခြေအနေ + တုံ့ပြန်မှုကိုယ်ထည်ကိုပေးကြောင်း စစ်ဆေးခြင်း။ အစိတ်အပိုင်း၏ အခြေခံလုပ်ဆောင်ချက်များကို စစ်ဆေးသည့် script အနည်းငယ်မျှသာ လက်ထဲတွင် ရှိနေမည်ဖြစ်ပြီး၊ နံနက် 3 နာရီတွင် အခြားမည်သည့်အရာများကို စစ်ဆေးရန် လိုအပ်သည်ကို အရူးအမူးမမှတ်မိစေရန်အတွက် လုံလောက်မည်ဖြစ်သည်။ 

တတိယနေရာ - "Cassandra တွင် ရုတ်တရက် နေရာလွတ်ကုန်သွားသည်"

ဒေတာများသည် တဖြည်းဖြည်း ကြီးထွားလာပြီး Cassandra cluster တွင် ကြီးမားသော casespace များကို ပြုပြင်ခြင်း မအောင်မြင်မီအထိ အရာအားလုံး အဆင်ပြေသွားပါသည်။ 

မုန်တိုင်းထန်သောတစ်နေ့တွင် အစုအဝေးသည် ရွှေဖရုံသီးအဖြစ်သို့ ပြောင်းလဲလုနီးပါးဖြစ်သည်၊

• အစုအဝေးတွင် နေရာစုစုပေါင်း၏ 20% ခန့် ကျန်နေပါသည်။
• အခန်းကန့်များတွင် နေရာလွတ်မရှိခြင်းကြောင့် node တစ်ခုကို ပေါင်းထည့်ပြီးနောက် သန့်ရှင်းမှု ပျက်သွားသောကြောင့် node များကို အပြည့်အ၀ထည့်ရန် မဖြစ်နိုင်ပါ။
• ကြိတ်စက် အလုပ်မလုပ်သောကြောင့် ကုန်ထုတ်စွမ်းအား တဖြည်းဖြည်း ကျဆင်းလာသည်။ 
• အစုအဝေးသည် အရေးပေါ်မုဒ်တွင် ရှိနေသည်။

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

ကောက်ချက်:

• cassandra ဆာဗာများအားလုံးတွင်၊ partition တစ်ခုစီရှိ space ၏ 60% ထက်မပိုစေရပါ။ 
• ၎င်းတို့ကို 50% cpu ထက်မပိုစေရပါ။
• စွမ်းရည်အစီအစဥ်ရေးဆွဲခြင်းအကြောင်း သင်မမေ့သင့်ဘဲ ၎င်း၏အသေးစိတ်အချက်များပေါ်အခြေခံ၍ အစိတ်အပိုင်းတစ်ခုစီအတွက် ၎င်းကိုစဉ်းစားရန် လိုအပ်ပါသည်။
• အစုအဝေးတွင် များလေလေ၊ ပိုကောင်းလေဖြစ်သည်။ ဒေတာပမာဏအနည်းငယ်ပါရှိသော ဆာဗာများသည် ဝန်ပိုမြန်ပြီး ထိုသို့သောအစုအဝေးကို ပြန်လည်အသက်သွင်းရန် ပိုမိုလွယ်ကူသည်။ 

ဒုတိယနေရာ - "ကောင်စစ်ဝန်ကီး-တန်ဖိုး သိုလှောင်မှုမှ ဒေတာများ ပျောက်ကွယ်သွားသည်"

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

ကောက်ချက်:

• ခွင့်ပြုချက်မရှိဘဲ ဝန်ဆောင်မှုများသည် ဆိုက်၏လည်ပတ်မှုအတွက် အရေးကြီးသော ဒေတာမပါဝင်သင့်ပါ။ ဥပမာအားဖြင့်၊ သင့်တွင် ES တွင် ခွင့်ပြုချက်မရှိပါက၊ မလိုအပ်သည့်နေရာတိုင်းမှ ကွန်ရက်အဆင့်တွင် ဝင်ရောက်ခွင့်ကို ငြင်းပယ်ရန်၊ လိုအပ်သည့်အရာများကိုသာ ထားခဲ့ကာ action.destructive_requires_name: true ဟု သတ်မှတ်ခြင်းသည် ပိုကောင်းမည်ဖြစ်သည်။
• သင်၏ အရန်သိမ်းခြင်းနှင့် ပြန်လည်ရယူခြင်း ယန္တရားကို ကြိုတင်လေ့ကျင့်ပါ။ ဥပမာအားဖြင့်၊ အရန်ကူးပြီး ပြန်လည်ရယူနိုင်သော ဇာတ်ညွှန်းတစ်ခု (ဥပမာ python တွင်) ကြိုတင်ပြုလုပ်ပါ။

ပထမနေရာ - "ကပ္ပတိန် Unobvious" 

တစ်ချိန်ချိန်တွင်၊ နောက်ကွယ်တွင် ဆာဗာ 10+ ရှိသည့်ကိစ္စများတွင် nginx အထက်ရေစီးကြောင်းများပေါ်တွင် ဝန်မညီမညာ ဖြန့်ဖြူးမှုကို ကျွန်ုပ်တို့သတိပြုမိခဲ့သည်။ round-robin သည် 1st မှ နောက်ဆုံးရေစီးကြောင်းအထိ တောင်းဆိုမှုများကို အစီအစဥ်ပေးပို့ပြီး nginx ပြန်လည်စတင်မှုတစ်ခုစီသည် အစမှပြန်စသောကြောင့်၊ ပထမရေစီးကြောင်းများသည် အခြားအရာများထက် တောင်းဆိုမှုများ ပိုမိုရရှိလေ့ရှိပါသည်။ ရလဒ်အနေဖြင့် ၎င်းတို့သည် ပိုမိုနှေးကွေးပြီး ဝဘ်ဆိုက်တစ်ခုလုံးကို ထိခိုက်စေခဲ့သည်။ ယာဉ်အသွားအလာ များပြားလာသည်နှင့်အမျှ ၎င်းသည် ပိုမိုသိသာလာသည်။ ကျပန်းဖွင့်ရန် nginx ကို အဆင့်မြှင့်တင်ခြင်းမှာ အလုပ်မဖြစ်ခဲ့ပါ - ကျွန်ုပ်တို့သည် ဗားရှင်း 1.15 (ယခုအချိန်တွင် မပေါ်သေးသော lua ကုဒ်များစွာကို ပြန်လည်လုပ်ဆောင်ရန် လိုအပ်ပါသည်။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ nginx 1.14.2 ကို patch လုပ်ကာ ၎င်းတွင် ကျပန်းပံ့ပိုးမှုကို မိတ်ဆက်ပေးခဲ့သည်။ ဒါက ပြဿနာကို ဖြေရှင်းပေးတယ်။ ဤချို့ယွင်းချက်သည် “ကပ္ပတိန်မရှင်းလင်းသော” အမျိုးအစားကို ရရှိသည်။

ကောက်ချက်:

ဒီပိုးကောင်ကို စူးစမ်းလေ့လာရတာ အရမ်းစိတ်ဝင်စားစရာကောင်းပြီး စိတ်လှုပ်ရှားစရာကောင်းပါတယ်။) 

• ထိုသို့သော အတက်အကျများကို လျင်မြန်စွာ တွေ့ရှိနိုင်ရန် ကူညီပေးနိုင်ရန် သင်၏ စောင့်ကြည့်မှုကို စုစည်းပါ။ ဥပမာအားဖြင့်၊ သင်သည် အထက်စီးကြောင်းတစ်ခုစီ၏ နောက်ခံတစ်ခုစီရှိ rps ကို စောင့်ကြည့်ရန်၊ nginx ရှုထောင့်မှ ၎င်းတို့၏ တုံ့ပြန်ချိန်ကို စောင့်ကြည့်ရန် ELK ကို အသုံးပြုနိုင်သည်။ ဤကိစ္စတွင်၊ ၎င်းသည် ကျွန်ုပ်တို့အား ပြဿနာကို ဖော်ထုတ်ရန် ကူညီပေးခဲ့သည်။ 

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

source: www.habr.com