کلاستر با طرح مشخص
توپولوژی، جداسازی محیطها، سیاستهای اجرا و سهمیهی منابع، همه مکتوب و قابل بازبینی.
$ service/kubernetes-sre
Kubernetes · SLI/SLO · Observability · Incident Response
سوال این نیست که آیا اتفاق میافتد، بلکه این است که آن شب چقدر طول میکشد تا سرویس برگردد. کار ما کوتاهکردن همان فاصله است: از طراحی کلاستر تا نوشتن رویهای که هر عضو تیم بتواند دنبالش کند.
$ رویکرد
بیشتر تیمها مانیتورینگ دارند. چیزی که ندارند، پاسخ به این سوال است: وقتی این عدد از این خط رد شد، گوشی چه کسی زنگ میخورد و اولین کاری که باید بکند چیست؟ بدون آن پاسخ، هر داشبوردی فقط یک تصویر قشنگ است.
برای همین کار را از ابزار شروع نمیکنیم. اول مشخص میکنیم کدام شاخصها واقعاً نشان میدهند سرویس سالم است، چه آستانهای ارزش بیدارکردن کسی را دارد، و بقیه هشدارها که فقط نویز تولید میکنند کنار گذاشته شوند.
همین منطق در طراحی کلاستر هم هست. مقدار CPU و حافظهی هر سرویس را از رفتار واقعی خودش درمیآوریم؛ عددی که از روی حدس گذاشته شود یا ظرفیت نودها را هدر میدهد یا سرویس را بیدلیل خفه میکند.
$ دامنه کار
توپولوژی، جداسازی محیطها، سیاستهای اجرا و سهمیهی منابع، همه مکتوب و قابل بازبینی.
چند عدد که واقعاً سلامت سرویس را نشان میدهند، بهجای دهها نمودار بیاستفاده.
برای هر دسته حادثه مشخص است چه کسی مسئول است و اولین سه کار چیست.
تعیین request و limit از روی مصرف واقعی، و برنامهریزی برای رشد.
نسخهی جدید تدریجی بالا میآید و اگر شاخصها افت کردند خودش عقب مینشیند.
مستندات و تمرین عملی، تا نگهداری بعد از تحویل گروگان دانش ما نباشد.
$ روند کار
میبینیم الان چه چیزی هست، چه چیزی میشکند و چه چیزی اصلاً دیده نمیشود.
ترتیب کارها و مرزهای دامنه را مکتوب میکنیم تا انتظار دو طرف یکی باشد.
زیرساخت و پایپلاین بهصورت کد در مخزن خودتان ساخته میشود.
چند هفته کنار سرویس میمانیم تا شاخصها و هشدارها به واقعیت نزدیک شوند.
مستندات، تمرین عملی و پاسخ به سوالها، تا تیم خودتان راه را ادامه دهد.
$ نمونه
# هیچ تغییری از روی لپتاپ کسی منتشر نمیشود
$
git push origin main
→ pipeline #4812 triggered
$
ci build && ci test
✓ 214 tests passed in 48s
$
argocd app sync api --prune
✓ rollout: 3/3 pods healthy
# شاخصها بلافاصله بعد از استقرار بررسی میشوند
$
kubectl top pods -l app=api
api-7d4f 142m 418Mi
$ ابزارها
ابزار را نیاز پروژه تعیین میکند، نه عادت ما. این فهرست نشاندهندهی هیچ همکاری رسمی یا گواهینامهای نیست.
$ سوالات
چون دامنهاش بین دو پروژه میتواند چند برابر فرق کند. یک کلاستر سالم که فقط مانیتورینگ کم دارد با زیرساختی که باید از نو چیده شود یکی نیست. بعد از جلسه ارزیابی، برآورد با زمانبندی میدهیم.
نه، و لزوماً هم لازمش ندارید. اگر سرویس شما با چند سرور ساده بهتر اداره میشود، همین را میگوییم. لایهی جدید وقتی اضافه میشود که مسئلهای را حل کند، نه چون در فهرست ابزارهای مرسوم است.
برنامه این است که نشود. کار را به مرحلههای کوچک میشکنیم و هر مرحله راه بازگشت دارد، تا اگر چیزی مطابق انتظار پیش نرفت بتوان عقب نشست.
بله، اما هدف این است که لازم نباشد. اگر نگهداری مستمر بخواهید در قالب جداگانه ممکن است؛ اگر نخواهید، باید بتوانید بدون ما ادامه دهید.
$ شروع کنیم
لازم نیست گزارش فنی آماده کنید. دو خط دربارهی چیزی که اذیتتان میکند کافی است تا بتوانیم جلسهی مفیدی داشته باشیم.