ایا څارنه مړه ده؟ - اوږد ژوند څارنه

د 2008 راهیسې، زموږ شرکت په ابتدايي توګه د زیربناوو مدیریت او د ویب پروژو لپاره د ساعت په اوږدو کې تخنیکي مالتړ کې بوخت دی: موږ له 400 څخه ډیر پیرودونکي لرو، چې د روسیې د ای کامرس شاوخوا 15٪ دي. په دې اساس، یو ډیر متنوع جوړښت ملاتړ کیږي. که یو څه راښکته شي، موږ مکلف یو چې دا په 15 دقیقو کې حل کړو. مګر د دې لپاره چې پوه شي چې یوه پیښه رامنځته شوې، تاسو اړتیا لرئ چې د پروژې څارنه وکړئ او پیښو ته ځواب ووایاست. دا څنګه وکړو؟

زه باور لرم چې د څارنې د سم سیستم په تنظیمولو کې ستونزه شته. که کومه ستونزه نه وه، نو زما وینا به په یوه مقاله مشتمل وي: "مهرباني وکړئ پرومیټیوس + ګرافانا او پلگ ان 1، 2، 3 نصب کړئ." له بده مرغه، دا نور کار نه کوي. او اصلي ستونزه دا ده چې هرڅوک په هغه څه باور لري چې په 2008 کې شتون درلود، د سافټویر اجزاو په اساس.

د څارنې د سیستم د تنظیم په اړه، زه غواړم ووایم چې ... داسې پروژې شتون نلري چې وړ نظارت ولري. او وضعیت دومره خراب دی چې که یو څه راښکته شي ، نو دا خطر شتون لري چې دا به له پامه ونه غورځول شي - په هرصورت ، هرڅوک ډاډه دي چې "هرڅه څارل کیږي."
شاید هرڅه څارل کیږي. خو څنګه؟

موږ ټول د لاندې کیسه سره مخ شوي یو: یو ځانګړی ډیوپس، یو ټاکلی مدیر کار کوي، د پراختیا ټیم دوی ته راځي او وايي - "موږ خوشې شوي، اوس څارنه کوو." څارنه څه شی؟ څنګه کار کوي؟

سمه ده. موږ د زاړه طریقې څارنه کوو. او دا لا دمخه بدلیږي، او دا معلومه شوه چې تاسو د A خدمت څارنه کړې، کوم چې خدمت B شو، کوم چې د خدماتو C سره اړیکه لري. مګر پراختیایی ټیم تاسو ته وایي: "سافټویر نصب کړئ، دا باید هرڅه وڅاري!"

نو څه بدلون راغلی؟ - هر څه بدل شوي!

۲۰۰۸ هر څه سم دي

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

که موږ د هغه کار اندازه پرتله کړو چې مدیر بیا د څارنې چمتو کولو لپاره ترسره کړي، نو 98٪ یې اتوماتیک و: هغه څوک چې څارنه کوي باید پوه شي چې څنګه زبیکس نصب کړي، څنګه یې تنظیم کړي او الرښوونه تنظیم کړي. او 2٪ - د بهرنیو چکونو لپاره: دا چې سایټ ځواب ورکوي او ډیټابیس ته غوښتنه کوي، چې نوي امرونه رارسیدلي دي.

۲۰۱۰ بار مخ په ډیریدو دی

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

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

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

یادونه: ما "د سکریپټونو سیټ" 3 ځله لیکلي. دا دی، د څارنې مسؤل شخص نور هغه څوک نه دی چې په ساده ډول زبیکس نصب کړي. دا یو سړی دی چې کوډ کول پیل کوي. خو تر اوسه د ټیم په ذهنونو کې هیڅ بدلون نه دی راغلی.

مګر نړۍ بدلیږي، ورځ تر بلې پیچلې کیږي. د مجازی کولو پرت او څو نوي سیسټمونه اضافه شوي. دوی د یو بل سره اړیکه پیل کوي. چا وویل "د مایکرو خدماتو په څیر بوی؟" مګر هر خدمت لاهم په انفرادي ډول د ویب پاڼې په څیر ښکاري. موږ کولی شو هغې ته ورشو او پوه شو چې دا اړین معلومات چمتو کوي او پخپله کار کوي. او که تاسو مدیر یاست په دوامداره توګه په یوه پروژه کې ښکیل یاست چې د 5-7-10 کلونو راهیسې وده کوي ، دا پوهه راټولیږي: یوه نوې کچه څرګندیږي - تاسو یې احساس کړی ، بله کچه څرګندیږي - تاسو دا احساس کړی ...

