ویبینار خراب آډیو لري، نو موږ یو نقل جوړ کړ.
زما نوم میدویدیف اډوارډ دی. نن به زه د دې په اړه وغږیږم چې SRE څه شی دی، SRE څنګه ښکاره شو، د SRE انجنیرانو لپاره د کار معیارونه څه دي، د اعتبار معیارونو په اړه لږ څه، د هغې د څارنې په اړه لږ څه. موږ به سر ته ځو، ځکه چې تاسو په یو ساعت کې ډیر څه نه شئ ویلای، مګر زه به تاسو ته د اضافي بیاکتنې لپاره مواد درکړم، او موږ ټول ستاسو په تمه یو. . د جنوري په پای کې په مسکو کې.
لومړی، راځئ چې د SRE - د سایټ اعتبار انجنیري - څه شی په اړه وغږیږو. او دا څنګه د جلا موقف په توګه ښکاره شو، د جلا لار په توګه. دا ټول د دې حقیقت سره پیل شوي چې په دودیز پراختیایی حلقو کې، دیو او اوپس دوه بشپړ مختلف ټیمونه دي، معمولا د دوه بشپړ مختلف اهدافو سره. د پراختیایي ټیم هدف د سوداګرۍ اړتیاو پوره کولو لپاره نوي ځانګړتیاوې رامینځته کول دي. د Ops ټیم هدف دا دی چې ډاډ ترلاسه کړي چې هرڅه کار کوي او هیڅ شی نه ماتیږي. په ښکاره ډول، دا اهداف په مستقیم ډول یو له بل سره مخالفت کوي: له دې امله چې هرڅه کار کوي او هیڅ شی نه ماتیږي، نو دا به غوره وي چې د امکان تر حده لږ نوي ځانګړتیاوې ولګول شي. د دې له امله ، ډیری داخلي شخړې رامینځته کیږي ، کوم چې اوس د DevOps په نوم میتودولوژي د حل کولو هڅه کوي.
ستونزه دا ده چې موږ د DevOps روښانه تعریف او د DevOps روښانه پلي کول نلرو. ما 2 کاله دمخه په یکاترینبورګ کې په یوه کنفرانس کې خبرې وکړې ، او تر دې دمه د DevOps برخه د راپور سره پیل شوې "د DevOps څه دی." په 2017 کې، devops نږدې 10 کلن دی، مګر موږ لاهم د دې په اړه بحث کوو. او دا یو ډیر عجیب حالت دی چې ګوګل څو کاله دمخه د حل کولو هڅه وکړه.
په 2016 کې، ګوګل د "Site Reliability Engineering" په نوم یو کتاب خپور کړ. او په حقیقت کې، دا د دې کتاب سره و چې د SRE غورځنګ پیل شو. SRE په یو ځانګړي شرکت کې د DevOps پاراډیم پلي کولو لپاره یو ځانګړی اختیار دی. د SRE انجینرانو ځان د سیسټمونو د باور وړ عملیاتو ډاډ ترلاسه کولو هدف ټاکلی. دوی په عمده توګه د پراختیا کونکو څخه اخیستل کیږي، کله ناکله د مدیرانو څخه د قوي پراختیا پس منظر سره. او دوی هغه څه کوي چې د سیسټم مدیرانو یې کول، مګر د کوډ له نظره د سیسټم په پراختیا او پوهه کې قوي شالید د دې حقیقت لامل کیږي چې دا خلک عادي اداري کارونو ته لیواله ندي، مګر اتوماتیک ته لیواله دي.
دا معلومه شوه چې د SRE ټیمونو کې د DevOps تمثیل د دې حقیقت لخوا پلي کیږي چې د SRE انجنیران شتون لري چې ساختماني ستونزې حل کوي. دلته د دیو او اوپس ترمینځ ورته اړیکه ده چې خلک یې د 8 کلونو راهیسې خبرې کوي. د SRE رول د یو معمار په څیر دی چې نوي کسان SREs نه کیږي. خلک د خپل مسلک په پیل کې لاهم تجربه نلري او د اړتیا وړ پوهه نلري. ځکه چې SRE خورا پیچلي پوهې ته اړتیا لري چې دقیقا څه او کله غلط کیدی شي. له همدې امله، دلته یو ډول تجربې ته اړتیا ده، د یوې قاعدې په توګه، دواړه د شرکت دننه او بهر.
دوی پوښتنه کوي چې آیا د SRE او devops ترمنځ توپیر به تشریح شي. هغې یوازې تشریح شوې. موږ کولی شو په سازمان کې د SRE ځای په اړه خبرې وکړو. د کلاسیک DevOps تګلارې برعکس، چیرې چې Ops لاهم جلا څانګه ده، SRE د پراختیایی ټیم برخه ده. دوی د محصول په پراختیا کې ښکیل دي. حتی یوه تګلاره شتون لري چیرې چې SRE یو رول دی چې له یو پراختیا کونکي څخه بل ته تیریږي. دوی د کوډ بیاکتنې کې په ورته ډول برخه اخلي لکه د مثال په توګه، د UX ډیزاینران، پخپله پراختیا کونکي، او ځینې وختونه د محصول مدیران. SREs په ورته کچه کار کوي. موږ د دوی تصویب ته اړتیا لرو، موږ د دوی بیاکتنې ته اړتیا لرو، نو د هرې ګومارنې لپاره SRE وايي: "ښه، دا ګمارل، دا محصول به په اعتبار باندې منفي اغیزه ونکړي. او که داسې وشي، دا به د منلو وړ حدونو کې وي. موږ به په دې اړه هم خبرې وکړو.
په دې اساس، SRE د کوډ بدلونونو په اړه ویټو لري. او په عموم کې، دا د ځینو کوچنیو شخړو لامل کیږي که چیرې SRE په غلط ډول پلي شي. د سایټ د اعتبار انجنیري په اړه په همدغه کتاب کې، ډیری برخې، حتی له یو څخه ډیرې، د دې شخړو څخه د مخنیوي څرنګوالی په ګوته کوي.
خلک پوښتنه کوي چې SRE څنګه د معلوماتو امنیت سره تړاو لري. SRE په مستقیم ډول د معلوماتو امنیت کې ښکیل نه دی. ډیری وختونه په لویو شرکتونو کې، دا د انفرادي خلکو، ازموینو او شنونکو لخوا ترسره کیږي. مګر SRE د دوی سره په دې معنی هم اړیکه لري چې ځینې عملیات، ځینې ژمنې، ځینې ګمارنې چې امنیت اغیزه کوي د محصول په شتون هم اغیزه کولی شي. له همدې امله، SRE په عموم کې د هر ټیم سره اړیکه لري، په شمول د امنیتي ټیمونو په شمول، د شنونکو په شمول. له همدې امله، SREs په عمده ډول اړین دي کله چې د DevOps پلي کولو هڅه کوي، مګر په پراختیا کونکو باندې بار خورا لوی کیږي. دا دی، پخپله پراختیایی ټیم نور نشي کولی د دې حقیقت سره مقابله وکړي چې اوس دوی هم اړتیا لري چې د عملیاتو مسؤلیت ولري. او یو جلا رول ښکاري. دا رول په بودیجه کې پلان شوی دی. ځینې وختونه دا رول د ټیم په اندازې کې رامینځته کیږي، یو جلا کس ښکاري، ځینې وختونه د پراختیا کونکو څخه یو کیږي. دا څنګه په ټیم کې لومړی SRE ښکاري.
د سیسټم پیچلتیا چې د SRE لخوا اغیزمن کیږي، پیچلتیا چې عملیاتي اعتبار اغیزه کوي، ممکن اړین یا ناڅاپي وي. اړین پیچلتیا هغه وخت ده کله چې د محصول پیچلتیا تر هغه حد پورې لوړه شي چې د نوي محصول ځانګړتیاوې ورته اړتیا لري. تصادفي پیچلتیا هغه وخت ده کله چې د سیسټم پیچلتیا ډیریږي ، مګر د محصول ځانګړتیا او د سوداګرۍ اړتیاوې په مستقیم ډول پدې اغیزه نه کوي. دا معلومه شوه چې یا پراختیا کونکي په کوم ځای کې غلطي کړې، یا الګوریتم غوره نه دی، یا ځینې اضافي ګټې معرفي شوي چې په غیر ضروري توګه د محصول پیچلتیا زیاتوي. یو ښه SRE باید تل د دې وضعیت څخه مخنیوی وکړي. دا دی، هر ډول ژمنې، هر ډول ګمارنه، هر ډول پلټ غوښتنه چې د تصادفي اضافې له امله پیچلتیا زیاتوي باید بند شي.
پوښتنه دا ده چې ولې یوازې یو انجینر نه استخدام کړئ ، د سیسټم مدیر چې خورا پوهه ولري ، د ټیم سره یوځای شي. د انجنیر په رول کې یو پراختیا کونکی، موږ ته ویل کیږي، د پرسونل ترټولو غوره حل نه دی. د انجینر په رول کې پراختیا کونکی تل د پرسونل غوره حل نه وي ، مګر دلته ټکی دا دی چې یو پراختیا کونکی چې په Ops کې بوخت دی د اتومات کولو لپاره لږ څه لیوالتیا لري ، د دې پلي کولو لپاره لږ څه پوهه او مهارت لري. اتومات او په دې اساس، موږ نه یوازې د ځینو ځانګړو عملیاتو لپاره وخت کموو، نه یوازې معمول، بلکې د MTTR په څیر مهم سوداګریز پیرامیټونه (د بیا رغونې لپاره وخت، د بیا رغونې وخت). پدې توګه ، او موږ به لږ وروسته پدې اړه هم وغږیږو ، موږ د سازمان لپاره پیسې خوندي کوو.
اوس راځئ چې د SRE کار لپاره د معیارونو په اړه وغږیږو. او لومړی د اعتبار په اړه. په کوچنیو شرکتونو او پیلونو کې، ډیری وختونه داسې پیښیږي چې خلک ګومان کوي چې که خدمت ښه لیکل شوی وي، که محصول ښه او سم لیکل شوی وي، دا به کار وکړي، دا به مات نشي. دا دی، موږ ښه کوډ لیکو، نو د ماتولو لپاره هیڅ شی نشته. کوډ خورا ساده دی، د ماتولو لپاره هیڅ شی نشته. دا د ورته خلکو په اړه دي چې وايي موږ ازموینې ته اړتیا نلرو، ځکه چې وګورئ، دا د VPI درې طریقې دي، ولې ځورول کیږي؟
دا ټول غلط دي، البته. او دا خلک ډیری وختونه په عمل کې د دې ډول کوډ لخوا زیانمن کیږي، ځکه چې شیان ماتیږي. شیان کله ناکله په خورا غیر متوقع لارو ماتیږي. ځینې وختونه خلک وايي چې نه، دا به هیڅکله نه وي. او دا لاهم پیښیږي. ډیر ځله پیښیږي. او له همدې امله هیڅوک هیڅکله د 100٪ شتون لپاره هڅه نه کوي، ځکه چې 100٪ شتون هیڅکله نه پیښیږي. دا نورم دی. او له همدې امله موږ تل د نونس په اړه خبرې کوو کله چې موږ د خدماتو شتون په اړه خبرې کوو. 2 نهه، 3 نهه، 4 نهه، 5 نهه. که موږ دا د ځنډ وخت کې وژباړئ، نو د مثال په توګه، 5 نانونه په کال کې د 5 دقیقو څخه لږ څه ډیر دي، 2 نون د 3,5 ورځو د ځنډ وخت دی.
مګر دا څرګنده ده چې په ځینو وختونو کې د POI کمښت او د پانګې اچونې بیرته راګرځیدل دي. له دوو نهو څخه تر دریو نهو پورې تلل پدې معنی دي چې د ځنډ وخت له 3 ورځو څخه ډیر کم کړئ. له څلورو نهو څخه پنځه ته تلل په کال کې د 47 دقیقو لخوا د ځنډ وخت کموي. او دا معلومه شوه چې دا ممکن د سوداګرۍ لپاره مهم نه وي. او په عموم کې، اړین اعتبار تخنیکي مسله نه ده، لومړی، دا د سوداګرۍ مسله ده، دا د محصول مسله ده. د محصول د کاروونکو لپاره د کم وخت کومه کچه د منلو وړ ده، دوی څه تمه لري، دوی څومره پیسې ورکوي، د بیلګې په توګه، دوی څومره پیسې له لاسه ورکوي، سیسټم څومره پیسې له لاسه ورکوي.
مهمه پوښتنه دا ده چې د پاتې برخو اعتبار څه دی. ځکه چې د 4 او 5 نائنز ترمینځ توپیر به په سمارټ فون کې د 2 اعتبار لرونکي نائنز سره نه لیدل کیږي. په لنډه توګه ، که چیرې ستاسو په خدمت کې په سمارټ فون کې یو څه په کال کې 10 ځله مات شي ، نو احتمالا د OS اړخ کې 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 نه ښکاره کړي. تېروتنه، یوټیوب به ووایي: "موږ هرڅه جوړ کړل، ستاسو ویډیو پروسس کیږي. دا به په لسو دقیقو کې چمتو شي. دا د زړه راښکونکي تخریب اصل دی، کوم چې پیژندل کیږي، د بیلګې په توګه، د مخکینۍ پراختیا څخه که تاسو دا کار کړی وي.
راتلونکي شرایط چې موږ به یې په اړه خبرې وکړو، کوم چې د اعتبار سره کار کولو لپاره خورا مهم دي، د غلطیو سره، د توقعاتو سره، MTBF او MTTR دي. MTBF د ناکامۍ تر مینځ اوسط وخت دی. MTTR د رغیدو لپاره معنی لري ، د رغیدو اوسط وخت. دا، د تېروتنې د موندلو له شیبې څخه څومره وخت تېر شو، له هغه شیبې څخه چې تېروتنه ښکاره شوه تر هغه وخته پورې چې خدمت په بشپړ ډول نورمال عملیات ته راستون شو. MTBF په عمده ډول د کوډ کیفیت باندې کار کولو سره سم شوی. دا حقیقت دی چې SREs کولی شي "نه" ووایی. او ټول ټیم باید پوه شي چې کله SRE وايي "نه"، هغه دا نه وايي چې هغه زیانمن دی، نه دا چې هغه بد دی، مګر دا چې که نه نو هرڅوک به رنځ وي.
یوځل بیا ، ډیری مقالې شتون لري ، ډیری میتودونه ، ډیری لارې ، حتی په هغه کتاب کې چې زه یې ډیری وختونه ورته اشاره کوم ، څنګه ډاډ ترلاسه کړم چې نور پراختیا کونکي د SRE څخه نفرت نه کوي. MTTR، له بلې خوا، ستاسو د SLO (د خدماتو د کچې هدف) باندې کار کولو په اړه دی. او دا اکثرا اتومات دی. ځکه چې ، د مثال په توګه ، زموږ SLO په هره ربع کې د 4 نونونو وخت دی. دا پدې مانا ده چې په 3 میاشتو کې موږ کولی شو د 13 دقیقو وخت ته اجازه ورکړو. او دا معلومه شوه چې زموږ MTTR ممکن د 13 دقیقو څخه ډیر نشي. که موږ 13 دقیقې وخت ونیسو ترڅو لږترلږه 1 کم وخت ته عکس العمل وښیو ، پدې معنی چې موږ دمخه د ربع لپاره ټوله بودیجه ختمه کړې. موږ د SLO څخه سرغړونه کوو. د ناکامۍ عکس العمل او سمولو لپاره 13 دقیقې د ماشین لپاره خورا ډیر دي ، مګر د یو شخص لپاره خورا لږ دي. ځکه کله چې یو څوک خبرتیا ترلاسه کوي، په هغه وخت کې چې هغه غبرګون وښيي، کله چې هغه تېروتنه معلومه کړي، دا لا دمخه څو دقیقې دي. تر هغه چې یو څوک پوه شي چې دا څنګه حل کړي، څه شی باید سم کړي، څه وکړي، دا به یو څو دقیقې وخت ونیسي. او په حقیقت کې، حتی که تاسو یوازې د سرور ریبوټ کولو ته اړتیا لرئ، لکه څنګه چې دا وګرځي، یا یو نوی نوډ پورته کړي، بیا MTTR په لاسي ډول شاوخوا 7-8 دقیقې وخت نیسي. کله چې د پروسې اتومات کول، MTTR ډیری وختونه یوې ثانیې ته رسیږي، ځینې وختونه ملیسیکنډونه. ګوګل معمولا د ملی ثانیو په اړه خبرې کوي، مګر په واقعیت کې، البته، هرڅه دومره ښه ندي.
په عین حال کې، یو SRE باید تقریبا په بشپړه توګه خپل کار اتومات کړي، ځکه چې دا په مستقیم ډول د MTTR، د هغې میټریک، د ټول خدمت SLO، او په وینا، د سوداګرۍ ګټې اغیزه کوي. که چیرې وخت تیر شي، موږ وپوښتل شو چې ایا ملامت د SRE سره دی. خوشبختانه، پړه په چا نه ده اچول شوې. او دا یو جلا کلتور دی، چې د بې شرمه پوسټ مارټم په نامه یادېږي، چې نن به یې په اړه خبرې نه کوو، مګر موږ به په سلرم کې تحلیل کړو. دا ډېره په زړه پورې موضوع ده چې په اړه یې ډېرې خبرې کېدای شي. په لنډه توګه، که په هر ربع کې ټاکل شوی وخت ډیر شي، نو هرڅوک یو څه ملامت دي، پدې معنی چې د هرچا ملامتول ګټور نه دي، راځئ چې پرځای یې، شاید، څوک ملامت نه کړو، مګر وضعیت سم کړو او د هغه څه سره کار وکړو چې موږ یې لرو. زما په تجربه کې، دا طریقه د ډیری ټیمونو لپاره یو څه بهرنۍ ده، په ځانګړې توګه په روسیه کې، مګر دا معنی لري او ډیر ښه کار کوي. له همدې امله ، په پای کې به زه د مقالې او ادب وړاندیز وکړم چې تاسو پدې موضوع لوستلی شئ. یا Slurm SRE ته راشئ.
اجازه راکړئ تشریح کړم. که د ربع لپاره د SLO وخت تیر شي، که د ځنډ وخت 13 دقیقې نه وي، مګر 15، څوک د دې لپاره ملامت کیدی شي؟ البته، SRE ممکن په غلطۍ کې وي ځکه چې دا په واضح ډول یو څه ناوړه ژمنې یا ګمارل شوي. د معلوماتو مرکز مدیر ممکن د دې لپاره ملامت وي ، ځکه چې هغه ممکن یو څه غیر منظم ساتل شوي وي. که چیرې د معلوماتو مرکز مدیر د دې لپاره ملامت وي ، نو د Ops څخه شخص هم د SLO سره موافق کیدو پرمهال د ساتنې محاسبه نه کولو لپاره ملامت دی. دا د مدیر، تخنیکي رییس، یا هغه چا ګناه ده چې د معلوماتو مرکز قرارداد لاسلیک کړی او دې حقیقت ته یې پام نه دی کړی چې د معلوماتو مرکز SLA د اړتیا وړ وخت لپاره ډیزاین شوی نه دی. په دې اساس، هرڅوک د دې وضعیت لپاره لږ څه ملامت دي. او دا پدې مانا ده چې د دې وضعیت لپاره په ځانګړي توګه په چا باندې د ملامتولو هیڅ معنی نلري. مګر البته دا باید اصلاح شي. له همدې امله پوسټ مارټم شتون لري. او که تاسو ولولئ ، د مثال په توګه ، د ګیټ هب پوسټ مارټمونه ، او دا تل په هره ځانګړې قضیه کې خورا په زړه پوري ، کوچنۍ او غیر متوقع کیسه ده ، تاسو کولی شئ ځای په ځای کړئ چې هیڅوک هیڅکله نه وايي چې دا ځانګړی کس ملامت و. ملامت تل په ځانګړو نیمګړتیاوو باندې اچول کیږي.
راځئ چې بلې پوښتنې ته لاړ شو. اتوماتیک. زه معمولا ، کله چې زه په نورو شرایطو کې د اتومات کولو په اړه وغږیږم ، ډیری وختونه یو میز ته مراجعه کوم چې پدې اړه خبرې کوي چې تاسو د یوې دندې په اتومات کولو کې څومره وخت کار کولی شئ ترڅو د دې اتومات کولو لپاره ډیر وخت ونه نیسي ترڅو تاسو عموما خوندي کړئ. یو کیچ شته. لاسته راوړنه دا ده چې کله SREs یو کار اتومات کوي ، دوی نه یوازې وخت خوندي کوي ، دوی پیسې خوندي کوي ځکه چې اتومات مستقیم په MTTR اغیزه کوي. دوی خوندي کوي، نو د خبرو کولو لپاره، د کارمندانو او پراختیا کونکو مورال، کوم چې د نه منلو وړ سرچینه هم ده. دوی معمول کموي. او دا ټول په کار مثبت اغیزه لري او په پایله کې، په سوداګرۍ کې، حتی که داسې ښکاري چې اتوماتیک د وخت لګښتونو سره سم معنی نلري.
په حقیقت کې، دا تقریبا تل کوي، او ډیر لږ قضیې شتون لري چیرې چې دا د SRE رول کې د یو څه اتومات کولو ارزښت نلري. بیا به موږ د هغه څه په اړه وغږیږو چې د غلطی بودیجه ویل کیږي، د غلطیو لپاره بودیجه. په حقیقت کې، دا معلومه شوه چې که تاسو د SLO څخه د پام وړ ښه کار کوئ چې تاسو د ځان لپاره ټاکلی، دا هم خورا ښه نه دی. دا خورا بد دی، ځکه چې SLO نه یوازې د ټیټ حد په توګه کار کوي، بلکې د نږدې لوړ حد په توګه هم کار کوي. کله چې تاسو خپل ځان ته د 99٪ شتون SLO وټاکئ، او په حقیقت کې تاسو 99,99٪ لرئ، دا معلومه شوه چې تاسو د تجربې لپاره یو څه ځای لرئ، کوم چې سوداګرۍ ته هیڅ زیان نه رسوي، ځکه چې تاسو پخپله دا ټول په ګډه ټاکلي دي، او تاسو دا ځای ولرئ دا مه کاروئ. تاسو د غلطیو لپاره بودیجه لرئ چې ستاسو په قضیه کې نه لګول کیږي.
موږ ورسره څه کوو؟ موږ دا د لفظي هرڅه لپاره کاروو. د تولید شرایطو کې ازموینې لپاره ، د نوي ب featuresو رامینځته کولو لپاره چې ممکن فعالیت اغیزه وکړي ، د خوشې کولو لپاره ، ساتنې لپاره ، د پلان شوي ځنډ وخت لپاره. برعکس قاعده هم پلي کیږي: که بودیجه پای ته ورسیږي، موږ نشو کولی نوی څه خپور کړو، ځکه چې که نه نو موږ به د SLO څخه ډیر شو. بودیجه لا دمخه ختمه شوې ده، موږ یو څه خپاره کړل، که دا په فعالیت منفي اغیزه وکړي، دا دا دی، که دا یو ډول حل نه وي چې پخپله مستقیم SLO زیاتوي، نو موږ د بودیجې څخه تیریږي، او دا یو بد حالت دی. دا تحلیل، پوسټ مارټم، او ممکن د پروسې ځینې سمون ته اړتیا لري.
دا، دا معلومه شوه چې که خدمت پخپله ښه کار نه کوي، او SLO لګول کیږي او بودیجه په تجربو باندې نه لګول کیږي، نه په هیڅ ریلیز کې، مګر پخپله، نو بیا د ځینې په زړه پورې اصلاحاتو پرځای، په زړه پورې. ځانګړتیاوې، د زړه پورې ریلیزونو پرځای. د کوم تخلیقي کار کولو پرځای، تاسو باید د بودیجې بیرته ترلاسه کولو لپاره ګونګ اصلاحات ترسره کړئ، یا SLO ترمیم کړئ، او دا هم یوه پروسه ده چې باید ډیری وختونه پیښ نشي.
له همدې امله، دا معلومه شوه چې په داسې حالت کې چې موږ د غلطیو لپاره ډیره بودیجه لرو، هرڅوک لیوالتیا لري: دواړه SRE او پراختیا کونکي. د پراختیا کونکو لپاره ، د غلطیو لپاره لوی بودیجه پدې معنی ده چې دوی کولی شي د ریلیزونو ، ازموینو او تجربو سره معامله وکړي. د SREs لپاره، د غلطیو لپاره بودیجه او پدې بودیجه کې ننوتل پدې معنی دي چې دوی واقعیا ښه کار کوي. او دا د یو ډول ګډ کار هڅونې اغیزه کوي. که تاسو خپل SREs د پراختیا کونکو په توګه واورئ، نو تاسو به د ښه کار کولو لپاره ډیر ځای ولرئ او ډیر لږ کارونه.
دا معلومه شوه چې په تولید کې تجربې په لویو ټیمونو کې د SRE خورا مهم او نږدې لازمي برخه ده. او دا معمولا د ګډوډ انجینرۍ په نوم تیریږي ، کوم چې په Netflix کې د ټیم څخه راځي چې د Chaos Monkey په نوم یو افادیت خپور کړی.
Chaos بندر د CI/CD پایپ لاین سره وصل دی او په تصادفي ډول سرور په تولید کې ټکر کوي. بیا بیا، د SRE جوړښت کې موږ وایو چې یو خراب شوی سرور پخپله بد ندی، دا تمه کیږي. او که په بودیجه کې شامل شي، د منلو وړ دی او سوداګرۍ ته زیان نه رسوي. البته ، Netflix کافي بې ځایه سرورونه لري ، کافي نقل ، چې دا ټول د کارونکي حتی په بشپړ ډول د پام کولو پرته تنظیم کیدی شي ، او یقینا هیڅ څوک د کومې بودیجې لپاره یو سرور نه پریږدي.
Netflix په یو وخت کې د ورته اسانتیاو بشپړ سیټ درلود، چې یو یې، Chaos Gorilla، په بشپړ ډول په ایمیزون کې د شتون زونونو څخه یو غیر فعالوي. او دا ډول شیان ښه مرسته کوي چې لومړی، پټ انحصارونه په ګوته کړي، کله چې دا په بشپړه توګه روښانه نه وي چې څه اغیزه کوي، په څه پورې اړه لري. او دا، که تاسو د مایکرو سرویس سره کار کوئ او اسناد په بشپړ ډول بشپړ نه وي، دا ممکن تاسو ته پیژندل شوي وي. او بیا، دا په کوډ کې د غلطیو په نیولو کې مرسته کوي چې تاسو د سټینګ کولو پرمهال نشئ نیولی، ځکه چې کوم سټینګ دقیق سمول نه دی، د دې حقیقت له امله چې د بار اندازه توپیر لري، د بار اندازه توپیر لري، تجهیزات هم دي، ډیری احتمال، نور. لوړ بارونه هم غیر متوقع او غیر متوقع کیدی شي. او دا ډول ازموینې، چې بیا د بودیجې څخه بهر نه ځي، په زیربنا کې د غلطیو په نیولو کې خورا ښه مرسته کوي چې سټینګ، آټوټیسټونه، او CI/CD پایپ لاینونه به هیڅکله ونه نیسي. او تر هغه چې دا ټول ستاسو په بودیجه کې شامل وي، دا مهمه نده چې ستاسو خدمت هلته راټیټ شوی، که څه هم دا به ډیر ویرونکی ښکاري، سرور خراب شوی، څه یو خوب دی. نه، دا عادي خبره ده، دا ښه ده، دا د غلطیو په نیولو کې مرسته کوي. که تاسو بودیجه لرئ، تاسو کولی شئ دا مصرف کړئ.
پوښتنه: زه کوم ادب وړاندیز کولی شم؟ لیست په پای کې دی. ډیر ادب دی، زه به د څو راپورونو وړاندیز وکړم. دا څنګه کار کوي او ایا SRE په شرکتونو کې د خپل سافټویر محصول پرته یا لږترلږه پراختیا سره کار کوي. د مثال په توګه، په یوه شرکت کې، چیرې چې اصلي فعالیت سافټویر نه وي. په یوه تصدۍ کې، چیرې چې اصلي فعالیت سافټویر نه وي، SRE بالکل د بل هر ځای په څیر کار کوي، ځکه چې تاسو په یوه تصدۍ کې هم کار کولو ته اړتیا لرئ، حتی که تاسو د سافټویر محصولاتو ته وده نه ورکوئ، تاسو اړتیا لرئ چې تازه معلومات وړاندې کړئ. زیربنا بدلولو ته اړتیا لرئ، تاسو اړتیا لرئ وده وکړئ، تاسو اندازه کولو ته اړتیا لرئ. او SREs په دې پروسو کې د احتمالي ستونزو پیژندلو او وړاندوینې کې مرسته کوي او د ځینې ودې پیل کیدو او سوداګرۍ اړتیاو بدلولو وروسته یې کنټرولوي. ځکه چې دا بالکل اړین ندي چې د SRE درلودلو لپاره د سافټویر پراختیا کې ښکیل شئ، که تاسو لږترلږه څو سرورونه لرئ او تاسو لږترلږه د ودې تمه لرئ.
ورته د کوچنیو پروژو، کوچنیو سازمانونو لپاره ځي، ځکه چې لوی شرکتونه د تجربې لپاره بودیجه او ځای لري. مګر په ورته وخت کې، د تجربو دا ټولې میوې هرچیرې کارول کیدی شي، دا دی، SREs، البته، په ګوګل، Netflix او Dropbox کې ښکاره شوي. مګر په ورته وخت کې، کوچني شرکتونه او پیل کول کولی شي مخکې له دې چې کم شوي مواد ولولي، کتابونه ولولي، او راپورونه وګوري. دوی د دې په اړه ډیر ځله اوریدل پیل کوي ، ځانګړي مثالونه وګورئ ، زه فکر کوم ، ښه ، دا واقعیا ګټور کیدی شي ، موږ دې ته هم اړتیا لرو ، ښه.
دا، د دې پروسو د معیاري کولو ټول اصلي کار لا دمخه ستاسو لپاره ترسره شوی. ټول هغه څه چې تاسو یې باید وکړئ په ځانګړې توګه ستاسو په شرکت کې د SRE رول تعریف کړئ او په حقیقت کې د دې ټولو کړنو پلي کول پیل کړئ، کوم چې بیا مخکې تشریح شوي. دا د وړو شرکتونو لپاره د ګټورو اصولو څخه دی، دا تل د SLA، SLI، SLO تعریف دی. که تاسو په سافټویر کې ښکیل نه یاست، نو دا به داخلي SLAs او داخلي SLOs وي، د غلطیو لپاره داخلي بودیجه. دا تقریبا تل د ټیم دننه او د سوداګرۍ دننه ځینې په زړه پورې بحثونو ته الر پیدا کوي، ځکه چې دا ممکن وګرځي چې تاسو په زیربناوو، د مثالی پروسو یو ډول تنظیم، یو مثالی پایپ لاین باندې د اړتیا څخه ډیر مصرف کوئ. او دا 4 نونسونه چې تاسو د آی ټي ډیپارټمنټ کې لرئ ، تاسو واقعیا اوس ورته اړتیا نلرئ. مګر په ورته وخت کې، دا ممکنه وه چې وخت ولګول شي، په بل څه کې د غلطیو لپاره بودیجه مصرف کړئ.
په دې اساس، د څارنې تنظیم او تنظیم د هرې اندازې شرکت لپاره ګټور دی. او په عموم کې، د فکر کولو دا طریقه، چیرې چې غلطۍ یو څه د منلو وړ وي، چیرې چې بودیجه شتون لري، چیرته چې موخې شتون لري، بیا د هرې اندازې شرکت لپاره ګټور دی، د 3-شخص پیل څخه پیل کیږي.
د تخنیکي اړخونو وروستی چې موږ یې په اړه خبرې کولی شو څارنه ده. ځکه چې که موږ د SLA، SLI، SLO په اړه وغږیږو، موږ نشو کولی پرته له دې چې څارنه وکړو پوه شو چې آیا موږ په بودیجه کې مناسب یو، ایا موږ د خپلو موخو سره مطابقت لرو، او موږ څنګه په وروستي SLA اغیزه کوو. ما ډیری وختونه لیدلي چې څارنه په لاندې ډول ترسره کیږي: یو څه ارزښت شتون لري، د بیلګې په توګه، سرور ته د غوښتنې وخت، اوسط وخت یا ډیټابیس ته د غوښتنو شمیر. هغه یو معیار لري چې د انجنیر لخوا ټاکل شوی. که میټریک د نورم څخه انحراف وکړي، یو بریښنالیک لیږل کیږي. دا ټول په بشپړ ډول بې ګټې دي، د یوې قاعدې په توګه، ځکه چې دا د خبرتیاو دومره زیاتوالي لامل کیږي، د څارنې پیغامونو د څارنې، کله چې یو شخص، لومړی، باید هر وخت دوی تشریح کړي، دا معلومه کړي چې ایا د میټریک ارزښت معنی لري. یو ډول عمل. او دوهم ، هغه په ساده ډول د دې ټولو خبرتیاو په پام کې نیولو مخه نیسي ، کله چې اساسا د هغه څخه هیڅ اقدام ته اړتیا نه وي. دا، د څارنې یو ښه قاعده او د SRE پلي کولو په وخت کې لومړی قاعده دا ده چې یو خبرتیا باید یوازې هغه وخت راشي کله چې یو عمل ته اړتیا وي.
په معیاري قضیه کې د پیښو 3 کچې شتون لري. دلته خبرتیاوې شتون لري، ټکټونه شتون لري، لاګونه شتون لري. خبرتیاوې هغه څه دي چې ستاسو څخه سمدستي اقدام ته اړتیا لري. یعني هر څه مات شوي دي، همدا اوس باید اصلاح شي. ټکټونه هغه څه دي چې انتظار ته اړتیا لري. هو ، تاسو اړتیا لرئ یو څه وکړئ ، تاسو اړتیا لرئ په لاسي ډول یو څه وکړئ ، اتومات ناکام شوی ، مګر تاسو اړتیا نلرئ دا په راتلونکو څو دقیقو کې ترسره کړئ. لوګز هغه څه دي چې عمل ته اړتیا نلري، او په عموم کې، که شیان ښه پرمخ ځي، هیڅوک به یې هیڅکله ونه لوستل شي. دا به اړین وي چې لاګونه یوازې هغه وخت ولوستل شي کله چې په شاتګ کې ، دا معلومه شوه چې یو څه د یو څه وخت لپاره مات شوی و ، موږ یې په اړه نه پوهیږو. یا یو ډول تحقیق ته اړتیا لري. مګر په عموم کې، هرڅه چې هیڅ عمل ته اړتیا نلري لاګ ته ځي.
د دې ټولو د اړخ اغیزې په توګه، که موږ معلومه کړو چې کومې پیښې عملونو ته اړتیا لري او په ښه توګه یې تشریح کړي چې دا عملونه باید څه وي، دا پدې مانا ده چې عمل کولی شي اتوماتیک وي. یعني څه پیښیږي. موږ د خبرتیا څخه راځي. راځئ چې عمل ته لاړ شو. راځئ چې د دې عمل توضیحاتو ته لاړ شو. او بیا موږ د اتومات په لور حرکت کوو. دا دی، هر اتومات د پیښې په وړاندې د غبرګون سره پیل کیږي.
له څارنې څخه موږ یوې اصطالح ته ځو چې د مشاهدې په نوم یادیږي. په تیرو څو کلونو کې د دې کلمې شاوخوا یو څه هایپ هم شتون لري. او لږ خلک پوهیږي چې دا د شرایطو څخه بهر څه معنی لري. مګر اصلي ټکی دا دی چې د نظارت وړتیا د سیسټم روڼتیا یوه اندازه ده. که یو څه غلط شوی وي، تاسو څومره ژر کولی شئ معلومه کړئ چې ریښتیا څه غلط شوي او په هغه وخت کې د سیسټم حالت څه و. د کوډ له نظره: کوم فعالیت ناکام شو، کوم خدمت ناکام شو. د مثال په توګه، داخلي متغیرات، ترتیب څه حالت وو. د زیربنا له نظره ، دا هغه څه دي چې د شتون په زون کې ناکامي رامینځته شوې ، او که تاسو یو ډول کوبرنیټس لرئ ، نو په کوم پوډ کې ناکامي رامینځته شوې ، د پوډ حالت څه و. او په دې اساس، مشاهده د MTTR سره مستقیم اړیکه لري. هرڅومره چې د خدماتو مشاهده لوړه وي ، هومره د خطا پیژندل اسانه وي ، د غلطۍ حل کول اسانه وي ، د غلطۍ اتومات کول اسانه وي ، د MTTR ټیټ.
که موږ بیا کوچني شرکتونو ته لاړ شو، دوی ډیری وختونه پوښتنه کوي، حتی اوس، د ټیم اندازې سره څه وکړي، او ایا دا اړینه ده چې په یو کوچني ټیم کې د جلا SRE ګمارل اړین وي. ما د دې په اړه لږ مخکې خبرې وکړې. د پیل کولو یا د بیلګې په توګه، د ټیم د پراختیا په لومړیو مرحلو کې، دا هیڅ اړتیا نلري، ځکه چې SRE یو انتقالي رول ترسره کیدی شي. او دا به ټیم یو څه ژوندی کړي، ځکه چې لږترلږه یو څه تنوع شتون لري. او برسیره پردې دا به خلک د دې حقیقت لپاره چمتو کړي چې څنګه دوی وده کوي، په عموم کې، د SRE مسؤلیتونه به خورا مهم بدلون ومومي. که تاسو یو څوک استخدام کړئ، نو البته، هغه یو څه تمه لري. او دا توقعات به د وخت په تیریدو سره نه بدلیږي، مګر اړتیاوې به ډیر بدلون ومومي. نو ځکه، د SRE استخدام په لومړیو مرحلو کې خورا ستونزمن دی. دا خورا اسانه ده چې خپل ځان لوړ کړئ. مګر دا د فکر کولو ارزښت لري.
یوازینی استثنا، شاید، هغه وخت وي کله چې خورا سخت او ښه تعریف شوي لوړوالی اړتیاوې وي. دا ، د پیل کولو په حالت کې ، دا ممکن د پانګوالو لخوا یو ډول فشار وي ، په یوځل کې څو ځله د ودې لپاره یو ډول وړاندوینه. بیا د SRE استخدام کول عموما توجیه کیږي ځکه چې دا توجیه کیدی شي. موږ د ودې اړتیاوې لرو، موږ یو داسې کس ته اړتیا لرو چې د دې ډاډ ترلاسه کولو لپاره مسؤل وي چې هیڅ شی د دې ودې سره مات نشي.
یوه بله پوښتنه. څه باید وکړو کله چې څو ځله پراختیا کونکي یو فیچر پرې کړي چې ازموینې تیریږي ، مګر محصول ماتوي ، ډیټابیس باروي ، نور ب featuresې ماتوي ، کوم پروسه پلي کول. په دې اساس، پدې حالت کې، د غلطیو لپاره بودیجه معرفي کیږي. او ځینې خدمتونه، ځینې ځانګړتیاوې په تولید کې سمدستي ازمول کیږي. دا یو کانري کیدی شي ، کله چې یوازې یو لږ شمیر کارونکي ، مګر دمخه په تولید کې ، یو ځانګړتیا ځای په ځای کوي ، مګر په دې تمه چې که یو څه مات شي ، د مثال په توګه ، د ټولو کاروونکو نیم سلنې لپاره ، دا به لاهم د کارونکي دننه فټ شي. د غلطیو لپاره بودیجه. په دې اساس، هو، یوه تېروتنه به وي، د ځینو کاروونکو لپاره به هرڅه مات شي، مګر موږ دمخه ویلي چې دا عادي خبره ده.
د SRE وسیلو په اړه یوه پوښتنه وه. دا دی، ایا داسې کوم ځانګړی شتون لري چې SREs به یې وکاروي چې هرڅوک به یې ونه کاروي؟ په حقیقت کې، ځینې خورا ځانګړي اسانتیاوې شتون لري، ځینې سافټویر شتون لري چې د بیلګې په توګه، بارونه سمبالوي یا د کانري A/B ازموینې ترسره کوي. مګر اساسا ، د SRE اوزار کول هغه څه دي چې ستاسو پراختیا کونکي دمخه کاروي. ځکه چې SRE مستقیم د پرمختیایي ټیم سره اړیکه لري. او که تاسو مختلف وسیلې لرئ ، نو دا معلومه شوه چې دا همغږي کولو لپاره وخت نیسي. په ځانګړې توګه که SREs په لویو ټیمونو کې کار کوي، په لویو شرکتونو کې چیرې چې ډیری ټیمونه شتون لري، د شرکت په کچه معیاري کول به دلته خورا ګټور وي، ځکه چې که 50 ټیمونه 50 مختلف اسانتیاوې کاروي، دا پدې مانا ده چې SRE باید دا ټول وپیژني. او البته دا به هیڅکله نه وي. او د کار کیفیت، لږترلږه د ځینو ټیمونو د کنټرول کیفیت به د پام وړ کم شي.
زموږ ویبینار ورو ورو پای ته رسیږي. ما اداره کوله چې تاسو ته ځینې اساسي شیان ووایم. البته، د SRE په اړه هیڅ شی نشي ویل کیدی او په یو ساعت کې پوه شي. مګر زه امید لرم چې ما د دې فکر کولو لاره ، اصلي کلیدي ټکي په ګوته کړي. او بیا، که تاسو لیوالتیا لرئ، تاسو کولی شئ موضوع ته ژوره ورسوئ، پخپله مطالعه وکړئ، او وګورئ چې دا څنګه په نورو شرکتونو کې د نورو خلکو لخوا پلي کیږي. او د دې مطابق، د فبروري په پیل کې، موږ ته په Slurm SRE کې راشئ.
Slurm SRE یو درې ورځنی ژور کورس دی چې نږدې هغه څه به پوښي چې زه یې اوس په اړه خبرې کوم، مګر د خورا ژورې ژورې سره، د حقیقي قضیو سره، د تمرین سره، ټول انګیزه د عملي کار موخه ده. خلک به په ټیمونو وویشل شي. تاسو ټول به په ریښتیني قضیو کار کوئ. په دې اساس، موږ د Booking.com ایوان کروګلوف او بین ټیلر څخه ښوونکي لرو. موږ د سان فرانسسکو څخه د ګوګل څخه په زړه پورې ایوګیني وراباس لرو. او زه به تاسو ته یو څه ووایم. نو ډاډه اوسئ چې موږ سره لیدنه وکړئ.
نو، د حوالې لیست. په SRE کې لینکونه شتون لري. په ورته کتاب کې، یا د SRE په اړه په 2 کتابونو کې، د ګوګل لخوا لیکل شوی. بل یو ، چیرې چې شرایط او د دوی غوښتنلیک په لږ تفصیل سره تشریح شوي. راتلونکی 3 په مختلفو شرکتونو کې د SRE په اړه راپورونه دي. لومړی - ، دا د ګوګل څخه د بین ټرینر کلیدي یادونه ده. دوهم - . دریم بیا په اړه دی . څخه څلورم راپور ، کوم چې په 5 هیوادونو کې یوازې 190 کلیدي SRE کارمندان لري. د دې ټولو لیدلو لپاره دا خورا په زړه پورې ده، ځکه چې لکه څنګه چې DevOps مختلف شرکتونو او حتی مختلف ټیمونو ته خورا مختلف شیان معنی لري، SRE خورا مختلف مسؤلیتونه لري، حتی د ورته اندازو شرکتونو کې.
د ګډوډۍ انجینري اصولو په اړه 2 نور لینکونه: , . او په پای کې د حیرانتیا لیستونو لړۍ څخه 3 لیستونه شتون لري په اړه او په اړه . په SRE کې لیست خورا خورا لوی دی، تاسو اړتیا نلرئ د دې ټولو له لارې لاړ شئ، شاوخوا 200 مقالې شتون لري. زه د ظرفیت پلان کولو او بې ګناه پوسټ مارټم په اړه مقالې خورا وړاندیز کوم.
په زړه پوری مقاله:
مننه چې دا ټول وخت یې ما ته غوږ شو. زه هیله لرم چې تاسو یو څه زده کړل. زه هیله لرم چې تاسو کافي مواد ولرئ ترڅو نور هم زده کړئ. او وروسته به ګورو. هیله ده په فبروري کې.
د ویبینار کوربه ایډوارډ میدویدیف و.
PS: د هغو کسانو لپاره چې لوستل یې خوښوي ، اډوارډ د حوالې لیست چمتو کړی. هغه څوک چې په عمل کې د دې پوهیدل غوره کوي ښه راغلاست .
سرچینه: www.habr.com