DevOpsDays ماسکو کانفرنس کا جائزہ: 6 رپورٹس سے بصیرتیں۔

تیسری کانفرنس 7 دسمبر کو منعقد ہوئی۔ DevOpsDays ماسکو, Mail.ru Cloud Solutions کے تعاون سے Moscow DevOps کمیونٹی کے ذریعے منظم کیا گیا ہے۔ معروف DevOps پریکٹیشنرز کی پیشکشوں کے علاوہ، شرکاء مختصر حوصلہ افزا لائٹننگ ٹاکس، ورکشاپس میں شرکت کر سکتے ہیں اور کھلی جگہوں پر بات چیت کر سکتے ہیں۔

ہم نے چھ تقریروں سے اہم بصیرتیں اکٹھی کیں اور کئی مقررین کے ساتھ انٹرویوز کیے تاکہ یہ معلوم کیا جا سکے کہ رپورٹس کے پیچھے کیا رہ گیا ہے۔

اندر:

1. Baruch Sadogursky، JFrog: "سافٹ ویئر کو وینڈر سے صارف تک مائع کی طرح بہنے دیں"
2. پاول سیلیوانوف، ساؤتھ برج: "دیو اور اوپس کا ایک مشترکہ کام ہے - کام کرنے والی پروڈکٹ بنانا"
3. ولادیمیر اتراٹینکو، ایکس 5 ریٹیل گروپ: "انٹرپرائز میں ڈی اوپس درد اور آگ کے بغیر ترقی ہے"
4. سرگئی پوزیریو، فیس بک: "پروڈکشن انجینئر مجموعی طور پر سروس کا خیال رکھتا ہے: تاکہ صارفین اور ڈویلپر دونوں کے پاس اچھا وقت ہو"
5. میخائل چنکوف، AMBOSS: "ایک شعبہ DevOps کے راستے پر نہیں چل سکتا، پوری کمپنی کو اس کی پیروی کرنی چاہیے"
6. Rosbank کے DevOps کے شائقین: "ایک خونی کاروبار میں DevOps کو لاگو کرنے کے 1000 دن"

1. Baruch Sadogursky، JFrog: "سافٹ ویئر کو وینڈر سے صارف تک مائع کی طرح بہنے دیں"

سافٹ ویئر اپ ڈیٹ کی ناکامیاں فی گھنٹہ اور ہر ایک کے لیے ہوتی ہیں۔ تقریر سے صرف ایک خوفناک کہانی یہ ہے: ایک ناکام اپ ڈیٹ کے بعد نائٹ کیپٹل کو ایک گھنٹے میں $440 ملین کا نقصان ہوا۔

بارچ نے مسلسل اپ ڈیٹس کے DevOps پیٹرن کے بارے میں بات کی جو ناکامیوں اور صارف کی نفرت سے بچنے میں مدد کریں گے۔

مقامی رول بیک - کچھ ہونے کی صورت میں واپس آنے کے لیے سافٹ ویئر کا پچھلا ورژن اپنے آلے پر رکھیں۔ یہ آپ کی حفاظت کرے گا اگر چیزیں اتنی خراب ہوجاتی ہیں کہ آپ ہوا پر پیچ نہیں بھیج سکتے۔

اوور دی ایئر اپڈیٹس - بہتر مسلسل. دوسری صورت میں، یہ جیگوار ڈویلپرز کے ساتھ ہوگا: بریک سسٹم میں ایک بگ کی وجہ سے، جو ہوا پر اپ ڈیٹ نہیں کیا جا سکتا تھا، کاروں کو فروخت سے واپس بلانا پڑا. یہ تکلیف دہ اور مہنگا تھا۔

مسلسل اپ ڈیٹس - جیسے ہی کوئی نیا فیچر تیار ہوتا ہے سافٹ ویئر کو مسلسل اپ ڈیٹ کریں۔ نایاب اپ ڈیٹس کے ساتھ، خصوصیات کو ایک ساتھ گروپ کیا جاتا ہے؛ ایک اہم اپ ڈیٹ غیر اہم کا انتظار کر سکتا ہے۔ ٹیسلا کی طرح، ایک اپ ڈیٹ جو بے ترتیب بریک کو ٹھیک کرنے والا تھا شطرنج کے کھیل میں اپ ڈیٹ کا انتظار کر رہا تھا۔

خودکار تعیناتی۔ - لوگوں کو مشینوں سے تبدیل کریں، کیونکہ لوگ معمول کے کام انجام دینے میں بری طرح ہوتے ہیں۔

