ويبينار ۾ خراب آڊيو آهي، تنهنڪري اسان ان کي نقل ڪيو آهي.
منهنجو نالو Medvedev Eduard آهي. اڄ مان ڳالهائيندس SRE ڇا آهي، SRE ڪيئن ظاهر ٿيو، SRE انجنيئرن لاءِ ڪم جا معيار ڪهڙا آهن، ٿورڙو اعتبار جي معيار بابت، ٿورڙو ان جي نگراني بابت. اسان چوٽيءَ تي هلنداسين، ڇاڪاڻ ته توهان هڪ ڪلاڪ ۾ گهڻو ڪجهه نٿا ٻڌائي سگهو، پر مان اضافي جائزو لاءِ مواد ڏيندس، ۽ اسان سڀ توهان جي انتظار ۾ آهيون. . جنوري جي آخر ۾ ماسڪو ۾.
پهرين، اچو ته ان بابت ڳالهايون ڇا آهي SRE - Site Reliability Engineering. ۽ اهو ڪيئن ظاهر ٿيو هڪ الڳ پوزيشن طور، هڪ الڳ هدايت جي طور تي. اهو سڀ حقيقت سان شروع ٿيو ته روايتي ترقي جي حلقن ۾، ديو ۽ اوپس ٻه مڪمل طور تي مختلف ٽيمون آهن، عام طور تي ٻه مڪمل طور تي مختلف مقصدن سان. ڊولپمينٽ ٽيم جو مقصد نون خصوصيتن کي رول ڪرڻ ۽ ڪاروبار جي ضرورتن کي پورو ڪرڻ آهي. Ops ٽيم جو مقصد اهو يقيني بڻائڻ آهي ته هر شي ڪم ڪري ٿي ۽ ڪجھ به نه ڀڃي. ظاهر آهي، اهي مقصد سڌو سنئون هڪ ٻئي سان تضاد ڪن ٿا: هر شي ڪم ڪرڻ لاءِ ۽ ڪجهه به نه ٽوڙڻ لاءِ، نئين خاصيتن کي گهٽ ۾ گهٽ وڌو. انهي جي ڪري، اتي ڪيترائي اندروني تضاد آهن جيڪي طريقا جيڪي هاڻي DevOps سڏيو ويندو آهي حل ڪرڻ جي ڪوشش ڪري رهيا آهن.
مسئلو اهو آهي ته اسان وٽ DevOps جي واضح تعريف ۽ DevOps جو واضح نفاذ ناهي. مون 2 سال اڳ يڪاترينبرگ ۾ هڪ ڪانفرنس ۾ ڳالهايو، ۽ هينئر تائين DevOps سيڪشن رپورٽ سان شروع ٿيو ”ڇا آهي DevOps“. 2017 ۾، Devops تقريبا 10 سالن جي عمر آهي، پر اسان اڃا تائين بحث ڪري رهيا آهيون ته اهو ڇا آهي. ۽ اها هڪ تمام عجيب صورتحال آهي جيڪا گوگل ڪجهه سال اڳ حل ڪرڻ جي ڪوشش ڪئي.
2016 ۾، گوگل سائٽ ريليبلٽي انجنيئرنگ نالي هڪ ڪتاب جاري ڪيو. ۽ حقيقت ۾، اهو هن ڪتاب سان هو ته SRE تحريڪ شروع ٿي. SRE هڪ مخصوص ڪمپني ۾ DevOps paradigm جو هڪ مخصوص عمل آهي. SRE انجنيئرن کي يقيني بڻائڻ لاءِ پرعزم آهن ته سسٽم معتبر طريقي سان هلن. اهي گهڻو ڪري ڊولپرز کان ايندا آهن، ڪڏهن ڪڏهن منتظمين کان هڪ مضبوط ترقي جي پس منظر سان. ۽ اھي ڪندا آھن جيڪي سسٽم منتظم ڪندا ھئا، پر ڪوڊ جي لحاظ کان سسٽم جي ترقي ۽ ڄاڻ ۾ ھڪڙو مضبوط پس منظر ان حقيقت جو سبب بڻجي ٿو ته اھي ماڻھو معمولي انتظامي ڪم ڏانھن مائل نه آھن، پر خودڪار طريقي سان مائل آھن.
اهو ظاهر ٿئي ٿو ته SRE ٽيمن ۾ DevOps پيراگراف هن حقيقت تي عمل ڪيو ويو آهي ته SRE انجنيئر آهن جيڪي ساختماني مسئلن کي حل ڪن ٿا. هتي اهو آهي، ديو ۽ اوپس جي وچ ۾ ساڳيو تعلق آهي جنهن بابت ماڻهو 8 سالن کان ڳالهائي رهيا آهن. هڪ SRE جو ڪردار هڪ معمار جي ڪردار وانگر هوندو آهي جنهن ۾ نوان ماڻهو SRE نه ٿيندا آهن. ماڻهو پنهنجي ڪيريئر جي شروعات ۾ اڃا تائين ڪو به تجربو نه آهي، علم جي گهربل ماني نه آهي. ڇو ته SRE جي ضرورت آھي ھڪڙي تمام ذيلي ڄاڻ جي بلڪل صحيح طور تي ڇا ۽ جڏھن بلڪل غلط ٿي سگھي ٿو. تنهن ڪري، هتي ڪجهه تجربي جي ضرورت آهي، ضابطي جي طور تي، ڪمپني جي اندر ۽ ٻاهران.
اهي پڇن ٿا ته ڇا SRE ۽ devps جي وچ ۾ فرق بيان ڪيو ويندو. هوء صرف بيان ڪئي وئي آهي. اسان تنظيم ۾ SRE جي جڳهه بابت ڳالهائي سگهون ٿا. هن کلاسک DevOps طريقي جي برعڪس، جتي Ops اڃا تائين هڪ الڳ ڊپارٽمينٽ آهي، SRE ترقياتي ٽيم جو حصو آهي. اهي پيداوار جي ترقي ۾ ملوث آهن. اتي به ھڪڙو طريقو آھي جتي SRE ھڪڙو ڪردار آھي جيڪو ھڪڙي ڊولپر کان ٻئي ڏانھن گذري ٿو. اهي ڪوڊ جي جائزي ۾ حصو وٺندا آهن ساڳئي طرح، مثال طور، يوڪس ڊزائنر، ڊولپر پاڻ، ڪڏهن ڪڏهن پراڊڪٽ مينيجرز. SREs ساڳئي سطح تي ڪم ڪن ٿا. اسان کي انهن کي منظور ڪرڻ جي ضرورت آهي، اسان کي انهن جو جائزو وٺڻ جي ضرورت آهي، انهي ڪري ته هر مقرري لاءِ SRE چوندو: "ٺيڪ آهي، هي تعیناتي، هي پيداوار منفي طور تي اعتبار تي اثر انداز نه ڪندي. ۽ جيڪڏھن اھو آھي، پوء ڪجھ قابل قبول حدن جي اندر. ان بابت به ڳالهائينداسين.
مطابق، SRE کي ڪوڊ تبديل ڪرڻ لاء ويٽو آھي. ۽ عام طور تي، اهو پڻ ڪجهه قسم جي ننڍڙي تڪرار جي ڪري ٿي جيڪڏهن SRE غلط طور تي لاڳو ٿئي ٿي. ساڳئي ڪتاب ۾ سائيٽ ريليبلٽي انجنيئرنگ بابت، ڪيترائي حصا، هڪ به نه، ٻڌايو ته انهن تڪرارن کان ڪيئن بچجي.
اهي پڇن ٿا ته ڪيئن SRE معلومات جي حفاظت سان لاڳاپيل آهي. SRE سڌو سنئون معلومات جي حفاظت ۾ ملوث ناهي. بنيادي طور تي، وڏي ڪمپنين ۾، اهو ڪيو ويندو آهي ماڻهن، ٽيسٽرن، تجزيه نگارن. پر SRE پڻ انھن سان ڳالھ ٻولھ ڪري ٿو ان معنى ۾ ته ڪجھ عمل، ڪجھ ڪم، ڪجھ مقرريون جيڪي سيڪيورٽي کي متاثر ڪن ٿيون پراڊڪٽ جي دستيابي کي پڻ متاثر ڪري سگھي ٿي. تنهن ڪري، SRE مجموعي طور تي ڪنهن به ٽيمن سان رابطي ۾ آهي، بشمول سيڪيورٽي ٽيمون، تجزيه نگارن سميت. تنهن ڪري، SREs بنيادي طور تي گهربل آهن جڏهن اهي DevOps کي لاڳو ڪرڻ جي ڪوشش ڪري رهيا آهن، پر ساڳئي وقت، ڊولپرز تي بوجھ تمام وڏو ٿي ويندو آهي. اهو آهي ته ترقي پسند ٽيم پاڻ هاڻي ان حقيقت کي منهن نه ڏئي سگهي آهي ته هاڻي انهن کي به Ops جي ذميواري ڪرڻ جي ضرورت آهي. ۽ هڪ الڳ ڪردار آهي. اهو ڪردار بجيٽ ۾ رٿيل آهي. ڪڏهن ڪڏهن هي ڪردار ٽيم جي سائيز ۾ رکيل آهي، هڪ الڳ شخص ظاهر ٿئي ٿو، ڪڏهن ڪڏهن ڊولپرز مان هڪ بڻجي ويندو آهي. هي ڪيئن ٽيم ۾ پهريون SRE ظاهر ٿئي ٿو.
سسٽم جي پيچيدگي جيڪا SRE کان متاثر ٿئي ٿي، پيچيدگي جيڪا آپريشن جي اعتبار کي متاثر ڪري ٿي، ضروري ۽ حادثاتي آهي. ضروري پيچيدگي اها آهي جڏهن هڪ پيداوار جي پيچيدگي حد تائين وڌائي ٿي جيڪا نئين پيداوار جي خاصيتن جي ضرورت آهي. بي ترتيب پيچيدگي آهي جڏهن سسٽم جي پيچيدگي وڌي ٿي، پر پيداوار جي خصوصيت ۽ ڪاروباري گهرجون سڌو سنئون اثر انداز نه ڪندا آهن. اهو ظاهر ٿئي ٿو ته يا ته ڊولپر ڪٿي غلطي ڪئي آهي، يا الورورٿم بهتر نه آهي، يا ڪجهه اضافي دلچسپيون متعارف ڪرايون ويون آهن جيڪي خاص ضرورت کان سواء پيداوار جي پيچيدگي کي وڌائي رهيا آهن. هڪ سٺو SRE هميشه هن صورتحال کي ختم ڪرڻ گهرجي. اهو آهي، ڪنهن به انجام، ڪنهن به مقرري، ڪنهن به ڇڪڻ جي درخواست، جتي بي ترتيب اضافو جي ڪري مشڪل وڌائي ٿي، بلاڪ ڪيو وڃي.
سوال اهو آهي ته ڇو نه صرف هڪ انجنيئر، هڪ سسٽم ايڊمنسٽريٽر کي ڀرتي ڪيو وڃي جنهن سان ٽيم ۾ تمام گهڻي ڄاڻ هجي. هڪ انجنيئر جي ڪردار ۾ هڪ ڊولپر، اسان کي ٻڌايو ويو آهي، بهترين عملي حل نه آهي. هڪ انجنيئر جي ڪردار ۾ هڪ ڊولپر هميشه بهترين عملي جو حل نه هوندو آهي، پر هتي نقطو اهو آهي ته هڪ ڊولپر جيڪو Ops ۾ مصروف آهي آٽوميشن لاءِ ٿوري گهڻي خواهش رکي ٿو، ان تي عمل ڪرڻ لاءِ ٿورو وڌيڪ ڄاڻ ۽ مهارت جو سيٽ آهي. هن automation. ۽ ان جي مطابق، اسان نه صرف ڪجهه مخصوص عملن لاءِ وقت گھٽائيندا آهيون، نه رڳو معمول، پر ان کان سواءِ اهم ڪاروباري پيٽرولر به گھٽائيندا آهيون جيئن MTTR (Mean Time To Recovery، Recovery time). اهڙيء طرح، ۽ اسان ان بابت ٿوري دير بعد ڳالهائينداسين، اسان تنظيم لاء پئسا بچائيندا آهيون.
هاڻي اچو ته SRE جي آپريشن جي معيار بابت ڳالهايون. ۽ سڀ کان پهرين reliability جي باري ۾. ننڍين ڪمپنين ۾، شروع ٿيندڙ، گهڻو ڪري ائين ٿيندو آهي ته ماڻهو اهو سمجهندا آهن ته جيڪڏهن سروس سٺو لکيو ويو آهي، جيڪڏهن پراڊڪٽ سٺو ۽ صحيح لکيو ويو آهي ته اهو ڪم ڪندو، اهو خراب نه ٿيندو. اھو اھو آھي، اسان سٺو ڪوڊ لکندا آھيون، تنھنڪري ٽوڙڻ لاء ڪجھ به نه آھي. ڪوڊ تمام سادو آهي، ٽوڙڻ لاء ڪجھ به ناهي. اهي انهن ئي ماڻهن بابت آهن جيڪي چون ٿا ته اسان کي ٽيسٽن جي ضرورت ناهي، ڇو ته، ڏسو، اهي ٽي وي پي آئي طريقا آهن، هتي ڇو ٽوڙيو.
اهو سڀ ڪجهه غلط آهي، يقينا. ۽ اهي ماڻهو گهڻو ڪري عملي طور تي اهڙي ڪوڊ سان کائي ويندا آهن، ڇاڪاڻ ته شيون ڀڃندا آهن. شيون ڪڏهن ڪڏهن سڀ کان وڌيڪ غير متوقع طريقن سان ڀڃندا آهن. ڪڏهن ڪڏهن ماڻهو چون ٿا نه، اهو ڪڏهن به نه ٿيندو. ۽ اهو هر وقت ٿئي ٿو. اهو اڪثر ڪافي ٿئي ٿو. ۽ اهو ئي سبب آهي ته ڪو به ماڻهو ڪڏهن به 100٪ دستيابي جي ڪوشش نه ڪندو آهي، ڇاڪاڻ ته 100٪ دستيابي ڪڏهن به نه ٿيندي آهي. اهو ئي معمول آهي. ۽ تنهن ڪري، جڏهن اسان هڪ خدمت جي دستيابي بابت ڳالهايو ٿا، اسان هميشه نينس بابت ڳالهايون ٿا. 2 اڱڻ، 3 نَون، 4 نَون، 5 نَون. جيڪڏهن اسان هن کي ڊائون ٽائم ۾ ترجمو ڪريون ٿا، ته پوءِ، مثال طور، 5 نائنز، پوءِ اهو هر سال 5 منٽ کان ٿورو وڌيڪ آهي، 2 نائنز آهي 3,5 ڏينهن جي ڊائون ٽائم.
پر اهو ظاهر آهي ته ڪجهه نقطي تي POI ۾ گهٽتائي آهي، سيڙپڪاري تي واپسي. ٻن نائن کان ٽن نائن تائين وڃڻ جو مطلب آهي 3 ڏينهن کان گهٽ وقت گهٽجڻ. چار نائن کان پنجن تائين وڃڻ سان هر سال 47 منٽ گھٽجي ٿو. ۽ اهو ظاهر ٿئي ٿو ته ڪاروبار لاء اهو شايد نازڪ نه هجي. ۽ عام طور تي، گهربل اعتبار هڪ ٽيڪنيڪل مسئلو ناهي، سڀ کان پهريان، اهو هڪ ڪاروباري مسئلو آهي، اهو هڪ پيداوار جو مسئلو آهي. پراڊڪٽ جي استعمال ڪندڙن لاءِ ڪھڙي سطح جي گھٽتائي قابل قبول آھي، اھي ڪھڙي اميد رکن ٿا، اھي ڪيترو ادا ڪن ٿا، مثال طور، اھي ڪيترو پيسا وڃائي ٿو، سسٽم ڪيترو پيسا وڃائي ٿو.
هتي هڪ اهم سوال اهو آهي ته باقي اجزاء جي اعتبار ڇا آهي. ڇاڪاڻ ته 4 ۽ 5 نائنز جي وچ ۾ فرق هڪ سمارٽ فون تي 2 نائنز جي قابل اعتماد سان نظر نه ايندو. عام طور تي ڳالهائڻ، جيڪڏهن ڪجهه سال ۾ 10 ڀيرا توهان جي سروس ۾ هڪ سمارٽ فون تي ڀڃڪڙي ٿئي ٿي، گهڻو ڪري 8 ڀيرا خراب ٿيڻ جي او ايس پاسي تي واقع ٿي. استعمال ڪندڙ هن کي استعمال ڪيو ويندو آهي، ۽ هڪ سال ۾ هڪ ڀيرو وڌيڪ ڌيان نه ڏيندو. اهو ضروري آهي ته وڌندڙ اعتماد ۽ وڌندڙ منافعي جي قيمت سان لاڳاپو.
بس SRE تي ڪتاب ۾ 4 نائن مان 3 نائن تائين وڌائڻ جو هڪ سٺو مثال آهي. اهو ظاهر ٿئي ٿو ته دستيابي ۾ اضافو 0,1٪ کان ٿورو گهٽ آهي. ۽ جيڪڏهن خدمت جي آمدني آهي $1 ملين هڪ سال، پوء آمدني ۾ اضافو آهي $900. جيڪڏهن اهو اسان کي 900 ڊالر کان گهٽ خرچ ڪري ٿو هڪ سال کان نو تائين استطاعت وڌائڻ لاءِ ، اضافو مالي احساس پيدا ڪري ٿو. جيڪڏهن اهو سال ۾ 900 ڊالر کان وڌيڪ خرچ ڪري ٿو، اهو هاڻي ڪو به احساس نٿو رکي، ڇاڪاڻ ته آمدني ۾ اضافو صرف مزدورن جي خرچن، وسيلن جي خرچن جي تلافي نه ڪندو آهي. ۽ 3 نينس اسان لاء ڪافي هوندا.
اهو يقيناً هڪ آسان مثال آهي جتي سڀ درخواستون برابر آهن. ۽ 3 نينس کان 4 نينس تائين وڃڻ ڪافي آسان آهي، پر ساڳئي وقت، مثال طور، 2 نائن کان 3 تائين، اهو اڳ ۾ ئي 9 هزار ڊالر جي بچت آهي، اهو مالي احساس پيدا ڪري سگهي ٿو. قدرتي طور تي، حقيقت ۾، رجسٽريشن جي درخواست جي ناڪامي صفحي کي ظاهر ڪرڻ جي ناڪامي کان وڌيڪ خراب آهي، درخواستن جا مختلف وزن آهن. ڪاروباري نقطي نظر کان اهي مڪمل طور تي مختلف معيار هوندا، پر بهرحال، ضابطي جي طور تي، جيڪڏهن اسان ڪجهه مخصوص خدمتن جي باري ۾ نه ڳالهائي رهيا آهيون، اهو هڪ انتهائي قابل اعتماد انداز آهي.
اسان کي هڪ سوال مليو ته ڇا SRE ڪوآرڊينيٽر مان هڪ آهي جڏهن خدمت لاءِ آرڪيٽيڪچرل حل چونڊيو وڃي. اچو ته موجوده انفراسٽرڪچر ۾ انضمام جي لحاظ کان، ته جيئن ان جي استحڪام ۾ ڪو به نقصان نه آهي. ها، SREs، ساڳئي طريقي سان درخواستن، ڪمن، رليزز کي متاثر ڪري ٿو فن تعمير، نئين خدمتن جو تعارف، مائڪرو سروسز، نئين حلن تي عمل درآمد. مون ان کان اڳ ڇو چيو هو ته تجربي جي ضرورت آهي، قابليت جي ضرورت آهي. حقيقت ۾، SRE ڪنهن به تعميراتي ۽ سافٽ ويئر حل ۾ بلاڪ آوازن مان هڪ آهي. ان جي مطابق، هڪ انجنيئر جي حيثيت سان، هڪ SRE، سڀ کان پهريان، نه رڳو اهو سمجهڻ گهرجي، پر اهو پڻ سمجهڻ گهرجي ته ڪي خاص فيصلا قابل اعتماد، استحڪام تي اثر انداز ڪندا، ۽ اهو سمجهڻ گهرجي ته اهو ڪاروبار جي ضرورتن سان ڪيئن تعلق رکي ٿو، ۽ ڪهڙي نقطي نظر کان اهو قابل قبول ٿي سگهي ٿو ۽ جيڪو نه.
تنهن ڪري، هاڻي اسان صرف قابل اعتماد معيار جي باري ۾ ڳالهائي سگهون ٿا، جيڪي روايتي طور تي SRE ۾ SLA (سروس ليول معاهدو) جي طور تي بيان ڪيا ويا آهن. گهڻو ڪري هڪ واقف اصطلاح. SLI (سروس ليول اشارو). SLO (خدمت جي سطح جو مقصد). خدمت جي سطح جو معاهدو شايد هڪ علامتي اصطلاح آهي، خاص طور تي جيڪڏهن توهان ڪم ڪيو آهي نيٽ ورڪن سان، مهيا ڪندڙن سان، هوسٽنگ سان. هي هڪ عام معاهدو آهي جيڪو بيان ڪري ٿو توهان جي سموري خدمت جي ڪارڪردگي، ڏنڊ، ڪجهه ڏنڊن لاءِ غلطيون، ميٽرڪس، معيار. ۽ SLI خود دستيابي ميٽرڪ آهي. اهو آهي، ڇا SLI ٿي سگهي ٿو: خدمت کان جوابي وقت، غلطين جو تعداد سيڪڙو طور. اهو بينڊوڊٿ ٿي سگهي ٿو جيڪڏهن اهو ڪنهن قسم جي فائل هوسٽنگ آهي. جڏهن اها سڃاڻپ الگورتھم تي اچي ٿي، اشارو ٿي سگهي ٿو، مثال طور، جواب جي درستگي پڻ. SLO (خدمت جي سطح جو مقصد)، ترتيب سان، SLI اشاري جو هڪ ميلاپ، ان جي قيمت ۽ مدت.
اچو ته چون ٿا SLA هن طرح ٿي سگهي ٿو. سروس موجود آهي 99,95٪ وقت جي سڄي سال ۾. يا 99 نازڪ سپورٽ ٽڪيٽون بند ڪيون وينديون 3 ڪلاڪ في ڪلاڪ اندر. يا 85 سيڪڙو سوالن جا جواب ملندا 1,5 سيڪنڊن اندر هر مهيني. اهو آهي، اسان کي آهستي آهستي سمجهه ۾ اچي ٿو ته غلطيون ۽ ناڪاميون بلڪل عام آهن. اها هڪ قابل قبول صورتحال آهي، اسان ان جي منصوبابندي ڪري رهيا آهيون، اسان ان تي ڪنهن حد تائين ڳڻتي به ڪري رهيا آهيون. اھو آھي، SRE سسٽم ٺاھي ٿو جيڪي غلطيون ڪري سگھن ٿيون، جن کي عام طور تي غلطين جو جواب ڏيڻ گھرجي، جيڪو انھن کي حساب ۾ رکڻ گھرجي. ۽ جڏهن به ممڪن هجي، انهن غلطين کي اهڙي طريقي سان سنڀالڻ گهرجي ته صارف يا ته انهن کي نوٽيس نه ڪري، يا نوٽيس، پر اتي هڪ قسم جو ڪم ڪار آهي، جنهن جي مهرباني، هر شيء مڪمل طور تي گر نه ٿيندي.
مثال طور، جيڪڏهن توهان يوٽيوب تي هڪ وڊيو اپلوڊ ڪريو ٿا، ۽ يوٽيوب ان کي فوري طور تي تبديل نٿو ڪري سگهي، جيڪڏهن وڊيو تمام وڏي آهي، جيڪڏهن فارميٽ بهتر نه آهي، ته پوءِ درخواست قدرتي طور تي وقت ختم ٿيڻ سان ناڪام نه ٿيندي، يوٽيوب 502 غلطي نه ڏيندو. ، يوٽيوب چوندو: ”اسان سڀ ڪجهه ٺاهيو آهي، توهان جي وڊيو تي عمل ٿي رهيو آهي. اهو اٽڪل 10 منٽن ۾ تيار ٿي ويندو. اهو اصول آهي فضلي تباهي جو، جيڪو واقف آهي، مثال طور، سامهون واري ترقي کان، جيڪڏهن توهان ڪڏهن ڪيو آهي.
ايندڙ اصطلاحن جي باري ۾ ڳالهائينداسين، جيڪي قابل اعتماد ڪم ڪرڻ لاء تمام ضروري آهن، غلطي سان، اميدن سان، MTBF ۽ MTTR آهن. MTBF ناڪامين جي وچ ۾ وچولي وقت آهي. MTTR مطلب وصولي لاءِ وقت، وصولي لاءِ اوسط وقت. اهو آهي، ڪيترو وقت گذري چڪو آهي ان وقت کان جڏهن غلطي دريافت ڪئي وئي هئي، ان لمحي کان وٺي غلطي ظاهر ٿيڻ کان وٺي خدمت مڪمل طور تي معمول جي آپريشن ۾ بحال ٿي وئي هئي. MTBF بنيادي طور تي ڪوڊ جي معيار تي ڪم جي ذريعي مقرر ڪيو ويو آهي. اهو آهي، حقيقت اها آهي ته SREs چئي سگهي ٿو "نه". ۽ توهان کي سڄي ٽيم کي سمجهڻ جي ضرورت آهي ته جڏهن SRE چوي ٿو "نه"، هو اهو نٿو چوي ڇاڪاڻ ته هو نقصانڪار آهي، نه ته هو خراب آهي، پر ان ڪري جو ٻي صورت ۾ هرڪو نقصان ٿيندو.
ٻيهر، ڪيترائي مضمون آهن، ڪيترائي طريقا، تمام گهڻا طريقا پڻ ان ڪتاب ۾ جن جو حوالو آئون اڪثر ڪريان ٿو، انهي کي ڪيئن يقيني بڻايو وڃي ته ٻيا ڊولپر SRE کان نفرت ڪرڻ شروع نه ڪن. MTTR، ٻئي طرف، توهان جي SLOs تي ڪم ڪرڻ بابت آهي (سروس ليول مقصد). ۽ اهو گهڻو ڪري خودڪار آهي. ڇو ته، مثال طور، اسان جو SLO هڪ اپ ٽائم آهي 4 نينس في چوٿين. ان جو مطلب اهو آهي ته 3 مهينن ۾ اسان اجازت ڏئي سگهون ٿا 13 منٽ جي دير سان. ۽ اهو ظاهر ٿئي ٿو ته MTTR 13 منٽ کان وڌيڪ نه ٿي سگهي. جيڪڏهن اسان 13 منٽ ۾ گهٽ ۾ گهٽ 1 دير جو جواب ڏيون ٿا، ان جو مطلب اهو آهي ته اسان اڳ ۾ ئي ٽه ماهي جي پوري بجيٽ ختم ڪري ڇڏي آهي. اسان SLO کي ٽوڙي رهيا آهيون. 13 منٽ رد عمل ۽ حادثي کي درست ڪرڻ هڪ مشين لاء تمام گهڻو آهي، پر انسان لاء تمام ننڍو آهي. ڇاڪاڻ ته جيستائين هڪ شخص هڪ خبرداري حاصل ڪري ٿو، جيستائين هو رد عمل نٿو ڪري، جيستائين هو غلطي کي سمجهي، اهو اڳ ۾ ئي ڪيترائي منٽ آهي. جيستائين ڪو ماڻهو سمجهي نه ٿو ته ان کي ڪيئن درست ڪجي، ڇا ٺيڪ ڪجي، ڇا ڪجي، پوءِ هي ڪجهه وڌيڪ منٽ آهي. ۽ حقيقت ۾، جيتوڻيڪ توهان کي صرف سرور کي ٻيهر شروع ڪرڻ جي ضرورت آهي، جيئن اهو نڪتو، يا هڪ نئون نوڊ وڌايو، پوء دستي طور تي MTTR اڳ ۾ ئي 7-8 منٽ آهي. جڏهن خودڪار طريقي سان عمل ڪندي، MTTR اڪثر ڪري هڪ سيڪنڊ تائين پهچي ٿو، ڪڏهن ڪڏهن مليس سيڪنڊ. گوگل عام طور تي مليس سيڪنڊن بابت ڳالهائيندو آهي، پر حقيقت ۾، يقينا، هر شيء ايترو سٺو ناهي.
مثالي طور تي، SRE کي پنهنجي ڪم کي مڪمل طور تي خودڪار ڪرڻ گهرجي، ڇاڪاڻ ته اهو سڌو سنئون متاثر ڪري ٿو MTTR، ان جي ميٽرڪس، سڄي خدمت جي SLO، ۽، مطابق، ڪاروباري منافعو. جيڪڏهن وقت گذري ويو آهي، اسان کان پڇيو ويو آهي ته SRE غلطي تي آهي. خوشقسمتيء سان، ڪو به الزام نه آهي. ۽ هي هڪ الڳ ڪلچر آهي جنهن کي balmeless postmortem سڏيو ويندو آهي، جنهن بابت اسين اڄ نه ڳالهائينداسين، پر اسان ان جو تجزيو Slurm تي ڪنداسين. هي هڪ تمام دلچسپ موضوع آهي جنهن تي تمام گهڻو ڳالهائي سگهجي ٿو. مجموعي طور تي، جيڪڏهن مقرر ڪيل وقت في ٽه ماهي کان وڌي وڃي، ته پوء هر ڪنهن جو ٿورڙو الزام آهي، جنهن جو مطلب آهي ته سڀني کي الزام ڏيڻ جو نتيجو ناهي، اچو ته ان جي بدران، شايد ڪنهن کي الزام نه ڏيو، پر صورتحال کي درست ڪريون ۽ جيڪي اسان وٽ آهن ان سان ڪم ڪريون. منهنجي تجربي ۾، هي طريقو اڪثر ٽيمن لاءِ اجنبي آهي، خاص طور تي روس ۾، پر اهو سمجهه ۾ اچي ٿو ۽ تمام سٺو ڪم ڪري ٿو. تنهن ڪري، آئون آرٽيڪل ۽ ادب جي آخر ۾ سفارش ڪندس ته توهان هن موضوع تي پڙهي سگهو ٿا. يا Slurm SRE تي اچو.
مون کي وضاحت ڪرڻ ڏيو. جيڪڏهن SLO وقت في ٽه ماهي کان وڌي ويو آهي، جيڪڏهن ڊائون ٽائم 13 منٽ نه، پر 15 هو، ان لاء ڪير ذميوار ٿي سگهي ٿو؟ يقينا، ايس آر اي کي الزام ڏيڻو پوندو، ڇاڪاڻ ته هن واضح طور تي ڪجهه قسم جي خراب ڪم يا تعیناتي ڪئي. ڊيٽا سينٽر جو منتظم ان لاءِ ذميوار ٿي سگهي ٿو، ڇاڪاڻ ته هن شايد ڪنهن قسم جي اڻڄاتل سار سنڀال ڪئي هجي. جيڪڏهن ڊيٽا سينٽر جو منتظم ان لاءِ ذميوار آهي ته پوءِ ان لاءِ اوپس جو شخص ذميوار آهي، جنهن ايس ايل او کي همٿائڻ وقت سار سنڀال جو حساب نه ڏنو. مئنيجر، ٽيڪنيڪل ڊائريڪٽر يا ڪو ماڻهو جيڪو ڊيٽا سينٽر جي معاهدي تي دستخط ڪيو ۽ ان حقيقت تي ڌيان نه ڏنو ته ڊيٽا سينٽر جو SLA گهربل وقت لاء ٺهيل نه آهي ان لاء ذميوار آهي. تنهن ڪري، هن صورتحال ۾ تمام ٿورڙي دير سان ذميوار آهن. ۽ ان جو مطلب اهو آهي ته هن صورتحال ۾ ڪنهن تي الزام هڻڻ جو ڪو به فائدو ناهي. پر يقينا، ان کي درست ڪرڻ جي ضرورت آهي. ان ڪري پوسٽ مارٽم ٿي رهيا آهن. ۽ جيڪڏهن توهان پڙهو، مثال طور، GitHub پوسٽ مارٽم، ۽ اهو هميشه هڪ تمام دلچسپ، ننڍڙو ۽ غير متوقع ڪهاڻي آهي هر مخصوص ڪيس ۾، توهان ان کي تبديل ڪري سگهو ٿا ته ڪو به ڪڏهن به اهو نه چوندو ته اهو خاص شخص الزام هو. الزام هميشه مخصوص نامڪمل عملن تي رکيل آهي.
اچو ته ايندڙ سوال ڏانهن وڃو. آٽوميشن. جڏهن آئون ٻين مقصدن ۾ آٽوميشن جي باري ۾ ڳالهائيندو آهيان، آئون اڪثر هڪ ٽيبل جو حوالو ڏيان ٿو جيڪو توهان کي ٻڌائي ٿو ته توهان ڪيتري وقت تائين ڪنهن ڪم کي خودڪار ڪرڻ تي ڪم ڪري سگهو ٿا بغير ان کي خودڪار ڪرڻ لاءِ وڌيڪ وقت وٺڻ کان سواءِ توهان جي اصل ۾ بچت. اتي هڪ snag آهي. پڪڙي اها آهي ته جڏهن SREs هڪ ڪم کي خودڪار ڪري ٿو، اهي نه صرف وقت بچائيندا آهن، اهي پئسا بچائيندا آهن، ڇاڪاڻ ته خودڪار طريقي سان سڌو سنئون MTTR کي متاثر ڪري ٿو. اهي بچائيندا آهن، تنهنڪري ڳالهائڻ لاء، ملازمن ۽ ڊولپرز جو حوصلو، جيڪو پڻ هڪ شاندار وسيلو آهي. اهي معمول کي گهٽائي ڇڏيندا آهن. ۽ اهو سڀ ڪجهه ڪم تي مثبت اثر آهي ۽ نتيجي طور، ڪاروبار تي، جيتوڻيڪ اهو لڳي ٿو ته خودڪار طريقي سان وقت جي قيمت جي لحاظ کان ڪو به مطلب ناهي.
حقيقت ۾، اهو تقريبا هميشه آهي، ۽ تمام ٿورڙا ڪيس آهن جتي SRE جي ڪردار ۾ ڪجهه خودڪار نه ٿيڻ گهرجي. اڳتي هلي اسان ان بابت ڳالهائينداسين جنهن کي ايرر بجيٽ چئجي ٿو، غلطين لاءِ بجيٽ. حقيقت ۾، اهو ظاهر ٿئي ٿو ته جيڪڏهن هر شيء توهان لاء SLO کان وڌيڪ بهتر آهي جيڪو توهان پنهنجي لاء مقرر ڪيو آهي، اهو پڻ تمام سٺو ناهي. اهو بلڪه خراب آهي، ڇاڪاڻ ته SLO ڪم ڪري ٿو نه رڳو هيٺئين طور تي، پر هڪ لڳ ڀڳ مٿين حد جي طور تي. جڏهن توهان پنهنجو پاڻ کي 99٪ دستيابي جو SLO مقرر ڪيو آهي، ۽ حقيقت ۾ توهان وٽ 99,99٪ آهي، اهو ظاهر ٿئي ٿو ته توهان وٽ تجربن لاءِ ڪجهه جاءِ آهي جيڪا ڪاروبار کي ڪو به نقصان نه پهچائيندي، ڇو ته توهان پاڻ اهو سڀ گڏجي طئي ڪيو آهي، ۽ توهان آهيو. هن خلا کي استعمال نه ڪندا آھن. توهان وٽ غلطين لاءِ بجيٽ آهي، جيڪا توهان جي صورت ۾ استعمال نه ڪئي وئي آهي.
اسان ان سان ڇا ڪريون. اسان ان کي لفظي طور تي هر شيء لاء استعمال ڪندا آهيون. پيداوار جي حالتن ۾ جاچ لاءِ، نئين خاصيتن کي رولنگ ڪرڻ لاءِ جيڪي ڪارڪردگي تي اثرانداز ٿي سگهن ٿيون، رليز لاءِ، سار سنڀال لاءِ، منصوبابندي بند وقتن لاءِ. ريورس قاعدو پڻ لاڳو ٿئي ٿو: جيڪڏهن بجيٽ ختم ٿي وئي آهي، اسان ڪا به نئين شيء جاري نه ڪري سگهون ٿا، ڇاڪاڻ ته ٻي صورت ۾ اسان SLO کان وڌي وينداسين. بجيٽ اڳ ئي ختم ٿي چڪي آهي، اسان ڪجهه جاري ڪيو آهي جيڪڏهن ان سان ڪارڪردگيءَ تي منفي اثر پوي ٿو، يعني جيڪڏهن اهو ڪجهه ٺيڪ نه آهي ته ان سان سڌو سنئون ايس ايل او وڌي وڃي ته پوءِ اسان بجيٽ کان اڳتي وڌي رهيا آهيون، ۽ اها صورتحال خراب آهي. ، ان جو تجزيو ڪرڻ جي ضرورت آهي، پوسٽ مارٽم، ۽ ممڪن طور تي ڪجهه عمل جي اصلاح.
اهو آهي، اهو ظاهر ٿئي ٿو ته جيڪڏهن خدمت پاڻ کي سٺو ڪم نٿو ڪري، ۽ SLO خرچ ڪيو ويو آهي ۽ بجيٽ خرچ ڪيو ويو آهي تجربن تي نه، ڪجهه رليز تي، پر پاڻ طرفان، پوء ڪجهه دلچسپ فيڪس بدران، دلچسپ خاصيتن جي بدران، دلچسپ رليز جي بدران. ڪنهن به تخليقي ڪم جي بدران، توهان کي بيوقوف سڌارن سان معاملو ڪرڻو پوندو ته بجيٽ کي ترتيب ۾ واپس آڻڻ، يا SLO ۾ ترميم ڪريو، ۽ اهو پڻ هڪ عمل آهي جيڪو گهڻو ڪري نه ٿيڻ گهرجي.
تنهن ڪري، اهو ظاهر ٿئي ٿو ته اهڙي صورتحال ۾ جتي اسان وٽ غلطين لاء وڌيڪ بجيٽ آهي، هرڪو دلچسپي رکي ٿو: SRE ۽ ڊولپر ٻنهي. ڊولپرز لاءِ، بگ لاءِ وڏي بجيٽ جو مطلب آھي توھان رليز، ٽيسٽ، تجربن سان ڊيل ڪري سگھو ٿا. SREs لاء، غلطين لاء هڪ بجيٽ ۽ ان بجيٽ ۾ داخل ٿيڻ جو مطلب آهي ته اهي سڌو سنئون پنهنجو ڪم ڪري رهيا آهن. ۽ اهو ڪجهه قسم جي گڏيل ڪم جي حوصله کي متاثر ڪري ٿو. جيڪڏهن توهان پنهنجي SREs کي ڊولپرز جي طور تي ٻڌو ٿا، توهان وٽ سٺي ڪم لاءِ وڌيڪ جاءِ هوندي ۽ تمام گهٽ معمولي.
اهو ظاهر ٿئي ٿو ته پيداوار ۾ تجربا وڏي ٽيمن ۾ SRE جو هڪ اهم ۽ لڳ ڀڳ لازمي حصو آهن. ۽ اهو عام طور تي افراتفري انجنيئرنگ سڏيو ويندو آهي، جيڪو Netflix تي ٽيم کان اچي ٿو جيڪو افراتفري کي جاري ڪيو آهي افراتفري بندر سڏيو ويندو آهي.
افراتفري بندر CI / CD پائپ لائن سان ڳنڍيندو آهي ۽ بي ترتيب سان سرور کي پيداوار ۾ تباهه ڪري ٿو. ٻيهر، SRE جي جوڙجڪ ۾، اسان حقيقت جي باري ۾ ڳالهائي رهيا آهيون ته هڪ نازل ٿيل سرور پاڻ ۾ خراب ناهي، اهو توقع آهي. ۽ جيڪڏهن اهو بجيٽ جي اندر آهي، اهو قابل قبول آهي ۽ ڪاروبار کي نقصان نه پهچائيندو آهي. يقينن، Netflix وٽ ڪافي بيڪار سرور آهن، ڪافي نقل، انهي ڪري ته اهو سڀ ڪجهه درست ٿي سگهي ٿو، ۽ انهي ڪري ته صارف مجموعي طور تي نوٽيس نه ڪري، ۽ اڃا به وڌيڪ، ڪو به هڪ سرور کي ڪنهن به بجيٽ لاء نه ڇڏيندو.
Netflix وٽ ٿوري دير لاءِ اهڙين يوٽيلٽيز جو هڪ پورو سوٽ هو، جن مان هڪ، Chaos Gorilla، Amazon جي دستيابي زون مان هڪ کي مڪمل طور تي بند ڪري ٿو. ۽ اهڙيون شيون ظاهر ڪرڻ ۾ مدد ڪن ٿيون، پهرين، پوشیدہ انحصار، جڏهن اهو مڪمل طور تي واضح ناهي ته ڇا اثر انداز ٿئي ٿو، ڇا تي منحصر آهي. ۽ اهو، جيڪڏهن توهان هڪ microservice سان ڪم ڪري رهيا آهيو، ۽ دستاويز بلڪل صحيح نه آهي، اهو توهان کي واقف ٿي سگهي ٿو. ۽ ٻيهر، اهو ڪوڊ ۾ غلطين کي پڪڙڻ ۾ تمام گهڻو مدد ڪري ٿو جيڪو توهان اسٽيجنگ تي پڪڙي نٿا سگهو، ڇاڪاڻ ته ڪنهن به اسٽيجنگ بلڪل صحيح نموني نه آهي، حقيقت جي ڪري ته لوڊ اسڪيل مختلف آهي، لوڊ جو نمونو مختلف آهي، سامان آهي. پڻ، گهڻو ڪري، ٻيو. چوٽي لوڊ پڻ غير متوقع ۽ غير متوقع ٿي سگھي ٿو. ۽ اهڙي جاچ، جيڪا ٻيهر بجيٽ کان ٻاهر نه ٿي وڃي، انفراسٹرڪچر ۾ غلطين کي پڪڙڻ ۾ تمام سٺو مدد ڪري ٿي جيڪا اسٽيجنگ، آٽو ٽيسٽ، سي آء / سي ڊي پائپ لائن ڪڏهن به پڪڙي نه سگهندي. ۽ جيستائين اهو سڀ ڪجهه توهان جي بجيٽ ۾ شامل آهي، اهو مسئلو ناهي ته توهان جي خدمت اتي هيٺ ٿي وئي، جيتوڻيڪ اهو تمام خوفناڪ لڳي ٿو، سرور هيٺ ٿي ويو، اهو ڪهڙو خواب آهي. نه، اهو عام آهي، اهو سٺو آهي، جيڪو ڪيچ پڪڙڻ ۾ مدد ڪري ٿو. جيڪڏهن توهان وٽ بجيٽ آهي، ته توهان ان کي خرچ ڪري سگهو ٿا.
سوال: مان ڪهڙو ادب تجويز ڪري سگهان ٿو؟ فهرست جي آخر ۾. تمام گهڻو ادب آهي، مان ڪجهه رپورٽون پيش ڪندس. اهو ڪيئن ڪم ڪري ٿو، ۽ SRE ڪم ڪري ٿو ڪمپنين ۾ انهن جي پنهنجي سافٽ ويئر پراڊڪٽ کان سواءِ يا گهٽ ۾ گهٽ ترقي سان. مثال طور، هڪ اداري ۾ جتي مکيه سرگرمي سافٽ ويئر نه آهي. هڪ انٽرپرائز ۾، جتي مکيه سرگرمي سافٽ ويئر نه آهي، SRE بلڪل ساڳي طرح ڪم ڪري ٿو جيئن هر هنڌ، ڇو ته هڪ ڪمپني ۾ توهان کي پڻ استعمال ڪرڻ جي ضرورت آهي، جيتوڻيڪ ترقي يافته نه آهي، سافٽ ويئر پروڊڪٽس، توهان کي تازه ڪاري ڪرڻ جي ضرورت آهي، توهان کي تبديل ڪرڻ جي ضرورت آهي. انفراسٽرڪچر، توهان کي وڌڻ جي ضرورت آهي، توهان کي ماپڻ جي ضرورت آهي. ۽ SREs انهن عملن ۾ ممڪن مسئلن جي نشاندهي ڪرڻ ۽ اڳڪٿي ڪرڻ ۾ مدد ڪن ٿا ۽ انهن کي ڪنٽرول ڪن ٿا ڪجهه ترقي ٿيڻ کان پوءِ ۽ ڪاروبار جي ضرورتن ۾ تبديلي. ڇو ته اهو بلڪل ضروري ناهي ته سافٽ ويئر ڊولپمينٽ ۾ شامل ٿيڻ لاءِ هڪ SRE هجي جيڪڏهن توهان وٽ گهٽ ۾ گهٽ ڪجهه سرور آهن ۽ توهان کي توقع آهي ته گهٽ ۾ گهٽ ڪجهه واڌارو.
ساڳيو ئي ننڍن منصوبن، ننڍن تنظيمن لاء، ڇو ته وڏي ڪمپنين وٽ بجيٽ ۽ تجربو ڪرڻ جي جاء آهي. پر ساڳئي وقت، تجربن جا اهي سڀئي ميوا ڪٿي به استعمال ڪري سگهجن ٿا، اهو آهي، SRE، يقينا، گوگل ۾ ظاهر ٿيو، Netflix ۾، ڊراپ باڪس ۾. پر ساڳئي وقت، ننڍيون ڪمپنيون ۽ شروع ڪرڻ وارا اڳ ۾ ئي مواد پڙهي سگهن ٿا، ڪتاب پڙهي، رپورٽون ڏسي. اهي ان جي باري ۾ گهڻو ڪجهه ٻڌڻ شروع ڪن ٿا، اهي مخصوص مثالن تي نظر اچن ٿا، مان سمجهان ٿو ته اهو ٺيڪ آهي، اهو واقعي ڪارائتو ٿي سگهي ٿو، اسان کي پڻ هن جي ضرورت آهي، اهو تمام سٺو آهي.
اهو آهي، انهن عملن کي معياري ڪرڻ تي سڀ بنيادي ڪم توهان لاء اڳ ۾ ئي ڪيو ويو آهي. اهو توهان لاءِ رهي ٿو ته خاص طور تي توهان جي ڪمپني ۾ SRE جي ڪردار جو تعين ڪرڻ ۽ اصل ۾ انهن سڀني عملن تي عمل ڪرڻ شروع ڪيو، جن کي، ٻيهر، اڳ ۾ ئي بيان ڪيو ويو آهي. اهو آهي، ننڍن ڪمپنين لاء مفيد اصولن مان، هي هميشه SLA، SLI، SLO جي تعريف آهي. جيڪڏهن توهان سافٽ ويئر ۾ شامل نه آهيو، ته اهي اندروني SLAs ۽ اندروني SLOs، غلطين لاء هڪ اندروني بجيٽ هوندي. اهو تقريبن هميشه ٽيم جي اندر ۽ ڪاروبار جي اندر ڪجهه دلچسپ بحثن ڏانهن وٺي ٿو، ڇاڪاڻ ته اهو ٿي سگهي ٿو ته توهان انفراسٹرڪچر تي خرچ ڪيو، مثالي عملن جي ڪنهن قسم جي تنظيم تي، مثالي پائپ لائن ضروري کان وڌيڪ آهي. ۽ اهي 4 نينس جيڪي توهان وٽ آئي ٽي ڊپارٽمينٽ ۾ آهن، توهان کي هاڻي انهن جي ضرورت ناهي. پر ساڳئي وقت، توهان وقت خرچ ڪري سگهو ٿا، ڪنهن ٻئي تي غلطي لاء بجيٽ خرچ ڪريو.
انهي جي مطابق، نگراني جي نگراني ۽ تنظيم ڪنهن به سائيز جي ڪمپني لاء ڪارائتو آهي. ۽ عام طور تي، سوچڻ جو هي طريقو، جتي غلطيون ڪجهه قابل قبول آهن، جتي هڪ بجيٽ آهي، جتي مقصد آهن، اهو ٻيهر ڪارائتو آهي ڪنهن به سائيز جي ڪمپني لاء، 3 ماڻهن لاء شروعاتي کان شروع ٿيندڙ.
ٽيڪنيڪل nuances جي آخري جي باري ۾ ڳالهائڻ جي نگراني آهي. ڇو ته جيڪڏھن اسان SLA، SLI، SLO بابت ڳالھائي رھيا آھيون، اسان مانيٽر ڪرڻ کان سواءِ سمجھي سگھون ٿا ته ڇا اسان بجيٽ ۾ فٽ آھيون، ڇا اسان پنھنجي مقصدن جي تعميل ڪريون ٿا، ۽ ڪيئن اسان حتمي SLA تي اثر انداز ٿيون. مون ڪيترا ڀيرا ڏٺو آهي ته مانيٽرنگ هن طرح ٿئي ٿي: اتي ڪجهه قدر آهي، مثال طور، سرور ڏانهن درخواست جو وقت، سراسري وقت، يا ڊيٽابيس ڏانهن درخواستن جو تعداد. هن وٽ هڪ انجنيئر طرفان مقرر ڪيل معيار آهي. جيڪڏهن ميٽرڪ معمول کان انحراف ڪري، پوء هڪ اي ميل اچي ٿو. اهو سڀ ڪجهه بلڪل بيڪار آهي، ضابطي جي طور تي، ڇاڪاڻ ته اهو انتباہ جي اهڙي گوت، نگراني کان پيغامن جو هڪ گوڙ، جڏهن هڪ شخص، پهريون ڀيرو، انهن کي هر وقت تفسير ڪرڻ گهرجي، اهو طئي ڪيو ته ڇا ميٽرڪ جي قيمت جو مطلب آهي. ڪجهه عمل جي ضرورت آهي. ۽ ٻيو، هو صرف انهن سڀني خبردارين کي ڏسڻ کان روڪي ٿو، جڏهن بنيادي طور تي هن کان ڪا به ڪارروائي گهربل ناهي. اهو هڪ سٺو مانيٽرنگ قاعدو آهي ۽ پهريون قاعدو جڏهن SRE لاڳو ٿئي ٿو ته نوٽيفڪيشن صرف تڏهن اچڻ گهرجي جڏهن عمل جي ضرورت هجي.
معياري صورت ۾، واقعن جا 3 سطح آھن. اتي الرٽ آهن، ٽڪيٽون آهن، لاگ آهن. خبرداريون ڪجھھ آھن جيڪي توھان کي فوري طور تي عمل ڪرڻ جي ضرورت آھي. اهو آهي، هر شيء ڀڄي وئي آهي، توهان کي ان کي درست ڪرڻ جي ضرورت آهي. ٽڪيٽون آهن جيڪي دير جي عمل جي ضرورت آهي. ها، توهان کي ڪجهه ڪرڻ جي ضرورت آهي، توهان کي ڪجهه دستي طور تي ڪرڻ جي ضرورت آهي، خودڪار ناڪام ٿي، پر توهان کي ايندڙ ڪجهه منٽن لاء اهو ڪرڻ جي ضرورت ناهي. لاگس ڪجھ به آھن جن کي عمل جي ضرورت نه آھي، ۽ عام طور تي، جيڪڏھن شيون چڱي طرح ھلندا آھن، ڪو به انھن کي پڙھي نه سگھندو آھي. توهان کي صرف لاگ پڙهڻ جي ضرورت پوندي، جڏهن، پوئتي موٽڻ ۾، اهو ظاهر ٿيو ته ڪجهه وقت لاء ڪجهه ڀڄي ويو، اسان کي ان جي باري ۾ ڄاڻ نه هئي. يا توهان کي ڪجهه تحقيق ڪرڻ جي ضرورت آهي. پر عام طور تي، هر شيء جيڪا ڪنهن به عمل جي ضرورت ناهي، لاگن ڏانهن ويندي آهي.
ان سڀني جي ضمني اثر جي طور تي، جيڪڏهن اسان وضاحت ڪئي آهي ته ڪهڙن واقعن جي عملن جي ضرورت آهي ۽ چڱي طرح بيان ڪيو آهي ته اهي عمل ڇا ٿيڻ گهرجن، ان جو مطلب اهو آهي ته عمل خودڪار ٿي سگهي ٿو. اهو آهي، جيڪو ٿئي ٿو. اسان خبرداريءَ کان هلون ٿا. اچو ته عمل تي وڃو. اسان هن عمل جي وضاحت ڏانهن وڃو. ۽ پوء اسان خودڪار طريقي سان اڳتي وڌو. اهو آهي، ڪنهن به خودڪار هڪ واقعي جي رد عمل سان شروع ٿئي ٿو.
مانيٽرنگ کان، اسان هڪ اصطلاح ڏانهن وڃون ٿا جنهن کي مشاهدو سڏيو ويندو آهي. گذريل ڪجھ سالن کان ھن لفظ جي چوڌاري ڪجھھ hype پڻ آھي. ۽ ٿورا ماڻھو سمجھن ٿا ته ان جو مطلب ڇا آھي ان حوالي سان. پر بنيادي نقطو اهو آهي ته مشاهدو نظام جي شفافيت لاء هڪ ميٽرڪ آهي. جيڪڏهن ڪجهه غلط ٿي ويو، توهان ڪيتري جلدي اندازو لڳائي سگهو ٿا ته ڇا واقعي غلط ٿي ويو آهي ۽ ان وقت سسٽم جي حالت ڪهڙي هئي. ڪوڊ جي لحاظ کان: ڪهڙو فنڪشن ناڪام ٿيو، ڪهڙي خدمت ناڪام ٿي. ڪهڙي حالت هئي، مثال طور، اندروني متغير، ترتيب. انفراسٽرڪچر جي لحاظ کان، هي اهو آهي جنهن ۾ دستيابي زون ۾ ناڪامي واقع ٿي، ۽ جيڪڏهن توهان وٽ ڪوبرنيٽس آهي، ته پوء ڪهڙي پوڊ ۾ ناڪامي ٿي، پوڊ جي حالت ڇا هئي. ۽ مطابق، مشاهدي جو MTTR سان سڌو تعلق آهي. خدمت جي مشاهدي جي صلاحيت جيتري وڌيڪ هوندي، اوترو ئي آسانيءَ سان غلطي کي سڃاڻڻ، غلطي کي درست ڪرڻ اوترو آسان، غلطي کي خودڪار ڪرڻ اوترو آسان، MTTR اوترو گهٽ.
ٻيهر ننڍين ڪمپنين ڏانهن منتقل ٿيڻ، اهو پڇڻ تمام عام آهي، اڃا به، ٽيم جي سائيز سان ڪيئن ڊيل ڪجي، ۽ ڇا هڪ ننڍڙي ٽيم کي الڳ SRE کي ڀرتي ڪرڻ جي ضرورت آهي. اڳ ۾ ئي هن جي باري ۾ ٿورو اڳ ڳالهائي. شروعاتي مرحلي ۾ يا، مثال طور، هڪ ٽيم جي ترقي جي پهرين مرحلن تي، اهو بلڪل ضروري ناهي، ڇاڪاڻ ته SRE کي هڪ عبوري ڪردار بڻائي سگهجي ٿو. ۽ هي ٽيم کي ٿورڙي بحال ڪندو، ڇاڪاڻ ته اتي گهٽ ۾ گهٽ ڪجهه تنوع آهي. ۽ انهي سان گڏ اهو ماڻهن کي حقيقت لاء تيار ڪندو ته ترقي سان، عام طور تي، SRE جون ذميواريون تمام گهڻو تبديل ٿي وينديون. جيڪڏهن توهان هڪ شخص کي نوڪري ڪريو، پوء، يقينا، هن کي ڪجهه اميدون آهن. ۽ اهي اميدون وقت سان تبديل نه ٿينديون، پر ضرورتون تمام گهڻيون تبديل ٿينديون. تنهن ڪري، هڪ SRE کي ڪيئن ڀرتي ڪجي شروعاتي مرحلن ۾ ڪافي ڏکيو آهي. پنهنجو پاڻ کي وڌائڻ تمام آسان آهي. پر اهو سوچڻ جي قابل آهي.
صرف استثنا، شايد، اهو آهي جڏهن اتي تمام سخت ۽ چڱي طرح بيان ڪيل ترقي گهرجن گهرجن. اھو آھي، ھڪڙي شروعاتي جي صورت ۾، اھو ٿي سگھي ٿو ڪنھن قسم جو دٻاءُ سيڙپڪارن کان، ڪنھن قسم جي اڳڪٿي لاءِ ڪيترائي ڀيرا ھڪ ئي وقت ۾. پوءِ هڪ SRE کي ڀرتي ڪرڻ بنيادي طور تي جائز آهي ڇاڪاڻ ته اهو صحيح ٿي سگهي ٿو. اسان کي ترقي جون گهرجون آهن، اسان کي هڪ اهڙي شخص جي ضرورت آهي جيڪو حقيقت جو ذميوار هجي ته اهڙي ترقي سان ڪجهه به نه ٽٽندو.
هڪ وڌيڪ سوال. ڇا ڪجي جڏهن ڪيترائي ڀيرا ڊولپرز هڪ فيچر کٽي ٿو جيڪو ٽيسٽ پاس ڪري ٿو، پر پيداوار کي ٽوڙي ٿو، بنياد لوڊ ڪري ٿو، ٻين خاصيتن کي ٽوڙي ٿو، ڪهڙي عمل کي لاڳو ڪرڻ. ان جي مطابق، هن معاملي ۾، اهو غلطين لاء بجيٽ آهي جيڪو متعارف ڪرايو ويو آهي. ۽ ڪجھ خدمتون، ڪجھ خاصيتون اڳ ۾ ئي پيداوار ۾ آزمائشي آھن. اهو ڪينري ٿي سگهي ٿو، جڏهن صرف استعمال ڪندڙن جو هڪ ننڍڙو تعداد، پر اڳ ۾ ئي پيداوار ۾، هڪ خاصيت مقرر ڪئي وئي آهي، پر اڳ ۾ ئي اميد آهي ته جيڪڏهن ڪجهه ڀڃي، مثال طور، سڀني صارفين جي اڌ سيڪڙو لاء، اهو اڃا تائين ملندو. غلطين لاء بجيٽ. انهي جي مطابق، ها، اتي هڪ غلطي هوندي، ڪجهه صارفين لاء هر شيء ڀڄي ويندي، پر اسان اڳ ۾ ئي چيو آهي ته اهو عام آهي.
SRE اوزار بابت هڪ سوال هو. اھو آھي، ڇا آھي خاص طور تي ڪجھھ آھي جيڪو SREs استعمال ڪندو آھي جيڪو ٻيو ڪو نه ڪندو. حقيقت ۾، اتي ڪي انتهائي خاص افاديتون آهن، اتي ڪجهه قسم جو سافٽ ويئر آهي، مثال طور، لوڊ ڪرڻ يا ڪينري A / B جاچ ۾ مصروف آهي. پر بنيادي طور تي SRE ٽول ڪٽ اهو آهي جيڪو توهان جا ڊولپر اڳ ۾ ئي استعمال ڪري رهيا آهن. ڇو ته SRE سڌو سنئون ڊولپمينٽ ٽيم سان رابطو ڪري ٿو. ۽ جيڪڏهن توهان وٽ مختلف اوزار آهن، اهو ظاهر ٿيندو ته اهو هم وقت سازي ۾ وقت وٺندو آهي. خاص طور تي جيڪڏهن SREs وڏين ٽيمن ۾ ڪم ڪن ٿيون، وڏين ڪمپنين ۾ جتي ڪيتريون ئي ٽيمون ٿي سگهن ٿيون، اها ڪمپني جي وسيع معيار آهي جيڪا هتي تمام گهڻي مدد ڪندي، ڇاڪاڻ ته جيڪڏهن 50 ٽيمن ۾ 50 مختلف يوٽيلٽيز استعمال ڪيون وڃن، ان جو مطلب اهو آهي ته SRE کي انهن کي ڄاڻڻ گهرجي. سڀ. ۽ يقيناً اهو ڪڏهن به نه ٿيندو. ۽ ڪم جي معيار، گهٽ ۾ گهٽ ڪجهه ٽيمن جي ڪنٽرول جي معيار کي تمام گهڻو گهٽجي ويندو.
اسان جي ويبينار ختم ٿيڻ تي آهي. مون ڪجھ بنيادي شيون ٻڌائڻ ۾ مدد ڪئي. يقينا، SRE بابت ڪجھ به نه ٿو چئي سگهجي ۽ هڪ ڪلاڪ ۾ سمجهي سگهجي ٿو. پر مون کي اميد آهي ته مون هن طريقي سان سوچڻ جو انتظام ڪيو، بنيادي اهم نقطا. ۽ پوءِ اهو ممڪن ٿيندو، جيڪڏهن دلچسپي رکي، موضوع تي غور ڪرڻ لاءِ، پنهنجو پاڻ سکو، ڏسو ته اهو ڪيئن عمل ڪيو پيو وڃي ٻين ماڻهن طرفان، ٻين ڪمپنين ۾. ۽ مطابق، فيبروري جي شروعات ۾، اسان وٽ اچو Slurm SRE تي.
Slurm SRE هڪ ٽن ڏينهن جو سخت ڪورس آهي جيڪو ان بابت ڳالهائيندو جنهن جي باري ۾ آئون هاڻي ڳالهائي رهيو آهيان، پر تمام گهڻي کوٽائي سان، حقيقي ڪيسن سان، عملي طور تي، پوري شدت جو مقصد عملي ڪم آهي. ماڻهن کي ٽيمن ۾ ورهايو ويندو. توهان سڀني کي حقيقي ڪيسن تي ڪم ڪيو ويندو. ان مطابق، اسان وٽ Booking.com استادن ايوان ڪرگلوف ۽ بين ٽائلر آهن. اسان وٽ گوگل کان هڪ شاندار يوگين باراباس آهي، سان فرانسسڪو کان. ۽ مان به توکي ڪجهه ٻڌايان. سو اسان جو دورو ضرور ڪجو.
سو، ببليوگرافي. SRE تي حوالا آهن. ساڳئي ڪتاب تي، يا بلڪه 2 ڪتابن تي SRE بابت، گوگل طرفان لکيل آهي. ٻيو ڪو , جتي شرطون ۽ انهن جي درخواست ٿورو وڌيڪ تفصيلي آهي. ايندڙ 3 مختلف ڪمپنين ۾ SRE تي رپورٽون آهن. پهريون - ، هي گوگل جي بين ٽرينر کان هڪ اهم نوٽ آهي. ٻيون - . ٽيون وري آهي . چوٿين رپورٽ کان ، جنهن وٽ 5 ملڪن ۾ صرف 190 اهم SRE ملازم آهن. اهو سڀ ڪجهه ڏسڻ لاءِ تمام دلچسپ آهي ، ڇاڪاڻ ته جيئن ته DevOps جو مطلب مختلف ڪمپنين ۽ حتي مختلف ٽيمن لاءِ تمام مختلف شيون آهن ، SRE وٽ تمام مختلف ذميواريون آهن ، حتي ساڳي سائز جي ڪمپنين ۾.
افراتفري انجنيئرنگ جي اصولن تي 2 وڌيڪ لنڪس: , . ۽ آخر ۾ سيريز مان 3 فهرستون آھن Awesome Lists بابت ، بابت ۽ اٽڪل . SRE تي لسٽ ناقابل يقين حد تائين وڏي آهي، اهو ضروري ناهي ته ان جي ذريعي وڃو، اٽڪل 200 آرٽيڪل آهن. مان اُتي کان آرٽيڪلز جي صلاح ڏيان ٿو صلاحيت جي منصوبابندي بابت ۽ بي قصور پوسٽ مارٽم بابت.
دلچسپ مضمون
هن وقت مون کي ٻڌڻ لاء توهان جي مهرباني. اميد ته توهان ڪجهه سکيو هوندو. اميد ته توھان وٽ ڪافي مواد آھي جيڪو اڃا وڌيڪ سکڻ لاءِ. ۽ توهان کي ڏسندا. اميد ته فيبروري ۾.
ويبينار جي ميزباني ڪئي وئي ايڊورڊ ميدوديف.
پي ايس: انهن لاءِ جيڪي پڙهڻ پسند ڪن ٿا، ايڊورڊ حوالن جي هڪ فهرست ڏني. جيڪي عملي طور سمجھڻ کي ترجيح ڏين ٿا، اھي ڀليڪار آھن .
جو ذريعو: www.habr.com