عملکرد قابل مشاهده برای کاربر را پایش کنید، شواهد کافی از منابع و برنامه برای تشخیص آن اضافه کنید، و فقط برای شرایطی که نیاز به اقدام انسانی به‌موقع دارند هشدار بدهید. هر هشدار را با یک مسئول، یک گام اول و تشدید همراه کنید. در طول یک حادثه، کاهش اثر را هماهنگ کنید، شواهد را محافظت کنید و بازیابی را از طریق مسیر واقعی کاربر تأیید کنید.
با عملکردی که اهمیت دارد شروع کنید
پاسخی که یک سرور به پینگ می‌دهد ثابت نمی‌کند که برنامه آن کار می‌کند. یک مسیر کاربری نماینده و بی‌ضرر انتخاب کنید، مانند بازیابی یک صفحه عمومی یا دسترسی به یک نقطه پایانی آزمایشی کنترل‌شده. تعریف کنید که موفقیت چگونه به نظر می‌رسد و از بررسی‌های مصنوعی که در هر اجرا سفارش واقعی ایجاد می‌کنند، محتوا منتشر می‌کنند یا اعلان‌های مشتری ارسال می‌کنند خودداری کنید.
هم از یک دیدگاه بیرونی مناسب و هم از داخل برنامه پایش کنید. مشاهده بیرونی می‌تواند مشکلات دسترسی یا مسیریابی را آشکار کند که سرور آن‌ها را نمی‌بیند. اندازه‌گیری‌های داخلی می‌توانند توضیح دهند چرا مسیر کاربری شکست خورد. هر دو دیدگاه را به عملکرد متصل نگه دارید، نه اینکه یک داشبورد بزرگ را صرفاً به این دلیل که هر معیار در دسترس است جمع‌آوری کنید.
سیگنال‌هایی با ارزش تشخیصی انتخاب کنید
راهنمای SRE گوگل تأخیر، ترافیک، خطاها و اشباع را به عنوان سیگنال‌های مفید برای سیستم‌های کاربرمحور برجسته می‌کند. از آن‌ها برای توصیف رفتار استفاده کنید: زمان پاسخ، حجم درخواست، درخواست‌های ناموفق و فشار بر منابع محدود. اندازه‌گیری‌های مناسب برنامه را انتخاب کنید، نه اینکه فرض کنید یک تعریف معیار برای یک وب‌سایت، یک سرویس انتقال و یک کارگر پس‌زمینه کار می‌کند.
در جایی که اهمیت دارد، رفتار درخواست‌های موفق و ناموفق را جدا کنید و نتایج دنباله کند را به جای فقط میانگین‌ها بررسی کنید. فشار حافظه، فضای دیسک، عمق صف یا محدودیت‌های خاص برنامه را وقتی که سرویس را توضیح می‌دهند اضافه کنید. یک خوانش بالای CPU می‌تواند در طول کار دسته‌ای مفید عادی باشد؛ اثر قابل مشاهده برای کاربر تعیین می‌کند که آیا اقدام فوری لازم است.
به هر هشدار یک اقدام و یک مسئول بدهید
یک هشدار باید عملکرد تحت تأثیر، شرایط مشاهده‌شده و بررسی اول مفید را بیان کند. پیش از استقرار آن یک مسئول و یک مسیر تشدید تعیین کنید. شرایطی که نیاز به وقفه سریع دارند را از موارد مناسب برای بررسی زمان‌بندی‌شده جدا کنید. هشدارهای مکرر کم‌ارزش، اپراتورها را آموزش می‌دهند که سیستم را نادیده بگیرند و تشخیص سیگنال‌های مهم را دشوارتر می‌کنند.
از یک بررسی کوچک هشدار برای رفع ابهام استفاده کنید. این جدول نمونه تصمیمات پایش بالقوه را توصیف می‌کند، نه پوشش پشتیبانی SwissOctet یا یک تعهد دسترس‌پذیری. آستانه‌ها باید در برابر خط پایه برنامه واقعی آزمایش شوند. یک شرط بازیابی بگنجانید تا اپراتور بداند چه زمانی هشدار پاک شده است و چه چیزی هنوز نیاز به اعتبارسنجی دارد.
| شرایط مشاهده‌شده | پاسخ مفید | زمینه‌ای که باید گنجانده شود |
|---|---|---|
| مسیر کاربری نماینده شکست می‌خورد | تأثیر را ارزیابی و کاهش دهید | نقطه پایانی تحت تأثیر، مدت و تغییر اخیر |
| دیسک به یک محدودیت برنامه‌ریزی‌شده نزدیک می‌شود | رشد و نگهداری را بررسی کنید | حجم، نرخ رشد و فضای امن |
| تأیید پشتیبان شکست می‌خورد | مسیر بازیابی را محافظت کنید | کار، آخرین نقطه قابل استفاده و خطا |
| تأخیر در طول یک انتشار افزایش می‌یابد | تغییر را بررسی یا بازگردانید | خط پایه، زمان انتشار و درخواست‌های تحت تأثیر |
یک ساختار کوچک برای حادثه آماده کنید
یک فرآیند پاسخ باید تحت فشار قابل فهم باشد. یک هماهنگ‌کننده، کسی که کار فنی را انجام می‌دهد و کسی که مسئول به‌روزرسانی‌ها است را وقتی حادثه به اندازه‌ای بزرگ است که به نقش‌های مجزا نیاز دارد، نام‌گذاری کنید. یک پروژه کوچک ممکن است نقش‌ها را ترکیب کند، اما همچنان از یک نقطه تصمیم‌گیری روشن بهره می‌برد. پیش از خرابی سرویس، یک کانال ارتباطی توافق کنید.
مطالب پاسخ به حادثه گوگل بر هماهنگی و رویکرد کاهش اثر در اولویت تأکید دارد. آن را در مقیاسی که با پروژه سازگار است اعمال کنید: تأثیر را مشخص کنید، اقدامات ایمن را انتخاب کنید و از ایجاد تغییرات متناقض توسط چند اپراتور خودداری کنید. یک خط زمانی و تصمیمات را ثبت کنید. جستجوی یک توضیح کامل نباید یک اقدام ایمن که عملکرد تحت تأثیر را بازمی‌گرداند را به تأخیر بیندازد.
یک افت عملکرد مشخص را مرور کنید
تصور کنید یک سایت پس از یک انتشار کند می‌شود. یک بررسی بیرونی افزایش زمان تکمیل را نشان می‌دهد، در حالی که اندازه‌گیری‌های داخلی خطاهای برنامه و کار رو به رشد پایگاه داده را نشان می‌دهند. هماهنگ‌کننده یک حادثه محدود اعلام می‌کند، شواهد را محافظت می‌کند و یک نفر را برای مقایسه انتشار با خط پایه تعیین می‌کند. نفر دیگری مسیر بازگشت آزمایش‌شده را آماده می‌کند، نه اینکه تغییرات زیرساختی نامرتبط ایجاد کند.
اگر بازگشت برای وضعیت داده برنامه ایمن است، از آن استفاده کنید و نتیجه را مشاهده کنید. اگر ایمن نیست، یک کاهش اثر محدودتر که توسط طرح عملیاتی پشتیبانی می‌شود انتخاب کنید. مستند کنید چه چیزی و چه زمانی تغییر کرد. یک VPS یا پورت بزرگ‌تر ممکن است بعداً ارزش ارزیابی داشته باشد، اما تصمیم فوری باید به شواهد بپردازد، نه اینکه فرض کند اندازه زیرساخت علت است.
شواهد را محافظت کنید و بازیابی را تأیید کنید
گزارش‌های عملیاتی و یادداشت‌های حادثه ممکن است شامل نشانی‌ها، شناسه‌ها و اطلاعات مشتری باشند. آنچه را که بررسی نیاز دارد جمع‌آوری کنید، دسترسی را محدود کنید و اعتبارنامه‌ها یا توکن‌های سفارش خصوصی را از گزارش‌های مشترک دور نگه دارید. برای یک حادثه امنیتی مشکوک، شواهد مناسب را حفظ کنید و سیاست پاسخ پروژه را دنبال کنید، نه اینکه اطلاعات را از طریق پاکسازی عجولانه نابود کنید.
راهنمای پاسخ به حادثه NIST پاسخ را در چارچوب مدیریت ریسک امنیت سایبری گسترده‌تر قرار می‌دهد. بازیابی شامل بررسی عملکرد مورد نظر و رفع شرایطی است که حادثه را ممکن کرده است. مسیر کاربری را آزمایش کنید، رفتار منابع را بررسی کنید و کار پس‌زمینه را پیش از بستن پاسخ بررسی کنید. یک هشدار پاک‌شده یا فرآیند راه‌اندازی مجددشده به تنهایی ممکن است بازگشت کامل به سرویس مفید را نشان ندهد.
حادثه را به یک بهبود قابل اندازه‌گیری تبدیل کنید
یک بررسی کوتاه از تأثیر، خط زمانی، شرایط مشارکت‌کننده و اقدامات انجام‌شده بنویسید. بر تغییراتی تمرکز کنید که قابل تأیید هستند: بهبود یک بررسی، اصلاح یک مجوز، تمرین بازگشت یا افزودن یک وابستگی بازیابی گمشده. مسئولان و معیارهای تکمیل را تعیین کنید. از یک فهرست طولانی از نیات مبهم که هیچ‌کس بعداً نمی‌تواند تأیید کند اجرا شده‌اند خودداری کنید.
هنگام استقرار روی SwissOctet، پایش و پاسخ را به عنوان بخشی از عملیات برنامه برنامه‌ریزی کنید، جدا از سخت‌افزار انتخاب‌شده و هر ترتیب مدیریتی تأییدشده. کاتالوگ یک تیم حادثه با کارکنان یا ساعات پشتیبانی مستمر را ثابت نمی‌کند. پیش از اتکا به یک محیط تولیدی، تصمیم بگیرید چه کسی هشدارها را دریافت می‌کند، چه کسی می‌تواند اقدام کند و شرایط واقعی سرویس چه چیزی را پوشش می‌دهد.
چک‌لیست عملی شما.
- یک مسیر کاربری نماینده بی‌ضرر را پایش کنید.
- سیگنال‌هایی انتخاب کنید که رفتار برنامه را توضیح می‌دهند.
- به هشدارها یک اقدام، مسئول و شرط بازیابی بدهید.
- پیش از یک حادثه بر هماهنگی و تشدید توافق کنید.
- شواهد را محافظت کنید و بازیابی کامل را تأیید کنید.
- پس از بررسی، بهبودهای قابل آزمایش تعیین کنید.
جزئیاتی که اهمیت دارند.
آیا پایش زمان کار سرور کافی است؟+
خیر. یک ماشین قابل دسترسی می‌تواند میزبان یک برنامه خراب باشد. عملکردی که کاربران به آن وابسته هستند را پایش کنید و شواهد منابع را برای تشخیص خرابی‌ها اضافه کنید.
آیا هر آستانه معیار باید فوراً به کسی هشدار بدهد؟+
خیر. وقفه‌های فوری را برای شرایط قابل اقدام که نیاز به توجه به‌موقع دارند نگه دارید. کارهای کم‌اولویت‌تر را به یک فرآیند بررسی با مسئول مشخص هدایت کنید.
چه زمانی یک حادثه تمام می‌شود؟+
پس از تأیید عملکرد تحت تأثیر و کار پس‌زمینه مرتبط، رسیدگی به ریسک‌های فوری و ثبت اقدامات پیگیری. راه‌اندازی مجدد یک فرآیند به تنهایی کافی نیست.
به منبع بروید.
این منابع از مفاهیم فنی این راهنما پشتیبانی می‌کنند. پیش از تغییر یک سیستم تولیدی، مستندات جاری را دنبال کنید.
- SRE گوگل: پایش سیستم‌های توزیع‌شده sre.google
- کتاب کار SRE گوگل: پاسخ به حادثه sre.google
- NIST SP 800-61 Rev. 3: پاسخ به حادثه csrc.nist.gov
راهنمایی تحریریه توسط SwissOctet. مثال‌ها نمایشی هستند. مشخصات خدمات، گزینه‌های موجود و شرایط قراردادی باید جداگانه تأیید شوند.