آپ نے یقینی طور پر سوچا ہوگا کہ آپ کے پروجیکٹ کے انفراسٹرکچر کی قیمت کتنی ہے۔ ایک ہی وقت میں، یہ حیرت انگیز ہے: لاگت میں اضافہ بوجھ کے حوالے سے خطی نہیں ہے۔ بہت سے کاروباری مالکان، سروس سٹیشنز اور ڈویلپرز خفیہ طور پر سمجھتے ہیں کہ وہ زیادہ ادائیگی کر رہے ہیں۔ لیکن بالکل کس لیے؟
عام طور پر، لاگت میں کمی صرف سستا حل تلاش کرنے، AWS پلان، یا، فزیکل ریک کے معاملے میں، ہارڈ ویئر کی ترتیب کو بہتر بنانے پر آتی ہے۔ صرف یہی نہیں: درحقیقت، کوئی بھی ایسا کر رہا ہے، جیسا کہ خدا چاہتا ہے: اگر ہم ایک سٹارٹ اپ کے بارے میں بات کر رہے ہیں، تو یہ غالباً ایک سرکردہ ڈویلپر ہے جسے کافی سر درد ہے۔ بڑے دفاتر میں، یہ سی ایم او/سی ٹی او کے ذریعے نمٹا جاتا ہے، اور بعض اوقات جنرل ڈائریکٹر ذاتی طور پر چیف اکاؤنٹنٹ کے ساتھ مل کر اس معاملے میں شامل ہو جاتے ہیں۔ عام طور پر، وہ لوگ جو کافی "بنیادی" خدشات رکھتے ہیں. اور یہ پتہ چلتا ہے کہ انفراسٹرکچر کے بل بڑھ رہے ہیں، لیکن جن کے پاس اس سے نمٹنے کا وقت نہیں ہے وہ اس سے نمٹ رہے ہیں۔
اگر آپ کو دفتر کے لیے ٹوائلٹ پیپر خریدنے کی ضرورت ہے، تو یہ سپلائی مینیجر یا صفائی کرنے والی کمپنی کا کوئی ذمہ دار شخص کرے گا۔ اگر ہم ترقی کے بارے میں بات کر رہے ہیں - لیڈز اور سی ٹی او۔ سیلز - سب کچھ بھی واضح ہے. لیکن پرانے دنوں سے، جب "سرور روم" ایک کابینہ کا نام تھا جس میں چھاپے میں تھوڑی زیادہ ریم اور دو ہارڈ ڈرائیوز کے ساتھ ایک عام ٹاور سسٹم ہوتا تھا، ہر کوئی (یا کم از کم بہت سے) اس کو نظر انداز کرتا تھا۔ حقیقت یہ ہے کہ صلاحیت کی خریداری کو بھی ایک خاص تربیت یافتہ شخص سے سنبھالنا چاہئے۔
افسوس، تاریخی یادداشت اور تجربہ بتاتا ہے کہ کئی دہائیوں سے یہ کام "بے ترتیب" لوگوں کو منتقل کیا گیا تھا: جو بھی قریب ترین تھا اس نے سوال اٹھایا۔ اور حال ہی میں FinOps کے پیشہ نے مارکیٹ میں شکل اختیار کرنا شروع کی اور کچھ ٹھوس شکل اختیار کی۔ یہ وہی خاص تربیت یافتہ شخص ہے جس کا کام صلاحیت کی خریداری اور استعمال کو کنٹرول کرنا ہے۔ اور، بالآخر، اس علاقے میں کمپنی کے اخراجات کو کم کرنے میں۔
ہم مہنگے اور موثر حلوں کو ترک کرنے کی وکالت نہیں کر رہے ہیں: ہر کاروبار کو خود فیصلہ کرنا چاہیے کہ اسے ہارڈ ویئر اور کلاؤڈ ٹیرف کے لحاظ سے آرام دہ وجود کے لیے کیا ضرورت ہے۔ لیکن کوئی مدد نہیں کر سکتا لیکن اس حقیقت پر توجہ نہیں دے سکتا کہ بہت سی کمپنیوں کے استعمال کی نگرانی اور تجزیہ کیے بغیر "فہرست کے مطابق" بغیر سوچے سمجھے خریداری کا نتیجہ بالآخر ان کے پس منظر کے "اثاثوں" کے غیر موثر انتظام کی وجہ سے بہت، بہت اہم نقصانات کا باعث بنتا ہے۔
FinOps کون ہے۔
فرض کریں کہ آپ کے پاس ایک معروف انٹرپرائز ہے، جس کے سیلز لوگ "انٹرپرائز" کے بارے میں ایک دم بھرے لہجے میں بات کرتے ہیں۔ شاید، "فہرست کے مطابق" آپ نے ایک درجن یا دو سرورز، AWS اور کچھ دوسری "چھوٹی چیزیں" خریدی ہیں۔ جو منطقی ہے: ایک بڑی کمپنی میں کسی نہ کسی قسم کی حرکت مسلسل ہوتی رہتی ہے - کچھ ٹیمیں بڑھ جاتی ہیں، کچھ ٹوٹ جاتی ہیں، دوسروں کو پڑوسی منصوبوں میں منتقل کر دیا جاتا ہے۔ اور ان تحریکوں کا مجموعہ، "لسٹ پر مبنی" پروکیورمنٹ میکانزم کے ساتھ، اگلے ماہانہ انفراسٹرکچر بل کو دیکھتے ہوئے بالآخر نئے سرمئی بالوں کی طرف لے جاتا ہے۔
تو کیا کرنا ہے - صبر کے ساتھ سرمئی کرنا جاری رکھیں، اس پر پینٹ کریں، یا ادائیگی میں ان بے شمار خوفناک صفروں کے ظاہر ہونے کی وجوہات معلوم کریں؟
آئیے ایماندار بنیں: اسی AWS ٹیرف کے لیے کمپنی کے اندر کسی درخواست کی منظوری، منظوری اور براہ راست ادائیگی ہمیشہ (حقیقت میں، تقریباً کبھی نہیں) جلدی نہیں ہوتی۔ اور خاص طور پر مسلسل کارپوریٹ تحریک کی وجہ سے، ان میں سے کچھ ایک جیسے حصول کہیں "کھو" گئے ہیں۔ اور بیکار کھڑا رہنا معمولی بات ہے۔ اگر ایک دھیان رکھنے والا منتظم اپنے سرور روم میں ایک مالک کے بغیر ریک کو دیکھتا ہے، تو کلاؤڈ ٹیرف کے معاملے میں سب کچھ زیادہ افسوسناک ہے۔ انہیں مہینوں تک رکھا جا سکتا ہے - جس کے لیے ادائیگی کی جاتی ہے، لیکن اس کے ساتھ ہی اس محکمے میں جس کے لیے وہ خریدے گئے تھے، ان کی مزید ضرورت نہیں۔ اسی وقت، اگلے دفتر کے ساتھی نہ صرف اپنے سروں پر بلکہ دیگر جگہوں پر بھی اپنے ابھی تک سفید بال نہیں پھاڑنا شروع کر دیتے ہیں - وہ نویں ہفتے کے لیے تقریباً اسی AWS ٹیرف کی ادائیگی کرنے کے قابل نہیں رہے، جو کی اشد ضرورت ہے.
سب سے واضح حل کیا ہے؟ یہ ٹھیک ہے، باگ ڈور ضرورت مندوں کے حوالے کر دو، اور سب خوش ہیں۔ لیکن افقی مواصلات ہمیشہ اچھی طرح سے قائم نہیں ہوتے ہیں۔ اور دوسرے محکمے کو شاید پہلے کی دولت کے بارے میں علم نہ ہو جو کسی نہ کسی طرح یہ نکلا کہ واقعی اس دولت کی ضرورت نہیں ہے۔
اس کا ذمہ دار کون ہے؟ - اصل میں، کوئی نہیں. فی الحال سب کچھ اسی طرح ترتیب دیا گیا ہے۔
کون اس کا شکار ہے؟ - یہ ہے، پوری کمپنی.
کون حالات کو ٹھیک کر سکتا ہے؟ - ہاں، ہاں، FinOps۔
FinOps صرف ڈویلپرز اور ان کی ضرورت کے سامان کے درمیان ایک پرت نہیں ہے، بلکہ ایک شخص یا ٹیم جو یہ جان سکے گی کہ کمپنی کی طرف سے خریدے گئے کلاؤڈ ٹیرف کے لحاظ سے یہ کہاں، کیا اور کتنی اچھی طرح سے "جھوٹ" ہے۔ درحقیقت، ان لوگوں کو ایک طرف DevOps کے ساتھ مل کر کام کرنا چاہیے، اور دوسری طرف فنانس ڈیپارٹمنٹ، ایک موثر ثالث اور سب سے اہم، ایک تجزیہ کار کا کردار ادا کرنا چاہیے۔
اصلاح کے بارے میں تھوڑا سا
بادل۔ نسبتاً سستا اور بہت آسان۔ لیکن یہ حل سستا ہونا بند ہو جاتا ہے جب سرورز کی تعداد دوہرے یا تین ہندسوں تک پہنچ جاتی ہے۔ اس کے علاوہ، بادل زیادہ سے زیادہ خدمات کو استعمال کرنا ممکن بناتے ہیں جو پہلے دستیاب نہیں تھیں: یہ ڈیٹا بیس بطور سروس (Amazon AWS، Azure Database)، سرور لیس ایپلی کیشنز (AWS Lambda، Azure Functions) اور بہت سی دوسری ہیں۔ وہ سب بہت اچھے ہیں کیونکہ وہ استعمال میں آسان ہیں - خریدیں اور جائیں، کوئی مسئلہ نہیں۔ لیکن کمپنی اور اس کے منصوبے جتنی گہرے بادلوں میں ڈوبتے ہیں، سی ایف او کی نیند اتنی ہی خراب ہوتی ہے۔ اور جتنی تیزی سے جنرل گرے ہو جاتا ہے۔
حقیقت یہ ہے کہ مختلف کلاؤڈ سروسز کے انوائسز ہمیشہ انتہائی الجھے ہوئے ہوتے ہیں: ایک آئٹم کے لیے آپ کو تین صفحات پر مشتمل وضاحت مل سکتی ہے کہ آپ کا پیسہ کیا، کہاں اور کیسے گیا۔ یہ، بلاشبہ، خوشگوار ہے، لیکن اسے سمجھنا تقریباً ناممکن ہے۔ مزید یہ کہ، اس مسئلے پر ہماری رائے صرف ایک سے بہت دور ہے: کلاؤڈ اکاؤنٹس کو انسانوں میں منتقل کرنے کے لیے، پوری خدمات موجود ہیں، مثال کے طور پر یا . اگر کسی نے بلوں کو سمجھنے کے لیے الگ سروس بنانے کی زحمت کی، تو مسئلہ کے پیمانے نے بالوں کے رنگنے کی قیمت کو بڑھا دیا ہے۔
تو اس صورت حال میں FinOps کیا کرتا ہے:
- واضح طور پر سمجھتا ہے کہ کلاؤڈ حل کب اور کن حجم میں خریدے گئے تھے۔
- جانتا ہے کہ ان صلاحیتوں کو کس طرح استعمال کیا جاتا ہے۔
- کسی خاص یونٹ کی ضروریات کے مطابق انہیں دوبارہ تقسیم کرتا ہے۔
- نہیں خریدتا ہے "تاکہ یہ ہو"۔
- اور آخر میں، یہ آپ کے پیسے بچاتا ہے.
ایک عمدہ مثال ڈیٹا بیس کی کولڈ کاپی کا کلاؤڈ اسٹوریج ہے۔ مثال کے طور پر، کیا آپ اسٹوریج کو اپ ڈیٹ کرتے وقت استعمال ہونے والی جگہ اور ٹریفک کی مقدار کو کم کرنے کے لیے اسے محفوظ کرتے ہیں؟ ہاں، ایسا لگتا ہے کہ صورت حال سستی ہے - کسی ایک مخصوص معاملے میں، لیکن اس طرح کے سستے حالات کا مجموعی نتیجہ بعد میں کلاؤڈ سروسز کے لیے بہت زیادہ اخراجات کا باعث بنتا ہے۔
یا دوسری صورت حال: آپ نے AWS یا Azure پر ریزرو صلاحیت خریدی ہے تاکہ زیادہ بوجھ میں نہ آئیں۔ کیا آپ یقین کر سکتے ہیں کہ یہ بہترین حل ہے؟ سب کے بعد، اگر یہ مثالیں 80٪ بیکار ہیں، تو آپ صرف Amazon کو پیسے دے رہے ہیں۔ مزید برآں، اس طرح کے معاملات کے لیے، ایک ہی AWS اور Azure میں پھٹنے کے قابل مثالیں ہیں - اگر آپ چوٹی کے بوجھ کے مسائل کو حل کرنے کے لیے کوئی ٹول استعمال کر سکتے ہیں تو آپ کو آئیڈلنگ سرورز کی ضرورت کیوں ہے؟ یا، On Premise مثالوں کے بجائے، آپ کو Reserved کی طرف دیکھنا چاہیے - وہ بہت سستے ہیں اور وہ چھوٹ بھی پیش کرتے ہیں۔
ویسے، چھوٹ کے بارے میں
جیسا کہ ہم نے شروع میں کہا، خریداری اکثر کسی کے ذریعہ کی جاتی ہے - انہوں نے آخری پایا، اور پھر وہ کسی نہ کسی طرح خود کرتا ہے۔ اکثر، جو لوگ پہلے سے مصروف ہیں وہ "انتہائی" ہو جاتے ہیں، اور اس کے نتیجے میں ہمیں ایک ایسی صورتحال ملتی ہے جہاں ایک شخص جلدی اور مہارت سے، لیکن مکمل طور پر آزادانہ طور پر فیصلہ کرتا ہے کہ کیا اور کس مقدار میں خریدنا ہے۔
لیکن جب کلاؤڈ سروس سے سیلز پرسن کے ساتھ بات چیت کرتے ہیں، تو آپ کو زیادہ سازگار حالات مل سکتے ہیں جب بات صلاحیت کی تھوک خریداری کی ہو۔ یہ واضح ہے کہ آپ خاموش اور یکطرفہ رجسٹریشن والی کار سے ایسی رعایتیں حاصل نہیں کر پائیں گے - لیکن ایک حقیقی سیلز مینیجر سے بات کرنے کے بعد، آپ جل سکتے ہیں۔ یا یہ لوگ آپ کو بتا سکتے ہیں کہ ان کے پاس فی الحال کس چیز پر چھوٹ ہے۔ یہ مفید بھی ہو سکتا ہے۔
ایک ہی وقت میں، آپ کو یہ یاد رکھنے کی ضرورت ہے کہ روشنی AWS یا Azure پر ایک پچر کی طرح نہیں ملتی تھی۔ بلاشبہ، آپ کے اپنے سرور روم کو منظم کرنے کا کوئی سوال نہیں ہے - لیکن جنات کی طرف سے ان دو کلاسک حلوں کے متبادل موجود ہیں۔
مثال کے طور پر، گوگل کمپنیوں کے لیے Firebase پلیٹ فارم لایا، جس پر وہ ٹرن کی بنیاد پر ایک ہی موبائل پروجیکٹ کی میزبانی کر سکتے ہیں، جس کے لیے تیزی سے اسکیلنگ کی ضرورت پڑ سکتی ہے۔ اس حل کو بطور مثال استعمال کرتے ہوئے اسٹوریج، ریئل ٹائم ڈیٹا بیس، ہوسٹنگ اور کلاؤڈ ڈیٹا سنکرونائزیشن ایک جگہ پر دستیاب ہیں۔
دوسری طرف، اگر ہم یک سنگی پراجیکٹ کے بارے میں بات نہیں کر رہے ہیں، بلکہ ان کے مکمل ہونے کے بارے میں بات کر رہے ہیں، تو ایک مرکزی حل ہمیشہ فائدہ مند نہیں ہوتا ہے۔ اگر پروجیکٹ طویل المدت ہے، اس کی اپنی ترقی کی تاریخ ہے اور ذخیرہ کرنے کے لیے مطلوبہ ڈیٹا کی اسی مقدار ہے، تو یہ مزید بکھری جگہ کے بارے میں سوچنے کے قابل ہے۔
کلاؤڈ سروسز کے لیے لاگت کو بہتر بناتے وقت، آپ کو اچانک یہ احساس ہو سکتا ہے کہ کاروباری لحاظ سے اہم ایپلی کیشنز کے لیے آپ زیادہ طاقتور ٹیرف خرید سکتے ہیں جو کمپنی کو بلاتعطل آمدنی فراہم کرے گا۔ ایک ہی وقت میں، ترقی کی "وراثت"، پرانے آرکائیوز، ڈیٹا بیس وغیرہ کو مہنگے بادلوں میں محفوظ کرنا ایک حل ہے۔ بہر حال، ایسے ڈیٹا کے لیے، بغیر کسی گھنٹی اور سیٹی کے باقاعدہ HDDs اور میڈیم پاور ہارڈ ویئر والا معیاری ڈیٹا سینٹر کافی موزوں ہے۔
یہاں ایک بار پھر، آپ سوچ سکتے ہیں کہ "یہ ہنگامہ آرائی اس کے قابل نہیں ہے،" لیکن اس اشاعت کا سارا مسئلہ اس حقیقت پر مبنی ہے کہ مختلف مراحل پر ذمہ دار چھوٹی چھوٹی باتوں کو نظر انداز کر دیتے ہیں اور وہ کام کرتے ہیں جو زیادہ آسان اور تیز ہو۔ جس کے آخر میں، چند سالوں کے بعد ان انتہائی خوفناک اکاؤنٹس کا نتیجہ نکلتا ہے۔
نتیجہ؟
عام طور پر، بادل ٹھنڈے ہوتے ہیں، وہ کسی بھی سائز کے کاروبار کے لیے بہت سے مسائل حل کرتے ہیں۔ تاہم، اس رجحان کے نئے ہونے کا مطلب یہ ہے کہ ہمارے پاس اب بھی استعمال اور انتظام کا کلچر نہیں ہے۔ FinOps ایک تنظیمی لیور ہے جو آپ کو زیادہ مؤثر طریقے سے کلاؤڈ پاور کا فائدہ اٹھانے میں مدد کرتا ہے۔ اہم بات یہ نہیں ہے کہ اس پوزیشن کو فائرنگ اسکواڈ کے ینالاگ میں تبدیل کیا جائے، جس کا کام غافل ڈویلپرز کو ہاتھ سے پکڑنا اور انہیں وقت کے لیے "ڈانٹنا" ہے۔
ڈویلپرز کو ترقی کرنی چاہیے، کمپنی کے پیسے کو شمار نہیں کرنا چاہیے۔ اور اس لیے FinOps کو خریداری کے عمل اور دیگر ٹیموں کو کلاؤڈ کی صلاحیت کو ختم کرنے یا منتقل کرنے کے عمل دونوں کو تمام فریقین کے لیے ایک آسان اور خوشگوار ایونٹ بنانا چاہیے۔
ماخذ: www.habr.com