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