مګر په ندرت سره څوک د 10 کلونو لپاره د پروژې سره یوځای کیږي.

د څارنې بیا پیلول

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

تاسو په دې ټولو کې ژوند کوئ. د خوشې کیدو دمخه 2 اونۍ پاتې دي ، دوی تاسو ته وايي: "اوس راځئ دا ټول وڅیړو ..." دا دی. د کلستر زیربنا څارنه، د مایکرو سرویس جوړښت څارنه، د بهرنیو خدماتو سره د کار څارنه ...

او زما همکاران معمول سکیم له خپل سر څخه اخلي او وايي: "ښه، دلته هرڅه روښانه دي! داسې پروګرام نصب کړئ چې دا ټول وڅاري. هو، هو: Prometheus + Grafana + plugins.
او دوی زیاتوي: "تاسو دوه اونۍ لرئ، ډاډ ترلاسه کړئ چې هرڅه خوندي دي."

په ډیرو پروژو کې چې موږ ګورو، یو کس د څارنې لپاره تخصیص شوی. تصور وکړئ چې موږ غواړو یو کس وګمارو ترڅو د 2 اونیو لپاره نظارت وکړي، او موږ د هغه لپاره بیا پیل کوو. دا سړی باید کوم مهارتونه ولري، هغه څه چې موږ یې تر اوسه ویلي دي؟

• هغه باید د اوسپنې زیربنا د عملیاتو د څارنې او ځانګړتیاوو په اړه پوه شي.
• هغه باید د Kubernetes څارنې ځانګړتیاوې درک کړي (او هرڅوک غواړي "مکعب" ته لاړ شي، ځکه چې تاسو کولی شئ له هرڅه څخه خلاص کړئ، پټ کړئ، ځکه چې مدیر به د پاتې سره معامله وکړي) - پخپله، د هغې زیربنا، او پوهیدل چې څنګه د غوښتنلیکونو څارنه وکړي. دننه
• هغه باید پوه شي چې خدمتونه یو له بل سره په ځانګړو لارو اړیکه نیسي، او د خدماتو ځانګړتیاوو په اړه پوهیږي چې څنګه یو بل سره اړیکه لري. دا خورا ممکنه ده چې یوه پروژه وګورئ چیرې چې ځینې خدمتونه په همغږي ډول اړیکه لري، ځکه چې بله لاره نشته. د مثال په توګه، پس منظر د REST له لارې، د gRPC له لارې د کتلاګ خدمت ته ځي، د محصولاتو لیست ترلاسه کوي او بیرته یې بیرته راولي. تاسو دلته انتظار نشئ کولی. او د نورو خدماتو سره دا په غیر متناسب ډول کار کوي. امر د تحویلي خدمت ته لیږدئ ، یو لیک واستوئ ، او داسې نور.
  تاسو شاید دمخه له دې ټولو څخه تیر شوي یاست؟ او مدیر، چې د دې څارنې ته اړتیا لري، نور هم مغشوش شو.
• هغه باید وکوالی شي په سمه توګه پلان او پلان جوړ کړي - لکه څنګه چې کار ډیریږي.
• له همدې امله هغه باید د رامینځته شوي خدمت څخه یوه ستراتیژي رامینځته کړي ترڅو پوه شي چې څنګه په ځانګړي توګه دا څارنه وکړي. هغه د پروژې د جوړښت او د هغې د پراختیا په اړه پوهاوی ته اړتیا لري + په پراختیا کې کارول شوي ټیکنالوژیو پوهه.

