پوښتنه "څنګه د ډیوپس پلي کول" د کلونو راهیسې شتون لري ، مګر ډیر ښه توکي شتون نلري. ځینې وختونه تاسو د غیر هوښیار مشاورینو لخوا د اعلاناتو قرباني یاست څوک چې اړتیا لري خپل وخت وپلوري ، مهمه نده چې څنګه. ځینې وختونه دا مبهم ، خورا عمومي ټکي دي پدې اړه چې څنګه د میګا کارپوریشن کښتۍ د کائنات پراخوالی تیروي. پوښتنه راپورته کیږي: دا زموږ لپاره څه ارزښت لري؟ ګرانه لیکواله، ایا تاسو کولی شئ په روښانه توګه خپل نظرونه په لیست کې جوړ کړئ؟
دا ټول د دې حقیقت څخه رامینځته شوي چې د شرکت کلتور د بدلون پایلو په اړه خورا ریښتیني تمرین او پوهه نه ده راټول شوي. په کلتور کې بدلونونه اوږدمهاله شیان دي، چې پایلې به یې په اونۍ یا یوه میاشت کې نه ښکاري. موږ دومره زوړ چا ته اړتیا لرو چې ولیدل شي چې څنګه شرکتونه جوړ شوي او د کلونو په اوږدو کې ناکام شوي.
جان ویلیس - د DevOps له پلرونو څخه یو. جان د ډیرو شرکتونو سره د کار کولو لسیزې تجربه لري. په دې وروستیو کې، جان د ځانګړو نمونو لیدل پیل کړل چې د دوی د هر یو سره کار کولو په وخت کې واقع کیږي. د دې آرکیټایپونو په کارولو سره ، جان شرکتونو ته د DevOps بدلون ریښتیني لار کې لارښود کوي. د دې آثارو په اړه نور ولولئ د DevOops 2018 کنفرانس څخه د هغه راپور په ژباړه کې.
د سپیکر په اړه:
د آی ټي مدیریت کې له 35 کلونو څخه ډیر ، په کینونیکل کې د اوپن کلاډ وړاندیز کونکي رامینځته کولو کې برخه اخیستې ، په 10 پیلونو کې برخه اخیستې ، چې دوه یې ډیل او ډاکر ته پلورل شوي. اوس مهال هغه په SJ ټیکنالوژیو کې د DevOps او ډیجیټل تمرینونو مرستیال دی.
بله کیسه د جان له نظره ده.
زما نوم جان ویلیس دی او زما د موندلو ترټولو اسانه ځای په ټویټر کې دی، . زه په Gmail او GitHub کې ورته عرف لرم. الف تاسو کولی شئ زما د راپورونو او پریزنټشنونو ویډیو ریکارډونه ومومئ.
زه د مختلفو لوی شرکتونو CIOs سره ډیری ناستې لرم. دوی ډیری وختونه شکایت کوي چې دوی نه پوهیږي DevOps څه شی دی، او هرڅوک چې دوی ته د تشریح کولو هڅه کوي د یو څه مختلف په اړه خبرې کوي. بل عام شکایت دا دی چې DevOps کار نه کوي، که څه هم داسې ښکاري چې رییسان هر څه کوي لکه څنګه چې دوی ته تشریح شوي. موږ د لوی شرکتونو په اړه خبرې کوو چې له سلو کلونو څخه ډیر عمر لري. د دوی سره د خبرو کولو وروسته، زه دې پایلې ته ورسیدم چې د ډیرو ستونزو لپاره، دا لوړ ټیکنالوژي نه ده چې غوره وي، مګر نسبتا ټیټ ټیکنالوژي حلونه. د اونیو لپاره ما یوازې د مختلفو څانګو خلکو سره خبرې وکړې. هغه څه چې تاسو په پوسټ کې په لومړي عکس کې ګورئ زما وروستۍ پروژه ده ، دا هغه څه دي چې خونه د دریو ورځو کار وروسته ورته ښکاري.
DevOps څه شی دی؟
په حقیقت کې، که تاسو د 10 مختلف خلکو څخه وپوښتئ، دوی به 10 مختلف ځوابونه ورکړي. مګر دلته په زړه پورې خبره ده: دا ټول لس ځوابونه به سم وي. دلته هیڅ غلط ځواب نشته. زه د شاوخوا 10 کلونو لپاره په DevOps کې خورا ژور وم ، او په لومړي DevOpsDay کې لومړی امریکایی وم. زه به ونه وایم چې زه د هرچا په پرتله هوښیار یم چې په DevOps کې دخیل دي ، مګر په ندرت سره داسې څوک شتون لري چې پدې کې یې دومره هڅه کړې وي. زه باور لرم چې DevOps واقع کیږي کله چې انساني پانګه او ټیکنالوژي سره یوځای شي. موږ ډیری وختونه د انساني اړخ په اړه هیر کوو، که څه هم موږ د هر ډول کلتورونو په اړه ډیرې خبرې کوو.
اوس موږ ډیری معلومات لرو، پنځه کلن علمي څیړنه، په صنعتي پیمانه د تیوریو ازموینه. هغه څه چې دا مطالعات موږ ته وایی که تاسو په سازماني کلتور کې د چلند ځینې نمونې سره یوځای کړئ ، تاسو کولی شئ د 2000x سرعت ترلاسه کړئ. دا سرعت په ثبات کې د مساوي پرمختګ سره سمون لري. دا د ګټې کمیتي اندازه ده چې DevOps کولی شي کوم شرکت ته راوړي. څو کاله وړاندې، ما د فارچون 5000 شرکت سی ای او سره د DevOps په اړه خبرې کولې، کله چې ما د پریزنټشن لپاره چمتووالی نیولی و، زه ډیر اندیښمن وم ځکه چې ما باید په 5 دقیقو کې زما د کلونو تجربې لنډیز کړي.
په پای کې ما لاندې ورکړل د DevOps تعریف: دا د طرزالعملونو او نمونو ټولګه ده چې د لوړ فعالیت سازماني پانګې ته د بشري پانګې د بدلون وړتیا ورکوي. یوه بیلګه هغه طریقه ده چې ټویوټا په تیرو 50 یا 60 کلونو کې فعالیت کوي.
(له دې وروسته، دا ډول ډیاګرامونه د حوالې موادو په توګه نه، بلکې د انځورونو په توګه وړاندې کیږي. د دوی محتويات به د هر نوي شرکت لپاره توپیر ولري. په هرصورت، انځور په جلا توګه لیدل کیدی شي او لوی کیدی شي.
یو له ډیرو بریالیو داسې کړنو څخه دی د ارزښت نخشه نقشه. د دې په اړه څو ښه کتابونه لیکل شوي، چې ترټولو بریالي یې د کیرن مارټین لخوا دي. مګر د تیر کال په اوږدو کې، زه دې پایلې ته رسیدلی یم چې حتی دا طریقه خورا لوړ ټیکنالوژي ده. دا یقینا ډیرې ګټې لري او ما دا ډیره کارولې ده. مګر کله چې اجرایوي رییس تاسو څخه پوښتنه کوي چې ولې د هغه شرکت نشي کولی نوي ریلونو ته لاړ شي، نو د ارزښت سټریم نقشه کولو په اړه خبرې کول ډیر وختي دي. ډیری نور بنسټیز پوښتنې شتون لري چې لومړی باید ځواب شي.
زه فکر کوم هغه غلطي چې زما ډیری همکاران کوي دا دي چې دوی په ساده ډول شرکت ته پنځه ټکي لارښود ورکوي او بیا شپږ میاشتې وروسته بیرته راځي او وګورئ چې څه پیښ شوي. حتی یو ښه سکیم لکه د ارزښت سټریم میپینګ لري ، راځئ چې ووایو ، ړانده ځایونه. د مختلفو شرکتونو د رییسانو سره د سلګونو مرکو وروسته، ما یو ځانګړی نمونه رامینځته کړې چې موږ ته اجازه راکوي ستونزه د هغې په برخو کې مات کړو، او اوس به موږ د دې هرې برخې په ترتیب سره بحث وکړو. د هر ډول تخنیکي حلونو پلي کولو دمخه، زه دا نمونه کاروم، او د پایلې په توګه، زما ټول دیوالونه د ډیاګرامونو سره پوښل شوي. پدې وروستیو کې ما د دوه اړخیز فنډ سره کار کاوه او ما د 100-150 داسې سکیمونو سره پای ته ورساوه.
بد کلتور د سهارنۍ لپاره ښه طریقې خوري
اصلي نظر دا دی: د Lean، Agile، SAFE او DevOps هیڅ مقدار به مرسته ونه کړي که چیرې د سازمان کلتور پخپله خراب وي. دا د سکوبا ګیر پرته ژورو ته د ډوبولو په څیر دی یا د ایکس رے پرته کار کوي. په بل عبارت، د ډرکر او ډیمینګ تمثیل کول: یو بد سازماني کلتور به پرته له دې چې په خوله کېږدي هر ښه سیسټم تیر کړي.
د دې اصلي ستونزې د حل لپاره، تاسو باید لاندې ګامونه پورته کړئ:
- ټول کارونه ښکاره کړئ: تاسو اړتیا لرئ ټول کارونه ښکاره کړئ. په دې معنی نه چې دا باید په ځینې سکرین کې ښکاره شي، مګر په دې معنی چې دا باید د لیدلو وړ وي.
- د کار مدیریت سیسټمونه: د مدیریت سیسټمونه باید یوځای شي. د "قبائلي" پوهې او اداري پوهې په ستونزه کې، له 9 څخه په 10 قضیو کې خنډ خلک دي. په کتاب کې ستونزه د یو واحد شخص، برینټ سره وه، چې د پروژې د مهال ویش څخه درې کاله وروسته وه. او زه هرچیرې دې "برینټ" ته ځم. د دې خنډونو حل کولو لپاره ، زه زموږ په لیست کې راتلونکي دوه توکي کاروم.
- د محدودیتونو میتودولوژي نظریه: د محدودیتونو نظریه
- د همکارۍ هکونه: د همکارۍ هیکونه.
- ټیوټا کاتا (): زه به د ټیوټا کاتا په اړه ډیرې خبرې ونه کړم. که علاقه لرئ ، زما په ګیتوب کې د دې موضوعاتو نږدې هرې یوې باندې.
- د بازار پر بنسټ اداره: د بازار پر بنسټ سازمان.
- کیڼ اړخ ته شفټ پلټونکي: د دورې په لومړیو مرحلو کې پلټنه.
زه په ساده ډول د یوې ادارې سره کار پیل کوم: زه شرکت ته ځم او د کارمندانو سره خبرې کوم. لکه څنګه چې تاسو لیدلی شئ، هیڅ لوړ ټیکنالوژي نشته. ټول هغه څه چې تاسو ورته اړتیا لرئ د لیکلو لپاره دي. زه په یوه خونه کې څو ټیمونه راټولوم او تحلیل کوم چې دوی زما د 7 لرغونو آثارو له لید څخه څه وايي. او بیا زه دوی ته پخپله مارکر ورکوم او له دوی څخه غواړم چې په تخته کې هر هغه څه ولیکي چې دوی تر دې دمه په لوړ غږ ویلي دي. معمولا په دې ډول غونډو کې یو څوک وي چې هر څه لیکي، او په غوره توګه هغه کولی شي د بحث 10٪ لیکي. زما د میتود سره، دا شمیره شاوخوا 40٪ ته پورته کیدی شي.
(دا انځور په جلا توګه لیدل کیدی شي )
زما تګلاره د ویلیم شنایډر د کار پراساس ده. ). تګلاره د دې مفکورې پر بنسټ والړ ده چې هر سازمان په څلورو چوکیو ویشل کیدی شي. زما لپاره دا سکیم معمولا د هغو سلګونو نورو سکیمونو سره د کار کولو پایله ده چې د یوې ادارې تحلیل کولو په وخت کې رامینځته کیږي. فرض کړئ چې موږ یوه اداره لرو چې د لوړې کچې کنټرول لري ، مګر د ټیټ وړتیا سره. دا یو خورا ناغوښتل شوی اختیار دی: کله چې هرڅوک کرښه ته ځي، مګر هیڅوک نه پوهیږي چې څه وکړي.
یو څه غوره انتخاب هغه دی چې د لوړې کچې کنټرول او وړتیا سره. که دا ډول شرکت ګټور وي، نو شاید دا DevOps ته اړتیا نلري. دا خورا په زړه پوري ده چې د داسې شرکت سره کار وکړئ چې د کنټرول لوړه کچه ، ټیټ وړتیا او همکاري ولري ، مګر په ورته وخت کې د کلتور (کرنې) لوړه کچه. دا پدې مانا ده چې شرکت ډیری خلک لري چې هلته کار کول خوښوي او د کار تبادله ټیټه ده.
(دا انځور په جلا توګه لیدل کیدی شي )
ماته داسې بریښي چې د سختو لارښوونو سره میتودونه د حقیقت ترلاسه کولو په لاره کې پای ته رسیږي. په ځانګړې توګه د ارزښت سټریم نقشه کولو کې، د دې په اړه ډیری قواعد شتون لري چې معلومات باید څنګه جوړ شي. د کار په لومړیو مرحلو کې، کوم چې زه یې اوس په اړه خبرې کوم، هیڅوک دې مقرراتو ته اړتیا نلري. که یو څوک په لاس کې مارکر ولري په بورډ کې د شرکت اصلي وضعیت بیانوي، دا د وضعیت د پوهیدو لپاره غوره لاره ده. دا ډول معلومات مدیرانو ته نه رسیږي. په دې وخت کې دا احمقانه خبره ده چې د سړي مداخله وکړي او ووایي چې هغه یو ډول تیر په غلط ډول راښکته کړ. په دې مرحله کې، دا غوره ده چې ساده قواعد وکاروئ، د بیلګې په توګه: څو اړخیزه خلاصون په ساده ډول د څو رنګ مارکرونو په کارولو سره رامینځته کیدی شي.
زه تکراروم، هیڅ لوړ ټیکنالوژي نشته. تور مارکر هدف واقعیت څرګندوي چې څنګه هرڅه کار کوي. د سور مارکر سره، خلک هغه څه په نښه کوي چې دوی د اوسني حالت په اړه نه خوښوي. دا مهمه ده چې دوی دا لیکي، نه زه. کله چې زه د غونډې وروسته CIO ته لاړ شم، زه د 10 شیانو لیست نه وړاندې کوم چې باید تنظیم شي. زه هڅه کوم چې د هغه څه ترمنځ اړیکې ومومئ چې په شرکت کې خلک وايي او موجوده ثابت نمونې. په نهایت کې ، نیلي مارکر د ستونزې احتمالي حل وړاندیز کوي.
(دا انځور په جلا توګه لیدل کیدی شي )
د دې طریقې یوه بیلګه اوس پورته ښودل شوې. د دې کال په پیل کې ما په یوه بانک کې کار کاوه. هلته امنیتي کسان په دې قانع شول چې د طرحو او اړتیاوو کتنو ته نه راځي.
(دا انځور په جلا توګه لیدل کیدی شي )
او بیا موږ د نورو څانګو له خلکو سره خبرې وکړې او دا معلومه شوه چې شاوخوا 8 کاله دمخه د سافټویر جوړونکو امنیتي کارمندان له دې امله له دندو ګوښه کړل چې کار یې ورو کاوه. او بیا دا په یو بندیز بدل شو، کوم چې د منلو وړ و. که څه هم په حقیقت کې هیڅ بندیز نه و.
زموږ غونډه په خورا مغشوش ډول پرمخ ولاړه: د شاوخوا دریو ساعتونو لپاره ، پنځه مختلف ټیمونه ما ته نشي توضیح کولی چې د کوډ او مجلس ترمینځ څه پیښیږي. او دا به تر ټولو ساده شی ښکاري. د DevOps ډیری مشاورین مخکې فرض کوي چې هرڅوک دمخه پدې پوهیږي.
بیا د معلوماتي ټیکنالوژۍ د حکومتدارۍ مسؤول سړی چې څلور ساعته غلی و، ناڅاپه په ژوند کې راغی کله چې موږ خپلې موضوع ته ورسیدو او د ډیر وخت لپاره یې موږ اشغال کړ. په پای کې ما له هغه وپوښتل چې هغه د غونډې په اړه څه فکر کوي، او زه به هیڅکله د هغه ځواب هیر نکړم. هغه وویل: "ما به فکر کاوه چې زموږ بانک د سافټویر وړاندې کولو لپاره یوازې دوه لارې لري، مګر اوس زه پوهیږم چې پنځه یې شتون لري، او زه حتی د دریو څخه خبر نه وم."
(دا انځور په جلا توګه لیدل کیدی شي )
په دې بانک کې وروستۍ ناسته د پانګونې سافټویر ټیم سره وه. دا د هغې سره وه چې دا معلومه شوه چې د کاغذ په پاڼه کې د مارکر سره ډیاګرام لیکل د تختې په پرتله غوره دي، او حتی د سمارټ بورډ څخه غوره دي.
هغه عکسونه چې تاسو یې ګورئ هغه څه دي چې زموږ د غونډې په څلورمه ورځ د هوټل کنفرانس خونه ورته ښکاري. او موږ دا سکیمونه د نمونو لټون کولو لپاره کارولي، دا د لرغونو آثارو.
نو، زه د کارګرانو څخه پوښتنې کوم، دوی د دریو رنګونو (تور، سور او نیلي) په نښه کولو سره ځوابونه لیکي. زه د دوی ځوابونه د لرغونو آثارو لپاره تحلیل کوم. اوس راځئ چې په ترتیب سره د ټولو لرغونو آثارو په اړه بحث وکړو.
1. ټول کارونه ښکاره کړئ: کار ښکاره کړئ
ډیری شرکتونه چې زه ورسره کار کوم د نامعلوم کار خورا لوړه سلنه لري. د مثال په توګه، دا هغه وخت دی چې یو کارمند بل ته راځي او په ساده ډول د یو څه کولو غوښتنه کوي. په لویو سازمانونو کې، ممکن 60٪ غیر پلان شوي کار وي. او تر 40٪ پورې کار په هیڅ ډول مستند شوی نه دی. که دا بوینګ وای، نو زه به هیڅکله په خپل ژوند کې د دوی الوتکه کې نه سپارم. که یوازې نیمایي کار مستند شي، نو معلومه نه ده چې دا کار په سمه توګه ترسره کیږي که نه. نورې ټولې میتودونه بې ګټې دي - د هیڅ شی اتومات کولو هڅه کولو کې هیڅ معنی نشته ، ځکه چې پیژندل شوي 50٪ ممکن د کار خورا همغږي او روښانه برخه وي ، د دې اتومات کول به عالي پایلې نه ورکوي ، او ټول بد. شیان په نه لیدونکي نیم کې دي. د اسنادو په نشتوالي کې، د هر ډول هیکونو او پټو کارونو موندل ناممکن دي، نه د خنډونو موندلو لپاره، هغه خورا "برینټ" چې ما دمخه یې په اړه خبرې کړې وې. د ډومینیکا ډیګرانډیس لخوا یو په زړه پوری کتاب شتون لري . هغې څرګنده کړه پنځه مختلف "وخت لیکونه" (د وخت غله):
- په پروسه کې ډیر کار (WIP)
- نامعلوم انحصارونه
- غیر پلان شوي کار
- متضاد لومړیتوبونه
- غفلت شوی کار
دا خورا ارزښتناکه تحلیل دی او کتاب خورا ښه دی، مګر دا ټولې مشورې بې ګټې دي که یوازې 50٪ ډاټا لیدل کیږي. د ډومینیکا لخوا وړاندیز شوي میتودونه کارول کیدی شي که چیرې د 90٪ څخه پورته دقت ترلاسه شي. زه د داسې شرایطو په اړه خبرې کوم چې مالک یو ماتحت ته 15 دقیقې دنده ورکوي، مګر دا هغه درې ورځې نیسي؛ مګر مالک په حقیقت کې نه پوهیږي چې دا ماتحت په څلورو یا پنځو نورو خلکو پورې اړه لري.
د فینکس پروژه د یوې پروژې په اړه یوه زړه پورې کیسه ده چې درې کاله ډیر ناوخته و. یو کرکټر د دې له امله له ګوښه کیدو سره مخ کیږي او هغه د بل کرکټر سره ملاقات کوي چې د سقراط په څیر وړاندې کیږي. هغه مرسته کوي چې معلومه کړي چې واقعیا څه غلط شوي. دا معلومه شوه چې شرکت د سیسټم یو مدیر لري، چې نوم یې برینټ دی، او ټول کارونه یو څه د هغه له لارې تیریږي. په یوه مجلس کې له یوه مامور څخه پوښتنه کیږي: ولې هر نیم ساعت کار یوه اونۍ وخت نیسي؟ ځواب د قطار تیوري او د کوچني قانون خورا ساده پریزنټشن دی، او پدې پریزنټشن کې دا معلومه شوه چې په 90٪ اشغال کې، د کار هر ساعت 9 ساعته وخت نیسي. هر کار ته اړتیا ده چې اوه نورو کسانو ته واستول شي، نو دا ساعت 63 ساعته، 7 ځله 9 کیږي. زه څه وایم چې د کوچني قانون یا کومې پیچلې قطار تیوري کارولو لپاره، تاسو لږترلږه ډاټا ته اړتیا لرئ.
نو کله چې زه د لید په اړه وغږیږم ، زما مطلب دا ندی چې هرڅه په سکرین کې دي ، مګر دا چې تاسو لږترلږه معلومات لرئ. کله چې دوی ترسره کوي، ډیری وختونه دا معلومه شوه چې د غیر پلان شوي کار خورا لوی مقدار شتون لري چې په یو ډول برینټ ته لیږل کیږي کله چې ورته اړتیا نشته. او برینټ یو ښه سړی دی، هغه به هیڅکله نه ووایي، مګر هغه چا ته نه وايي چې هغه څنګه خپله دنده ترسره کوي.
کله چې کار څرګند وي ، ډاټا په ښه ډول طبقه بندي کیدی شي (دا هغه څه دي چې ډومینیکا په عکس کې کوي) ، د پنځه وخت لیکونو خلاصول پلي کیدی شي ، او اتومات پلي کیدی شي.
2. د کار مدیریت سیسټمونه یوځای کړئ: د دندې مدیریت
هغه آثار چې زه یې په اړه خبرې کوم یو ډول پیرامیډ دی. که لومړی په سمه توګه ترسره شي، نو دویم یې لا دمخه یو ډول اضافه دی. ډیری یې د پیل لپاره کار نه کوي، دوی باید د لویو شرکتونو لکه Fortune 5000 لپاره په پام کې ونیول شي. وروستی شرکت چې ما کار کړی د 10 ټکټینګ سیسټمونه درلودل. یوې ډلې Remedy درلود، بل یې یو ډول خپل سیسټم لیکلی و، دریم یې جیرا کارولی و، او ځینې یې د بریښنالیک سره جوړ کړل. ورته ستونزه رامینځته کیږي که چیرې شرکت 30 مختلف پایپ لاینونه ولري ، مګر زه د دې ټولو قضیو په اړه د بحث کولو وخت نلرم.
زه د خلکو سره په ریښتیا بحث کوم چې ټکټونه څنګه رامینځته کیږي ، دوی ته څه پیښیږي ، او دوی څنګه مخنیوی کیږي. تر ټولو په زړه پورې خبره دا ده چې زموږ په غونډو کې خلک خورا صادقانه خبرې کوي. ما وپوښتل چې څومره خلک په ټکټونو کې "کوچني / هیڅ اغیزه" نلري چې واقعیا باید "لوی تاثیر" ورکړل شي. دا معلومه شوه چې نږدې هرڅوک دا کوي. زه په غندنه کې ښکیل نه یم او په هره ممکنه طریقه هڅه کوم چې خلک ونه پیژنم. کله چې دوی په صادقانه توګه ما ته یو څه اعتراف کوي، زه هغه کس نه ورکوم. مګر کله چې نږدې هرڅوک د سیسټم څخه تیریږي، دا پدې مانا ده چې ټول امنیت په اصل کې د کړکۍ جامې دي. له همدې امله، د دې سیسټم د معلوماتو څخه هیڅ نتیجه نشي اخیستل کیدی.
د ټکټ ستونزه حل کولو لپاره، تاسو اړتیا لرئ یو اصلي سیسټم غوره کړئ. که تاسو جیرا کاروئ نو جیرا وساتئ. که کوم بدیل شتون ولري، اجازه راکړئ چې یوازینۍ وي. لاندینۍ کرښه دا ده چې ټکټونه باید د پراختیا په بهیر کې د بل ګام په توګه وګڼل شي. هر عمل باید یو ټکټ ولري، کوم چې باید د پراختیایي کاري فلو له لارې تیریږي. ټکټونه ټیم ته لیږل کیږي، کوم چې دوی د کیسې بورډ کې پوسټ کوي او بیا یې مسولیت په غاړه اخلي.
دا په ټولو څانګو باندې تطبیق کیږي، په شمول د زیربنا او عملیات. په دې حالت کې، دا ممکنه ده چې د وضعیت په اړه لږ تر لږه د پام وړ مفکوره جوړه کړئ. یوځل چې دا پروسه رامینځته شي ، دا ناڅاپه اسانه کیږي چې پیژندل شي څوک د هر غوښتنلیک لپاره مسؤل دی. ځکه چې اوس موږ 50٪ نه، مګر 98٪ نوي خدمتونه ترلاسه کوو. که دا اصلي پروسه کار وکړي، نو دقت په ټول سیسټم کې وده کوي.
د خدماتو پایپ لاین
دا بیا یوازې په لویو شرکتونو باندې تطبیق کیږي. که تاسو په یوه نوي ساحه کې نوی شرکت یاست، خپل آستین پورته کړئ او د خپل Travis CI یا CircleCI سره کار وکړئ. کله چې دا د فارچون 5000 شرکتونو ته راځي ، یوه قضیه په هغه بانک کې پیښ شوه چیرې چې ما کار کاوه. ګوګل دوی ته راغی او دوی ته د زاړه IBM سیسټمونو ډیاګرامونه وښودل شول. د ګوګل څخه هلکانو په ګډوډۍ کې وپوښتل - د دې لپاره سرچینه کوډ چیرته دی؟ مګر د سرچینې کوډ شتون نلري، حتی د GUI نه. دا هغه حقیقت دی چې لوی سازمانونه باید ورسره معامله وکړي: په لرغوني مین فریم کې د 40 کلن بانک ریکارډونه. زما یو پیرودونکي د سرکټ بریکر نمونو سره د کوبرنیټس کانټینرونه کاروي ، او د چاوس بندر ، ټول د کیبینک غوښتنلیک لپاره. مګر دا کانټینرونه په نهایت کې د COBOL غوښتنلیک سره وصل کیږي.
د ګوګل هلکان په بشپړ ډول ډاډه وو چې دوی به زما د پیرودونکي ټولې ستونزې حل کړي، او بیا یې پوښتنې پیل کړې: د IBM ډیټاپپ څه شی دی؟ دوی ته ویل کیږي: دا یو نښلونکی دی. دا څه سره نښلوي؟ د سپری سیسټم ته. او هغه څه دي؟ او همداسی پسی. په لومړي نظر کې داسې ښکاري: کوم ډول DevOps شتون لري؟ مګر په حقیقت کې، دا ممکنه ده. د تحویلي سیسټمونه شتون لري چې تاسو ته اجازه درکوي د تحویلي ټیمونو ته کاري جریان وسپارئ.
3. د خنډونو تیوري: د محدودیتونو تیوري
راځئ چې دریم لرغونتوب ته لاړ شو: اداری / "قبائلي" پوهه. د یوې قاعدې په توګه، په هره اداره کې ډیری خلک شتون لري چې هرڅه پوهیږي او هرڅه اداره کوي. دا هغه څوک دي چې په سازمان کې تر ټولو اوږد وي او څوک چې ټول کاري چاري پیژني.
کله چې دا په ډیاګرام کې راځي، زه په ځانګړې توګه دا ډول خلک د مارکر سره حلقوي: د بیلګې په توګه، دا معلومه شوه چې یو ځانګړی لو په ټولو غونډو کې شتون لري. او دا ماته روښانه ده: دا سیمه ایز برینټ دی. کله چې CIO زما تر منځ په ټي شرټ او سنیکرز کې او د IBM یو سړی په جامو کې غوره کوي ، زه غوره شوی یم ځکه چې زه کولی شم رییس ته هغه شیان ووایم چې بل سړی به یې ونه ویل شي او دا چې رییس شاید اوریدل خوښ نه کړي. . زه دوی ته وایم چې د دوی په شرکت کې خنډ یو څوک دی چې فریډ نومیږي او یو څوک لو نومیږي. دا خنډ باید خلاص شي، د دوی پوهه باید له دوی څخه یو یا بل ډول ترلاسه شي.
د دې ډول ستونزې حل کولو لپاره، زه کولی شم، د بیلګې په توګه، د Slack کارولو وړاندیز وکړم. یو هوښیار رییس به پوښتنه وکړي - ولې؟ عموما، په داسې قضیو کې، د DevOps مشاورین ځواب ورکوي: ځکه چې هرڅوک دا کوي. که رییس رښتیا هوښیار وي، هغه به ووایي: نو څه. او دا هغه ځای دی چې خبرې اترې پای ته رسیږي. او دې ته زما ځواب دا دی: ځکه چې په شرکت کې څلور خنډونه شتون لري، فریډ، لو، سوسي او جین. د دوی د پوهې بنسټیز کولو لپاره، یو څوک باید لومړی سلیک معرفي کړي. ستاسو ټول ویکي په بشپړ ډول بې بنسټه دي ځکه چې هیڅوک د دوی د شتون په اړه نه پوهیږي. که چیرې د انجینرۍ ټیم د مخکینۍ پای او شاته پای پراختیا کې ښکیل وي او هرڅوک اړتیا لري پوه شي چې دوی کولی شي د مخکښې پای پرمختیا ټیم یا زیربنایی ټیم سره د پوښتنو سره اړیکه ونیسي. دا هغه وخت دی چې لو یا فریډ به شاید د ویکي سره د یوځای کیدو وخت ولري. او بیا په سلیک کې یو څوک ممکن پوښتنه وکړي چې ولې، ووایاست، 5 ګام کار نه کوي. او بیا لو یا فریډ به په ویکي کې لارښوونې سم کړي. که تاسو دا پروسه جوړه کړئ، نو ډیری شیان به په خپل ځای کې راشي.
دا زما اصلي ټکی دی: د هرې لوړې ټیکنالوژۍ وړاندیز کولو لپاره ، تاسو باید لومړی د دوی لپاره اساس تنظیم کړئ ، او دا د ټیټ ټیک حلونو سره ترسره کیدی شي چې یوازې تشریح شوي. که تاسو د لوړ ټیکنالوژیو سره پیل کوئ او تشریح نه کړئ چې ولې دوی ورته اړتیا لري، نو د یوې قاعدې په توګه، دا ښه پای ته نه رسیږي. زموږ یو پیرودونکي Azure ML کاروي، یو خورا ارزانه او ساده حل. د دوی شاوخوا 30٪ پوښتنې پخپله د ځان زده کړې ماشین لخوا ځواب شوي. او دا شی د آپریټرانو لخوا لیکل شوی و چې د ډیټا ساینس، احصایې یا ریاضیاتو کې ښکیل نه وو. دا د پام وړ دی. د داسې حل لګښت لږ تر لږه دی.
4. د همکارۍ هیکونه: د همکارۍ هیکونه
څلورم لرغونتوب د انزوا سره د مبارزې اړتیا ده. ډیری خلک دمخه پدې پوهیږي: انزوا د دښمنۍ نسل کوي. که هره څانګه په خپل پوړ کې وي او خلک د لفټ پرته په هیڅ ډول یو له بل سره متقابل نه وي، نو د دوی ترمنځ دښمني په اسانۍ سره رامینځته کیږي. مګر که، برعکس، خلک د یو بل سره په ورته خونه کې وي، هغه سمدستي پریږدي. کله چې یو څوک یو څه عمومي تورونه وغورځوي، د بیلګې په توګه، داسې او داسې یو انټرفیس هیڅکله کار نه کوي، د داسې تورونو له مینځه وړلو لپاره هیڅ شی اسانه ندي. هغه برنامه کونکي چې انٹرفیس یې لیکلی یوازې اړتیا لري د ځانګړو پوښتنو پوښتنه پیل کړي ، او دا به ډیر ژر روښانه شي چې د مثال په توګه ، کارونکي په ساده ډول وسیله په غلط ډول کارولې.
د انزوا له منځه وړلو لپاره ډیری لارې شتون لري. یو ځل له ما څخه وغوښتل شول چې په اسټرالیا کې د یوه بانک لپاره مشوره وکړم، خو ما له دې کولو انکار وکړ ځکه چې زه دوه ماشومان او یوه ښځه لرم. ټول هغه څه چې زه یې کولی شم د دوی سره مرسته وکړم د ګرافیکي کیسې ویلو وړاندیز وکړم. دا هغه څه دي چې د کار کولو لپاره ثابت شوي. بله په زړه پورې لاره د لیون کافي ناستې دي. په یوه لوی سازمان کې، دا د پوهې خپرولو لپاره غوره انتخاب دی. سربیره پردې ، تاسو کولی شئ داخلي وقفې ورځې ، هیکاتون او داسې نور ترسره کړئ.
5. د کاتا کوچ کول
لکه څنګه چې ما په پیل کې خبرداری ورکړ، زه به نن ورځ پدې اړه خبرې ونه کړم. که تاسو علاقه لرئ، تاسو کولی شئ یو نظر وګورئ .
په دې موضوع د مایک روتر څخه ښه خبرې هم شتون لري:
6. د بازار په لور: د بازار په لور سازمان
دلته بیلابیلې ستونزې شتون لري. د مثال په توګه، "I" خلک، "T" خلک او "E" خلک. "زه" هغه خلک دي چې یوازې یو کار کوي. معمولا دوی په سازمانونو کې شتون لري چې جلا څانګې لري. "T" هغه وخت دی چې یو څوک په یو شی کې ښه وي مګر په نورو شیانو کې هم ښه وي. "ای" یا حتی "کنګ" هغه وخت دی کله چې یو څوک ډیری مهارتونه ولري.
د کانوی قانون دلته کار کوي ()، کوم چې په خورا ساده بڼه کې په لاندې ډول ویل کیدی شي: که چیرې درې ټیمونه په کمپیلر کار وکړي، نو پایله به د دریو برخو تالیف کونکی وي. له همدې امله ، که چیرې په یوه اداره کې د لوړې کچې انزوا شتون ولري ، نو حتی په دې سازمان کې کوبرنیټس ، سرکټ بریکر ، د API توسعیت او نور په زړه پوري شیان به د سازمان په څیر تنظیم شي. په کلکه د کانوی په وینا او تاسو ټولو ځوان ګیکانو ته سپکاوی وکړئ.
د دې ستونزې حل څو ځله تشریح شوی. د بیلګې په توګه، د فرناندو فرنانډیز لخوا تشریح شوي سازماني لرغونتوب شتون لري. دا ستونزه لرونکی معمار چې ما یوازې په اړه خبرې وکړې، د انزوا سره، د فعالیت پر بنسټ معمار دی. دوهم ډول ترټولو خراب دی، د میټرکس جوړښت، د نورو دوو ګډوډۍ. دریم هغه څه دي چې په ډیری پیلونو کې لیدل کیږي، او لوی شرکتونه هم هڅه کوي چې دا ډول سره سمون ولري. دا یو بازار لرونکی سازمان دی. دلته موږ د پیرودونکو غوښتنو ته د ګړندي ځواب ترلاسه کولو لپاره غوره کوو. دا ځینې وختونه د فلیټ سازمان په نوم یادیږي.
ډیری خلک دا جوړښت په بیلابیلو لارو تشریح کوي، زه د کلمې خوښوم ټیمونه جوړول / چلول، په ایمیزون کې دوی ورته غږ کوي دوه پیزا ټیمونه. په دې جوړښت کې، ټول "I" خلک د یو خدمت په شاوخوا کې ګروپ شوي، او ورو ورو دوی "T" ډول ته نږدې کیږي، او که سم مدیریت شتون ولري، دوی حتی "E" کیدی شي. دلته لومړی ضد دلیل دا دی چې دا ډول جوړښت غیر ضروري عناصر لري. تاسو ولې په هره څانګه کې ټیسټر ته اړتیا لرئ که تاسو د ازموینو ځانګړې څانګه لرئ؟ کوم ته چې زه ځواب ورکوم: پدې قضیه کې اضافي لګښتونه د ټولې ادارې قیمت دی چې په راتلونکي کې "E" ډول شي. په دې جوړښت کې، ټیسټر په تدریجي ډول د شبکې، جوړښت، ډیزاین او نورو په اړه زده کړه کوي. د پایلې په توګه، په سازمان کې هر ګډون کوونکی د هر هغه څه څخه په بشپړه توګه خبر دی چې په سازمان کې پیښیږي. که تاسو غواړئ پوه شئ چې دا سکیم په صنعت کې څنګه کار کوي، ولولئ .
7. کیڼ اړخ ته شفټ پلټونکي: د دورې په پیل کې پلټنه. په نندارتون کې د خوندیتوب قواعدو سره موافقت
دا هغه وخت دی چې ستاسو کړنې د بوی ازموینه نه تیریږي، نو د خبرو کولو لپاره. هغه خلک چې ستاسو لپاره کار کوي احمق نه دي. که، لکه څنګه چې په پورته مثال کې، دوی په هر ځای کې لږ/هیڅ اغیزه جوړه کړه، دا درې کاله دوام وکړ، او هیچا هیڅ هم ونه لیدل، نو هرڅوک ښه پوهیږي چې سیسټم کار نه کوي. یا بله بیلګه - د بدلون مشورتي بورډ، چیرې چې راپورونه باید د چهارشنبې په ورځ وړاندې شي. د خلکو یوه ډله شتون لري چې هلته کار کوي (ډیر ښه معاش نلري، په لاره کې) څوک چې په تیوري کې باید پوه شي چې سیسټم څنګه په بشپړ ډول کار کوي. او په تیرو پنځو کلونو کې، تاسو شاید لیدلي وي چې زموږ سیسټمونه خورا پیچلي دي. او پنځه یا شپږ کسان باید د هغه بدلون په اړه پریکړه وکړي چې دوی ندي کړي او په اړه یې هیڅ نه پوهیږي.
البته، دا طریقه کار نه کوي. زه باید له داسې شیانو څخه ځان خلاص کړم ځکه چې دا خلک د نظام ساتنه نه کوي. پریکړه باید پخپله ټیم وکړي، ځکه چې ټیم باید د هغې لپاره مسؤل وي. که نه نو، یو متضاد حالت رامینځته کیږي کله چې یو مدیر چې هیڅکله یې په خپل ژوند کې کوډ نه دی لیکلی، پروګرامر ته ووایي چې د کوډ لیکلو لپاره څومره وخت نیسي. یو شرکت چې ما ورسره کار کاوه 7 مختلف بورډونه درلودل چې هر بدلون بیاکتنه کوي، پشمول د معمارۍ بورډ، د محصول بورډ، او نور. حتی د انتظار یوه لازمي دوره هم وه، که څه هم یو کارمند ما ته وویل چې په لس کلن کار کې، هیڅوک هیڅکله د دې اجباري دورې په جریان کې د دې شخص لخوا بدلون نه دی رد کړی.
اوریدونکي باید له موږ سره یوځای کیدو ته بلنه ورکړل شي، او له دوی څخه لرې نه شي. دوی ته ووایاست چې تاسو د بدلیدونکي بائنری کانټینرونه ولیکئ چې که دوی ټولې ازموینې تیرې کړي ، د تل لپاره غیر متغیر پاتې کیږي. دوی ته ووایاست چې تاسو د کوډ په توګه پایپ لاین لرئ او تشریح کړئ چې دا څه معنی لري. دوی ته لاندې سکیم وښایاست: په یو کانټینر کې د نه بدلیدونکي یوازې لوستلو بائنری چې د زیان مننې ټولې ازموینې تیریږي؛ او بیا نه یوازې دا چې هیڅوک یې لمس نه کوي ، دوی حتی هغه سیسټم ته لاس نه ورکوي چې پایپ لاین رامینځته کوي ، ځکه چې دا هم په متحرک ډول رامینځته شوی. زه پیرودونکي لرم، Capital One، څوک چې د بلاکچین په څیر یو څه رامینځته کولو لپاره والټ کاروي. پلټونکی اړتیا نلري د شیف څخه "ترکیبونه" وښیې؛ دا د بلاکچین ښودلو لپاره کافي دي ، له کوم څخه چې دا روښانه کیږي چې په تولید کې د جیرا ټیکټ سره څه پیښ شوي او څوک یې مسؤل دي.
د ، په 2018 کې د سونټایپ لخوا رامینځته شوی ، په 2017 کې د 87 ملیارد OSS ډاونلوډ غوښتنې وې.
د زیان منونکو زیانونو له امله رامینځته شوي زیانونه منع دي. سربیره پردې ، هغه ارقام چې تاسو یې اوس پورته ګورئ د فرصت لګښتونه پکې شامل ندي. په لنډه توګه DevSecOps څه شی دی؟ اجازه راکړئ سمدلاسه ووایم چې زه د دې خبرې سره علاقه نه لرم چې دا نوم څومره بریالی دی. ټکی دا دی چې له هغه وخته چې DevOps ډیر بریالي شوي، موږ باید هڅه وکړو چې دې پایپ لاین ته امنیت اضافه کړو.
د دې لړۍ یوه بیلګه:
دا د ځانګړو محصولاتو لپاره سپارښتنه نه ده، که څه هم زه دا ټول خوښوم. ما دوی ته د مثال په توګه اشاره وکړه ترڅو وښیې چې DevOps ، کوم چې په پیل کې په صنعت کې د تنظیمي تمثیل پراساس و ، تاسو ته اجازه درکوي په محصول کې د کار هرې مرحلې اتومات کړئ.
او هیڅ دلیل شتون نلري چې موږ د امنیت لپاره ورته چلند نشو کولی.
نتیجه
د پایلې په توګه، زه به د DevSecOps لپاره ځینې لارښوونې ورکړم. تاسو اړتیا لرئ د خپل سیسټمونو رامینځته کولو په پروسه کې پلټونکي شامل کړئ او د دوی په زده کړه کې وخت مصرف کړئ. تاسو اړتیا لرئ د پلټونکو سره همکاري وکړئ. بیا ، تاسو اړتیا لرئ د غلط مثبتو پروړاندې په بشپړ ډول بې رحمه مبارزه وکړئ. حتی د خورا قیمتي زیان مننې سکین کولو وسیلې سره ، تاسو کولی شئ د خپلو پراختیا کونکو ترمینځ خورا بد عادتونه رامینځته کړئ که تاسو نه پوهیږئ ستاسو د سیګنال څخه تر شور تناسب څه دی. پراختیا کونکي به د پیښو سره ډوب شي او په ساده ډول به یې حذف کړي. که تاسو د Equifax کیسه په اړه اوریدلي وي، دا خورا ډیر څه دي چې هلته پیښ شوي، چیرې چې د خبرتیا لوړه کچه له پامه غورځول شوې وه. برسېره پردې، زیانمننې باید په داسې طریقه تشریح شي چې دا روښانه کړي چې دوی څنګه په سوداګرۍ اغیزه کوي. د مثال په توګه، تاسو کولی شئ ووایاست چې دا د Equifax کیسه کې ورته ورته زیان دی. د امنیت زیانمننې باید د نورو سافټویر مسلو په څیر چلند وشي، دا دی، دوی باید د ټول DevOps پروسې کې شامل شي. تاسو اړتیا لرئ د جیرا ، کنبان او نورو له لارې له دوی سره کار وکړئ. پراختیا کونکي باید فکر ونه کړي چې بل څوک به دا کار وکړي - برعکس، هرڅوک باید دا وکړي. په نهایت کې ، تاسو اړتیا لرئ د خلکو په روزنه کې انرژي مصرف کړئ.
ګټور لینکونه
دلته د DevOops کنفرانس څخه یو څو خبرې دي چې ممکن تاسو ګټور ومومئ:
- سرګي برډنیکوف، آرتیوم کالیچکین - د بریالیتوب کیسه، یا "Dev+DevOps+Ops" (, )
- باروچ سادوګورسکي، لیونید ایګولنیک - دیو اوپس په پیمانه: په دریو اعمالو کې د یونان تراژیدي (, )
- الکساندر تیتوف، کیریل تولکاچوف -
- تیموتی لیسټر -
ورته ځير شه DevOops 2020 مسکو - دلته ډیر په زړه پوري شیان هم شتون لري.
سرچینه: www.habr.com