یک گره Edge در شعبه فروشگاه سفارش را پذیرفته، رسید را چاپ کرده و موجودی محلی را کم کرده است؛ اما ارتباط با مرکز درست پس از ثبت پرداخت قطع میشود. وقتی شبکه برمیگردد، همان رویداد دو بار ارسال میشود، ساعت دستگاه هفت دقیقه عقب است و نسخه قدیمی نرمافزار هنوز مبلغ را به تومان نمایش میدهد ولی API مرکزی ریال میخواهد. آیا سامانه فقط «آنلاین شد»، یا واقعاً بدون فروش تکراری، گمشدن داده و موجودی نادرست همگرا شد؟
تست رایانش لبه با افزودن چند میلیثانیه Delay به یک API تمام نمیشود. باید رفتار سیستم را در مرز دستگاه، گره محلی، شبکه و ابر بسنجید؛ مشخص کنید هنگام جدایی کدام جزء اختیار تصمیم دارد؛ و بازیابی را تا رسیدن به نتیجهٔ کسبوکاری دنبال کنید. این راهنما یک مسیر عملی از Topology و Latency budget تا Offline sync، OTA، Observability و تصمیم انتشار ارائه میدهد.
رایانش لبه چیست و چه چیزی را تضمین نمیکند؟
در Edge Computing بخشی از پردازش، ذخیرهسازی یا تصمیمگیری نزدیکتر به محل تولید یا مصرف داده اجرا میشود. «نزدیکتر» میتواند روی خود دستگاه، Gateway یک شعبه، سایت منطقهای یا زیرساخت نزدیک شبکه باشد. مدل مفهومی Fog Computing از NIST نیز این معماری را بهصورت مجموعهای توزیعشده و گاه فدرال از گرهها در ارتباط با Cloud توضیح میدهد.
Edge ذاتاً Low latency، امن، ارزان یا قابلاعتماد نیست. پردازش محلی ممکن است مسیر شبکه را کوتاه کند، اما Queue، Cold start، سختافزار ضعیف، ذخیرهساز کند، مسیر اشتباه، Handover یا وابستگی ابری میتواند کل مزیت را از بین ببرد. نگهداشتن داده در محل نیز بهتنهایی امنیت یا حریم خصوصی نمیسازد؛ دستگاه فیزیکی، Interface باز، Secret قدیمی و OTA ناامن سطح حملهٔ تازهای ایجاد میکنند.
اگر موضوع شما کل اکوسیستم Sensor، Firmware، Protocol و Cloud است، راهنمای تست اینترنت اشیا دامنهٔ وسیعتر را پوشش میدهد. این مقاله عمداً روی ریسکهای ویژهٔ اجرای نرمافزار نزدیک منبع داده و مرز Edge–Cloud متمرکز است.
چهار صفحهای که باید جدا دیده شوند
- Data plane: دریافت Sensor/Event، پردازش محلی، پاسخ و انتقال داده؛
- Control plane: Discovery، Routing، Policy، Assignment و هماهنگی Edge–Cloud؛
- Management/update plane: Provisioning، Configuration، Certificate، Firmware/App و Rollback؛
- Observability plane: Log، Metric، Trace، Health، Audit و انتقال شواهد.
ممکن است Data plane هنگام قطع Cloud سالم بماند، ولی Policy جدید یا Telemetry نرسد. نتیجهٔ «فروش محلی موفق بود» نباید به اشتباه «کل سیستم سالم است» تعبیر شود.
مدل تست Edge: از توپولوژی تا تصمیم
برای هر ریسک این زنجیره را کامل کنید:
Topology/Promise → Risk & deadline → Network/device state → Stimulus/fault → Oracle → Evidence/limits → Recovery → Owner/decision
این مدل مانع دو خطای رایج میشود: اجرای Fault بدون دانستن Outcome مورد انتظار، و گزارش نمودار شبکه بدون اثبات نتیجهٔ مشتری. برای پرسشهای عمومیتر دربارهٔ Partition، Concurrency و Eventual Consistency، مرز این مقاله را با تست سیستمهای توزیعشده حفظ کنید.
پیش از ابزار، نقشهٔ توپولوژی بسازید
یک دیاگرام جعبهوخط کافی نیست. نسخهٔ قابلآزمون توپولوژی باید مسیر، اختیار و هویت اجرا را نشان دهد:
| بخش | پرسش لازم | نمونه شاهد |
|---|---|---|
| Device/Sensor/Actuator | چه دادهای میسازد یا چه عمل فیزیکی انجام میدهد؟ | Device ID، Firmware، Sample rate، Calibration |
| Edge node/Gateway | چه تصمیم، Cache، Queue یا تبدیل محلی دارد؟ | App/config/schema version، queue depth، resource limit |
| Network paths | مسیر Primary/Fallback چیست و در هر جهت چگونه فرق میکند؟ | Operator/VPN/APN، DNS، NAT، MTU، RTT profile |
| Regional/Cloud | System of Record کجاست و چه زمانی Authority دارد؟ | API/event contract، database/ledger، reconciliation job |
| Management | Provision، Secret، Policy و Update چگونه میرسد؟ | Fleet cohort، signed artifact، rollout/rollback status |
| Evidence | در قطع ارتباط چه چیزی محلی میماند و چه زمانی Upload میشود؟ | Correlation/Event ID، durable audit، telemetry gap |
برای هر Test Run یک Manifest ثابت از Hardware revision، OS/Firmware، Edge app، Container image، Configuration، Schema، Network profile، Dataset، Clock source و Backend build ذخیره کنید. بدون این هویت، مقایسهٔ دو نمودار یا بازتولید خطا قابلاعتماد نیست. اصول ساخت محیط Fit-for-Purpose و کنترل Drift در راهنمای مدیریت محیط تست تشریح شده است.
قرارداد اختیار در حالتهای اتصال
واژهٔ «Offline support» مبهم است. سامانه باید برای هر حالت Connection، مجاز و غیرمجاز بودن عمل، محل ثبت و شیوهٔ بازگشت را مشخص کند.
| حالت | نشانهٔ ورود | رفتار مجاز | Oracle خروج |
|---|---|---|---|
| Connected | Health و مسیر اصلی در بودجهاند | عمل عادی و Sync نزدیکبهآن | ثبت محلی و مرکزی با یک Event ID |
| Degraded | Tail latency/Loss از آستانه گذشته | کاهش payload، Batch یا مسیر جایگزین | Deadline حیاتی حفظ و افت قابلیت اعلام شود |
| Disconnected | Heartbeat/Dependency طبق Contract ناموجود است | فقط عملهای دارای Authority محلی | داده Durable و وضعیت آفلاین برای کاربر روشن باشد |
| Reconnecting | مسیر برگشته ولی Backlog باقی است | Sync کنترلشده، Dedup و Reconcile | همگرایی در زمان محدود، بدون Duplicate یا Starvation |
| Quarantined | Identity/Schema/Integrity نامعتبر است | توقف اثر خطرناک و حفظ Evidence | تصمیم مالک و Recovery امن |
اتصال یک Boolean ساده نیست. برای نمونه، EdgeHub در معماری KubeEdge با Heartbeat وضعیت ارتباط Cloud–Edge را منتشر میکند و برای پیام Sync انتظار و Timeout دارد. این یک مثال پیادهسازی است، نه Contract آماده برای هر محصول؛ زمان Heartbeat، False positive و رفتار ماژولها باید در سیستم شما آزموده شود.
نیاز تأخیر را از Deadline کسبوکار استخراج کنید
«Latency کم» Requirement نیست. بنویسید کدام Journey، از کدام نقطه تا کدام نقطه، برای چه Cohort و چه درصدی از رخدادها باید در چه Deadline کامل شود. تأخیر نمایش وضعیت موجودی با تأخیر توقف یک عملگر صنعتی یک ریسک ندارد.
بودجهٔ End-to-End را خرد کنید
یک بودجهٔ ساده میتواند چنین باشد:
T_total = T_capture + T_queue + T_serialize + T_network + T_process + T_dependency + T_persist + T_actuate
هر جزء نقطهٔ اندازهگیری و Owner میخواهد. اگر فقط زمان API مرکزی را بسنجید، تأخیر Sensor، Queue محلی، Batch، Disk flush و Actuation پنهان میماند. اندازهٔ Payload، جهت جریان، پروتکل، مسیر، تعداد Hop، TLS session، Cache state و بار دستگاه نیز بخشی از Context نتیجهاند.
میانگین کافی نیست
p50 رفتار معمول را نشان میدهد؛ p95/p99 دم توزیع را آشکار میکند؛ Max به Outlier و اندازهٔ نمونه حساس است. علاوه بر Percentileها، نسبت Miss شدن Deadline و تعداد رخدادهای معتبر را گزارش کنید:
Timely-action ratio = valid actions completed within deadline / all valid actions
مبانی طراحی Workload، Tail latency، Goodput و Saturation در راهنمای تست عملکرد آمده است. برای Edge، نتایج را حداقل به تفکیک Hardware cohort، Network profile، Firmware/App version و مسیر Primary/Fallback برش دهید.
اندازهگیری One-way، RTT و Delay variation
One-way delay برای مسیرهای نامتقارن مفید است، اما Timestamp دو سر و Clock synchronization دقیق میخواهد. RFC 7679 Metric تأخیر یکطرفه را با پارامترهای Source، Destination، زمان و نوع Packet صورتبندی میکند و بر خطا/عدمقطعیت اندازهگیری تأکید دارد. اگر Clockها بهاندازهٔ نیاز هماهنگ نیستند، RTT را با یک Clock بسنجید و آن را بهجای One-way جا نزنید.
برای Loss نیز Timeout بخشی از تعریف است؛ Packet خیلی دیر ممکن است «گمشده» طبقهبندی شود. RFC 7680 میخواهد Type-P، آستانهٔ انتظار، همگامی ساعت و محدودیت ابزار اندازهگیری گزارش شوند. بنابراین عبارت «۲٪ Packet loss» بدون Protocol، Payload، direction، sample size، duration و threshold شاهد کامل نیست.
Jitter در ابزارها معانی متفاوت دارد. RFC 3393 اصطلاح دقیقتر IP Packet Delay Variation را تفاوت تأخیر یکطرفهٔ Packetهای انتخابشده تعریف میکند. در Test Contract مشخص کنید variation را چگونه محاسبه میکنید؛ نام نمودار بهتنهایی تعریف نیست.
Network Profile قابلبازتولید طراحی کنید
پروفایل را از Trace و مشاهدهٔ واقعیِ مجاز بسازید، سپس برای پوشش مرزها گسترش دهید. فقط یک Delay ثابت، رفتار شبکهٔ سیار را نمایندگی نمیکند.
- Base latency و Delay variation در هر جهت؛
- Random loss و Burst loss با طول Burst؛
- Bandwidth، Queue limit و شکل Burst ترافیک؛
- Duplicate، Reorder و Corruption در پروتکلهای مرتبط؛
- Hard outage، Silent blackhole، Half-open و Network partition؛
- DNS failure/slow response، TLS handshake و Certificate expiry؛
- NAT rebinding، MTU/fragmentation و Handover بین مسیرها؛
- مدت Fault، زمان شروع، Seed و Ramp بازگشت.
هر Fault باید با failure mechanism محصول مرتبط باشد. Corruption در لایهای که TLS آن را رد میکند، Oracle متفاوتی از Payload سالم اما Schema قدیمی دارد. Packet loss نیز برای UDP telemetry، MQTT و HTTP/TCP اثر یکسانی ندارد.
نمونهٔ کنترلشده با NetEm
# فقط روی Linux، interface و محیط تستِ تأییدشده
tc qdisc add dev eth0 root netem \
delay 120ms 30ms distribution normal \
loss 2% \
rate 2mbit
# پاکسازی پس از سناریو
tc qdisc del dev eth0 root
راهنمای tc-netem قابلیتهای Delay، Loss، Duplicate، Corrupt، Reorder و Rate و نیز محدودیتهایی مانند دقت Timer و محل اعمال برای TCP را توضیح میدهد. Command را در Runner مشترک، لپتاپ روزمره یا Production اجرا نکنید. Interface، Namespace، Direction و Cleanup را صریح کنید و قبل/بعد Health check بگیرید.
گذار اتصال را تست کنید، نه فقط دو حالت آنلاین و آفلاین
ارزش اصلی در Transitionهاست: Connected→Degraded، Degraded→Disconnected، Disconnected→Reconnecting و Reconnecting→Connected. در هر گذار این موارد را بسنجید:
- تشخیص وضعیت چقدر طول میکشد و False positive/negative چیست؟
- درخواست در حال اجرا Abort، Retry یا Commit میشود؟
- UI یا اپراتور چه وضعیت و محدودیتی میبیند؟
- داده در Memory، Queue یا Storage پایدار میماند؟
- بازگشت شبکه باعث Retry storm یا Starvation ترافیک حیاتی میشود؟
- چه زمانی سیستم واقعاً «بازیابیشده» است: Link up یا Backlog zero و Reconciliation clean؟
سناریوی Timeout-before-commit را از Timeout-after-commit جدا کنید. در حالت دوم، Retry کور میتواند اثر دوباره بسازد. Oracle باید Outcome را در System of Record، Ledger یا Actuator بسنجد، نه صرفاً Response آخر را.
قرارداد همگامسازی آفلاین
Store-and-forward بدون Contract میتواند فقط خطا را به آینده منتقل کند. هر Record یا Event آفلاین حداقل این هویت و سیاست را لازم دارد:
- Event ID یکتا، Tenant/Device ID و Idempotency key؛
- Sequence یا Version و رابطهٔ Ordering؛
- Event time و Receive time با Clock-quality indicator؛
- Schema، App، Firmware و Config version؛
- Payload canonical و Integrity metadata؛
- Authority و Conflict-resolution rule؛
- Priority، TTL، Durability و Storage quota؛
- Retry/backoff، Acknowledgement و سقف Attempt؛
- Quarantine/DLQ و مسیر Reconciliation؛
- PII classification، Retention و Redaction.
Oracle همگرایی
عبارت «Sync موفق شد» را با چند شرط جایگزین کنید: همهٔ Eventهای پذیرفتهشده ظرف T همگرا شدهاند؛ هیچ اثر کسبوکاری تکراری نیست؛ ترتیبِ الزامشده حفظ شده؛ Conflict طبق Rule نسخهدار حل شده؛ Record نامعتبر قرنطینه و قابلپیگیری است؛ و جمع Ledger/Inventory با منبع مستقل Reconcile میشود.
Conflict و Clock
Last-write-wins فقط وقتی معتبر است که Requirement همین باشد و Clock semantics قابلاعتماد باشد. ساعت محلی میتواند عقب بماند، جلو بپرد یا پس از خاموشی Reset شود. برای پول، موجودی یا فرمان خطرناک، Conflict را با قانون دامنه، Version/sequence یا مالک تصمیم حل کنید؛ Timestamp نمایشی جای Evidence ترتیب نیست.
ماتریس Fault و Oracle بسازید
| Fault | ریسک | Oracle حداقلی | بازیابی |
|---|---|---|---|
| قطع پس از Commit و پیش از Ack | اثر تکراری | یک Business effect برای یک Idempotency key | Replay امن و Reconcile |
| Event تکراری/خارج از ترتیب | State نادرست | Invariant و Version monotonic | Dedup/Buffer/Quarantine |
| Backlog پس از اتصال | Retry storm و گرسنگی پیام حیاتی | Priority، Throughput و Queue-age limit | Drain کنترلشده |
| Disk full/Write failure | داده پذیرفته اما ناپایدار | عدم اعلام Success پیش از Durability | Backpressure/Read-only/Safe stop |
| Reboot یا قطع برق هنگام Write | Record نیمه و Index خراب | Atomic recovery و Audit کامل | Journal/replay/repair |
| Clock drift | ترتیب/TTL/Certificate اشتباه | Clock-quality و قانون مستقل از زمان نامطمئن | Resync بدون جهش مخرب |
| Schema یا Config ناسازگار | تفسیر متفاوت Edge/Cloud | Compatibility gate و explicit rejection | Rollback/adapter/quarantine |
| Telemetry path قطع | سکوت اشتباه بهعنوان سلامت | Gap/heartbeat و local durable evidence | Upload محدود و قابلردگیری |
منابع محدود دستگاه را وارد تست کنید
Edge node ممکن است CPU، RAM، Storage، Battery، Thermal envelope و I/O محدودی داشته باشد. یک Benchmark روی سختافزار توسعه، رفتار Fleet را اثبات نمیکند.
- Cold/warm start، Cache خالی/پر و Queue کوچک/بزرگ؛
- CPU/RAM/Disk pressure همراه Workload واقعی؛
- Storage fragmentation، log growth و عمر/خطای رسانه؛
- Thermal throttling و تغییر Frequency در دستگاه مرتبط؛
- Battery/energy per operation با ابزار کالیبره؛
- Concurrent local workload و update/telemetry upload؛
- Resource leak در Soak و رفتار OOM/restart؛
- Backpressure پیش از ازدسترفتن داده.
سنجهٔ Resource را به Outcome وصل کنید: CPU بالا بهتنهایی Fail نیست، اما اگر p99 از Deadline عبور کند، Queue age رشد بیحد داشته باشد یا Local decision حذف شود، اثر قابلتصمیم میشود.
ماتریس Fleet را ریسکمحور کنید
ترکیب کامل مدل دستگاه × OS × Firmware × App × Network × Operator × Region معمولاً عملی نیست. Matrix را از Installed base، Criticality، تغییر و Incident بسازید:
- Golden cohort: ترکیب مرجع برای تشخیص سریع؛
- Representative cohorts: بیشترین سهم واقعی و مسیرهای اصلی؛
- Risk cohorts: قدیمیترین سختافزار، کمترین Storage، ضعیفترین شبکه یا نسخهٔ درحالخروج؛
- Changed cohort: اجزایی که Release لمس کرده است؛
- Canary cohort: کوچک، مشاهدهپذیر، قابلبازیابی و بدون تمرکز روی یک منطقه یا مشتری حساس.
برای دستگاهی که واقعاً در Fleet وجود ندارد Coverage نسازید. در مقابل، Long tail کوچک اما پرریسک را پشت سهم بازار پنهان نکنید. Supported/Deprecated/Blocked و تاریخ End-of-Life باید تصمیم رسمی باشند.
بهروزرسانی OTA یک Journey مستقل است
موفقیت Download پایان تست OTA نیست. Artifact باید برای Device/Hardware درست انتخاب، از نظر امضا و Hash اعتبارسنجی، در فضای کافی نصب، پس از Reboot سالم و قابل Rollback باشد.
- انتخاب Target با Hardware/App/Schema compatibility؛
- دانلود کامل و Resume امن روی شبکهٔ محدود؛
- رد Artifact دستکاریشده، امضای نامعتبر و Version قدیمی؛
- قطع برق/شبکه در Download، Verify، Install و First boot؛
- Migration داده با Backup/rollback و Storage کم؛
- Health gate پس از Boot و عدم Rollout خودکار به Cohort بعدی؛
- Rollback یا Recovery image بدون از دستدادن Queue محلی؛
- گزارش دقیق Unknown/offline devices و پایان پشتیبانی.
مشخصات The Update Framework کنترلهایی برای Signature، Version، Expiration و مقابله با Rollback، Freeze و Mix-and-match attack تعریف میکند. استفاده از یک چارچوب امن نیز جای آزمون Power loss، Boot failure، Migration، Fleet rollout و Recovery محصول شما را نمیگیرد.
امنیت و حریم خصوصی در مرز فیزیکی
Threat model باید فرض کند برخی دستگاهها در محیط کمترکنترلشدهاند. خط پایه امنیت سایبری دستگاه IoT در NISTIR 8259A از قابلیتهایی مانند شناسایی دستگاه، پیکربندی مجاز، حفاظت داده، کنترل Interface، بهروزرسانی و آگاهی از وضعیت امنیتی شروع میکند.
- Identity یکتای Device و جلوگیری از Clone/Impersonation؛
- Mutual authentication و Rotation گواهی/Secret، از جمله انقضا هنگام Offline بودن؛
- Secure boot/attestation در صورت وجود Requirement و سختافزار مربوط؛
- Least privilege برای Debug/Admin/Local API و بستن Interface تولید؛
- Encryption در Transit و At rest همراه مدیریت Key؛
- Tamper evidence، Factory reset و Decommission/ownership transfer؛
- حداقلسازی داده، Retention محلی و حذف امن؛
- عدم ثبت Token، اطلاعات بانکی، شماره تماس یا Payload حساس در Log/Trace.
اسکن خودکار یا یک Penetration test امنیت را تضمین نمیکند. Risk، مجوز و Rule of Engagement را از راهنمای تست امنیت نرمافزار بگیرید و آزمونهای فعال را روی دستگاه/شبکهٔ مجاز با Recovery plan اجرا کنید.
Observability باید قطع ارتباط را هم تحمل کند
Trace سراسری زمانی مفید است که هویت رخداد از Device به Edge و Cloud حفظ شود. Context propagation در OpenTelemetry ارتباط علّی Signalها را از مرز Process و Network ممکن میکند؛ اما صف آفلاین، Batch و Async boundary ممکن است Parent/child ساده نداشته باشد. Event ID و Span link را متناسب با مدل خود طراحی کنید.
Evidence contract شامل این موارد است:
- Correlation/Event/Device/Run ID بدون دادهٔ حساس؛
- Timestamp همراه Clock source، offset/quality و timezone؛
- App/Firmware/Config/Schema/Network-profile version؛
- Queue depth/age، retry reason، connection transition و sync outcome؛
- Local durable buffer و سیاست حذف هنگام Storage pressure؛
- Telemetry gap بهعنوان Unknown، نه Success؛
- Sampling و Cardinality budget؛
- Instrumentation overhead و اثرش بر Latency/Energy.
بعد از بازگشت شبکه، Upload تلهمتری نباید جریان کسبوکاری را گرسنه کند. اولویت، Rate limit و Drop policy را تست کنید و Loss شواهد را خودش قابلمشاهده سازید.
نردبان محیط: از مدل تا Field pilot
| لایه | برای چه پرسشی | محدودیت شاهد |
|---|---|---|
| Unit/model | State machine، conflict، retry و invariant | Protocol/OS/Hardware واقعی نیست |
| Component + virtual dependency | Queue، persistence، timeout و contract | رفتار dependency سادهشده است |
| Network-emulated integration | Delay/loss/rate/partition قابلبازتولید | RF، Operator و Handover واقعی را کامل بازنمیسازد |
| Device lab/HIL | Firmware، resource، reboot، power و I/O | مقیاس/مکان/آبوهوا محدود است |
| Field pilot | مسیر، Handover، محیط و عملیات واقعی | کنترل و بازتولید کمتر؛ نیازمند ایمنی |
| Staged production | Fleet distribution و outcome واقعی | آزمایش پرخطر ممنوع و Blast radius محدود |
Emulator و Simulator را با Device real اشتباه نگیرید. شبکهٔ مصنوعی برای Regression و Boundary عالی است، اما رفتار RF، راننده، Modem firmware، Operator policy یا کابل معیوب را کامل بازسازی نمیکند. Field data نیز بدون Manifest و Cohort قابلمقایسه نیست.
Fault injection و تست میدانی را ایمن کنید
قطع عمدی Network، Power یا Storage میتواند داده و تجهیزات را آسیب بزند. پیش از هر آزمایش، Readiness، مجوز، محیط، Blast radius، Stop condition، Kill mechanism، Recovery، Observer مستقل و مالک Incident را ثبت کنید. برای طراحی Hypothesis و Guardrail از راهنمای Chaos Experiment امن استفاده کنید.
در سامانهٔ صنعتی، درمانی، خودرویی یا هر سیستم Safety-critical، این مقاله جای Hazard analysis، استاندارد حوزه، Rig تخصصی و صلاحیت مهندسی ایمنی را نمیگیرد. هیچ Fault فعال را روی Actuator یا کاربر واقعی بدون مجوز و containment مناسب اجرا نکنید.
در Production فقط Verification کمخطر، مشاهدهپذیر و برگشتپذیر انجام دهید. تمایز Canary، Synthetic probe، Shadow، Feature flag و Experiment در راهنمای Shift-right و Testing in Production آمده است.
مثال ایرانی: Edge در شعبهٔ فروشگاه
این سناریو ساختگی اما واقعگرایانه است؛ ادعای مطالعهٔ موردی یا نتیجهٔ تجاری ندارد. هر شعبه یک POS و Gateway محلی دارد. فروش در حالت اتصال به مرکز ثبت میشود؛ در قطع VPN/اینترنت، فقط فروشهای زیر سقف Risk و موجودی محلی مجازند. مبلغ canonical در IRR ذخیره میشود، UI ممکن است تومان نمایش دهد و زمان رخداد UTC همراه offset/quality ثبت میشود.
وعدهها و ریسکها
| وعده | شکست محتمل | شاهد لازم |
|---|---|---|
| فروش محلی در قطع کوتاه | پذیرش بدون ثبت پایدار | Durable event پیش از چاپ Success |
| عدم فروش تکراری | Retry پس از Commit | یک Ledger effect برای Idempotency key |
| موجودی قابلاعتماد | Conflict دو شعبه/مرکز | قانون Authority و Reconciliation diff |
| مبلغ درست | تومان/ریال یا رقم فارسی | IRR canonical و parse/display tests |
| بازیابی کنترلشده | Backlog storm پس از اتصال | Priority، queue age و bounded drain |
پروفایل شبکه و توالی آزمون
- Baseline را روی Hardware و build مشخص با شبکهٔ سالم ثبت کنید.
- Delay/Loss را از Profile مشاهدهشدهٔ یک مسیر مجاز بگیرید؛ Operator یا «اینترنت ایران» را با یک عدد ثابت نمایندگی نکنید.
- هنگام ثبت Sale، مسیر را پس از Commit محلی و پیش از Ack مرکزی قطع کنید.
- همان Sale را با یک Idempotency key Retry و یک Callback مرکزی تکراری تزریق کنید.
- Gateway را هنگام Flush صف خاموش و پس از Boot صحت Journal را بررسی کنید.
- در Reconnect، همزمان ۵۰۰ Event کماولویت و یک Reversal حیاتی وارد کنید.
- Sync را تا صفرشدن Backlog، Reconciliation و گزارش Record قرنطینهشده دنبال کنید.
Oracleهای مستقل
- UI فقط یک رسید و وضعیت اتصال درست نشان دهد؛
- Storage محلی یک Event کامل و قابلبازیابی داشته باشد؛
- مرکز فقط یک Sale/Ledger اثر ایجاد کند؛
- Inventory طبق قانون دامنه همگرا شود؛
- IRR canonical در API/DB/Event یکسان و تومان فقط Presentation باشد؛
- رقمهای فارسی/عربی ورودی طبق Locale contract نرمال شوند، نه اینکه Identifier مخفی تغییر کند؛
- Tehran display از Instant canonical ساخته شود و Clock نامطمئن علامت بخورد؛
- Reversal حیاتی پشت Upload تلهمتری گرسنه نماند؛
- PII/Token در Artifact منتشرشده وجود نداشته باشد.
قالب سناریوی تست Edge
این کارت را برای هر ریسک کپی کنید:
Scenario ID / owner:
Customer or operational promise:
Topology and authority:
Hardware / OS / firmware / app / config / schema:
Network profile, direction, duration and seed:
Initial state and durable data:
Stimulus and exact fault timing:
Expected local outcome / cloud outcome / side effects:
Latency, sync and recovery deadlines:
Independent oracle and evidence IDs:
Stop / kill / rollback / cleanup:
Known gaps and residual risk:
Decision owner and expiry:
اگر Stimulus قابلکنترل یا نتیجه قابلمشاهده نیست، ابتدا Testability را اصلاح کنید. راهنمای طراحی تستپذیری نرمافزار برای Clock، Dependency، Failure، Reset، Oracle و Evidence یک Contract اجرایی ارائه میکند.
اتوماسیون و Pipeline را بر اساس هزینهٔ بازخورد بچینید
- هر Commit: State model، serialization، idempotency، conflict و migration unit tests؛
- Pull Request: component tests با queue/storage/dependency مجازی و failureهای deterministic؛
- روزانه: Network-emulated integration روی Golden/representative cohort؛
- Release candidate: Device lab/HIL، reboot/power/OTA و Soak؛
- پیش از Fleet rollout: Field pilot محدود و Canary با health/stop/rollback؛
- دورهای: Certificate expiry، EOL، recovery image و Disaster/GameDay امن.
Automation coverage درصدی از «واقعیت Edge» نیست. هر Lane باید ریسک، Scope، Environment identity، Oracle، زمان بازخورد، Failure owner و سیاست Retry/Quarantine داشته باشد. Test flaky یا Lab ناپایدار را با Rerun سبز نکنید؛ Product/Test/Environment/Device/Network/Dependency/Unknown را جدا Triaging کنید.
SLI و SLO کاربرمحور تعریف کنید
راهنمای SLO در Google SRE از نسبت Good events به Valid events و هدفی کمتر از ۱۰۰٪ برای تصمیمگیری شروع میکند. برای Edge، Availability ساده کافی نیست؛ سرویس میتواند پاسخ دهد ولی دادهٔ stale یا duplicate بسازد.
- Timeliness: نسبت عملهای معتبر کاملشده در Deadline؛
- Correctness: نسبت Outcomeهای بدون Duplicate/Invariant violation؛
- Durability: Event پذیرفتهشدهای که پس از Reboot/Sync گم نشده است؛
- Freshness: نسبت Read/Decision با age زیر حد تعریفشده؛
- Convergence: نسبت Partitionهایی که ظرف T با Reconciliation clean پایان مییابند؛
- Update health: Cohortهای نصبشده و سالم، Rollback، Unknown و Unsupported؛
- Evidence health: telemetry gaps، dropped evidence و clock-quality distribution.
مخرج را شفاف کنید و Unknown را از Success جدا نگه دارید. SLO واحد برای همهٔ Journey، Device و Region میتواند Cohort آسیبدیده را پنهان کند.
نقشها و حق تصمیم
| نقش | مالکیت نمونه |
|---|---|
| Product/domain | وعده، Offline authority، conflict و customer recourse |
| Edge/firmware engineer | state machine، persistence، resource و recovery |
| Backend/data engineer | contract، idempotency، ordering و reconciliation |
| Network/platform | path/profile، provisioning، fleet و update control |
| Security/privacy | identity، interface، key/update، data minimization و RoE |
| Test/quality engineer | risk model، scenario، oracle، coverage gap و evidence |
| SRE/operations/support | SLI/SLO، alarm، incident، field feedback و runbook |
| Release/risk owner | پذیرش residual risk و Rollout/Stop/Rollback decision |
QA نتیجه را تضمین یا Risk را بهجای کسبوکار قبول نمیکند. تیم تست کیفیت Evidence و Gap را روشن میکند؛ مالک نامبرده تصمیم میگیرد.
گزارش Release باید چه بگوید؟
- Topology، Cohort و نسخههای آزمودهشده؛
- وعده/ریسک و Deadline هر Journey؛
- Network profile و محدودیت نمایندگی آن؛
- نتیجه SLI distribution و denominator، نه فقط Pass count؛
- Faultهای اجراشده و دقیقاً کجا Inject شدهاند؛
- Oracleهای محلی/مرکزی و Reconciliation evidence؛
- Not tested/Unknown، unsupported cohorts و telemetry gaps؛
- Residual risk، Mitigation، Rollout، Stop و Rollback؛
- Owner تصمیم و زمان بازنگری.
دامهای رایج
- فرض اینکه Edge همیشه Latency را کم یا Security را زیاد میکند؛
- یکسانگرفتن Device، Gateway، Fog، MEC و Cloud edge؛
- تست فقط Online و Offline، بدون Transition و Reconnecting؛
- اعلام «۲٪ Loss» بدون Direction، Protocol، Payload، duration و threshold؛
- استفاده از Average و ندیدن p99/Deadline miss/Cohort؛
- One-way timing با Clock نامطمئن؛
- برابر دانستن Link up با بازیابی کامل؛
- Retry بدون Idempotency و Outcome Oracle؛
- Last-write-wins با Timestamp دستگاه بهعنوان قانون عمومی؛
- ندیدن Disk full، Power loss، Cold boot و backlog storm؛
- شمارش Sync success بدون Reconciliation؛
- Emulator بهعنوان اثبات RF/Operator/Device واقعی؛
- OTA فقط با Happy path Download؛
- ذخیره PII/Secret در Log برای تشخیص بهتر؛
- Fault injection بدون مجوز، Stop و Recovery؛
- Canary فقط روی جدیدترین Device و بهترین شبکه؛
- تفسیر سکوت Telemetry بهعنوان سلامت؛
- درصد Automation یا تعداد Device بهعنوان کیفیت؛
- پنهانکردن Unsupported و Unknown برای سبزشدن Dashboard.
برنامهٔ ۳۰روزه
هفتهٔ اول: Topology و Authority
یک Journey مهم را انتخاب کنید. چهار Plane، مسیرهای Primary/Fallback، System of Record، Device cohorts و حالتهای Connected تا Quarantined را رسم کنید. Promise، Deadline، Authority و Recovery owner را ثبت کنید.
هفتهٔ دوم: Profile و Oracle
از دادهٔ مجاز، دو Network profile نماینده و یک Boundary profile بسازید. Latency budget، Clock caveat، Event identity، Idempotency و Reconciliation oracle را تعریف کنید. یک Scenario card کامل بنویسید.
هفتهٔ سوم: Lab و Failure
State-model tests را به Pipeline اضافه کنید؛ سپس روی Namespace/Device مجاز Delay/Loss/Partition، Timeout-after-commit، reboot و backlog drain را اجرا کنید. Artifact و Cleanup را خودکار و محدودیت شواهد را ثبت کنید.
هفتهٔ چهارم: Fleet و تصمیم
Golden، representative و risk cohort را اجرا کنید. یک OTA interruption و Recovery drill امن انجام دهید. SLI/SLO، Unknown، residual risk، Canary/Stop/Rollback و Owner را در Release memo جمع کنید.
چکلیست نهایی تست رایانش لبه
- Topology و چهار Plane با نسخه و Owner ثبت شدهاند.
- Authority هر عمل در Connected/Degraded/Disconnected/Reconnecting روشن است.
- Latency requirement نقطه شروع/پایان، Cohort، Percentile و Deadline دارد.
- Clock، مسیر، Type/Payload و خطای Instrumentation مستند است.
- Network profile فقط Delay ثابت نیست و محدودیت نمایندگی دارد.
- Timeout-before/after-commit، Duplicate و Reorder پوشش داده شدهاند.
- Offline Event هویت، Durability، Priority، Retry و Conflict rule دارد.
- همگرایی با Outcome مستقل و Reconciliation اثبات میشود.
- Disk/CPU/RAM/Thermal/Power و Recovery متناسب با ریسک آزمودهاند.
- Fleet matrix شامل Cohortهای قدیمی/پرریسک و Unknown است.
- OTA امضا، Version، interruption، health، rollback و EOL را پوشش میدهد.
- Identity، Secret/certificate، Interface و حریم خصوصی آزموده شدهاند.
- Evidence در قطع ارتباط Durable است و PII/Secret ندارد.
- Field/Production test مجوز، Blast radius، Stop و Recovery دارد.
- SLI مخرج، Cohort، freshness و limitation را نشان میدهد.
- Residual risk به مالک تصمیم نامبرده رسیده است.
پرسشهای متداول
مهمترین تفاوت تست Edge با تست Cloud چیست؟
Edge معمولاً مرزهای بیشتری میان Device، Gateway، Network و Cloud دارد و باید محدودیت سختافزار، قطع ارتباط، Authority محلی، همگامسازی، Fleet ناهمگون و OTA را بررسی کند. بااینحال روش تست از معماری و ریسک واقعی میآید؛ هر سامانهٔ Edge همهٔ این مشکلات را ندارد و Cloud نیز میتواند توزیعشده و ناپایدار باشد.
برای شبیهسازی اینترنت ضعیف فقط Delay و Packet loss کافی است؟
خیر. Bandwidth، Delay variation، Burst loss، Reorder، Duplicate، Outage، DNS/TLS/NAT/MTU، Direction و Transition نیز ممکن است مهم باشند. Profile باید از دادهٔ مجاز و failure mechanism محصول ساخته شود و Protocol/Payload/مدت/Seed و محدودیت Emulator را ثبت کند.
چگونه بفهمیم همگامسازی آفلاین درست انجام شده است؟
فقط Success response را نبینید. Eventهای پذیرفتهشده باید در زمان محدود به System of Record برسند، Duplicate effect نسازند، Ordering/Conflict rule را رعایت کنند، Record نامعتبر را قرنطینه کنند و با Oracle مستقل مانند Ledger یا Reconciliation همگرا شوند.
آیا One-way latency از RTT بهتر است؟
برای مسیر نامتقارن اطلاعات بیشتری میدهد، اما به Timestamp و Clock synchronization دو سر وابسته است. اگر عدمقطعیت ساعت نسبت به Deadline زیاد است، RTT با یک Clock معتبرتر است. نوع Metric، Measurement points، Clock quality و خطای ابزار را در گزارش بنویسید.
آیا میتوان Faultهای Edge را در Production تست کرد؟
فقط با ریسک پذیرفتهشده، مجوز، Readiness، کوچکترین Blast radius، Guardrail، Stop/Kill، Recovery و Observability کافی؛ آن هم برای سناریوهای غیرخطرناک و برگشتپذیر. ابتدا در مدل، Lab، Device rig و Field pilot پیش بروید. برای سیستم Safety-critical از فرایند و صلاحیت حوزه استفاده کنید.
جمعبندی: Link up نتیجهٔ تست نیست
تست رایانش لبه باید نشان دهد سامانه زیر محدودیت واقعی چگونه تصمیم میگیرد، چه دادهای را پایدار نگه میدارد، پس از Partition چگونه بدون اثر تکراری همگرا میشود و چه زمانی واقعاً بازیابی شده است. نمودار Latency یا سبزشدن Connection فقط بخشی از شاهد است.
از یک Journey شروع کنید: Topology را رسم کنید، Authority حالتهای اتصال را بنویسید، Deadline را به Latency budget تبدیل کنید و یک Timeout-after-commit را با Oracle مستقل اجرا کنید. اگر Event ID، Reconciliation، Clock quality یا Recovery owner ندارید، همان شکاف از افزودن ابزار تازه مهمتر است.
