SRE (د سایټ د اعتبار انجنیري) د ویب پروژو د لاسرسي وړ کولو لپاره یوه تګلاره ده. دا د DevOps لپاره یو چوکاټ ګڼل کیږي او وايي چې څنګه د DevOps کړنو پلي کولو کې بریالي شي. دا مقاله ژباړه کوي شپږم فصل د توزیع شوي سیسټمونو څارنه کتابونه د سایټ د اعتبار انجنیري د ګوګل څخه. ما دا ژباړه پخپله چمتو کړه او د څارنې پروسې په پوهیدو کې زما په خپله تجربه تکیه وکړه. په ټیلیګرام چینل کې @monitorim_it и بلاګ په منځني ډول ما د ورته کتاب د 4 څپرکي د ژباړې لینک هم د خدماتو کچې اهدافو په اړه پوسټ کړ.

د پیشو لخوا ژباړه. له لوستلو خوند واخلئ!

د ګوګل SRE ټیمونه د بریالي څارنې او خبرتیا سیسټمونو جوړولو لپاره لومړني اصول او غوره کړنې لري. دا فصل سپارښتنې وړاندې کوي چې د ویب پاڼې لیدونکي له کومو ستونزو سره مخ کیدی شي او څنګه هغه ستونزې حل کړي چې د ویب پاڼو ښودل ستونزمن کوي.

تعریفونه

د څارنې اړوند موضوعاتو په اړه د بحث لپاره هیڅ یو لغت نشته. حتی په ګوګل کې، لاندې شرایط په عام استعمال کې ندي، مګر موږ به ترټولو عام تفسیرونه لیست کړو.

څارنه

د سیسټم په اړه د ریښتیني وخت مقداري ډیټا راټولول ، پروسس کول ، راټولول او ښودل: د غوښتنو شمیر او ډولونه ، د غلطیو شمیر او د غلطیو ډولونه ، د پروسس کولو وخت او سرور وخت غوښتنه کول.

د سپینې بکس څارنه

نظارت د میټریکونو پراساس چې د سیسټم داخلي لخوا ښودل شوي ، پشمول د لاګونو ، JVM یا HTTP هینډلر پروفایل میټریکونه چې داخلي احصایې رامینځته کوي.

د تور بکس څارنه

د کارونکي له نظره د غوښتنلیک چلند ازموینه.

ډشبورډ (ډشبورډونه)

یو انٹرفیس (معمولا یو ویب انٹرفیس) چې د خدماتو کلیدي روغتیا شاخصونو عمومي کتنه وړاندې کوي. ډشبورډ کولی شي فلټرونه ولري، د دې وړتیا چې د ښودلو لپاره کوم میټریکونه غوره کړي، او داسې نور. انٹرفیس د کاروونکو لپاره خورا مهم میټریکونو پیژندلو لپاره ډیزاین شوی. ډشبورډ کولی شي د تخنیکي مالتړ کارمندانو لپاره معلومات هم ښکاره کړي: د غوښتنې کتار، د لوړ لومړیتوب غلطیتونو لیست، د مسؤلیت د یوې ټاکلې ساحې لپاره ګمارل شوی انجنیر.

خبرتیا (خبرتیا)

خبرتیاوې چې هدف یې د یو شخص لخوا د بریښنالیک یا بل ډول ترلاسه کول دي ، کوم چې ممکن د غلطیو یا د غوښتنې په کتار کې د زیاتوالي په پایله کې رامینځته شي. خبرتیاوې په دې ډول طبقه بندي شوي دي: ټکټونه، بریښنالیک خبرتیاوې او د رسول پیغامونه.

اصلي لامل (اصلي لامل)

د سافټویر نیمګړتیا یا انساني تېروتنه چې کله سم شي، باید بیا واقع نشي. ستونزه کیدای شي ډیری اصلي لاملونه ولري: د پروسې ناکافي اتومات، د سافټویر نیمګړتیا، د غوښتنلیک منطق ناکافي مطالعه. د دې فکتورونو څخه هر یو اصلي لامل کیدی شي، او هر یو باید له منځه یوړل شي.

نوډ او ماشین (نوډ او ماشین)

د تبادلې وړ شرایط په فزیکي سرور، مجازی ماشین، یا کانټینر کې د چلولو غوښتنلیک یو واحد مثال ته اشاره کوي. په یو ماشین کې ډیری خدمتونه کیدی شي. خدمتونه کیدی شي:

• د یو بل سره تړاو لري: د بیلګې په توګه، د کیچ سرور او ویب سرور؛
• په ورته هارډویر کې غیر اړونده خدمات: د مثال په توګه، د کوډ ذخیره او د ترتیب کولو سیسټم لپاره وزرډ، لکه ګوډاګی او یا مشر.

ټیله کول

د سافټویر ترتیب کې کوم بدلون.

ولې څارنې ته اړتیا ده

ډیری دلیلونه شتون لري چې ولې غوښتنلیکونه باید وڅیړل شي:

د اوږد مهاله رجحاناتو تحلیل

ډیټابیس څومره لوی دی او څومره چټک وده کوي؟ د کاروونکو ورځني شمیر څنګه بدلیږي؟

د فعالیت پرتله کول

ایا پوښتنې د Ajax DB 2.72 په پرتله د بایټ 3.14 Acme بالټ کې ګړندي دي؟ د اضافي نوډ له څرګندیدو وروسته غوښتنې څومره ښه ساتل کیږي؟ ایا سایټ د تیرې اونۍ په پرتله سست شوی؟

