سود:
- مدیریت سرتاسر یک حادثه با پشتیبانی هوش مصنوعی در مراحل تشخیص، تشخیص، کاهش، راه حل دائمی و یادگیری
- توانایی حفظ نظم و انضباط تایید حتی در مواقع وحشت با جداسازی مراحل قابل انتقال به هوش مصنوعی و مواردی که نیاز به تصمیم گیری انسانی در هر مرحله دارند.
- توانایی تبدیل این قانون طلایی که هوش مصنوعی بر سؤالات «آنچه اتفاق میافتد، چگونه بنویسیم» اولویت دارد و انسانها بر سؤالات «آیا باید آن را انجام دهم، کسی که ضامن است» اولویت را به یک بازتاب تجاری دارند.
یکپارچه سازی End-to-End: مدیریت یک حادثه از انتها به انتها با هوش مصنوعی
شما قطعات را در ده بخش قبلی یاد گرفتید: اسکریپت نویسی، تجزیه و تحلیل گزارش، نظارت، پیکربندی، IaC، مستندسازی، نگهداری پیش بینی، مدیریت تغییر و امنیت. اما در دنیای واقعی، این بخش ها یکی یکی نمی آیند، بلکه در درون یک رویداد در هم تنیده می شوند. در این بخش نهایی، ما قطعات را کنار هم میآوریم: به طور کامل خواهید دید که چگونه میتوانید حادثهای را که در نیمهشب شروع شده است، از انتها به انتها، از تشخیص به علت اصلی، از اصلاح به مستندسازی، و استفاده از دوز مناسب هوش مصنوعی در هر مرحله، مدیریت کنید. هدف آموزش یک تکنیک جدید نیست. به هم پیوستن آنچه که به عنوان رفلکس یک مهندس آموخته اید، تقویت حقیقت واحد تکرار شده در ماژول: هوش مصنوعی در هر مرحله شتاب می دهد، روشن می کند و طرح ریزی می کند. but it is always the human who confirms the diagnosis, runs the command, confirms the change, and bears responsibility for the outcome.
در این واحد، شما چرخه حیات یک حادثه - تشخیص، تشخیص، مداخله، حل و فصل، یادگیری - و نقش و محدودیت های هوش مصنوعی را در هر مرحله از طریق یک مثال یکپارچه خواهید کرد.
چرخه زندگی یک رویداد
هر حادثه جدی مراحل مشابهی را پشت سر می گذارد و هوش مصنوعی در هر مرحله نقش متفاوتی دارد. تشخیص: یک زنگ هشدار به صدا در می آید، یک کاربر شکایت می کند، یک متریک از خط پایه منحرف می شود (واحد 4). اعتبار و دامنه: آیا واقعاً یک موضوع است، چقدر گسترده است؟ تشخیص: دستیابی به علت اصلی از لاگ ها و معیارها (واحد 3). پاسخ و کاهش: توقف آسیب، راه حل. راه حل دائمی: رفع مشکل با مدیریت تغییر (واحد 9)، اسکریپت (واحد 2) یا پیکربندی در صورت لزوم (واحد 5). آموزش: به روز رسانی پس از مرگ و runbook (واحد 7). هوش مصنوعی ناهنجاری را در تشخیص مشخص می کند، فرضیه هایی را در تشخیص ایجاد می کند، گزینه هایی را در مداخله ارائه می دهد، پیش نویس ها را در راه حل می نویسد، اسناد را در یادگیری تولید می کند - اما در هر مرحله، انسان ها در نقطه تصمیم گیری می ایستند.
نکته: خطرناکترین لحظه یک حادثه، لحظه تشخیص و پاسخ است که استرس در بالاترین حد است - دقیقاً زمانی که میل به اعتماد کورکورانه به هوش مصنوعی قویترین است. هر چه بیشتر عجله کنید، بازتاب "خواندن، تأیید، آماده شدن برای بازگشت" را محکم تر نگه می دارید. یک تأیید صحت که در یک لحظه وحشت انجام می شود، رویداد را دو برابر می کند.
یک مثال از ابتدا تا انتها
بیایید آن را ملموس کنیم. زنگ ساعت 02:10: زمان پاسخگویی سرویس پرداخت p99 6 ثانیه است، بسیار بالاتر از خط پایه (250-400 میلی ثانیه). تشخیص درست: ردیابی کار کرد. تأیید: تأیید از چندین مکان، یک رویداد واقعی. تشخیص: مهندس گزارش و معیارهای 20 دقیقه آخر را به هوش مصنوعی می دهد. هوش مصنوعی یک جدول زمانی تعیین می کند و کاهش سرعت را بلافاصله پس از استقرار در ساعت 02:08 شروع می کند - یک همبستگی قوی، اما همچنان یک فرضیه. مهندس این را با گزارش استقرار تأیید می کند: بله، یک نسخه در 02:08 منتشر شد. پاسخ: سریعترین کاهش، بازگرداندن توزیع است. مرحله برگشت در درخواست تغییر آماده است (واحد 9). مهندس ابتدا rollback را بر روی یک سرور با منطق قناری پیاده سازی می کند، زمان پاسخگویی بهبود می یابد و سپس آن را منتشر می کند. راه حل دائمی: علت اصلی واقعی (پرس و جوی غیر نمایه شده در نسخه جدید) روز بعد با آرامش برطرف می شود. یادگیری: یک پس از مرگ بدون هوش مصنوعی تهیه می شود و مرحله "نظارت p99 پس از استقرار" به runbook اضافه می شود. در هر مرحله، هوش مصنوعی شتاب گرفت. انسان در هر نقطه تصمیم گیری معتبر است.
قانون طلایی تقسیم کار انسان و هوش مصنوعی
تمایزی که در سراسر ماژول می بینید در اینجا به یک قانون تبدیل می شود: هوش مصنوعی در سؤالات "چه اتفاقی می افتد، چه می تواند بیفتد، چگونه بنویسیم" جلوتر است. وقتی صحبت از سؤالاتی مانند "آیا باید این کار را الان انجام دهم، چه کسی می تواند این کار را تضمین کند؟" جلوتر هستند. هوش مصنوعی خستگیناپذیر، سریع است، اطلاعات گسترده را اسکن میکند و طرحهای اولیه را تولید میکند - اما زمینه کامل را نمیداند، میتواند توهم ایجاد کند، نمیتواند مسئولیتپذیری را مدیریت کند، و وابستگیهای پنهان سازمان شما را نمیبیند. انسان کند است، اما دارای زمینه، مسئولیت و قضاوت است. بهترین نتیجه در تقسیم کار صحیح بین این دو است: کار تکراری، متنی و قابل تولید را به هوش مصنوعی واگذار کنید. تایید، تصمیم و اجرا را انسان نگه دارید.
سه کیف کوچک
مورد 1 - 40 دقیقه پایان به پایان. در یک رویداد کامل دیسک، یک SRE کل زنجیره را با هوش مصنوعی تسریع کرد: زنگ را با خط پایه (5 دقیقه) تأیید کرد، گزارش ماسکشده را به YZ خلاصه کرد و اولین خطا را پیدا کرد (5 دقیقه)، فرضیه «چرخش ورود به سیستم متوقف شد» AI را در سیستم واقعی تأیید کرد (5 دقیقه)، اجرا کرد و یک اسکریپت پاکسازی آماده را اجرا کرد (اسکریپت تمیز کردن 10 دقیقه با خشک کردن اسکریپت نوشته شده بود و 10 دقیقه). حقایق را تأیید کرد (15 دقیقه). مجموع 40 دقیقه; تقریباً دو برابر بدون هوش مصنوعی. اما در هر مرحله یک مرحله تأیید وجود داشت.
مورد 2 - در یک لحظه وحشت از تأیید صحت رد شد. تیم دیگری با عجله برید. اولین فرضیه علت اصلی هوش مصنوعی (یک سرویس وابستگی) را بدون تأیید آن پذیرفت و آن سرویس را دوباره راه اندازی کرد. مشکل حل نشد زیرا علت واقعی چیز دیگری بود. علاوه بر این، راهاندازی مجدد غیرضروری باعث قطعی دوم شد. درس: عجله هیچ توجیهی برای نادیده گرفتن تأیید نیست. قبل از اینکه فرضیه هوش مصنوعی تایید شود، اقدام باعث تشدید رویداد می شود.
مورد 3 - آگاهی از حد. یک مهندس در حال اجرای یک تغییر پیکربندی بود که هوش مصنوعی در مورد یک مشکل پیچیده شبکه اصرار کرده بود. اما این تغییر غیرقابل برگشت به نظر می رسید و هوش مصنوعی قوانین مسیریابی خاص آژانس را نمی دانست. مهندس متوقف شد، با یک کارشناس ارشد شبکه مشورت کرد و فهمید که پیشنهاد هوش مصنوعی یک حلقه مسیریابی در این توپولوژی خاص ایجاد می کند. دانستن محدودیت هوش مصنوعی از ایجاد اختلال جلوگیری کرد.
چهار قالب قابل کپی
1) خلاصه محرک رویداد (تریاژ):
نقش شما: ارشد SRE، دستیار فرمانده حوادث. یک رویداد فعال وجود دارد. هشدار/متریک/گزارش ماسکدار که به شما میدهم یک تریاژ سریع به من میدهد: (1) نشانه چیست، (2) دامنه تاثیر چیست، (3) 3 ناحیه که باید ابتدا نگاه کنم، (4) یک فرمان کنترل فقط خواندنی برای هر کدام. تصمیم و اجرا با من است. راه را بفرست داده ها: [ماسک شده]
2) راهنمای مدیریت حادثه مرحلهای:
من را گام به گام در چرخه عمر حادثه برای علامت [علائم] همراهی کنید: تأیید تشخیص، تشخیص، کاهش، رفع دائمی، یادگیری. در هر مرحله، به من بگویید (الف) چه کاری باید انجام دهم، (ب) چه زمانی می توانم با خیال راحت آن را به هوش مصنوعی واگذار کنم، (ج) چه تصمیمی باید خودم بگیرم. مراحل تأیید را علامت گذاری کنید که حتی اگر عجله دارم نباید از آنها بگذرم.
3) کنترل نقطه تصمیم:
من در میانه یک رویداد هستم و می خواهم این عمل را انجام دهم: [عمل]. قبل از اجرا، از من بپرسید: (1) آیا این قابل برگشت است، (2) چه تأییدیه ای انجام دادم/ انجام ندادم، (3) آیا برنامه بازگشتی دارم، (4) آیا شواهدی دارم که این عمل واقعاً علت اصلی را حل کرده است؟ اگر چیزی کم دیدی، جلوی من را بگیر.
4) یادگیری تلفیقی پس از رویداد:
برای حادثه ای که به تازگی حل شده است، [خلاصه] به من می دهد: (1) یک پیش نویس پس از مرگ بدون سرزنش، (2) 3 بهبود دائمی (نظارت/اتوماسیون/پیکربندی) که از این حادثه جلوگیری می کند، (3) مراحل runbook که باید به روز شوند، (4) پیشنهاد سیگنال هشدار اولیه برای حادثه مشابه. نوشتن علت اصلی بدون مدرک؛ بر اساس واقعیت ها
اعلان ضعیف / اعلان قوی
اعلان ضعیف:
سیستم خراب شد چیکار کنم؟
وحشت زده، بدون زمینه و بدون تأیید، این اعلان توصیه های عمومی و احتمالاً خطرناک را از هوش مصنوعی دریافت می کند. عجله در این مرحله بیشتر به اشتباه منجر می شود.
اعلان قدرتمند:
نقش شما: دستیار فرمانده حادثه. رویداد فعال: پرداخت serviceip99 زمان پاسخگویی 15 بار پایه (250-400 میلیثانیه) از ساعت 02:10. من می دانم که توزیع در 02:08 وجود داشت. به من بدهید: (1) محتمل ترین فرضیه و نحوه تأیید آن فقط خواندنی، (2) سریعترین و برگشت پذیرترین گزینه کاهش، (3) خطراتی که باید قبل از اعمال این کاهش کنترل کنم. من اجرا و تایید را دارم. دادههای اضافی: [متریک/log masked]
مرحله رویداد
نقش هوش مصنوعی
تصمیم حیاتی انسانی
تشخیص
ناهنجاری را علامت بزنید
آیا این رویداد واقعی است، دامنه آن چیست؟
تشخیص
ایجاد فرضیه
کدام فرضیه تایید شد؟
کاهش
گزینه ها را پیشنهاد نکنید
کدام کاهش قابل برگشت است؟
راه حل دائمی
پیش نویس/اسکریپت
تغییر را تایید و اجرا کنید
یادگیری
طرح پس از مرگ
اعتبارسنجی حقایق و درس ها
اشتباهات رایج
- رد شدن از تأیید در حالت وحشت. عجله هیچ توجیهی برای کنار گذاشتن رفلکس «خواندن، تأیید، آماده کردن بازگشت» نیست. با افزایش استرس، نظم و انضباط باید افزایش یابد.
- اشتباه فرضیه با شواهد اقدام بدون تایید اولین پیشنهاد علت ریشه ای هوش مصنوعی باعث تشدید حادثه می شود.
- فراموش کردن مرز زمینه هوش مصنوعی هوش مصنوعی وابستگی های پنهان سازمان را نمی شناسد. در تغییر بحرانی، قضاوت انسان غالب است.
- رد شدن از مرحله یادگیری این رویداد، بدون بهروزرسانیهای پس از مرگ و رانبوک، دوباره در همان شب آغاز میشود.
- مسئولیت را بر دوش هوش مصنوعی گذاشت. "هوش مصنوعی چنین گفته است" دفاع نیست. مسئولیت اعدام همیشه بر عهده انسان است.
احتیاط: استفاده از هوش مصنوعی در مدیریت حوادث جایگزین یادگیری مدیریت حوادث نمی شود. وسیله نقلیه ممکن است تصادف کند، تصادف کند یا غیر قابل دسترس باشد. مهندسی که اصول اولیه را می داند با هوش مصنوعی سریع تر است. مهندسی که اصول اولیه را نمی داند با هوش مصنوعی سریعتر اشتباه می کند. ابتدا نظم و انضباط را برقرار کنید، سپس سرعت را از هوش مصنوعی بگیرید.
به طور خلاصه
در دنیای واقعی، بخش ها یکی یکی نمی آیند بلکه در درون یک رویداد در هم تنیده می شوند. هنگام مدیریت یک رویداد از تشخیص تا یادگیری، هوش مصنوعی در هر مرحله سرعت میبخشد: ناهنجاری را علامتگذاری میکند، فرضیهها را تولید میکند، گزینهها را ارائه میدهد، پیشنویسها را آماده میکند. اما در هر نقطه تصمیم گیری، فرد متوقف می شود - تشخیص را تأیید می کند، کاهش را انتخاب می کند، تغییر را تأیید می کند، صاحب نتیجه می شود. قانون طلایی روشن است: هوش مصنوعی در سؤالات «چه اتفاقی می افتد، چگونه بنویسیم» جلوتر است و انسان ها در سؤالات «آیا باید آن را انجام دهم، ضامن کیست؟» جلوتر هستند؟ در مواقع وحشت، نظم و انضباط را افزایش دهید، فرضیه ها را از شواهد جدا کنید، محدودیت های زمینه هوش مصنوعی را به خاطر بسپارید و از هر رویداد یک درس درسی بگیرید. ماهیت این ماژول یک جمله است: هوش مصنوعی یک دستیار قدرتمند است. مسئولیت مهندسی قابل تفویض نیست.
وظیفه کاربردی
رویدادی را که در گذشته خود تجربه کرده اید (یا تصور کرده اید) از ابتدا تا انتها در نظر بگیرید. با الگوی «راهنمای مدیریت مرحلهای حادثه» در بالا، از هوش مصنوعی بخواهید که حادثه را در مراحل تشخیص-تشخیص-کاهش-حل-حل-یادگیری هدایت کند. در هر مرحله، مرحله ای را که می توانید به هوش مصنوعی تفویض کنید و مرحله ای که باید خودتان تصمیم بگیرید را جداگانه بنویسید. Confirm at least one AI hypothesis with a verification command during the diagnosis phase. در نهایت، پیشنویس بهروزرسانی پس از مرگ و runbook را با الگوی «آموزش یکپارچه پس از رویداد» تهیه کنید. تقسیم کار انسان و هوش مصنوعی در کل فرآیند را در 7 مورد خلاصه کنید.
چک لیست
- [ ] آیا حادثه را به مراحل تشخیص، تشخیص، کاهش، راه حل و یادگیری تقسیم کرده ام؟
- [ ] آیا من بین مراحلی که می توان به هوش مصنوعی واگذار کرد و مراحلی که نیاز به تصمیم گیری انسانی در هر مرحله دارند تمایز قائل شده ام؟
- [ ] آیا در تشخیص، فرضیه هوش مصنوعی را از شواهد جدا کردم و آن را با یک فرمان تأیید تأیید کردم؟
- [ ] آیا کاهش را از نظر برگشت پذیری و طرح بازگشت ارزیابی کرده ام؟
- [ ] آیا رفلکس «خواندن، تأیید، آماده کردن بازگشت» را حتی در مواقع وحشت حفظ کردم؟
- [ ] آیا من یک درس پس از مرگ و رانبوک از این حادثه یاد گرفتم؟
امتحان ماژول
1. کدام یک از موارد زیر دقیق ترین موقعیت یابی هوش مصنوعی در مدیریت سیستم و شبکه است؟
- الف) هوش مصنوعی یک ابزار دستیار و پشتیبانی تصمیم است. مسئولیت و تایید نهایی تصمیمات اجرایی حیاتی بر عهده انسان است ✔
- ب) هوش مصنوعی می تواند دستورات را اجرا کند و تغییراتی را در تولید بدون تایید انسان اعمال کند
- ج) هوش مصنوعی فقط در نوشتن متن کار می کند، ربطی به کار سیستمی و شبکه ای ندارد
- د) هوش مصنوعی همیشه تصمیمات دقیق تری نسبت به انسان می گیرد، بنابراین تأیید غیرضروری است
توضیحات: هوش مصنوعی یک ابزار دستیار و پشتیبانی تصمیم است که پیش نویس ها و تحلیل هایی مانند اسکریپت ها، تجزیه و تحلیل گزارش و اسناد را تولید می کند. مسئولیت و تایید نهایی تصمیمات اجرایی که بر زمان خرابی، از دست دادن داده ها و امنیت تاثیر می گذارد، مانند اجرای دستور یا تایید تغییر، بر عهده مهندس ذیصلاح است.
2. چهار مرحله از رفلکس تایید که باید قبل از اجرای دستور تولید شده توسط هوش مصنوعی در تولید اجرا شود، چیست؟
- الف) کپی، پیست، اجرا، امید
- ب) بخوانید و درک کنید، مستندسازی کنید، در یک محیط ایزوله امتحان کنید، برای بازخورد آماده شوید ✔
- ج) لایک، اشتراک گذاری، ذخیره، آرشیو
- د) حذف، بازنویسی، فشرده سازی، ارسال
توضیحات: چهار مرحله برای اعمال در یک خروجی حیاتی: (1) خط به خط فرمان را بخوانید و درک کنید، (2) پرچم ها و نحو را به اسناد رسمی پیوند دهید، (3) آن را در یک محیط ایزوله/آزمایشی امتحان کنید، در صورت امکان اجرا خشک کنید، (4) یک طرح بازگشتی (پشتیبان، عکس فوری) را در صورت اشتباه تهیه کنید.
3. «بی توان» بودن یک اسکریپت اتوماسیون به چه معناست و چرا مهم است؟
- الف) اسکریپت در هر اجرا نتایج متفاوتی تولید می کند
- ب) اسکریپت فقط یک بار می تواند اجرا شود و سپس حذف شود
- ج) اسکریپت در اجرای بار دوم هیچ آسیبی ایجاد نمی کند. ✔ ایمن است حتی اگر دوباره فعال شود
- د) اسکریپت شامل مدیریت خطا نیست
توضیح: Idempotency به این معنی است که وقتی یک اسکریپت دو یا چند بار اجرا می شود، در اجرای دوم باعث آسیب یا خطا نمی شود. منطقی مانند 'پرش اگر کاربر از قبل وجود دارد'، 'ایجاد دایرکتوری اگر وجود ندارد، آن را لمس نکنید اگر وجود دارد' ایجاد شده است. این تضمین می کند که اتوماسیون ایمن کار می کند حتی اگر به طور تصادفی دوباره راه اندازی شود.
4. اساسی ترین راه برای ایمن سازی اسکریپتی که شامل عملیات مخرب (حذف، راه اندازی مجدد) است چیست؟
- الف) اسکریپت را با بیشترین سرعت ممکن اجرا کنید
- ب) مخفی کردن پیام های خطا
- ج) تست مستقیم فیلمنامه در مرحله تولید
- د) قرار دادن عملیات مخرب در پشت اجرای خشک پیشفرض و اتصال اجرای واقعی به یک علامت صریح ✔
توضیح: نگهداری فرآیندهای مخرب در حالت اجرای خشک به طور پیشفرض و تنها اجرای برنامه واقعی با یک پرچم تأیید صریح (مثلاً --apply) به شما این امکان را میدهد که ابتدا ببینید با اجرای اسکریپت چه اتفاقی میافتد. همچنین بررسی متغیر تهی (VAR:?) از خطاهای مسیر جلوگیری می کند.
5. اصل "همبستگی علیت نیست" در تحلیل لاگ به چه معناست؟
- الف) دو رویدادی که با هم تغییر می کنند، لزوماً در رابطه علت و معلولی نیستند. علیت نیز باید تأیید شود ✔
- ب) جستجوی همبستگی در لاگ ها اتلاف وقت است
- ج) از دو رویدادی که با هم تغییر می کنند، قطعاً یکی علت دیگری است.
- D) Causality can only be determined by artificial intelligence
توضیح: صرف اینکه دو رویداد همزمان رخ می دهند (همبستگی) به این معنا نیست که یکی باعث دیگری می شود (علت). هر دو ممکن است نتیجه یک رویداد سوم باشند. پیشنهاد هوش مصنوعی مبنی بر اینکه "X احتمالا باعث Y شده است" یک فرضیه است و تا زمانی که در سیستم تأیید نشود، یافته ای محسوب نمی شود.
6. چرا هنگام اندازه گیری زمان پاسخ در پایش عملکرد، صدک (p95/p99) بر میانگین ترجیح داده می شود؟
- الف) محاسبه درصد ساده تر از میانگین است
- ب) میانگین تجربه بد اقلیت را پنهان می کند. صدک این مشکلات پنهان را آشکار می کند ✔
- C) The average is always wrong and should not be used
- د) درصد فقط برای معیارهای CPU اعمال می شود
توضیح: میانگین تجربه بسیار بدی را که بخش کوچکی از کاربران دارند پنهان می کند. حتی اگر میانگین به نظر می رسد 200 میلی ثانیه است، p99 ممکن است 6 ثانیه باشد. این بدان معنی است که از هر صد درخواست، یک درخواست به طرز وحشتناکی کند است. صدک درد این اقلیت را که با میانگین پنهان شده است نمایان می کند.
7. "دریفت" در مدیریت پیکربندی چیست و چرا خطرناک است؟
- الف) ترافیک شبکه در شب کاهش می یابد
- ب) جابجایی فیزیکی یک سرور
- ج) سرورها با گذشت زمان از یکدیگر و استاندارد منحرف می شوند. ✔ نامرئی تا زمانی که مشکلی رخ دهد
- د) پشتیبان گیری خودکار از فایل های پیکربندی
توضیحات: دریفت انحراف سرورها از یکدیگر و از استاندارد از طریق تغییرات دستی غیرمستند در طول زمان است. خطر آن سکوت آن است: تا زمانی که مشکل رخ ندهد قابل مشاهده نیست، سپس یک سرور متفاوت از بقیه رفتار می کند و تشخیص ساعت ها طول می کشد. هوش مصنوعی باعث می شود رانش با مقایسه قابل مشاهده باشد. اصل جوشکاری طلا مانع می شود.
8. چرا مرحله "طرح" حیاتی ترین نرده امنیتی در ابزارهای IaC (مانند Terraform) است؟
- الف) طرح کد را سریعتر اجرا می کند
- ب) فایل حالت پلان را حذف می کند
- ج) طرح فقط قالب بندی کد را اصلاح می کند
- د) طرح نشان می دهد که چه چیزی قبل از اجرا اضافه، تغییر و حذف می شود. جلوگیری از از دست رفتن اطلاعات ✔
توضیحات: پلان (طرح Terraform / Ansible --check) پیش نمایش "چه چیزی تغییر خواهد کرد" را قبل از اجرای کد ارائه می دهد: تعداد منابع اضافه، تغییر، حذف شده است. به طور خاص، خطوط "تخریب" و "جایگزینی نیروها" خطر از دست دادن داده ها را قبل از اجرا نشان می دهد. درخواست بدون مطالعه طرح یکی از گران ترین اشتباهات است.
9. چرا فایل State Terraform باید به دقت محافظت شود و در AI یا مخازن باز قرار داده نشود؟
- الف) اسرار متن ساده ممکن است در پرونده دولتی گنجانده شود. در صورت لو رفتن، اطلاعات هویتی فاش خواهد شد ✔
- ب) چون فایل state خیلی بزرگ است
- ج) فایل حالت از قبل به صورت غیرقابل خواندن رمزگذاری شده است.
- د) هنگامی که فایل حالت به اشتراک گذاشته می شود، کد سریعتر اجرا می شود
توضیحات: فایل State وضعیت فعلی زیرساخت مدیریت شده را حفظ می کند و می تواند شامل اسرار متن ساده (رمزهای عبور پایگاه داده، کلیدها) باشد. بنابراین، باید در یک باطن از راه دور رمزگذاری شده، با دسترسی محدود و قفل شده نگهداری شود. هرگز نباید در یک وسیله نقلیه عمومی یا مخزن قرار داده شود، در غیر این صورت راز فاش می شود.
10. عبارت "Runbook اشتباه خطرناکتر از بدون runbook است" در مستندات بر چه چیزی تاکید دارد؟
- الف) نوشتن runbook اتلاف وقت است
- ب) یک runbook تست نشده کورکورانه در یک بحران اجرا می شود. یک قدم اشتباه می تواند منجر به فاجعه شود ✔
- ج) Runbook ها فقط برای مدیران نوشته شده اند
- د) اسناد هرگز نباید به روز شوند
توضیح: یک تیم بدون runbook در هنگام بحران محتاط و مشکوک است. اما فردی که دارای راندبوک "رسمی" است، آن را تحت استرس و بدون سوال اعمال می کند. اگر runbook آزمایش نشده باشد و یک مرحله اشتباه داشته باشد، اجرای کور منجر به فاجعه خواهد شد. به همین دلیل است که هر runbook باید به طور کامل تست شده و در یک محیط واقعی مهر شود.
11. در تعمیر و نگهداری پیش بینی، کدام رویکرد صحیح برای درک زمانی که یک دیسک در حال نزدیک شدن به خرابی است؟
- الف) بلافاصله یک دیسک SMART بد را جایگزین کنید
- ب) نادیده گرفتن کامل داده های SMART
- ج) نگاهی به روند ارزش ها در طول زمان؛ ✔ افزایش مداوم و شتاب دهنده تعداد سیگنال
- د) اقدام فقط پس از جمع شدن کامل دیسک
توضیح: یک خواندن SMART بد دلیلی برای وحشت نیست. این طبیعی است که دیسک ها گاهی اوقات خطاهای خود را تصحیح کنند. سیگنال واقعی روند است: افزایش مداوم و شتابان مقادیری مانند بخش تخصیص مجدد در طول زمان. به همین دلیل است که به هوش مصنوعی یک سری زمانی داده می شود، نه یک خواندن.
12. دو بخش غالباً نادیده گرفته شده اما حیاتی در تغییر تولید کدامند؟
- الف) رنگ و نام تغییر
- ب) عنوان و بخش شخصی که تغییر را انجام می دهد
- ج) اعلام تغییر در شبکه های اجتماعی
- د) طرح بازگشت و معیارهای تأیید موفقیت ✔
توضیح: اگر قبل از اعمال تغییر، پاسخ کتبی به سؤالات «اگر خراب شد چگونه دقیق برگردم» (طرح برگشت) و «چگونه موفقیت آمیز بودن آن را ثابت کنم» (معیارهای تأیید موفقیت) وجود نداشته باشد، آن تغییر هنوز آماده نیست. بدون این دو، یک تغییر شکسته ممکن است "کامل" در نظر گرفته شود.
13. چرا رویکرد "قناری" به جای گسترش یک استقرار امنیتی (نسخه/وصله جدید) برای همه سرورها به طور همزمان ترجیح داده می شود؟
- الف) تغییر ابتدا در قسمت کوچکی اعمال می شود. یک اشکال بر بخش کوچکی تأثیر میگذارد، نه کل ناوگان، و زودهنگام کشف میشود ✔
- ب) توزیع قناری برق کمتری مصرف می کند
- ج) Canary تأیید استقرار را کاملاً غیر ضروری می کند
- د) استقرار قناری فقط برای پایگاه های داده اعمال می شود
توضیحات: استقرار قناری ابتدا اعمال تغییر بر روی بخش کوچکی (یک سرور، 5 درصد از کاربران) و نظارت است. به این ترتیب، یک باگ بخش کوچکی را تحت تأثیر قرار می دهد، نه کل ناوگان، و زودهنگام گرفتار می شود. یک باگ که به یکباره گسترش می یابد، به طور همزمان به همه کاربران برخورد می کند.
14. قانون تغییرناپذیر اخلاقی و قانونی در استفاده از هوش مصنوعی در کارهای امنیتی چیست؟
- الف) از هوش مصنوعی می توان آزادانه برای اسکن آسیب پذیری در هر سیستمی استفاده کرد
- ب) منشور اخلاقی فقط برای مؤسسات بزرگ اعمال می شود
- ج) فقط در سیستم های مجاز و برای اهداف دفاعی استفاده می شود. استفاده برای دسترسی یا حمله غیرمجاز جرم است ✔
- د) نفوذ به سیستم شخص دیگری برای یادگیری رایگان است.
توضیحات: اطلاعات سیستم و شبکه دو کاربرد دارد. هوش مصنوعی فقط در سیستمهایی که مجوز کتبی برای آنها دارید و برای اهداف دفاعی (تشخیص تهدید ورود، سختسازی، پاسخ به حادثه) قابل استفاده است. استفاده از آن برای اسکن یا نفوذ به سیستمی که متعلق به شما نیست، دسترسی غیرمجاز و جرم است. برای یادگیری باید از آزمایشگاه ایزوله استفاده کرد.