Anton Weiss، Otomato Software کے بانی اور ڈائریکٹر، جو اسرائیل میں پہلے DevOps سرٹیفیکیشن کے آغاز کرنے والوں اور انسٹرکٹرز میں سے ایک ہیں، نے گزشتہ سال کی تقریب میں بات کی۔ افراتفری کے نظریہ اور افراتفری انجینئرنگ کے بنیادی اصولوں کے بارے میں، اور یہ بھی بتایا کہ مستقبل کی مثالی DevOps تنظیم کیسے کام کرتی ہے۔
ہم نے رپورٹ کا متنی ورژن تیار کیا ہے۔
صبح بخیر
مسلسل دوسرے سال ماسکو میں DevOpsDays، اس اسٹیج پر یہ میرا دوسرا موقع ہے، آپ میں سے بہت سے لوگ دوسری بار اس کمرے میں ہیں۔ اس کا کیا مطلب ہے؟ اس کا مطلب یہ ہے کہ روس میں DevOps تحریک بڑھ رہی ہے، بڑھ رہی ہے، اور سب سے اہم بات، اس کا مطلب یہ ہے کہ 2018 میں DevOps کے بارے میں بات کرنے کا وقت آگیا ہے۔
اپنے ہاتھ اٹھائیں جو سمجھتے ہیں کہ DevOps 2018 میں پہلے سے ہی ایک پیشہ ہے؟ ایسے ہیں۔ کیا کمرے میں کوئی DevOps انجینئر ہیں جن کی ملازمت کی تفصیل "DevOps انجینئر" کہتی ہے؟ کیا کمرے میں کوئی DevOps مینیجر ہیں؟ ایسا کوئی نہیں ہے۔ DevOps آرکیٹیکٹس؟ اس کے علاوہ نہیں. کافی نہیں. کیا یہ واقعی سچ ہے کہ کوئی نہیں کہتا کہ وہ ڈیو اوپس انجینئر ہیں؟
تو آپ میں سے اکثر کو لگتا ہے کہ یہ ایک اینٹی پیٹرن ہے؟ کہ کیا ایسا پیشہ نہیں ہونا چاہیے؟ ہم جو چاہیں سوچ سکتے ہیں، لیکن جب ہم سوچ رہے ہیں، صنعت سنجیدگی کے ساتھ DevOps صور کی آواز پر آگے بڑھ رہی ہے۔
DevDevOps نامی ایک نئے موضوع کے بارے میں کس نے سنا ہے؟ یہ ایک نئی تکنیک ہے جو ڈویلپرز اور ڈیوپس کے درمیان موثر تعاون کی اجازت دیتی ہے۔ اور اتنا نیا نہیں۔ ٹویٹر کے مطابق، انہوں نے 4 سال پہلے ہی اس کے بارے میں بات کرنا شروع کردی تھی۔ اور اب تک، اس میں دلچسپی بڑھ رہی ہے اور بڑھ رہی ہے، یعنی، ایک مسئلہ ہے. مسئلہ کو حل کرنے کی ضرورت ہے۔
ہم تخلیقی لوگ ہیں، ہم صرف آرام سے آرام نہیں کرتے۔ ہم کہتے ہیں: DevOps کافی جامع لفظ نہیں ہے؛ اس میں اب بھی ہر طرح کے مختلف، دلچسپ عناصر کا فقدان ہے۔ اور ہم اپنی خفیہ لیبارٹریوں میں جاتے ہیں اور دلچسپ تغیرات پیدا کرنا شروع کر دیتے ہیں: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps۔
منطق لوہے کی ہے، ٹھیک ہے؟ ہمارا ڈیلیوری سسٹم فعال نہیں ہے، ہمارے سسٹمز غیر مستحکم ہیں اور ہمارے صارفین غیر مطمئن ہیں، ہمارے پاس وقت پر سافٹ ویئر کو رول آؤٹ کرنے کا وقت نہیں ہے، ہم بجٹ میں فٹ نہیں ہیں۔ ہم یہ سب کیسے حل کریں گے؟ ہم ایک نیا لفظ لے کر آئیں گے! یہ "Ops" کے ساتھ ختم ہو جائے گا اور مسئلہ حل ہو جائے گا.
لہذا میں اس نقطہ نظر کو کال کرتا ہوں - "آپس، اور مسئلہ حل ہو گیا ہے۔"
یہ سب پس منظر میں دھندلا جاتا ہے اگر ہم خود کو یاد دلاتے ہیں کہ ہم نے یہ سب کیوں کیا۔ ہم اس پوری DevOps چیز کے ساتھ آئے ہیں تاکہ سافٹ ویئر کی ترسیل اور اس عمل میں ہمارے اپنے کام کو بلا روک ٹوک، بے درد، موثر، اور سب سے اہم بات یہ ہے کہ ہر ممکن حد تک لطف اندوز ہوں۔
ڈی او اوپس درد سے بڑھ گئے۔ اور ہم دکھوں سے تھک چکے ہیں۔ اور یہ سب کچھ ہونے کے لیے، ہم سدا بہار طریقوں پر انحصار کرتے ہیں: موثر تعاون، بہاؤ کے طریقے، اور سب سے اہم، نظام سوچ، کیونکہ اس کے بغیر کوئی ڈی او اوپس کام نہیں کرتا۔
نظام کیا ہے؟
اور اگر ہم پہلے ہی سسٹم سوچ کے بارے میں بات کر رہے ہیں تو آئیے خود کو یاد دلائیں کہ سسٹم کیا ہے۔
اگر آپ انقلابی ہیکر ہیں، تو آپ کے لیے سسٹم واضح طور پر برا ہے۔ یہ ایک بادل ہے جو آپ کے اوپر لٹکتا ہے اور آپ کو وہ کام کرنے پر مجبور کرتا ہے جو آپ نہیں کرنا چاہتے۔
نظام سوچ کے نقطہ نظر سے، ایک نظام ایک مکمل ہے جو حصوں پر مشتمل ہے. اس لحاظ سے ہم میں سے ہر ایک ایک نظام ہے۔ ہم جن تنظیموں میں کام کرتے ہیں وہ نظام ہیں۔ اور جو آپ اور میں بنا رہے ہیں اسے نظام کہتے ہیں۔
یہ سب ایک بڑے سماجی و تکنیکی نظام کا حصہ ہے۔ اور صرف اگر ہم یہ سمجھیں کہ یہ سماجی اور تکنیکی نظام کس طرح ایک ساتھ کام کرتا ہے، تب ہی ہم اس معاملے میں صحیح معنوں میں کچھ بہتر کر سکیں گے۔
نظام سوچنے کے نقطہ نظر سے، ایک نظام میں مختلف دلچسپ خصوصیات ہیں۔ سب سے پہلے، یہ حصوں پر مشتمل ہے، جس کا مطلب یہ ہے کہ اس کا رویہ حصوں کے رویے پر منحصر ہے. مزید یہ کہ اس کے تمام حصے بھی ایک دوسرے پر منحصر ہیں۔ اس سے پتہ چلتا ہے کہ سسٹم میں جتنے زیادہ حصے ہوتے ہیں، اس کے رویے کو سمجھنا یا پیش گوئی کرنا اتنا ہی مشکل ہوتا ہے۔
رویے کے نقطہ نظر سے، ایک اور دلچسپ حقیقت ہے. نظام وہ کچھ کر سکتا ہے جو اس کا کوئی بھی فرد نہیں کر سکتا۔
جیسا کہ ڈاکٹر رسل اکوف (نظام سوچ کے بانیوں میں سے ایک) نے کہا، یہ سوچے سمجھے تجربے سے ثابت کرنا کافی آسان ہے۔ مثال کے طور پر، کمرے میں کون جانتا ہے کہ کوڈ کیسے لکھنا ہے؟ بہت سارے ہاتھ ہیں، اور یہ عام بات ہے، کیونکہ یہ ہمارے پیشے کی اہم ضروریات میں سے ایک ہے۔ کیا آپ لکھنا جانتے ہیں، لیکن کیا آپ کے ہاتھ آپ سے الگ الگ کوڈ لکھ سکتے ہیں؟ ایسے لوگ ہیں جو کہیں گے: "یہ میرے ہاتھ نہیں ہیں جو کوڈ لکھتے ہیں، یہ میرا دماغ ہے جو کوڈ لکھتا ہے۔" کیا آپ کا دماغ آپ سے الگ الگ کوڈ لکھ سکتا ہے؟ ٹھیک ہے، شاید نہیں.
دماغ ایک حیرت انگیز مشین ہے، ہمیں 10 فیصد بھی نہیں معلوم کہ یہ وہاں کیسے کام کرتا ہے، لیکن یہ ہمارے جسم کے نظام سے الگ کام نہیں کر سکتا۔ اور یہ ثابت کرنا آسان ہے: اپنی کھوپڑی کھولیں، اپنا دماغ نکالیں، اسے کمپیوٹر کے سامنے رکھیں، اسے کچھ آسان لکھنے کی کوشش کرنے دیں۔ مثال کے طور پر، ازگر میں "ہیلو، دنیا"۔
اگر کوئی نظام کچھ ایسا کر سکتا ہے جو اس کا کوئی بھی حصہ الگ سے نہیں کر سکتا، تو اس کا مطلب یہ ہے کہ اس کے رویے کا تعین اس کے حصوں کے رویے سے نہیں ہوتا۔ پھر اس کا تعین کیا ہے؟ یہ ان حصوں کے درمیان تعامل کی طرف سے مقرر کیا جاتا ہے. اور اس کے مطابق، جتنے زیادہ حصے، زیادہ پیچیدہ تعاملات، نظام کے رویے کو سمجھنا اور پیش گوئی کرنا اتنا ہی مشکل ہوتا ہے۔ اور یہ اس طرح کے نظام کو افراتفری کا باعث بناتا ہے، کیونکہ نظام کے کسی بھی حصے میں کوئی بھی، حتیٰ کہ انتہائی معمولی، پوشیدہ تبدیلی مکمل طور پر غیر متوقع نتائج کا باعث بن سکتی ہے۔
ابتدائی حالات کی اس حساسیت کو سب سے پہلے امریکی ماہر موسمیات ایڈ لورینز نے دریافت کیا اور اس کا مطالعہ کیا۔ اس کے بعد، اسے "تتلی کا اثر" کہا گیا اور اس نے سائنسی فکر کی ایک تحریک کو فروغ دیا جسے "افراتفری کا نظریہ" کہا جاتا ہے۔ یہ نظریہ 20 ویں صدی کی سائنس میں ایک بڑے پیراڈائم شفٹ میں سے ایک بن گیا۔
افراتفری کا نظریہ
افراتفری کا مطالعہ کرنے والے لوگ خود کو افراتفری کے ماہر کہتے ہیں۔
درحقیقت، اس رپورٹ کی وجہ یہ تھی کہ، پیچیدہ تقسیم شدہ نظاموں اور بڑی بین الاقوامی تنظیموں کے ساتھ کام کرتے ہوئے، کسی وقت میں نے محسوس کیا کہ یہ وہی ہے جو مجھے لگتا ہے۔ میں ایک افراتفری کا ماہر ہوں۔ یہ بنیادی طور پر کہنے کا ایک ہوشیار طریقہ ہے: "میں سمجھ نہیں پا رہا ہوں کہ یہاں کیا ہو رہا ہے اور مجھے نہیں معلوم کہ اس کے بارے میں کیا کرنا ہے۔"
میرا خیال ہے کہ آپ میں سے بہت سے لوگ بھی اکثر ایسا محسوس کرتے ہیں، اس لیے آپ افراتفری کے ماہر بھی ہیں۔ میں آپ کو افراتفری کے ماہرین کی جماعت میں مدعو کرتا ہوں۔ جن سسٹمز کا آپ اور میں، پیارے ساتھی افراتفری کے ماہرین مطالعہ کریں گے، انہیں "پیچیدہ موافقت پذیر نظام" کہا جاتا ہے۔
موافقت کیا ہے؟ موافقت کا مطلب یہ ہے کہ اس طرح کے موافقت پذیر نظام میں حصوں کا انفرادی اور اجتماعی طرز عمل بدلتا ہے اور خود کو منظم کرتا ہے، نظام میں واقعات یا مائیکرو واقعات کی زنجیروں کا جواب دیتا ہے۔ یعنی نظام خود تنظیم کے ذریعے تبدیلیوں کے مطابق ہوتا ہے۔ اور خود کو منظم کرنے کی یہ صلاحیت آزاد خود مختار ایجنٹوں کے رضاکارانہ، مکمل طور پر وکندریقرت تعاون پر مبنی ہے۔
اس طرح کے نظاموں کی ایک اور دلچسپ خاصیت یہ ہے کہ وہ آزادانہ طور پر توسیع پذیر ہیں۔ بلا شبہ ہمیں کیا دلچسپی ہونی چاہیے، بطور انتشار کے ماہرین انجینئرز۔ لہذا، اگر ہم یہ کہتے ہیں کہ ایک پیچیدہ نظام کا رویہ اس کے حصوں کے تعامل سے طے ہوتا ہے، تو ہمیں کس چیز میں دلچسپی ہونی چاہیے؟ تعامل۔
دو اور دلچسپ نتائج ہیں۔
سب سے پہلے، ہم سمجھتے ہیں کہ ایک پیچیدہ نظام کو اس کے حصوں کو آسان بنا کر آسان نہیں کیا جا سکتا۔ دوسرا، پیچیدہ نظام کو آسان بنانے کا واحد طریقہ اس کے حصوں کے درمیان تعاملات کو آسان بنانا ہے۔
ہم کس طرح بات چیت کرتے ہیں؟ آپ اور میں ایک بڑے معلوماتی نظام کے حصے ہیں جسے انسانی معاشرہ کہتے ہیں۔ ہم ایک مشترکہ زبان کے ذریعے بات چیت کرتے ہیں، اگر ہمارے پاس یہ ہے، اگر ہمیں یہ مل جاتی ہے۔
لیکن زبان خود ایک پیچیدہ انکولی نظام ہے۔ اس کے مطابق، زیادہ موثر اور آسانی سے بات چیت کرنے کے لیے، ہمیں کچھ قسم کے پروٹوکول بنانے کی ضرورت ہے۔ یعنی علامتوں اور اعمال کی کچھ ترتیب جو ہمارے درمیان معلومات کے تبادلے کو آسان، زیادہ پیش گوئی، زیادہ قابل فہم بنائے گی۔
میں یہ کہنا چاہتا ہوں کہ پیچیدگی کی طرف، موافقت کی طرف، وکندریقرت کی طرف، افراتفری کی طرف رجحان ہر چیز میں پایا جا سکتا ہے۔ اور ان نظاموں میں جو آپ اور میں بنا رہے ہیں، اور ان نظاموں میں جس کا ہم حصہ ہیں۔
اور بے بنیاد نہ ہو، آئیے دیکھتے ہیں کہ ہمارے بنائے ہوئے نظام کیسے بدل رہے ہیں۔
آپ اس لفظ کا انتظار کر رہے تھے، میں سمجھ گیا۔ ہم ایک DevOps کانفرنس میں ہیں، آج یہ لفظ تقریباً ایک لاکھ بار سنا جائے گا اور پھر ہم رات کو اس کے بارے میں خواب دیکھیں گے۔
مائیکرو سروسز وہ پہلا سافٹ ویئر فن تعمیر ہے جو DevOps طریقوں کے رد عمل کے طور پر ابھرا ہے، جو ہمارے سسٹمز کو مزید لچکدار، زیادہ توسیع پذیر، اور مسلسل ترسیل کو یقینی بنانے کے لیے ڈیزائن کیا گیا ہے۔ وہ یہ کیسے کرتی ہے؟ خدمات کے حجم کو کم کرکے، ان مسائل کے دائرہ کار کو کم کرکے جن پر یہ خدمات عمل کرتی ہیں، ترسیل کے وقت کو کم کرتی ہیں۔ یعنی ہم نظام کے پرزوں کو کم اور آسان کرتے ہیں، ان کی تعداد میں اضافہ کرتے ہیں، اور اس کے مطابق ان حصوں کے درمیان تعامل کی پیچیدگی ہمیشہ بڑھ جاتی ہے، یعنی نئے مسائل جنم لیتے ہیں جن کو حل کرنا ہوتا ہے۔
مائیکرو سروسز کا اختتام نہیں ہے، مائیکرو سروسز، عام طور پر، پہلے سے ہی کل ہیں، کیونکہ سرور لیس آ رہا ہے۔ تمام سرورز جل گئے، کوئی سرور، کوئی آپریٹنگ سسٹم نہیں، صرف خالص قابل عمل کوڈ۔ کنفیگریشنز الگ ہیں، ریاستیں الگ ہیں، ہر چیز کو واقعات سے کنٹرول کیا جاتا ہے۔ خوبصورتی، صفائی، خاموشی، کوئی واقعہ، کچھ نہیں ہوتا، مکمل ترتیب۔
پیچیدگی کہاں ہے؟ مشکل، یقینا، بات چیت میں ہے. ایک فنکشن اپنے طور پر کتنا کر سکتا ہے؟ یہ دوسرے افعال کے ساتھ کیسے تعامل کرتا ہے؟ پیغام کی قطاریں، ڈیٹا بیس، بیلنسرز۔ جب ناکامی واقع ہوئی تو کسی واقعہ کو دوبارہ کیسے بنایا جائے؟ بہت سارے سوالات اور چند جوابات۔
مائیکرو سروسز اور سرور لیس وہ ہیں جنہیں ہم جیک ہپسٹرز کلاؤڈ نیٹیو کہتے ہیں۔ یہ سب بادل کے بارے میں ہے۔ لیکن بادل بھی اپنی توسیع پذیری میں فطری طور پر محدود ہے۔ ہم اسے تقسیم شدہ نظام کے طور پر سوچنے کے عادی ہیں۔ درحقیقت، کلاؤڈ فراہم کرنے والوں کے سرور کہاں رہتے ہیں؟ ڈیٹا سینٹرز میں۔ یعنی ہمارے یہاں ایک قسم کا مرکزی، بہت محدود، تقسیم شدہ ماڈل ہے۔
آج ہم سمجھتے ہیں کہ انٹرنیٹ آف تھنگز اب صرف بڑے الفاظ نہیں رہے کہ معمولی پیشین گوئیوں کے مطابق بھی اگلے پانچ سے دس سالوں میں انٹرنیٹ سے جڑے اربوں آلات ہمارے منتظر ہیں۔ مفید اور بیکار ڈیٹا کی ایک بڑی مقدار جسے کلاؤڈ میں ضم کر کے کلاؤڈ سے اپ لوڈ کیا جائے گا۔
کلاؤڈ قائم نہیں رہے گا، لہذا ہم تیزی سے کسی ایسی چیز کے بارے میں بات کر رہے ہیں جسے ایج کمپیوٹنگ کہتے ہیں۔ یا مجھے "فوگ کمپیوٹنگ" کی شاندار تعریف بھی پسند ہے۔ یہ رومانیت اور اسرار کے تصوف میں ڈوبا ہوا ہے۔
فوگ کمپیوٹنگ۔ بات یہ ہے کہ بادل پانی، بھاپ، برف اور پتھروں کے مرکزی جھرمٹ ہیں۔ اور دھند پانی کی وہ بوندیں ہیں جو فضا میں ہمارے اردگرد بکھری ہوئی ہیں۔
دھند کے نمونے میں، زیادہ تر کام ان بوندوں کے ذریعے مکمل طور پر خود مختاری سے یا دیگر بوندوں کے ساتھ مل کر کیا جاتا ہے۔ اور وہ بادل کا رخ صرف اس وقت کرتے ہیں جب وہ واقعی دبایا جاتا ہے۔
یعنی، ایک بار پھر وکندریقرت، خود مختاری، اور یقیناً، آپ میں سے بہت سے لوگ پہلے ہی سمجھ چکے ہیں کہ یہ سب کہاں جا رہا ہے، کیونکہ آپ بلاکچین کا ذکر کیے بغیر وکندریقرت کے بارے میں بات نہیں کر سکتے۔
وہ لوگ ہیں جو یقین رکھتے ہیں، یہ وہ لوگ ہیں جنہوں نے کرپٹو کرنسی میں سرمایہ کاری کی ہے۔ مثال کے طور پر، میری طرح وہ لوگ ہیں جو مانتے ہیں لیکن ڈرتے ہیں۔ اور وہ ہیں جو ایمان نہیں لاتے۔ یہاں آپ مختلف طریقے سے علاج کر سکتے ہیں. ٹیکنالوجی ہے، ایک نیا نامعلوم معاملہ ہے، مسائل ہیں۔ کسی بھی نئی ٹیکنالوجی کی طرح، یہ اس کے جوابات سے زیادہ سوالات اٹھاتی ہے۔
بلاکچین کے ارد گرد ہائپ قابل فہم ہے۔ گولڈ رش کو ایک طرف رکھتے ہوئے، ٹیکنالوجی خود ایک روشن مستقبل کے لیے قابل ذکر وعدے رکھتی ہے: زیادہ آزادی، زیادہ خود مختاری، تقسیم شدہ عالمی اعتماد۔ کیا نہیں چاہتے؟
اس کے مطابق، دنیا بھر میں زیادہ سے زیادہ انجینئرز وکندریقرت ایپلی کیشنز تیار کرنا شروع کر رہے ہیں۔ اور یہ ایک ایسی طاقت ہے جسے محض یہ کہہ کر مسترد نہیں کیا جا سکتا: "آہ، بلاکچین صرف ایک ناقص طور پر نافذ کردہ تقسیم شدہ ڈیٹا بیس ہے۔" یا جیسا کہ شکی لوگ یہ کہنا پسند کرتے ہیں: "بلاکچین کے لیے کوئی حقیقی ایپلی کیشنز نہیں ہیں۔" اگر آپ اس کے بارے میں سوچیں تو 150 سال پہلے انہوں نے بجلی کے بارے میں بھی یہی کہا تھا۔ اور وہ کچھ طریقوں سے درست بھی تھے، کیونکہ جو کچھ آج بجلی سے ممکن ہوتا ہے وہ 19ویں صدی میں ممکن نہیں تھا۔
ویسے کون جانتا ہے کہ اسکرین پر کس قسم کا لوگو ہے۔ یہ Hyperledger ہے۔ یہ ایک ایسا منصوبہ ہے جو لینکس فاؤنڈیشن کے زیر اہتمام تیار کیا جا رہا ہے اور اس میں بلاک چین ٹیکنالوجیز کا ایک سیٹ شامل ہے۔ یہ واقعی ہماری اوپن سورس کمیونٹی کی طاقت ہے۔
افراتفری انجینئرنگ
لہذا، جو نظام ہم تیار کر رہے ہیں وہ زیادہ سے زیادہ پیچیدہ، زیادہ سے زیادہ افراتفری، اور زیادہ سے زیادہ موافقت پذیر ہوتا جا رہا ہے۔ Netflix مائیکرو سروس سسٹم کے علمبردار ہیں۔ وہ اس بات کو سمجھنے والے پہلے لوگوں میں سے تھے، انہوں نے ٹولز کا ایک سیٹ تیار کیا جسے انہوں نے سمیان آرمی کہا، جن میں سب سے مشہور تھا۔ . اس نے اس کی تعریف کی جس کے نام سے جانا جاتا ہے۔ .
ویسے، رپورٹ پر کام کرنے کے عمل میں، ہم نے اس متن کا روسی زبان میں ترجمہ بھی کیا ہے، تو اس پر جائیں۔ ، پڑھنا، تبصرہ کرنا، ڈانٹنا۔
مختصراً، افراتفری انجینئرنگ کے اصول درج ذیل کہتے ہیں۔ پیچیدہ تقسیم شدہ نظام فطری طور پر غیر متوقع اور فطری طور پر چھوٹی چھوٹی ہیں۔ غلطیاں ناگزیر ہیں، جس کا مطلب ہے کہ ہمیں ان غلطیوں کو قبول کرنے اور ان سسٹمز کے ساتھ بالکل مختلف طریقے سے کام کرنے کی ضرورت ہے۔
ہمیں خود ان خامیوں کو اپنے پروڈکشن سسٹم میں متعارف کرانے کی کوشش کرنی چاہیے تاکہ اپنے سسٹمز کو اسی موافقت، خود تنظیم سازی کی اسی قابلیت، بقا کے لیے جانچیں۔
اور یہ سب کچھ بدل دیتا ہے۔ نہ صرف یہ کہ ہم سسٹمز کو پیداوار میں کیسے لانچ کرتے ہیں، بلکہ یہ بھی کہ ہم انہیں کیسے تیار کرتے ہیں، ہم ان کی جانچ کیسے کرتے ہیں۔ کوڈ کو مستحکم کرنے یا منجمد کرنے کا کوئی عمل نہیں ہے؛ اس کے برعکس، عدم استحکام کا ایک مستقل عمل ہے۔ ہم نظام کو ختم کرنے کی کوشش کر رہے ہیں اور دیکھتے ہیں کہ یہ برقرار رہتا ہے۔
تقسیم شدہ سسٹم انٹیگریشن پروٹوکول
اس کے مطابق، اس کے لیے ہمارے سسٹمز کو کسی نہ کسی طرح تبدیل کرنے کی ضرورت ہے۔ ان کے مزید مستحکم ہونے کے لیے، انہیں اپنے حصوں کے درمیان تعامل کے لیے کچھ نئے پروٹوکول کی ضرورت ہے۔ تاکہ یہ حصے متفق ہو کر کسی قسم کی خود ساختہ تنظیم کی طرف آجائیں۔ اور ہر طرح کے نئے ٹولز، نئے پروٹوکول پیدا ہوتے ہیں، جنہیں میں "تقسیم شدہ نظاموں کے تعامل کے لیے پروٹوکول" کہتا ہوں۔
میں کس بارے میں بات کر رہا ہوں؟ سب سے پہلے، منصوبے . کچھ ایک عام تقسیم شدہ ٹریکنگ پروٹوکول بنانے کی کوشش کرتے ہیں، جو پیچیدہ تقسیم شدہ نظاموں کو ڈیبگ کرنے کے لیے ایک بالکل ناگزیر ٹول ہے۔
مزید - . ہم کہتے ہیں کہ ہم اندازہ نہیں لگا سکتے کہ نظام کا کیا ہوگا، یعنی ہمیں اس کی آبزرویبلٹی، آبزرویبلٹی بڑھانے کی ضرورت ہے۔ اوپن ٹریسنگ کا تعلق ٹولز کے ایک ایسے خاندان سے ہے جو ہمارے سسٹمز کو مشاہدہ کرتے ہیں۔ لیکن ہمیں اس بات کا تعین کرنے کے لیے مشاہدے کی ضرورت ہے کہ آیا نظام اس طرح برتاؤ کرتا ہے جیسا کہ ہم اس کی توقع کرتے ہیں یا نہیں۔ ہم متوقع رویے کی وضاحت کیسے کرتے ہیں؟ کسی قسم کی پالیسی، کچھ اصولوں کا تعین کرکے۔ اوپن پالیسی ایجنٹ پروجیکٹ وسائل کی تقسیم تک رسائی سے لے کر ایک سپیکٹرم میں قواعد کے اس سیٹ کی وضاحت کرنے کے لیے کام کر رہا ہے۔
جیسا کہ ہم نے کہا، ہمارے نظام تیزی سے واقعات پر مبنی ہیں۔ سرور لیس ایونٹ سے چلنے والے نظاموں کی ایک عمدہ مثال ہے۔ ہمارے لیے سسٹمز کے درمیان واقعات کی منتقلی اور ان کا سراغ لگانے کے لیے، ہمیں کچھ مشترکہ زبان، کچھ مشترکہ پروٹوکول کی ضرورت ہے کہ ہم واقعات کے بارے میں کیسے بات کرتے ہیں، ہم انہیں ایک دوسرے تک کیسے منتقل کرتے ہیں۔ اسی کو پروجیکٹ کہتے ہیں۔ .
تبدیلیوں کا مسلسل سلسلہ جو ہمارے سسٹمز کو مسلسل غیر مستحکم کرتا ہے، سافٹ ویئر کے نمونے کا ایک مسلسل سلسلہ ہے۔ تبدیلیوں کے اس مسلسل بہاؤ کو برقرار رکھنے کے لیے، ہمیں کسی قسم کے عام پروٹوکول کی ضرورت ہے جس کے ذریعے ہم اس بارے میں بات کر سکیں کہ سافٹ ویئر آرٹفیکٹ کیا ہے، اس کی جانچ کیسے کی جاتی ہے، اس کی کیا تصدیق ہو چکی ہے۔ اسی کو پروجیکٹ کہتے ہیں۔ . یعنی، سافٹ ویئر کے نمونے کے لیے ایک عام میٹا ڈیٹا پروٹوکول۔
اور آخر میں، اگر ہم چاہتے ہیں کہ ہمارے نظام مکمل طور پر خودمختار، موافقت پذیر، اور خود منظم ہوں، تو ہمیں انہیں خود شناخت کا حق دینا چاہیے۔ پروجیکٹ کہا جاتا ہے۔ یہ بالکل وہی ہے جو وہ کرتا ہے۔ یہ Cloud Native Computing Foundation کے زیراہتمام بھی ایک پروجیکٹ ہے۔
یہ تمام منصوبے نوجوان ہیں، ان سب کو ہماری محبت، ہماری توثیق کی ضرورت ہے۔ یہ سب اوپن سورس، ہماری جانچ، ہمارا نفاذ ہے۔ وہ ہمیں دکھاتے ہیں کہ ٹیکنالوجی کہاں جا رہی ہے۔
لیکن DevOps کبھی بھی بنیادی طور پر ٹیکنالوجی کے بارے میں نہیں رہا ہے، یہ ہمیشہ لوگوں کے درمیان تعاون کے بارے میں رہا ہے۔ اور، اس کے مطابق، اگر ہم چاہتے ہیں کہ جو نظام ہم تیار کرتے ہیں وہ بدلیں، تو ہمیں خود کو بدلنا ہوگا۔ درحقیقت، ہم بہرحال بدل رہے ہیں؛ ہمارے پاس زیادہ انتخاب نہیں ہے۔
ایک شاندار ہے برطانوی مصنف ریچل بوٹسمین، جس میں وہ پوری انسانی تاریخ میں اعتماد کے ارتقاء کے بارے میں لکھتی ہیں۔ وہ کہتی ہیں کہ ابتدائی طور پر، قدیم معاشروں میں، اعتماد مقامی تھا، یعنی ہم صرف ان لوگوں پر بھروسہ کرتے تھے جنہیں ہم ذاتی طور پر جانتے تھے۔
پھر ایک بہت لمبا دور تھا - ایک تاریک دور جب اعتماد کو مرکزی حیثیت حاصل تھی، جب ہم نے ان لوگوں پر بھروسہ کرنا شروع کیا جنہیں ہم اس حقیقت کی بنیاد پر نہیں جانتے کہ ہمارا تعلق ایک ہی عوامی یا ریاستی ادارے سے ہے۔
اور یہ وہی ہے جو ہم اپنی جدید دنیا میں دیکھتے ہیں: اعتماد زیادہ سے زیادہ تقسیم اور غیر مرکزی ہوتا جا رہا ہے، اور یہ معلومات کے بہاؤ کی آزادی، معلومات کی دستیابی پر مبنی ہے۔
اگر آپ اس کے بارے میں سوچتے ہیں، تو یہی قابل رسائی، جو اس اعتماد کو ممکن بناتی ہے، وہی ہے جسے آپ اور میں نافذ کر رہے ہیں۔ اس کا مطلب یہ ہے کہ ہمارا تعاون کرنے کا طریقہ اور جس طرح سے ہم کرتے ہیں دونوں کو تبدیل ہونا چاہیے، کیونکہ پرانی مرکزی، درجہ بندی کی آئی ٹی تنظیمیں اب کام نہیں کر رہی ہیں۔ وہ مرنا شروع کر دیتے ہیں۔
DevOps تنظیم کے بنیادی اصول
مستقبل کی مثالی ڈی او اوپس تنظیم خود مختار ٹیموں پر مشتمل ایک وکندریقرت، موافقت پذیر نظام ہے، ہر ایک خود مختار افراد پر مشتمل ہے۔ یہ ٹیمیں دنیا بھر میں پھیلی ہوئی ہیں، انتہائی شفاف مواصلاتی پروٹوکول کا استعمال کرتے ہوئے، غیر مطابقت پذیر مواصلات کا استعمال کرتے ہوئے ایک دوسرے کے ساتھ مؤثر طریقے سے تعاون کر رہی ہیں۔ بہت خوبصورت، ہے نا؟ ایک بہت ہی خوبصورت مستقبل۔
یقیناً ثقافتی تبدیلی کے بغیر اس میں سے کوئی بھی ممکن نہیں۔ ہمارے پاس تبدیلی کی قیادت، ذاتی ذمہ داری، اندرونی محرک ہونا چاہیے۔
یہ DevOps تنظیموں کی بنیاد ہے: معلومات کی شفافیت، غیر مطابقت پذیر مواصلات، تبدیلی کی قیادت، وکندریقرت۔
برن آؤٹ
ہم جن نظاموں کا حصہ ہیں اور جو ہم بناتے ہیں وہ تیزی سے افراتفری کا شکار ہیں، اور ہم انسانوں کے لیے اس سوچ سے نمٹنا مشکل ہے، کنٹرول کے بھرم کو ترک کرنا مشکل ہے۔ ہم ان پر قابو پانے کی کوشش کرتے ہیں، اور یہ اکثر جل جانے کا باعث بنتا ہے۔ میں یہ اپنے تجربے سے کہتا ہوں، میں بھی جل گیا، میں پروڈکشن میں غیر متوقع ناکامیوں سے معذور بھی ہوا۔
برن آؤٹ اس وقت ہوتا ہے جب ہم کسی ایسی چیز کو کنٹرول کرنے کی کوشش کرتے ہیں جو فطری طور پر بے قابو ہے۔ جب ہم جل جاتے ہیں تو ہر چیز اپنا معنی کھو دیتی ہے کیونکہ ہم کچھ نیا کرنے کی خواہش کھو دیتے ہیں، ہم دفاعی ہو جاتے ہیں اور جو کچھ ہمارے پاس ہے اس کا دفاع کرنا شروع کر دیتے ہیں۔
انجینئرنگ کا پیشہ، جیسا کہ میں اکثر اپنے آپ کو یاد دلانا چاہتا ہوں، سب سے پہلے اور سب سے اہم تخلیقی پیشہ ہے۔ اگر ہم کسی چیز کو بنانے کی خواہش کھو دیں تو ہم راکھ میں بدل جاتے ہیں، راکھ میں بدل جاتے ہیں۔ لوگ جل جاتے ہیں، پوری تنظیمیں جل جاتی ہیں۔
میری رائے میں، صرف افراتفری کی تخلیقی طاقت کو قبول کرنا، اس کے اصولوں کے مطابق تعاون کی تعمیر ہی وہ چیز ہے جو ہمارے پیشے میں اچھی چیز کو کھونے سے بچنے میں ہماری مدد کرے گی۔
میں آپ کے لیے یہی چاہتا ہوں: اپنے کام سے پیار کرنا، جو ہم کرتے ہیں اس سے پیار کرنا۔ یہ دنیا معلومات پر پلتی ہے، اسے کھلانے کا اعزاز ہمیں حاصل ہے۔ تو آئیے افراتفری کا مطالعہ کریں، آئیے افراتفری کے ماہر بنیں، آئیے قدر لائیں، کچھ نیا بنائیں، ٹھیک ہے، مسائل، جیسا کہ ہم پہلے ہی جان چکے ہیں، ناگزیر ہیں، اور جب وہ ظاہر ہوں گے، تو ہم بس کہیں گے "Ops!" اور مسئلہ حل ہو جاتا ہے۔
افراتفری کے بندر کے علاوہ اور کیا ہے؟
درحقیقت یہ تمام آلات بہت کم عمر ہیں۔ اسی نیٹ فلکس نے اپنے لیے ٹولز بنائے۔ اپنے اوزار بنائیں۔ افراتفری انجینئرنگ کے اصولوں کو پڑھیں اور ان اصولوں پر قائم رہیں بجائے اس کے کہ دوسرے ٹولز کو تلاش کرنے کی کوشش کریں جو کسی اور نے پہلے سے ہی بنائے ہیں۔
یہ سمجھنے کی کوشش کریں کہ آپ کے سسٹم کیسے ٹوٹتے ہیں اور ان کو توڑنا شروع کریں اور دیکھیں کہ وہ کیسے برقرار ہیں۔ یہ پہلے آتا ہے۔ اور آپ ٹولز تلاش کر سکتے ہیں۔ ہر طرح کے منصوبے ہیں۔
مجھے اس لمحے کی سمجھ نہیں آئی جب آپ نے کہا کہ سسٹم کو اس کے اجزاء کو آسان بنا کر آسان نہیں بنایا جا سکتا، اور فوری طور پر مائیکرو سروسز کی طرف چلا گیا، جو خود اجزاء کو آسان بنا کر اور تعاملات کو پیچیدہ بنا کر سسٹم کو آسان بناتا ہے۔ یہ بنیادی طور پر دو حصے ہیں جو ایک دوسرے سے متصادم ہیں۔
یہ ٹھیک ہے، مائیکرو سروسز عام طور پر ایک بہت ہی متنازعہ موضوع ہے۔ درحقیقت، حصوں کو آسان بنانے سے لچک میں اضافہ ہوتا ہے۔ مائیکرو سروسز کیا فراہم کرتی ہیں؟ وہ ہمیں لچک اور رفتار دیتے ہیں، لیکن وہ یقینی طور پر ہمیں سادگی نہیں دیتے۔ وہ مشکلات میں اضافہ کرتے ہیں۔
تو، DevOps فلسفہ میں، microservices اتنی اچھی چیز نہیں ہیں؟
کسی بھی نیکی کا الٹا پہلو ہوتا ہے۔ فائدہ یہ ہے کہ یہ لچک کو بڑھاتا ہے، ہمیں تیزی سے تبدیلیاں کرنے کی اجازت دیتا ہے، لیکن یہ پیچیدگی اور پورے نظام کی نزاکت کو بڑھاتا ہے۔
پھر بھی، زیادہ زور کیا ہے: بات چیت کو آسان بنانے پر یا حصوں کو آسان بنانے پر؟
بلاشبہ، بات چیت کو آسان بنانے پر زور دیا جاتا ہے، کیونکہ اگر ہم اس کو اس نقطہ نظر سے دیکھیں کہ ہم آپ کے ساتھ کیسے کام کرتے ہیں، تو سب سے پہلے، ہمیں بات چیت کو آسان بنانے پر توجہ دینے کی ضرورت ہے، نہ کہ کام کو آسان بنانے پر۔ ہم میں سے ہر ایک کے الگ الگ۔ کیونکہ کام کو آسان بنانے کا مطلب روبوٹ میں تبدیل ہونا ہے۔ یہاں میکڈونلڈ میں یہ عام طور پر کام کرتا ہے جب آپ کو ہدایات ملتی ہیں: یہاں آپ برگر ڈالتے ہیں، یہاں آپ اس پر چٹنی ڈالتے ہیں۔ یہ ہمارے تخلیقی کام میں بالکل بھی کام نہیں کرتا۔
کیا یہ سچ ہے کہ آپ کی کہی ہوئی ہر چیز بغیر مقابلہ کے دنیا میں رہتی ہے، اور وہاں کی افراتفری بہت مہربان ہے، اور اس افراتفری کے اندر کوئی تضاد نہیں ہے، کوئی کسی کو کھانا یا مارنا نہیں چاہتا؟ مقابلہ اور DevOps کا کرایہ کیسے ہونا چاہئے؟
ٹھیک ہے، یہ اس بات پر منحصر ہے کہ ہم کس قسم کے مقابلے کی بات کر رہے ہیں۔ کیا یہ کام کی جگہ پر مقابلہ ہے یا کمپنیوں کے درمیان مقابلہ؟
خدمات کے مقابلے کے بارے میں جو موجود ہیں کیونکہ خدمات کئی کمپنیاں نہیں ہیں۔ ہم ایک نئی قسم کا معلوماتی ماحول بنا رہے ہیں، اور کوئی بھی ماحول مقابلہ کے بغیر نہیں رہ سکتا۔ ہر جگہ مقابلہ ہے۔
وہی Netflix، ہم انہیں ایک رول ماڈل کے طور پر لیتے ہیں۔ وہ اس کے ساتھ کیوں آئے؟ کیونکہ انہیں مقابلہ کرنے کی ضرورت تھی۔ نقل و حرکت کی یہ لچک اور رفتار بالکل مسابقتی ضرورت ہے؛ یہ ہمارے نظام میں افراتفری کو متعارف کراتی ہے۔ یعنی افراتفری وہ چیز نہیں ہے جو ہم شعوری طور پر کرتے ہیں کیونکہ ہم یہ چاہتے ہیں، یہ وہ چیز ہے جو اس لیے ہوتی ہے کہ دنیا اس کا مطالبہ کرتی ہے۔ ہمیں بس اپنانا ہے۔ اور افراتفری، یہ بالکل مقابلہ کا نتیجہ ہے.
کیا اس کا مطلب یہ ہے کہ افراتفری مقاصد کی عدم موجودگی ہے، جیسا کہ یہ تھے؟ یا وہ مقاصد جو ہم نہیں دیکھنا چاہتے؟ ہم گھر میں ہیں اور دوسروں کے مقاصد کو نہیں سمجھتے۔ مقابلہ، درحقیقت، اس حقیقت کی وجہ سے ہے کہ ہمارے پاس واضح اہداف ہیں اور ہم جانتے ہیں کہ ہم وقت کے ہر اگلے لمحے کہاں پہنچیں گے۔ یہ، میرے نقطہ نظر سے، DevOps کا جوہر ہے۔
سوال پر بھی ایک نظر۔ میرے خیال میں ہم سب کا ایک ہی مقصد ہے: زندہ رہنا اور اس کے ساتھ کرنا
سب سے بڑی خوشی. اور کسی بھی تنظیم کا مسابقتی ہدف ایک ہی ہوتا ہے۔ بقا اکثر مقابلے کے ذریعے ہوتی ہے، اس کے بارے میں آپ کچھ نہیں کر سکتے۔
اس سال کی کانفرنس 7 دسمبر کو Technopolis میں منعقد ہوگا۔ ہم 11 نومبر تک رپورٹس کے لیے درخواستیں قبول کر رہے ہیں۔ اگر آپ بات کرنا چاہتے ہیں تو ہم سے۔
شرکاء کے لیے رجسٹریشن کھلا ہے، ٹکٹ کی قیمت 7000 روبل ہے۔ ہمارے ساتھ شامل ہوں!
ماخذ: www.habr.com