مدیریت دستگاههای IoT از یک پنل
ساختن یک دستگاه هوشمند که به اینترنت وصل شود، مسئلهٔ سختی نیست.
مدیریت هزار تای آن، وقتی در سراسر کشور و در دست مشتریانی هستند که شما به آنها دسترسی فیزیکی ندارید، مسئلهٔ کاملاً دیگری است.
و شرکتهایی که وارد این حوزه میشوند، معمولاً برای اولی برنامه دارند و برای دومی نه.
چهار مسئلهای که با مقیاس ظاهر میشوند
۱. ثبت و هویت. دستگاهی که از خط تولید بیرون میآید، چطور خودش را به سامانه معرفی میکند و چطور مطمئن میشوید که واقعاً دستگاه شماست؟
۲. بهروزرسانی از راه دور. باگی در نرمافزار دستگاه پیدا شده. اگر راهی برای بهروزرسانی نداشته باشید، تنها گزینه فراخوان محصول است.
۳. پایش سلامت. کدام دستگاهها آنلایناند، کدامها خطا میدهند، کدامها باتریشان تمام شده.
۴. داده. هزار دستگاه که هر دقیقه یک اندازهگیری میفرستند، روزی یک و نیم میلیون رکورد است. این با پایگاه دادهٔ معمولی و رویکرد معمولی اداره نمیشود.
هویت دستگاه
اصل ساده: هر دستگاه هویت یکتای خودش را دارد و کلید مشترک بین همه، ممنوع است.
اگر همهٔ دستگاهها یک کلید داشته باشند، لو رفتن یکی یعنی لو رفتن همه — و چون دستگاه در دست کاربر است و قابل باز کردن، لو رفتن فقط مسئلهٔ زمان است.
هر دستگاه باید بتواند مستقلاً باطل شود، بدون اینکه بقیه تحت تأثیر قرار بگیرند. و چرخهٔ حیاتش باید تعریفشده باشد: تولید شده، فعال، در گارانتی، بازگشتی، باطل.
تخصیص به مشتری جدا از هویت دستگاه است. دستگاه ممکن است فروخته شود، دست به دست شود، یا به مشتری دیگری منتقل شود — و دادههای قبلی نباید به مالک جدید نشان داده شوند.
بهروزرسانی از راه دور، حیاتی و خطرناک
قابلیتی که نبودش فاجعه است و بدپیادهسازیاش هم.
تدریجی منتشر کنید. اول ده دستگاه، بعد صد، بعد همه. اگر بهروزرسانی معیوبی یکباره روی هزار دستگاه برود، هزار دستگاه از کار افتاده دارید که هیچکدام دیگر بهروزرسانی نمیگیرند.
بازگشت خودکار. دستگاهی که پس از بهروزرسانی بالا نیامد، باید خودش به نسخهٔ قبل برگردد. این را در سطح راهانداز دستگاه پیاده کنید، نه در نرمافزار اصلی — چون نرمافزار اصلی همان چیزی است که خراب شده.
امضای دیجیتال. دستگاه باید فقط بستهای را بپذیرد که با کلید شما امضا شده. بدون این، هر کسی که در مسیر شبکه باشد میتواند نرمافزار خودش را روی دستگاههای شما بنشاند.
قطع وسط کار را فرض بگیرید. برق میرود، شبکه قطع میشود. دستگاه باید بتواند از حالت نیمهکاره سالم بیرون بیاید.
اینها همان اصولی است که در مدیریت انتشار گفتیم، با یک تفاوت مهم: اینجا بازگشت بهصورت دستی ممکن نیست. اگر خودکار نباشد، وجود ندارد.
دادههای زماندار
دادههای حسگری الگوی متفاوتی دارند: نوشتن زیاد، ویرایش تقریباً هیچ، خواندن عمدتاً بهصورت بازهٔ زمانی و تجمیعشده.
سه تصمیمی که هزینه را کنترل میکنند:
تجمیع تدریجی. دادهٔ خام دقیقهای را چند هفته نگه دارید؛ بعد میانگین ساعتی، بعد روزانه. کسی سه سال بعد به اندازهگیری دقیقهٔ فلان نیاز ندارد، اما به روند سالانه نیاز دارد.
سیاست نگهداری، از روز اول. بدون آن، هزینهٔ ذخیرهسازی شما خطی رشد میکند و هیچوقت متوقف نمیشود.
پایگاه دادهٔ مناسب. برای این الگو، پایگاههای دادهٔ سریزمانی بهمراتب کارآمدترند. معیارهای انتخاب را در انتخاب پایگاه داده نوشتهایم.
و فقط چیزی را بفرستید که لازم است. دستگاهی که دمای ثابت را هر ثانیه گزارش میکند، پهنای باند و ذخیرهسازی را برای هیچ مصرف میکند. ارسال بر اساس تغییر — بهعلاوهٔ یک ضربان دورهای برای اثبات زنده بودن — معمولاً حجم را چند برابر کم میکند.
شبکه، در شرایط واقعی
دستگاه در انبار، زیرزمین یا کارگاه است. شبکه ضعیف و قطعوصلشونده است.
بافر روی خود دستگاه. اگر شبکه نبود، داده روی دستگاه بماند و بعد ارسال شود. حافظهٔ دستگاه محدود است، پس سیاست پر شدن بافر را از قبل مشخص کنید: قدیمیترین حذف شود یا جدید ثبت نشود؟ جوابش به کاربرد بستگی دارد و باید تصمیم گرفته شود، نه اینکه اتفاقی باشد.
پروتکل سبک. برای دستگاههای کمتوان، پروتکلهای مخصوص این کار بهمراتب از درخواستهای وب معمولی کمهزینهترند.
زمان دستگاه قابل اعتماد نیست. دستگاهی که برقش رفته و ساعتش صفر شده، داده با زمان غلط میفرستد. هم زمان دستگاه و هم زمان دریافت سرور را ذخیره کنید.
پنل، از دید دو کاربر متفاوت
اینجا اشتباه رایجی هست: ساختن یک پنل برای همه.
مالک دستگاه میخواهد بداند دستگاهش کار میکند، اندازهگیریهایش چیست و اگر مشکلی هست چه باید بکند. ساده، بصری، عمدتاً روی موبایل.
اپراتور شما میخواهد هزار دستگاه را با هم ببیند: کدامها آفلایناند، کدام نسخهها کجا هستند، الگوی خرابی چیست، کدام تولیدی بیشتر برمیگردد.
اینها دو محصولاند با دو دسته نیاز. تلاش برای یکی کردنشان، معمولاً به پنلی ختم میشود که برای هیچکدام خوب نیست.
نمونهٔ این تفکیک را در محک میبینید: مدیریت ترازوها از سمت کاربر و از سمت سازنده، دو تجربهٔ متفاوت روی یک زیرساخت.
هزینهای که با تعداد رشد میکند
نکتهٔ اقتصادی که در مدل کسبوکار باید دیده شود: در نرمافزار معمولی، کاربر بیشتر تقریباً رایگان است. در اینترنت اشیا، هر دستگاه هزینهٔ جاری دارد — اتصال، ذخیرهسازی، پردازش، پشتیبانی.
اگر محصول را یکبار میفروشید و سرویس را برای همیشه میدهید، هر فروش شما را متعهدتر میکند بدون درآمد متناظر. این دقیقاً همان مسئلهای است که در چندمستأجری گفتیم: معماری، سقف مدل قیمتگذاری را تعیین میکند.
پس از ابتدا تصمیم بگیرید: هزینهٔ سرویس در قیمت دستگاه مستهلک میشود، یا اشتراک جداگانهای هست؟ هر دو قابل دفاعاند؛ نداشتن تصمیم نه.
از کجا شروع کنیم
اگر در ابتدای چنین محصولی هستید، این ترتیب کمترین دوبارهکاری را دارد:
۱. هویت یکتای دستگاه و ثبت امن. بدون این، بقیه معنا ندارد. ۲. بهروزرسانی از راه دور، حتی پیش از اولین فروش. اگر بعد از فروش هزار دستگاه اضافه شود، آن هزار تا هرگز آن را نخواهند داشت. ۳. پایش سلامت و هشدار. ۴. جمعآوری داده با سیاست نگهداری. ۵. پنل کاربر و پنل عملیات، جدا.
قدم دوم را جدی بگیرید. تنها قابلیتی در این فهرست است که نمیشود بعداً به دستگاههای فروختهشده اضافه کرد — و همان است که اولین باگ جدی، هزینهاش را به شما نشان میدهد.