обновленияые обновления - آپ کو عادت پیدا کرنے اور خوف سے چھٹکارا پانے میں مدد کریں۔ نایاب اپ ڈیٹس ہنگامی واقعات میں بدل جاتی ہیں۔

ڈیوائس کی حالت جاننا - ٹیسٹ اپ ڈیٹس، شروع سے انسٹالیشن نہیں۔ یہ اہم ہے کیونکہ اپ ڈیٹس آلہ کی حالت کے لحاظ سے مختلف طریقے سے برتاؤ کر سکتی ہیں۔

کینری ریلیز - صارفین کی ایک چھوٹی سی تعداد میں اپ ڈیٹس کو رول آؤٹ کریں اور مشاہدہ کریں۔ اگر کچھ غلط ہو جائے تو یہ نقصان کو کم کرتا ہے۔

اپ ڈیٹس بغیر دستیابی کے - صارفین کو صرف نئی خصوصیات کی اطلاع دیں، اور جب آپ اپڈیٹ شروع کریں تو کئی ہفتوں تک سروس کے بغیر نہ چھوڑیں۔

ہم نے Baruch Sadogursky کے ساتھ اس بارے میں بات کی کہ روسی اور مغربی IT میں DevOps کا نظریہ کس طرح مختلف ہے، کیا کلاؤڈ جلد ہی ہمارے لیے سب کچھ کرے گا اور کیا تمام سافٹ ویئر سروسز AAS اسکیم میں شامل ہو جائیں گی - انٹرویو دیکھیں:

2. Pavel Selivanov، Southbridge: "Dev اور Ops کا ایک مشترکہ کام ہے - ایک ایسی پروڈکٹ بنانا جو کام کرے"

Kubernetes کو لاگو کرنے سے DevOps کو حاصل کرنے میں مدد نہیں ملے گی، اور اس کے برعکس، یہ سب کچھ توڑ سکتا ہے۔ پاول نے وضاحت کی کہ کیوں ٹیکنالوجی (حتی کہ بہترین) آپ کے تمام مسائل حل نہیں کر سکتی:

منصوبے کی پیچیدگی کوڈ سے آگے بڑھ گئی ہے۔. پہلے، ایک پیچیدہ درخواست تھی: منصوبے اور پیچیدہ ترقی کے اندر تعامل، لیکن ایک سادہ ڈھانچہ - منتظم نے اسے تعینات کیا، سب کچھ کام کرتا ہے۔ ہم مائیکرو سروسز پر چلے گئے: ہر سروس ایک سادہ ایپلی کیشن ہے، معیاری پروٹوکول اور تیز رفتار ترقی کا استعمال کرتے ہوئے مواصلات، لیکن پروجیکٹ کا ڈھانچہ زیادہ پیچیدہ ہو گیا ہے۔ مائیکرو سروس آرکیٹیکچر والے پروجیکٹ کی پیچیدگی ختم نہیں ہوئی ہے - یہ کوڈ سے آگے بڑھ گئی ہے۔ اب DevOps انجینئر اس کے ذمہ دار ہیں۔

ڈویلپر ڈی او اوپس کو لاگو کرنے کے بعد تبدیلیاں نہیں چاہتے ہیں۔. نتیجے کے طور پر، Kubernetes کے ساتھ کام کا بہاؤ ایسا لگتا ہے جیسے کاموں کو Dev سے Ops تک دیوار کے اوپر پھینک دیا جائے، نہ صرف ایک استعاراتی - Git ایسی دیوار بن جاتا ہے۔ ڈویلپر وہاں کوڈ رکھتا ہے اور پہلے کی طرح کام کرتا ہے، اور منتظمین کے پاس Kubernetes، CI/CD اور باقی سب کچھ ہوتا ہے۔

تاہم، ڈویلپرز کو تبدیلیاں قبول کرنے کی ضرورت ہے۔. ایسی صورت حال جب ڈویلپرز نہیں جانتے کہ ایڈمنز کیا کر رہے ہیں، اور ایڈمن نہیں جانتے کہ ڈویلپرز کے ساتھ کیا ہو رہا ہے، مسائل پیدا کرتی ہے۔

اگر ڈویلپرز کے لیے کچھ بھی نہیں بدلا ہے، تو وہ یہ نہیں سمجھتے کہ ایپلی کیشن کو چلانا ان کی ذمہ داری ہے - مختلف تکنیکی چالیں کام نہیں کریں گی۔

