توجه داشته باشید. ترجمه: نویسنده این مطلب سیندی سریدهران، مهندس imgix است که در توسعه API و به ویژه تست میکروسرویس تخصص دارد. در این مطالب، او دیدگاه دقیق خود را از مشکلات فعلی در زمینه ردیابی توزیع شده به اشتراک می گذارد، جایی که، به نظر او، کمبود ابزار واقعا موثر برای حل مشکلات فوری وجود دارد.
[تصویر گرفته شده از در مورد ردیابی توزیع شده.]
اعتقاد بر این است که دشوار است برای پیاده سازی، و بازگشت در آن است . دلایل زیادی وجود دارد که ردیابی مشکل ساز است، اغلب به زحمتی که در پیکربندی هر جزء سیستم برای انتقال هدرهای مناسب با هر درخواست نیاز دارد، اشاره می کنند. اگرچه این مشکل وجود دارد، اما به هیچ وجه غیر قابل حل نیست. به هر حال، توضیح نمی دهد که چرا توسعه دهندگان واقعاً ردیابی را دوست ندارند (حتی زمانی که قبلاً کار می کند).
چالش اصلی با ردیابی توزیع‌شده، جمع‌آوری داده‌ها، استاندارد کردن قالب‌ها برای توزیع و ارائه نتایج، یا تعیین زمان، مکان و نحوه نمونه‌برداری نیست. من سعی نمی کنم تصور کنم ناچیز این "مشکلات قابل درک"، در واقع، فنی بسیار مهم هستند و (اگر ما واقعاً منبع باز را در نظر بگیریم) ) چالش های سیاسی که باید برطرف شوند تا این مشکلات حل شده تلقی شوند.
با این حال، اگر تصور کنیم که همه این مشکلات حل شده است، احتمال زیادی وجود دارد که هیچ چیز به طور قابل توجهی از نظر تغییر نخواهد کرد. تجربه کاربر نهایی. ردیابی ممکن است هنوز در رایج ترین سناریوهای اشکال زدایی کاربرد عملی نداشته باشد - حتی پس از استقرار.
چنین ردی متفاوت
ردیابی توزیع شده شامل چندین جزء متفاوت است:
- تجهیز برنامه ها و میان افزارها به ابزارهای کنترلی؛
- انتقال بافت توزیع شده؛
- مجموعه آثار؛
- ذخیره ردیابی؛
- استخراج و تجسم آنها
بسیاری از صحبت ها در مورد ردیابی توزیع شده، آن را به عنوان نوعی عملیات یکپارچه تلقی می کنند که تنها هدف آن کمک به تشخیص کامل سیستم است. این تا حد زیادی به این دلیل است که چگونه ایده‌های مربوط به ردیابی توزیع شده در طول تاریخ شکل گرفته است. که در ، ساخته شده در زمان باز شدن منابع زیپکین ذکر شد که آن [Zipkin] توییتر را سریعتر می کند. اولین پیشنهادات تجاری برای ردیابی نیز به عنوان تبلیغ شد .
توجه داشته باشید. ترجمه: برای درک آسانتر متن، اجازه دهید دو اصطلاح اساسی را بر اساس آن تعریف کنیم :
- محدوده - عنصر اساسی ردیابی توزیع شده. این توصیفی از یک گردش کار خاص (به عنوان مثال، یک جستجوی پایگاه داده) با نام، زمان شروع و پایان، برچسب ها، گزارش ها و زمینه است.
- دهانه‌ها معمولاً حاوی پیوندهایی به دهانه‌های دیگر هستند که اجازه می‌دهند چندین دهانه با هم ترکیب شوند پی گیری - تجسم عمر یک درخواست در حین حرکت در یک سیستم توزیع شده.
ردیابی ها حاوی داده های فوق العاده ارزشمندی هستند که می توانند به کارهایی مانند تست تولید، آزمایش بازیابی فاجعه، تست تزریق خطا و غیره کمک کنند. در واقع، برخی از شرکت ها در حال حاضر از ردیابی برای اهداف مشابه استفاده می کنند. بیایید شروع کنیم علاوه بر انتقال ساده دهانه ها به سیستم ذخیره سازی، کاربردهای دیگری نیز دارد:
- به عنوان مثال، اوبر ردیابی نتایج برای تمایز بین ترافیک آزمایشی و ترافیک تولید.
- فیس بوک ردیابی داده ها برای تجزیه و تحلیل مسیر بحرانی و برای سوئیچینگ ترافیک در طول آزمایش های معمول بازیابی فاجعه.
- همچنین شبکه اجتماعی نوت‌بوک‌های Jupyter که به توسعه‌دهندگان اجازه می‌دهد تا درخواست‌های دلخواه را روی نتایج ردیابی انجام دهند.
- طرفداران (تزریق شکست خطی) ردیابی برای آزمایش با تزریق خطا توزیع شده است.
هیچ یک از گزینه های ذکر شده در بالا به طور کامل برای سناریو اعمال نمی شود اشکال زدایی، که طی آن مهندس سعی می کند با مشاهده ردیابی مشکل را حل کند.
وقتی که می آید هنوز به اسکریپت اشکال زدایی می رسد، رابط اصلی نمودار باقی می ماند ردیابی (اگرچه برخی به آن می گویند "نمودار گانت" یا "نمودار آبشار"). زیر ردیابی я همه گستره ها و ابرداده های همراه که با هم ردیابی را تشکیل می دهند. هر سیستم ردیابی منبع باز، و همچنین هر راه حل ردیابی تجاری، ارائه می دهد ردیابی رابط کاربری برای تجسم، جزئیات و فیلتر کردن آثار.
مشکل تمام سیستم های ردیابی که من تا به حال دیده ام این است که نتیجه آن است تجسم (traceview) تقریباً به طور کامل ویژگی های فرآیند تولید ردیابی را منعکس می کند. حتی زمانی که تجسم‌های جایگزین پیشنهاد می‌شوند: نقشه‌های حرارتی، توپولوژی‌های سرویس، هیستوگرام‌های تأخیر، باز هم در نهایت به ردیابی.
در گذشته من به نظر می رسد که اکثر "نوآوری ها" در ردیابی UI/UX محدود به آن هستند ابرداده های اضافی در ردیابی، سرمایه گذاری بر روی آنها اطلاعات با کاردینالیتی بالا (کاردینالیته بالا) یا ارائه توانایی برای دریل کردن در دهانه های خاص یا اجرای پرس و جوها بین و درون ردیابی... که در آن ردیابی ابزار تجسم اولیه باقی می ماند. تا زمانی که این وضعیت ادامه داشته باشد، ردیابی توزیع شده (در بهترین حالت) جایگاه چهارم را به عنوان ابزار اشکال زدایی، پس از متریک ها، لاگ ها و ردیابی های پشته ای به خود اختصاص می دهد، و در بدترین حالت به اتلاف پول و زمان تبدیل می شود.
مشکل با traceview
هدف ردیابی - ارائه یک تصویر کامل از حرکت یک درخواست واحد در تمام اجزای سیستم توزیع شده که به آن مربوط است. برخی از سیستم‌های ردیابی پیشرفته‌تر به شما این امکان را می‌دهند که در دهانه‌های جداگانه بررسی کنید و یک خرابی را در طول زمان مشاهده کنید در داخل یک فرآیند (زمانی که دهانه ها دارای مرزهای عملکردی هستند).
فرض اصلی معماری میکروسرویس ها این ایده است که ساختار سازمانی با نیازهای شرکت رشد می کند. طرفداران میکروسرویس ها استدلال می کنند که توزیع وظایف تجاری مختلف در خدمات فردی به تیم های توسعه کوچک و مستقل اجازه می دهد تا کل چرخه عمر چنین خدماتی را کنترل کنند و به آنها توانایی ایجاد، آزمایش و استقرار مستقل این خدمات را می دهد. با این حال، نقطه ضعف این توزیع از دست دادن اطلاعات در مورد نحوه تعامل هر سرویس با دیگران است. در چنین شرایطی، ردیابی توزیع شده ادعا می کند که ابزاری ضروری است اشکال زدایی تعاملات پیچیده بین خدمات
اگر شما واقعا ، پس حتی یک نفر نمی تواند آن را در سر خود نگه دارد کامل تصویر در واقع، توسعه ابزاری بر اساس این فرض که حتی ممکن است چیزی شبیه به یک ضدالگو (رویکردی ناکارآمد و غیرمولد) است. در حالت ایده آل، اشکال زدایی به ابزاری نیاز دارد که کمک کند منطقه جستجوی خود را محدود کنید، به طوری که مهندسان می توانند بر زیر مجموعه ای از ابعاد (خدمات/کاربران/میزبان ها و غیره) مربوط به سناریوی مشکل در نظر گرفته شده تمرکز کنند. هنگام تعیین علت خرابی، مهندسان ملزم به درک آنچه در طول آن رخ داده است، نیستند همه خدمات به یکباره، زیرا چنین الزامی با ایده معماری میکروسرویس در تضاد است.
با این حال، Traceview است یعنی این. بله، برخی از سیستم‌های ردیابی زمانی که تعداد دهانه‌ها در ردیابی آنقدر زیاد است که نمی‌توانند در یک تجسم نمایش داده شوند، نمایش‌های ردیابی فشرده ارائه می‌دهند. با این حال، به دلیل حجم زیادی از اطلاعات موجود حتی در چنین تجسم ساده، مهندسان هنوز مجبور شد آن را "الک" کنید و انتخاب را به صورت دستی به مجموعه ای از خدمات که منبع مشکلات هستند محدود کنید. متأسفانه در این زمینه ماشین ها بسیار سریعتر از انسان ها هستند، کمتر در معرض خطا هستند و نتایج آنها تکرارپذیرتر است.
دلیل دیگری که فکر می کنم traceview اشتباه است این است که برای اشکال زدایی مبتنی بر فرضیه خوب نیست. در هسته آن، اشکال زدایی است تکرار شونده فرآیندی که با یک فرضیه شروع میشود و به دنبال آن تأیید مشاهدات و حقایق مختلف به‌دست‌آمده از سیستم در کنار بردارهای مختلف، نتیجه‌گیری/تعمیم‌ها و ارزیابی بیشتر صحت فرضیه است.
فرصت سریع و ارزان آزمون فرضیه ها و بهبود مدل ذهنی بر این اساس می باشد سنگ زاویه، سنگ گوشه اشکال زدایی هر ابزار اشکال زدایی باید باشد در ارتباط بودن و فضای جستجو را محدود کنید یا در صورت سرنخ نادرست، به کاربر اجازه دهید به عقب برگردد و روی ناحیه دیگری از سیستم تمرکز کند. ابزار کامل این کار را انجام خواهد داد فعالانه، بلافاصله توجه کاربر را به مناطق مشکل دار بالقوه جلب می کند.
افسوس ، ردیابی را نمی توان ابزاری با رابط تعاملی نامید. بهترین چیزی که می توانید در هنگام استفاده از آن امیدوار باشید، یافتن منبع افزایش تاخیر و مشاهده تمام برچسب ها و گزارش های ممکن مرتبط با آن است. این به مهندس کمک نمی کند که شناسایی کند الگوها در ترافیک، مانند ویژگی های توزیع تاخیر، یا تشخیص همبستگی بین اندازه گیری های مختلف. ممکن است به رفع برخی از این مشکلات کمک کند. واقعا، تجزیه و تحلیل موفق با استفاده از یادگیری ماشین برای شناسایی گستره های غیرعادی و شناسایی زیرمجموعه ای از برچسب ها که ممکن است با رفتار غیرعادی مرتبط باشند. با این حال، من هنوز تجسم‌های متقاعدکننده‌ای از یافته‌های یادگیری ماشین یا داده‌کاوی را ندیده‌ام که به‌طور قابل‌توجهی با یک Traceview یا یک DAG (گراف غیر چرخه‌ای هدایت‌شده) متفاوت هستند.
سطح دهانه ها خیلی پایین است
مشکل اساسی Traceview این است دهانه می کند هم برای تجزیه و تحلیل تأخیر و هم برای تجزیه و تحلیل علت ریشه ای، ابتدایی های بسیار سطح پایین هستند. این مانند تجزیه دستورات یک پردازنده برای تلاش برای حل یک استثنا است، با دانستن اینکه ابزارهای سطح بسیار بالاتری مانند Backtrace وجود دارند که کار با آنها بسیار راحت تر است.
علاوه بر این، من این آزادی را می‌پذیرم که موارد زیر را بیان کنم: در حالت ایده‌آل، ما نیازی نداریم تصویر کامل در طول چرخه عمر درخواست رخ داده است، که توسط ابزارهای ردیابی مدرن نشان داده می شود. در عوض، نوعی انتزاع سطح بالاتر مورد نیاز است که حاوی اطلاعاتی در مورد چیستی باشد اشتباه رفت (شبیه به بک ردیابی)، همراه با برخی زمینه ها. به جای تماشای کل ردیابی، ترجیح می دهم آن را ببینم часть، جایی که اتفاق جالب یا غیرعادی رخ می دهد. در حال حاضر، جستجو به صورت دستی انجام می شود: مهندس ردیابی را دریافت می کند و به طور مستقل دهانه ها را در جستجوی چیزی جالب تجزیه و تحلیل می کند. رویکرد افرادی که به امید شناسایی فعالیت مشکوک به دهانه‌ها خیره می‌شوند، به هیچ وجه مقیاس‌پذیر نیست (به‌ویژه زمانی که آنها باید تمام ابرداده‌های کدگذاری‌شده در بازه‌های مختلف، مانند شناسه دهانه، نام روش RPC، مدت زمان بازه را درک کنند. A، سیاهههای مربوط، برچسب ها، و غیره).
جایگزین های Traceview
نتایج ردیابی زمانی بیشترین کاربرد را دارند که بتوان آنها را به گونه‌ای تجسم کرد که بینش غیر ضروری نسبت به آنچه در بخش‌های به هم پیوسته سیستم اتفاق می‌افتد ارائه دهد. تا زمانی که این اتفاق نیفتد، فرآیند اشکال زدایی تا حد زیادی باقی می ماند بی اثر و بستگی به توانایی کاربر در توجه به همبستگی‌های درست، بررسی قسمت‌های درست سیستم یا کنار هم قرار دادن قطعات پازل دارد - بر خلاف ابزار، به کاربر در تدوین این فرضیه ها کمک می کند.
من یک طراح بصری یا متخصص UX نیستم، اما در بخش بعدی می‌خواهم چند ایده در مورد اینکه این تجسم‌ها چه شکلی هستند به اشتراک بگذارم.
روی خدمات خاص تمرکز کنید
در زمانی که صنعت حول محور ایده ها در حال تثبیت است ، منطقی به نظر می رسد که تیم های فردی باید اطمینان حاصل کنند که خدمات آنها با این اهداف هماهنگ است. نتیجه می شود که خدمات گرا تجسم برای چنین تیم هایی مناسب است.
ردیابی ها، به ویژه بدون نمونه گیری، گنجینه ای از اطلاعات در مورد هر جزء از یک سیستم توزیع شده است. این اطلاعات را می توان در اختیار یک پردازنده حیله گر قرار داد که کاربران را تامین می کند خدمات گرا یافته ها. آنها را می توان از قبل شناسایی کرد - حتی قبل از اینکه کاربر به آثار نگاه کند:
- نمودارهای توزیع تاخیر فقط برای درخواست های بسیار برجسته (درخواست های دور از دسترس);
- نمودارهای توزیع تاخیر برای مواردی که اهداف SLO خدمات به دست نیامده است.
- "متداول ترین"، "جالب" و "عجیب" برچسب ها در پرس و جو که اغلب تکرار می شوند;
- تفکیک تاخیر برای مواردی که وابستگی ها خدمات به اهداف SLO خود نمی رسند.
- تفکیک تاخیر برای سرویس های مختلف پایین دستی.
برخی از این سؤالات به سادگی با معیارهای داخلی پاسخ داده نمی شوند و کاربران را مجبور می کند تا دامنه ها را دقیق بررسی کنند. در نتیجه، ما یک مکانیسم بسیار خصمانه کاربر داریم.
این سؤال را مطرح می‌کند: در مورد تعاملات پیچیده بین خدمات متنوعی که توسط تیم‌های مختلف کنترل می‌شوند چطور؟ اینطور نیست ردیابی آیا مناسب ترین ابزار برای برجسته کردن چنین وضعیتی در نظر گرفته نمی شود؟
توسعه دهندگان موبایل، صاحبان سرویس های بدون تابعیت، دارندگان سرویس های دولتی مدیریت شده (مانند پایگاه های داده) و دارندگان پلت فرم ممکن است به چیز دیگری علاقه مند باشند. ارائه سیستم توزیع شده؛ ردیابی یک راه حل بسیار عمومی برای این نیازهای اساسی متفاوت است. حتی در یک معماری میکروسرویس بسیار پیچیده، صاحبان سرویس نیازی به دانش عمیق بیش از دو یا سه سرویس بالادستی و پایین دستی ندارند. اساساً، در اکثر سناریوها، کاربران فقط باید به سؤالات مربوط به آن پاسخ دهند مجموعه محدودی از خدمات.
مثل این است که به یک زیرمجموعه کوچک از خدمات از طریق ذره بین نگاه کنید تا آن را دقیق بررسی کنید. این به کاربر این امکان را می دهد که سؤالات مبرم تری در مورد تعاملات پیچیده بین این خدمات و وابستگی های فوری آنها بپرسد. این شبیه به ردیابی در دنیای خدمات است، جایی که مهندس می داند که اشتباه است، و همچنین درک درستی از آنچه در سرویس های اطراف اتفاق می افتد دارد چرا.
رویکردی که من تبلیغ می‌کنم دقیقاً برعکس رویکرد مبتنی بر ردیابی از بالا به پایین است، که در آن تجزیه و تحلیل با کل ردیابی شروع میشود و سپس به تدریج تا محدوده‌های فردی ادامه می‌یابد. در مقابل، یک رویکرد از پایین به بالا با تجزیه و تحلیل یک منطقه کوچک نزدیک به علت بالقوه حادثه آغاز می شود، و سپس فضای جستجو را در صورت نیاز گسترش می دهد (با پتانسیل آوردن تیم های دیگر برای تجزیه و تحلیل طیف وسیع تری از خدمات). روش دوم برای آزمایش سریع فرضیه های اولیه مناسب تر است. هنگامی که نتایج ملموس به دست آمد، می توان به سمت تجزیه و تحلیل متمرکزتر و دقیق تر حرکت کرد.
ساخت توپولوژی
اگر کاربر بداند، نماهای خاص سرویس می تواند بسیار مفید باشد چه یک سرویس یا گروهی از سرویس ها مسئول افزایش تاخیر یا ایجاد خطا هستند. با این حال، در یک سیستم پیچیده، شناسایی سرویس متخلف ممکن است یک کار غیر ضروری در هنگام خرابی باشد، به خصوص اگر هیچ پیام خطایی از سرویس‌ها گزارش نشده باشد.
ساخت یک توپولوژی سرویس می تواند کمک بزرگی برای تشخیص اینکه کدام سرویس با افزایش نرخ خطا یا افزایش تاخیر مواجه است که باعث کاهش قابل ملاحظه سرویس می شود، کمک کند. وقتی در مورد ساخت توپولوژی صحبت می کنم، منظورم این نیست نقشه خدمات، نمایش هر سرویس موجود در سیستم و شناخته شده برای آن . این نمای بهتر از traceview بر اساس یک گراف غیر چرخه ای جهت دار نیست. در عوض من دوست دارم ببینم توپولوژی سرویس ایجاد شده به صورت پویا، بر اساس ویژگی های خاصی مانند میزان خطا، زمان پاسخ یا هر پارامتر تعریف شده توسط کاربر که به روشن شدن وضعیت با سرویس های مشکوک خاص کمک می کند.
بیایید یک مثال بزنیم. بیایید یک سایت خبری فرضی را تصور کنیم. خدمات صفحه اصلی (صفحه اول) تبادل داده با Redis، با یک سرویس توصیه، با یک سرویس تبلیغاتی و یک سرویس ویدئویی. این سرویس ویدیویی ویدیوها را از S3 و ابرداده ها را از DynamoDB می گیرد. سرویس توصیه ابرداده را از DynamoDB دریافت می‌کند، داده‌ها را از Redis و MySQL بارگیری می‌کند و پیام‌هایی را برای کافکا می‌نویسد. سرویس تبلیغاتی داده ها را از MySQL دریافت می کند و پیام هایی را برای کافکا می نویسد.
در زیر یک نمایش شماتیک از این توپولوژی است (بسیاری از برنامه های مسیریابی تجاری توپولوژی را می سازند). اگر نیاز به درک وابستگی های سرویس دارید، می تواند مفید باشد. با این حال، در طول اشکال زداییهنگامی که یک سرویس خاص (مثلاً یک سرویس ویدیویی) زمان پاسخگویی را افزایش می دهد، چنین توپولوژی خیلی مفید نیست.
نمودار خدمات یک سایت خبری فرضی
نمودار زیر مناسب تر است. سرویس مشکل داره (ویدئو) درست در مرکز به تصویر کشیده شده است. کاربر بلافاصله متوجه آن می شود. از این تجسم مشخص می شود که سرویس ویدیویی به دلیل افزایش زمان پاسخگویی S3 به طور غیرعادی کار می کند که بر سرعت بارگذاری بخشی از صفحه اصلی تأثیر می گذارد.
توپولوژی پویا فقط خدمات "جالب" را نمایش می دهد
توپولوژی های تولید شده به صورت پویا می توانند کارآمدتر از نقشه های سرویس ایستا باشند، به خصوص در زیرساخت های الاستیک و مقیاس پذیر خودکار. توانایی مقایسه و مقایسه توپولوژی های سرویس به کاربر این امکان را می دهد که سوالات مرتبط تری بپرسد. سوالات دقیق تر در مورد سیستم به احتمال زیاد منجر به درک بهتری از نحوه عملکرد سیستم می شود.
نمایش مقایسه ای
تجسم مفید دیگر یک نمایش مقایسه ای است. در حال حاضر ردیابی ها برای مقایسه های جانبی چندان مناسب نیستند، بنابراین معمولاً مقایسه انجام می شود دهانه می کند. و ایده اصلی این مقاله دقیقاً این است که دهانه ها برای استخراج ارزشمندترین اطلاعات از نتایج ردیابی بسیار پایین هستند.
مقایسه دو ردیابی اساساً نیازی به تجسم جدید ندارد. در واقع، چیزی مانند هیستوگرام که همان اطلاعات یک traceview را نشان می دهد، کافی است. با کمال تعجب، حتی این روش ساده می تواند ثمرات بیشتری نسبت به مطالعه دو اثر جداگانه به همراه داشته باشد. حتی قدرتمندتر این امکان خواهد بود تجسم کردن مقایسه آثار در مجموع. بسیار مفید است که ببینیم چگونه یک تغییر پیکربندی پایگاه داده به تازگی مستقر شده برای فعال کردن GC (جمع آوری زباله) بر زمان پاسخگویی یک سرویس پایین دستی در مقیاس چند ساعت تأثیر می گذارد. اگر آنچه من در اینجا توضیح می دهم شبیه تحلیل A/B از تاثیر تغییرات زیرساخت به نظر می رسد در بسیاری از خدمات با استفاده از نتایج ردیابی، پس از حقیقت خیلی دور نیستید.
نتیجه
من سودمندی خود ردیابی را زیر سوال نمی برم. من صمیمانه معتقدم که هیچ روش دیگری برای جمع‌آوری داده‌ها به اندازه روش‌های موجود در یک ردیابی غنی، علّی و زمینه‌ای وجود ندارد. با این حال، من همچنین معتقدم که همه راه حل های ردیابی از این داده ها به شدت ناکارآمد استفاده می کنند. تا زمانی که ابزارهای ردیابی روی نمایش ردیابی گیر کرده باشند، توانایی آنها برای استفاده حداکثری از اطلاعات ارزشمندی که می تواند از داده های موجود در ردیابی ها استخراج شود، محدود خواهد شد. علاوه بر این، خطر توسعه بیشتر یک رابط بصری کاملا غیر دوستانه و غیر شهودی وجود دارد که توانایی کاربر را برای عیب یابی خطاهای برنامه به شدت محدود می کند.
اشکال زدایی سیستم های پیچیده، حتی با جدیدترین ابزارها، فوق العاده دشوار است. ابزارها باید به توسعه‌دهنده کمک کنند تا یک فرضیه را تدوین و آزمایش کند، به طور فعال ارائه می کند اطلاعات مربوطه، شناسایی نقاط پرت و توجه به ویژگی های توزیع تاخیر. برای اینکه ردیابی به ابزار انتخابی توسعه‌دهندگان در هنگام عیب‌یابی خرابی‌های تولید یا حل مشکلاتی که چندین سرویس را در بر می‌گیرد، تبدیل شود، به رابط‌های کاربر اصلی و تجسم‌هایی نیاز است که با مدل ذهنی توسعه‌دهندگانی که این خدمات را ایجاد و اجرا می‌کنند سازگارتر باشد.
طراحی سیستمی که سیگنال‌های مختلف موجود در نتایج ردیابی را به گونه‌ای که برای سهولت تحلیل و استنتاج بهینه‌سازی شده باشد، نشان دهد، تلاش ذهنی قابل توجهی می‌طلبد. شما باید به این فکر کنید که چگونه توپولوژی سیستم را در حین اشکال زدایی به گونه ای انتزاعی کنید که به کاربر کمک کند بدون نگاه کردن به ردپاها یا دهانه های منفرد بر نقاط کور غلبه کند.
ما به قابلیت های انتزاعی و لایه بندی خوبی نیاز داریم (به خصوص در رابط کاربری). مواردی که به خوبی در فرآیند اشکال زدایی مبتنی بر فرضیه قرار می گیرند، جایی که می توانید به طور مکرر سؤال بپرسید و فرضیه ها را آزمایش کنید. آنها به طور خودکار همه مشکلات مشاهده پذیری را حل نمی کنند، اما به کاربران کمک می کنند شهود خود را تیز کنند و سوالات هوشمندانه تری را فرموله کنند. من خواستار رویکردی متفکرانه و نوآورانه تر برای تجسم هستم. در اینجا یک چشم انداز واقعی برای گسترش افق وجود دارد.
PS از مترجم
در وبلاگ ما نیز بخوانید:
- «"؛
- «"؛
- «'.
منبع: www.habr.com