خبرتیا (اطلاعات)

یو څه مات شوی او څوک باید سم کړي. یا یو څه به ژر مات شي او څوک باید ژر تر ژره وګوري.

د ډشبورډونو جوړول

ډشبورډونه باید اساسي پوښتنو ته ځواب ووایي او یو څه پکې شامل کړي "4 طلایی نښې" - ځنډ (تعدیل)، ترافیک (ترافيک)، تېروتنې (غلطۍ) او د بار ارزښت (سنتریت).

د مخکینۍ تحلیل ترسره کول (دبګ کول)

د غوښتنې پروسس کولو ځنډ ډیر شوی، په ورته وخت کې نور څه پیښ شوي؟
د څارنې سیسټمونه د سوداګرۍ استخباراتي سیسټمونو او د امنیتي پیښو تحلیل اسانه کولو لپاره د معلوماتو سرچینې په توګه ګټور دي. ځکه چې دا کتاب د انجینرۍ په ساحو تمرکز کوي چې SREs تخصص لري، موږ به دلته د څارنې تخنیکونو په اړه بحث ونه کړو.

نظارت او خبرتیا سیسټم ته اجازه ورکوي چې ووایی کله چې مات شوی یا د ماتیدو په حال کې دی. کله چې یو سیسټم نشي کولی په اوتومات ډول خپل ځان ترمیم کړي، موږ یو انسان غواړو چې خبرتیا تحلیل کړي، معلومه کړي چې ستونزه لاهم شتون لري، دا حل کړي، او د هغې اصلي لامل وټاکي. که تاسو د سیسټم اجزاو پلټنه نه کوئ، تاسو به هیڅکله خبرتیا ترلاسه نه کړئ ځکه چې "یو څه لږ عجیب ښکاري."

د انساني خبرتیاو بارول د کارمند د وخت خورا ګران کار دی. که کارمند کار کوي، خبرتیا د کار جریان مداخله کوي. که چیرې کارمند په کور کې وي، خبرتیا د شخصي وخت او احتمالي خوب سره مداخله کوي. کله چې خبرتیاوې په مکرر ډول پیښیږي ، کارمندان د راتلونکو خبرتیاو څخه ډډه کوي ، ځنډوي یا له پامه غورځوي. د وخت په تیریدو سره دوی اصلي خبرتیا له پامه غورځوي، کوم چې د شور پیښو لخوا پوښل شوی. د خدماتو مداخلې د اوږدې مودې لپاره دوام کولی شي ځکه چې د شور پیښې د ګړندۍ ستونزې تشخیص او حل مخه نیسي. د عامه پتې اغیزمن سیسټمونه د غږ څخه تر غږ پورې ښه سیګنال لري.

د څارنې له سیستم څخه د معقولو توقعاتو معلومول

د پیچلي غوښتنلیک لپاره د نظارت تنظیم کول پخپله یو پیچلي انجینري دنده ده. حتی د راټولولو، ښودلو، او خبرتیا وسیلو د پام وړ زیربنا سره، د 10-12 غړو Google SRE ټیم په عموم ډول یو یا دوه کسان شامل دي چې اصلي موخه یې د څارنې سیسټم جوړول او ساتل دي. دا شمیره د وخت په تیریدو سره کمه شوې ده ځکه چې موږ د څارنې زیربنا عمومي او مرکزي کوو، مګر د SRE هر ټیم معمولا لږ تر لږه د څارنې یوازینی کارمند لري. دا باید وویل شي چې پداسې حال کې چې د نظارت سیسټم ډشبورډونو لیدل خورا په زړه پوري دي ، د SRE ټیمونه په احتیاط سره د داسې شرایطو مخه نیسي چې څوک اړتیا لري د ستونزو نظارت کولو لپاره سکرین ته وګوري.

په عموم کې، ګوګل د واقعیت څخه وروسته د تحلیلي وسیلو سره ساده او چټک څارنې سیسټمونو ته لیږدول شوی. موږ د "جادو" سیسټمونو څخه مخنیوی کوو چې هڅه کوي د حدونو وړاندوینه وکړي یا په اتوماتيک ډول د اصلي لامل کشف کړي. هغه سینسرونه چې د کارونکي په پای کې غوښتنې کې غیر ارادي مینځپانګې کشف کوي یوازینۍ بیلګه ده؛ تر هغه چې دا سینسر ساده پاتې شي، دوی کولی شي په چټکۍ سره د جدي عوارضو لاملونه ومومي. د څارنې ډیټا کارولو لپاره نور فارمیټونه لکه د ظرفیت پلان کول یا د ترافیک وړاندوینه ، ډیر ننګونې دي. د ډیر اوږد وخت (میاشتو یا کلونو) لپاره د ټیټ نمونې نرخ (ساعتونو یا ورځو) کې مشاهده به اوږدمهاله رجحان څرګند کړي.