DevOps اور Kubernetes کی آمد کے ساتھ، ترقی میں بہت کچھ بدل جائے گا۔ Devs کو Ops میں اہل ہونا چاہیے اور اس کے برعکس۔ ان ماہرین کی اپنی مخصوص مہارتیں ہیں، لیکن انہیں ایک دوسرے کے کام سے آگاہ ہونا چاہیے۔ Kubernetes کو لاگو کرنے سے پہلے Dev اور Ops کو دوست بننے کی ضرورت ہے، ورنہ آپ جو کچھ آپ کے پاس ہے اسے توڑ دیں گے۔

Pavel Selivanov نے بتایا کہ 5 سالوں میں Kubernetes کے ساتھ کیا ہوگا اور ایک جدید اسٹارٹ اپ کو ٹیکنالوجی کا اسٹیک کیا بنانا چاہیے - انٹرویو دیکھیں:

3. ولادیمیر اتراٹینکو، ایکس 5 ریٹیل گروپ: "انٹرپرائز میں ڈی اوپس درد اور آگ کے بغیر ترقی ہے"

کمپنیاں DevOps کی تبدیلی پر آتی ہیں جب انہیں یہ احساس ہوتا ہے کہ ترقی بہت سست ہے اور حقیقتوں پر پورا نہیں اترتی، ان کی خواہش ہوتی ہے کہ وہ بہتر ترقی کریں اور تیزی سے کام کریں۔

ولادیمیر نے بتایا کہ یہ کیسے ہوتا ہے اور کیچ کیا ہے:

1. سب سے پہلے، کمپنیاں ایک DevOps انجینئر کی خدمات حاصل کرتی ہیں۔ یہ ایک سینئر سسٹم ایڈمنسٹریٹر ہے، وہ پروڈکشن میں ریلیز کی تعیناتی، ترقیاتی ماحول کو معیاری بنانے، انفراسٹرکچر قائم کرنے، مختلف مسائل کا پتہ لگانے اور ان کو ٹھیک کرنے، خودکار عمل اور دیگر تکنیکی کاموں میں شامل ہے۔
2. پھر ایک DevOps انجینئر اب کافی نہیں ہے، اور کمپنی ایک DevOps ٹیم کی خدمات حاصل کرتی ہے۔ یہ ایک قابلیت کا مرکز ہے جو مختلف انجینئروں کی کوششوں کو منظم کرتا ہے اور انہیں ایک سمت میں مرکوز رہنے دیتا ہے۔
3. درحقیقت، DevOps انجینئر اور DevOps ٹیمیں DevOps تبدیلی کے مخالف پیٹرن ہیں۔ چونکہ DevOps طریقوں اور ثقافت کے بارے میں ہے، اس کے علاوہ، ٹیکنالوجی کمپنیوں (SRE، پروڈکشن انجینئرنگ) میں DevOps کے نفاذ موجود ہیں۔

کیا کرنا ہے؟ ایک عارضی DevOps ٹیم کی خدمات حاصل کریں جو DevOps کی تبدیلی کو نافذ کرنے، طریقوں کو انجام دینے، ترقیاتی ثقافت اور تکنیکی ثقافت کو فروغ دینے میں مدد کرے گی۔

جب کوئی کاروبار شروع ہوتا ہے اور DevOps میں سرمایہ کاری کرتا ہے، تو کئی منظرنامے ممکن ہیں: ٹیک آف پر سب کچھ الگ ہو جائے گا۔ SRE/پروڈکشن انجینئرنگ یا ایمبیڈڈ آپریشنز کے طور پر رہے گا۔ BizOps پر جائیں گے، جب عمل کاروباری میٹرکس پر مبنی ہوں گے۔

Vladimir Utratenko نے ہمیں بتایا کہ ایک انٹرپرائز میں "خونی" DevOps واقعی کس طرح ہے اور بڑے ریٹیل میں کس طرح عمل درآمد کیا جاتا ہے - انٹرویو دیکھیں:

4. Sergey Puzyrev، Facebook: "پروڈکشن انجینئر مجموعی طور پر سروس کا خیال رکھتا ہے: تاکہ صارفین اور ڈویلپر دونوں کے پاس اچھا وقت ہو"