راځئ چې یو بالکل عادي قضیه په یاد ولرو: ځینې خدمات په پی ایچ پی کې دي، ځینې خدمتونه په ګو کې دي، ځینې خدمتونه په JS کې دي. دوی یو له بل سره کار کوي. دا هغه ځای دی چې د "مایکرو خدمت" اصطلاح له هغه ځایه راځي: دلته ډیری انفرادي سیسټمونه شتون لري چې پراختیا کونکي نشي کولی په ټوله پروژه پوه شي. د ټیم یوه برخه په JS کې خدمتونه لیکي چې په خپله کار کوي او نه پوهیږي چې پاتې سیسټم څنګه کار کوي. بله برخه په Python کې خدمتونه لیکي او د نورو خدماتو په څرنګوالي کې مداخله نه کوي؛ دوی په خپله سیمه کې جلا دي. دریم یې په PHP یا بل څه کې د خدماتو لیکل دي.
دا ټول 20 کسان په 15 خدماتو ویشل شوي، او یوازې یو اډمین دی چې باید په دې ټولو پوه شي. درېدل! موږ یوازې سیسټم په 15 مایکرو خدماتو ویشو ځکه چې 20 خلک په ټول سیسټم نه پوهیږي.

مګر دا باید یو څه وڅیړل شي ...

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

زه څه ووایم ... هوسټن، موږ ستونزې لرو.

د عصري سافټویر پروژې څارنه پخپله د سافټویر پروژه ده

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

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

او که تاسو دا په مرحله کې مدیر او پراختیا کونکو ته هم ورکړئ کله چې د خوشې کیدو دمخه لږ وخت پاتې وي ، نو سړی به پدې بشپړ پروتوکول پوهیدو ته اړتیا ولري. هغوی. د دې پیمانه پروژه د پام وړ وخت نیسي، او دا باید د سیسټم پراختیا کې فکتور شي.
مګر ډیری وختونه، په ځانګړې توګه په پیل کې، موږ ګورو چې څنګه څارنه تر هغه وروسته ځنډول کیږي. "اوس به موږ د مفهوم ثبوت جوړ کړو، موږ به یې پیل کړو، پریږدو چې راټیټ شي - موږ قربانۍ ته چمتو یو. او بیا به موږ دا ټول وڅیړو. کله چې (یا که) پروژه د پیسو ګټلو لپاره پیل کوي، سوداګر غواړي نور ځانګړتیاوې اضافه کړي - ځکه چې دا کار پیل کړی، نو دا باید نور هم وغځول شي! او تاسو په هغه ځای کې یاست چیرې چې تاسو اړتیا لرئ لومړی د هرڅه دمخه څارنه وکړئ ، کوم چې 1٪ وخت نه نیسي ، مګر ډیر څه. او د لارې په توګه، پراختیا کونکي به د څارنې لپاره اړین وي، او دا اسانه ده چې دوی ته اجازه ورکړي چې په نویو بڼو کار وکړي. د پایلې په توګه، نوې بڼې لیکل شوي، هرڅه خرابیږي، او تاسو په نه ختمیدونکي بند کې یاست.

نو څنګه د یوې پروژې څخه د پیل څخه څارنه وکړئ، او څه وکړئ که تاسو داسې پروژه ترلاسه کړئ چې نظارت ته اړتیا لري، مګر تاسو نه پوهیږئ چې چیرته یې پیل کړئ؟

لومړی، تاسو اړتیا لرئ پلان کړئ.

شعري تحلیل: ډیری وختونه دوی د زیربنا نظارت سره پیل کوي. د مثال په توګه، موږ Kubernetes لرو. راځئ چې د Grafana سره Prometheus نصبولو سره پیل وکړو، د "مکعب" څارنې لپاره د پلگ ان نصبولو سره. نه یوازې پراختیا کونکي ، بلکه مدیران هم بدبختانه عمل لري: "موږ به دا پلگ ان نصب کړو ، مګر پلگ ان شاید پوهیږي چې دا څنګه وکړي." خلک خوښوي چې د مهمو کړنو پرځای د ساده او مستقیم سره پیل وکړي. او د زیربنا څارنه اسانه ده.

لومړی، پریکړه وکړئ چې څه او څنګه غواړئ څارنه وکړئ، او بیا یوه وسیله غوره کړئ، ځکه چې نور خلک نشي کولی ستاسو لپاره فکر وکړي. او دوی باید؟ نورو خلکو ځان ته فکر کاوه، د یو نړیوال سیسټم په اړه - یا هیڅکله فکر نه کاوه کله چې دا پلگ ان لیکل شوی و. او یوازې د دې لپاره چې دا پلگ ان 5 زره کارونکي لري پدې معنی ندي چې دا د هیڅ کار نه دی. شاید تاسو به په ساده ډول 5001 شئ ځکه چې هلته دمخه 5000 خلک شتون درلود.

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