د ګوګل SRE ټیم د پیچلي انحصاري درجې سره د بریالیتوب مختلف درجې سره کار کړی. موږ په ندرت سره مقررات کاروو لکه "که زه پوه شم چې ډیټابیس ورو شوی، زه د ډیټابیس سست خبرتیا ترلاسه کوم، که نه نو زه د سایټ سست خبرتیا ترلاسه کوم." د انحصار پر بنسټ مقررات معمولا زموږ د سیسټم نه بدلیدونکي برخو ته راجع کیږي، لکه د ډیټا مرکز ته د کاروونکي ترافیک فلټر کولو سیسټم. د مثال په توګه، "که چیرې د ډیټا مرکز ترافیک فلټر کول تنظیم شوي وي، ما د کاروونکو غوښتنو پروسس کولو کې د ځنډ په اړه خبرداری مه ورکوئ" د ډیټا مرکز خبرتیاو لپاره یو عام قاعده ده. په ګوګل کې لږ ټیمونه د پیچلي انحصار درجه بندي مالتړ کوي ځکه چې زموږ زیربنا د دوامداره بیاکتنې دوامداره نرخ لري.

په دې فصل کې بیان شوي ځینې نظرونه لاهم ریښتیا دي: تل د نښې څخه اصلي لامل ته د ګړندي حرکت کولو لاره شتون لري ، په ځانګړي توګه په تل بدلیدونکي سیسټمونو کې. له همدې امله، پداسې حال کې چې دا څپرکی د څارنې سیسټمونو لپاره ځینې اهداف په ګوته کوي او دا اهداف څنګه ترلاسه کوي، دا مهمه ده چې د څارنې سیسټمونه ساده او په ټیم کې د هرچا لپاره د پوهیدو وړ وي.

په ورته ډول، د شور کچه ټیټه او د سیګنال کچه لوړه ساتلو لپاره، د څارنې څیزونو ته چې خبرداری ورکول کیږي باید خورا ساده او د باور وړ وي. هغه قواعد چې د انسانانو لپاره اخطارونه رامینځته کوي باید د پوهیدو لپاره اسانه وي او روښانه ستونزه وړاندې کړي.

نښې او لاملونه

ستاسو د څارنې سیسټم باید دوه پوښتنې ځواب کړي: "څه مات شوی" او "ولې مات شوی".
"څه مات شو" نښې ته اشاره کوي، او "ولې مات شوی" علت ته اشاره کوي. لاندې جدول د داسې لینکونو مثالونه ښیې.

علامه
دليل

د HTTP تېروتنه 500 یا 404 ترلاسه کول
د ډیټابیس سرورونه اړیکې ردوي

ورو ورو سرور ځوابونه
د لوړ CPU کارول یا خراب شوی ایترنیټ کیبل

په انټارکټیکا کې کاروونکي د پیشو GIFs نه ترلاسه کوي
ستاسو CDN د ساینس پوهانو او فیلین څخه نفرت کوي، نو ځینې IPs تور لیست شوي دي

شخصي مینځپانګه هرچیرې شتون لري
د نوي سافټویر ریلیز رول کول د فایر وال ټول ACL هیر کړي او هرڅوک یې پریږدي

"څه" او "ولې" د اعظمي سیګنال او لږترلږه شور سره د ښه نظارت سیسټم رامینځته کولو لپاره یو له خورا مهم ساختماني بلاکونو څخه دي.

تور بکس په مقابل کې سپین بکس

موږ د جدي میټریکونو لپاره د سپینې بکس پراخه څارنه د تور بکس د معمولي څارنې سره یوځای کوو. د سپینې بکس سره د بلیک باکس پرتله کولو ترټولو اسانه لار دا ده چې بلیک باکس د نښې متمرکز دی او د فعالې څارنې پرځای عکس العمل دی: "سیسټم اوس سم کار نه کوي." سپینه بکس د سیسټمونو داخلي چک کولو وړتیاو پورې اړه لري: د پیښې لاګ یا ویب سرورونه. په دې توګه، سپینه بکس تاسو ته اجازه درکوي چې راتلونکې ستونزې، نیمګړتیاوې چې د غوښتنې بیا لیږد په څیر ښکاري، کشف کړئ.

په یاد ولرئ چې په څو پرت سیسټم کې، د یو انجنیر د مسؤلیت په ساحه کې یوه نښه د بل انجنیر د مسؤلیت په ساحه کې یوه نښه ده. د مثال په توګه، د ډیټابیس فعالیت کم شوی. ورو ډیټابیس لوستل د ډیټابیس SRE نښه ده چې دوی کشف کوي. په هرصورت، د مخکینۍ پای SRE لپاره چې ورو ویب پاڼه ګوري، د ورته سست ډیټابیس لوستلو دلیل دا دی چې ډیټابیس ورو دی. له همدې امله، د سپینې بکس څارنه کله ناکله په نښو تمرکز کوي او کله ناکله په لاملونو پورې اړه لري، دا څومره پراخه ده.

کله چې د ډیبګ کولو لپاره ټیلی میټري راټول کړئ، د سپینې بکس څارنه اړینه ده. که چیرې ویب سرورونه د ډیټابیس پوښتنو ته ځواب ویلو کې سست وي، تاسو اړتیا لرئ پوه شئ چې ویب سرور څومره ګړندی د ډیټابیس سره اړیکه لري او څومره چټک ځواب ورکوي. که نه نو، تاسو به نشئ کولی د سست ډیټابیس سرور او د ویب سرور او ډیټابیس ترمنځ د شبکې ستونزې ترمنځ توپیر ووایاست.

د بلیک باکس څارنه کلیدي ګټه لري کله چې خبرتیاوې لیږل کیږي: تاسو ترلاسه کونکي ته خبرتیا رامینځته کوئ کله چې ستونزه دمخه اصلي نښې رامینځته کړي. له بلې خوا، د تور بکس ستونزه چې تراوسه نه ده رامینځته شوې، مګر د راتلونکي لپاره، څارنه بې ګټې ده.

