هن وقت، هي بازار تي لڳ ڀڳ سڀ کان قيمتي پوزيشن آهي. “DevOps” انجنيئرن جي چوڌاري ڦرلٽ تمام تصوراتي حدن کان ٻاهر آهي، ۽ سينيئر DevOps انجنيئرن سان اڃا به بدتر آهي.
مان انٽيگريشن ۽ آٽوميشن ڊپارٽمينٽ جي سربراهه طور ڪم ڪريان ٿو، انگريزي ڊيڪوڊنگ جو اندازو لڳايو - DevOps مئنيجر. اهو ممڪن ناهي ته انگريزي ٽرانسڪرپٽ اسان جي روزاني سرگرمين کي ظاهر ڪري، پر هن معاملي ۾ روسي نسخو وڌيڪ صحيح آهي. منهنجي سرگرمي جي نوعيت جي ڪري، اهو قدرتي آهي ته مون کي پنهنجي ٽيم جي مستقبل جي ميمبرن سان انٽرويو ڪرڻ جي ضرورت آهي، ۽ گذريل سال جي دوران، تقريبا 50 ماڻهو مون وٽان گذريا آهن، ۽ اهو ئي تعداد منهنجي ملازمن سان پريس اسڪرين تي ڪٽيو ويو آهي.
اسان اڃا تائين ساٿين کي ڳولي رهيا آهيون، ڇاڪاڻ ته DevOps ليبل جي پويان مختلف قسم جي انجنيئرن جي هڪ تمام وڏي پرت لڪائي رهي آهي.
هيٺ ڏنل سڀ ڪجهه منهنجي ذاتي راءِ آهي، توهان جو ان سان متفق ٿيڻ ضروري ناهي، پر مان اعتراف ڪريان ٿو ته ان سان توهان جي موضوع ڏانهن روش ۾ ڪجهه رنگ ضرور شامل ٿيندو. حق کان ٻاهر ٿيڻ جي خطري جي باوجود، مان پنهنجي راء کي شايع ڪريان ٿو ڇاڪاڻ ته مون کي يقين آهي ته اهو هڪ جڳهه آهي.
ڪمپنيون مختلف سمجھن ٿيون ته ڪير DevOps انجنيئر آهن ۽، جلدي هڪ وسيلا کي ڀرتي ڪرڻ جي خاطر، اهي هن ليبل کي هر ڪنهن تي لٽڪائين ٿا. صورتحال بلڪل عجيب آهي، ڇو ته ڪمپنيون انهن ماڻهن کي غير حقيقي معاوضو ادا ڪرڻ لاء تيار آهن، وصول ڪن ٿا، اڪثر ڪيسن ۾، انهن لاء هڪ اوزار منتظم.
پوء ڪير آهن DevOps انجنيئر؟
اچو ته ان جي ظهور جي تاريخ سان شروع ڪريون - ترقي جي عملن جي پيداوار جي رفتار کي وڌائڻ لاء ننڍڙي ٽيمن ۾ رابطي کي بهتر ڪرڻ لاء هڪ ٻيو قدم طور ظاهر ٿيو، هڪ متوقع نتيجي جي طور تي. اهو خيال هو ته ترقياتي ٽيم کي مضبوط ڪرڻ جي طريقيڪار ۽ طريقن جي ڄاڻ سان پيداوار جي ماحول کي منظم ڪرڻ ۾. ٻين لفظن ۾، ڊولپر کي سمجهڻ گهرجي ۽ ڄاڻڻ گهرجي ته هن جي پيداوار ڪجهه حالتن ۾ ڪيئن ڪم ڪري ٿي، اهو سمجهڻ گهرجي ته هن جي پيداوار کي ڪيئن ترتيب ڏيڻ، ڪارڪردگي بهتر ڪرڻ لاء ماحول جي ڪهڙي خاصيتن کي ترتيب ڏئي سگهجي ٿو. تنهن ڪري، ڪجهه وقت لاء، ڊولپر هڪ DevOps طريقي سان ظاهر ٿيو. DevOps ڊولپرز انهن جي سرگرمين ۽ پيداوار جي ماحول جي ڪارڪردگي کي آسان ڪرڻ لاءِ تعمير ۽ پيڪنگنگ اسڪرپٽ لکيا. بهرحال، حل جي فن تعمير جي پيچيدگي ۽ بنيادي ڍانچي جي اجزاء جو باهمي اثر وقت سان گڏ ماحول جي ڪارڪردگي کي خراب ڪرڻ شروع ڪيو؛ هر هڪ ورهاڱي سان، ڪجهه اجزاء جي وڌندڙ گہرے سمجھڻ جي ضرورت هئي، اضافي اضافو سبب ڊولپر جي پيداوار کي گهٽائڻ. ھڪڙي خاص ڪم لاء اجزاء ۽ سرنگ سسٽم کي سمجھڻ جي قيمت. . ڊولپر جي پنهنجي قيمت وڌي وئي، پراڊڪٽ جي قيمت ان سان گڏ، ٽيم ۾ نون ڊولپرز جون گهرجون تيزيءَ سان وڌيون، ڇو ته انهن کي ”اسٽار“ ڊولپمينٽ جون ذميواريون به پوريون ڪرڻيون پيون ۽ قدرتي طور تي ”اسٽار“ گهٽ ٿي ويا. ۽ گهٽ دستياب. اهو پڻ قابل ذڪر آهي ته، منهنجي تجربي ۾، ڪجھ ڊولپرز پيڪٽ پروسيسنگ جي خاصيتن ۾ دلچسپي وٺندا آهن آپريٽنگ سسٽم ڪنييل، پيڪٽ جي رستي جي ضابطن، ۽ ميزبان سيڪيورٽي جا حصا. منطقي قدم هڪ منتظم کي راغب ڪرڻ هو جيڪو هن سان واقف آهي ۽ هن کي ساڳيون ذميواريون تفويض ڪرڻ، جنهن، هن جي تجربي جي مهرباني، "اسٽار" جي ترقي جي قيمت جي مقابلي ۾ گهٽ قيمت تي ساڳئي اشارن کي حاصل ڪرڻ ممڪن ڪيو. اهڙن منتظمين کي هڪ ٽيم ۾ رکيو ويو ۽ هن جو بنيادي ڪم ٽيسٽ ۽ پيداوار جي ماحول کي منظم ڪرڻ هو، هڪ مخصوص ٽيم جي ضابطن جي مطابق، هن خاص ٽيم کي مختص ڪيل وسيلن سان. اهو ڪيئن آهي، حقيقت ۾، DevOps اڪثريت جي ذهنن ۾ ظاهر ٿيو.
جزوي طور يا مڪمل طور تي، وقت سان گڏ، انهن سسٽم جي منتظمين ترقي جي ميدان ۾ هن خاص ٽيم جي ضرورتن کي سمجهڻ شروع ڪيو، ڪيئن ڊولپرز ۽ ٽيسٽرز لاء زندگي کي آسان بڻائي، هڪ تازه ڪاري ڪيئن ڪجي ۽ جمعه تي رات جو رهڻ نه گهرجي. آفيس، مقرري جي غلطي کي درست ڪرڻ. وقت گذري ويو، ۽ ھاڻي "ستارا" سسٽم منتظم ھئا جيڪي سمجھندا ھئا ته ڊولپر ڇا چاھيندا آھن. اثر کي گھٽائڻ لاءِ، انتظامي افاديتون سامهون اچڻ لڳيون؛ سڀني کي او ايس ليول کي الڳ ڪرڻ جا پراڻا ۽ قابل اعتماد طريقا ياد آيا، جن کي سيڪيورٽي جي ضرورتن کي گھٽائڻ، نيٽ ورڪ جي حصي جو انتظام، ۽ ميزبان جي ترتيب کي ممڪن بڻايو. مڪمل ۽، نتيجي طور، نئين "ستارن" جي گهرج کي گھٽايو.
هڪ "شاندار" شيء ظاهر ٿيو آهي - docker. شاندار ڇو؟ ها، صرف ان ڪري ته هڪ ڪروٽ يا جيل ۾ اڪيلائي پيدا ڪرڻ، گڏوگڏ OpenVZ، OS جي غير معمولي ڄاڻ جي ضرورت آهي، ان جي ابتڙ، يوٽيليٽي توهان کي اجازت ڏئي ٿي ته هڪ خاص ميزبان تي هڪ الڳ ٿيل ايپليڪيشن ماحول پيدا ڪرڻ جي اندر ۽ هٿ سان هر شيءِ سان. ٻيهر ترقي جي رينن تي، ۽ سسٽم منتظم صرف هڪ ميزبان سان منظم ڪري سگهي ٿو، ان جي حفاظت ۽ اعلي دستيابي کي يقيني بڻائي - هڪ منطقي آساني. پر ترقي اڃا به بيٺي نه آهي ۽ سسٽم ٻيهر وڌيڪ پيچيده ٿي رهيا آهن، وڌيڪ ۽ وڌيڪ اجزاء آهن، هڪ ميزبان هاڻي سسٽم جي ضرورتن کي پورو نٿو ڪري ۽ اهو ڪلستر ٺاهڻ ضروري آهي، اسان ٻيهر سسٽم جي منتظمين ڏانهن موٽندا آهيون. انهن سسٽم کي تعمير ڪرڻ جي قابل.
سائيڪل کان پوءِ، مختلف سسٽم ظاهر ٿيندا آهن جيڪي ترقي ۽/يا انتظاميا کي آسان بڻائيندا آهن، آرڪيسٽريشن سسٽم ظاهر ٿيندا آهن، جيڪي، جيستائين توهان کي معياري عمل کان انحراف ڪرڻ جي ضرورت ناهي، استعمال ڪرڻ آسان آهي. مائيڪرو سروس آرڪيٽيڪچر پڻ ظاهر ٿيو مقصد سان مٿي بيان ڪيل هر شي کي آسان ڪرڻ - گهٽ رشتا، منظم ڪرڻ آسان. منهنجي تجربي ۾، مون کي مڪمل طور تي مائڪرو سروسز آرڪيٽيڪچر نه مليو، مان چوندس 50 کان 50 - 50 سيڪڙو مائڪرو سروسز، بليڪ باڪس، اندر آيا، پروسيس ٿيل ٻاهر آيا، باقي 50 هڪ ٽٽل مونولٿ آهن، خدمتون ٻين کان الڳ ڪم ڪرڻ جي قابل نه آهن. اجزاء. هي سڀ وري ٻنهي ڊولپر ۽ منتظم جي علم جي سطح تي پابنديون لاڳو.
هڪ خاص وسيلن جي ماهر جي ڄاڻ جي سطح ۾ ساڳيو "جھول" اڄ ڏينهن تائين جاري آهي. پر اسان ٿورڙو ڦيرايو، اتي ڪيترائي نقطا نمايان ڪرڻ جي قابل آھن.
تعمير انجنيئر / رليز انجنيئر
تمام انتهائي خاص انجنيئر جيڪي سافٽ ويئر جي تعمير جي عملن ۽ رليز کي معياري ڪرڻ جي هڪ وسيلا طور سامهون آيا. وسيع Agile متعارف ڪرائڻ جي عمل ۾، اهو لڳي ٿو ته اهي مطالبن ۾ بند ٿي ويا، پر اهو معاملو کان پري آهي. هي اسپيشلائيزيشن صنعتي پيماني تي اسيمبليءَ ۽ سافٽ ويئر جي ترسيل کي معياري ڪرڻ جو هڪ وسيلو طور ظاهر ٿيو، يعني. سڀني ڪمپني جي شين لاء معياري ٽيڪنالاجي استعمال ڪندي. 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 انهن ڊيڊ لائنن جي اندر اعلي معيار جو نتيجو پيدا نٿو ڪري سگهي ۽ ان کي بهترين طور تي پيدا ڪري سگهي ٿو، بعد ۾ ريفڪٽرنگ کي ڇڏي، آئي ٽي سان لاڳاپيل DevOps ٽيڪنالاجي ذريعن کي استعمال ڪندي رليز کي بلاڪ ڪري ٿو. . صورتحال کي تبديل ڪرڻ لاءِ اختيار جو فقدان، ذميوار ملازمن جي صورت ۾، اعليٰ ذميواريءَ جي ظهور جو سبب بڻجي ٿو جنهن تي اهي اثر انداز نٿا ڪري سگهن، خاص طور تي جيڪڏهن اهي ملازم سمجهن ۽ غلطيون ڏسن، ۽ انهن کي ڪيئن درست ڪجي - ”خوشي آهي جهالت“، ۽ نتيجي ۾ انهن ملازمن جي ساڙڻ ۽ نقصان جي نتيجي ۾.
DevOps وسيلن جي مارڪيٽ
اچو ته مختلف ڪمپنين مان DevOps پوزيشن لاءِ ڪيترن ئي خالي جاين تي نظر وجهون.
اسان توهان سان ملڻ لاء تيار آهيون جيڪڏهن توهان:
- توهان Zabbix جا مالڪ آهيو ۽ ڄاڻو ته Prometheus ڇا آهي؛
- iptables؛
- BASH پي ايڇ ڊي شاگرد؛
- پروفيسر جوابي؛
- لينڪس گرو؛
- ڄاڻو ته ڊيبگنگ ڪيئن استعمال ڪجي ۽ ڊولپرز (php/java/python) سان گڏ ايپليڪيشن مسئلا ڳولھيو؛
- رستي ۾ توهان کي hysterical نه بڻائي;
- سسٽم جي حفاظت تي خاص ڌيان ڏيو؛
- بيڪ اپ “ڪجهه به ۽ سڀ ڪجهه”، ۽ پڻ ڪاميابيءَ سان بحال ڪريو “ڪجهه به ۽ هر شي”؛
- توهان ڄاڻو ٿا ته سسٽم کي ڪيئن ترتيب ڏيڻ لاء اهڙي طريقي سان وڌ کان وڌ حاصل ڪرڻ لاء گهٽ ۾ گهٽ؛
- Postgres ۽ MySQL تي بستري تي وڃڻ کان اڳ نقل قائم ڪريو؛
- CI/CD ترتيب ڏيڻ ۽ ترتيب ڏيڻ توهان لاءِ ضروري آهي جيترو ناشتو/ لنچ/ ڊنر.
- AWS سان تجربو ڪريو؛
- ڪمپني سان ترقي ڪرڻ لاء تيار؛
پوء:
- 1 کان 6 تائين - سسٽم ايڊمنسٽريٽر
- 7 - ٿورڙو نيٽ ورڪ ايڊمنسٽريشن، جيڪو پڻ سسٽم ايڊمنسٽريٽر، مڊل ليول ۾ اچي ٿو
- 8 - ٿورڙي سيڪيورٽي، جيڪا مڊل ليول سسٽم ايڊمنسٽريٽر لاءِ لازمي آهي
- 9-11 - مڊل سسٽم ايڊمنسٽريٽر
- 12 — تفويض ڪيل ڪمن تي مدار رکندي، يا ته مڊل سسٽم ايڊمنسٽريٽر يا بلڊ انجنيئر
- 13 - ورچوئلائيزيشن - مڊل سسٽم ايڊمنسٽريٽر، يا نام نهاد CloudOps، هڪ مخصوص هوسٽنگ سائيٽ جي خدمتن جي جديد ڄاڻ، فنڊز جي موثر استعمال ۽ سار سنڀال تي لوڊ گھٽائڻ لاءِ
هن خالي جاءِ کي مختصر ڪندي، اسان چئي سگهون ٿا ته مڊل/سينئر سسٽم ايڊمنسٽريٽر ماڻهن لاءِ ڪافي آهي.
رستي جي ذريعي، توهان کي لينڪس / ونڊوز تي منتظمين کي مضبوط طور تي ورهائڻ نه گهرجي. يقينن، مان سمجهان ٿو ته انهن ٻنهي جهانن جون خدمتون ۽ نظام مختلف آهن، پر سڀني جو بنياد هڪ ئي آهي ۽ ڪو به باوقار منتظم هڪ ٻئي کان واقف هوندو آهي، ۽ جيتوڻيڪ هو واقف نه هوندو آهي، پر اهو به. هڪ قابل منتظم لاءِ ان سان واقف ٿيڻ ڏکيو نه آهي.
اچو ته هڪ ٻي جاء تي غور ڪريو:
- اعلي لوڊ سسٽم جي تعمير ۾ تجربو؛
- لينڪس او ايس جي بهترين ڄاڻ، عام سسٽم سافٽ ويئر ۽ ويب اسٽيڪ (Nginx، PHP/Python، HAProxy، MySQL/PostgreSQL، Memcached، Redis، RabbitMQ، ELK)؛
- ورچوئلائيزيشن سسٽم سان تجربو (KVM، VMWare، LXC / Docker)؛
- اسڪرپٽنگ ٻولين ۾ مهارت؛
- نيٽ ورڪ پروٽوڪول نيٽ ورڪ جي آپريٽنگ اصولن کي سمجهڻ؛
- غلطي برداشت ڪرڻ واري نظام جي تعمير جي اصولن کي سمجھڻ؛
- آزادي ۽ شروعات؛
اچو ته ڏسون:
- 1 - سينئر سسٽم ايڊمنسٽريٽر
- 2 - مطلب تي مدار رکندي ھن اسٽيڪ ۾ رکيل آھي - مڊل / سينئر سسٽم ايڊمنسٽريٽر
- 3 - ڪم جو تجربو، بشمول، مطلب ٿي سگھي ٿو - "ڪلسٽر نه وڌو، پر ورچوئل مشينون ٺاھيو ۽ منظم ڪيو، ھڪڙو ڊاڪر ھوسٽ ھو، ڪنٽينرز تائين رسائي دستياب ناھي" - مڊل سسٽم ايڊمنسٽريٽر
- 4 - جونيئر سسٽم ايڊمنسٽريٽر - ها، هڪ منتظم جيڪو نه ڄاڻندو آهي بنيادي آٽوميشن اسڪرپٽ ڪيئن لکڻو آهي، ٻولي جي لحاظ کان، منتظم نه - اينڪي.
- 5 - مڊل سسٽم ايڊمنسٽريٽر
- 6 - سينئر سسٽم ايڊمنسٽريٽر
اختصار ڪرڻ لاءِ - مڊل / سينئر سسٽم ايڊمنسٽريٽر
ٻيو ڪو:
- ترقي جو تجربو؛
- CI/CD پروسيس ٺاهڻ لاءِ هڪ يا وڌيڪ پروڊڪٽس استعمال ڪرڻ ۾ تجربو. Gitlab CI هڪ فائدو ٿيندو؛
- ڪنٽينرز ۽ ورچوئلائيزيشن سان ڪم ڪرڻ؛ جيڪڏهن توهان ڊاکر استعمال ڪيو، سٺو، پر جيڪڏهن توهان k8s استعمال ڪيو، عظيم!
- هڪ چست ٽيم ۾ ڪم ڪرڻ جو تجربو؛
- ڪنهن به پروگرامنگ ٻولي جي ڄاڻ؛
اچو ته ڏسون:
- 1 - هيم... ڇوڪرن جو مطلب ڇا آهي؟ =) گهڻو ڪري اهي پاڻ کي خبر ناهي ته ان جي پويان ڇا لڪيل آهي
- 2 - تعمير انجنيئر
- 3 - مڊل سسٽم ايڊمنسٽريٽر
- 4 - نرم مهارت، اسان ان تي في الحال غور نه ڪنداسين، جيتوڻيڪ Agile هڪ ٻي شيء آهي جيڪا آسانيء سان تشريح ڪئي وئي آهي.
- 5 - ڏاڍو لفظي - اهو ٿي سگهي ٿو لکت واري ٻولي يا مرتب ڪيل. مان حيران آهيان ته ڇا اسڪول ۾ پاسڪل ۽ بيسڪ ۾ لکڻ انهن کي مناسب ڪندو؟ =)
مان پڻ پوائنٽ 3 جي حوالي سان هڪ نوٽ ڇڏڻ چاهيان ٿو انهي سمجھ کي مضبوط ڪرڻ لاءِ ته هي نقطو سسٽم ايڊمنسٽريٽر طرفان ڇو ڍڪيل آهي. ڪبرنيٽس صرف هڪ آرڪيسٽريشن آهي، هڪ اوزار جيڪو نيٽ ورڪ ڊرائيورن ۽ ورچوئلائيزيشن / آئسوليشن هوسٽس ڏانهن سڌو حڪمن کي لپي ٿو ڪجهه حڪمن ۾ ۽ توهان کي اجازت ڏئي ٿو ته انهن سان رابطي کي خلاصو، بس اهو ئي آهي. مثال طور، اچو ته وٺو 'بلڊ فريم ورڪ' ٺاهيو، جيڪو، طريقي سان، مان فريم ورڪ تي غور نٿو ڪريان. ها، مان ڄاڻان ٿو ته ٺهڪندڙ ٺاھڻ جي فيشن جي باري ۾ ڪٿي به، جتي اھو ضروري آھي ۽ ضرورت نه آھي - ميڪن ۾ ميون لپائڻ، مثال طور، سنجيدگي سان؟
لازمي طور تي، ٺاهيو شيل مٿان صرف هڪ لفافي آهي، ترتيب ڏيڻ، ڳنڍڻ، ۽ ترتيب ڏيڻ واري ماحول جي حڪمن کي آسان بڻائي ٿو، جهڙوڪ k8s.
هڪ دفعي، مون هڪ ماڻهوءَ سان انٽرويو ڪيو، جيڪو اوپن اسٽيڪ جي چوٽي تي پنهنجي ڪم ۾ k8s استعمال ڪندو هو، ۽ هن ڳالهه ڪئي ته ڪيئن هن ان تي خدمتون سرانجام ڏنيون، جڏهن ته، مون جڏهن OpenStack بابت پڇيو، ته اهو معلوم ٿيو ته اهو انتظام ڪيو ويو آهي، انهي سان گڏ سسٽم طرفان وڌايو ويو آهي. منتظمين. ڇا توهان واقعي سوچيو ٿا ته هڪ شخص جنهن OpenStack انسٽال ڪيو آهي، قطع نظر هن جي پويان ڪهڙو پليٽ فارم استعمال ڪري ٿو، k8s استعمال ڪرڻ جي قابل ناهي؟ =)
هي درخواست ڪندڙ اصل ۾ هڪ DevOps نه آهي، پر هڪ سسٽم ايڊمنسٽريٽر ۽، وڌيڪ صحيح هجڻ لاء، هڪ ڪبرنيٽس ايڊمنسٽريٽر.
اچو ته هڪ ڀيرو ٻيهر اختصار ڪريون - مڊل / سينيئر سسٽم ايڊمنسٽريٽر انهن لاءِ ڪافي هوندو.
گرام ۾ ڪيترو وزن ڪجي
ظاهر ڪيل خالي جاين لاءِ تجويز ڪيل تنخواه جي حد 90k-200k آهي
هاڻي مان سسٽم ايڊمنسٽريٽرز ۽ ڊي او پيز انجنيئرز جي مالياتي انعامن جي وچ ۾ هڪ متوازي ٺاهڻ چاهيندس.
اصول ۾، شين کي آسان ڪرڻ لاء، توهان ڪم جي تجربن جي بنياد تي گريڊ کي ورهائي سگهو ٿا، جيتوڻيڪ اهو صحيح نه ٿيندو، پر مضمون جي مقصدن لاء اهو ڪافي هوندو.
هڪ تجربو:
- 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 کي ترتيب ڏئي سگهي ٿو، هن ڪلستر ۾ Fluentd sidecar ۽ AWS ELK اسٽيڪ سان 10 منٽن ۾ لاگنگ سسٽم لاءِ، ڪنسول ۾ صرف هڪ حڪم استعمال ڪندي، پر جيڪڏهن هو سمجهي نه ٿو پروسيسنگ جو اصول پاڻ لاگز ۽ انهن لاءِ ڇا گهربل آهي، جيڪڏهن توهان نٿا ڄاڻو ته انهن تي ميٽرڪ ڪيئن گڏ ڪجي ۽ خدمت جي تباهي کي ٽريڪ ڪجي، پوءِ به اهو ساڳيو اينڪي هوندو جيڪو ڄاڻي ٿو ته ڪي يوٽيلٽيز ڪيئن استعمال ڪجي.
طلب، جيتوڻيڪ، فراهمي پيدا ڪري ٿي، ۽ اسان ڏسون ٿا هڪ انتهائي گرم بازار DevOps پوزيشن لاءِ، جتي گهرجون اصل ڪردار سان مطابقت نه رکن ٿيون، پر صرف سسٽم منتظمين کي وڌيڪ ڪمائڻ جي اجازت ڏين ٿيون.
پوء اهي ڪير آهن؟ DevOps يا لالچي سسٽم منتظمين؟ =)
ڪيئن جيئڻ جاري رکڻ لاء؟
ملازمن کي ضرورتن کي وڌيڪ واضح طور تي ترتيب ڏيڻ گهرجي ۽ انهن کي ڳولڻ گهرجي جيڪي گهربل آهن، ۽ ليبل جي چوڌاري نه اڇلائي. توهان کي خبر ناهي ته DevOps ڇا ڪندا آهن - توهان کي ان صورت ۾ انهن جي ضرورت ناهي.
ڪم ڪندڙ- سکيا. مسلسل پنھنجي ڄاڻ کي بھتر ڪريو، عمل جي مجموعي تصوير کي ڏسو ۽ پنھنجي مقصد جي رستي کي ٽريڪ ڪريو. توهان بنجي سگهو ٿا جيڪو توهان چاهيو، توهان کي صرف ڪوشش ڪرڻ گهرجي.
جو ذريعو: www.habr.com