1. زه باور لرم چې تاسو اړتیا لرئ د کارونکي د ننوتلو نقطې څخه دقیق نظارت پیل کړئ. که کاروونکي ونه ګوري چې غوښتنلیک کار کوي، دا دی، دا ناکامي ده. او د څارنې سیسټم باید لومړی په دې اړه خبرداری ورکړي.
2. او یوازې بیا موږ کولی شو د زیربنا څارنه وکړو. یا دا په موازي توګه ترسره کړئ. دا د زیربنا سره اسانه ده - دلته موږ کولی شو په پای کې یوازې زبیکس نصب کړو.
3. او اوس تاسو اړتیا لرئ د غوښتنلیک ریښو ته لاړشئ ترڅو پوه شئ چې چیرې شیان کار نه کوي.

زما اصلي نظر دا دی چې څارنه باید د پراختیا پروسې سره موازي وي. که تاسو د نظارت ټیم د نورو کارونو لپاره متوجه کړئ (د CI/CD رامینځته کول ، سینڈ باکسینګ ، د زیربنا بیا تنظیم کول) ، څارنه به په ځنډ پیل شي او تاسو به هیڅکله د پرمختګ سره مخ نه شئ (یا ژر یا وروسته تاسو باید دا ودروئ).

هر څه د کچې له مخې

دا څنګه زه د څارنې سیسټم تنظیم کوم.

1) د غوښتنلیک کچه:

• د څارنې غوښتنلیک سوداګرۍ منطق؛
• د خدماتو د روغتیا معیارونو څارنه؛
• د ادغام څارنه

2) د زیربنا کچه:

• د اورکسټریشن کچه څارنه؛
• د سیسټم سافټویر څارنه؛
• د اوسپنې د کچې څارنه.

3) بیا د غوښتنلیک کچه - مګر د انجینرۍ محصول په توګه:

• د غوښتنلیک لوګو راټولول او څارنه؛
• APM;
• تعقیب

4) خبرداری:

• د خبرتیا سیسټم تنظیم؛
• د وظیفوي سیسټم تنظیم؛
• د "پوهې اساس" تنظیم کول او د پیښې پروسس کولو لپاره کاري جریان.

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

د غوښتنلیک پرت - د سوداګرۍ منطق څارنه

دلته موږ د دې حقیقت چک کولو په اړه خبرې کوو چې غوښتنلیک د کارونکي لپاره کار کوي.

دا کچه باید د پراختیا په مرحله کې ترسره شي. د مثال په توګه، موږ یو مشروط Prometheus لرو: دا سرور ته ځي چې چکونه کوي، پای ټکی راوباسي، او پای ټکی د API ته ځي او چک کوي.

کله چې ډیری وختونه د کور پا pageې نظارت کولو غوښتنه کیږي ترڅو ډاډ ترلاسه کړي چې سایټ کار کوي ، برنامه کونکي یو لاسوند ورکوي چې هرکله چې دوی ورته اړتیا ولري راښکته شي ترڅو ډاډ ترلاسه کړي چې API کار کوي. او په دې وخت کې پروګرام کونکي لاهم اخلي او لیکي /api/test/helloworld
د ډاډ ترلاسه کولو یوازینۍ لار چې هرڅه کار کوي؟ - نه!

• د دې ډول چکونو رامینځته کول په اصل کې د پراختیا کونکو دنده ده. د واحد ازموینې باید د پروګرام کونکو لخوا لیکل شي چې کوډ لیکي. ځکه چې که تاسو دا مدیر ته لیکئ ، "یار ، دلته د ټولو 25 دندو لپاره د API پروتوکولونو لیست دی ، مهرباني وکړئ هرڅه وڅارئ!" - هیڅ شی به کار ونه کړي.
• که تاسو "هیلو نړۍ" چاپ کړئ، هیڅوک به هیڅکله نه پوهیږي چې API باید کار وکړي او کار وکړي. هر API بدلون باید په چکونو کې د بدلون لامل شي.
• که تاسو دمخه دا ډول ستونزه لرئ ، ځانګړتیاوې بند کړئ او پراختیا کونکي تخصیص کړئ څوک چې دا چیکونه لیکي ، یا زیانونه ومني ، دا ومنئ چې هیڅ شی نه چک شوی او ناکام به شي.