فیس بک ایک بہت بڑی کمپنی ہے، جس کے اجزاء، سرورز، لوگ اور ڈیٹا سینٹرز کی ایک بڑی تعداد ہے۔ اس کے بڑے سائز کے باوجود، یہ بہت تیز ہے - ڈویلپرز دن میں کئی بار سروسز کو رول آؤٹ کر سکتے ہیں۔ اس کے علاوہ، فیس بک تیزی سے ترقی کر رہا ہے، اور یہ صرف صارفین اور سرورز کی تعداد ہی نہیں بڑھ رہی ہے، بلکہ ڈویلپرز کی تعداد بھی بڑھ رہی ہے، جو اس عمل کو مزید پیچیدہ بناتی ہے۔

سرجی نے بتایا کہ ایک پروڈکشن انجینئر فیس بک پر کیا کرتا ہے:

1. ایک پروڈکشن انجینئر بہت زیادہ کوڈ کرتا ہے، اس کے پاس سسٹم کا علم ہونا چاہیے: آپریٹنگ سسٹم، فائل سسٹم، ڈیٹا بیس، نیٹ ورکس اور اس طرح کے۔ تقسیم شدہ نظاموں اور قابل اعتماد انجینئرنگ کے ساتھ کام کرنے کا تجربہ ہونا چاہیے، یعنی مصنوعات کی وشوسنییتا کو سپورٹ کرنا۔ یہ آن کال ہونا چاہیے، یعنی کسی بھی وقت کال کرنے کے لیے دستیاب ہے۔
2. پروڈکشن انجینئر آپریشن میں جدید مہارت رکھنے میں سافٹ ویئر انجینئر سے مختلف ہے، لیکن درحقیقت، سافٹ ویئر انجینئر کی ذیلی قسم ہے۔ سافٹ ویئر انجینئرز زیادہ کوڈ کرتے ہیں؛ ان کے پاس اضافی مہارتیں ہوسکتی ہیں، مثال کے طور پر، ڈیٹا پروسیسنگ سے۔ فیس بک پر، ایسے ماہرین کو آن کال بھی ہونا چاہیے، جو بہت سے لوگوں کے لیے ناخوشگوار حیرت کا باعث بنتا ہے۔
3. کسی کمپنی میں پروڈکشن انجینئر کی ضروریات کا اہرام مانیٹرنگ سرورز اور ان کے لائف سائیکل سے شروع ہوتا ہے، یعنی نیا ہارڈویئر حاصل کرنا، اسے ترتیب دینا، اسے کام میں لانا۔ اگلی سطح سروس کی سطح پر ایک جیسی ہے: نگرانی کی خدمات اور ان کا لائف سائیکل۔ پھر ہموار اسکیلنگ اور جدید نگرانی آتی ہے۔ سروس لائف سائیکل کے خودکار ہونے کے بعد وہ آٹو اسکیلنگ پر سوئچ کرتے ہیں۔ اور آخر میں، ٹیوننگ کرنا ضروری ہے تاکہ اسکیلنگ موثر ہو اور کمپنی کے پیسے اور وسائل کی بچت ہو۔

5. میخائل چنکوف، AMBOSS: "ایک محکمہ DevOps کے راستے پر نہیں چل سکتا، پوری کمپنی کو اس کی پیروی کرنی چاہیے"

میخائل کا خیال ہے کہ DevOps مسلسل ترقی ہے۔ آپ کچھ ٹولز متعارف نہیں کروا سکتے اور وہیں رک نہیں سکتے۔ کون سے مسائل کمپنیوں کو DevOps بننے سے روکتے ہیں اور طریقوں کو کیسے نافذ کیا جائے؟

ڈی او اوپس کو سمجھنے میں فرق. کینونیکل ڈیوپس، جیسا کہ مبشر اسے دیکھتے ہیں، 5 ستونوں پر قائم ہے:

• ثقافت - لوگوں اور تعاون پر توجہ مرکوز کرنا؛
• آٹومیشن - کام کے بہاؤ کو معمول کا وفد؛
• دبلی پتلی - صارف کو قدر کی فراہمی پر زور؛
• اشتراک - علم کا مسلسل تبادلہ؛
• میٹرکس اور ان کا استعمال کرتے ہوئے فیڈ بیک وصول کرنا۔

کمپنیاں عام طور پر صرف آٹومیشن اور صارف کو قدر کی فراہمی پر توجہ مرکوز کرتی ہیں۔ لیکن ترقی کو ٹریک کرنے کے لیے ثقافت، علم کا اشتراک، اور DevOps میٹرکس پس منظر میں دھندلا جاتا ہے۔

DevOps معیاری بنانے کے چیلنجز. پروڈکٹ کے اہداف تمام کمپنیوں کے لیے مختلف ہیں اور معیاری نہیں ہو سکتے۔ کسی کمپنی میں DevOps کی حالت خود کمپنی پر منحصر ہوتی ہے، لیکن بہت سے لوگ یہ نہیں سمجھتے اور سمجھتے ہیں کہ DevOps انجینئر کی خدمات حاصل کرنا کافی ہے۔

