مک پس از بیداری با VPN فریز می‌شود: چه چیزی ثبت کنیم
فریز پس از بیداری می‌تواند کل میزکار، کلاینت یا یک برنامه در انتظار باشد. مشخص کنید چه چیزی از کار افتاده و سپس گزارشی متناسب با همان نشانه بگیرید.
گزارش‌های مک فریزشده پس از بیداری اغلب سه خرابی را در یک شکایت جمع می‌کنند. ممکن است نشانگر هنوز حرکت کند در حالی که کلاینت VPN کلیک‌ها را نادیده می‌گیرد، کلاینت کار کند در حالی که یک نشست راه دور منقضی می‌شود، یا کل میزکار از پذیرش ورودی باز بماند. هر یک از این‌ها شواهد متفاوتی می‌خواهد و دقیقه اول پس از فریز تعیین می‌کند کدام را می‌بینید. حدس نادرست هر گام بعدی را به جهت اشتباه می‌فرستد.
چه چیزی پاسخ دادن را متوقف کرد و چه چیزی فقط انتظار را متوقف کرد
با ارزان‌ترین آزمون‌ها شروع کنید: نشانگر را حرکت دهید و در یک فیلد متنی محلی تایپ کنید، نمای وضعیت خود کلاینت را باز کنید و وضعیتی را که گزارش می‌دهد بخوانید، سپس به‌جای از سر گرفتن نشستی که از قبل باز بود، عملیات تازه‌ای در برنامه خصوصی شروع کنید. سه پاسخ را قبل از دست زدن به هر چیز دیگر بنویسید، چون ترتیب آنچه از کار افتاد اولین جزئیاتی است که مردم فراموش می‌کنند.
هر نتیجه به جایی متفاوت اشاره می‌کند. یک نشست گیرکرده شواهد را به آن سوی تونل می‌برد و مک فقط تماشاگر است. کلاینتی که کلیک‌ها را نادیده می‌گیرد در حالی که میزکار هنوز کار می‌کند، جست‌وجو را به همان فرایند و گزارش آن محدود می‌کند. دستگاهی که نشانگر را نادیده می‌گیرد امکان اجرای هر چیزی را برمی‌دارد، چون هر فرمان بازرسی به پوسته‌ای نیاز دارد که پاسخ دهد.
سه مورد را جدا نگه دارید حتی وقتی کاربر آن‌ها را با یک جمله توصیف می‌کند. گزارشی که ثبت می‌کنید باید بگوید کدام آزمون اول شکست خورد و کدام‌ها هنوز موفق بودند، نه اینکه دستگاه فریز شد. همین تمایز به مهندس پشتیبانی اجازه می‌دهد تصمیم بگیرد به شبکه، کلاینت یا سخت‌افزار نگاه کند.
گاه‌شماره‌ای که فردا هم می‌توانید از آن دفاع کنید
ساعت بخشی از ثبت است که بعداً بازسازی نمی‌شود. یادداشت کنید درپوش چه زمانی باز شد یا دستگاه بیدار شد، اولین اقدام ناموفق چه زمانی رخ داد، و آیا آن دو لحظه ثانیه‌ها یا دقیقه‌ها فاصله داشتند. سپس بنویسید مک واقعاً خوابید یا فقط صفحه را قفل کرد، چون این‌ها وضعیت‌های متفاوتی با مسیرهای بیداری متفاوت هستند. گزارش خواب تنها بخشی از آن گاه‌شماره است که بعداً می‌توانید بررسی کنید.
pmset -g log | grep -i -E 'wake|sleep'
log show --last 15m --predicate 'process == "<client-process>"' --style compactفرمان اول خاطره‌ای مبهم را به برچسب زمانی تبدیل می‌کند که می‌توانید در دومی تایپ کنید. پرس‌وجوی گزارش را به فرایند کلاینت و پنجره‌ای کوتاه محدود کنید تا به‌جای یک روز کامل، یک صفحه خروجی بگیرید. شناسه مدل، ساخت کلاینت و شبکه‌ای که در آن بودید را همان‌جا در همان یادداشت کپی کنید تا صفحه هنوز جلوی شماست؛ گزارشی که صبح روز بعد جمع شود ترتیبی را که آن را خوانا می‌کرد از دست می‌دهد.
ضبطی را انتخاب کنید که با نشانه می‌خواند
اپل سه ضبط را در راهنمای عیب‌یابی Activity Monitor مستند کرده است و هر کدام به پرسشی متفاوت پاسخ می‌دهند. Sample Process یک فرایند انتخابی را سه ثانیه می‌پاید، spindump برنامه‌ای را هدف می‌گیرد که پاسخ دادن را متوقف کرده و به‌زودی به‌اجبار بسته می‌شود، و System Diagnostics گزارش‌های سیستم را در یک بسته جمع می‌کند.
بر اساس آنچه مشاهده کردید انتخاب کنید، نه بر اساس عادت. کلاینتی که کار می‌کند اما بدرفتاری می‌کند یک sample می‌گیرد، که با sample <pid> 3 -file ~/Desktop/sample.txt یا از منوی چرخ‌دنده گرفته می‌شود. برنامه‌ای که بی‌پایان می‌چرخد و باید کشته شود، آیتم Spindump را از همان منو می‌گیرد. مشکلی که کلاینت و سیستم را در بر می‌گیرد sudo sysdiagnose -f ~/Desktop می‌گیرد. اگر می‌توانید قبل از بستن اجباری sample بگیرید، چون خاتمه دقیقاً همان وضعیتی را نابود می‌کند که می‌خواستید بررسی کنید، و فایل را به نام رویداد و زمان نام‌گذاری کنید نه بر اساس حدس‌تان درباره علت.
هر بسته را حساس در نظر بگیرید. این گزارش‌ها نام حساب‌ها، نام میزبان‌ها، مسیرها و جزئیات شبکه را حمل می‌کنند، پس آن‌ها را از کانال پشتیبانی سازمان خود بفرستید نه با پیوست کردن به یک رشته عمومی. اگر گزارشی باید کوتاه شود، یک نسخه را کوتاه کنید و اصل را دست‌نخورده نگه دارید.
وقتی خود نشانگر حرکت نمی‌کند
رابط مرده ترتیب عملیات را تغییر می‌دهد. نمی‌توانید از پوسته‌ای که پاسخ نمی‌دهد نمونه‌ای از فرایند بگیرید یا پرس‌وجویی اجرا کنید، پس هدف اول بازیابی است و هدف دوم ثبت. راه‌اندازی مجدد اجباری گاهی تنها راه خروج است و همان لحظه‌ای است که سودمندترین جزئیات ناپدید می‌شوند. زمان، پنجره‌های باز و اینکه منوی شبکه قبل از راه‌اندازی مجدد اتصال نشان می‌داد را یادداشت کنید؛ این مشاهدات از راه‌اندازی مجدد جان سالم به در می‌برند هرچند وضعیت فرایند نه.
وقتی دستگاه برگشت، در برابر این نتیجه‌گیری مقاومت کنید که راه‌اندازی مجدد مقصر را پیدا کرده است. سرویس را بازگرداند و چیزی نام نبرد. فقط تکرار با یک تغییر کنترل‌شده می‌تواند به یک مؤلفه اشاره کند.
اگر فریز برگشت، هر بار یک شرط را تغییر دهید: شبکه، نسخه کلاینت یا حالت خواب. اول کار راه دور را ذخیره کنید و از تکرار خواب‌های اجباری روی دستگاه تولیدی بپرهیزید، چون چرخه‌های سخت مکرر خطر از دست رفتن داده را دارند و اغلب خرابی متفاوتی از آنچه دنبالش هستید می‌سازند. هر تلاش را با شرایطش بنویسید تا تلاش بعدی قابل مقایسه باشد نه حکایت.
یک رویداد را تحویل دهید، نه یک حال‌وهوا
تحویلی که به اقدام می‌رسد چهار چیز را نام می‌برد: چه چیزی پاسخ دادن را متوقف کرد، چه زمانی رخ داد، شبکه در آن لحظه چگونه بود، و کدام ضبط آن بازه را پوشش می‌دهد. نسخه کلاینت و ساخت macOS را اضافه کنید و سپس متوقف شوید. هم تیم پلتفرم و هم فروشنده کلاینت می‌توانند بر پایه آن جمله عمل کنند و هیچ‌کدام نمی‌توانند بر پایه توصیف ناکامی عمل کنند. ثبت را در یک جا نگه دارید و به آن بیفزایید به‌جای اینکه هر بار داستان را از نو بگویید؛ اگر به‌روزرسانی رفتار را تغییر داد، بنویسید کدام، چون آن هم شواهد است.
ثبت خوب همچنین می‌گوید چه چیزی را قبلاً کنار گذاشته‌اید. اگر برنامه‌ای محلی در طول فریز پاسخ داد، بگویید؛ اگر گزارش خواب بیداری واقعی نشان می‌دهد نه قفل، آن را هم بگویید. نفر بعدی نباید آزمون‌هایی را که قبلاً انجام داده‌اید تکرار کند.
قبل از بستن تیکت، سه چیز را بررسی کنید: برچسب زمان از گزارش خواب می‌آید نه از حافظه، ضبط با نشانه‌ای که واقعاً دیدید می‌خواند، و بسته در محل تأییدشده قرار دارد. اگر هر یک از این سه نبود، گزارش آماده ارسال نیست.