تخنیکي لارښوونې:

• ډاډ ترلاسه کړئ چې د چکونو تنظیم کولو لپاره یو بهرنی سرور تنظیم کړئ - تاسو باید ډاډه اوسئ چې ستاسو پروژه بهرنۍ نړۍ ته د لاسرسي وړ ده.
• په ټول API پروتوکول کې چیکونه تنظیم کړئ، نه یوازې د انفرادي پای ټکي.
• د ازموینې پایلو سره د پرومیتیس پای ټکی رامینځته کړئ.

د غوښتنلیک پرت - د روغتیا میټریک څارنه

اوس موږ د خدماتو د بهرني روغتیا میټریکونو په اړه خبرې کوو.

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

دا څنګه په تخنیکي ډول په سمه توګه پلي کول: هر خدمت د خپل اوسني فعالیت په اړه پای ټکی څرګندوي، او د ګرافانا (یا کوم بل غوښتنلیک) په ګرافونو کې موږ د ټولو خدماتو وضعیت ګورو.

• هر API بدلون باید په چکونو کې د بدلون لامل شي.
• سمدلاسه د روغتیا میټریکونو سره یو نوی خدمت رامینځته کړئ.
• یو مدیر کولی شي پراختیا کونکو ته راشي او پوښتنه وکړي "ما ته یو څو ځانګړتیاوې اضافه کړئ ترڅو زه په هرڅه پوهیږم او زما د څارنې سیسټم ته پدې اړه معلومات اضافه کړم." مګر پراختیا کونکي معمولا ځواب ورکوي ، "موږ به د خوشې کیدو دوه اونۍ دمخه هیڅ شی اضافه نه کړو."
  پریږدئ چې پرمختیایي مدیران پوه شي چې دا ډول زیانونه به وي، پریږدئ چې د پراختیا مدیران هم خبر شي. ځکه چې کله هرڅه راټیټیږي، یو څوک به بیا هم تلیفون وکړي او غوښتنه وکړي چې د "په دوامداره توګه راټیټ شوي خدمت" څارنه وکړي (c)
• په هرصورت، د ګرافانا لپاره پلگ ان لیکلو لپاره پراختیا کونکي تخصیص کړئ - دا به د مدیرانو لپاره ښه مرسته وي.

د غوښتنلیک پرت - د ادغام څارنه

د ادغام څارنه د سوداګرۍ - مهم سیسټمونو ترمنځ د اړیکو نظارت باندې تمرکز کوي.

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

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

هغه څه چې زه یې وړاندیز کوم:

• د همغږي ارتباط لپاره: پای ټکی د اړوندو خدماتو غوښتنه کوي. هغوی. موږ دا پای ټکی ونیسو، د خدمت دننه یو سکریپټ راوباسئ، کوم چې ټولو ټکو ته ځي او وايي "زه هلته راښکته کولی شم، او هلته راښکته کولی شم، زه کولی شم هلته کش کړم ..."
• د غیر متناسب اړیکو لپاره: راتلوونکي پیغامونه - پای ټکی د ازموینې پیغامونو لپاره بس چیک کوي او د پروسس حالت ښیې.
• د غیر متناسب اړیکو لپاره: بهر ته تلونکي پیغامونه - پای ټکی بس ته د ازموینې پیغامونه لیږي.

لکه څنګه چې معمولا پیښیږي: موږ یو خدمت لرو چې معلومات په بس کې اچوي. موږ دې خدمت ته راغلو او له تاسو څخه غوښتنه کوو چې موږ ته د دې ادغام روغتیا په اړه ووایو. او که چیرې خدمت ته اړتیا وي چې بل چیرې یو پیغام تولید کړي (WebApp) ، نو دا به دا ازموینې پیغام تولید کړي. او که موږ د OrderProcessing اړخ کې خدمت پرمخ وړو، دا لومړی هغه څه پوسټ کوي چې دا خپلواکه پوسټ کولی شي، او که چیرې یو څه تړلي شیان شتون ولري، نو دا د بس څخه د ازموینې پیغامونو سیټ لولي، پوهیږي چې دا پروسس کولی شي، راپور ورکړي او ، که اړتیا وي ، نور یې پوسټ کړئ ، او پدې اړه هغه وايي - هرڅه سم دي ، زه ژوندی یم.

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