ہم ابھی تک DevOps کیوں نہیں ہیں؟ دو اہم مسائل ہیں۔ انٹرپرائز میں تنظیم کی ترقی سست ہے، ہزاروں ملازمین کے ذہنوں میں ویکٹر کو تبدیل کرنے میں مشکلات ہیں۔ سٹارٹ اپس میں علم کے ذرائع کی کمی ہے اور تبدیلی کے لیے وسائل مختص کرنے میں ایک مسئلہ ہے۔

کمپنی میں DevOps کی ترقی کے مراحل:

• پہلا کلاؤڈ میں انفراسٹرکچر ہے، لیکن ایک یا دو ایڈمن کے علاوہ کوئی نہیں جانتا کہ یہ کیسے کام کرتا ہے۔
• دوسرا، بنیادی ڈھانچہ تمام انجینئرز کے لیے شفاف اور قابل فہم ہے، لیکن عمل ہموار نہیں ہیں۔
• تیسرا - انجینئرز آزادانہ طور پر لائیو سروسز کا آغاز اور مرمت کرتے ہیں۔
• چوتھا - انجینئرز اختیاری طور پر بنیادی انفراسٹرکچر، کلاؤڈ میں شفاف کوڈ، بٹن کے ذریعے تعیناتی میں حصہ ڈالیں گے۔

مثالی اسکیم یہ ہے کہ انفراسٹرکچر تک سبھی کو یکساں رسائی حاصل ہے، تمام انجینئرز کو پروڈکٹ تک رسائی حاصل ہے اور وہ سمجھتے ہیں کہ وہ کیا کر رہے ہیں۔

تمام ثقافتی اور تکنیکی گیسٹالٹس کو بند کرنے کے بعد، کمپنی کی DevOps تبدیلی کاروبار اور پلیٹ فارم میٹرکس کے تاثرات کو مدنظر رکھے گی۔

6. Rosbank کے DevOps کے شوقین: "ایک خونی کاروبار میں DevOps کو نافذ کرنے کے 1000 دن"

Rosbank سے یوری بلیچ، ڈینا مالٹسیوا، ایوگینی پانکوف نے بتایا کہ وہ تین سالوں میں ڈی او اوپس میں کیسے آئے۔ دو مقاصد تھے: مخصوص ٹیموں میں مخصوص مسائل کو حل کرنا اور مرکزی آلات کو لاگو کرنا۔

یہاں حاصل کردہ نتائج ہیں:

پروڈکٹ ٹیموں کے نتائج: 30 گنا تیز اسمبلی، 6 گنا تیز تنصیب، مکمل سائیکل پر 30 فیصد تک بچت۔ اب ہمارے پاس پیداواری صلاحیت پر جانے کے لیے بٹن دبانے کی صلاحیت ہے۔

پلیٹ فارم کمانڈز کے نتائج: 10 گنا تیز اسمبلی اور تنصیب، 87% تنصیبات کی تعداد میں اضافہ، 46% آٹو ٹیسٹ کوریج۔ انضمام کی ٹیم اب کوئی رکاوٹ نہیں ہے۔

تو، خونی انٹرپرائز میں DevOps طریقوں کو کیسے نافذ کیا جائے؟

سب سے پہلے ایک پائلٹ پراجیکٹ نافذ کریں۔: ٹیمیں منتخب کریں، فیصلہ کریں کہ فن تعمیر کو کیسے نافذ کیا جائے، اور ٹولز منتخب کریں۔ ہم نے اوپن لائسنس کے ساتھ ٹولز کا انتخاب کیا، جس میں بینک میں انسٹالیشن اور ان کے ساتھ کام کرنے میں مہارت تھی۔ Rosbank نے بیک وقت DevOps پلیٹ فارم کے ساتھ ایک نجی کلاؤڈ تعینات کیا، اور اس سے شروع میں مدد ملی۔ بادل میں، 15 منٹ میں ایک بٹن کے ٹچ پر ضروری وسائل حاصل کرنا ممکن تھا، اس سے قبل، اس طرح کے عمل میں ایک ہفتہ لگ سکتا تھا۔

بینکوں اور دیگر کاروباری اداروں میں، انفارمیشن سیکیورٹی ٹیم کے ساتھ پہلے سے پابندیوں پر کام کرنا اور ایک ایسا حل تلاش کرنا ضروری ہے جو تبدیلیوں کو لاگو کرنے کی اجازت دے۔

