با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
پیام اول سرویس و زمان شروع را بگوید
در پیام اولیه رخداد بگو کدام سرویس تحت تأثیر است، از چه زمانی مشکل دیده شده و تیم در حال بررسی است؛ علت تأییدنشده را حدس نزن برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، ارتباط حرفهای با مشتری یعنی مسئله فنی را بدون تحقیر، ابهام یا وعده غیرواقعی توضیح بدهی؛ ابتدا نشانه را با زبان خود کاربر بشنو، سپس سؤالهای مشخص درباره زمان، دامنه و تغییر اخیر بپرس؛ هنگام توضیح، اصطلاح فنی را فقط جایی استفاده کن که به تصمیم یا اقدام کمک میکند و در صورت استفاده معنای ساده آن را هم روشن کن در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که در طول رخداد، حتی نبود نتیجه نهایی هم باید مدیریت شود؛ زمان بهروزرسانی بعدی، کاری که در حال بررسی است و محدودیت فعلی را واضح بگو؛ بعد از رفع مشکل از کاربر بخواه نتیجه را در همان سناریویی که مشکل داشت تأیید کند و Closure را با خلاصه اقدام و راه پیشگیری در صورت وجود ثبت کن برای کامل شدن تصویر این موضوع، این درس بخشی از مدل کاری یک کارشناس پشتیبانی است و هدف آن فقط شناخت یک اصطلاح نیست؛ باید بتوانی موضوع را در یک شرکت واقعی تشخیص بدهی، اثر آن را روی کاربر و سرویس بفهمی، شواهد درست جمع کنی و بدون تغییرهای عجولانه تصمیم بگیری؛ هنگام مطالعه تلاش کن هر مفهوم را به یک مثال از محیط کار، یک نشانه قابل مشاهده و یک روش بررسی امن وصل کنی
علت تأییدنشده را حدس نزن
در رخداد بزرگ گفتن علت اشتباه اعتماد را کم میکند؛ تا وقتی شواهد کافی نداری وضعیت را با عبارتهایی مثل «در حال بررسی» یا «علت هنوز تأیید نشده» گزارش کن برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که در طول رخداد، حتی نبود نتیجه نهایی هم باید مدیریت شود؛ زمان بهروزرسانی بعدی، کاری که در حال بررسی است و محدودیت فعلی را واضح بگو؛ بعد از رفع مشکل از کاربر بخواه نتیجه را در همان سناریویی که مشکل داشت تأیید کند و Closure را با خلاصه اقدام و راه پیشگیری در صورت وجود ثبت کن در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که ارتباط حرفهای با مشتری یعنی مسئله فنی را بدون تحقیر، ابهام یا وعده غیرواقعی توضیح بدهی؛ ابتدا نشانه را با زبان خود کاربر بشنو، سپس سؤالهای مشخص درباره زمان، دامنه و تغییر اخیر بپرس؛ هنگام توضیح، اصطلاح فنی را فقط جایی استفاده کن که به تصمیم یا اقدام کمک میکند و در صورت استفاده معنای ساده آن را هم روشن کن
Update دورهای بده
در رخداد بزرگ حتی اگر علت هنوز پیدا نشده، Update کوتاه درباره اثر، کار در حال انجام و زمان پیام بعدی بده؛ سکوت طولانی اضطراب و تماسهای تکراری ایجاد میکند اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، در طول رخداد، حتی نبود نتیجه نهایی هم باید مدیریت شود؛ زمان بهروزرسانی بعدی، کاری که در حال بررسی است و محدودیت فعلی را واضح بگو؛ بعد از رفع مشکل از کاربر بخواه نتیجه را در همان سناریویی که مشکل داشت تأیید کند و Closure را با خلاصه اقدام و راه پیشگیری در صورت وجود ثبت کن برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که ارتباط حرفهای با مشتری یعنی مسئله فنی را بدون تحقیر، ابهام یا وعده غیرواقعی توضیح بدهی؛ ابتدا نشانه را با زبان خود کاربر بشنو، سپس سؤالهای مشخص درباره زمان، دامنه و تغییر اخیر بپرس؛ هنگام توضیح، اصطلاح فنی را فقط جایی استفاده کن که به تصمیم یا اقدام کمک میکند و در صورت استفاده معنای ساده آن را هم روشن کن
راهحل موقت را اعلام کن
اگر راهحل موقت امنی وجود دارد واضح بگو چه کسی میتواند از آن استفاده کند و چه محدودیتی دارد؛ راهحل موقت را با رفع کامل اشتباه نگیر نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که در طول رخداد، حتی نبود نتیجه نهایی هم باید مدیریت شود؛ زمان بهروزرسانی بعدی، کاری که در حال بررسی است و محدودیت فعلی را واضح بگو؛ بعد از رفع مشکل از کاربر بخواه نتیجه را در همان سناریویی که مشکل داشت تأیید کند و Closure را با خلاصه اقدام و راه پیشگیری در صورت وجود ثبت کن برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، ارتباط حرفهای با مشتری یعنی مسئله فنی را بدون تحقیر، ابهام یا وعده غیرواقعی توضیح بدهی؛ ابتدا نشانه را با زبان خود کاربر بشنو، سپس سؤالهای مشخص درباره زمان، دامنه و تغییر اخیر بپرس؛ هنگام توضیح، اصطلاح فنی را فقط جایی استفاده کن که به تصمیم یا اقدام کمک میکند و در صورت استفاده معنای ساده آن را هم روشن کن برای کامل شدن تصویر این موضوع، این درس بخشی از مدل کاری یک کارشناس پشتیبانی است و هدف آن فقط شناخت یک اصطلاح نیست؛ باید بتوانی موضوع را در یک شرکت واقعی تشخیص بدهی، اثر آن را روی کاربر و سرویس بفهمی، شواهد درست جمع کنی و بدون تغییرهای عجولانه تصمیم بگیری؛ هنگام مطالعه تلاش کن هر مفهوم را به یک مثال از محیط کار، یک نشانه قابل مشاهده و یک روش بررسی امن وصل کنی
پیام پایان وضعیت پایدار را بگوید
پیام پایان رخداد باید بگوید سرویس از چه زمانی پایدار است، آیا اقدامی از کاربر لازم است و آیا بررسی علت اصلی ادامه دارد نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که در طول رخداد، حتی نبود نتیجه نهایی هم باید مدیریت شود؛ زمان بهروزرسانی بعدی، کاری که در حال بررسی است و محدودیت فعلی را واضح بگو؛ بعد از رفع مشکل از کاربر بخواه نتیجه را در همان سناریویی که مشکل داشت تأیید کند و Closure را با خلاصه اقدام و راه پیشگیری در صورت وجود ثبت کن برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، ارتباط حرفهای با مشتری یعنی مسئله فنی را بدون تحقیر، ابهام یا وعده غیرواقعی توضیح بدهی؛ ابتدا نشانه را با زبان خود کاربر بشنو، سپس سؤالهای مشخص درباره زمان، دامنه و تغییر اخیر بپرس؛ هنگام توضیح، اصطلاح فنی را فقط جایی استفاده کن که به تصمیم یا اقدام کمک میکند و در صورت استفاده معنای ساده آن را هم روشن کن برای کامل شدن تصویر این موضوع، این درس بخشی از مدل کاری یک کارشناس پشتیبانی است و هدف آن فقط شناخت یک اصطلاح نیست؛ باید بتوانی موضوع را در یک شرکت واقعی تشخیص بدهی، اثر آن را روی کاربر و سرویس بفهمی، شواهد درست جمع کنی و بدون تغییرهای عجولانه تصمیم بگیری؛ هنگام مطالعه تلاش کن هر مفهوم را به یک مثال از محیط کار، یک نشانه قابل مشاهده و یک روش بررسی امن وصل کنی
فرض کن در ارتباط با کاربر یا مشتری مشکلی گزارش شده و احتمال میدهی به اعلام Downtime و رخداد بزرگ مربوط باشد. قبل از تغییر، وضعیت فعلی را با Ticket، یادداشت تماس، ایمیل و سابقه ارتباط بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- در رخداد بزرگ گفتن علت اشتباه اعتماد را کم میکند. تا وقتی شواهد کافی نداری وضعیت را با عبارتهایی مثل «در حال بررسی» یا «علت هنوز تأیید نشده» گزارش کن
- اگر راهحل موقت امنی وجود دارد واضح بگو چه کسی میتواند از آن استفاده کند و چه محدودیتی دارد. راهحل موقت را با رفع کامل اشتباه نگیر
- تغییر دادن تنظیمات مرتبط با اعلام Downtime و رخداد بزرگ قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با اعلام Downtime و رخداد بزرگ، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با Ticket، یادداشت تماس، ایمیل و سابقه ارتباط وضعیت مرتبط با اعلام Downtime و رخداد بزرگ را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با اعلام Downtime و رخداد بزرگ بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- پیام اول سرویس و زمان شروع را بگوید
- علت تأییدنشده را حدس نزن
- Update دورهای بده
- راهحل موقت را اعلام کن
- پیام پایان وضعیت پایدار را بگوید
- چیزی را که هنوز مطمئن نیستی بهعنوان نتیجه قطعی به کاربر اعلام نکن
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: پیام اول سرویس و زمان شروع را بگوید. بعد بگو در عمل چطور آن را بررسی میکنی.
در پیام اولیه رخداد بگو کدام سرویس تحت تأثیر است، از چه زمانی مشکل دیده شده و تیم در حال بررسی است. علت تأییدنشده را حدس نزن
این نکته را با یک مثال توضیح بده: علت تأییدنشده را حدس نزن. بعد بگو در عمل چطور آن را بررسی میکنی.
در رخداد بزرگ گفتن علت اشتباه اعتماد را کم میکند. تا وقتی شواهد کافی نداری وضعیت را با عبارتهایی مثل «در حال بررسی» یا «علت هنوز تأیید نشده» گزارش کن
چرا باید Update دورهای بدهی و از کجا میفهمی نتیجه درست است؟
در رخداد بزرگ حتی اگر علت هنوز پیدا نشده، Update کوتاه درباره اثر، کار در حال انجام و زمان پیام بعدی بده؛ سکوت طولانی اضطراب و تماسهای تکراری ایجاد میکند
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
