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