DevOps အကြောင်းပြောသောအခါ အဓိကအချက်ကို နားလည်ရန် ခက်ခဲပါသလား။ သင့်အတွက် ကွက်ကွက်ကွင်းကွင်း ဥပမာများ၊ ဖော်မြူလာများနှင့် ကျွမ်းကျင်သူများထံမှ အကြံဉာဏ်များကို ကျွမ်းကျင်သူများထံ မရောက်ရောက်အောင် ကူညီပေးမည့် အကြံဉာဏ်များကို သင့်အတွက် ကျွန်ုပ်တို့ စုဆောင်းထားပါသည်။ အဆုံးတွင်၊ ဘောနပ်စ်သည် Red Hat ဝန်ထမ်းများ၏ကိုယ်ပိုင် DevOps ဖြစ်သည်။
Термин DevOps возник 10 лет назад и прошел путь от хэштега в Твиттере до мощного культурного движения в мире ИТ, настоящей философии, поощряющей разработчиков быстрее добиваться результатов, экспериментировать и двигаться вперед методом итераций. DevOps стал неразрывно связан с понятием цифровой трансформации. Но как это часто бывает с ИТ-терминологией, за десяток лет DevOps успел обрасти множеством определений, трактовок и заблуждений на свой счет.
Поэтому про DevOps нередко можно услышать вопросы вроде, это то же самое, что agile? Или это какая-то особая методология? Или это просто еще один синоним слова «сотрудничество»?
DevOps включает в себя много разных концепций (непрерывная доставка, непрерывная интеграция, автоматизация и т. п.), поэтому вычленить главное может быть непросто, особенно когда вы неравнодушны к предмету. Однако это умение очень полезно, неважно, пытаетесь ли вы донести свои идеи до начальства или же просто рассказываете о своей работе кому-то из родных или знакомых. Поэтому пока отложим в сторону терминологические нюансы DevOps и сосредоточимся на общей картине.
DevOps ဟူသည် အဘယ်နည်း- 6 အဓိပ္ပါယ်ဖွင့်ဆိုချက်များနှင့် Analogies
ကျွန်ုပ်တို့သည် DevOps ၏အနှစ်သာရကို တတ်နိုင်သမျှ ရိုးရိုးရှင်းရှင်းနှင့် အတိုချုံးရှင်းပြရန် ကျွမ်းကျင်သူများကို ကျွန်ုပ်တို့က နည်းပညာဆိုင်ရာ အသိပညာအဆင့်ဖြင့် စာဖတ်သူများထံ ၎င်း၏တန်ဖိုးကို ရှင်းရှင်းလင်းလင်းဖြစ်လာစေရန် တောင်းဆိုထားသည်။ ဤစကားဝိုင်းများ၏ ရလဒ်များအပေါ် အခြေခံ၍ DevOps နှင့်ပတ်သက်သော သင့်ဇာတ်လမ်းကို တည်ဆောက်ရာတွင် အထောက်အကူဖြစ်စေမည့် အထူးခြားဆုံးသော တူညီသော တူညီချက်များနှင့် အထူးခြားဆုံးပုံစံများကို ကျွန်ုပ်တို့ ရွေးချယ်ထားပါသည်။
1. DevOps သည် ယဉ်ကျေးမှုလှုပ်ရှားမှုတစ်ခုဖြစ်သည်။
"DevOps သည် နှစ်ဖက်စလုံး (ဆော့ဖ်ဝဲလ်တီထွင်သူများနှင့် အိုင်တီစနစ်လည်ပတ်ရေးကျွမ်းကျင်သူများ) သည် တစ်စုံတစ်ဦးမှစတင်အသုံးပြုသည့်အချိန်အထိ ဆော့ဖ်ဝဲလ်သည် အမှန်တကယ်အကျိုးအမြတ်များမယူဆောင်ကြောင်း အသိအမှတ်ပြုသည့် ယဉ်ကျေးမှုလှုပ်ရှားမှုတစ်ခုဖြစ်သည်" ဟု အကြီးတန်းသုတေသနပြုသူ Eveline Oehrlich မှ ပြောကြားခဲ့သည်။ DevOps Institute မှ သုံးသပ်သူ။ "ထို့ကြောင့်၊ ဤပါတီနှစ်ရပ်စလုံးသည် လျင်မြန်ပြီး အရည်အသွေးမြင့် ဆော့ဖ်ဝဲလ်ပေးပို့မှုကို အာမခံပါသည်။"
2. DevOps သည် developer များအား စွမ်းဆောင်ရည်မြှင့်တင်ပေးသည့်အကြောင်းဖြစ်သည်။
"DevOps သည် developer များအား အပလီကေးရှင်းများ ပိုင်ဆိုင်ရန်၊ ၎င်းတို့ကို လုပ်ဆောင်ရန်နှင့် ပေးပို့မှုကို အစမှ အဆုံးထိ စီမံခန့်ခွဲရန် အခွင့်အာဏာပေးသည်။"
"ပုံမှန်အားဖြင့်၊ DevOps သည် ထုတ်လုပ်မှုသို့ အက်ပ်လီကေးရှင်းများ ပေးပို့မှုကို အရှိန်မြှင့်ရန် နည်းလမ်းတစ်ခုအဖြစ် ပြောဆိုနေကြသည်" ဟု အာမခံကုမ္ပဏီ Liberty Mutual မှ DevOps ပလပ်ဖောင်းများ၏ ဒါရိုက်တာ Jai Schniepp က ပြောကြားခဲ့သည်။ "ဒါပေမယ့် ငါ့အတွက်က ပိုအခြေခံကျတဲ့ အရာတစ်ခုပါ။" DevOps သည် developer များအား အပလီကေးရှင်းများ သို့မဟုတ် ဆော့ဖ်ဝဲလ်အပိုင်းအစများကို ပိုင်ဆိုင်ရန်၊ ၎င်းတို့ကို လုပ်ဆောင်ရန်နှင့် ၎င်းတို့၏ ပေးပို့မှုကို အစမှအဆုံးအထိ စီမံခန့်ခွဲရန် အခွင့်အာဏာပေးသည်။ DevOps သည် တာဝန်အရှုပ်အထွေးများကို ဖယ်ရှားပေးပြီး အလိုအလျောက် တီထွင်သူ-မောင်းနှင်သော အခြေခံအဆောက်အအုံကို ဖန်တီးရာတွင် ပါဝင်သူတိုင်းကို လမ်းညွှန်ပေးသည်။"
3. DevOps – это сотрудничество при создании и доставке приложений
"ရိုးရှင်းစွာပြောရလျှင် DevOps သည် လူတိုင်းအတူတကွအလုပ်လုပ်နိုင်သည့်ဆော့ဖ်ဝဲလ်ထုတ်လုပ်ရေးနှင့်ပေးပို့ခြင်းဆိုင်ရာချဉ်းကပ်မှုတစ်ခုဖြစ်သည်" ဟု BMC ၏ဒစ်ဂျစ်တယ်လုပ်ငန်းအလိုအလျောက်စနစ်၏ဥက္ကဌနှင့်ခေါင်းဆောင် Gur Staf ကပြောကြားခဲ့သည်။
4. DevOps – это конвейер
«Конвейерная сборка возможна, только если все детали подходят друг к другу».
"ကျွန်တော် DevOps ကို ကားတပ်ဆင်တဲ့လိုင်းနဲ့ နှိုင်းယှဉ်မယ်" ဟု Gur Staff က ဆက်လက်ပြောပြသည်။ - စိတ်ကူးကတော့ အစိတ်အပိုင်းအားလုံးကို ဒီဇိုင်းဆွဲပြီး ကြိုပြီးလုပ်ထားတာမို့ တစ်ဦးချင်း ချိန်ညှိစရာမလိုဘဲ စုစည်းနိုင်ပါတယ်။ အစိတ်အပိုင်းအားလုံး တညီတညွှတ်တည်းရှိမှသာ Conveyor တပ်ဆင်ခြင်း ဖြစ်နိုင်သည်။ အင်ဂျင်ကို ဒီဇိုင်းဆွဲပြီး ဆောက်သူများသည် ကားကိုယ်ထည် သို့မဟုတ် ဖရိန်တွင် မည်သို့တပ်ဆင်ရမည်ကို စဉ်းစားရမည်ဖြစ်သည်။ ဘရိတ်လုပ်သူတွေက ဘီးတွေအကြောင်း စဉ်းစားရမှာပေါ့။ ဆော့ဖ်ဝဲလ်တွင်လည်း အလားတူဖြစ်သင့်သည်။
လုပ်ငန်းဆိုင်ရာ ယုတ္တိဗေဒ သို့မဟုတ် အသုံးပြုသူမျက်နှာပြင်ကို ဖန်တီးသည့် developer သည် ဖောက်သည်အချက်အလက်ကို သိမ်းဆည်းသည့် ဒေတာဘေ့စ်၊ သုံးစွဲသူဒေတာကို ကာကွယ်ရန် လုံခြုံရေးအစီအမံများနှင့် ဝန်ဆောင်မှု ကြီးမားသော ဒေါ်လာသန်းပေါင်းများစွာ အသုံးပြုသူပရိသတ်ကိုပင် ဝန်ဆောင်မှုပေးသည့်အခါ ၎င်းအားလုံး မည်သို့လုပ်ဆောင်မည်ကို စဉ်းစားရမည်ဖြစ်ပါသည်။ ."
“လူတွေကို ပူးပေါင်းပြီး တခြားသူတွေ လုပ်နေတဲ့ အလုပ်ရဲ့ အစိတ်အပိုင်းတွေကို စဉ်းစားဖို့က ကိုယ့်အလုပ်တွေကိုပဲ အာရုံစိုက်နေတာထက် ကျော်လွှားဖို့ အကြီးမားဆုံး အတားအဆီးပါပဲ။ ဒါကို သင်လုပ်နိုင်ရင် ဒစ်ဂျစ်တယ်အသွင်ပြောင်းဖို့ အခွင့်အလမ်းကောင်းရှိပါတယ်” ဟု Gur Staff က ထပ်လောင်းပြောကြားခဲ့သည်။
5. DevOps – это правильная комбинация людей, процессов и автоматизация
DevOps Institute ၏ အမှုဆောင်ဒါရိုက်တာ Jayne Groll က DevOps ကို ရှင်းပြရန် ကြီးစွာသော တူညီသော တူညီမှုကို ပေးခဲ့သည်။ သူမ၏စကားတွင် "DevOps သည် လူ၊ လုပ်ငန်းစဉ်နှင့် အလိုအလျောက်လုပ်ဆောင်ခြင်း- ပါဝင်ပစ္စည်းများ၏ အဓိကအမျိုးအစားသုံးမျိုးပါသည့် ဟင်းချက်နည်းတစ်ခုနှင့်တူသည်။ ဤပါဝင်ပစ္စည်းများအများစုကို အခြားနယ်ပယ်များနှင့် အရင်းအမြစ်များမှ မှာယူနိုင်သည်- Lean၊ Agile၊ SRE၊ CI/CD၊ ITIL၊ ခေါင်းဆောင်မှု၊ ယဉ်ကျေးမှု၊ ကိရိယာများ။ DevOps ၏လျှို့ဝှက်ချက်သည် ဟင်းချက်နည်းကောင်းများကဲ့သို့ပင်၊ မှန်ကန်သောအချိုးအစားများရရှိရန်နှင့် အပလီကေးရှင်းများဖန်တီးခြင်းနှင့် ထုတ်လွှတ်ခြင်း၏အမြန်နှုန်းနှင့် ထိရောက်မှုတိုးမြင့်စေရန်အတွက် မှန်ကန်သောအချိုးအစားများရရှိစေရန်နှင့် ဤပါဝင်ပစ္စည်းများကို ရောစပ်နည်းဖြစ်သည်။
6. DevOps သည် ပရိုဂရမ်မာများ ဖော်မြူလာ 1 အဖွဲ့ကဲ့သို့ အလုပ်လုပ်သည့် အချိန်ဖြစ်သည်။
“ပြိုင်ပွဲကို အစကနေ အဆုံးအထိ မစီစဉ်ထားပေမယ့် ဆန့်ကျင်ဘက်အနေနဲ့ အဆုံးကနေ အစကနေ ပြန်စမှာပါ။”
«Говоря о том, чего ждать от инициативы DevOps, я привожу в пример гоночную команду NASCAR или Формулы-1, – говорит Крис Шорт (Chris Short), главный менеджер по маркетингу облачных платформ Red Hat и издатель рассылки DevOps’ish. – У руководителя такой команды одна цель: занять по итогам гонки максимально возможное место с учетом имевшихся у команды ресурсов и выпавших на ее долю испытаний. При этом гонка планируется не от старта к финишу, а наоборот, от финиша к старту. Вначале ставится амбициозная цель, а затем определяются пути ее достижения. После чего они разбиваются на подзадачи и делегируются членам команды».
“အဖွဲ့ဟာ တွင်းမှတ်တိုင်ကို ပြီးပြည့်စုံအောင် မပြိုင်ခင် တစ်ပတ်လုံး အချိန်ဖြုန်းပါတယ်။ သူသည် ကြမ်းတမ်းသော ပြိုင်ပွဲနေ့အတွက် ပုံသဏ္ဍာန်ရှိနေစေရန် ခွန်အားလေ့ကျင့်ခန်းနှင့် cardio လုပ်သည်။ ပြိုင်ပွဲအတွင်း ဖြစ်ပေါ်လာနိုင်သည့် ပြဿနာများကို ဖြေရှင်းရန် အတူတကွ ပူးပေါင်းလုပ်ဆောင်သည့် အလေ့အကျင့်များ။ အလားတူ၊ ဖွံ့ဖြိုးတိုးတက်ရေးအဖွဲ့သည် ဗားရှင်းအသစ်များကို မကြာခဏ ထုတ်ဝေခြင်းဆိုင်ရာ ကျွမ်းကျင်မှုကို လေ့ကျင့်ပေးသင့်သည်။ သင့်တွင် ထိုသို့သောကျွမ်းကျင်မှုများနှင့် ကောင်းမွန်စွာလုပ်ဆောင်နိုင်သော လုံခြုံရေးစနစ်ရှိပါက၊ ဗားရှင်းအသစ်များကို ထုတ်လုပ်ခြင်းသို့ လွှင့်တင်ခြင်းသည်လည်း မကြာခဏဖြစ်လေ့ရှိသည်။ ဤကမ္ဘာ့အမြင်တွင်၊ အရှိန်မြှင့်ခြင်းသည် ဘေးကင်းမှုကို တိုးမြင့်စေသည်” ဟု Short ကဆိုသည်။
“မှန်ကန်တဲ့အရာကို လုပ်နေတာမဟုတ်ဘူး၊” လို့ Short က ထပ်လောင်းပြောတယ် “လိုချင်တဲ့ရလဒ်ကို လိုချင်တဲ့ရလဒ်ကို တတ်နိုင်သမျှ ဖယ်ရှားပစ်ဖို့ပဲ ဖြစ်တယ်။ အချိန်နှင့်တပြေးညီ သင်လက်ခံရရှိသော အကြံပြုချက်အပေါ် အခြေခံ၍ ပူးပေါင်းလုပ်ဆောင်ပါ။ ကွဲလွဲချက်များကို ကြိုတင်ပြင်ဆင်ထားပြီး သင့်ပန်းတိုင်ဆီသို့ ၎င်းတို့၏တိုးတက်မှုအပေါ် ၎င်းတို့၏အကျိုးသက်ရောက်မှုကို လျှော့ချရန် အရည်အသွေးမြှင့်တင်ရန် ပြင်ဆင်ပါ။ ဤအရာသည် DevOps ၏ကမ္ဘာတွင် ကျွန်ုပ်တို့ကို စောင့်မျှော်နေပါသည်။"
DevOps ကို တိုင်းတာနည်း- ကျွမ်းကျင်သူများထံမှ အကြံပြုချက် 10 ခု
DevOps နှင့် DevOps အစုလိုက်အပြုံလိုက်များသည် လုံးဝကွဲပြားသောအရာများဖြစ်သည်။ ပထမလမ်းမှ ဒုတိယလမ်းတွင် အတားအဆီးများကို မည်သို့ကျော်ဖြတ်ရမည်ကို ပြောပြပါမည်။
Для многих организаций путь к DevOps начинается легко и приятно. Создаются небольшие пассионарные команды, старые процессы заменяются на новые и первые успехи не заставляют себя ждать.
ကံမကောင်းစွာပဲ၊ ဒါဟာ တိုးတက်မှုရဲ့ ထင်ယောင်ထင်မှားဖြစ်စေတဲ့ လှည့်ကွက်တစ်ခုသာဖြစ်တယ်လို့ North Highland ရဲ့ ဒစ်ဂျစ်တယ်အကြံပေးအဖွဲ့ရဲ့ မန်နေးဂျင်းဒါရိုက်တာနဲ့ အကြီးအကဲ Ben Grinnell က ပြောပါတယ်။ အစောပိုင်းအနိုင်ရမှုများသည် အားရစရာဖြစ်သော်လည်း၊ ၎င်းတို့သည် အဖွဲ့အစည်းအနှံ့ DevOps ကို ကျယ်ကျယ်ပြန့်ပြန့် လက်ခံကျင့်သုံးခြင်း၏ အဆုံးစွန်ပန်းတိုင်ကို မအောင်မြင်နိုင်ပေ။
ရလဒ်သည် "ကျွန်ုပ်တို့" နှင့် "သူတို့" အကြား ပိုင်းခြားသည့် ယဉ်ကျေးမှုတစ်ခုဖြစ်ကြောင်း သိမြင်ရန် လွယ်ကူသည်။
«Зачастую организации запускают такие проекты-первопроходцы, считая, что они проложат путь к массовому DevOps, не задумываясь, смогут и захотят ли пойти этим путем остальные, – объясняет Бен Гриннел. – Команды для реализации таких проектов обычно набирают из самоуверенных “варягов”, которые уже делали нечто подобное в других местах, но являются новичками в вашей организации. При этом их поощряют ломать и разрушать правила, которые остаются обязательными для всех остальных. Легко видеть, что в результате формируется культура разделения на «мы» и «они», которая препятствует передаче знаний и навыков».
“ဒီယဉ်ကျေးမှုပြဿနာက DevOps ကို စကေးချရခက်တဲ့ အကြောင်းရင်းတစ်ခုပါပဲ။ DevOps အဖွဲ့များသည် လျင်မြန်စွာတိုးတက်နေသော IT-ပထမကုမ္ပဏီများ၏ပုံမှန်နည်းပညာဆိုင်ရာစိန်ခေါ်မှုများကိုရင်ဆိုင်နေကြရသည်” ဟု Scalyr ၏တည်ထောင်သူနှင့်ဥက္ကဌ Steve Newman မှပြောကြားခဲ့သည်။
“ခေတ်သစ်ကမ္ဘာမှာ ဝန်ဆောင်မှုတွေ လိုအပ်တာနဲ့တပြိုင်နက် ပြောင်းလဲနေပါတယ်။ အင်္ဂါရပ်အသစ်များကို အဆက်မပြတ်အကောင်အထည်ဖော်ရန်နှင့် အကောင်အထည်ဖော်ခြင်းသည် ကောင်းမွန်သော်လည်း ဤလုပ်ငန်းစဉ်ကို ညှိနှိုင်းဆောင်ရွက်ခြင်းနှင့် ပေါ်ပေါက်လာသောပြဿနာများကို ဖယ်ရှားခြင်းသည် အမှန်တကယ်ခေါင်းကိုက်ခြင်းဖြစ်သည်ဟု Steve Newman က ထပ်လောင်းပြောကြားခဲ့သည်။ - အလွန်လျင်မြန်စွာ ကြီးထွားလာသော အဖွဲ့အစည်းများတွင်၊ လုပ်ငန်းခွင်သုံးအဖွဲ့များမှ အင်ဂျင်နီယာများသည် အပြောင်းအလဲအဖြစ် မြင်နိုင်စွမ်းကို ထိန်းသိမ်းထားရန်နှင့် မှီခိုမှုအဆင့်တွင် ဖြစ်ပေါ်လာသည့် သက်ရောက်မှုများကို ထိန်းသိမ်းရန် ရုန်းကန်နေရပါသည်။ ထို့အပြင်၊ အင်ဂျင်နီယာများသည် ဤအခွင့်အရေးကို ဆုံးရှုံးရသောအခါတွင် မပျော်ရွှင်ကြဘဲ ရလဒ်အနေဖြင့် ဖြစ်ပေါ်လာသော ပြဿနာများ၏ အနှစ်သာရကို နားလည်ရန် ပိုမိုခက်ခဲလာပါသည်။"
အထက်တွင်ဖော်ပြထားသော အဆိုပါစိန်ခေါ်မှုများကို မည်သို့ကျော်လွှားပြီး အဖွဲ့အစည်းကြီးတစ်ခုတွင် DevOps ကို အစုလိုက်အပြုံလိုက်လက်ခံခြင်းသို့ ပြောင်းရွှေ့မည်နည်း။ သင်၏ အဆုံးစွန်ပန်းတိုင်မှာ သင်၏ဆော့ဖ်ဝဲလ်ဖွံ့ဖြိုးတိုးတက်ရေးစက်ဝန်းနှင့် လုပ်ငန်းလုပ်ငန်းစဉ်များကို အရှိန်မြှင့်ရန်ပင်လျှင် စိတ်ရှည်သည်းခံရန် ကျွမ်းကျင်သူများက တိုက်တွန်းပါသည်။
1. ယဉ်ကျေးမှုပြောင်းလဲမှုသည် အချိန်ယူရမည်ကို သတိရပါ။
Джейн Гролл (Jayne Groll), исполнительный директор Института DevOps: "ကျွန်ုပ်၏အမြင်အရ၊ DevOps ၏ချဲ့ထွင်မှုသည် လျင်မြန်သောဖွံ့ဖြိုးတိုးတက်မှုကဲ့သို့ တိုးမြင့်ပြီး ထပ်ခါထပ်ခါဖြစ်သင့်သည် (ယဉ်ကျေးမှုအပေါ် ထပ်တူထပ်မျှထိထိမိမိ) ဖြစ်သင့်သည်။ Agile နှင့် DevOps သည် အသင်းငယ်များကို အလေးထားသည်။ ဒါပေမယ့် ဒီအဖွဲ့တွေဟာ အရေအတွက်နဲ့ ပေါင်းစည်းမှု တိုးပွားလာတာနဲ့အမျှ ကျွန်ုပ်တို့ဟာ အလုပ်နည်းလမ်းအသစ်တွေကို လက်ခံကျင့်သုံးတဲ့ လူတွေပိုများလာကာ ရလဒ်အနေနဲ့ ကြီးမားတဲ့ ယဉ်ကျေးမှုအသွင်ကူးပြောင်းမှုတွေ ဖြစ်လာပါတယ်။”
2. အလုံအလောက်အချိန်ယူစီစဉ်ပြီး ပလက်ဖောင်းတစ်ခုရွေးချယ်ပါ။
Эран Кинсбрюнер (Eran Kinsbruner), ведущий технический евангелист компании Perfecto: "လုပ်ငန်းခွင်ချဲ့ထွင်ရန်အတွက် DevOps အဖွဲ့များသည် ရိုးရာလုပ်ငန်းစဉ်များ၊ ကိရိယာများနှင့် ကျွမ်းကျင်မှုများကို ပေါင်းစပ်ရန် ဦးစွာလေ့လာသင်ယူကြပြီး၊ ထို့နောက် DevOps အဆင့်တစ်ခုချင်းစီကို တည်ငြိမ်အောင် ဖြည်းဖြည်းချင်း ပြုစုပျိုးထောင်ပေးရပါမည်။ ၎င်းအားလုံးသည် သုံးစွဲသူဇာတ်လမ်းများနှင့် တန်ဖိုးစီးကြောင်းများကို ဂရုတစိုက်စီစဉ်ခြင်းဖြင့် စတင်ပြီး၊ ၎င်းနောက်တွင် ပင်စည်အခြေပြု ဖွံ့ဖြိုးတိုးတက်မှု သို့မဟုတ် ကုဒ်ခွဲခြင်းနှင့် ပေါင်းစည်းခြင်းအတွက် အသင့်တော်ဆုံး အခြားနည်းလမ်းများကို အသုံးပြု၍ ဆော့ဖ်ဝဲလ်ရေးသားခြင်းနှင့် ဗားရှင်းထိန်းချုပ်မှုတို့ ပါဝင်သည်။”
“ထို့နောက် ပေါင်းစပ်ခြင်းနှင့် စမ်းသပ်ခြင်းအဆင့်သို့ ရောက်ရှိလာသည်၊၊ အလိုအလျောက်စနစ်အတွက် အတိုင်းအတာတစ်ခုအထိ လိုအပ်ပြီးဖြစ်သည်။ ဤနေရာတွင် DevOps အဖွဲ့များသည် ၎င်းတို့၏ကျွမ်းကျင်မှုအဆင့်နှင့် ပရောဂျက်၏အဆုံးပန်းတိုင်များနှင့်ကိုက်ညီသော မှန်ကန်သောပလက်ဖောင်းကို ရွေးချယ်ရန် အရေးကြီးပါသည်။
Следующая фаза – развертывание в производственной среде, и оно должно быть полностью автоматизировано с использованием инструментов оркестрации и контейнеров. При этом важно иметь виртуализированные среды на всех этапах DevOps (симулятор производственной среды, среда контроля качества и, собственно, производственная среда) и всегда использовать для тестов только самые последние данные, чтобы получать актуальные выводы. Аналитика должны быть умной и способной обрабатывать большие данные с быстрой и действенной обратной связью».
3. Избавьте ответственности от привкуса вины
Gordon Haff၊ RedHat Evangelist “စမ်းသပ်မှုများကို ခွင့်ပြုပြီး အားပေးသည့် စနစ်နှင့် လေထုကို ဖန်တီးခြင်းသည် လျင်မြန်သော ဆော့ဖ်ဝဲလ် ဖွံ့ဖြိုးတိုးတက်မှုတွင် အောင်မြင်သော ကျရှုံးမှုများဟု လူသိများသော အရာကို ရရှိစေပါသည်။ ဒါက ကျရှုံးမှုအတွက် တခြားဘယ်သူမှ တာဝန်ရှိတယ်လို့ မဆိုလိုပါဘူး။ အမှန်မှာ၊ မည်သူ့တွင် တာဝန်ရှိသည်ကို ခွဲခြားသိမြင်ခြင်းသည် ပို၍လွယ်ကူလာသည်၊ “တာဝန်ယူခြင်း” သည် “မတော်တဆမှုဖြစ်စေသည်” ဟု မဆိုလိုတော့ပါ။ ဆိုလိုတာက တာဝန်ယူမှုရဲ့ အနှစ်သာရက အရည်အသွေးနဲ့ ပြောင်းလဲတယ်။ အချက်လေးချက်သည် အရေးကြီးလာသည်- အနှောင့်အယှက်၊ ချဉ်းကပ်မှု၊ ထုတ်လုပ်မှု လုပ်ငန်းစဉ်များနှင့် မက်လုံးများ။" (Gordon Huff ၏ "DevOps သင်ခန်းစာများ- ကျန်းမာသော စမ်းသပ်မှု 4 ကဏ္ဍ" တွင် ဤအချက်များအကြောင်း ပိုမိုဖတ်ရှုနိုင်ပါသည်။)
4. Расчищайте путь вперед
အတိုင်ပင်ခံကုမ္ပဏီ North Highland မှ မန်နေးဂျင်းဒါရိုက်တာနှင့် ဒစ်ဂျစ်တယ်အကြီးအကဲ Ben Grinnell "အတိုင်းအတာတစ်ခုအောင်မြင်ရန်၊ ရှေ့ဆောင်ပရောဂျက်များနှင့်အတူ "လမ်းကြောင်းရှင်းလင်းခြင်း" အစီအစဉ်ကို စတင်ရန် အကြံပြုပါသည်။ ဒီပရိုဂရမ်ရဲ့ ရည်ရွယ်ချက်ကတော့ DevOps ရဲ့ ရှေ့ဆောင်တွေက စွန့်ပစ်ထားတဲ့ အမှိုက်တွေကို ရှင်းပစ်ဖို့ဖြစ်ပြီး ခေတ်မမီတော့တဲ့ စည်းမျဉ်းစည်းကမ်းတွေနဲ့ ဒီလိုအရာတွေကို ရှင်းရှင်းလင်းလင်းဖြစ်အောင် ရှေ့ဆက်သွားဖို့ပါပဲ။”
«Дайте людям организационную поддержку и придайте импульс через коммуникацию, которая выходит далеко за рамки группы первопроходцев, широко празднуя успехи новых методов работы. Тренируйте людей, которые задействованы в следующей волне проектов DevOps и нервничают из-за того, что используют DevOps впервые. И помните, что эти люди сильно отличаются от первопроходцев».
5. Сделайте инструменты более демократичными
Стив Ньюман (Steve Newman), основатель и председатель правления компании Scalyr: «Инструменты не надо прятать от людей, и они должны быть относительно просты в освоении для любого, кто готов потратить на это время. Если возможность запрашивать логи предоставлена только трем людям, «сертифицированным» для работы с каким-то инструментом, у вас всегда будет максимум три человека, способных разобраться с соответствующей проблемой, даже если у вас очень большая вычислительная среда. Иначе говоря, здесь возникает узкое место, которое может привести к серьезным (для бизнеса) последствиям».
6. အဖွဲ့လိုက်လုပ်ဆောင်မှုအတွက် စံပြအခြေအနေများကို ဖန်တီးပါ။
ITV ၏ Common Platform အကြီးအကဲ Tom Clark «Вы можете сделать что угодно, но не все сразу. Поэтому ставьте большие цели, начинайте с малого и двигайтесь вперед быстрыми итерациями. Со временем вы заработаете репутацию команды, у которой все получается, поэтому другие тоже захотят использовать ваши методы. И не гонитесь за выстраиванием высокоэффективной команды. Вместо этого обеспечьте людям идеальные условия для работы и эффективность придет сама собой».
7. Conway's Law နှင့် Kanban ဘုတ်များအကြောင်း မမေ့ပါနှင့်
CollabNetVersionOne မှ Software Delivery နှင့် DevOps Strategy ၏ ဒါရိုက်တာ Logan Daigle “ကွန်ဝေးဥပဒေရဲ့ အကျိုးဆက်တွေကို နားလည်ဖို့ အရေးကြီးတယ်။ ကျွန်ုပ်၏ ပျော့ပျောင်းသောစာပိုဒ်တွင်၊ ကျွန်ုပ်တို့ဖန်တီးသည့် ထုတ်ကုန်များနှင့် DevOps အပါအဝင် ကျွန်ုပ်တို့အသုံးပြုသည့် လုပ်ငန်းစဉ်များသည် ကျွန်ုပ်တို့၏အဖွဲ့အစည်းကဲ့သို့ပင် ဖွဲ့စည်းတည်ဆောက်ထားသည်ဟု ဤဥပဒေတွင် ဖော်ပြထားသည်။"
“အဖွဲ့အစည်းတစ်ခုတွင် silos အများအပြားရှိပြီး၊ ဆော့ဖ်ဝဲလ်စီစဉ်ခြင်း၊ တည်ဆောက်ခြင်းနှင့် ထုတ်လွှတ်ခြင်းများတွင် အကြိမ်များစွာ လက်ဖြင့်ထိန်းချုပ်ခြင်းသည် အတိုင်းအတာပမာဏသည် သုည သို့မဟုတ် ခဏတာဖြစ်လိမ့်မည်။ အဖွဲ့အစည်းတစ်ခုသည် စျေးကွက်အာရုံစူးစိုက်မှုဖြင့် ငွေကြေးထောက်ပံ့ထားသော ထုတ်ကုန်များအနီးတွင် ဘက်စုံလုပ်ငန်းသုံးအဖွဲ့များကို တည်ဆောက်ပါက၊ အောင်မြင်နိုင်ခြေများ သိသိသာသာ တိုးလာပါသည်။"
"စကေးချဲ့ခြင်း၏နောက်ထပ်အရေးကြီးသောအချက်မှာ Kanban ဘုတ်များပေါ်တွင် လုပ်ဆောင်နေသောအလုပ်များ (WIP၊ workinprogress) ကိုပြသရန်ဖြစ်သည်။ အဖွဲ့အစည်းတစ်ခုတွင် ဤအရာများကို လူအများမြင်နိုင်သည့်နေရာတစ်ခုရှိသောအခါ၊ ၎င်းသည် အတိုင်းအတာချဲ့ထွင်ခြင်းအပေါ် ကောင်းသောအကျိုးသက်ရောက်မှုရှိသော ပူးပေါင်းဆောင်ရွက်မှုကို များစွာအားပေးပါသည်။"
8. အမာရွတ်ဟောင်းများကို ရှာဖွေပါ။
Manuel Pais၊ DevOps အတိုင်ပင်ခံနှင့် Team Topologies ပူးတွဲရေးသားသူ- “DevOps ကျင့်စဉ်များကို Dev နှင့် Ops ကိုယ်တိုင်ထက် ကျော်လွန်ပြီး ၎င်းတို့ကို အခြားလုပ်ဆောင်ချက်များတွင် အသုံးချရန် ကြိုးစားခြင်းသည် အကောင်းဆုံးသော ချဉ်းကပ်မှုတစ်ခု မဟုတ်ပေ။ ၎င်းသည် သေချာပေါက် သက်ရောက်မှုအချို့ရှိလိမ့်မည် (ဥပမာ၊ အလိုအလျောက် manual ထိန်းချုပ်ခြင်းဖြင့်)၊ သို့သော် ကျွန်ုပ်တို့သည် ပေးပို့မှုနှင့် တုံ့ပြန်မှုလုပ်ငန်းစဉ်များကို နားလည်ခြင်းဖြင့် စတင်ပါက ပိုမိုအောင်မြင်နိုင်သည်။”
“အဖွဲ့အစည်းတစ်ခု၏ IT စနစ်တွင် ဒဏ်ရာဟောင်းများ ရှိခဲ့ပါက- အတိတ်က ဖြစ်ရပ်များကြောင့် အကောင်အထည်ဖော်ခဲ့သော လုပ်ထုံးလုပ်နည်းများနှင့် စီမံခန့်ခွဲမှု ယန္တရားများ (ထုတ်ကုန်များ၊ နည်းပညာများ သို့မဟုတ် လုပ်ငန်းစဉ်များ အပြောင်းအလဲကြောင့်) ဆက်စပ်မှု ဆုံးရှုံးသွားပါက ၎င်းတို့ကို သေချာပေါက် ဖယ်ရှားရန် လိုအပ်ပါသည်။ သို့မဟုတ် ထိရောက်မှုမရှိသော သို့မဟုတ် မလိုအပ်သော လုပ်ငန်းစဉ်များကို အလိုအလျောက်လုပ်ဆောင်ခြင်းထက် ချောမွေ့စေပါသည်။"
9. Не плодите варианты DevOps
Энтони Эдвардс (Antony Edwards), директор по производству компании Eggplant: “DevOps သည် အလွန်မရေရာသော အသုံးအနှုန်းဖြစ်ပြီး အသင်းတိုင်းသည် ၎င်း၏ကိုယ်ပိုင် DevOps ဗားရှင်းဖြင့် အဆုံးသတ်ပါသည်။ အဖွဲ့အစည်းတစ်ခုတွင် DevOps အမျိုးပေါင်း 20 သည် ရုတ်တရက် အတူတကွ ကောင်းမွန်စွာ မလိုက်လျောညီထွေဖြစ်သောအခါတွင် ပိုဆိုးသည်မဟုတ်။ ဖွံ့ဖြိုးတိုးတက်မှုအဖွဲ့ သုံးခုမှ တစ်ခုစီသည် ဖွံ့ဖြိုးတိုးတက်မှုနှင့် ထုတ်ကုန်စီမံခန့်ခွဲမှုကြားတွင် ၎င်းတို့၏ကိုယ်ပိုင်၊ အထူးဆက်သွယ်မှု ရှိရန် မဖြစ်နိုင်ပေ။ ထုတ်လုပ်မှု simulator သို့ လွှဲပြောင်းသည့်အခါ ထုတ်ကုန်များသည် တုံ့ပြန်ချက်ကို ကိုင်တွယ်ရန်အတွက် ၎င်းတို့၏ ကိုယ်ပိုင်သီးသန့် မျှော်လင့်ချက်များ ရှိမနေသင့်ပါ။ မဟုတ်ပါက သင်သည် DevOps ကို ဘယ်တော့မှ စကေးချနိုင်မည်မဟုတ်ပါ။"
10. DevOps ၏ လုပ်ငန်းတန်ဖိုးကို ဟောပြောပါ။
Стив Ньюман (Steve Newman), основатель и председатель правления компании Scalyr: "DevOps ၏တန်ဖိုးကိုအသိအမှတ်ပြုရန်အလုပ်။ သင်လုပ်ဆောင်သည့်အရာ၏ အကျိုးကျေးဇူးများအကြောင်း သင်ယူပြီး လွတ်လပ်စွာပြောဆိုပါ။ DevOps သည် မယုံနိုင်လောက်အောင် အချိန်နှင့်ငွေကို ချွေတာနိုင်သည် (စဉ်းစားကြည့်ပါ- စက်ရပ်ချိန်နည်းသည်၊ ပြန်လည်ရယူရန် အချိန်တိုတောင်းသည်)၊ DevOps အဖွဲ့များသည် လုပ်ငန်းအောင်မြင်ရန်အတွက် ဤအစပျိုးမှုများ၏ အရေးပါမှုကို အလေးပေး (ဟောပြောပြီး) မပြတ်အလေးပေးရမည်ဖြစ်သည်။ ဤနည်းဖြင့် သင်သည် ချိတ်ဆက်သူများအဝန်းအဝိုင်းကို ချဲ့ထွင်နိုင်ပြီး အဖွဲ့အစည်းအတွင်းရှိ DevOps ၏ သြဇာလွှမ်းမိုးမှုကို တိုးမြှင့်နိုင်သည်။"
ဆုငှေ
အပေါ် 13 сентября прилетит наш собственный DevOps – да, у Red Hat, как у производителя программного обеспечения, есть собственные DevOps команды и практики.
Наш инженер Марк Биргер, который занимается разработкой служб внутренней автоматизации для других групп по всей организации, на чистом русском языке расскажет собственную историю – как DevOps команда Red Hat мигрировала приложения из виртуальных сред Hat Virtualization, управляемых Ansible в полноценный контейнерный формат на платформе OpenShift.
ဒါပေမယ့် ဒါအကုန်တော့ မဟုတ်ပါဘူး။
အဖွဲ့အစည်းများသည် ကွန်တိန်နာများသို့ အလုပ်ချိန်များကို ရွှေ့လိုက်သည်နှင့်၊ သမားရိုးကျ အပလီကေးရှင်း စောင့်ကြည့်ရေးနည်းလမ်းများ အလုပ်မဖြစ်နိုင်ပါ။ ဒုတိယ ဟောပြောချက်တွင် ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ သစ်ခုတ်ခြင်းနည်းလမ်းကို ပြောင်းလဲခြင်းအတွက် ကျွန်ုပ်တို့၏ စေ့ဆော်မှုကို ရှင်းပြပြီး ကျွန်ုပ်တို့အား ခေတ်မီသစ်ခုတ်ခြင်းနှင့် စောင့်ကြည့်ခြင်းနည်းလမ်းများဆီသို့ ဦးတည်စေသည့် လမ်းကြောင်း၏ ဆက်လက်ဖြစ်ပေါ်မှုကို ပြသပါမည်။
source: www.habr.com