څلور طلایی نښې

د څارنې څلور زرین سیګنالونه ځنډ، ترافیک، تېروتنې، او سنتریت دي. که تاسو یوازې د څلورو کاروونکو سیسټم میټریک اندازه کولی شئ، په دغو څلورو تمرکز وکړئ.

ځنډ

د غوښتنې پروسس کولو لپاره اړین وخت. دا مهمه ده چې د بریالي او ناکامه غوښتنو د ځنډ ترمنځ توپیر وکړو. د مثال په توګه، د HTTP 500 تېروتنه د ډیټابیس یا بل بیک انډ سره د ورک شوي پیوستون له امله رامینځته کیدی شي په چټکۍ سره تشخیص شي، په هرصورت، د HTTP 500 تېروتنه کولی شي ناکامه غوښتنه په ګوته کړي. په ټولیز ځنډ کې د 500 غلطۍ اغیزې موندل کولی شي غلطې پایلې رامینځته کړي. له بلې خوا، ورو تېروتنه حتی ګړندۍ تېروتنه ده! نو ځکه، دا مهمه ده چې د تېروتنې د فلټر کولو پرځای د تېروتنې ځنډ تعقیب کړئ.

د ترافيکو

ستاسو سیسټم ته د غوښتنو شمیر، د لوړې کچې سیسټم میټریکونو کې اندازه شوی. د ویب خدماتو لپاره، دا اندازه کول عموما په هر ثانیه کې د HTTP غوښتنو شمیره استازیتوب کوي چې د غوښتنو طبیعت (د بیلګې په توګه، جامد یا متحرک منځپانګې) ویشل شوي. د آډیو سټریمینګ سیسټم لپاره ، دا اندازه کول ممکن د شبکې I/O نرخ یا د ورته غونډو شمیر باندې متمرکز وي. د کلیدي ارزښت ذخیره کولو سیسټم لپاره، دا اندازه کیدای شي په هره ثانیه کې لیږد یا لټون وي.

تېروتنه

دا د ناکامه غوښتنو کچه ده، یا په ښکاره ډول (د مثال په توګه، HTTP 500)، په ښکاره ډول (د مثال په توګه، HTTP 200 مګر د خراب مینځپانګې سره یوځای شوی)، یا د پالیسۍ له مخې (د مثال په توګه، "که تاسو په یوه ثانیه کې ځواب ونیسئ، هر یو یوه ثانیه یوه تېروتنه ده"). که چیرې د ټولو ناکامیو شرایطو څرګندولو لپاره کافي HTTP ځواب کوډونه شتون ونلري ، نو د جزوي ناکامۍ موندلو لپاره ثانوي (داخلي) پروتوکولونو ته اړتیا لیدل کیدی شي. د دې ټولو غلطو غوښتنو څارنه غیرمعلوماتي کیدی شي، پداسې حال کې چې د پای څخه تر پای پورې سیسټم ازموینې کولی شي تاسو سره مرسته وکړي چې معلومه کړي چې تاسو غلط مینځپانګې پروسس کوئ.

سنتریشن

میټریک ښیې چې ستاسو خدمت څومره په پراخه کچه کارول کیږي. دا د سیسټم نظارت اندازه ده چې سرچینې پیژني چې خورا محدود دي (د مثال په توګه ، په سیسټم کې چې محدود حافظه لري ، حافظه ښیې ، په سیسټم کې د محدود I / O سره ، د I / O شمیر ښیې). په یاد ولرئ چې ډیری سیسټمونه مخکې له دې چې دوی 100٪ کارونې ته ورسیږي خرابیږي، نو د کارونې هدف درلودل اړین دي.

په پیچلي سیسټمونو کې، سنتریت د لوړې کچې بار اندازه کولو سره ضمیمه کیدی شي: آیا ستاسو خدمت په سمه توګه دوه چنده ټرافيک اداره کولی شي، یوازې 10٪ ډیر ټرافیک اداره کړي، یا حتی لږ ټرافیک اداره کړي چې اوس مهال یې کولی شي؟ د ساده خدماتو لپاره چې پیرامیټرې نلري چې د غوښتنې پیچلتیا بدلوي (د مثال په توګه "ما ته هیڅ نه راکوي" یا "زه یو ځانګړی یو مونوټونک انټیجر ته اړتیا لرم") چې په ندرت سره ترتیب بدلوي ، د جامد بار ازموینې ارزښت ممکن کافي وي. لکه څنګه چې په تیرو پراګراف کې بحث شوی، ډیری خدمتونه باید غیر مستقیم سیګنالونه وکاروي لکه د CPU کارول یا د شبکې بینډ ویت چې پیژندل شوی پورتنۍ حد لري. د ځنډ زیاتوالی اکثرا د سنتریت اصلي شاخص دی. په یوه کوچنۍ کړکۍ کې د 99 فیصده غبرګون وخت اندازه کول (د بیلګې په توګه یوه دقیقه) کولی شي ډیر ژر د سنتریت سیګنال ورکړي.

په نهایت کې ، سنتریت د راتلونکي سنتریت وړاندوینو سره هم تړاو لري ، لکه: "داسې ښکاري چې ستاسو ډیټابیس به ستاسو هارډ ډرایو په 4 ساعتونو کې ډک کړي."

