رخداد جایی است که معماری، ابزار و فرهنگ تیم هم‌زمان آزموده می‌شوند. فرایند خوب باید impact کاربر را کم کند و در عین حال شواهد و توان یادگیری را حفظ کند. امشب پاسخ‌های فنی و انسانی را جدا نمی‌کنیم: on-call بدون امنیت روانی فرسوده می‌شود و فرهنگ بدون نقش و runbook در بحران کافی نیست.

پرسش‌های ۱۲۱ تا ۱۲۵: مدیریت رخداد#

۱۲۱. incident management چیست؟#

پاسخ کوتاه: مدیریت رخداد فرایند تشخیص، هماهنگی، مهار و بازیابی از اختلال خدمت است و پس از restore به یادگیری و پیگیری اقدام‌ها ادامه می‌دهد. اولویت نخست کاهش impact کاربر با تصمیم‌های قابل برگشت است.

رخداد با alert یکسان نیست؛ alert یک signal است و incident وضعی است که هماهنگی و پاسخ می‌خواهد. نقش‌هایی مانند incident commander، مسئول عملیات و ارتباطات از کار موازی و پیام متناقض جلوگیری می‌کنند. timeline، فرضیه و تصمیم‌ها باید ثبت شوند. هنگام بحران، یافتن مقصر یا root cause نهایی اولویت نیست. معیار پایان پاسخ اولیه، بازگشت پایدار خدمت و تحویل روشن کارهای باقی‌مانده است.

۱۲۲. Incident Response Plan چیست؟#

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

فهرست تماس، دسترسی اضطراری، channel جایگزین و وابستگی بیرونی باید حتی هنگام ازکارافتادن ابزار اصلی در دسترس باشند. plan سطح بالا با runbook سرویس فرق دارد؛ اولی فرایند سازمانی و دومی اقدام فنی مشخص است. الزام امنیتی و قانونی برای اطلاع‌رسانی و نگه‌داری شواهد نیز در scope می‌آید. تمرین tabletop و game day نشان می‌دهد شماره، مجوز یا فرض معماری قدیمی شده است.

۱۲۳. postmortem analysis چیست؟#

پاسخ کوتاه: postmortem بررسی ساختاریافتهٔ رخداد پس از بازیابی است که impact، timeline، عامل‌های مؤثر، نقاط خوب و بد تشخیص و پاسخ، و اقدام‌های قابل پیگیری را ثبت می‌کند. هدف یادگیری و کاهش احتمال یا اثر تکرار است.

عبارت «خطای انسانی» پایان تحلیل نیست؛ باید پرسید چرا یک اقدام قابل انجام و اثر آن گسترده بود و چه guardrail یا بازخوردی کم بود. root cause واحد در سامانهٔ پیچیده اغلب ساده‌سازی است. action item باید owner، مهلت و معیار پایان داشته باشد و تعداد آن قابل انجام باشد. postmortem بدون اشتراک و پیگیری فقط سند بایگانی است. اطلاعات حساس و لحن سرزنش‌آمیز نیز باید مدیریت شوند.

۱۲۴. incident severity level چیست؟#

پاسخ کوتاه: severity طبقه‌بندی impact و فوریت رخداد است تا پاسخ، escalation و ارتباط متناسب فعال شود. معیار می‌تواند گسترهٔ کاربر، از دست‌رفتن داده، ریسک امنیتی، درآمد و نبود workaround را ترکیب کند.

عددها میان سازمان‌ها یکسان نیستند؛ در جایی SEV1 بالاترین و در جای دیگر P0 به‌کار می‌رود. پس تعریف را بگویید، نه فقط برچسب. severity باید با اطلاعات تازه قابل تغییر باشد. علت فنی عجیب لزوماً severity بالا نمی‌سازد و خرابی ساده با impact گسترده ممکن است بالاترین سطح باشد. target پاسخ و cadence اطلاع‌رسانی باید برای هر سطح روشن باشد و طبقه‌بندی برای پنهان‌کردن آمار دست‌کاری نشود.

۱۲۵. on-call management چیست؟#

پاسخ کوتاه: مدیریت on-call طراحی rotation، handoff، escalation، ابزار و سلامت کاری است تا فرد مناسب در زمان لازم بتواند با context و دسترسی کافی پاسخ دهد. هدف ۲۴ساعته‌کردن فشار روی چند نفر نیست.

alert باید actionable، دارای owner و متناسب با شدت باشد. runbook، محیط تمرین و shadow rotation ورود عضو جدید را امن می‌کند. جبران خدمت، زمان استراحت و محدودیت حجم هشدار بخشی از طراحی پایدارند. handoff رخداد باز و تغییر مهم را منتقل می‌کند. شاخص‌هایی مانند تعداد page شبانه، false positive و زمان پاسخ برای بهبود سیستم استفاده می‌شوند، نه تنبیه فرد. وابستگی به یک متخصص bus factor خطرناک می‌سازد.

