با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
اثر و Urgency را بسنج
اثر میزان اثر رخداد یا تغییر روی کاربران و فرایند کسبوکار است؛ تعداد کاربر تنها معیار نیست؛ اهمیت سرویس و وجود راه جایگزین هم مهم است اثر را با احساس فوریت فرد گزارشدهنده یکی ندان در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که وقتی چند مشکل همزمان ارائه میشوند، اولویت را بر اساس اثر کسبوکار، امنیت و گستره خرابی تعیین کن؛ سپس کار را به واحدهای قابل کنترل تقسیم کن؛ پس از رفع هر مورد، Validation و Closure انجام بده و اگر Fix موقت است آن را صریح ثبت کن تا بهعنوان حل دائمی فراموش نشود
امنیت و از دست رفتن داده اولویت دارند
از دست رفتن داده اولویت بالایی دارد چون ممکن است بازگشتپذیر نباشد؛ قبل از هر اقدام مخرب احتمال حفظ یا بازیابی داده را بررسی کن راهنمای CISA و NIST بر چند پایه تکرارشونده تأکید دارد: استفاده از MFA برای حسابهای مهم، بهروزرسانی منظم، محدود کردن دسترسی مدیریتی، نگهداری Backup قابل بازیابی، ثبت رویدادها و آموزش مقابله با فیشینگ؛ در رخداد مشکوک، هدف اول حفظ شواهد و محدود کردن دامنه اثر است، نه انجام تغییرهای متعدد و بدون ثبت؛ حسابهای مدیریتی باید از حساب روزمره جدا باشند و سطح دسترسی فقط به اندازه نیاز کاری داده شود در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد
اقدام سریع کمریسک را از تغییر پرریسک جدا کن
اقدام سریع کمریسک کاری کمریسک و سریع با اثر روشن است؛ نباید فقط برای گرفتن نتیجه فوری، تغییر پرریسک را بهاشتباه اقدام سریع کمریسک بنامیم در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمانبندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود میتواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگیها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفهای است
وابستگی ترتیب کار را تغییر میدهد
وابستگی یعنی یک سرویس یا برنامه برای کار کردن به جزء دیگری نیاز دارد؛ توقف جزء پایه میتواند چند سرویس ظاهراً نامرتبط را همزمان خراب کند در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمانبندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود میتواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگیها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفهای است
معیار موفقیت تعریف کن
معیار موفقیت از قبل مشخص میکند بعد از کار چه چیزی باید سالم باشد؛ مثلاً کاربر وارد شود، Ping کافی نیست اگر نرمافزار هنوز خطا دارد قبل از شروع هر رخداد بنویس چه نتیجهای نشان میدهد کار تمام شده است؛ این معیار میتواند Login موفق، دسترسی File، Restore سالم یا Latency قابل قبول باشد در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که در آزمون نهایی باید همان مدل کاری محیط واقعی را بهکار ببری: Asset و Dependency را بشناس، Scope رخداد را محدود کن، Evidence جمع کن، فرضیه بساز، Test کمریسک انجام بده و نتیجه را مستند کن؛ پاسخ درست فقط رسیدن اتفاقی به Fix نیست و باید بتوانی توضیح دهی چرا آن اقدام با شواهد سازگار بود
فرض کن در شرکت مجازی آزمون نهایی مشکلی گزارش شده و احتمال میدهی به اولویتبندی مشکلات و برنامه کار مربوط باشد. قبل از تغییر، وضعیت فعلی را با ابزارها و روشهای کل دوره بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- اقدام سریع کمریسک کاری کمریسک و سریع با اثر روشن است؛ نباید فقط برای گرفتن نتیجه فوری، تغییر پرریسک را بهاشتباه اقدام سریع کمریسک بنامیم
- معیار موفقیت از قبل مشخص میکند بعد از کار چه چیزی باید سالم باشد؛ مثلاً کاربر وارد شود، Ping کافی نیست اگر نرمافزار هنوز خطا دارد
- تغییر دادن تنظیمات مرتبط با اولویتبندی مشکلات و برنامه کار قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با اولویتبندی مشکلات و برنامه کار، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با ابزارها و روشهای کل دوره وضعیت مرتبط با اولویتبندی مشکلات و برنامه کار را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با اولویتبندی مشکلات و برنامه کار بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- اثر و Urgency را بسنج
- امنیت و از دست رفتن داده اولویت دارند
- اقدام سریع کمریسک را از تغییر پرریسک جدا کن
- وابستگی ترتیب کار را تغییر میدهد
- معیار موفقیت تعریف کن
- هیچ اقدام پرریسک بدون شواهد، Backup یا روش بازگشت قابل قبول نیست
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: اثر و Urgency را بسنج. بعد بگو در عمل چطور آن را بررسی میکنی.
اثر میزان اثر رخداد یا تغییر روی کاربران و فرایند کسبوکار است؛ تعداد کاربر تنها معیار نیست؛ اهمیت سرویس و وجود راه جایگزین هم مهم است
این نکته را با یک مثال توضیح بده: امنیت و از دست رفتن داده اولویت دارند. بعد بگو در عمل چطور آن را بررسی میکنی.
از دست رفتن داده اولویت بالایی دارد چون ممکن است بازگشتپذیر نباشد؛ قبل از هر اقدام مخرب احتمال حفظ یا بازیابی داده را بررسی کن
چرا باید اقدام سریع کمریسک را از تغییر پرریسک جدا کنی و از کجا میفهمی نتیجه درست است؟
اقدام سریع کمریسک کاری کمریسک و سریع با اثر روشن است؛ نباید فقط برای گرفتن نتیجه فوری، تغییر پرریسک را بهاشتباه اقدام سریع کمریسک بنامیم
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