که تاسو ټول څلور طلایی سیګنالونه اندازه کړئ او کله چې د یو میټریک سره ستونزه وي (یا د سنتریت په حالت کې ، نږدې یوه ستونزه) ، تاسو شخص ته خبر ورکړئ ، ستاسو خدمت به لږ یا لږ د نظارت پوښښ وي.

د لکۍ په اړه اندیښنه (یا وسیله او فعالیت)

کله چې له پیل څخه د څارنې سیسټم رامینځته کړئ ، نو دا د اوسط پراساس سیسټم رامینځته کولو لپاره لیوالتیا ده: اوسط ځنډ ، د اوسط نوډ CPU کارول ، یا اوسط ډیټابیس اشغال. د وروستي دوه مثالونو خطر څرګند دی: پروسیسرونه او ډیټابیسونه په خورا غیر متوقع ډول له مینځه وړل کیږي. همداسې په ځنډ باندې تطبیق کیږي. که تاسو په هره ثانیه کې د 100 غوښتنو سره د 1000ms اوسط ځنډ سره ویب خدمت پرمخ وړئ، د غوښتنو 1٪ کولی شي 5 ثانیې وخت ونیسي. که چیرې کاروونکي په ډیری ورته ویب خدماتو تکیه وکړي، د یو واحد پس منظر 99 فیصده کولی شي په اسانۍ سره د انٹرفیس منځني غبرګون وخت شي.

د ورو اوسط او خورا ورو ورو غوښتنو ترمینځ توپیر کولو ترټولو ساده لاره د ریښتیني ځنډونو پرځای په احصایو کې څرګند شوي غوښتنې اندازه کول دي (هیسټوګرامونه د ښودلو لپاره مناسبه وسیله ده) ، نه د حقیقي ځنډونو په پرتله: څومره غوښتنې د خدماتو لخوا وړاندې شوې چې اخیستې. د 0 ms او 10ms تر منځ، د 10ms او 30ms تر منځ، د 30ms او 100ms تر منځ، د 100ms او 300ms تر منځ، او داسې نور. د هسټوګرام حدود تقریبا په چټکۍ سره پراخول (د شاوخوا 3 فکتور په واسطه) اکثرا د پوښتنو ویش لیدلو لپاره اسانه لار ده.

د اندازه کولو لپاره سم دانه غوره کول

د سیسټم مختلف عناصر باید د توضیحاتو مختلف کچو سره اندازه شي. د مثال په ډول:

• د یوې مودې په اوږدو کې د CPU کارولو کارول به اوږده سپکونه ونه ښیې چې د لوړې ځنډ لامل کیږي.
• له بلې خوا، د ویب خدماتو لپاره چې په کال کې د 9 ساعتونو څخه ډیر وخت نه وي (99,9٪ کلنۍ اپټایم) په نښه کوي، د HTTP 200 ځواب لپاره په یوه دقیقه کې یو یا دوه ځله چک کول شاید غیر ضروري وي.
• په ورته ډول ، په هارډ ډرایو کې د 99,9٪ شتون لپاره په هر 1-2 دقیقو کې له یو ځل څخه ډیر وړیا ځای چیک کول شاید غیر ضروري وي.

پام وکړئ چې تاسو د ابعادو د کثافاتو جوړښت څنګه جوړ کړئ. په هر ثانیه کې د 1 CPU کارولو نرخ کولی شي په زړه پوري معلومات چمتو کړي ، مګر دا ډول پرله پسې اندازه کول د راټولولو ، ذخیره کولو او تحلیل لپاره خورا ګران کیدی شي. که ستاسو د څارنې هدف لوړې کچې ته اړتیا ولري او لوړ غبرګون ته اړتیا نلري، تاسو کولی شئ دا لګښتونه په سرور کې د میټریک راټولولو په ترتیب کولو سره کم کړئ او بیا د دې میترونو راټولولو او راټولولو لپاره یو بهرنی سیسټم تنظیم کړئ. ته کولای شی:

1. په هره ثانیه کې د CPU کارول اندازه کړئ.
2. تفصیل 5٪ ته راکم کړئ.
3. په هره دقیقه کې میټریکونه راټول کړئ.

دا ستراتیژي به تاسو ته اجازه درکړي چې د تحلیل او ذخیره کولو لپاره د لوړ سرونو تجربه کولو پرته خورا ګران ډیټا راټول کړئ.

څومره چې ممکنه وي ساده، مګر اسانه نه

د یو بل په سر کې د مختلف اړتیاو ذخیره کول کولی شي د څارنې خورا پیچلي سیسټم رامینځته کړي. د مثال په توګه، ستاسو سیسټم ممکن لاندې پیچلي عناصر ولري:

• د غوښتنې ځنډ لپاره د مختلف حدونو سره سم خبرتیاوې ، په مختلف سلنې کې ، په هر ډول مختلف میټریکونو کې.
• د احتمالي لاملونو موندلو او پیژندلو لپاره اضافي کوډ لیکل.
• د ستونزو د هر ممکنه لاملونو لپاره اړوند ډشبورډونه جوړ کړئ.

د احتمالي پیچلتیا سرچینې هیڅکله پای ته نه رسیږي. د ټولو سافټویر سیسټمونو په څیر، څارنه کیدای شي دومره پیچلې شي چې دا نازک، بدلون او ساتل ستونزمن کیږي.

له همدې امله ، خپل د نظارت سیسټم ډیزاین کړئ ترڅو دا څومره چې امکان ولري ساده کړئ. کله چې دا غوره کړئ چې څه تعقیب کړئ، لاندې ټکي په پام کې ونیسئ:

