آمادگی را برای یک تغییر مشخص بسنجید
«DevOps می‌خواهیم» هنوز دامنه قابل تحویل نیست. یک انتشار نزدیک را انتخاب کنید و بنویسید چه کد، تنظیم، داده، وظیفه زمان‌بندی‌شده یا اتصال بیرونی تغییر می‌کند. جریان مهم کاربر و ساعت حساس عملیات را هم ثبت کنید. مثال فرضی: انتشار ماژول صورتحساب ممکن است بدون خطای صفحه اجرا شود، اما کار زمان‌بندی‌شده نسخه قدیم دیگر نتواند رکورد جدید را بخواند. مرز انتشار باید این مصرف‌کننده را هم پوشش دهد. فهرست مسئولان و تصمیم‌گیر توقف را پیش از تغییر کامل کنید.
- اقلام انتشار: نسخه کد، پیکربندی، تغییر داده، مالک تأیید و وابستگی‌ها.
- معیار خروج از بررسی: هر تغییر، یک روش تأیید و یک تصمیم درباره شکست داشته باشد.
- اگر یکی از وابستگی‌ها در اختیار تیم دیگری است، زمان هماهنگی و مسئول پاسخ را در برنامه بیاورید.
منبع فنی این بخش: Google SRE Workbook [۱]
نسخه و محیط مقصد باید قابل اثبات باشند
اصول مهندسی انتشار در Google SRE بر ساخت تکرارپذیر، آزمون و خودکارسازی تأکید می‌کنند. برای پذیرش عملی، یک نفر غیر از سازنده اصلی باید بتواند ورودی ساخت، خروجی و مقصد استقرار را ردیابی کند. پیشنهاد این راهنما آن است که بسته تأییدشده با شناسه روشن منتقل شود و تغییر تنظیمات نیز ثبت داشته باشد. محیط آزمایش باید داده و دسترسی متناسب خود را داشته باشد؛ صرف نام‌گذاری یک محیط به‌عنوان preview شاهد جداسازی نیست.
| پرسش | شاهد قابل بررسی | اگر شاهد نداریم |
|---|---|---|
| چه چیزی منتشر می‌شود؟ | شناسه commit، خروجی ساخت و نتیجه آزمون مرتبط | ابتدا امکان ردیابی نسخه را فراهم کنید |
| کجا منتشر می‌شود؟ | حساب، پروژه، پایگاه داده و نام متغیرهای محیطی بدون نمایش مقدار محرمانه | پیش از اجرای تغییر داده، مقصد را راستی‌آزمایی کنید |
| چه کسی اجازه انتشار دارد؟ | دسترسی محدود، تأیید تغییر و سابقه اقدام | مالک و مسیر کنترل دسترسی را تعیین کنید |
منبع فنی این بخش: Google SRE Workbook [۱]
RTO و RPO را با مالک کسب‌وکار توافق کنید
در چارچوب AWS، RTO بیشترین تأخیر قابل قبول تا بازگشت سرویس است و RPO به میزان زمانی داده قابل از دست رفتن نسبت به نقطه بازیابی اشاره دارد. این‌ها هدف‌اند؛ وجود فایل پشتیبان، دستیابی به آن‌ها را اثبات نمی‌کند. برای مثال فرضی، گزارش داخلی با دفتر ثبت سفارشِ در حال دریافت پول تحمل یکسانی ندارد. به‌جای عدد دلخواه یا وعده «قطعی صفر»، پیامد قطع جریان، توان بازسازی داده و وابستگی‌های سرویس را با مالک عملیات مرور و هدف قابل دفاع ثبت کنید.
- مبدأ و پایان اندازه‌گیری را تعریف کنید: از رخداد تا بازگشت کدام جریان قابل استفاده؟
- هدف سرویس باید با توان بازیابی احراز هویت، پایگاه داده و سرویس‌های وابسته سازگار باشد.
- اگر وضعیت فعلی به هدف نمی‌رسد، فاصله را با تصمیم سرمایه‌گذاری، تغییر دامنه یا پذیرش موقت ریسک مستند کنید.
منبع فنی این بخش: AWS Well-Architected [۲]
بازگشت کد را با بازیابی داده اشتباه نگیرید
برای تغییر پایگاه داده، جداگانه بررسی کنید نسخه قبلی برنامه با ساختار و داده جدید کار می‌کند یا نه. مثال فرضی: حذف ستونی که پردازشگر قدیمی می‌خواند، با انتشار مجدد برنامه قبلی رفع نمی‌شود. پیشنهاد عملی، تغییر مرحله‌ای است: قابلیت سازگار را اضافه کنید، داده را با کنترل منتقل کنید، مصرف‌کننده‌ها را جابه‌جا و حذف را به تغییر بعدی موکول کنید. این الگو هم باید در فناوری منتخب آزموده شود؛ برای برخی تغییرات، اصلاح رو به جلو انتخاب مناسب‌تری از بازگردانی است.
- پیش‌شرط: مقصد، حجم داده، زمان تقریبی عملیات، قفل‌های احتمالی و اختیار اجرا بررسی شوند.
- پشتیبان را در مقصد جداگانه بازیابی و سازگاری برنامه با داده بازیابی‌شده را آزمایش کنید؛ صرف موفقیت گرفتن پشتیبان کافی نیست.
- برای داده‌ای که پس از انتشار نوشته شده، روش تطبیق و جلوگیری از از دست رفتن ثبت‌های معتبر تعیین کنید.
منبع فنی این بخش: AWS Well-Architected [۳]
انتشار تدریجی فقط با معیار توقف ارزش دارد
Google SRE، canary را انتشار محدود و زمان‌دار همراه با ارزیابی برای تصمیم ادامه توصیف می‌کند. سهم کوچک ترافیک، به‌تنهایی آزمون نماینده نمی‌سازد؛ اگر مشتریان عمده فقط در ساعت خاص کار می‌کنند، باید رفتار آنان هم بررسی شود. پیش از شروع، گروه دریافت‌کننده، نسخه مرجع، مدت مشاهده متناسب با چرخه استفاده و مسئول توقف را مشخص کنید. عدد ثابت و عمومی برای درصد ترافیک یا زمان پایش وجود ندارد که جای شناخت همان سرویس را بگیرد.
- پیشنهاد معیار: خطا، تأخیر یا شکست جریان مهم نسبت به خط پایه و حد توافق‌شده بررسی شوند.
- اگر دو نسخه داده مشترک را به شکل ناسازگار تغییر می‌دهند، پیش از تقسیم ترافیک مسئله سازگاری را حل کنید.
- تصمیم ادامه یا توقف و شواهد آن را ثبت کنید تا «چند دقیقه صبر کردیم» جای ارزیابی را نگیرد.
منبع فنی این بخش: Google SRE Workbook [۱]
سلامت را از دید کاربر و عملیات ببینید
پایش بیرونی در راهنمای Google SRE، رفتار قابل مشاهده برای کاربر را می‌سنجد. بنابراین برای سامانه صورتحساب، پاسخ موفق صفحه اصلی تنها شاهد کافی نیست؛ مسیر ورود، ثبت سند و مشاهده نتیجه باید بررسی شود. برای فروشگاه نیز موفقیت پرداخت را از موفقیت ایجاد سفارش جدا گزارش کنید. پیشنهاد عملی، داشبوردی محدود به چند جریان مهم همراه با علامت نسخه و راهنمای اقدام است. هر هشدار باید گیرنده، شدت و اقدام روشن داشته باشد تا مسئول پاسخ بتواند تصمیم بگیرد.
- نشانه کسب‌وکاری را با داده فنی همراه کنید: سفارش در انتظار، شکست ثبت سند یا صف پردازش عقب‌مانده.
- آزمون مصنوعی را با داده و حساب مشخص اجرا کنید تا با معامله واقعی اشتباه نشود.
- زمان رخداد، نسخه و شناسه پیگیری را برای اتصال گزارش کاربر به شواهد فنی در دسترس مسئول مجاز قرار دهید.
منبع فنی این بخش: Google SRE Book [۴]
با تمرین بازیابی و تحویل مسئولیت کار را کامل کنید
راهنمای AWS بر آزمون منظم مسیر بازیابی و استفاده از runbook در تمرین تأکید دارد. در یک تمرین برنامه‌ریزی‌شده، شرایط شکست، حدود مجاز، مسئول توقف و داده مورد استفاده را روشن کنید. اپراتور باید از روی دستورالعمل و دسترسی خودش سرویس را به وضعیت قابل استفاده برگرداند، نه با کمک شفاهی نویسنده سیستم. گزارش تمرین، زمان واقعی، وضعیت داده و شکاف‌ها را نگه دارد. این شاهد فقط درباره همان دامنه و شرایط آزمون معتبر است و تضمین همه رخدادهای آینده نیست.
| آزمون پیشنهادی | شاهد پذیرش | مسئول تحویل |
|---|---|---|
| بازیابی از پشتیبان | داده و جریان کاربردی در محیط بازیابی قابل استفاده‌اند | مالک داده و بهره‌برداری |
| بازگشت یا اصلاح انتشار | نسخه، تنظیم و سازگاری داده پس از اقدام تأیید می‌شوند | مسئول انتشار و توسعه |
| هشدار و واکنش | هشدار به فرد مسئول می‌رسد و دستورالعمل قابل اجراست | مسئول پاسخ‌گویی رخداد |
| بستن تمرین | شکاف، مالک اقدام و تاریخ بازبینی بعدی ثبت شده‌اند | مالک سرویس |
منبع فنی این بخش: AWS Well-Architected [۳]