پائلٹ کے بعد، ایک کامیاب حل کو چھوٹا کرنے کی ضرورت ہے.

1. پائپ لائن کو زیادہ سے زیادہ "سیدھا" کرنا، اس سے غیر ضروری روابط کو ختم کرنا، قدر فراہم کرنے والوں کو نمایاں کرنا، اور بقیہ اجزاء کو ہٹانا ضروری ہے۔ انٹرمیڈیٹس اینٹی پیٹرن ہیں۔ مثال کے طور پر، Rosbank میں، متعدد ٹیموں نے اندرونی ترقی نہیں کی، صرف بیرونی ترقی کو چھوڑ کر۔ اس کی وجہ سے ایک وقف ڈیو اوپس ٹیم کا ظہور ہوا، جس نے کوڈ کی بیرونی سے اندرونی ڈویلپرز کو منتقلی کو یقینی بنایا۔ بیرونی ترقی کو CI/CD میں ضم کرکے مسئلہ حل کیا گیا، تاکہ وہ کوڈ کو نہ صرف خود سے بینک میں منتقل کریں، بلکہ اس کی کامیابی کے ذمہ دار بھی ہوں گے۔
2. میچورٹی ماڈل میں DevOps پریکٹس کے عناصر، درج کردہ ٹولز، اور بیرونی سپلائرز کے ساتھ کام کرنے کی خصوصیات کو مدنظر رکھا گیا - مستقبل میں، اس سے نئی ٹیموں میں کاموں کو لاگو کرتے وقت ان کے بیک لاگ کو تیزی سے کم کرنے میں مدد ملی۔
3. ہمیں نرم کنٹرول اور سفارشات کی صورت میں گورننس کی ضرورت ہے۔ ایک DevOps ہینڈ بک جو اچھی طرح سے کام کرتی ہے تنظیمی اور ٹولنگ خصوصیات کا ایک مجموعہ ہے جو ٹیموں کو پلیٹ فارم کو صحیح طریقے سے استعمال کرنے میں مدد کرتی ہے۔
4. آپ کو فوری طور پر ثقافت پر توجہ دینا چاہئے، پھر بہت سی تبدیلیاں تیز اور آسان ہو جائیں گی. اپنی داخلی برادری کو بڑھائیں، ملاقاتیں کریں، تکنیکی ورکشاپس، تربیتیں، اور تفریحی سرگرمیاں کریں۔ یہ پھل دیتا ہے: لوگ مشقیں بانٹتے ہیں، دیکھیں کہ کس نے کیا کیا، جانتے ہیں کہ کہاں جانا ہے، کمپنی کے اندر ہائپ اور صحت مند مقابلہ ہے۔
5. ان لوگوں کے ساتھ کام کرنے کا کوئی فائدہ نہیں ہے جو اس عمل میں شامل نہیں ہیں، ایسی ٹیموں کے ساتھ جو پختہ نہیں ہوئی ہیں؛ دلچسپی رکھنے والی ٹیموں اور وفادار لوگوں میں سرمایہ کاری کرنا بہتر ہے۔
6. منتخب کردہ حل ان انجینئرز کے لیے آسان ہونا چاہیے جو اسے استعمال کرتے ہیں۔
7. بیرونی ترقی کو روکنے والا نہیں ہے، وہاں بھی مشقیں لاگو کی جا سکتی ہیں، اصل بات یہ ہے کہ ٹیم کی خود خواہش ہے۔

تھوڑا اور فائدہ

الیگزینڈر چستیاکوف، vdsina.ru کی طرف سے ڈی او اوپس میں پڑھنے کے قابل کتابوں کی فہرست:

1. ارینا یاکوٹینکو "مرضی اور خود پر قابو۔"
2. ڈینیل Kahneman "سوچ، تیز اور سست"
3. باربرا اوکلے "نمبروں کے لئے ایک دماغ"۔
4. میکسم ڈوروفیف "جیدی تکنیک"۔
5. وکٹر فرینک "انسان کی معنی کی تلاش"۔

دیکھتے رہنا

ہمیں DevOps بھی پسند ہے۔ سیریز کے اعلانات پر عمل کریں۔ @DevOps اور @Kubernetes، نیز دیگر Mail.ru Cloud Solutions ایونٹس، ہمارے ٹیلیگرام چینل میں: t.me/k8s_mail

ماخذ: www.habr.com