• هغه قواعد چې ډیری وختونه اصلي پیښې نیسي باید د امکان تر حده ساده، د وړاندوینې وړ او د باور وړ وي.
• د معلوماتو راټولولو، راټولولو، او خبرتیا لپاره ترتیب چې په مکرر ډول ترسره کیږي (د بیلګې په توګه، د ځینې SRE ټیمونو لپاره له ربع څخه لږ) باید لیرې شي.
• هغه میټریکونه چې راټول شوي مګر د مخکتنې پینل کې ندي ښودل شوي یا د کوم خبرتیا لخوا کارول کیږي د حذف کولو لپاره نوماندان دي.

په ګوګل کې، د میتریکونو بنسټیز راټولول او راټولول، د خبرتیاو او ډشبورډونو سره یوځای، د نسبتا ځان لرونکي سیسټم په توګه ښه کار کوي (د ګوګل د څارنې سیسټم په حقیقت کې په څو فرعي سیسټمونو ویشل شوی، مګر معمولا خلک د دې فرعي سیسټمونو ټولو اړخونو څخه خبر دي). دا د پیچلو سیسټمونو ازموینې نورو میتودونو سره د نظارت ترکیب کولو لپاره هڅول کیدی شي: د سیسټم تفصيلي پروفایل کول ، د پروسې ډیبګ کول ، د استثنا یا ناکامۍ توضیحات تعقیب کول ، د بار ازموینه ، د ننوتلو راټولول او تحلیل ، یا د ترافیک تفتیش. پداسې حال کې چې ډیری دا شیان د لومړني څارنې سره مشترکات شریکوي، د دوی مخلوط کول به ډیرې پایلې ولري او یو پیچلي او خراب سیسټم رامینځته کړي. لکه څنګه چې د سافټویر پراختیا د ډیری نورو اړخونو سره، د واضح، ساده، په نرمۍ سره یوځای شوي یوځای کولو نقطو سره د مختلف سیسټمونو مالتړ غوره ستراتیژي ده (د مثال په توګه، د ویب API کارول ترڅو د لنډیز ډیټا په بڼه ترلاسه کړي چې د اوږدې مودې لپاره ثابت پاتې کیدی شي. ).

د اصولو سره یوځای کول

په دې فصل کې بحث شوي اصول د څارنې او خبرتیا فلسفه کې یوځای کیدی شي چې د ګوګل SRE ټیمونو لخوا تایید او تعقیب کیږي. د دې څارنې فلسفې ته غاړه ایښودل د پام وړ دي، دا د خبرتیا میتودولوژی رامینځته کولو یا بیاکتنې لپاره یو ښه پیل ټکی دی، او کولی شي تاسو سره مرسته وکړي چې ستاسو د سازمان اندازې یا د خدماتو یا سیسټم پیچلتیا په پام کې نیولو پرته د عملیاتو لپاره سمې پوښتنې وپوښتئ.

کله چې د څارنې او خبرتیا قواعد رامینځته کړئ، د لاندې پوښتنو پوښتنه کولی شي تاسو سره د غلط مثبت او غیر ضروري خبرتیاو څخه مخنیوي کې مرسته وکړي:

• ایا دا قاعده د بل ډول نه پیژندل کیدونکي سیسټم حالت کشف کوي چې عاجل دی ، عمل ته زنګ وهي ، او په لازمي ډول کارونکي اغیزه کوي؟
• ایا زه کولی شم دا خبرتیا له پامه غورځولی شم چې پوهیدم دا بې ساري دی؟ کله او ولې کولی شم دا خبرداری له پامه غورځولی شم او څنګه کولی شم له دې سناریو څخه مخنیوی وکړم؟
• ایا دا خبرتیا پدې معنی ده چې کاروونکي په منفي توګه اغیزمن کیږي؟ ایا داسې شرایط شتون لري چیرې چې کاروونکي په منفي ډول اغیزه نلري، د بیلګې په توګه، د ټرافيکي فلټر کولو له امله یا کله چې د ازموینې سیسټمونه کاروي، خبرتیاوې چې باید فلټر شي؟
• ایا زه کولی شم د دې خبرتیا په ځواب کې اقدام وکړم؟ ایا دا اقدامات بیړني دي یا دوی کولی شي تر سهار پورې انتظار وکړي؟ ایا د عمل اتومات کول خوندي دي؟ ایا دا عمل به اوږدمهاله حل وي که لنډمهاله حل؟
• ځینې ​​​​خلک د دې مسلې لپاره ډیری خبرتیاوې ترلاسه کوي، نو ایا دا ممکنه ده چې شمیر کم کړي؟

دا پوښتنې د خبرتیا او خبرتیا سیسټمونو بنسټیز فلسفه منعکس کوي:

• هرکله چې خبرتیا راشي، زه باید سمدستي غبرګون وښیم. زه کولی شم په ورځ کې څو ځله مخکې له دې چې ستړی شم.
• هر خبرتیا باید تازه وي.
• د خبرتیا هر ځواب باید د انسان مداخلې ته اړتیا ولري. که چیرې خبرتیا په اتوماتيک ډول پروسس شي، نو دا باید راشي.
• خبرتیاوې باید د یوې نوې مسلې یا پیښې په اړه وي چې مخکې نه وي پیښ شوي.

