د DevOps تعریف خورا پیچلی دی ، نو موږ باید د دې په اړه بحث هر ځل بیا پیل کړو. یوازې په هابري کې د دې موضوع په اړه زرګونه خپرونې شتون لري. مګر که تاسو دا لوستل کوئ، تاسو شاید پوه شئ چې DevOps څه شی دی. ځکه چې زه نه یم. سلام زما نوم دی الکساندر تیتوف (@)، او موږ به یوازې د DevOps په اړه وغږیږو او زه به خپله تجربه شریک کړم.
زه د اوږدې مودې لپاره فکر کوم چې څنګه زما کیسه ګټوره کړي، نو دلته به ډیری پوښتنې وي - هغه چې زه یې له ځانه پوښتنه کوم او هغه چې زه زموږ د شرکت پیرودونکو څخه پوښتنه کوم. د دې پوښتنو په ځوابولو سره، پوهه ښه کیږي. زه به تاسو ته ووایم چې ولې زما له نظره DevOps ته اړتیا ده ، دا څه دي ، بیا زما له نظره ، او څنګه پوهیدم چې تاسو زما له نظره بیا د DevOps په لور روان یاست. وروستی ټکی به د پوښتنو له لارې وي. د ځان لپاره د دوی په ځواب ورکولو سره، تاسو کولی شئ پوه شئ چې آیا ستاسو شرکت د DevOps په لور روان دی یا ایا په یو ډول ستونزې شتون لري.
یو وخت زه د ادغام او استملاک په څپو کې سپاره وم. لومړی، ما د کیک په نوم د کوچني پیل لپاره کار وکړ، بیا دا د سکایپ په نوم د یو څه لوی شرکت لخوا اخیستل شوی و، چې بیا د مایکروسافټ په نوم یو څه لوی شرکت لخوا اخیستل شوی و. په دې شیبه کې، ما لیدل پیل کړل چې څنګه د DevOps مفکوره په مختلفو اندازو شرکتونو کې بدلیږي. له هغې وروسته، زه د بازار له نظره DevOps لیدلو ته لیواله شوم، او ما او زما همکارانو د ایکسپریس 42 شرکت تاسیس کړ. د 6 کلونو راهیسې موږ د بازار د څپو سره حرکت کوو.
د نورو شیانو په مینځ کې ، زه د DevOps مسکو ټولنې تنظیم کونکو څخه یم او د DevOps-Days 2017 تنظیم کونکی یم ، مګر ما 2018 تنظیم نه کړ. ایکسپریس 42 د ډیری شرکتونو سره کار کوي. موږ هلته DevOps وده کوو، وګورئ چې دا څنګه پیښیږي، پایلې راوباسئ، تحلیل کړئ، هرچا ته زموږ پایلې ووایاست، او خلک د DevOps په کړنو کې وروزل. په عموم کې، موږ په دې برخه کې زموږ د تجربې او مهارتونو د زیاتولو لپاره خپله هڅه کوو.
ولې DevOps
لومړۍ پوښتنه چې هرڅوک ځوروي او تل دا دی - ولې؟ ډیری خلک فکر کوي چې DevOps یوازې اتومات یا ورته شی دی چې هر شرکت دمخه درلود.
- موږ دوامداره ادغام درلود - پدې معنی چې موږ دمخه DevOps درلود ، او ولې دې ټولو توکو ته اړتیا ده؟ دوی په بهر کې ساتیري کوي، مګر دوی موږ د کار کولو مخه نیسي!
د ټولنې او میتودولوژي د 9 کلونو په اوږدو کې د پرمختګ په جریان کې ، دا لا دمخه روښانه شوې چې دا لاهم د بازار موندنې چمک نه دی ، مګر دا لاهم په بشپړ ډول روښانه نده چې ولې ورته اړتیا ده. د هرې وسیلې او پروسې په څیر، DevOps ځانګړي اهداف لري چې په پای کې یې ترلاسه کوي.
دا ټول د دې حقیقت له امله دي چې نړۍ بدلیږي. هغه د تصدۍ له طریقې څخه لیرې کیږي، کله چې شرکتونه په مستقیم ډول د خوب په لور حرکت کوي، لکه څنګه چې زموږ د سینټ پیټرزبورګ کلاسیک سندرې سندرې ویلي، د یوې ځانګړې ستراتیژۍ سره سم د A څخه نقطې B پورې، د دې لپاره یو ځانګړي جوړښت سره جوړ شوی.
په اصل کې، په IT کې هرڅه باید د دې طریقې سره سم جوړ شي. دلته IT په ځانګړي ډول د پروسې اتومات کولو لپاره کارول کیږي.
اتوماتیک اکثرا بدلون نه کوي، ځکه چې کله یو شرکت په ښه توګه راټیټیږي، د بدلون لپاره څه شتون لري؟ دا کار کوي - لاس مه وهئ. اوس په نړۍ کې تګلارې بدلیږي، او یو چې د Agile په نوم یادیږي وړاندیز کوي چې پای ټکی B سمدستي نه لیدل کیږي.
کله چې یو شرکت د بازار څخه تیریږي، د پیرودونکي سره کار کوي، دا په دوامداره توګه بازار لټوي او د پای ټکی B بدلوي. سربیره پردې، هرڅومره چې شرکت خپل سمت بدلوي، په پایله کې ډیر بریالي کیږي، ځکه چې ډیر بازار غوره کوي. طاقونه
ستراتیژي د یو زړه پورې شرکت لخوا ښودل کیږي چې ما پدې وروستیو کې زده کړل. One Box Shave په یوه بکس کې د استرا او د شییو لوازمو لپاره د ګډون رسولو خدمت دی. دوی پوهیږي چې څنګه د مختلف پیرودونکو لپاره خپل "بکس" تنظیم کړي. دا د یو ځانګړي سافټویر لخوا ترسره کیږي ، کوم چې بیا د کوریا فابریکې ته امر لیږي چې توکي تولیدوي.
دا محصول د یونیلیور لخوا په 1 ملیارد ډالرو اخیستل شوی. دا اوس د ګیلټ سره سیالي کوي او په امریکایی بازار کې یې د مصرف کونکو پام وړ برخه اخیستې ده. یو بکس شیف وايي:
- 4 تیغونه؟ ایا تاسو جدي یاست؟ تاسو ولې دې ته اړتیا لرئ - دا د ویښتو کیفیت ښه نه کوي. یو ځانګړی غوره شوی کریم ، بوی او د لوړ کیفیت استرا دوه بلیډونه د دې احمق 4 جیلیټ بلیډونو په پرتله ډیرې ستونزې حل کوي! ایا موږ به ژر 10 ته ورسیږو؟
دا څنګه نړۍ بدلیږي. یونیلیور ادعا کوي چې دوی یو ښه معلوماتي سیسټم لري چې تاسو ته اجازه درکوي دا کار وکړي. په پای کې دا د مفهوم په څیر ښکاري بازار ته وخت، چې هیڅوک یې دمخه خبرې نه دي کړي.
د وخت څخه مارکیټ ټکی دا ندی چې موږ څو ځله ځای په ځای کوو. تاسو ډیری وختونه ځای په ځای کولی شئ، مګر د خوشې کولو دوره به اوږده وي. که چیرې د دریو میاشتو خوشې کولو دورې په یو بل باندې تکیه شوي وي، د یوې اونۍ لخوا یې لیږدول، دا معلومه شوه چې شرکت په اونۍ کې یو ځل ګمارل کیږي. او د نظر څخه تر وروستي پلي کیدو پورې دا 3 میاشتې وخت نیسي.
بازار ته وخت د نظر څخه تر وروستي پلي کیدو پورې د وخت کمولو په اړه دی.
په دې حالت کې، سافټویر د بازار سره اړیکه لري. دا څنګه د One Box Shave ویب پاڼه د پیرودونکي سره اړیکه لري. دوی پلورونکي نلري - یوازې یوه ویب پاڼه چیرې چې لیدونکي کلیک کوي او هیلې پریږدي. په دې اساس، یو څه باید په دوامداره توګه په سایټ کې پوسټ شي او د هیلو سره سم تازه شي. د مثال په توګه، په سویلي کوریا کې دوی د روسیې په پرتله په مختلف ډول خړوب کوي، او دوی د انارو بوی نه خوښوي، مګر د مثال په توګه، د گاجر او وینیلا.
څنګه چې دا اړینه ده چې د سایټ مینځپانګه ژر تر ژره بدله کړئ، د سافټویر پراختیا خورا بدلون کوي. د سافټویر له لارې موږ باید معلومه کړو چې پیرودونکي څه غواړي. مخکې، موږ دا د ځینو ګردي لارو له لارې زده کړل، د بیلګې په توګه، د سوداګرۍ مدیریت له لارې. بیا موږ دا ډیزاین کړ، اړتیاوې یې د معلوماتي ټکنالوجۍ سیسټم ته واچولې، او هرڅه ښه وو. اوس دا توپیر لري - سافټویر د هر چا لخوا ډیزاین شوی چې په پروسه کې دخیل وي، د انجنیرانو په شمول، ځکه چې دوی د تخنیکي مشخصاتو له لارې زده کوي چې بازار څنګه کار کوي او د سوداګرۍ سره خپل بصیرت شریکوي.
د مثال په توګه، په کیک کې موږ ناڅاپه پوه شو چې خلکو واقعیا سرور ته د اړیکو لیست اپلوډ کول خوښ کړل، او دوی موږ ته یو غوښتنلیک راکړ. په پیل کې موږ د دې په اړه فکر نه کاوه. په یوه کلاسیک شرکت کې، هرڅوک به پریکړه وکړي چې دا یوه بګ وه، ځکه چې ځانګړتیا دا نه ویل چې دا باید ښه کار وکړي او په عمومي توګه په زنګون کې پلي کیږي، دوی به دا فیچر بند کړ او ویې ویل: "هیڅوک دې ته اړتیا نلري، ترټولو مهمه خبره دا ده چې اصلي فعالیت کار کوي. او د ټیکنالوژۍ شرکت دې ته د یو فرصت په توګه ګوري او د دې سره سم سافټویر بدلول پیل کوي.
په 1968 کې، یو لیدونکي سړی، میلون کونوی، لاندې نظریه جوړه کړه.
هغه سازمان چې سیسټم رامینځته کوي د ډیزاین لخوا محدود دی چې د دې سازمان ارتباطي جوړښت نقل کوي.
په ډیر تفصیل سره، د مختلف ډول سیسټمونو تولید لپاره، تاسو باید د مختلف ډول شرکت کې د ارتباط جوړښت هم ولرئ. که ستاسو د مخابراتو جوړښت لوړ پوړیز وي، نو دا به تاسو ته اجازه ورنکړي چې داسې سیسټمونه رامینځته کړي چې کولی شي د بازار څخه تر بازار پورې خورا لوړ شاخص چمتو کړي.
لوستل کولای شي . دا د DevOps کلتور یا فلسفې د پوهیدو لپاره مهم دی ځکه چې یوازینی شی چې په بنسټیز ډول په DevOps کې بدلون راولي د ټیمونو ترمنځ د اړیکو جوړښت دی.
د پروسې له نظره، د DevOps څخه مخکې، ټولې مرحلې: تحلیلونه، پراختیا، ازموینه، عملیات، خطي وو.
د DevOps په حالت کې، دا ټولې پروسې په ورته وخت کې واقع کیږي.
بازار ته وخت یوازینۍ لار ده چې دا ترسره کیدی شي. د هغو خلکو لپاره چې په زاړه پروسې کې کار کوي، دا یو څه کاسمیک ښکاري، او په عمومي توګه داسې ښکاري.
نو ولې تاسو DevOps ته اړتیا لرئ؟
د ډیجیټل محصول پراختیا لپاره. که ستاسو شرکت ډیجیټل محصول نلري، DevOps ته اړتیا نشته - دا خورا مهم دی.
DevOps د ترتیب شوي سافټویر تولید سرعت محدودیتونه لرې کوي. پدې کې ټولې پروسې په ورته وخت کې پیښیږي.
مشکل زیاتیږي. کله چې د DevOps تبلیغ کونکي تاسو ته ووایی چې دا به ستاسو لپاره د سافټویر خوشې کول اسانه کړي ، دا بې معنی ده.
د DevOps سره، شیان به یوازې نور پیچلي شي.
په ایویټو سټینډ کې کنفرانس کې ، تاسو کولی شئ وګورئ چې دا د ډاکر کانټینر ځای په ځای کول څه وو - یو غیر واقعیتي کار. پیچلتیا ممنوع کیږي؛ تاسو باید په ورته وخت کې ډیری بالونه وخورئ.
DevOps په بشپړ ډول په شرکت کې پروسه او تنظیم بدلوي - په دقیق ډول ، دا DevOps ندي چې بدلون کوي ، مګر ډیجیټل محصول. DevOps ته د راتلو لپاره ، تاسو لاهم اړتیا لرئ دا پروسه په بشپړ ډول بدله کړئ.
د متخصص لپاره پوښتنې
ته څه لرې؟ هغه پوښتنې چې تاسو کولی شئ له ځانه وپوښتئ کله چې په شرکت کې کار کوئ او د متخصص په توګه وده کوئ.
ایا تاسو د ډیجیټل محصول رامینځته کولو لپاره تګلاره لرئ؟ که شتون ولري، دا لا دمخه ښه دی. دا پدې مانا ده چې ستاسو شرکت د DevOps په لور روان دی.
ایا ستاسو شرکت دمخه ډیجیټل محصول رامینځته کوي؟ د دې معنی دا ده چې تاسو کولی شئ بله کچه لوړه کړئ او کارونه په زړه پورې کړئ - بیا د DevOps له لید څخه. زه یوازې له دې نظره خبرې کوم.
ایا ستاسو شرکت د ډیجیټل محصول ځای کې د بازار له مشرانو څخه دی؟ Spotify، Yandex، Uber هغه شرکتونه دي چې اوس د تخنیکي پرمختګ په سر کې دي.
له ځانه دا پوښتنې وپوښتئ، او که ټول ځوابونه نه وي، نو شاید تاسو باید پدې شرکت کې DevOps ونه کړئ. که د DevOps موضوع واقعیا ستاسو لپاره په زړه پوري وي ، شاید ... تاسو باید بل شرکت ته لاړشئ؟ که ستاسو شرکت غواړي DevOps ته لاړ شي، مګر تاسو ټولو پوښتنو ته "نه" ځواب ورکړ، نو دا د هغه ښکلي ګینډ په څیر دی چې هیڅکله به بدل نشي.
سازمان
لکه څنګه چې ما وویل، د کانوی د قانون له مخې، د شرکت تنظیم بدلیږي. زه به د هغه څه سره پیل وکړم چې DevOps د سازماني لید څخه د شرکت دننه د ننوتلو مخه نیسي.
د "کوهیانو" ستونزه
د انګلیسي کلمه "Silo" دلته په روسیه کې د "ښه" په توګه ژباړل شوې. د دې ستونزې نقطه دا ده د ټیمونو ترمنځ د معلوماتو تبادله شتون نلري. هر ټیم خپل تخصص ته ژور کیندنه کوي، پرته له دې چې د تګ کولو لپاره یو عام نقشه جوړه کړي.
په ځینو لارو کې دا ما د یو چا یادونه کوي چې یوازې مسکو ته رسیدلی او لاهم نه پوهیږي چې څنګه د میټرو نقشه پرمخ بوځي. مسکوویټونه معمولا خپله سیمه ښه پیژني، او په ټوله مسکو کې دوی کولی شي د میټرو نقشې په کارولو سره حرکت وکړي. کله چې تاسو د لومړي ځل لپاره مسکو ته راشئ، تاسو دا مهارت نلرئ، او تاسو یوازې بې هوښه یاست.
DevOps وړاندیز کوي چې د ګډوډۍ له دې شیبې څخه تیر شي او ټولې څانګې په ګډه کار کوي ترڅو د ګډ متقابل نقشه رامینځته کړي.
دوه عوامل د دې مخه نیسي.
د شرکت مدیریت سیسټم پایله. دا په جلا جلا "څاه" کې جوړ شوی دی. د مثال په توګه، په شرکتونو کې ځینې KPIs شتون لري چې د دې سیسټم ملاتړ کوي. له بلې خوا، د هغه چا مغز چې د خپل تخصص له حدودو څخه بهر تلل او د ټول سیسټم حرکت کول ستونزمن وي په لاره کې راځي. دا یوازې نا آرامه ده. تصور وکړئ چې تاسو د بنکاک په هوایی ډګر کې یاست - تاسو به ژر تر ژره خپله لاره ونه مومئ. DevOps نیویګیټ کول هم ستونزمن دي، او له همدې امله خلک وايي چې تاسو اړتیا لرئ هلته د رسیدو لپاره لارښود ومومئ.
مګر ترټولو مهمه خبره دا ده چې د یو انجینر لپاره د "څاګانو" ستونزه چې د DevOps په روحیه اخته وي، فولر او یو شمیر نور کتابونه یې لوستلي دي، په حقیقت کې څرګند شوي دي. "څاه" تاسو ته اجازه نه ورکوي چې "څرګند" شیان ترسره کړي. موږ ډیری وختونه د DevOps مسکو وروسته سره یوځای کیږو، یو بل سره خبرې کوو، او خلک شکایت کوي:
- موږ یوازې غوښتل چې CI پیل کړو، مګر دا معلومه شوه چې مدیریت ورته اړتیا نلري.
دا دقیقا پیښیږي ځکه چې CI и د تحویلي دوامداره پروسه د ډیری ازموینو په سرحد کې دي. په ساده ډول پرته له دې چې په سازماني کچه د "څاګانو" ستونزې له مینځه ویسي، تاسو به نشئ کولی مخ په وړاندې لاړ شئ، مهمه نده چې تاسو څه وکړئ او مهمه نده چې دا څومره غمجن وي.
په شرکت کې په پروسه کې هر ګډون کوونکی: بیک اینڈ او فرنټ اینډ پراختیا کونکي، ازموینه، DBA، عملیات، شبکه، په خپل لوري کې کیندل، او هیڅوک د مدیر پرته مشترکه نقشه نلري، څوک چې په یو ډول دوی څارنه کوي او د "تقسیم" په کارولو سره یې اداره کوي. او فتح" طریقه.
خلک د ځینو ستورو یا بیرغونو لپاره جنګیږي، هرڅوک خپل ماهرین کوي.
د پایلې په توګه، کله چې د دې ټولو سره د نښلولو او د ګډ پایپ لاین د جوړولو دنده رامنځته کیږي، او نور د ستورو او بیرغونو لپاره د جګړې اړتیا نشته، پوښتنه راپورته کیږي - څه باید وکړو؟ موږ باید په یو ډول توافق ته ورسیږو، مګر هیچا موږ ته دا درس نه دی راکړی چې دا څنګه په ښوونځي کې ترسره کړو. موږ ته له ښوونځي راهیسې درس ورکول کیږي: اتم ټولګي - واه! - د اووم ټولګي په پرتله! دلته هم همداسې ده.
ایا دا ستاسو په شرکت کې ورته دی؟
د دې چک کولو لپاره، تاسو کولی شئ له ځانه لاندې پوښتنې وپوښتئ.
ایا ټیمونه عام وسیلې کاروي او د دې عام وسیلو بدلونونو کې مرسته کوي؟
ټیمونه څومره وخت تنظیموي - ځینې متخصصین د یوې ټیم څخه بل ټیم ته ځي؟ دا د DevOps چاپیریال کې دی چې دا نورمال کیږي ، ځکه چې ځینې وختونه یو څوک په ساده ډول نشي پوهیدلی چې د تخصص بله برخه څه کوي. هغه بلې څانګې ته ځي، هلته د دوو اونیو لپاره کار کوي ترڅو د ځان لپاره د دې څانګې سره د تعامل او تعامل نقشه جوړه کړي.
ایا دا ممکنه ده چې د بدلون کمیټه جوړه شي او شیان بدل کړي؟ یا دا د لوړ مدیریت او لارښود قوي لاس ته اړتیا لري؟ ما پدې وروستیو کې په فیسبوک کې لیکلي چې څنګه یو لږ پیژندل شوی بانک د امرونو له لارې وسیلې پلي کوي: موږ امر لیکو ، موږ یې د یو کال لپاره پلي کوو ، او ګورو چې څه پیښیږي. دا، البته، اوږد او غمجن دی.
د مدیرانو لپاره دا څومره مهم دی چې د شرکت لاسته راوړنو په پام کې نیولو پرته شخصي لاسته راوړنې ترلاسه کړي؟
که تاسو د ځان لپاره دې پوښتنو ته ځواب ووایاست، نو دا به روښانه شي چې آیا تاسو په خپل شرکت کې دا ډول ستونزه لرئ.
د کوډ په توګه زیربنا
وروسته له دې چې دا ستونزه تیریږي، لومړی مهم تمرین، پرته له دې چې په DevOps کې نور پرمختګ ستونزمن وي د کوډ په توګه زیربنا.
ډیری وختونه، د کوډ په توګه زیربنا په لاندې ډول پیژندل کیږي:
- راځئ چې په باش کې هرڅه اتومات کړو، ځان د سکریپټونو سره پوښ کړو ترڅو مدیران لږ لاسي کار ولري!
خو دا رښتیا نه ده.
د کوډ په توګه زیربنا پدې معنی ده چې تاسو د معلوماتي ټیکنالوژۍ سیسټم تشریح کوئ چې تاسو ورسره د کوډ په بڼه کار کوئ ترڅو په دوامداره توګه د دې حالت پوه شئ.
د نورو ټیمونو سره یوځای، تاسو د کوډ په بڼه یوه نقشه جوړه کړئ چې هرڅوک پرې پوهیږي او کولی شي نیویګیټ او حرکت وکړي. دا مهمه نده چې دا څه شوي دي - شیف ، ځواب ورکوونکي ، مالګه ، یا په کوبرنیټس کې د YAML فایلونو کارول - هیڅ توپیر نلري.
په کنفرانس کې، د 2GIS یو همکار وویل چې دوی څنګه د کوبرنیټس لپاره خپل داخلي شیان جوړ کړي، کوم چې د انفرادي سیسټمونو جوړښت بیانوي. د 500 سیسټمونو تشریح کولو لپاره، دوی یو جلا وسیله ته اړتیا درلوده چې دا توضیحات تولید کړي. کله چې دا توضیحات شتون ولري، هرڅوک کولی شي د یو بل سره وګوري، بدلونونه وڅیړي، دا څنګه بدل کړي او څنګه یې ښه کړي، څه ورک دي.
موافق، د انفرادي باش سکریپټونه معمولا دا پوهه نه وړاندې کوي. په یو شرکت کې چې ما کار کاوه، حتی د "یوازې لیکلو" سکریپټ لپاره نوم هم شتون درلود - کله چې سکریپټ لیکل کیږي، مګر دا نور د لوستلو امکان نلري. زه فکر کوم چې دا تاسو ته هم پیژندل شوی.
زیربنا لکه څنګه چې کوډ دی کوډ چې د زیربنا اوسنی حالت بیانوي. ډیری محصولات، زیربناوې، او د خدماتو ټیمونه په دې کوډ کې یوځای کار کوي، او تر ټولو مهم، دوی ټول باید پوه شي چې دا کوډ واقعیا څنګه کار کوي.
کوډ د غوره کوډ طرزالعملونو سره سم ساتل کیږي: ګډ پرمختګ، د کوډ بیاکتنه، د XP-پروګرام کول، ازموینه، پلې غوښتنې، د کوډ زیربنا لپاره CI - دا ټول مناسب دي او کارول کیدی شي.
کوډ د ټولو انجینرانو لپاره یوه ګډه ژبه کیږي.
په کوډ کې د زیربنا بدلول ډیر وخت نه نیسي. هو، د زیربنا کوډ کولی شي تخنیکي پور هم ولري. معمولا ټیمونه یو نیم کال وروسته له هغې سره مخ کیږي کله چې دوی د سکریپټونو یا حتی ځواب ورکونکي په بڼه د "کوډ په توګه زیربنا" پلي کول پیل کړل، کوم چې دوی د سپیګیټي کوډ په څیر لیکي، او دوی د باش سکریپټونه هم مخلوط ته اچوي!
مهم: که تاسو تر اوسه دا توکي نه وي ازمویل، په یاد ولرئ ځواب ورکوونکی نه دی! اسناد په دقت سره ولولئ، مطالعه کړئ چې دوی یې په اړه څه لیکي.
زیربنا د کوډ په توګه د زیربنا کوډ په جلا پرتونو کې جلا کول دي.
زموږ په شرکت کې، موږ 3 بنسټیز پرتونه توپیر کوو، کوم چې خورا روښانه او ساده دي، مګر ممکن د دوی څخه ډیر وي. تاسو کولی شئ خپل زیربنا کوډ وګورئ او ووایاست چې ایا تاسو دا حالت لرئ یا نه. که چیرې هیڅ پرتونه روښانه نه شي، نو تاسو اړتیا لرئ یو څه وخت ونیسئ او یو څه ریفیکٹر کړئ.
اساس پرت - دا دا دی چې OS، بیک اپ او نور ټیټ کچې شیان څنګه تنظیم شوي، د بیلګې په توګه، Kubernetes څنګه په اساسي کچه ځای پرځای شوي.
د خدمت کچه - دا هغه خدمتونه دي چې تاسو پرمخ وړونکي ته وړاندې کوئ: د خدمت په توګه ننوتل، د خدمت په توګه څارنه، د خدمت په توګه ډیټابیس، د خدمت په توګه بیلانس، د خدمت په توګه قطار، د خدمت په توګه دوامداره تحویل - د خدماتو یوه ډله چې انفرادي ټیمونه پرمختګ ته زمینه برابرولی شي. دا ټول باید ستاسو د ترتیب مدیریت سیسټم کې په جلا ماډلونو کې تشریح شي.
هغه طبقه چیرې چې غوښتنلیکونه جوړیږي او تشریح کوي چې دوی به څنګه د تیرو دوو پرتونو په سر کې راښکاره شي.
کنټرول پوښتنې
ایا ستاسو شرکت یو عام زیربنا ذخیره لري؟ ایا تاسو په خپل زیربنا کې تخنیکي پور اداره کوئ؟ ایا تاسو د زیربناوو په ذخیره کې د پراختیایي کړنې کاروئ؟ ایا ستاسو زیربنا په پرتونو کې ټوټه شوې؟ تاسو کولی شئ د بیس-خدمت-APP ډیاګرام وګورئ. د بدلون راوستل څومره ستونزمن دي؟
که تاسو تجربه کړې وي چې د بدلونونو لپاره یې یوه نیمه ورځ نیولې، دا پدې مانا ده چې تاسو تخنیکي پور لرئ او اړتیا لرئ چې ورسره کار وکړئ. تاسو یوازې په خپل زیربنا کوډ کې د تخنیکي پور ریک سره ټکر وکړ. زه ډیری داسې کیسې په یاد لرم کله چې د ځینې CCTL بدلولو لپاره، تاسو اړتیا لرئ د زیربنا نیمایي کوډ بیا ولیکئ، ځکه چې خلاقیت او د هرڅه اتومات کولو لیوالتیا د دې حقیقت لامل شوې چې هرڅه په هر ځای کې خراب شوي، ټول لاسونه لیرې شوي، او د بیاکتنې لپاره اړین دی.
دوامداره تحویلي
راځئ چې ډیبیټ د کریډیټ سره پرتله کړو. لومړی د زیربناوو توضیحات راځي، کوم چې خورا بنسټیز کیدی شي. تاسو اړتیا نلرئ هر څه په تفصیل سره بیان کړئ، مګر ځینې اساسي توضیحات اړین دي نو تاسو کولی شئ د هغې سره کار وکړئ. که نه نو، دا روښانه نده چې د پرله پسې تحویلۍ سره څه وکړي. دا ټول عملونه په ورته وخت کې څرګندیږي کله چې تاسو DevOps ته راشئ ، مګر دا د دې پوهیدو سره پیل کیږي چې تاسو څه لرئ او څنګه یې اداره کړئ. دا دقیقا د کوډ په توګه د زیربنا تمرین دی.
یوځل چې دا روښانه شي چې تاسو یې لرئ او دا څنګه اداره کړئ ، تاسو په دې پوهیدل پیل کړئ چې څنګه ژر تر ژره تولید ته د پراختیا کونکي کوډ ولیږئ. زما مطلب د پراختیا کونکي سره یوځای دی - موږ د "څاګانو" ستونزې په اړه یادونه کوو ، دا دا دی چې دا انفرادي خلک ندي چې د دې سره راځي ، مګر یو ټیم.
کله چې موږ سره یو وانیا ایوتخوویچ لومړی کتاب یې ولید جیز عاجز او د لیکوالانو ډلې "دوامداره تحویلي"، کوم چې په 2009 کې خپور شو، موږ د اوږدې مودې لپاره فکر کاوه چې څنګه یې سرلیک په روسیه کې وژباړو. دوی غوښتل چې دا د "دوامداره تحویل" په توګه وژباړي، مګر، له بده مرغه، دا د "دوامداره تحویل" په توګه ژباړل شوی. داسې ښکاري چې زموږ په نوم کې یو څه روسی شتون لري، د فشار سره.
په دوامداره توګه د وسیلو تحویلول
کوډ چې د محصول ذخیره کې وي تل تولید ته ډاونلوډ کیدی شي. هغه ښایي سپک نه شي، مګر هغه تل د دې لپاره چمتو دی. په همدې اساس، تاسو تل د خپل د پښې لاندې د ځینې اضطراب احساس سره کوډ لیکئ. دا ډیری وختونه ښکاري کله چې تاسو د زیربنا کوډ رول کړئ. د ځینې اضطراب دا احساس باید شتون ولري - دا د دماغ پروسې رامینځته کوي چې تاسو ته اجازه درکوي یو څه مختلف کوډ ولیکئ. دا باید د پراختیا دننه قواعدو کې ثبت شي.
په دوامداره توګه وړاندې کولو لپاره، تاسو د هنري بڼه بڼه ته اړتیا لرئ چې د زیربناوو پلیټ فارم کې تیریږي. که تاسو د زیربنا په پلیټ فارم کې د مختلف فارمیټونو "د ژوند ضایع" وغورځوئ، نو دا متحد کیږي، ساتل یې ستونزمن دي، او د تخنیکي پور ستونزه رامینځته کیږي. د هنري اثارو بڼه باید همغږي شي - دا هم یو ډله ایز کار دی: موږ ټول باید سره یوځای شو، خپل مغزونه وخورئ او د دې شکل سره مخ شو.
هنري اثار په دوامداره توګه وده کوي او د تولید چاپیریال سره سم بدلیږي ځکه چې دا د تحویلي پایپ لاین له لارې حرکت کوي. کله چې یو هنري اثار د پایپ لاین په اوږدو کې حرکت کوي، دا په دوامداره توګه د ځینو شیانو سره مخ کیږي چې د هغې لپاره ناامنه وي، کوم چې د هغه هنري اثار سره ورته وي چې تاسو یې د تولید سره مخ کیږي. که په کلاسیک پرمختګ کې دا د سیسټم مدیر لخوا ترسره کیږي چې رول آوټ کوي ، نو د DevOps پروسې کې دا هر وخت پیښیږي: دلته دوی دا د ځینې ازموینو سره ازمویل ، دلته دوی دا د کوبرنیټس کلستر ته وغورځول ، کوم چې ډیر یا لږ ورته دی. تولید ته، بیا یې ناڅاپه د بار ازموینه پیل کړه.
دا یو څه د Pac-Man لوبې یادونه کوي - هنري آثار د یو ډول کیسې له لارې تیریږي. په ورته وخت کې، دا مهمه ده چې کنټرول کړئ چې آیا کوډ په حقیقت کې د کیسې له لارې تیریږي او ایا دا په یو ډول ستاسو د تولید سره تړاو لري. د تولید کیسې د دوامداره تحویلي پروسې ته راښکته کیدی شي: دا داسې وه کله چې یو څه راوتلی و ، اوس راځئ چې دا سناریو په سیسټم کې برنامه کړو. هر ځل چې کوډ به د دې سناریو څخه تیریږي، او تاسو به بل ځل له دې ستونزې سره مخ نه شئ. تاسو به د دې په اړه ډیر دمخه زده کړئ مخکې لدې چې دا ستاسو پیرودونکي ته ورسیږي.
د ګمارنې مختلف تګلارې. د مثال په توګه، تاسو د AB ټیسټینګ یا کانري ګمارنې کاروئ ترڅو کوډ په مختلف پیرودونکو کې په مختلف ډول ازموینه وکړئ ، د کوډ کار کولو څرنګوالي په اړه معلومات ترلاسه کړئ ، او د 100 ملیون کاروونکو ته وړاندې کولو څخه ډیر دمخه.
"په دوامداره توګه وړاندې کول" داسې ښکاري.
د تحویلي پروسه Dev, CI, Test, PreProd, Prod یو جلا چاپیریال نه دی، دا مرحلې یا سټیشنونه دي چې د اور وژنې مقدار لري چې ستاسو هنري توکي تیریږي.
که تاسو د زیربنا کوډ لرئ چې د بیس خدمت APP په توګه تشریح شوی نو دا مرسته کوي ټول سکریپټونه مه هېروئ، او د دې هنري اثارو لپاره یې د کوډ په توګه ولیکئ، هنري اثارو ته وده ورکول او دا بدل کړئ لکه څنګه چې تاسو ځئ.
د ځان ازموینې پوښتنې
په 95٪ قضیو کې د فیچر توضیحاتو څخه تولید ته خوشې کیدو وخت له یوې اونۍ څخه کم دی؟ ایا د پایپ لاین په هره مرحله کې د هنري اثارو کیفیت ښه کیږي؟ ایا داسې کیسه شتون لري چې له لارې تیریږي؟ ایا تاسو د ګمارنې مختلف ستراتیژیانې کاروئ؟
که ټول ځوابونه هو وي، نو تاسو په زړه پورې یاست! خپل ځوابونه په نظرونو کې ولیکئ - زه به خوښ شم).
دباندې
دا د ټولو تر ټولو ستونزمن تمرین دی. د DevOpsConf کنفرانس کې، د Infobip یو همکار، د دې په اړه خبرې کولې، په خپلو خبرو کې یو څه ګډوډ و، ځکه چې دا واقعیا د دې حقیقت په اړه خورا پیچلي تمرین دی چې تاسو اړتیا لرئ د هرڅه څارنه وکړئ!
د مثال په توګه، ډیر وخت دمخه، کله چې ما په Qik کې کار کاوه او موږ پوهیږو چې موږ د هرڅه څارلو ته اړتیا لرو. موږ دا وکړل، او موږ اوس په زبکس کې 150 توکي لرو، چې په دوامداره توګه څارل کیږي. دا ویره وه، تخنیکي رییس په خپل معبد کې خپله ګوته وګرځوله:
- هلکانو، تاسو ولې سرور د ناڅرګنده شی سره جنسي تیری کوئ؟
خو بیا یوه پیښه را منځته شوه چې وښودله چې دا واقعیا ډیره ښه تګلاره ده.
یو له خدماتو څخه په دوامداره توګه حادثه پیل شوه. په پیل کې، دا ټکر نه و، کوم چې په زړه پورې دی، کوډ هلته نه و اضافه شوی، ځکه چې دا یو بنسټیز بروکر و، کوم چې په عملي توګه هیڅ سوداګریز فعالیت نه درلود - دا په ساده ډول د انفرادي خدماتو ترمنځ پیغامونه لیږل. خدمت د 4 میاشتو لپاره بدل نه شو، او ناڅاپه یې د "Segmentation غلطي" تېروتنې سره ټکر پیل کړ.
موږ حیران شو، په زبکس کې زموږ چارټونه پرانستل، او دا معلومه شوه چې یوه اونۍ دمخه، د API خدمت کې د غوښتنو چلند چې دا بروکر کاروي خورا بدل شوی. بیا موږ ولیدل چې د یو ځانګړي ډول پیغام لیږلو فریکوینسي بدله شوې وه. وروسته موږ وموندله چې دا د Android پیرودونکي وو. موږ وپوښتل:
- هلکانو، یوه نیمه اونۍ مخکې تاسو ته څه پیښ شوي؟
په ځواب کې، موږ په زړه پورې کیسه واوریدله چې څنګه دوی د UI بیا ډیزاین کړی. دا امکان نلري چې څوک به سمدلاسه ووایی چې دوی د HTTP کتابتون بدل کړی. د Android پیرودونکو لپاره ، دا په تشناب کې د صابون بدلولو په څیر دی - دوی یوازې په یاد نه لري. د پایلې په توګه، د 40 دقیقو خبرو اترو وروسته، موږ وموندله چې دوی د HTTP کتابتون بدل کړی، او د دې ډیفالټ وختونه بدل شوي. دا د API سرور بدلولو کې د ترافیک چلند لامل شو ، کوم چې د داسې وضعیت لامل شو چې په بروکر کې د سیالۍ لامل شو ، او دا حادثه پیل شوه.
د ژورې څارنې پرته د دې خلاصول عموما ناممکن دي. که چیرې سازمان لاهم د "څاګانو" ستونزه ولري، کله چې هرڅوک یو بل ته پیسې وغورځوي، دا کولی شي د کلونو لپاره ژوند وکړي. تاسو په ساده ډول سرور بیا پیل کړئ ځکه چې د ستونزې حل کول ناممکن دي. کله چې تاسو ټول هغه پیښې وڅارئ، تعقیب کړئ چې تاسو یې لرئ، او څارنه د ازموینې په توګه وکاروئ - کوډ ولیکئ او سمدلاسه په ګوته کړئ چې څنګه یې څارنه وکړئ، د کوډ په بڼه (موږ دمخه د کوډ په توګه زیربنا لرو)، هرڅه روښانه کیږي چې څنګه. په لاس کې حتی دا ډول پیچلې ستونزې په اسانۍ سره تعقیب کیږي.
په دې اړه ټول معلومات راټول کړئ چې د تحویلي پروسې په هر مرحله کې هنري اثار ته څه پیښیږي - نه په تولید کې.
نظارت CI ته اپلوډ کړئ، او ځینې اساسي شیان به لا دمخه هلته ښکاره شي. وروسته به تاسو دوی په ټیسټ ، پریډ پروډ ، او بار ټیسټ کې وګورئ. په ټولو مرحلو کې معلومات راټول کړئ، نه یوازې میټریکونه، احصایې، بلکې لاګونه هم: څنګه چې غوښتنلیک خپور شو، بې نظمۍ - هرڅه راټول کړئ.
که نه نو دا به ستونزمن وي چې دا معلومه کړي. ما دمخه وویل چې DevOps خورا پیچلي دي. د دې پیچلتیا سره د مقابلې لپاره، تاسو اړتیا لرئ چې نورمال تحلیلونه ولرئ.
د ځان کنټرول لپاره پوښتنې
ایا ستاسو نظارت او ننوتل ستاسو لپاره د پراختیا وسیله ده؟ کله چې کوډ لیکئ، ایا ستاسو په شمول ستاسو پراختیا کونکي فکر کوي چې څنګه یې څارنه وکړي؟
ایا تاسو د پیرودونکو ستونزو په اړه اورئ؟ ایا تاسو پیرودونکي د څارنې او ننوتلو څخه ښه پوهیږئ؟ ایا تاسو سیسټم د څارنې او ننوتلو څخه ښه پوهیږئ؟ ایا تاسو په ساده ډول سیسټم بدل کړی ځکه چې تاسو ولیدل چې په سیسټم کې رجحان وده کوي او تاسو پوهیږئ چې په نورو 3 اونیو کې به هرڅه مړه شي؟
یوځل چې تاسو دا درې برخې ولرئ، تاسو کولی شئ د دې په اړه فکر وکړئ چې تاسو په خپل شرکت کې کوم ډول زیربنا پلیټ فارم لرئ.
د زیربنا پلیټ فارم
ټکی دا ندی چې دا د متفاوت وسیلو سیټ دی چې هر شرکت لري.
د زیربنا پلیټ فارم نقطه دا ده چې ټول ټیمونه دا وسیلې کاروي او یوځای یې وده کوي.
دا روښانه ده چې جلا ټیمونه شتون لري چې د زیربنا پلیټ فارم انفرادي برخو پراختیا لپاره مسؤل دي. مګر په ورته وخت کې، هر انجنیر د زیربناوو پلیټ فارم پراختیا، فعالیت او ترویج مسولیت لري. په داخلي کچه دا یو عام وسیله کیږي.
ټول ټیمونه د زیربنا پلیټ فارم رامینځته کوي او د خپل IDE په توګه یې د پاملرنې سره چلند کوي. ستاسو په IDE کې تاسو مختلف پلگ ان نصب کړئ ترڅو هرڅه ښه او ګړندي کړي ، او هاټ کیز تنظیم کړئ. کله چې تاسو Sublime، Atom یا Visual Studio Code خلاص کړئ، د کوډ تېروتنې په کې راځي او تاسو پوهیږئ چې دا په هیڅ ډول کار کول ناممکن دي، تاسو سمدلاسه د خپګان احساس کوئ او تاسو د خپل IDE د سمولو لپاره منډه کوئ.
ستاسو د زیربنا پلیټ فارم سره ورته چلند وکړئ. که تاسو پوهیږئ چې پدې کې یو څه غلط دی، یوه غوښتنه پریږدئ که تاسو دا پخپله حل نه کړئ. که یو څه ساده وي، دا پخپله ایډیټ کړئ، د پلټ غوښتنه واستوئ، هلکان به یې په پام کې ونیسي او اضافه کړي. دا د پراختیا کونکي په سر کې د انجینرۍ وسیلو لپاره یو څه مختلف چلند دی.
د زیربنا پلیټ فارم د کیفیت په دوامداره پرمختګ سره پیرودونکي ته د پراختیا څخه د هنري اثارو لیږد تضمینوي. IP د کیسې سیټ سره برنامه شوی چې په تولید کې کوډ سره پیښیږي. د پراختیا په کلونو کې، د دې کیسې ډیری شتون لري، ځینې یې بې ساري دي او یوازې تاسو پورې اړه لري - دوی نشي کولی ګوګل شي.
پدې مرحله کې ، د زیربنا پلیټ فارم ستاسو سیالي ګټه کیږي، ځکه چې دا په دې کې یو څه جوړ شوی چې د سیالي کونکي وسیلې کې ندي. هرڅومره چې ستاسو IP ژور وي ، په بازار کې د وخت په شرایطو کې ستاسو سیالي ګټه خورا لوړه ده. دلته ښکاري د پلورونکي بند ستونزه: تاسو کولی شئ د بل چا پلیټ فارم واخلئ، مګر د بل چا تجربه په کارولو سره، تاسو به نه پوهیږئ چې دا ستاسو لپاره څومره اړین دی. هو، هر شرکت نشي کولی د ایمیزون په څیر پلیټ فارم جوړ کړي. دا یوه ستونزمنه کرښه ده چیرې چې د شرکت تجربه په بازار کې د هغې موقعیت سره تړاو لري، او تاسو نشئ کولی هلته د پلورونکي تالا وکاروئ. دا هم مهمه ده چې فکر وکړئ.
دا پلان
دا د زیربنا پلیټ فارم بنسټیز ډیاګرام دی چې تاسو سره به د DevOps شرکت کې ټولې کړنې او پروسې تنظیم کولو کې مرسته وکړي.
راځئ وګورو چې دا څه شی لري.
د سرچینو آرکیسټریشن سیسټم، کوم چې غوښتنلیکونو او نورو خدماتو ته CPU ، حافظه ، ډیسک چمتو کوي. د دې په سر کې - د ټیټې کچې خدمتونه: څارنه، ننوتنه، د CI/CD انجن، د آثارو ذخیره، د سیسټم کوډ په توګه زیربنا.
د لوړې کچې خدمتونه: ډیټابیس د خدمت په توګه، د خدمت په توګه کتارونه، د خدمت په توګه د بار بیلانس، د خدمت په توګه د انځور اندازه کول، د لوی ډیټا فابریکه د خدمت په توګه. د دې په سر کې - پایپ لاین چې ستاسو پیرودونکي ته په دوامداره توګه بدل شوی کوډ وړاندې کوي.
تاسو د دې په اړه معلومات ترلاسه کوئ چې ستاسو سافټویر د پیرودونکي لپاره څنګه کار کوي، دا بدل کړئ، دا کوډ بیا وړاندې کړئ، معلومات ترلاسه کړئ - او پدې توګه تاسو په دوامداره توګه د زیربنا پلیټ فارم او ستاسو سافټویر دواړه وده کوئ.
په ډیاګرام کې، د لیږد پایپ لاین ډیری مرحلې لري. مګر دا یو سکیماتیک ډیاګرام دی چې د مثال په توګه ورکړل شوی - اړتیا نشته چې دا یو یو تکرار کړئ. مرحلې د خدماتو سره متقابل عمل کوي لکه څنګه چې دوی خدمتونه وي — د پلیټ فارم هره خښت خپله کیسه لري: څنګه سرچینې تخصیص کیږي ، څنګه غوښتنلیک پیل شوی ، د سرچینو سره کار کوي ، نظارت کیږي او بدلونونه.
دا مهمه ده چې پوه شئ چې د پلیټ فارم هره برخه یوه کیسه لري، او له ځانه وپوښتئ چې دا خښته څه کیسه لري، شاید دا باید وغورځول شي او د دریمې ډلې خدمت سره بدل شي. د مثال په توګه، ایا دا ممکنه ده چې د خښتو پر ځای Okmeter نصب کړئ؟ شاید هلکانو لا دمخه دا تخصص زموږ په پرتله خورا ډیر رامینځته کړی. مګر شاید نه - شاید موږ ځانګړي مهارتونه لرو، موږ اړتیا لرو چې پرومیتیس نصب کړو او نور یې پراختیا کړو.
د پلیټ فارم جوړول
دا د اړیکو پیچلې پروسه ده. کله چې تاسو بنسټیز تمرینونه لرئ، تاسو د مختلف انجینرانو او متخصصینو ترمنځ اړیکه پیل کوئ چې اړتیاوې او معیارونه رامینځته کوي، او په دوامداره توګه دوی مختلف وسایلو او طریقو ته بدلوي. هغه کلتور چې موږ یې په DevOps کې لرو دلته مهم دی.
د کلتور سره هرڅه خورا ساده دي - دا د همکارۍ او اړیکو په اړه دی، دا دی، د یو بل سره په ګډ ساحه کې د کار کولو لیوالتیا، د یوې وسیلې سره یوځای کولو هیله. دلته د راکټ ساینس شتون نلري - هرڅه خورا ساده دي، بندیز. د مثال په توګه، موږ ټول په ننوتلو کې ژوند کوو او دا پاک ساتو - دا ډول کلتور.
ته څه لرې؟
بیا بیا، پوښتنې چې تاسو کولی شئ له ځانه وپوښتئ.
ایا د زیربنا پلیټ فارم وقف شوی دی؟ د هغه د پرمختګ مسولیت څوک دی؟ ایا تاسو د خپل زیربنا پلیټ فارم رقابتي ګټې پیژنئ؟
تاسو باید په دوامداره توګه له ځانه دا پوښتنې وپوښتئ. که یو څه د دریمې ډلې خدماتو ته لیږدول کیدی شي، دا باید لیږدول شي؛ که چیرې د دریمې ډلې خدمت ستاسو د حرکت مخنیوی پیل کړي، نو تاسو باید په خپل ځان کې یو سیسټم جوړ کړئ.
نو، DevOps ...
... دا یو پیچلی سیسټم دی، دا باید ولري:
- ډیجیټل محصول.
- د سوداګرۍ ماډلونه چې دا ډیجیټل محصول رامینځته کوي.
- د محصول ټیمونه چې کوډ لیکي.
- د تحویلي دوامداره تمرینونه.
- د خدمت په توګه پلیټ فارمونه.
- زیربنا د خدمت په توګه.
- د کوډ په توګه زیربنا.
- د اعتبار ساتلو لپاره جلا تمرینونه، په DevOps کې جوړ شوي.
- د فیډبیک تمرین چې دا ټول تشریح کوي.
تاسو کولی شئ دا ډیاګرام وکاروئ ، پدې کې هغه څه په ګوته کړئ چې تاسو دمخه ستاسو په شرکت کې په یو شکل کې لرئ: ایا دا رامینځته شوی یا لاهم پراختیا ته اړتیا لري.
دا به په څو اونیو کې پای ته ورسیږي . د RIT++ د یوې برخې په توګه. کنفرانس ته راشئ ، چیرې چې تاسو به د دوامداره تحویلۍ ، د کوډ په توګه زیربنا او د DevOps بدلون په اړه ډیری ښه راپورونه ومومئ. د نرخ وروستۍ نیټه د می 20 ده
سرچینه: www.habr.com