پرش به محتوا

$ service/kubernetes-sre

سرویس شما بالاخره یک شب از کار می‌افتد

Kubernetes · SLI/SLO · Observability · Incident Response

سوال این نیست که آیا اتفاق می‌افتد، بلکه این است که آن شب چقدر طول می‌کشد تا سرویس برگردد. کار ما کوتاه‌کردن همان فاصله است: از طراحی کلاستر تا نوشتن رویه‌ای که هر عضو تیم بتواند دنبالش کند.

  • طراحی کلاستر
  • شاخص‌های قابل‌اقدام
  • رویه‌ی حادثه

$ رویکرد

داشبوردی که کسی نگاهش نمی‌کند، مانیتورینگ نیست

بیشتر تیم‌ها مانیتورینگ دارند. چیزی که ندارند، پاسخ به این سوال است: وقتی این عدد از این خط رد شد، گوشی چه کسی زنگ می‌خورد و اولین کاری که باید بکند چیست؟ بدون آن پاسخ، هر داشبوردی فقط یک تصویر قشنگ است.

برای همین کار را از ابزار شروع نمی‌کنیم. اول مشخص می‌کنیم کدام شاخص‌ها واقعاً نشان می‌دهند سرویس سالم است، چه آستانه‌ای ارزش بیدارکردن کسی را دارد، و بقیه هشدارها که فقط نویز تولید می‌کنند کنار گذاشته شوند.

همین منطق در طراحی کلاستر هم هست. مقدار CPU و حافظه‌ی هر سرویس را از رفتار واقعی خودش درمی‌آوریم؛ عددی که از روی حدس گذاشته شود یا ظرفیت نودها را هدر می‌دهد یا سرویس را بی‌دلیل خفه می‌کند.

$ دامنه کار

چه چیزی تحویل می‌گیرید

01

کلاستر با طرح مشخص

توپولوژی، جداسازی محیط‌ها، سیاست‌های اجرا و سهمیه‌ی منابع، همه مکتوب و قابل بازبینی.

02

شاخص‌هایی که معنا دارند

چند عدد که واقعاً سلامت سرویس را نشان می‌دهند، به‌جای ده‌ها نمودار بی‌استفاده.

03

رویه‌ی رسیدگی

برای هر دسته حادثه مشخص است چه کسی مسئول است و اولین سه کار چیست.

04

ظرفیت بر پایه داده

تعیین request و limit از روی مصرف واقعی، و برنامه‌ریزی برای رشد.

05

انتشار قابل برگشت

نسخه‌ی جدید تدریجی بالا می‌آید و اگر شاخص‌ها افت کردند خودش عقب می‌نشیند.

06

واگذاری به تیم شما

مستندات و تمرین عملی، تا نگهداری بعد از تحویل گروگان دانش ما نباشد.

$ روند کار

مسیری که با هم طی می‌کنیم

  1. 01

    شناخت وضعیت

    می‌بینیم الان چه چیزی هست، چه چیزی می‌شکند و چه چیزی اصلاً دیده نمی‌شود.

  2. 02

    نقشه راه

    ترتیب کارها و مرزهای دامنه را مکتوب می‌کنیم تا انتظار دو طرف یکی باشد.

  3. 03

    ساخت

    زیرساخت و پایپ‌لاین به‌صورت کد در مخزن خودتان ساخته می‌شود.

  4. 04

    تثبیت

    چند هفته کنار سرویس می‌مانیم تا شاخص‌ها و هشدارها به واقعیت نزدیک شوند.

  5. 05

    واگذاری

    مستندات، تمرین عملی و پاسخ به سوال‌ها، تا تیم خودتان راه را ادامه دهد.

$ نمونه

مسیر یک تغییر، از مخزن تا محیط عملیاتی

deploy.log

                # هیچ تغییری از روی لپ‌تاپ کسی منتشر نمی‌شود

                
                
              
                
                
                    $ 
                    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

              

$ ابزارها

معمولاً با این‌ها کار می‌کنیم

  • Kubernetes
  • Prometheus
  • Grafana
  • GitLab CI
  • Argo CD
  • Terraform

ابزار را نیاز پروژه تعیین می‌کند، نه عادت ما. این فهرست نشان‌دهنده‌ی هیچ همکاری رسمی یا گواهی‌نامه‌ای نیست.

$ سوالات

سوال‌های پرتکرار

چرا برای این خدمت قیمت ثابت ندارید؟

چون دامنه‌اش بین دو پروژه می‌تواند چند برابر فرق کند. یک کلاستر سالم که فقط مانیتورینگ کم دارد با زیرساختی که باید از نو چیده شود یکی نیست. بعد از جلسه ارزیابی، برآورد با زمان‌بندی می‌دهیم.

ما هنوز Kubernetes نداریم. اشکالی دارد؟

نه، و لزوماً هم لازمش ندارید. اگر سرویس شما با چند سرور ساده بهتر اداره می‌شود، همین را می‌گوییم. لایه‌ی جدید وقتی اضافه می‌شود که مسئله‌ای را حل کند، نه چون در فهرست ابزارهای مرسوم است.

در حین مهاجرت سرویس قطع می‌شود؟

برنامه این است که نشود. کار را به مرحله‌های کوچک می‌شکنیم و هر مرحله راه بازگشت دارد، تا اگر چیزی مطابق انتظار پیش نرفت بتوان عقب نشست.

بعد از تحویل هم در دسترس هستید؟

بله، اما هدف این است که لازم نباشد. اگر نگهداری مستمر بخواهید در قالب جداگانه ممکن است؛ اگر نخواهید، باید بتوانید بدون ما ادامه دهید.

$ شروع کنیم

بگویید الان کجا می‌لنگد

لازم نیست گزارش فنی آماده کنید. دو خط درباره‌ی چیزی که اذیتتان می‌کند کافی است تا بتوانیم جلسه‌ی مفیدی داشته باشیم.