ہم بات کر رہے ہیں، بالکل، کے بارے میں . اگر آپ تفصیلات میں نہیں جاتے ہیں، تو 30 ستمبر اور 1 اکتوبر کو ہم ترقی، جانچ اور آپریشن کے عمل کو یکجا کرنے پر ایک کانفرنس منعقد کریں گے، اور اگر آپ تفصیلات میں جائیں تو، براہ کرم، بلی کے نیچے۔
DevOps نقطہ نظر کے اندر، پروجیکٹ کی تکنیکی ترقی کے تمام حصے آپس میں جڑے ہوئے ہیں، متوازی طور پر پائے جاتے ہیں اور ایک دوسرے پر اثر انداز ہوتے ہیں۔ یہاں خاص اہمیت خودکار ترقی کے عمل کی تخلیق ہے جسے حقیقی وقت میں تبدیل، نقلی اور تجربہ کیا جا سکتا ہے۔ اس سے مارکیٹ میں ہونے والی تبدیلیوں کا فوری جواب دینے میں مدد ملتی ہے۔
کانفرنس میں ہم یہ بتانا چاہتے ہیں کہ یہ طریقہ کس طرح مصنوعات کی ترقی کو متاثر کرتا ہے۔ کلائنٹ کے لیے سسٹم کی قابل اعتمادی اور موافقت کو کیسے یقینی بنایا جاتا ہے۔ کس طرح DevOps اپنے کام کے عمل کو منظم کرنے کے لیے کمپنی کے ڈھانچے اور نقطہ نظر کو تبدیل کر رہا ہے۔
پردے کے پیچھے
ہمارے لیے نہ صرف یہ جاننا ضروری ہے کہ مختلف کمپنیاں DevOps اپروچ کے فریم ورک کے اندر کیا کر رہی ہیں، بلکہ یہ سمجھنا بھی ضروری ہے کہ یہ سب کیوں کیا جاتا ہے۔ اس لیے، ہم نے نہ صرف ماہرین کو پروگرام کمیٹی میں شامل ہونے کے لیے مدعو کیا، بلکہ ماہرین کو جو مختلف عہدوں سے DevOps ڈسکورس دیکھتے ہیں:
- سینئر انجینئرز؛
- ڈویلپرز
- ٹیم کے رہنما؛
- سی ٹی او
ایک طرف، یہ رپورٹس کی درخواستوں پر بحث کرتے وقت مشکلات اور تنازعات پیدا کرتا ہے۔ اگر کوئی انجینئر کسی بڑے حادثے کا تجزیہ کرنے میں دلچسپی رکھتا ہے، تو ایک ڈویلپر کے لیے یہ سمجھنا زیادہ ضروری ہے کہ ایسا سافٹ ویئر کیسے بنایا جائے جو بادلوں اور انفراسٹرکچر میں کام کرے۔ لیکن اتفاق کرتے ہوئے، ہم ایک ایسا پروگرام بناتے ہیں جو سب کے لیے قیمتی اور دلچسپ ہوگا: انجینئرز سے لے کر CTO تک۔
ہماری کانفرنس کا مقصد صرف سب سے زیادہ ہائپ رپورٹس کا انتخاب کرنا نہیں ہے، بلکہ مجموعی تصویر پیش کرنا ہے: DevOps اپروچ عملی طور پر کیسے کام کرتا ہے، نئے پراسیسز کی طرف جانے کے دوران آپ کس قسم کے ریک میں حصہ لے سکتے ہیں۔ ایک ہی وقت میں، ہم کاروباری مسئلے سے مخصوص ٹیکنالوجیز تک جاکر مواد کا حصہ بناتے ہیں۔
کانفرنس کے حصے وہی رہیں گے جیسے میں .
- انفراسٹرکچر پلیٹ فارم۔
- بنیادی ڈھانچہ بطور کوڈ۔
- مسلسل ترسیل۔
- تاثرات
- ڈی او اوپس میں آرکیٹیکچر، سی ٹی او کے لیے ڈی او اوپس۔
- SRE پریکٹسز۔
- تربیت اور علم کا انتظام۔
- سیکورٹی، DevSecOps.
- DevOps تبدیلی۔
کاغذات کے لیے کال کریں: ہم کس قسم کی رپورٹس تلاش کر رہے ہیں۔
ہم نے کانفرنس کے ممکنہ سامعین کو مشروط طور پر پانچ گروپوں میں تقسیم کیا: انجینئرز، ڈویلپرز، سیکورٹی ماہرین، ٹیم لیڈز اور CTO۔ کانفرنس میں آنے کے لیے ہر گروپ کا اپنا محرک ہوتا ہے۔ اور، اگر آپ ان پوزیشنوں سے DevOps کو دیکھتے ہیں، تو آپ سمجھ سکتے ہیں کہ اپنے موضوع پر کیسے فوکس کرنا ہے اور کہاں زور دینا ہے۔
انجینئرز کے لیے، جو ایک انفراسٹرکچر پلیٹ فارم بنا رہے ہیں، موجودہ رجحانات کو سمجھنا ضروری ہے، یہ سمجھنے کے لیے کہ کون سی ٹیکنالوجیز اب سب سے زیادہ جدید ہیں۔ وہ ان ٹیکنالوجیز کو استعمال کرنے اور رائے کے تبادلے میں حقیقی زندگی کے تجربے کے بارے میں سیکھنے میں دلچسپی لیں گے۔ ایک انجینئر کسی سخت حادثے کا تجزیہ کرنے والی رپورٹ سن کر خوش ہو گا، اور ہم، بدلے میں، ایسی رپورٹ کو منتخب کرنے اور پالش کرنے کی کوشش کریں گے۔
ڈویلپرز کے لیے اس طرح کے تصور کو سمجھنا ضروری ہے۔ کلاؤڈ مقامی ایپلی کیشن. یعنی، سافٹ ویئر کیسے تیار کیا جائے تاکہ یہ بادلوں اور مختلف انفراسٹرکچر میں کام کرے۔ ڈویلپر کو سافٹ ویئر سے مسلسل فیڈ بیک حاصل کرنے کی ضرورت ہے۔ یہاں ہم اس بارے میں کیس سننا چاہتے ہیں کہ کمپنیاں اس عمل کو کیسے تیار کرتی ہیں، سافٹ ویئر کی کارکردگی کی نگرانی کیسے کی جاتی ہے، اور ترسیل کا پورا عمل کیسے کام کرتا ہے۔
سائبر سیکیورٹی ماہرین یہ سمجھنا ضروری ہے کہ سیکیورٹی کے عمل کو کیسے ترتیب دیا جائے تاکہ یہ کمپنی کے اندر ترقی اور تبدیلی کے عمل کو روک نہ دے۔ ضروریات کے بارے میں عنوانات جو DevOps ایسے ماہرین پر رکھتا ہے وہ بھی دلچسپ ہوں گے۔
ٹیم لیڈز جاننا چاہتے ہیں۔، دوسری کمپنیوں میں مسلسل ترسیل کا عمل کیسے کام کرتا ہے۔ کمپنیوں نے اس کو حاصل کرنے کے لیے کیا راستہ اختیار کیا، انہوں نے DevOps کے اندر ترقی اور معیار کی یقین دہانی کے عمل کیسے بنائے۔ ٹیم لیڈز بھی کلاؤڈ مقامی میں دلچسپی رکھتے ہیں۔ اور ٹیم کے اندر اور ترقیاتی اور انجینئرنگ ٹیموں کے درمیان تعامل کے بارے میں بھی سوالات۔
کے لیے CTO سب سے اہم بات یہ جاننا ہے کہ ان تمام عملوں کو کس طرح مربوط کیا جائے اور انہیں کاروباری ضروریات کے مطابق کیسے بنایا جائے۔ وہ اس بات کو یقینی بناتا ہے کہ درخواست کاروبار اور کلائنٹ دونوں کے لیے قابل اعتماد ہے۔ اور یہاں آپ کو یہ سمجھنے کی ضرورت ہے کہ کون سی ٹیکنالوجی کام کرے گی کن کاروباری کاموں کے لیے، پورے عمل کو کیسے بنایا جائے وغیرہ۔ CTO بجٹ بنانے کا بھی ذمہ دار ہے۔ مثال کے طور پر، اسے سمجھنا چاہیے کہ ماہرین کو دوبارہ تربیت دینے پر کتنی رقم خرچ کرنے کی ضرورت ہے تاکہ وہ DevOps میں کام کر سکیں۔
اگر آپ کو ان معاملات پر کچھ کہنا ہے تو خاموش نہ رہیں، . کاغذات طلب کرنے کی آخری تاریخ 20 اگست ہے۔ جتنی جلدی آپ رجسٹر کریں گے، اتنا ہی زیادہ وقت آپ کو اپنی رپورٹ کو حتمی شکل دینے اور اپنی پریزنٹیشن کی تیاری میں لگے گا۔ تو، تاخیر نہ کرو.
ٹھیک ہے، اگر آپ کو عوامی طور پر بات کرنے کی ضرورت نہیں ہے، بس اور ساتھیوں کے ساتھ بات چیت کرنے کے لیے 30 ستمبر اور 1 اکتوبر کو آئیں۔ ہم وعدہ کرتے ہیں کہ یہ دلچسپ اور متاثر کن ہوگا۔
ہم DevOps کو کس طرح دیکھتے ہیں۔
یہ سمجھنے کے لیے کہ ڈی او اوپس سے ہمارا کیا مطلب ہے، میں اپنی رپورٹ کو پڑھنے (یا دوبارہ پڑھنے) کی تجویز کرتا ہوں۔" مارکیٹ کی لہروں سے گزرتے ہوئے، میں نے مشاہدہ کیا کہ کس طرح مختلف سائز کی کمپنیوں میں DevOps کا آئیڈیا تبدیل ہو رہا ہے: ایک چھوٹے سے سٹارٹ اپ سے ملٹی نیشنل کمپنیوں تک۔ رپورٹ کو سوالات کی ایک سیریز پر بنایا گیا ہے، ان کے جوابات دے کر آپ سمجھ سکتے ہیں کہ آیا آپ کی کمپنی DevOps کی طرف بڑھ رہی ہے یا کہیں مسائل ہیں۔
DevOps ایک پیچیدہ نظام ہے، اس میں شامل ہونا ضروری ہے:
- ڈیجیٹل پروڈکٹ۔
- کاروباری ماڈیول جو اس ڈیجیٹل پروڈکٹ کو تیار کرتے ہیں۔
- پروڈکٹ ٹیمیں جو کوڈ لکھتی ہیں۔
- مسلسل ترسیل کے طریقے۔
- پلیٹ فارمز بطور سروس۔
- بنیادی ڈھانچہ بطور خدمت۔
- بنیادی ڈھانچہ بطور کوڈ۔
- وشوسنییتا کو برقرار رکھنے کے لیے علیحدہ طریقے، جو ڈی او اوپس میں بنائے گئے ہیں۔
- ایک فیڈ بیک پریکٹس جو یہ سب بیان کرتی ہے۔
رپورٹ کے آخر میں ایک خاکہ ہے جو کمپنی میں DevOps سسٹم کا اندازہ دیتا ہے۔ یہ آپ کو یہ دیکھنے کی اجازت دے گا کہ آپ کی کمپنی میں کون سے عمل پہلے ہی ہموار ہو چکے ہیں اور کون سے ابھی تعمیر ہونا باقی ہیں۔
رپورٹ کی ویڈیو آپ دیکھ سکتے ہیں۔ .
اور اب ایک بونس ہوگا: RIT++ 2019 کی کئی ویڈیوز، جو DevOps کی تبدیلی کے سب سے عام مسائل کو چھوتی ہیں۔
کمپنی کا بنیادی ڈھانچہ بطور مصنوعات
Artyom Naumenko Skyeng میں DevOps ٹیم کی قیادت کرتے ہیں اور اپنی کمپنی کے بنیادی ڈھانچے کی ترقی کا خیال رکھتے ہیں۔ اس نے بتایا کہ بنیادی ڈھانچہ کس طرح SkyEng میں کاروباری عمل کو متاثر کرتا ہے: اس کے لیے ROI کا حساب کیسے لگایا جائے، حساب کے لیے کون سے میٹرکس کا انتخاب کیا جائے اور ان کو بہتر بنانے کے لیے کیسے کام کیا جائے۔
مائیکرو سروسز کے راستے پر
Nixys کمپنی مصروف ویب پروجیکٹس اور تقسیم شدہ نظاموں کے لیے تعاون فراہم کرتی ہے۔ اس کے تکنیکی ڈائریکٹر، بورس ایرشوف نے بتایا کہ سافٹ ویئر پروڈکٹس کا ترجمہ کیسے کیا جائے، جس کی ترقی 5 سال پہلے (یا اس سے بھی زیادہ) ایک جدید پلیٹ فارم پر شروع ہوئی تھی۔
ایک اصول کے طور پر، اس طرح کے منصوبے ایک خاص دنیا ہیں جہاں بنیادی ڈھانچے کے ایسے تاریک اور قدیم گوشے ہیں کہ موجودہ انجینئرز ان کے بارے میں نہیں جانتے۔ اور فن تعمیر اور ترقی کے نقطہ نظر جو ایک بار منتخب کیے گئے تھے وہ پرانے ہیں اور کاروبار کو ترقی کی ایک ہی رفتار اور نئے ورژن کے اجراء کے ساتھ فراہم نہیں کرسکتے ہیں۔ نتیجے کے طور پر، ہر پروڈکٹ کی ریلیز ایک ناقابل یقین مہم جوئی میں بدل جاتی ہے، جہاں کوئی چیز مسلسل گرتی ہے، اور انتہائی غیر متوقع جگہ پر۔
اس طرح کے منصوبوں کے مینیجرز کو لامحالہ تمام تکنیکی عمل کو تبدیل کرنے کی ضرورت کا سامنا کرنا پڑتا ہے۔ بورس نے اپنی رپورٹ میں کہا:
- منصوبے کے لیے صحیح فن تعمیر کا انتخاب کیسے کریں اور بنیادی ڈھانچے کو ترتیب میں رکھیں؛
- کون سے اوزار استعمال کرنے ہیں اور تبدیلی کے راستے میں کن نقصانات کا سامنا کرنا پڑتا ہے۔
- آگے کیا کرنا ہے.
ریلیز کا آٹومیشن یا جلدی اور بغیر تکلیف کے ڈیلیور کرنے کا طریقہ
الیگزینڈر کوروٹکوف CIAN میں CI/CD سسٹم کا ایک سرکردہ ڈویلپر ہے۔ انہوں نے آٹومیشن ٹولز کے بارے میں بات کی جنہوں نے معیار کو بہتر بنانا اور کوڈ کو پروڈکشن تک پہنچانے کا وقت 5 گنا کم کرنا ممکن بنایا۔ لیکن ایسے نتائج اکیلے آٹومیشن سے حاصل نہیں کیے جا سکتے تھے، اس لیے الیگزینڈر نے ترقی کے عمل میں ہونے والی تبدیلیوں پر بھی توجہ دی۔
حادثات آپ کو سیکھنے میں کس طرح مدد کرتے ہیں؟
Alexey Kirpichnikov 5 سالوں سے SKB کونتور میں DevOps اور بنیادی ڈھانچے کو نافذ کر رہا ہے۔ تین سالوں کے دوران، ان کی کمپنی میں تقریباً 1000 مختلف درجات کی مہاکاوی کے واقعات رونما ہوئے۔ ان میں سے، مثال کے طور پر، 36% پیداوار میں کم معیار کی ریلیز کی وجہ سے ہوئے، اور 14% ڈیٹا سینٹر میں ہارڈ ویئر کی دیکھ بھال کے کام کی وجہ سے ہوئے۔
رپورٹس کا ایک ذخیرہ (پوسٹ مارٹم) جسے کمپنی کے انجینئرز لگاتار کئی سالوں سے برقرار رکھے ہوئے ہیں، حادثات کے بارے میں ایسی درست معلومات حاصل کرنا ممکن بناتا ہے۔ پوسٹ مارٹم ڈیوٹی پر موجود انجینئر نے لکھا ہے، جس نے سب سے پہلے ایمرجنسی سگنل کا جواب دیا اور سب کچھ ٹھیک کرنا شروع کیا۔ رپورٹیں لکھ کر رات کو فیکیپس کے ساتھ جدوجہد کرنے والے انجینئرز کو کیوں عذاب دیتے ہیں؟ یہ ڈیٹا آپ کو پوری تصویر دیکھنے اور بنیادی ڈھانچے کی ترقی کو صحیح سمت میں آگے بڑھانے کی اجازت دیتا ہے۔
اپنی تقریر میں، الیکسی نے بتایا کہ واقعی مفید پوسٹ مارٹم کیسے لکھا جائے اور ایک بڑی کمپنی میں اس طرح کی رپورٹس کے عمل کو کیسے نافذ کیا جائے۔ اگر آپ اس بارے میں کہانیاں پسند کرتے ہیں کہ کس طرح کسی نے خراب کیا، تو کارکردگی کی ویڈیو دیکھیں۔
ہم سمجھتے ہیں کہ DevOps کے بارے میں آپ کا وژن ہمارے ساتھ میل نہیں کھا سکتا ہے۔ یہ جاننا دلچسپ ہوگا کہ آپ DevOps کی تبدیلی کو کیسے دیکھتے ہیں۔ تبصرے میں اس موضوع کے بارے میں اپنے تجربے اور وژن کا اشتراک کریں۔
ہم نے پہلے ہی پروگرام میں کن رپورٹس کو قبول کیا ہے؟
اس ہفتے پروگرام کمیٹی نے 4 رپورٹس کو اپنایا: سیکورٹی، انفراسٹرکچر اور SRE طریقوں پر۔
شاید DevOps کی تبدیلی کا سب سے تکلیف دہ موضوع: یہ کیسے یقینی بنایا جائے کہ انفارمیشن سیکیورٹی ڈیپارٹمنٹ کے لوگ ترقی، آپریشن اور انتظامیہ کے درمیان پہلے سے بنائے گئے رابطوں کو تباہ نہ کریں۔ کچھ کمپنیاں انفارمیشن سیکیورٹی ڈیپارٹمنٹ کے بغیر انتظام کرتی ہیں۔. اس معاملے میں معلومات کی حفاظت کو کیسے یقینی بنایا جائے؟ اس کے بارے میں مونا آرکھیپووا sudo.su سے. اس کی رپورٹ سے ہم سیکھتے ہیں:
- کس چیز کی حفاظت کی ضرورت ہے اور کس سے؛
- سیکیورٹی کے معمول کے عمل کیا ہیں؛
- آئی ٹی اور انفارمیشن سیکیورٹی کے عمل کس طرح ایک دوسرے کو آپس میں ملاتے ہیں۔
- CIS CSC کیا ہے اور اسے کیسے نافذ کیا جائے؛
- کس طرح اور کن اشارے کے ذریعہ باقاعدگی سے معلومات کی حفاظت کی جانچ کی جائے۔
اگلی رپورٹ کوڈ کے طور پر بنیادی ڈھانچے کی ترقی سے متعلق ہے۔ دستی روٹین کی مقدار کو کم کریں اور پورے منصوبے کو افراتفری میں نہ بدلیں، کیا یہ ممکن ہے؟ اس سوال پر میکسم کوسٹریکن ایکسٹینس سے. اس کی کمپنی استعمال کرتی ہے۔ ٹرافیفار AWS انفراسٹرکچر کے ساتھ کام کرنے کے لیے۔ ٹول آسان ہے، لیکن سوال یہ ہے کہ اسے استعمال کرتے وقت کوڈ کا ایک بڑا بلاک بنانے سے کیسے بچنا ہے۔ اس طرح کی میراث کی دیکھ بھال ہر سال زیادہ سے زیادہ مہنگی ہوتی جائے گی۔
میکسم دکھائے گا کہ کوڈ پلیسمنٹ پیٹرن کیسے کام کرتے ہیں، جس کا مقصد آٹومیشن اور ترقی کو آسان بنانا ہے۔
ایک اور ہم سے انفراسٹرکچر کے بارے میں سنیں گے۔ پلے کی سے ولادیمیر ریابوف. یہاں ہم بنیادی ڈھانچے کے پلیٹ فارم کے بارے میں بات کریں گے، اور ہم سیکھیں گے:
- یہ کیسے سمجھیں کہ آیا ذخیرہ کرنے کی جگہ کو مؤثر طریقے سے استعمال کیا جا رہا ہے۔
- اگر صرف 10 TB سٹوریج استعمال کیا جائے تو کئی سو صارفین 20 TB مواد کیسے حاصل کر سکتے ہیں۔
- ڈیٹا کو 5 بار کمپریس کرنے اور اسے ریئل ٹائم میں صارفین کو فراہم کرنے کا طریقہ؛
- کئی ڈیٹا سینٹرز کے درمیان فلائی پر ڈیٹا کو کیسے سنکرونائز کیا جائے؛
- ایک ورچوئل مشین کو ترتیب وار استعمال کرتے وقت ایک دوسرے پر صارفین کے اثر و رسوخ کو کیسے ختم کیا جائے۔
اس جادو کا راز ٹیکنالوجی ہے۔ فری بی ایس ڈی کے لیے زیڈ ایف ایس اور اس کا تازہ کانٹا لینکس پر زیڈ ایف ایس. ولادیمیر پلے کی سے کیسز شیئر کریں گے۔
Amixr.IO سے Matvey Kukuy زندگی سے مثالوں کے ساتھ تیار ، کیا ہوا SRE اور یہ قابل اعتماد نظام بنانے میں کس طرح مدد کرتا ہے۔ Amixr.IO اپنے پس منظر کے ذریعے کلائنٹ کے واقعات سے گزرتا ہے؛ دنیا بھر میں درجنوں آن ڈیوٹی ٹیمیں پہلے ہی 150 ہزار کیسوں سے نمٹ چکی ہیں۔ کانفرنس میں، Matvey ان اعدادوشمار اور بصیرت کا اشتراک کرے گا جو اس کی کمپنی نے صارفین کے مسائل حل کرنے اور ناکامیوں کا تجزیہ کرکے جمع کیے ہیں۔
ایک بار پھر میں آپ سے گزارش کرتا ہوں کہ لالچی نہ بنیں اور ایک DevOps samurai کے طور پر اپنا تجربہ شیئر کریں۔ سرو کریں۔ ایک رپورٹ کے لیے، اور آپ اور میرے پاس ایک بہترین تقریر تیار کرنے کے لیے 2,5 مہینے ہوں گے۔ اگر آپ سامع بننا چاہتے ہیں، پروگرام کی تازہ کاریوں کے ساتھ نیوز لیٹر پر جائیں اور وقت سے پہلے ٹکٹوں کی بکنگ کے بارے میں سنجیدگی سے سوچیں، کیونکہ وہ کانفرنس کی تاریخوں کے قریب زیادہ مہنگے ہو جائیں گے۔
ماخذ: www.habr.com