دا طریقه ځینې توپیرونه روښانه کوي: که یو خبرتیا پخوانی څلور شرایط پوره کړي، دا مهمه نده چې خبرداری د سپینې بکس څارنې سیسټم یا بلیک بکس څخه لیږل شوی وي. دا طریقه هم ځینې توپیرونه پیاوړي کوي: دا غوره ده چې د علتونو په پرتله د نښو پیژندلو لپاره ډیرې هڅې مصرف کړئ. کله چې د لاملونو خبره راځي، تاسو یوازې د ناگزیر لاملونو په اړه اندیښنه ته اړتیا لرئ.

د اوږدې مودې څارنه

د نن ورځې تولید چاپیریال کې، د څارنې سیسټمونه د سافټویر جوړښت، د بار ځانګړتیاوو، او د فعالیت اهدافو بدلولو سره د تل پاتې تولید سیسټم څارنه کوي. خبرتیاوې، چې اوس مهال اتومات کول ستونزمن دي، ممکن عام شي، شاید حتی د حل کولو وړ وي. په دې وخت کې، یو څوک باید د ستونزې اصلي لاملونه ومومي او حل کړي؛ که دا ډول حل ممکن نه وي، د خبرتیا غبرګون بشپړ اتومات ته اړتیا لري.

دا مهمه ده چې د څارنې پریکړې د اوږدې مودې اهدافو په پام کې نیولو سره ترسره شي. هر خبرتیا چې نن ورځ کیږي یو سړی د سبا سیسټم له ښه کولو څخه لیرې کوي، نو ډیری وختونه د یو تولیدي سیسټم شتون یا فعالیت کې د هغه وخت لپاره کموالی راځي چې دا په اوږد مهال کې د څارنې سیسټم ښه کولو لپاره اخلي. راځئ چې دوه مثالونه وګورو چې دا پدیده روښانه کوي.

Bigtable SRE: د ډیر خبرتیا په اړه یوه کیسه

د ګوګل داخلي زیربنا په عموم ډول د خدماتو کچې (SLO) له مخې چمتو شوي او اندازه کیږي. کلونه دمخه، د Bigtable خدمت SLO د یو چلونکي پیرودونکي سمولو لپاره د مصنوعي لیږد د اوسط فعالیت پر بنسټ والړ و. په Bigtable کې د ستونزو او د ذخیرې سټیک ټیټ کچې له امله، اوسط فعالیت د "لوی" دم لخوا پرمخ وړل شوی: د پوښتنو ترټولو خراب 5٪ اکثرا د پاتې نورو په پرتله د پام وړ سست وو.

د بریښنالیک خبرتیاوې لیږل شوي کله چې د SLO حد ته نږدې شوی و، او د میسنجر خبرتیاوې لیږل شوي کله چې د SLO څخه تیریږي. دواړه ډوله خبرتیاوې په مکرر ډول لیږل شوي ، د انجینرۍ وخت د نه منلو وړ مقدار مصرفوي: ټیم د پام وړ وخت د خبرتیاو تحلیل کولو لپاره مصرف کړی ترڅو یو څو ومومئ چې واقعیا اړوند وو. موږ ډیری وختونه یوه مسله له لاسه ورکړې چې واقعیا یې کاروونکي اغیزمن کړي ځکه چې یوازې یو څو خبرتیاوې د دې ځانګړي مسلې لپاره وې. ډیری خبرتیاوې د پوهیدو وړ زیربنایی مسلو له امله غیر عاجل وې او په معیاري ډول اداره شوي ، یا په بشپړ ډول ندي اداره شوي.

د وضعیت د حل لپاره، ټیم درې اړخیزه طریقه کارولې: پداسې حال کې چې د Bigtable فعالیت ښه کولو لپاره سخت کار کوي، موږ په موقتي توګه د پوښتنې ځواب ځنډ لپاره 75 فیصده زموږ د SLO هدف په توګه وټاکه. موږ د بریښنالیک خبرتیاوې هم بندې کړې، ځکه چې ډیری یې شتون درلود چې د دوی په تشخیص کې د وخت ضایع کول ناممکن وو.

دې ستراتیژۍ موږ ته ساه ورکړه چې په دوامداره توګه د تاکتیکي مسلو حل کولو پرځای په بګټبل او د ذخیره کولو ټیټ پوړونو کې د اوږدې مودې مسلو حل کول پیل کړو. انجینران په حقیقت کې هغه وخت کولی شي دنده ترسره کړي کله چې دوی هر وخت د خبرتیاو سره بمباري نه وي. په نهایت کې ، د خبرتیاو پروسس کولو لنډمهاله ځنډ موږ ته اجازه راکړه چې د خدماتو کیفیت ښه کړو.

Gmail: د وړاندوینې وړ، الګوریتمیک انساني ځوابونه

په لومړي سر کې، Gmail په یو تعدیل شوي کاري قطار پروسې کنټرول سیسټم کې جوړ شوی و چې د پروسې لټون شاخصونو بسته کولو لپاره رامینځته شوی و. کاري کتار د اوږدمهاله پروسو سره تطابق شوی او وروسته بیا په جی میل کې پلي شوی ، مګر د ناپاک مهالویش کوډ کې ځینې بګونه د حل کولو لپاره خورا سخت ثابت شوي.

