په اوس وخت کې، دا په بازار کې نږدې ترټولو ګران موقعیت دی. د "DevOps" انجنیرانو شاوخوا ګډوډي د ټولو تصور وړ حدونو څخه بهر ده، او حتی د لوړ پوړو DevOps انجنیرانو سره بدتر دی.
زه د ادغام او اتومات څانګې د رییس په توګه کار کوم، د انګلیسي کوډ کولو اټکل وکړئ - DevOps مدیر. دا امکان نلري چې د انګلیسي لیږد زموږ ورځني فعالیتونه منعکس کړي، مګر پدې حالت کې د روسیې نسخه خورا دقیقه ده. زما د فعالیت د نوعیت له امله، طبیعي ده چې زه باید د خپل ټیم راتلونکو غړو سره مرکې وکړم، او په تیر کال کې، شاوخوا 50 کسان زما له لارې تیر شوي، او همدومره شمیر زما د کارمندانو سره په پرده کې پرې شوي.
موږ لاهم د همکارانو په لټه کې یو ، ځکه چې د DevOps لیبل شاته د مختلف ډوله انجینرانو خورا لوی پرت پټ دی.
دا هر څه چې لاندې لیکل شوي زما شخصي نظر دی، تاسو باید ورسره موافق نه یاست، مګر زه دا منم چې دا به موضوع ته ستاسو چلند ته یو څه رنګ ورکړي. د حق څخه د وتلو خطر سره سره، زه خپل نظر خپروم ځکه چې زه باور لرم چې دا یو ځای لري.
شرکتونه مختلف پوهه لري چې د DevOps انجینران څوک دي او د ګړندي سرچینې استخدام لپاره ، دوی دا لیبل په هرچا ځړوي. وضعیت خورا عجیب دی، ځکه چې شرکتونه چمتو دي چې دې خلکو ته غیر حقیقي معاش ورکړي، په ډیرو مواردو کې، د دوی لپاره د وسیلې مدیر ترلاسه کوي.
نو د DevOps انجنیران څوک دي؟
راځئ چې د هغې د ظهور تاریخ سره پیل وکړو - د پراختیا عملیات په وړو ټیمونو کې د متقابل عمل د ښه کولو په لور د بل ګام په توګه راڅرګند شول ترڅو د محصول تولید سرعت زیات کړي، د متوقع پایلې په توګه. نظر دا و چې د محصول چاپیریال اداره کولو کې د پروسیجرونو او چلندونو پوهه سره پراختیایی ټیم پیاوړی کړي. په بل عبارت، پرمخ وړونکی باید پوه شي او پوه شي چې د هغه محصول په ځینو شرایطو کې څنګه کار کوي، باید پوه شي چې څنګه خپل محصول ځای په ځای کړي، د چاپیریال کوم ځانګړتیاوې د فعالیت ښه کولو لپاره تنظیم کیدی شي. نو، د یو څه وخت لپاره، د DevOps چلند سره پراختیا کونکي ښکاره شول. د DevOps پراختیا کونکو د دوی فعالیتونه او د تولید چاپیریال فعالیت ساده کولو لپاره د جوړولو او بسته کولو سکریپټونه لیکلي. په هرصورت، د حل جوړښت پیچلتیا او د وخت په تیریدو سره د زیربناوو اجزاو متقابل نفوذ د چاپیریال فعالیت خرابول پیل کړل؛ د هر تکرار سره، د ځینو اجزاوو په زیاتیدونکي توګه ژور پوهاوی ته اړتیا وه، د اضافي اضافو له امله د پراختیا کونکي تولید کمول. د یوې ځانګړې دندې لپاره د اجزاوو او سیسټمونو د پوهیدو لګښتونه. د پراختیا کونکي خپل لګښت لوړ شو، د دې سره د محصول لګښت، په ټیم کې د نویو پراختیا کونکو اړتیاوې په چټکۍ سره پورته شوې، ځکه چې دوی د "ستوري" پراختیا مسؤلیتونو پوښلو ته هم اړتیا درلوده او په طبیعي توګه، "ستوري" کم شوي. او لږ شتون لري. دا هم د یادولو وړ ده چې زما په تجربه کې، یو څو پراختیا کونکي د عملیاتي سیسټم کرنل، د پاکټ روټینګ قواعد، او د کوربه امنیتي اړخونو لخوا د پاکټ پروسس کولو ځانګړتیاو سره علاقه لري. منطقي ګام دا و چې یو مدیر راجلب کړي چې له دې سره آشنا وي او ورته ورته مسؤلیتونه وټاکي، کوم چې د هغه تجربې څخه مننه، د "ستوري" پراختیا لګښت په پرتله په ټیټ لګښت کې ورته شاخصونه ترلاسه کول ممکن کړي. دا ډول مدیران په ټیم کې ځای په ځای شوي او د هغه اصلي دنده دا وه چې د ازموینې او تولید چاپیریال اداره کړي ، د ځانګړي ټیم قواعدو سره سم ، دې ځانګړي ټیم ته ځانګړي شوي سرچینې سره. دا څنګه، په حقیقت کې، DevOps د اکثریت په ذهنونو کې ښکاره شول.
په جزوي یا بشپړ ډول ، د وخت په تیریدو سره ، د دې سیسټم مدیرانو د پراختیا په برخه کې د دې ځانګړي ټیم اړتیاو باندې پوهیدل پیل کړل ، چې څنګه د پراختیا کونکو او ازموینو لپاره ژوند اسانه کړي ، څنګه تازه معلومات رامینځته کړي او د جمعې په ورځ د شپې پاتې کیدو ته اړتیا نلري. دفتر، د ګمارنې تېروتنې سمول. وخت تېر شو، او اوس "ستوري" د سیسټم مدیران وو چې پوهیدل چې پراختیا کونکي څه غواړي. د اغیزو کمولو لپاره، د مدیریت اسانتیاوې راڅرګندې شوې؛ هرڅوک د OS کچې جلا کولو زاړه او باوري میتودونه یاد کړل، کوم چې د امنیت، د شبکې برخې مدیریت، او د کوربه ترتیباتو لپاره د اړتیاو کمولو امکان برابر کړ. ټول او په پایله کې، د نوي "ستوري" اړتیاوې کموي.
یو "په زړه پوری" شی څرګند شو - ډاکر. ولې په زړه پورې؟ هو ، یوازې د دې لپاره چې په کروټ یا جیل کې د انزوا رامینځته کول ، په بیله بیا OpenVZ ، د OS غیر معمولي پوهه ته اړتیا لري ، په مقابل کې ، افادیت تاسو ته اجازه درکوي په ساده ډول په یو ځانګړي کوربه کې د جلا غوښتنلیک چاپیریال رامینځته کړئ هر څه چې دننه او لاس ته اړتیا لري. یو ځل بیا د پراختیا په سر کې، او د سیسټم مدیر کولی شي یوازې د یو کوربه سره اداره کړي، د هغې امنیت او لوړ شتون ډاډمن کړي - یو منطقي ساده کول. خو پرمختګ په ټپه ولاړ نه دی او سیسټمونه بیا ورځ تر بلې پیچلې کیږي، ډیرې برخې شتون لري، یو کوربه نور د سیسټم اړتیاوې نه پوره کوي او د کلسترونو جوړولو ته اړتیا ده، موږ بیا د سیسټم مدیرانو ته راستانه کیږو چې څوک دي. د دې سیسټمونو د جوړولو توان لري.
د سایکل وروسته ، مختلف سیسټمونه څرګندیږي چې پراختیا او / یا اداره ساده کوي ، د آرکیسټریشن سیسټمونه څرګندیږي ، کوم چې تر هغه وخته پورې چې تاسو اړتیا لرئ د معیاري پروسې څخه انحراف وکړئ ، کارول اسانه دي. د مایکرو سرویس جوړښت هم د پورته تشریح شوي هرڅه ساده کولو هدف سره څرګند شو - لږ اړیکې ، اداره کول اسانه دي. زما په تجربه کې، ما په بشپړه توګه د مایکرو سرویس جوړښت ونه موندل، زه به ووایم چې د 50 څخه تر 50 - 50 سلنې مایکرو خدمتونه، تور بکسونه، دننه راغلل، پروسس شوي، نور 50 یو مات شوي مونولیت دي، خدمتونه نشي کولی له نورو څخه جلا کار وکړي. اجزا. دا ټول بیا د پراختیا کونکو او مدیرانو د پوهې په کچه محدودیتونه وضع کوي.
د یوې ځانګړې سرچینې په اړه د متخصص پوهې په کچه کې ورته "سنګونه" تر نن ورځې دوام لري. مګر موږ لږ څه انحراف کوو، ډیری ټکي شتون لري چې د روښانه کولو وړ دي.
انجینر جوړ کړئ / د خوشې کولو انجینر
خورا لوړ تخصصي انجینران چې د سافټویر جوړونې پروسې او ریلیزونو معیاري کولو وسیلې په توګه راپورته شوي. د پراخه ایجیل معرفي کولو په پروسه کې ، داسې بریښي چې دوی په غوښتنې کې پاتې راغلي ، مګر دا له قضیې څخه لرې ده. دا تخصص په صنعتي پیمانه د سافټویر راټولولو او تحویلي معیاري کولو وسیلې په توګه څرګند شو ، د بیلګې په توګه. د ټولو شرکتونو محصولاتو لپاره د معیاري تخنیکونو کارول. د DevOps په راتګ سره، پراختیا کونکو په یوه برخه کې خپلې دندې له لاسه ورکړې، ځکه چې دا پراختیا کونکي وو چې د تحویل لپاره یې محصول چمتو کول پیل کړل، او د بدلیدونکي زیربنا او د کیفیت په پام کې نیولو پرته د ژر تر ژره وړاندې کولو طریقه، د وخت په تیریدو سره دوی بدل شول. د بدلونونو مخه نیسي، ځکه چې د کیفیت معیارونو ته غاړه ایښودل په حتمي ډول د تحویلۍ سست کوي. نو، په تدریجي ډول، د ساختمان / ریلیز انجنیرانو د فعالیت یوه برخه د سیسټم مدیرانو اوږو ته لیږدول شوې.
عملیات ډیر توپیر لري
موږ بیا حرکت کوو او د لوی مسؤلیتونو شتون او د وړ پرسونل نشتوالی موږ د سخت تخصص په لور هڅوي، لکه د باران وروسته د چرګانو په څیر، مختلف عملیات څرګندیږي:
- TechOps - enikey system administrators aka HelpDesk Engineer
- LiveOps - د سیسټم مدیران په عمده ډول د تولید چاپیریال لپاره مسؤل دي
- CloudOps - د سیسټم مدیران چې په عامه بادلونو کې تخصص لري Azure، AWS، GCP، او نور.
- PlatOps/InfraOps/SysOps - د زیربنا سیسټم مدیران.
- NetOps - د شبکې مدیران
- SecOps - د سیسټم مدیران چې د معلوماتو امنیت کې تخصص لري - د PCI اطاعت، د CIS اطاعت، پیچ کول، او نور.
DevOps (په تیوري کې) یو څوک دی چې د پراختیا دورې ټولې پروسې په لومړي سر کې پوهیږي - پراختیا ، ازموینه ، د محصول جوړښت پوهیږي ، د امنیت خطرونو ارزولو وړ دی ، د چلند او اتومات وسیلو سره آشنا دی ، لږترلږه په لوړه کچه. کچه، د دې سربیره، د پروسس کولو دمخه او وروسته د محصول خوشې کولو مالتړ هم پوهیږي. یو شخص چې د دواړو عملیاتو او پراختیا لپاره د مدافع وکیل په توګه کار کولو وړتیا لري، کوم چې د دې دوو ستنو ترمنځ د مناسبې همکارۍ لپاره اجازه ورکوي. د ټیمونو لخوا د پلان کولو کار کولو پروسې او د پیرودونکو توقعاتو اداره کول پوهیږي.
د دې ډول کار او مسؤلیتونو د ترسره کولو لپاره، دا شخص باید وسیلې ولري چې نه یوازې د پراختیا او ازموینې پروسې اداره کړي، بلکه د محصول زیربنا مدیریت، او همدارنګه د سرچینو پالن جوړونه. په دې تفاهم کې DevOps نه په IT کې موقعیت لري، یا په R&D کې، یا حتی په PMO کې؛ دا باید په دې ټولو برخو کې نفوذ ولري - د شرکت تخنیکي رییس، لوی تخنیکي افسر.
ایا دا ستاسو په شرکت کې ریښتیا ده؟ - زه شک لرم. په ډیرو مواردو کې، دا یا IT یا R&D دی.
د بودیجې نشتوالی او د فعالیت له دې دریو برخو څخه لږ تر لږه یوه باندې د نفوذ کولو وړتیا به د ستونزو وزن هغه ځای ته واړوي چیرې چې دا بدلونونه پلي کول اسانه دي ، لکه د جامد سره سم د "ناپاکو" کوډ سره په اړیکه کې په خپرونو کې د تخنیکي محدودیتونو پلي کول. د تحلیل سیسټمونه دا دی، کله چې PMO د فعالیت د خوشې کولو لپاره سخته نیټه ټاکي، R&D نشي کولی د دې نیټې په اوږدو کې د لوړ کیفیت پایلې تولید کړي او دا چې څومره یې کولی شي تولید کړي، د بیاکتنې لپاره وروسته پاتې کیږي، د IT پورې اړوند DevOps د تخنیکي وسیلو لخوا خوشې کول بندوي. . د وضعیت د بدلون لپاره د واک نشتوالی، د مسؤل کارمندانو په قضیه کې، د هغه څه لپاره د لوړ مسؤلیت څرګندولو لامل کیږي چې دوی نشي کولی اغیزه وکړي، په ځانګړې توګه که چیرې دا کارمندان پوه شي او غلطی وګوري، او څنګه یې سم کړي - "خوشحالي ناپوهي ده"، او په پایله کې د دې کارمندانو سوځول او له لاسه ورکول.
د DevOps سرچینو بازار
راځئ چې د مختلف شرکتونو څخه د DevOps پوستونو لپاره څو خالي بستونه وګورو.
موږ له تاسو سره لیدو ته چمتو یو که تاسو:
- تاسو زبیکس لرئ او پوهیږئ چې پرومیتیس څه شی دی؛
- iptables;
- د BASH PhD زده کوونکی؛
- پروفیسور ځواب ورکوونکی؛
- لینوکس گرو؛
- پوهیږئ چې څنګه د ډیبګ کولو کارول او د پراختیا کونکو سره یوځای د غوښتنلیک ستونزې ومومئ (php/java/python)؛
- روټینګ تاسو هیسټریکل نه کوي؛
- د سیسټم امنیت ته د پام وړ پاملرنه وکړئ؛
- د "هر څه او هرڅه" بیک اپ کړئ، او همدارنګه په بریالیتوب سره دا "هر څه او هرڅه" بحال کړئ؛
- تاسو پوهیږئ چې څنګه سیسټم په داسې ډول تنظیم کړئ چې له لږترلږه څخه اعظمي ترلاسه کړئ؛
- په Postgres او MySQL کې ویده کیدو دمخه نقل ترتیب کړئ؛
- د CI/CD ترتیب او تنظیم کول ستاسو لپاره د سهار / غرمې / ډوډۍ په څیر اړین دي.
- د AWS سره تجربه ولرئ؛
- د شرکت سره پرمختګ ته چمتو؛
نو:
- له 1 څخه تر 6 پورې - د سیسټم مدیر
- 7 - د شبکې کوچنۍ اداره، کوم چې د سیسټم مدیر، منځنۍ کچې سره هم سمون لري
- 8 - لږ امنیت، کوم چې د منځنۍ کچې سیسټم مدیر لپاره لازمي دی
- 9-11 - د منځني سیسټم مدیر
- 12 — په ټاکل شوي دندو پورې اړه لري، یا د منځني سیسټم مدیر یا جوړونکي انجنیر
- 13 - مجازی کول - د منځني سیسټم مدیر، یا د CloudOps په نامه یادېږي، د ځانګړي کوربه کولو سایټ د خدماتو پرمختللی پوهه، د فنډونو اغیزمن استعمال او د ساتنې بار کمولو لپاره
د دې خالي ځای لنډیز کول، موږ کولی شو ووایو چې د منځني / لوړ سیسټم مدیر د هلکانو لپاره کافي دی.
په لاره کې، تاسو باید په لینوکس / وینډوز کې مدیران په کلکه ونه ویشئ. البته زه پوهیږم چې د دې دواړو نړۍ خدمتونه او سیسټمونه سره توپیر لري، مګر د ټولو اساسات یو دي او هر یو باعزته اداره د یو او بل سره پیژني او حتی که هغه نه وي، نو دا به هم وي. د وړ مدیر لپاره ستونزمن نه وي چې ورسره آشنا شي.
راځئ چې یو بل خالي ځای په پام کې ونیسو:
- د لوړ بار سیسټمونو په جوړولو کې تجربه؛
- د لینکس OS عالي پوهه ، د عمومي سیسټم سافټویر او ویب سټیک (Nginx، PHP/Python، HAProxy، MySQL/PostgreSQL، Memcached، Redis، RabbitMQ، ELK)؛
- د مجازی سیسټمونو سره تجربه (KVM، VMWare، LXC/Docker)؛
- د سکریپټ ژبو مهارت؛
- د شبکې پروتوکول شبکې عملیاتي اصولو پوهه؛
- د غلطیو زغمونکي سیسټمونو جوړولو اصولو پوهیدل؛
- خپلواکي او نوښت؛
راځئ چې وګورو:
- 1 – د سیسټم لوړ پوړی مدیر
- 2 - د معنی پورې اړه لري چې پدې سټیک کې ایښودل شوي - د مینځني / لوړ سیسټم مدیر
- 3 - د کار تجربه، په شمول، کیدای شي پدې معنی وي - "کلستر پورته نه شو، مګر مجازی ماشینونه جوړ او اداره کول، یو ډاکر کوربه و، کانټینرونو ته لاسرسی شتون نلري" - د منځني سیسټم مدیر
- 4 - د جونییر سیسټم مدیر - هو، یو مدیر چې نه پوهیږي چې څنګه د لومړني اتومات سکریپټ لیکلو څرنګوالی، د ژبې په پام کې نیولو پرته، مدیر نه - enikey.
- ۵ – د منځني نظام مدیر
- 6 – د سیسټم لوړ پوړی مدیر
د لنډیز کولو لپاره - منځنی / لوړ سیسټم مدیر
بل یو:
- تجربه کول؛
- د CI/CD پروسو رامینځته کولو لپاره د یو یا ډیرو محصولاتو کارولو تجربه. Gitlab CI به یوه ګټه وي؛
- د کانټینرونو او مجازی کولو سره کار کول؛ که تاسو ډاکر کاروئ، ښه، مګر که تاسو k8s کارولی وي، ښه!
- په ځیرک ټیم کې د کار کولو تجربه؛
- د هرې برنامې ژبې پوهه؛
راځئ چې وګورو:
- 1 - هوم ... هلکان څه معنی لري؟ =) ډیری احتمال دوی پخپله نه پوهیږي چې د هغې تر شا څه پټ دي
- ۲ – د انجنیرۍ جوړول
- ۵ – د منځني نظام مدیر
- 4 - نرم مهارت، موږ به یې د اوس لپاره په پام کې ونیسو، که څه هم چټک یو بل شی دی چې په مناسب ډول تشریح کیږي.
- 5 - ډیر لفظي - دا کیدای شي د سکریپټ ژبه وي یا یو تالیف شوی وي. زه حیران یم چې ایا په ښوونځي کې د پاسکال او اساسی لیکل به دوی ته مناسب وي؟ =)
زه غواړم د 3 ټکي په اړه یو یادداشت هم پریږدم ترڅو پوه شي چې ولې دا ټکی د سیسټم مدیر لخوا پوښل شوی. کوبرنیټس یوازې یو آرکیسټریشن دی ، یوه وسیله چې د شبکې ډرایورانو او مجازی کولو / انزوا کوربه توب ته مستقیم قوماندې په یو څو کمانډونو کې پوښي او تاسو ته اجازه درکوي له دوی سره خلاصې اړیکې رامینځته کړئ ، بس. د مثال په توګه، راځئ چې د چوکاټ جوړونه واخلو، کوم چې، په لاره کې، زه یو چوکاټ په پام کې نه لرم. هو، زه په هر ځای کې د جوړیدو د فیشن په اړه پوهیږم، چیرته چې دا اړینه ده او اړتیا نلري - په میک کې د ماون لپاسه، د بیلګې په توګه، په جدي توګه؟
په لازمي ډول ، میک په شیل کې یوازې یو ریپر دی ، د k8s په څیر د تالیف ، لینک کولو ، او تالیف چاپیریال کمانډونه ساده کوي.
یوځل ، ما د یو سړي سره مرکه وکړه چې د OpenStack په سر کې یې په خپل کار کې k8s کاروي ، او هغه پدې اړه خبرې وکړې چې څنګه یې پدې کې خدمات ځای په ځای کړي ، په هرصورت ، کله چې ما د OpenStack په اړه وپوښتل ، نو معلومه شوه چې دا اداره کیږي ، او همدارنګه د سیسټم لخوا پورته شوی. مدیران ایا تاسو واقعیا فکر کوئ چې یو څوک چې OpenStack نصب کړی ، پرته لدې چې هغه د هغه شاته کوم پلیټ فارم کاروي ، نشي کولی k8s وکاروي؟ =)
دا غوښتونکی واقعیا د DevOps نه دی ، مګر د سیسټم مدیر او د ډیر دقیق کیدو لپاره ، د کبرنیټس مدیر.
راځئ چې یو ځل بیا لنډیز وکړو - د منځني / لوړ سیسټم مدیر به د دوی لپاره کافي وي.
په ګرام کې څومره وزن لري
د اشاره شوي خالي بستونو لپاره د وړاندیز شوي معاشونو سلسله 90k-200k ده
اوس زه غواړم د سیسټم مدیرانو او DevOps انجینرانو د پیسو انعامونو ترمینځ موازي رسم کړم.
په اصولو کې، د شیانو ساده کولو لپاره، تاسو کولی شئ د کاري تجربې پراساس درجې وویشئ، که څه هم دا به دقیق نه وي، مګر د مقالې موخو لپاره به کافي وي.
یوه تجربه:
- تر 3 کلونو پورې - ځوان
- تر 6 کلنۍ پورې - منځنی
- له 6 څخه ډیر - لوړ پوړی
د کارمند لټون سایټ وړاندیز کوي:
د سیسټم مدیران:
- جونیئر - 2 کاله - 50k روب.
- منځنۍ - 5 کاله - 70k روب.
- لوړ عمر - 11 کاله - 100k روب.
د DevOps انجینران:
- جونیئر - 2 کاله - 100k روب.
- منځنۍ - 3 کاله - 160k روب.
- لوړ عمر - 6 کاله - 220k روب.
د "DevOps" تجربې سره سم، تجربه کارول شوې وه چې لږترلږه یو څه په SDLC اغیزه کړې.
له پورته څخه دا پیروي کوي چې په حقیقت کې شرکتونه DevOps ته اړتیا نلري، او دا چې دوی کولی شي د مدیر په ګمارلو سره لږترلږه 50 سلنه لومړني پلان شوي لګښتونه خوندي کړي؛ سربیره پردې ، دوی کولی شي د هغه چا مسؤلیتونه په روښانه ډول تعریف کړي چې دوی یې په لټه کې دي. او اړتیا په چټکۍ سره ډک کړئ. موږ باید دا هم هیر نکړو چې د مسؤلیتونو روښانه ویش موږ ته اجازه راکوي چې د پرسونل اړتیاوې کمې کړو، په بیله بیا په ټیم کې یو ډیر مناسب فضا رامینځته کړو، د یو بل د نشتوالي له امله. ډیری خالي بستونه د اسانتیاو او DevOps لیبلونو څخه ډک دي ، مګر دا د DevOps انجینر لپاره د حقیقي اړتیاو پراساس ندي ، یوازې د وسیلې مدیر لپاره غوښتنه کوي.
د DevOps انجینرانو د روزنې پروسه هم یوازې د ځانګړو کارونو ، اسانتیاو یو سیټ پورې محدوده ده ، او د پروسو او د دوی انحصارونو عمومي پوهه نه وړاندې کوي. دا واقعیا ښه ده کله چې یو څوک کولی شي AWS EKS د Terraform په کارولو سره ځای په ځای کړي ، په دې کلستر کې د Fluentd sidecar او AWS ELK سټیک سره په 10 دقیقو کې د ننوتلو سیسټم لپاره ، په کنسول کې یوازې یوه کمانډ کاروي ، مګر که هغه نه پوهیږي د پروسس کولو اصول پخپله لاګونه او د هغه څه لپاره چې دوی ورته اړتیا لري ، که تاسو نه پوهیږئ چې څنګه په دوی باندې میټریک راټول کړئ او د خدماتو تخریب تعقیب کړئ ، نو بیا به هم ورته اینکي وي څوک چې پوهیږي چې څنګه ځینې اسانتیاوې وکاروي.
تقاضا، په هرصورت، اکمالات رامینځته کوي، او موږ د DevOps موقعیت لپاره خورا ډیر ګرم بازار ګورو، چیرې چې اړتیاوې د اصلي رول سره مطابقت نلري، مګر یوازې د سیسټم مدیرانو ته اجازه ورکوي چې ډیر عاید ترلاسه کړي.
نو دوی څوک دي؟ DevOps یا لالچی سیسټم مدیران؟ =)
څنګه ژوند ته دوام ورکړو؟
کارګمارونکي باید اړتیاوې په دقیق ډول تنظیم کړي او دقیقا هغه کسان وګوري چې اړتیا ورته لري، او د لیبل شاوخوا نه وغورځوي. تاسو نه پوهیږئ چې DevOps څه کوي - تاسو ورته اړتیا نلرئ پدې حالت کې.
کارګران - زده کړه. په دوامداره توګه خپله پوهه ښه کړئ، د پروسو ټولیز انځور وګورئ او خپل هدف ته لاره تعقیب کړئ. تاسو کولی شئ هغه څوک شئ چې تاسو یې غواړئ، تاسو باید یوازې هڅه وکړئ.
سرچینه: www.habr.com