وقتی چیزی خراب میشود چه چیزی باید ثبت شود
بیشتر گزارشهای دستگاه را کسی مینویسد که فریمور را نوشته و کسی میخواند که زیر باران ایستاده. آنچه واقعا کمک میکند و آنچه باید کنار گذاشت.
دستگاهی در میدان خراب میشود. کسی راه میافتد، لپتاپ را وصل میکند، گزارش را باز میکند و چهار هزار سطر میبیند: راهاندازی موفق، ضربان، ضربان، ضربان. هیچ چیز درباره خرابی. تنها رویدادی که اهمیت داشت سه روز پیش رد شد و رویش نوشته شد.
این رخ میدهد چون ثبت رویداد معمولا در جریان توسعه نوشته میشود، به دست کسی که مسئلهای مشخص را روی میز اشکالزدایی میکرده، و بعد هرگز بازبینی نمیشود. پیامهایی که به تولید میرسند همانهاییاند که یک بار، برای یک نفر، در وضعیتی که دیگر وجود ندارد سودمند بودند.
از سر دیگر شروع کنید. بپرسید وقتی این دستگاه بدرفتاری کند، آدمی به پاسخ چه پرسشهایی نیاز دارد، و از آنجا به عقب تا ورودیهایی بیایید که پاسخشان میدهند. در عمل حدود شش پرسشاند: برق داشت، تمیز راه افتاد، شبکه را میدید، حسگر را میدید، چه اندازه گرفت، و تصمیم گرفت چه کند. اگر گزارش شما این شش را برای یک ماه گذشته پاسخ میدهد، گزارش خوبی است. اگر هیچکدام را پاسخ نمیدهد و هر تکرار موفق حلقه را ثبت میکند، فایل بسیار بزرگی است.
برق اول میآید چون بیش از هر چیز دیگری خرابیها را توضیح میدهد. دلیل هر ریست را ثبت کنید — سگ نگهبان، افت ولتاژ، بیرونی، نرمافزاری، روشن شدن — چون همین یک میدان، گیر کردن فریمور را از تغذیه بیثبات و از کسی که کلید را قطع و وصل کرده جدا میکند، و این سه درمانهای یکسره متفاوتی دارند. دستگاهی که نمیتواند بگوید چرا دوباره راه افتاده، فریمورش به جای خطای سیمکشی متهم خواهد شد، احتمالا بیش از یک بار.
سپس گذارها را ثبت کنید نه حالتها. «لینک بالا» و «لینک پایین» با برچسب زمان میگویند شبکه شب گذشته یازده بار پرید. «لینک بالاست» هر سی ثانیه همان را میگوید، دفنشده در ۲۸۸۰ سطر، و فقط اگر کسی آنقدر صبور باشد که شکافها را ببیند. همین درباره حسگرها هم هست: ثبت کنید کی خوانشی از بازه بیرون رفت و کی برگشت، نه هر خوانش را. خوانشها به مسیر داده تعلق دارند؛ گزارش برای رویدادهاست.
برچسب زمان باید از قطع برق جان به در ببرد، و این همان جزئیاتی است که بیش از همه جا میماند. دستگاهی بدون ساعت پشتیباندار از مبدا تاریخ شروع میکند و کل حادثهاش را در ۱۹۷۰ ثبت میکند، که همبسته کردنش با هر چیز دیگری را ناممکن میسازد. اگر ساعت بیدرنگ نیست، زمان کارکرد یکنواخت را کنار هر زمان دیواری موجود ثبت کنید، و لحظهای را که ساعت از شبکه تنظیم میشود بنویسید. دستکم آنوقت کسی میتواند توالی را بازسازی کند.
دو چیز را کنار بگذارید. رازها، آشکارا — کلید، توکن، گذرواژه، محتوای یک گواهی — چون گزارشها ایمیل میشوند، در سامانههای تیکت چسبانده میشوند و روی لپتاپها میمانند. و داده شخصی، به همان دلیل بهعلاوه دلیل حقوقی. شگفتآور است که چند بار دستگاهی کل بار پیکربندی را با همان اعتبارنامهای که تازه به کار برده ثبت میکند.
سازوکار به اندازه محتوا اهمیت دارد. از سطوح استفاده کنید و کاری کنید معنای ثابتی داشته باشند، تا تکنسین بتواند روی خطاها فیلتر کند و خطا بگیرد نه ترکیبی از خطا و پرحرفی. فایل را بچرخانید تا نتواند حافظه را پر کند و دستگاه را از کار بیندازد، که خرابی واقعی و رایجی است. اندازه کل را سقف بگذارید. و به نگه داشتن دو گزارش فکر کنید: یک بافر حلقوی پرجزئیات برای چند ساعت گذشته، و سابقهای کوچک و دائمی از رویدادهای مهم — ریست، تغییر پیکربندی، بهروزرسانی فریمور، خروج از بازه — که ماهها بماند.
آخر آنکه، بازیابیاش را بینیاز از بازدید سایت کنید. گزارشی که برای خواندنش باید فیزیکی به دستگاه وصل شد، از پیش بیش از آنچه صرفهجویی میکند هزینه برده است. توانایی کشیدن چند صد رویداد آخر از شبکه، یا اینکه دستگاه پس از وصل شدن دوباره خودش بفرستدشان، همان تفاوت تشخیص یک خطا از پشت میز و فرستادن کسی به دویست کیلومتری برای آوردن یک فایل متنی است.