په هغه وخت کې، د Gmail څارنه داسې جوړه شوې وه چې خبرتیاوې به هغه وخت ډزې وکړي کله چې د کاري قطار په کارولو سره انفرادي دندې لغوه شي. دا طریقه مناسبه نه وه، ځکه چې حتی په هغه وخت کې Gmail په زرګونو دندې ترسره کړې، چې هر یو یې زموږ د کاروونکو سلنې برخې ته ورکړل شوي. موږ ډیره پاملرنه وکړه ترڅو ډاډ ترلاسه کړو چې د Gmail کاروونکي ښه کاروونکي تجربه لري، مګر د ډیرو خبرتیاو اداره کول د پوښتنې څخه بهر وو.

د دې ستونزې د حل لپاره، Gmail SRE یوه وسیله جوړه کړه ترڅو د شیډولر ډیبګ کولو کې مرسته وکړي څومره چې ممکنه وي ترڅو په کاروونکو باندې اغیز کم کړي. ټیم د دې په اړه څو خبرې اترې درلودې چې ایا په ساده ډول د ستونزې موندلو څخه د حل کولو لپاره ټوله دوره اتومات کړي تر څو چې اوږدمهاله حل وموندل شي ، مګر ځینې اندیښمن و چې دا ډول حل به د ستونزې ریښتیني حل وځنډوي.

دا ډول تاو تریخوالی په ټیم کې عام و او ډیری وختونه د ځان انضباط بې باوري منعکس کوي: پداسې حال کې چې د ټیم ځینې غړي غواړي د سم حل لپاره وخت ورکړي، نور اندیښنه لري چې وروستی حل به هیر شي او لنډمهاله حل به د تل لپاره ونیسي. دا ستونزه د پاملرنې وړ ده، ځکه چې د دایمي حل کولو پرځای د لنډمهاله ستونزو حل کول خورا اسانه دي. مدیران او تخنیکي کارمندان د احتمالي اوږدمهاله اوږدمهاله فکسونو مالتړ او لومړیتوب ورکولو سره د اوږدمهاله اصلاحاتو پلي کولو کې کلیدي رول لوبوي حتی کله چې لومړني درد کم شي.

منظم تکراري خبرتیاوې او الګوریتمیک عکس العملونه باید سور بیرغ وي. د دې خبرتیاو اتومات کولو لپاره ستاسو د ټیم لیوالتیا پدې معنی ده چې ټیم باور نلري چې دوی کولی شي په الګوریتم باور وکړي. دا یوه جدي ستونزه ده چې باید حل شي.

اوږده موده

یو عام موضوع د Bigtable او Gmail مثالونو سره اړیکه لري: د لنډ مهاله او اوږد مهاله شتون ترمنځ سیالي. ډیری وختونه قوي هڅې کولی شي د یو نازک سیسټم سره د لوړ شتون په ترلاسه کولو کې مرسته وکړي، مګر دا لاره معمولا لنډمهاله وي، د ټیم سوځیدلو څخه ډک وي او د ورته اتل ټیم ​​په لږ شمیر غړو پورې تړاو لري.

په شتون کې یو کنټرول شوی، لنډمهاله کمښت اکثرا دردناک دی، مګر د سیسټم اوږدمهاله ثبات لپاره ستراتیژیک مهم دی. دا مهمه نه ده چې هر خبرتیا په انزوا کې په پام کې ونیسو، مګر دا په پام کې ونیسئ چې آیا د خبرتیا عمومي کچه د یو ګټور ټیم او د مناسب تشخیص سره د صحي، په سمه توګه د لاسرسي وړ سیسټم ته الرښوونه کوي. موږ د خبرتیا نرخ احصایې تحلیل کوو (معمولا د هر بدلون پیښو په توګه څرګندیږي ، چیرې چې پیښه د ډیری اړوندو پیښو څخه جوړه وي) د مدیریت سره په درې میاشتنۍ راپورونو کې ، پریکړه کونکو ته اجازه ورکوي چې په دوامداره توګه د خبرتیا سیسټم بار او د ټیم عمومي روغتیا وړاندې کړي.

پایلې

صحي څارنې او خبرتیاو ته لاره ساده او مستقیمه ده. دا د ستونزې په نښو تمرکز کوي د کوم لپاره چې خبرتیاوې رامینځته کیږي، او د علت څارنه د ستونزو د حل کولو لپاره د مرستې په توګه کار کوي. د نښې څارنه اسانه ده څومره چې تاسو په هغه سټیک کې یاست چې تاسو یې کنټرول کوئ، که څه هم د ډیټابیس بار او د فعالیت څارنه باید په مستقیم ډول پخپله ډیټابیس کې ترسره شي. د بریښنالیک خبرتیاوې خورا محدودې کارول کیږي او په اسانۍ سره شور ته وده ورکوي؛ پرځای یې، تاسو باید یو ډشبورډ وکاروئ چې ټولې اوسني مسلې څاري چې د بریښنالیک له لارې خبر شوي. ډشبورډ د تاریخي اړیکو تحلیل کولو لپاره د پیښې لاګ سره هم جوړه کیدی شي.

په اوږد مهال کې، د نښو خبرتیاو او نږدې اصلي ستونزو تر منځ یو بریالي بدلون ته اړتیا ده، او اهدافو ته اړتیا لري ترڅو ډاډ ترلاسه شي چې څارنه د چټک تشخیص ملاتړ کوي.

تر پایه د ژباړې لوستلو لپاره مننه. د څارنې په اړه زما د ټیلیګرام چینل کې ګډون وکړئ @monitorim_it и بلاګ په منځني ډول.

سرچینه: www.habr.com