پرسش‌های ۱۲۶ تا ۱۳۰: فرهنگ و رویه‌های DevOps#

۱۲۶. فرهنگ DevOps چیست؟#

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

گفتن «همه مسئول‌اند» بدون مرز مسئولیت می‌تواند به بی‌مالکی برسد. service owner، platform owner و security نقش‌های روشن دارند، ولی هدف و داده را مشترک می‌بینند. تیمی که بابت هر شکست تنبیه می‌شود تغییر را پنهان می‌کند؛ تیمی که هیچ استانداردی ندارد نیز قابل اعتماد نیست. امنیت روانی با پاسخ‌گویی منافات ندارد: تصمیم و سیستم بررسی می‌شوند و اقدام مشخص پیگیری می‌شود.

۱۲۷. بهترین رویه‌های DevOps چیست؟#

پاسخ کوتاه: تغییر کوچک و پرتکرار، CI قابل اعتماد، artifact نسخه‌دار، IaC و automation، محیط قابل تکرار، observability، security در چرخه، rollback آزموده و یادگیری از incident پایه‌های رایج‌اند.

این‌ها نسخهٔ آماده نیستند. bottleneck فعلی را اندازه بگیرید و یک بهبود را با نتیجهٔ کاربر بسنجید. افزایش deploy بدون test و کاهش lead time با حذف review می‌تواند آسیب بزند. platform self-service باید guardrail و golden path داشته باشد، نه ticket تازه با ظاهر جدید. مستندسازی تصمیم و ownership، نگه‌داری dependency و محدودکردن work in progress نیز اغلب از خرید ابزار تازه اثر بیشتری دارند.

۱۲۸. blameless culture چیست؟#

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

Blameless به معنی نبود مسئولیت، نادیده‌گرفتن رفتار عمدی یا حذف استاندارد حرفه‌ای نیست. فرد می‌تواند owner اقدام اصلاحی باشد بدون اینکه «علت حادثه» نامیده شود. پرسش‌های بهتر عبارت‌اند از: چه signalی دیده می‌شد؟ چرا اقدام منطقی به نظر رسید؟ چه کنترل و بازبینی‌ای غایب بود؟ اگر فقط نام فرد حذف شود ولی لحن و پیامد تنبیهی بماند، فرهنگ تغییر نکرده است.

۱۲۹. knowledge sharing چیست؟#

پاسخ کوتاه: اشتراک دانش تبدیل تجربهٔ فردی به توان قابل استفادهٔ تیم از طریق مستندات، review، pairing، demo، runbook، postmortem و rotation است. هدف کاهش bus factor و سرعت‌دادن به تصمیم درست است.

انباشت صفحه‌ها در wiki کافی نیست. سند باید owner، مخاطب، تاریخ بازبینی و راه آزمون داشته باشد و نزدیک جریان کار پیدا شود. runbook با اجرای game day تازه می‌ماند. recording جلسه مکمل متن جست‌وجوپذیر است، نه جای آن. تصمیم معماری با context و گزینه‌های ردشده ثبت شود. زمان یادگیری باید در ظرفیت تیم دیده شود؛ اگر همیشه بعد از کار اصلی باشد، انجام نمی‌شود.

۱۳۰. team collaboration در DevOps چیست؟#

پاسخ کوتاه: همکاری تیمی یعنی توسعه، عملیات، امنیت، محصول و سایر نقش‌ها هدف، interface و بازخورد مشترک برای تحویل و بهره‌برداری داشته باشند. همکاری مالکیت را حذف نمی‌کند؛ handoff و انتظار را شفاف می‌کند.

جلسهٔ بیشتر الزاماً همکاری بهتر نیست. API، template، service catalog و automated check می‌توانند هماهنگی تکراری را self-service کنند. برای تغییر پرخطر، review چندتخصصی زودهنگام از تأیید انتهای pipeline بهتر است. chat باید به issue یا تصمیم پایدار پیوند بخورد. سنجه‌های مشترک مانند SLO و lead time رفتار هم‌راستا می‌سازند؛ KPI متضاد—سرعت برای یک تیم و صفر تغییر برای دیگری—صف و تعارض می‌سازد.

جمع‌بندی مصاحبه‌ای#

در incident ابتدا impact را کم کنید، سپس عمیق یاد بگیرید. در فرهنگ نیز به رفتار قابل مشاهده و سازوکار اشاره کنید، نه صفت‌های کلی. rotation، postmortem، SLO و review نمونه‌هایی‌اند که نشان می‌دهند اعتماد و پاسخ‌گویی چگونه در کار روزانه اجرا می‌شوند.

منابع#