د زیربنا کچه

د زیربنا څارنه هغه څه دي چې له اوږدې مودې راهیسې پخپله څارنه ګڼل کیږي.

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

د سوداګرۍ واحد په توګه د غوښتنلیک کچه

مهم ټکي:

• ELK. دا د صنعت معیار دی. که د کوم دلیل لپاره تاسو لاګونه راټول نه کړئ، سمدلاسه یې پیل کړئ.
• APM. بهرني APMs د یوې لارې په توګه د غوښتنلیک نظارت ګړندي بندولو لپاره (نیو ریلیک ، بلیک فایر ، ډیټاډګ). تاسو کولی شئ دا شی په لنډمهاله توګه نصب کړئ ترڅو لږترلږه یو څه پوه شئ چې ستاسو سره څه تیریږي.
• تعقیب په لسګونو مایکرو خدماتو کې، تاسو باید هرڅه تعقیب کړئ، ځکه چې غوښتنه نور په خپل ځان ژوند نه کوي. وروسته اضافه کول خورا ګران دي ، نو دا به غوره وي چې سمدلاسه په پراختیا کې د تعقیب مهالویش تنظیم کړئ - دا د پراختیا کونکو کار او ګټه ده. که مو تر اوسه نه وي پلي کړي، عملي یې کړئ! Jaeger/Zipkin وګورئ

خبرداری ورکول

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

د ټیکنالوژۍ کڅوړه

راځئ چې تصور وکړو چې زموږ سټیک په لاندې ډول دی:

• د معلوماتو راټولول - Prometheus + Grafana؛
• د ننوتلو تحلیل - ELK؛
• د APM یا تعقیب لپاره - Jaeger (Zipkin).

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

یو څو تخنیکي ټکي چې زه پدې وروستیو کې هرچیرې ګورم:

پرومیتیوس د کبرنیټس دننه فشار راوړل کیږي - څوک د دې سره راغلی؟! که ستاسو کلستر خراب شي، تاسو به څه کوئ؟ که تاسو دننه یو پیچلي کلستر ولرئ، نو باید د کلستر دننه یو ډول نظارت سیسټم وي، او ځینې بهر، چې د کلستر دننه ډاټا راټولوي.

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

موندنو

• د څارنې پراختیا د اسانتیاوو نصب کول ندي، مګر د سافټویر محصول پراختیا. د نن ورځې نظارت 98٪ کوډ کول دي. په خدماتو کې کوډ کول، د بهرني چکونو کوډ کول، د بهرنیو خدماتو چک کول، او دا ټول دي.
• په نظارت کې د خپلو پراختیا کونکو وخت مه ضایع کوئ: دا کولی شي د دوی 30٪ کار واخلي ، مګر دا ارزښت لري.
• دیوپس، اندیښنه مه کوئ چې تاسو نشئ کولی یو څه وڅیړئ، ځکه چې ځینې شیان د فکر کولو بشپړ ډول دی. تاسو پروګرامر نه یاست، او د څارنې کار په حقیقت کې د دوی دنده ده.
• که پروژه لا دمخه روانه وي او نه څارل کیږي (او تاسو مدیر یاست)، د نظارت لپاره سرچینې تخصیص کړئ.
• که محصول لا دمخه په تولید کې وي ، او تاسو یو ډیوپس یاست چې ویل شوي و چې "څارنې تنظیم کړئ" - هڅه وکړئ مدیریت ته تشریح کړئ چې ما دا ټول څه لیکلي.

دا د سینټ هایلوډ ++ کنفرانس کې د راپور پراخه نسخه ده.

که تاسو د دې او اړوندو موضوعاتو په اړه زما نظرونو او افکارو سره علاقه لرئ نو دلته یې کولی شئ چینل ولولئ 🙂

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