نوشته‌های ترمینالی

خطا داریم؟ همینه که هست!

یه مثال دیدم که می‌گفت شما وقتی ماشینتون پنچر میشه صبر می‌کنید تا تعمیرکار بیاد درستش کنه، یا با همون چرخ های پنجر با سرعت کم ادامه میدین تا به مقصد برسید؟

به نظرم همین توی برنامه‌نویسی هم مصداق داره، وقتی برنامه‌مون به ارور میخوره چطوری مدیریتش می‌کنیم؟ حالا این ارور خیلی وقت ها exceptionه توی زبون های برنامه نویسی، ولی یکم سطح بالاتر ببینیم،
مثلا به یه سرویس خارجی درخواست دادیم و نیست، خب چیکار کنیم؟
یه فایل کانفیگ رو میخوایم لود کنیم ولی نیست.
دیتایی که از سمت کاربر اومده معتبر نیست.

در یک برنامه معمولی جوابِ (احتمالا) درست به خیلی از این سوالا اینه که خب کارکرد برنامه رو متوقف کن و بگو نمیتونم. برنامه کار نکنه تا دوباره با برطرف شدن مشکلات یکی از اول اجراش کنه،
ولی اگر برنامه ما قراره توی یکسری از محیط‌ها اجرا بشه دیگه خبری از «من کار نمیکنم تا شرایط درست بشه» نیست. چه محیط‌هایی؟ محیط‌هایی که availability بالا مهمه مثلا سیستم های امبدد یا بک‌اند.
مثلا قراره ما مسیریابی یک هواپیما رو انجام بدیم و سیگنال GPS دریافت نمی‌کنیم، خب به هواپیما بگیم فعلا من کار نمیکنم؟! یعنی چی که کار نمیکنم، با سرعت زیاد داره میره :)))
یا مثلاً توی کلود اگر ارور بدیم و برنامه کرش کنه کنیم چی میشه؟ کوبرنتیز دوباره برنامه رو اجرا می‌کنه و دوباره با مشکل درگیریم!

پس در این شرایط نمیشه ارور داد و بیخیال شد، بلکه باید با همون چرخ پنچر ادامه داد، برای هر روش هم با خلاقیت خودمون یا با کمک روش های پیشنهاد شده باید یه پلن بی داشته باشیم،
پیاده سازی و تست خود برنامه در کنار اینکه هر قسمتی ممکنه کار نکنه و سناریوهای مختلفش، کار سختیه ولی هزینه‌ی داشتن یه نرم افزار قابل اعتماده.

مثلا چه مشکلاتی؟
مثلاً اگه قراره کانفیگ فایل رو از بیرون لود کنیم, آمادگی نبودنش رو هم داشته باشیم، مثلا یه کانفیگ پیشفرض داشته باشیم (البته کانفیگ چون موقع اولین اجرای برنامه خودش رو نشون میده شاید نیازی هم نباشه)
مثلا اگر داده gps به ما نرسید، با کمک داده های قبلی که ذخیره کردیم و یا ترکیبش با سرعت و شتاب و ... مشکل رو موقتا و حتی نادقیق حل کنیم
یا مثلاً اگر به سرور خارجی درخواست می‌زنیم و نیست، آمادگی نبودنش رو داشته باشیم، اینجا یکسری پترن که تو صنعت استفاده میشه داریم
مثلا چه پترنهایی؟
+ دوباره درخواست بده: retry pattern
+ به یکی دیگه درخواست بده: fallback
+ اگر خرابه تا یه مدت بهش درخواست نده تا ارور الکی نگیری: circuit breaker
+ اگه سرور خارجی کنده، خیلی صبر نکن تا response time خودت هم بالا نره
+ اگر سرور خارجی دیتا قراره بهت بده، دیتای قبلی رو کش کن.

اینها در سطح کد بودن، در سطح معماری هم میشه از قبل روش‌هایی رو تدارک دید مثلاً خود دیتابیس رو چطوری High available کنیم، یا روش‌هایی که بیشتر تو سیستم های امبدد استفاده میشه مثل اینکه یه برنامه رو با چند تا پیاده سازی همزمان اجرا کنیم تا اگر یکیش خراب شد اون یکی‌ها باشن!

منابع:
https://opensource.com/article/19/9/transient-faults-devops

https://www.jrebel.com/blog/microservices-resilience-patterns

https://learn.microsoft.com/en-us/azure/architecture/best-practices/transient-faults

https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/application-resiliency-patterns

@terminal_stuff

Opensource.com

3 ways to handle transient faults for DevOps

In electrical engineering, a transient fault is defined as an error condition that vanishes after the power is disconnected and restored.

www.tgoop.com/terminal_stuff/2834

3.9K viewsedited  Dec 29, 2023 at 07:30

خطا داریم؟ همینه که هست!

یه مثال دیدم که می‌گفت شما وقتی ماشینتون پنچر میشه صبر می‌کنید تا تعمیرکار بیاد درستش کنه، یا با همون چرخ های پنجر با سرعت کم ادامه میدین تا به مقصد برسید؟

به نظرم همین توی برنامه‌نویسی هم مصداق داره، وقتی برنامه‌مون به ارور میخوره چطوری مدیریتش می‌کنیم؟ حالا این ارور خیلی وقت ها exceptionه توی زبون های برنامه نویسی، ولی یکم سطح بالاتر ببینیم،
مثلا به یه سرویس خارجی درخواست دادیم و نیست، خب چیکار کنیم؟
یه فایل کانفیگ رو میخوایم لود کنیم ولی نیست.
دیتایی که از سمت کاربر اومده معتبر نیست.

در یک برنامه معمولی جوابِ (احتمالا) درست به خیلی از این سوالا اینه که خب کارکرد برنامه رو متوقف کن و بگو نمیتونم. برنامه کار نکنه تا دوباره با برطرف شدن مشکلات یکی از اول اجراش کنه،
ولی اگر برنامه ما قراره توی یکسری از محیط‌ها اجرا بشه دیگه خبری از «من کار نمیکنم تا شرایط درست بشه» نیست. چه محیط‌هایی؟ محیط‌هایی که availability بالا مهمه مثلا سیستم های امبدد یا بک‌اند.
مثلا قراره ما مسیریابی یک هواپیما رو انجام بدیم و سیگنال GPS دریافت نمی‌کنیم، خب به هواپیما بگیم فعلا من کار نمیکنم؟! یعنی چی که کار نمیکنم، با سرعت زیاد داره میره :)))
یا مثلاً توی کلود اگر ارور بدیم و برنامه کرش کنه کنیم چی میشه؟ کوبرنتیز دوباره برنامه رو اجرا می‌کنه و دوباره با مشکل درگیریم!

پس در این شرایط نمیشه ارور داد و بیخیال شد، بلکه باید با همون چرخ پنچر ادامه داد، برای هر روش هم با خلاقیت خودمون یا با کمک روش های پیشنهاد شده باید یه پلن بی داشته باشیم،
پیاده سازی و تست خود برنامه در کنار اینکه هر قسمتی ممکنه کار نکنه و سناریوهای مختلفش، کار سختیه ولی هزینه‌ی داشتن یه نرم افزار قابل اعتماده.

مثلا چه مشکلاتی؟
مثلاً اگه قراره کانفیگ فایل رو از بیرون لود کنیم, آمادگی نبودنش رو هم داشته باشیم، مثلا یه کانفیگ پیشفرض داشته باشیم (البته کانفیگ چون موقع اولین اجرای برنامه خودش رو نشون میده شاید نیازی هم نباشه)
مثلا اگر داده gps به ما نرسید، با کمک داده های قبلی که ذخیره کردیم و یا ترکیبش با سرعت و شتاب و ... مشکل رو موقتا و حتی نادقیق حل کنیم
یا مثلاً اگر به سرور خارجی درخواست می‌زنیم و نیست، آمادگی نبودنش رو داشته باشیم، اینجا یکسری پترن که تو صنعت استفاده میشه داریم
مثلا چه پترنهایی؟
+ دوباره درخواست بده: retry pattern
+ به یکی دیگه درخواست بده: fallback
+ اگر خرابه تا یه مدت بهش درخواست نده تا ارور الکی نگیری: circuit breaker
+ اگه سرور خارجی کنده، خیلی صبر نکن تا response time خودت هم بالا نره
+ اگر سرور خارجی دیتا قراره بهت بده، دیتای قبلی رو کش کن.

اینها در سطح کد بودن، در سطح معماری هم میشه از قبل روش‌هایی رو تدارک دید مثلاً خود دیتابیس رو چطوری High available کنیم، یا روش‌هایی که بیشتر تو سیستم های امبدد استفاده میشه مثل اینکه یه برنامه رو با چند تا پیاده سازی همزمان اجرا کنیم تا اگر یکیش خراب شد اون یکی‌ها باشن!

منابع:
https://opensource.com/article/19/9/transient-faults-devops

https://www.jrebel.com/blog/microservices-resilience-patterns

https://learn.microsoft.com/en-us/azure/architecture/best-practices/transient-faults

https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/application-resiliency-patterns

@terminal_stuff

BY نوشته‌های ترمینالی