https://virgool.io/feed/@SajjadGhafarian Platform / DevOps Engineer at Asa Co.(Agah Group) fa 2026-04-14 15:38:48 https://files.virgool.io/upload/users/11831/avatar/sG6Mx1.jpg?height=120&width=120 https://virgool.io/@SajjadGhafarian https://virgool.io/@SajjadGhafarian/scalable-system-design-principles-part-4-q0655zwwbwyn در ادامه‌ی قسمت قبلی که درباره‌ی Design for Operations (طراحی برای عملیات) و Partition Around Limits (پارتیشن‌بندی براساس محدودیت‌ها) صحبت کردیم، توی این بخش سوم قصد داریم به سراغ دو مفهوم اساسی دیگه بریم که تأثیر عمیقی در طراحی سیستم‌های بزرگ، پایدار و مقیاس‌پذیر دارن: Design for Evolution (طراحی برای تکامل‌پذیری) و Build for Business Needs (طراحی بر اساس نیازهای کسب‌وکار).لینک بخش اول - اصول طراحی نرم‌افزارها و سیستم‌های مقیاس‌پذیرلینک بخش دوم - اصول طراحی نرم‌افزارها و سیستم‌های مقیاس‌پذیرلینک بخش سوم - اصول طراحی نرم‌افزارها و سیستم‌های مقیاس‌پذیرچرا این مفاهیم مهم هستند؟در هر سیستم بزرگ و در حال رشد، تغییرات و نیازهای جدید اجتناب‌ناپذیرند. سیستم‌هایی که امروز طراحی می‌کنی، باید نه تنها نیازهای فعلی بلکه نیازهای آینده‌ی کسب‌وکار رو هم پوشش بدن و به‌راحتی با تحولات بازار و تکنولوژی‌های جدید سازگار بشن. اینجاست که اهمیت Design for Evolution مشخص میشه؛ یعنی سیستمی بسازی که بتونه به مرور زمان تکامل پیدا کنه، بدون اینکه نیاز به بازطراحی اساسی باشه.از طرف دیگه، طراحی سیستم نباید فقط براساس اصول فنی باشه، بلکه باید همیشه اهداف و نیازهای کسب‌وکار رو هم در نظر داشته باشه. Build for Business Needs به این معناست که هر تصمیم طراحی باید در راستای ارزش‌آفرینی برای کسب‌وکار و رفع نیازهای واقعی اون باشه. هر تغییری که انجام می‌دی، باید به شکلی مستقیم یا غیرمستقیم، کسب‌وکار رو تقویت کنه.در این مقاله، می‌خواهیم بررسی کنیم که چطور با پیاده‌سازی اصول تکامل‌پذیری و توجه به نیازهای کسب‌وکار، می‌تونی سیستمی بسازی که نه تنها مقیاس‌پذیر و قابل اعتماد باشه، بلکه در گذر زمان به‌راحتی گسترش پیدا کنه و همچنان با اهداف سازمان همسو باقی بمونه.طراحی برای تکامل‌پذیری (Design for Evolution)یکی از ویژگی‌های مهم در طراحی یک سیستم موفق، تکامل‌پذیری آن است. هیچ سیستمی بدون تغییر و به‌روزرسانی باقی نمی‌ماند؛ چه برای رفع باگ‌ها، افزودن ویژگی‌های جدید، به‌کارگیری تکنولوژی‌های نو، یا بهبود مقیاس‌پذیری و پایداری. اگر اجزای یک اپلیکیشن به‌طور شدید به یکدیگر وابسته باشند، هرگونه تغییر می‌تواند باعث ایجاد مشکلات گسترده‌ای در سایر بخش‌ها شود. بنابراین، طراحی تکامل‌پذیر به تیم‌ها این امکان رو میده که به راحتی ویژگی‌های جدید رو اضافه کنن، بدون اینکه سیستم به مرور زمان دچار شکنندگی و کاهش انعطاف‌پذیری بشه.معماری میکروسرویس‌ها به عنوان یک روش محبوب برای دستیابی به طراحی تکامل‌پذیر شناخته میشه. این معماری به دلیل استفاده از سرویس‌های مستقل، به راحتی اجازه میده که تغییرات و نوآوری‌های جدید بدون ایجاد مشکل در کل سیستم، پیاده‌سازی بشن.توصیه‌هایی برای دستیابی به یک طراحی تکامل‌پذیراستفاده از انسجام بالا و کاپلینگ ضعیف (High Cohesion & Loose Coupling): سرویس‌ها باید به نحوی طراحی بشن که هر سرویس یک وظیفه مشخص و منسجم رو انجام بده و به حداقل وابستگی‌ها با سایر سرویس‌ها محدود بشه. انسجام بالا به این معنیه که سرویس تمام وظایف مرتبط به خودش رو مستقل انجام میده. اتصال ضعیف یا کاپلینگ ضعیف هم یعنی هر سرویس باید بدون تغییر در سایر سرویس‌ها، قابل تغییر و به‌روزرسانی باشه. این ویژگی‌ها به کاهش وابستگی‌ها کمک کرده و نوآوری و توسعه سرویس‌ها رو ساده‌تر می‌کنن.کپسوله کردن(Encapsulate Domain Knowledge): قوانین و چارچوبهای کسب‌وکار و دانش تخصصی باید به‌طور کامل در داخل سرویس‌های مربوطه انکپسوله بشن و در دسترس کلاینت‌ها یا سرویس‌های دیگه قرار نگیرن. این کار باعث میشه که هر تغییری در منطق کسب‌وکار، تنها در سرویس‌های مرتبط اعمال بشه و از پراکندگی قوانین در اپلیکیشن جلوگیری بشه.استفاده از ساختارهای Async ویا همان Asynchronous Messaging: ارتباطات غیرهمزمان بین سرویس‌ها باعث کاهش وابستگی‌های مستقیم بین آن‌ها میشه. در این روش، تولیدکننده پیام(Producer) نیازی نداره که منتظر پاسخ مصرف‌کننده(Consumer) باشه و حتی ممکنه ندونه که چه سرویس‌هایی پیامش رو مصرف می‌کنن. با این کار، سرویس‌های جدید می‌تونن بدون نیاز به تغییر در تولیدکننده پیام، از پیام‌ها استفاده کنن.پرهیز از افزودن Logic به Gatewayها: گیت‌وی ها در معماری میکروسرویس برای کارهایی مثل مسیریابی درخواست‌ها، مدیریت پروتکل‌ها، لودبالانسینگ، یا احراز هویت استفاده میشن، بهتره که این Gatewayها صرفاً وظایف زیرساختی رو انجام بدن و منطق کسب‌وکار درونشون قرار نگیره تا Gatewayها تبدیل به وابستگی‌ها نشن.اینترفیس‌ها (Open Interfaces): سرویس‌ها باید APIهایی با قراردادهای مشخص(API Contract) و نسخه‌بندی شده(Versioned) داشته باشن که به راحتی قابل استفاده و دارای backward compatibility باشن. این کار به سرویس‌ها اجازه میده که تغییرات و به‌روزرسانی‌های خودشون رو به مرور زمان و بدون نیاز به تغییر در تمام سرویس‌های وابسته، اعمال کنن. قابل ذکر هستش که سرویس‌های پابلیک می‌تونن از APIهای RESTful استفاده کنن، در حالی که سرویس‌های داخلی برای کارایی بهتر میتونن از پروتکل‌های RPC بهره ببرن.طراحی و Testing براساس قراردادهای سرویس‌ها: با تعریف APIهای دقیق و قراردادهای مشخص(API Contract)، می‌تونی سرویس‌ها رو به صورت مستقل طراحی و تست کنی، بدون اینکه نیاز به راه‌اندازی همه‌ی سرویس‌های وابسته باشه.استفاده از توابع ارزیابی معماری (Fitness Functions): توابع ارزیابی، به عنوان ابزاری برای سنجش تغییرات سیستم به کار میرن و می‌تونن تعیین کنن که آیا یک تغییر معماری به بهبود یا افت کارایی منجر شده. برای مثال، اگه زمان بارگذاری صفحات یکی از ویژگی‌های مهم سیستم باشه، میشه یه تابع ارزیابی برای بررسی زمان بارگذاری به فرآیند continuous integration در CI/CD اضافه کرد تا تغییرات باعث افت عملکرد نشن.جدا کردن Abstract infrastructure از منطق: منطق کسب‌وکار (Domain Logic) نباید با موارد زیرساختی مثل messaging یا persistence ترکیب بشه. این کار باعث میشه که تغییرات زیرساختی یا منطق کسب‌وکار به‌طور مستقل و بدون تاثیر منفی روی دیگری، انجام بشه.واگذاری دغدغه‌های مشترک به سرویس‌های جداگانه(Offload cross-cutting concerns to a separate service): بعضی از وظایف مثل احراز هویت که چندین سرویس ازش استفاده می‌کنن، بهتره به یک سرویس مشترک واگذار بشن. اینطوری اگه نیاز به تغییر در فرآیند احراز هویت باشه، می‌تونی فقط سرویس احراز هویت رو تغییر بدی و سرویس‌های دیگه بدون نیاز به تغییر، از اون استفاده کنن.دیپلوی مستقل هر سرویس: یکی از مزایای اصلی معماری تکامل‌پذیر، توانایی به‌روزرسانی و استقرار مستقل هر سرویسه(مثلا روی کوبرنتیز که به راحتی میشه roll-out و rollback داشت). با این روش، می‌تونی باگ‌ها و ویژگی‌های جدید رو بدون وقفه و به‌سرعت عرضه کنی، چون نیاز به هماهنگی با سایر سرویس‌ها و پیاده‌سازی همزمان نیست.طراحی براساس نیازهای کسب‌وکار (Build for Business Needs)هر تصمیم طراحی باید به شکل مستقیم یا غیرمستقیم از یک نیاز کسب‌وکاری پشتیبانی کنه. در ظاهر، این اصل ممکنه بدیهی به نظر برسه، اما در عمل، رعایت این اصل برای طراحی سیستم‌هایی که واقعاً ارزش‌آفرینی می‌کنن سخت اما حیاتیه. اینکه اپلیکیشن باید چه سطحی از دسترسی‌پذیری، مقیاس‌پذیری یا پایداری داشته باشه، همگی به نیازهای واقعی کسب‌وکار بستگی دارن.توصیه‌هایی برای طراحی براساس نیازهای کسب‌وکارتعیین اهداف کسب‌وکاری مثل RTO، RPO و MTO: پارامتر Recovery Time Objective (RTO) یعنی حداکثر زمان مجاز برای بازیابی سرویس بعد از وقوع خرابی و پارامتر Recovery Point Objective (RPO) به مقدار داده‌ای اشاره داره که در صورت خرابی می‌تونیم از دست بدیم و همچنین پارامتر Maximum Tolerable Outage (MTO) هم حداکثر مدت زمان قطعی است که کسب‌وکار می‌تونه تحمل کنه. این اعداد، راهنمایی برای تصمیم‌گیری درباره معماری سیستم هستن. اگر نیاز به RTO و RPO خیلی پایین داری، معماری‌های افزونه‌دار (مثل معماری‌های چندمنطقه‌ای یا چند-دیتاسنتری) ضروری هستن.بررسی ریسک‌ها و مخاطرات شکست: شناسایی ریسک‌ها و مخاطرات در طراحی اپلیکیشن حیاتی است. طراحی باید به نحوی باشه که سیستم در برابر خرابی‌های رایج مقاوم باشه، اما ممکنه نیازی نباشه که برای ریسک‌های غیرمحتمل هزینه‌های سنگین صرف کنیم... بنابراین، لازم است که میزان تحمل کسب‌وکار در برابر ریسک رو به‌خوبی درک کنی و معماری رو بر اساس اون طراحی کنی.مستندسازی SLAها و SLOها: پارامتر Service Level Agreement (SLA) و Service Level Objective (SLO) معیارهایی مثل دسترس‌پذیری و کارایی رو تعیین می‌کنن که باید به وضوح مستند بشن. برای مثال، یک راهکار ممکنه سطح دسترس‌پذیری ۹۹.۹۵٪ رو ارائه بده، اما این باید با نیازهای کسب‌وکار همخوانی داشته باشه.(توضیحات بیشتر در کتاب SRE گوگل)مدل‌سازی اپلیکیشن بر اساس دامنه کسب‌وکار: مدل‌سازی اپلیکیشن براساس نیازهای کسب‌وکار، برای درک بهتر از فرایندهای سازمانی و چالش‌های اون ضروریه. طراحی مبتنی بر دامنه (Domain-Driven Design - DDD) می‌تونه به ایجاد مدل‌هایی کمک کنه که با فرآیندها و نیازهای واقعی کسب‌وکار همخوانی دارن.تعریف نیازهای عملکردی و غیرفعال: نیازهای عملکردی (Functional Requirements) و غیرفعال (Non-Functional Requirements) نقش مهمی در تصمیم‌گیری‌های طراحی ایفا می‌کنن. نیازهای عملکردی تعیین می‌کنن که اپلیکیشن باید چه کارهایی رو انجام بده، در حالی که نیازهای غیرفعال شامل دسترس‌پذیری، مقیاس‌پذیری و زمان تأخیر میشن و روی انتخاب تکنولوژی و معماری تأثیر می‌ذارن.تقسیم Workloadها(Decompose workloads into discrete functionality): بارهای کاری (Workloads) بخش‌های مختلفی از اپلیکیشن هستن که می‌تونن نیازهای متفاوتی در زمینه دسترس‌پذیری، مقیاس‌پذیری و بازیابی داشته باشن. با تقسیم این بارها به بخش‌های مستقل، می‌تونی طراحی رو به شکلی بهینه کنی که نیازهای خاص هر بخش رو برآورده کنه. به‌طور معمول، می‌تونی کامپوننت‌ها رو بر اساس اهمیت تجاری‌شون دسته‌بندی کنی؛ کامپوننت‌های مهم (Tier 1) باید به بهترین شکل بهینه‌سازی بشن، در حالی که کامپوننت‌های کمتر حیاتی (Tier 3) باید با هزینه و پیچیدگی کمتری مدیریت بشن.(این موضوع بهت کمک میکنه که مثلا فقط کامپوننت موردنیاز رو اسکیل بدی)برنامه‌ریزی برای رشد: طراحی یک راهکار نباید فقط نیازهای فعلی رو پشتیبانی کنه؛ بلکه باید برای نیازهای آینده و رشد احتمالی سیستم هم آماده باشه. این شامل آمادگی برای افزایش تعداد کاربران، حجم تراکنش‌ها و فضای ذخیره‌سازی میشه. همچنین باید پیش‌بینی کرد که مدل کسب‌وکار یا نیازهای کسب‌وکار ممکنه با گذر زمان تغییر کنه.همسو کردن مدل کسب‌وکار و هزینه‌ها: طراحی سیستم باید به نحوی باشه که هزینه‌ها و ارزش‌ها در راستای مدل کسب‌وکار هماهنگ باشن. به عنوان مثال، اگه ارزش سیستم از جنبه سودآوری ارزیابی میشه، باید مطمئن بشی که معماری از ارزش‌های کلیدی کسب‌وکار حمایت می‌کنه. این نوع طراحی به مدیریت هزینه‌ها و حفظ پایداری مالی کمک می‌کنه و باعث میشه که سرمایه‌گذاری روی سیستم در درازمدت برای کسب‌وکار سودآور باشه.مدیریت هزینه‌ها: همیشه در طراحی، هزینه های مربوط به موارد عملیاتی مثل DevOps، Incident Response و بازیابی پس از حادثه(Disaster Recovery) رو در نظر بگیر.سخن پایانیدر این مجموعه مقالات، اصول مهمی رو برای طراحی سیستم‌های مقیاس‌پذیر، پایدار و تکامل‌پذیر بررسی کردیم. از طراحی خودترمیم و افزونگی برای ایجاد پایداری بیشتر، تا به حداقل رساندن هماهنگی و مقیاس‌دهی افقی برای افزایش کارایی و انعطاف‌پذیری، همگی این اصول به طراحان و تیم‌های توسعه کمک می‌کنن تا سیستمی بسازن که در برابر چالش‌های رشد و تغییرات پایدار باقی بمونه... در ادامه به پارتیشن‌بندی برای مدیریت محدودیت‌ها و طراحی برای عملیات پرداختیم تا اطمینان حاصل کنیم که سیستم به راحتی قابل مدیریت و نگهداری است. اصولی مثل تکامل‌پذیری و طراحی براساس نیازهای کسب‌وکار هم کمک می‌کنن تا سیستم نه‌تنها انعطاف‌پذیر و مقاوم باشه، بلکه همواره با اهداف و نیازهای کسب‌وکار همسو باقی بمونه.در نهایت، این اصول طراحی به شما کمک می‌کنن سیستمی بسازید که با گذشت زمان همچنان پایدار، مقیاس‌پذیر و همسو با ارزش‌های سازمانی باشه. رعایت این اصول به تیم‌ها اجازه میده که نوآوری و تغییرات رو به راحتی وارد سیستم کنن، در حالی که همچنان از پایداری، عملکرد و ارزش‌آفرینی اون برای کسب‌وکار اطمینان داشته باشن.پایانامیدوارم که واستون مفید بوده باشه!منابع:https://learn.microsoft.com/en-us/azure/architecture/guide/design-principles/build-for-businesshttps://learn.microsoft.com/en-us/azure/architecture/guide/design-principles/design-for-evolution سجاد غفاریان سجاد غفاریان Mon, 11 Nov 2024 15:45:00 +0330 https://virgool.io/@SajjadGhafarian/scalable-system-design-principles-part-3-lsox4m1xkjy4 در ادامه‌ی بحث‌های قبلی که درباره Minimize Coordination (به حداقل رساندن هماهنگی بین کامپوننت‌ها) و Design to Scale Out (طراحی برای مقیاس‌پذیری افقی) صحبت کردیم، در این قسمت سوم، می‌خواهیم دو مفهوم کلیدی دیگه رو بررسی کنیم که نقش بسیار مهمی در طراحی سیستم‌های بزرگ و مقیاس‌پذیر دارن: Partition Around Limits و Design for Operations.لینک بخش اول - اصول طراحی نرم‌افزارها و سیستم‌های مقیاس‌پذیرلینک بخش دوم - اصول طراحی نرم‌افزارها و سیستم‌های مقیاس‌پذیرچرا این مفاهیم مهم هستند؟وقتی یک سیستم بزرگ و پیچیده رو طراحی می‌کنی، همیشه محدودیت‌هایی مثل ظرفیت پایگاه داده‌ها، توان شبکه، یا منابع محاسباتی سر راهت قرار می‌گیرن. این محدودیت‌ها می‌تونن مانعی جدی برای عملکرد و مقیاس‌پذیری سیستم باشن. اینجاست که اصل Partition Around Limits (پارتیشن‌بندی براساس محدودیت‌ها) وارد عمل میشه. این اصل بهت کمک می‌کنه داده‌ها و منابع سیستم رو به بخش‌های کوچکتر و مستقل تقسیم کنی تا بار بین اون‌ها توزیع بشه و از محدودیت‌ها عبور کنی.در کنار اون، Design for Operations (طراحی برای عملیات) یکی دیگه از اصول مهم در طراحی سیستم‌های پیچیده است. این اصل به این نکته اشاره داره که سیستم‌ها باید از همون ابتدا طوری طراحی بشن که برای مدیریت و عملیات‌های نگهداری روزانه آماده باشن. به عبارت دیگه، داشتن یک سیستم پایدار فقط به معماری و کد خوب محدود نمیشه؛ بلکه باید ابزارها و فرآیندهایی برای تیم‌های عملیات فراهم بشه تا بتونن به‌راحتی سیستم رو مانیتور کنن، از مشکلات جلوگیری کنن و به سرعت در صورت بروز خطا واکنش نشون بدن.در این مقاله، به بررسی این دو مفهوم خواهیم پرداخت و توضیح می‌دهیم چطور با پارتیشن‌بندی هوشمندانه و طراحی برای عملیات، می‌تونی سیستمی بسازی که نه تنها مقیاس‌پذیر باشه، بلکه مدیریت و نگهداریش هم ساده و کارآمد باشه.پارتیشن‌بندی برای مدیریت محدودیت‌ها (Partition Around Limits)یکی از مهم‌ترین چالش‌هایی که در سیستم‌های بزرگ و در حال رشد با آن مواجه می‌شوی، برخورد با محدودیت‌های مقیاس‌پذیری است. هر سرویس ابری، از جمله سرویس‌های ابری معروف مثل Azure، AWS ویا Google Cloud محدودیت‌هایی در زمینه مقیاس‌دهی داره؛ از جمله تعداد هسته‌های پردازشی، حجم پایگاه داده، میزان ورودی/خروجی داده‌ها (I/O)، و ظرفیت شبکه. به همین دلیل، وقتی سیستم به اندازه کافی بزرگ میشه، احتمالاً با یکی از این محدودیت‌ها برخورد خواهی کرد.پارتیشن‌بندی (Partitioning) یک راه‌حل کارآمد برای عبور از این محدودیت‌هاست. با تقسیم‌بندی داده‌ها، منابع، یا اجزای سیستم به بخش‌های مستقل، می‌تونی بار رو بین اون‌ها توزیع کنی و از بروز گلوگاه‌ها جلوگیری کنی. پارتیشن‌بندی بهت این امکان رو میده که به جای اینکه یک منبع خاص رو بیش از حد تحت فشار بذاری، از چندین منبع کوچک‌تر به صورت همزمان استفاده کنی و از ظرفیت حداکثری اون‌ها بهره‌مند بشی.روش‌های مختلف پارتیشن‌بندیپارتیشن‌بندی می‌تونه در بخش‌های مختلف سیستم اعمال بشه، از جمله پایگاه‌های داده، صف‌ها، سرویس‌های وب، یا حتی زیرساخت‌های پردازشی. هر کدوم از این بخش‌ها ممکنه با محدودیت‌های خاص خودشون مواجه بشن و نیاز به تقسیم‌بندی داشته باشن.پارتیشن‌بندی پایگاه دادهپایگاه داده‌ها یکی از رایج‌ترین بخش‌هایی هست که با محدودیت‌های مختلفی مثل حجم داده، تعداد درخواست‌های همزمان، یا سرعت I/O مواجه میشن. پارتیشن‌بندی پایگاه داده می‌تونه به سه شکل انجام بشه:پارتیشن‌بندی افقی (Sharding): در این روش، داده‌ها براساس یک معیار خاص (مثل نام مشتری یا شماره سفارش) به چندین پارتیشن مستقل تقسیم میشن. هر پارتیشن شامل یک زیرمجموعه از داده‌های کل سیستمه و همه پارتیشن‌ها از یک طرح داده مشابه استفاده می‌کنن.پارتیشن‌بندی عمودی: در این روش، هر پارتیشن شامل یک زیرمجموعه از فیلدهای داده‌های سیستم است. به عنوان مثال، می‌تونی فیلدهای پراستفاده رو در یک پارتیشن و فیلدهای کمتر استفاده شده رو در پارتیشن دیگری ذخیره کنی.پارتیشن‌بندی عملکردی: در این روش، داده‌ها براساس کارکرد و زمینه استفاده‌شون تقسیم میشن. برای مثال، داده‌های مربوط به فاکتورها در یک پارتیشن و داده‌های موجودی محصولات در پارتیشن دیگه ذخیره میشه.پارتیشن‌بندی صف‌ها و پیام‌هابرای سرویس‌های پیام‌محور یا صف‌ها، محدودیت‌هایی مثل تعداد اتصالات همزمان یا حجم پیام‌ها می‌تونن ایجاد مشکل کنن. با پارتیشن‌بندی صف‌ها یا پیام‌ها، می‌تونی درخواست‌ها رو به چندین صف مجزا تقسیم کنی و تعداد پیام‌ها رو بین این صف‌ها به شکل مساوی توزیع کنی.پارتیشن‌بندی سرویس‌های پردازشیبرای سرویس‌های پردازشی که ممکنه با محدودیت‌هایی مثل تعداد هسته‌های پردازشی یا ظرفیت شبکه مواجه بشن، می‌تونی پارتیشن‌بندی رو در سطح سرویس‌ها یا ماشین‌های مجازی انجام بدی. به این صورت که چندین سرویس یا ماشین مجازی با منابع جداگانه به کار گرفته بشن و بار پردازشی بین اون‌ها توزیع بشه.نکات کلیدی در پارتیشن‌بندیانتخاب کلید پارتیشن‌بندی مناسب: مهم‌ترین نکته در پارتیشن‌بندی اینه که کلید پارتیشن‌بندی رو طوری انتخاب کنی که باعث توزیع یکنواخت بار بین پارتیشن‌ها بشه. برای مثال، اگه پارتیشن‌بندی رو براساس اولین حرف نام مشتری انجام بدی، ممکنه برخی حروف بیشتر از بقیه تکرار بشن و یک پارتیشن خیلی شلوغ‌تر از بقیه بشه. در عوض، از کلیدهایی مثل شناسه‌های تصادفی یا هش شده استفاده کن که توزیع بار رو بهتر مدیریت کنن.پارتیشن‌بندی بر اساس محدودیت‌های مختلف: پارتیشن‌بندی فقط برای پایگاه‌های داده کاربرد نداره، باید به محدودیت‌های دیگه مثل شبکه، پردازشگرها، و ذخیره‌سازی هم توجه کنی و در صورت نیاز، پارتیشن‌بندی رو در سطوح مختلف سیستم پیاده‌سازی کنی. مثلاً اگه یک سرور یا VM داره به محدودیت‌های CPU می‌رسه، می‌تونی بار پردازشی رو بین چندین VM یا سرویس تقسیم کنی.پرهیز از نقاط بحرانی (Hotspots): یکی از چالش‌های رایج در پارتیشن‌بندی، بروز نقاط بحرانی یا Hotspotهاست. این اتفاق زمانی رخ میده که یک پارتیشن بیشتر از بقیه پارتیشن‌ها درخواست دریافت می‌کنه و در نتیجه، دچار گلوگاه میشه. برای جلوگیری از این مشکل، کلید پارتیشن‌بندی رو طوری انتخاب کن که بار به شکل مساوی بین پارتیشن‌ها تقسیم بشه.پارتیشن‌بندی در سطوح مختلف: پارتیشن‌بندی می‌تونه در سطوح مختلفی از سیستم انجام بشه، از پایگاه‌های داده گرفته تا ماشین‌های مجازی، حساب‌های اشتراکی و حتی سطوح زیرساختی بالاتر. در برنامه‌های بزرگ، ممکنه نیاز باشه پارتیشن‌بندی رو حتی در سطح اشتراک‌ها (Subscriptions) یا گروه‌های منابع (Resource Groups) هم انجام بدی تا محدودیت‌های مربوط به این سطوح هم مدیریت بشن.پارتیشن‌بندی یک ابزار قدرتمند برای مدیریت محدودیت‌های مختلف سیستم است. با تقسیم‌بندی هوشمندانه منابع، می‌تونی از بروز گلوگاه‌ها جلوگیری کنی و عملکرد سیستم رو به شکل قابل توجهی بهبود بدی. به کمک پارتیشن‌بندی، می‌تونی سیستم رو مقیاس‌پذیرتر، پایدارتر و انعطاف‌پذیرتر کنی تا در برابر چالش‌های مربوط به محدودیت‌های مقیاس‌پذیری مقاوم باشه.طراحی برای عملیات (Design for Operations)یکی از جنبه‌های حیاتی در طراحی اپلیکیشن‌های ابری موفق اینه که سیستم رو طوری بسازی که تیم عملیات بتونه به راحتی اون رو مدیریت کنه و ابزارهای لازم برای نظارت، نگهداری و واکنش سریع به مشکلات رو در اختیار داشته باشه. در دنیای ابری، نقش تیم عملیات به شکلی اساسی تغییر کرده. اون‌ها دیگه مسئولیت مدیریت مستقیم سخت‌افزار یا زیرساخت‌های میزبانی رو ندارن، اما همچنان نقش کلیدی در اجرای موفق اپلیکیشن‌ها ایفا می‌کنن.وظایف تیم عملیات شامل موارد زیر میشه:استقرار (Deployment): راه‌اندازی و به‌روز‌رسانی اپلیکیشن‌ها.نظارت (Monitoring): پیگیری سلامت و عملکرد سیستم.اقدام در برابر مشکلات (Incident Response): واکنش سریع به مشکلات و خطاها.امنیت و بررسی‌های امنیتی (Security Auditing): بررسی امنیت و انطباق با استانداردهای امنیتی.پایش و تحلیل ریشه‌ای مشکلات (Root Cause Analysis): پیدا کردن دلایل اصلی مشکلات.اهمیت ثبت وقایع و ردیابی (Logging & Tracing)یکی از مهم‌ترین ابزارهایی که تیم عملیات برای مدیریت سیستم‌های ابری نیاز داره، ثبت وقایع (Logging) و ردیابی (Tracing) است. در واقع، این دو مورد به عنوان مهم‌ترین منابع برای درک وضعیت سیستم و پیگیری مشکلات به شمار میان. در محیط‌های ابری، به دلیل پیچیدگی و مقیاس بالای سیستم‌ها، بدون داشتن لاگ‌ها و ردگیری‌ها، شناسایی مشکلات و نقاط ضعف به شدت دشوار میشه.ثبت وقایع (Logging)لاگ‌ها شامل رویدادهایی مثل تغییرات وضعیت اپلیکیشن، خطاها و استثناها هستن. این لاگ‌ها به تیم عملیات کمک می‌کنن که در زمان‌های بحرانی، اطلاعات دقیقی درباره اتفاقاتی که افتاده به دست بیارن.ردیابی (Tracing)ردیابی مسیر یک درخواست رو در سیستم دنبال می‌کنه و می‌تونه گلوگاه‌ها و مشکلات عملکردی رو شناسایی کنه. در اپلیکیشن‌های ابری که شامل سرویس‌های متعددی هستن، ردیابی به تیم عملیات کمک می‌کنه که بفهمن کدوم سرویس یا کدوم مرحله در پردازش یک درخواست باعث بروز مشکل شده.توصیه‌ها برای طراحی عملیاتیهمه چیز رو قابل مشاهده کنمشاهده‌پذیری (Observability) یکی از اصول کلیدی در عملیات موفقه. بعد از استقرار سیستم، لاگ‌ها و ردگیری‌ها اصلی‌ترین ابزاری هستن که به تیم عملیات دیدگاهی از داخل سیستم میدن. بنابراین، باید مطمئن بشی که همه بخش‌های سیستم به شکل مناسبی لاگ‌ها و اطلاعات مرتبط رو تولید و ارائه می‌کنن. اگر لاگ‌ها و ردیابی‌ها در محیط تولید فعال نباشن، در لحظاتی که بیشتر از همیشه به اطلاعات نیاز داری، اون‌ها رو از دست می‌دی.ابزارهای نظارت (Monitoring) رو به‌درستی پیاده‌سازی کننظارت (Monitoring) باید دیدی از سلامت و عملکرد سیستم در زمان‌های واقعی (Real-Time) فراهم کنه. نظارت باید شامل اطلاعاتی مثل میزان دسترس‌پذیری، عملکرد و سلامت کلی سیستم باشه. این اطلاعات به تیم عملیات اجازه میده که در صورت مشاهده مشکلات، قبل از اینکه به بحران تبدیل بشن، اقدام کنن. نظارت باید در بالاترین سطح ممکن از زمان واقعی باشه تا تیم بتونه به سرعت به مشکلات واکنش نشون بده و حتی از وقوع اون‌ها جلوگیری کنه.برای توضیحات بیشتر درمورد Prometheus و Application Performance Monitoring مطالعه داشته باشید.ابزارهای تحلیل علت اصلی مشکلات (Root Cause Analysis) رو فراهم کنوقتی مشکلی رخ میده، تحلیل علت اصلی (Root Cause Analysis) به تیم کمک می‌کنه که دلیل بروز مشکل رو پیدا کنه. بنابراین، سیستم باید طوری طراحی بشه که امکان ردیابی دقیق و ارائه اطلاعات لازم برای تشخیص مشکل رو فراهم کنه. استفاده از Distributed Tracing که از شناسه‌های همبسته (Correlation ID) استفاده می‌کنه، در اینجا اهمیت زیادی داره. شناسه‌های همبسته کمک می‌کنن که مسیر یک درخواست از بین سرویس‌های مختلف به شکل دقیق دنبال بشه و علت اصلی خطاها مشخص بشه.برای توضیحات بیشتر درمورد Jaeger مطالعه داشته باشید.استانداردسازی لاگ‌ها و معیارها (Metrics)یکی از مشکلات رایج در سیستم‌های بزرگ اینه که هر سرویس لاگ‌ها و معیارهای خودش رو با قالب و استانداردی متفاوت تولید می‌کنه. این کار باعث میشه جمع‌آوری و تحلیل اطلاعات سخت بشه. برای حل این مشکل، از استانداردسازی استفاده کن. همه سرویس‌ها باید از یک طرح مشترک برای ثبت لاگ‌ها استفاده کنن که شامل اطلاعات مهم مثل شناسه‌های همبسته، نام رویداد، آدرس IP فرستنده و غیره باشه.برای توضیحات بیشتر درمورد Open Telemetry مطالعه داشته باشید.اتوماتیک سازی وظایف (Automation)اتوماسیون وظایف عملیاتی مثل استقرار (Deployment)، نظارت (Monitoring) و پیاده‌سازی (Provisioning) باعث میشه این فرآیندها تکرارپذیر و کمتر وابسته به خطاهای انسانی باشن. وظایف دستی معمولاً احتمال بروز خطا دارن، اما وقتی این فرآیندها رو اتومات کنی، دقت و سرعت کارها به شکل چشمگیری افزایش پیدا می‌کنه.برای توضیحات بیشتر درمورد Ansible مطالعه داشته باشید.استفاده از تنظیمات به‌عنوان کد (Configuration as Code)تنظیمات به‌عنوان کد (Configuration as Code) یکی از اصول مهم در مدیریت عملیات مدرن است. فایل‌های پیکربندی باید به شکلی مدیریت بشن که تغییرات اون‌ها قابل ردیابی و نسخه‌بندی باشن. با استفاده از سیستم‌های کنترل نسخه (Version Control)، می‌تونی تغییرات تنظیمات رو دنبال کنی و در صورت بروز مشکل، به راحتی به نسخه قبلی برگردی.برای توضیحات بیشتر درمورد GitOps مطالعه داشته باشید.طراحی برای عملیات به این معنیه که از همون ابتدای طراحی، سیستم رو طوری بسازی که تیم عملیات به راحتی بتونه عملکرد، سلامت و امنیت سیستم رو مدیریت کنه. با پیاده‌سازی ابزارهای مشاهده‌پذیری مثل لاگ‌ها و ردیابی، استانداردسازی داده‌های عملیاتی، و اتوماسیون فرآیندهای کلیدی، می‌تونی سیستمی بسازی که نه تنها مقیاس‌پذیر باشه، بلکه به راحتی مدیریت و نگهداری بشه.پایانامیدوارم که واستون مفید بوده باشه!منابع:https://learn.microsoft.com/en-us/azure/architecture/guide/design-principles/partitionhttps://learn.microsoft.com/en-us/azure/architecture/guide/design-principles/design-for-operations سجاد غفاریان سجاد غفاریان Mon, 14 Oct 2024 14:29:50 +0330 https://virgool.io/@SajjadGhafarian/scalable-system-design-principles-part-2-zgcamhqfrdwx در ادامه‌ی قسمت قبلی که در مورد طراحی برای خودترمیمی (Self-Healing) و ایجاد افزونگی در همه اجزا (Redundancy) صحبت کردیم، توی این مقاله می‌خوایم به سراغ دو اصل دیگه بریم که می‌تونن تأثیر زیادی روی مقیاس‌پذیری و کارایی سیستم داشته باشن: Minimize Coordination و Design to Scale Out.این اصول بهت کمک می‌کنن تا سیستمی بسازی که نه تنها مقاوم و پایدار باشه، بلکه بتونه به راحتی با رشد نیازمندی‌ها و افزایش ترافیک، خودش رو وفق بده.لینک بخش اول از این سری مقاله - اصول طراحی نرم‌افزارها و سیستم‌های مقیاس‌پذیرچرا باید به این اصول توجه کنیم؟وقتی داری یه سیستم بزرگ و پیچیده می‌سازی، یکی از مشکلات رایجی که باهاش مواجه می‌شی، افزایش وابستگی‌ها و هماهنگی بین بخش‌های مختلفه. هر چه میزان هماهنگی بین کامپوننت‌ها بیشتر بشه، احتمال بروز خطا و کاهش کارایی هم بالاتر میره. در واقع، هماهنگی زیاد، مثل یه ترافیک سنگین توی یه چهارراه شلوغه؛ هر چقدر هم که ماشین‌ها منظم حرکت کنن، کوچک‌ترین مشکل یا تأخیر می‌تونه کل سیستم رو دچار اختلال کنه.اینجاست که مفهوم Minimize Coordination یا کاهش وابستگی‌ها و هماهنگی بین کامپوننت‌ها مطرح میشه. این اصل بهت میگه که باید تا جایی که ممکنه، هر بخش از سیستم رو مستقل و بدون نیاز به ارتباطات پیچیده طراحی کنی. با این کار، هر کامپوننت می‌تونه به صورت جداگانه مقیاس‌پذیر بشه و حتی اگه یکی از اون‌ها از کار بیفته، بقیه بخش‌ها بدون مشکل به کار خودشون ادامه بدن.اما کاهش هماهنگی به تنهایی کافی نیست. باید مطمئن بشی که سیستم به راحتی قابل گسترش (Scale) باشه. اینجاست که اصل Design to Scale Out یا طراحی برای مقیاس‌پذیری افقی وارد میشه. این اصل به این معنیه که سیستم رو طوری بسازی که بتونی با افزایش یا کاهش تعداد Instanceها (سرورها، سرویس‌ها یا منابع)، عملکرد و ظرفیتش رو تنظیم کنی، بدون اینکه معماری یا زیرساخت رو تغییر بدی.توی این مقاله، میبینیم که چطور می‌تونیم با کاهش وابستگی‌ها و هماهنگی‌های پیچیده بین بخش‌ها، و پیاده‌سازی یه معماری مناسب برای مقیاس‌پذیری افقی، میتونیم یه سیستم بسازیم که نه تنها تحت بار زیاد دچار مشکل نمیشه، بلکه می‌تونه به سرعت خودش رو با شرایط جدید وفق بده و همچنان عملکرد خوبی داشته باشه.به حداقل رساندن هماهنگی بین کامپوننت‌ها برای دستیابی به مقیاس‌پذیری (Minimize Coordination)یکی از چالش‌های بزرگ در طراحی سیستم‌های پیچیده اینه که با افزایش مقیاس، هماهنگی بین کامپوننت‌ها هم بیشتر میشه. این هماهنگی گاهی می‌تونه خودش به عنوان یه مانع جدی بر سر راه مقیاس‌پذیری و کارایی سیستم عمل کنه. اصل Minimize Coordination (به حداقل رسوندن هماهنگی)، به این نکته اشاره داره که هرچه وابستگی‌ها و تعاملات بین بخش‌های مختلف سیستم رو کمتر کنی، سیستم راحت‌تر و سریع‌تر می‌تونه رشد کنه و به مقیاس‌های بالاتر برسه.چرا هماهنگی زیاد مشکل‌ساز میشه؟وقتی یک سیستم توزیع‌شده (Distributed System) داری، معمولاً اجزای مختلف مثل پایگاه داده‌ها، سرویس‌های پردازشی، و سرویس‌های ارتباطی، همگی نیاز به همگام‌سازی (Synchronization) دارن تا نتیجه نهایی به درستی تولید بشه. اما این هماهنگی باعث ایجاد تنگناها و محدودیت‌هایی میشه که در نهایت، به کاهش کارایی و سرعت منجر میشه.برای مثال، تصور کن دو سرویس مختلف سعی کنن همزمان روی یک دیتابیس مشترک تغییراتی ایجاد کنن. در این حالت، برای حفظ یکپارچگی داده‌ها، سیستم مجبور میشه از قفل‌ها (Locks) و هماهنگی‌های پیچیده‌ای استفاده کنه. این کار باعث میشه که هر سرویس منتظر بمونه تا سرویس دیگه کارش رو تموم کنه و این انتظارها می‌تونه سرعت سیستم رو به شدت پایین بیاره.هماهنگی به چه شکل‌هایی وجود داره؟هماهنگی معمولاً در سطوح مختلف مثل داده‌ها (Data) و محاسبات (Compute) اتفاق می‌افته. برای مثال، در سطح داده‌ها، سرویس‌ها ممکنه نیاز داشته باشن که برای حفظ ACID (اتمی بودن، سازگاری، ایزوله بودن و پایداری) از قفل‌های دیتابیس استفاده کنن. در سطح محاسبات هم، هماهنگی ممکنه برای مدیریت توزیع کارها بین سرویس‌ها یا جلوگیری از دوباره‌کاری‌ها (Duplicate Processing) نیاز باشه.در نتیجه، به حداقل رسوندن این هماهنگی‌ها بهت کمک می‌کنه که سرعت سیستم رو بالا ببری و بدون ایجاد تنگنا، به راحتی مقیاس‌پذیری افقی رو پیاده‌سازی کنی.چطور میشه هماهنگی‌ها رو به حداقل رسوند؟استفاده از کامپوننت‌های جدا و ارتباطات غیرهمزمان: یکی از راه‌های کاهش هماهنگی، اینه که کامپوننت‌ها به صورت مستقل و بدون نیاز به هماهنگی با هم کار کنن. این کار رو می‌تونی با استفاده از ارتباطات غیرهمزمان (Asynchronous Communication) و پیام‌محور (Event-Driven) پیاده‌سازی کنی. در این مدل، کامپوننت‌ها به جای اینکه مستقیماً با هم درگیر باشن، از طریق پیام‌ها یا رویدادها با هم ارتباط می‌گیرن.پذیرش همگرایی نهایی (Eventual Consistency): به جای تلاش برای حفظ سازگاری قوی (Strong Consistency) که نیاز به هماهنگی‌های زیادی داره، می‌تونی به سمت سازگاری نهایی (Eventual Consistency) حرکت کنی. یعنی داده‌ها ممکنه برای مدتی با هم همگام نباشن، اما در نهایت به یک وضعیت پایدار برسن. اینکار نیاز به هماهنگی رو به شدت کاهش می‌ده.استفاده از پترن‌هایی مثل CQRS و Event Sourcing: با استفاده از پترن CQRS (جداسازی خواندن و نوشتن)، می‌تونی عملیات‌های نوشتن و خواندن رو از هم جدا کنی تا هر کدوم مسیرهای مستقل خودشون رو داشته باشن و روی همدیگه اثر منفی نذارن.با پترن Event Sourcing، تغییرات وضعیت سیستم رو به شکل رویدادها (Events) ذخیره می‌کنی. این کار نیاز به قفل‌های دیتابیس و هماهنگی‌های پیچیده رو از بین می‌بره، چون هر تغییری به شکل یک رویداد مجزا ثبت میشه.پارتیشن‌بندی داده‌ها و وضعیت‌ها (Partition Data and State): با تقسیم داده‌ها به پارتیشن‌ها یا Shardهای جداگانه، هر سرویس می‌تونه بدون نیاز به هماهنگی با بقیه، روی بخش خودش کار کنه. مثلاً اگه یه دیتابیس بزرگ داری، اون رو به چند بخش مستقل تقسیم کن تا سرویس‌ها فقط روی بخش خودشون تمرکز کنن. این کار، نیاز به هماهنگی بین سرویس‌ها رو به شدت کاهش میده.طراحی عملیات‌های Idempotent: عملیات‌های Idempotent به این معنی هستن که حتی اگه یک عملیات چندین بار تکرار بشه، نتیجه نهایی همچنان یکسان می‌مونه. با این روش، اگه یکی از سرویس‌ها وسط کار دچار مشکل بشه، سرویس دیگه‌ای می‌تونه ادامه کار رو انجام بده، بدون اینکه نیاز به هماهنگی پیچیده‌ای باشه.استفاده از Optimistic Concurrency: به جای قفل کردن منابع (که باعث کاهش کارایی میشه)، از مدل‌های Optimistic Concurrency استفاده کن. در این مدل، هر تراکنش روی یک نسخه کپی از داده‌ها کار می‌کنه و در زمان ذخیره‌سازی نهایی، سیستم بررسی می‌کنه که آیا داده‌ها تغییر کرده‌اند یا نه. این روش باعث کاهش نیاز به قفل‌ها و هماهنگی‌های سنگین میشه.استفاده از پترن‌های موازی‌سازی مثل Map-reduce: اگه کارهای زیادی داری که میشه به صورت مستقل انجام داد، اون‌ها رو به وظایف کوچیک‌تر تقسیم کن و روی چندین نود مختلف به صورت موازی اجرا کن. این کار نیاز به هماهنگی رو به حداقل می‌رسونه و بهت کمک می‌کنه از مقیاس‌پذیری افقی بهره‌مند بشی.استفاده از پترن انتخاب رهبر (Leader Election): بعضی وقت‌ها هماهنگی اجتناب‌ناپذیره، در این موارد از پترن Leader Election استفاده کن تا همیشه یه هماهنگ‌کننده داشته باشی و اگه از کار افتاد، نود جدیدی به عنوان رهبر انتخاب بشه و هماهنگی رو ادامه بده.(درمورد این موضوع روی الگوریتم raft هم یک مقدار مطالعه داشته باشین)به حداقل رسوندن هماهنگی بین بخش‌های مختلف سیستم، بهت کمک می‌کنه که تنگناها و مشکلات عملکردی رو کاهش بدی و به راحتی سیستمت رو در مقیاس‌های بالاتر گسترش بدی. با استفاده از روش‌هایی مثل تقسیم‌بندی داده‌ها، استفاده از ارتباطات غیرهمزمان، پذیرش همگرایی نهایی و پیاده‌سازی پترن‌های مناسب، می‌تونی سیستمی بسازی که علاوه بر سرعت و کارایی بالا، در برابر خطاها هم مقاوم باشه و به راحتی مقیاس‌پذیری افقی رو پیاده‌سازی کنه.طراحی برای مقیاس‌پذیری افقی (Design to Scale Out)مقیاس‌پذیری افقی یکی از اصول کلیدی در طراحی سیستم‌های مدرن است که بهت اجازه میده با افزایش تعداد منابع (مثل سرورها، سرویس‌ها یا نودها)، ظرفیت و عملکرد سیستم رو متناسب با نیاز بالا ببری. این قابلیت، به ویژه توی محیط‌های ابری (Cloud)، اهمیت بیشتری پیدا می‌کنه چون می‌تونی بر اساس نیاز لحظه‌ای، منابع رو به صورت داینامیک اضافه یا کم کنی.به عبارت ساده، مقیاس‌پذیری افقی یعنی به جای ارتقا دادن قدرت سخت‌افزاری یک سرور (Scale Up)، تعداد بیشتری سرور رو به مجموعه اضافه کنی تا بار رو بین این سرورها توزیع کنی.مزیت مقیاس‌پذیری افقی در سیستم‌های ابریدر محیط‌های ابری، یکی از بزرگترین مزیت‌ها اینه که می‌تونی از مقیاس‌پذیری الستیک (Elastic Scaling) استفاده کنی. به این معنی که هر وقت ترافیک بالایی وارد شد، سرورها و سرویس‌های بیشتری اضافه می‌کنی و وقتی بار کاهش پیدا کرد، این منابع اضافی رو حذف می‌کنی تا هزینه‌ها رو بهینه‌سازی کنی. این انعطاف‌پذیری در محیط‌های ابری، بهت اجازه می‌ده بدون نیاز به نگرانی از بابت کمبود منابع، پاسخگوی هر نوع حجم کاری (Workload) باشی.چالش‌های مقیاس‌پذیری افقیطراحی برای مقیاس‌پذیری افقی خیلی ساده به نظر می‌رسه: «چندتا سرور اضافه کن و تموم!» اما در واقع، موانعی مثل گلوگاه‌ها (Bottlenecks) و نقاط همگام‌سازی (Synchronization Points) می‌تونن به شدت روی عملکرد و مقیاس‌پذیری تأثیر بذارن، در یک سیستم ایده‌آل، وقتی تعداد منابع دو برابر میشه، باید بتونی عملکرد سیستم رو هم دو برابر کنی. ولی در دنیای واقعی، این نسبت به ندرت به شکل کامل اتفاق می‌افته، چون معمولاً بعضی بخش‌های سیستم دچار تنگناهایی میشن که با افزایش منابع، نتیجه بهینه‌ای به دست نمیاد.اصول مهم برای پیاده‌سازی مقیاس‌پذیری افقیاجتناب از Instance Stickiness: چسبندگی یا Session Affinity به این معنیه که درخواست‌های یک کاربر همیشه به همون سرور یا سرویس خاص ارسال بشه. این اتفاق معمولاً به خاطر ذخیره‌سازی حالت (State) در حافظه محلی یا استفاده از کلیدهای رمزنگاری منحصر به‌فرد برای هر سرور رخ میده. اما این کار باعث میشه نتونی به راحتی سرورها رو اضافه یا کم کنی، چون بار درخواست‌ها روی چندتا سرور خاص متمرکز میشه. بنابراین، باید کاری کنی که هر Instance بتونه هر درخواست رو پردازش کنه.شناسایی و رفع گلوگاه‌ها (Bottlenecks): اضافه کردن منابع همیشه راه‌حل نیست! اگه مشکل اصلی توی پایگاه داده یا سرویس‌های Back-end باشه، اضافه کردن تعداد بیشتری سرور جلویی (Front-end) کمکی نمی‌کنه. قبل از پیاده‌سازی مقیاس‌پذیری افقی، گلوگاه‌ها و نقاط بحرانی رو شناسایی کن و رفعشون کن.تقسیم کارها بر اساس نیازمندی‌های مقیاس‌پذیری: اپلیکیشن‌ها معمولاً از چندین Workload مختلف تشکیل شدن که هر کدومشون نیازهای متفاوتی برای مقیاس‌پذیری دارن. مثلاً یه بخش ممکنه دائماً درگیر درخواست‌های کاربر باشه و نیاز به مقیاس‌پذیری بالا داشته باشه، در حالی که یه بخش دیگه بار کمتری داره و به مقیاس‌پذیری زیادی نیاز نداره. هر Workload رو جداگانه مدیریت کن تا بتونی فقط بخش‌هایی که نیاز دارن رو مستقل مقیاس‌دهی کنی.استفاده از کامپوننت‌های مستقل و غیرهمگام (Asynchronous Communication): بهتره کامپوننت‌ها از طریق پروتکل‌های غیرهمزمان با هم ارتباط برقرار کنن و به شکل مستقل کار کنن. این کار باعث میشه هر کامپوننت بتونه بدون نیاز به هماهنگی با بقیه، به راحتی مقیاس‌پذیر بشه. از مکانیزم‌هایی مثل Message Queue استفاده کن تا بتونی بار اضافی رو مدیریت و در زمان مناسب پردازش کنی.پرهیز از هماهنگی و انتظارهای بی‌مورد: هماهنگی زیاد و انتظار برای منابع مشترک، قاتل مقیاس‌پذیریه. همیشه به دنبال راه‌حل‌هایی باش که نیاز به این نوع تعاملات رو کم کنی. مثلاً به جای تراکنش‌های سنگین، از همگرایی نهایی (Eventual Consistency) استفاده کن.انتقال وظایف سنگین به پس‌زمینه (Offload Resource-Intensive Tasks): کارهایی که منابع زیادی مصرف می‌کنن، مثل پردازش‌های سنگین یا عملیات I/O، رو به پس‌زمینه (Background Jobs) منتقل کن تا فشار از روی سرویس‌هایی که درخواست‌های کاربران رو مدیریت می‌کنن، برداشته بشه.پیاده‌سازی مکانیزمهای مقیاس‌پذیری خودکار (Auto-scaling): یکی از مهم‌ترین ابزارها برای مقیاس‌پذیری افقی، استفاده از auto-scaling بر اساس معیارهای عملکردی مثل میزان استفاده از CPU یا طول صف درخواست‌هاست. اگه Workloadهایت پیش‌بینی‌پذیر هستن، از زمان‌بندی استفاده کن تا در ساعات اوج کار، سرورها رو اضافه کنی و در ساعات کم‌بار، منابع اضافی رو حذف کنی.(یکی از قابلیت هایی که پلتفرمهایی مثل کوبرنتیز به ما میدن، همین موضوع هستش)طراحی برای مقیاس‌دهی معکوس (Scale In): باید سیستمت رو طوری طراحی کنی که وقتی نیاز به منابع اضافی نداری، بتونی به راحتی اون‌ها رو حذف کنی، بدون اینکه روی عملکرد کلی سیستم تأثیر بذاره. مطمئن شو که عملیات‌ها به شکل Idempotent طراحی شدن و می‌تونن بعد از حذف یا قطع یک Instance، کارشون رو از همون نقطه ادامه بدن.مدل‌سازی و بهینه‌سازی مقیاس‌پذیری (Model and Optimize Scalability): از مدل‌سازی‌هایی مثل Amdahl استفاده کن تا بفهمی کدوم قسمت‌های سیستم قابل موازی‌سازی هستن و کجاها همچنان نیاز به هماهنگی و همگام‌سازی وجود داره. این کار بهت کمک می‌کنه نقاط ضعف سیستمت رو شناسایی کنی و بفهمی کجا باید روی بهبود مقیاس‌پذیری تمرکز کنی.طراحی برای مقیاس‌پذیری افقی، یک اصل حیاتی در ساخت سیستم‌های بزرگ و پیچیده است که می‌خوای همزمان پایدار و انعطاف‌پذیر باشن. با پیاده‌سازی اصولی مثل اجتناب از Session Affinity، تقسیم‌بندی Workloadها، استفاده از ارتباطات غیرهمزمان و پیاده‌سازی Autoscaling، می‌تونی سیستمی بسازی که همزمان با رشد نیازها، رشد کنه و در زمان کاهش بار، هزینه‌ها رو کاهش بده.در نهایت، هدف از این نوع طراحی اینه که بتونی سیستمی بسازی که همواره با شرایط سازگار بشه و بدون هیچ نقطه گلوگاهی، همچنان سریع و پاسخگو باقی بمونه.پایانامیدوارم که واستون مفید بوده باشه!منابع:https://learn.microsoft.com/en-us/azure/architecture/guide/design-principles/minimize-coordinationhttps://learn.microsoft.com/en-us/azure/architecture/guide/design-principles/scale-out سجاد غفاریان سجاد غفاریان Wed, 02 Oct 2024 13:47:36 +0330 https://virgool.io/@SajjadGhafarian/scalable-system-design-principles-ebx87ft4jtxs توی این سری مقالات، قراره به مفاهیم و اصولی بپردازیم که اگه به درستی پیاده‌سازی بشن، بهت کمک می‌کنن تا یک سیستم مقیاس‌پذیر (Scalable)، پایدار (Stable) و قابل اعتماد (Reliable) بسازی. وقتی در مورد طراحی سیستم‌های پیچیده صحبت می‌کنیم، مخصوصاً سیستم‌های توزیع‌شده (Distributed Systems)، نکته اصلی اینه که بدونیم سیستممون قراره در دنیای واقعی با چه چالش‌هایی روبرو بشه. این چالش‌ها می‌تونن از ترافیک‌های سنگین و ناگهانی گرفته تا خرابی‌های سخت‌افزاری، مشکلات شبکه، یا حتی قطع شدن کل دیتاسنتر باشن.اینجاست که داشتن یه طراحی اصولی و قوی، اهمیت خودش رو نشون میده. طراحی درست، چیزی فراتر از نوشتن کد خوبه؛ باید بدونیم چطور اجزای سیستم رو کنار هم بچینیم، از ابزارهای موجود استفاده کنیم و معماری‌ای بسازیم که در برابر خطاها مقاوم باشه و بتونه بدون افت کارایی به راحتی گسترش پیدا کنه.لیست اصول طراحی که قراره در این سری مقالات بررسی کنیم:Design for Self-Healing (طراحی برای خودترمیمی)Make Everything Redundant (ایجاد افزونگی در همه چیز)Minimize Coordination (به حداقل رسوندن هماهنگی بین کامپوننت‌ها)Design to Scale Out (طراحی برای مقیاس‌پذیری افقی)Partition Around Limits (پارتیشن‌بندی براساس محدودیت‌ها)Design for Operations (طراحی برای عملیات و نگهداری)Design for Evolution (طراحی برای تکامل‌پذیری)Build for Business Needs (طراحی بر اساس نیازهای کسب‌وکار)توی این مقاله می‌خوایم دو تا از مهم‌ترین اصول اولیه رو بررسی کنیم:طراحی برای Self-Healing: اینکه سیستم بتونه در مواجهه با خطاها و مشکلات، به شکل خودکار ریکاوری کنه و نیاز به دخالت انسانی رو به حداقل برسونه.ایجاد افزونگی در همه چیز: اگه می‌خوای یک سیستم واقعاً پایدار و قابل اعتماد داشته باشی، باید برای هر بخشی از سیستم یه نسخه پشتیبان یا جایگزین داشته باشی. اینجوری وقتی یکی از اجزا دچار مشکل میشه، بقیه سیستم همچنان به کار خودش ادامه میده.هدف اینه که با بررسی این اصول، متوجه بشیم چطور می‌تونیم طراحی‌ای داشته باشیم که نه تنها با خطاها به خوبی کنار بیاد، بلکه حتی در مواجهه با فشارهای بالا و تغییرات ناگهانی هم بدون مشکل به کار خودش ادامه بده.توی این مقاله می‌خوایم وارد جزییات بشیم و بهت نشون بدیم چطور با رعایت این دو اصل، می‌تونی بنیان یه سیستم پایدار و مقاوم رو بذاری که حتی توی شرایط بحرانی هم عملکرد خوبی داشته باشه. پس با من همراه باش تا این دو کانسپت رو به زبون ساده و با مثال‌های واقعی بررسی کنیم!وقتی داری یک اپلیکیشن رو طراحی می‌کنی، یکی از نکات مهم اینه که بتونه در مواجهه با خطاها، خودش به طور خودکار بازیابی بشه (Self-Healing). توی سیستم‌های توزیع‌شده، خطاها اجتناب‌ناپذیرن و باید همیشه انتظارشون رو داشته باشی. ممکنه سخت‌افزار خراب بشه، شبکه دچار قطعی موقت بشه، یا ارتباطات بین سرویس‌ها به مشکل بخوره. حتی اگه این اتفاق‌ها کم پیش بیان، نباید فقط به خطاهای کوچک محدود فکر کنی؛ باید سیستم رو طوری طراحی کنی که در مواجهه با سناریوهای بحرانی مثل خرابی کل یک دیتاسنتر هم مقاوم باشه.اصول طراحی برای Self-Healingبرای طراحی سیستمی که خودش بتونه از پس مشکلات بر بیاد، باید این سه مرحله رو در نظر بگیری:تشخیص خطاها: سیستم باید بتونه خیلی سریع و دقیق متوجه بشه که چه خطایی و کجا رخ داده.واکنش مناسب به خطاها: وقتی خطا اتفاق می‌افته، سیستم باید بتونه بدون اختلال زیاد، به شکل مناسبی واکنش نشون بده و سرویس‌دهی رو ادامه بده.ثبت و مانیتورینگ خطاها: برای اینکه تیم عملیات بتونه مشکلات رو ریشه‌یابی کنه و کیفیت سیستم رو بالا ببره، باید لاگ‌ها و گزارش‌های دقیق از خطاها داشته باشه.انتخاب نحوه واکنش به خطانحوه واکنش به هر نوع خطا، بستگی به نیازمندی‌های دسترسی‌پذیری (Availability) اپلیکیشنت داره. مثلاً اگه به دسترسی‌پذیری بالا نیاز داری، می‌تونی از چندین Availability Zone استفاده کنی یا برای سناریوهای بحرانی، سوییچ اتوماتیک به Region پشتیبان (Fail-over) داشته باشی. این کار از قطع شدن سرویس در بدترین شرایط هم جلوگیری می‌کنه، ولی به هزینه و پیچیدگی سیستم اضافه می‌کنه.اما تمرکزت نباید فقط روی رویدادهای بزرگ باشه. خطاهای کوتاه‌مدت و محلی مثل از دست رفتن موقتی شبکه یا قطع شدن ارتباط با دیتابیس هم می‌تونه تأثیر زیادی روی تجربه کاربر داشته باشه. طراحی درست به این معنیه که برای این نوع خطاها هم راه‌حل‌هایی پیش‌بینی کنی.توصیه‌ها برای طراحی سیستم‌های مقاوم و خودترمیم (Self-Healing):استفاده از کامپوننت‌های مستقل و ارتباطات غیرهمزمان (Asynchronous): کامپوننت‌ها رو طوری طراحی کن که به صورت مستقل کار کنن و برای ارتباط، به جای درخواست مستقیم، از الگوهای رویدادمحور (Event-Driven) استفاده کنن. اینجوری اگه یک کامپوننت به مشکل بخوره، بقیه سیستم مختل نمیشه و از خطاهای زنجیره‌ای جلوگیری میشه.پیاده‌سازی منطق Retry برای مدیریت خطاهای موقت (Transient Failures): خطاهای موقتی مثل از دست دادن ارتباط شبکه، قطع شدن دیتابیس، یا مشغول بودن سرویس‌ها همیشه اتفاق می‌افتن. پس منطق Retry رو توی کدت پیاده‌سازی کن تا این خطاها رو مدیریت کنه.استفاده از پترن‌هایی مثل Circuit Breaker برای جلوگیری از تکرار خطاهای مداوم: اگه یک سرویس در طولانی‌مدت مشکل داشته باشه، تکرار درخواست‌ها می‌تونه به خطاهای زنجیره‌ای منجر بشه. الگویی مثل Circuit Breaker به سیستم میگه تا وقتی احتمال موفقیت کمه، دیگه به اون سرویس درخواست نفرسته و سریعاً خطا رو گزارش بده.ایزوله کردن منابع حیاتی با پترن Bulkhead: بعضی وقت‌ها خطا توی یک بخش از سیستم می‌تونه باعث بشه منابعی مثل Threadها و Socketها بیش از حد مصرف بشه و سیستم دچار اختلال بشه. پترن Bulkhead این منابع رو جدا می‌کنه تا خطا توی یک بخش، بقیه سیستم رو تحت تأثیر قرار نده.استفاده از Load Leveling برای کنترل نوسانات بار: نوسانات ترافیک می‌تونن به بک‌اند فشار بیارن، از الگوی Queue-Based Load Leveling استفاده کن تا درخواست‌ها رو در صف نگه داری و به شکل یکنواخت‌تر پردازش کنی.پیاده‌سازی Fail-over: اگه یک Instance از دسترس خارج شد، به صورت خودکار به یک Instance دیگه سوییچ کن. برای سرویس‌های Stateless مثل وب‌سرورها، می‌تونی از Load Balancer استفاده کنی. برای سرویس‌هایی که داده رو ذخیره می‌کنن (Stateful)، از Replicaها و Fail-over استفاده کن.جبران خطاهای تراکنشی با Compensating Transactions: به جای تراکنش‌های توزیع‌شده که هماهنگی بالایی نیاز دارن، از چندین تراکنش کوچک‌تر استفاده کن. اگه تراکنش در وسط راه شکست خورد، با تراکنش جبرانی (Compensation) مراحل قبلی رو برگردون(یا به زبان دیگه، rollback صورت بگیره).استفاده از Checkpoint برای تراکنش‌های طولانی‌مدت: تراکنش‌های طولانی‌مدت ممکنه در وسط کار متوقف بشن. با استفاده از Checkpointها، وضعیت (State) عملیات رو ذخیره کن تا اگه سیستم متوقف شد، از همون نقطه ادامه بده.ارائه‌ی نسخه ساده‌تر و کاربردی (Graceful Degradation): اگه نتونی همه‌ی قابلیت‌ها رو ارائه بدی، یه نسخه ساده‌تر ولی کاربردی رو ارائه بده. مثلاً اگه تصاویر محصولات لود نشدن، از تصویر پیش‌فرض استفاده کن.استفاده از Throttling: اگه یه کلاینت بار زیادی روی سیستم ایجاد کرد، برای مدت کوتاهی درخواست‌هاش رو محدود کن.استفاده از الگوی Leader Election برای هماهنگی وظایف: اگه نیاز به هماهنگی مرکزی داری، از Leader Election استفاده کن تا نقش هماهنگ‌کننده به یک سرویس داده بشه و در صورت از کار افتادن، سرویس دیگه‌ای جاش رو بگیره.تست با Fault Injection و Chaos Engineering: از Fault Injection و Chaos Engineering استفاده کن تا پایداری سیستم رو در شرایط بحرانی واقعی یا شبیه‌سازی شده بسنجی.استفاده از Availability Zones برای دسترسی‌پذیری بالا: با توزیع منابع توی Availability Zoneهای مختلف، سیستم رو در برابر خرابی‌های منطقه‌ای مقاوم کن و دسترسی‌پذیری رو به حداکثر برسون.با استفاده از این الگوها، سیستم تو مقاوم‌تر، انعطاف‌پذیرتر و خودترمیم (Self-Healing)تر میشه و در صورت بروز هر خطا، بدون نیاز به دخالت زیاد، خودش به حالت پایدار برمی‌گرده.یکی دیگر از اصول اساسی در طراحی سیستم‌های مقاوم و پایدار، افزایش افزونگی (Redundancy) در تمام بخش‌های اپلیکیشن است. به عبارت ساده، ایجاد افزونگی به این معنیه که هیچ قسمتی از سیستم نباید به تنهایی نقطه ضعف بحرانی باشه که با خرابی اون، کل سیستم دچار اختلال بشه. داشتن افزونگی در همه بخش‌ها باعث میشه حتی اگه یکی از اجزای سیستم از کار بیفته، بقیه اجزا بتونن به کار خودشون ادامه بدن و سیستم به شکل خودکار مسیر خودش رو به سمت منابع سالم هدایت کنه.چرا افزونگی مهمه؟افزونگی در واقع یه لایه حفاظتی به سیستم اضافه می‌کنه تا در مواجهه با هرگونه خرابی، سیستم همچنان پایدار بمونه و به کار خودش ادامه بده. به این ترتیب، اپلیکیشن تو فقط در صورتی از کار میفته که تمامی اجزای جایگزین همزمان دچار مشکل بشن که احتمال وقوع چنین اتفاقی خیلی کمتره. این لایه حفاظتی می‌تونه در هر جایی از سیستم باشه: از لایه سخت‌افزار و شبکه گرفته تا سرویس‌ها و پایگاه‌های داده.اما نکته‌ای که نباید ازش غافل بشی اینه که میزان Redundancy‌ای که در معماری سیستم پیاده می‌کنی، مستقیماً روی هزینه، پیچیدگی و عملکرد سیستم اثر می‌ذاره. پس همیشه باید بدونی چه جاهایی واقعاً به افزونگی نیاز داره و کجاها میشه با یه راه‌حل ساده‌تر به نتیجه رسید.نکات کلیدی در طراحی افزونگیبرای داشتن یه معماری مقاوم و Redundant، بهتره این اصول رو در نظر بگیری:شناسایی مسیرهای بحرانی: قبل از هر چیزی، باید مسیرهای حیاتی (Critical Paths) رو توی اپلیکیشن شناسایی کنی. یعنی بررسی کنی که کدوم بخش‌ها برای کارکرد صحیح سیستم ضروری هستن. بعد از شناسایی، باید افزونگی رو به این بخش‌ها اضافه کنی. این افزونگی می‌تونه شامل نسخه‌های پشتیبان، سرویس‌های جایگزین، یا حتی فرآیندهای موازی باشه که به محض بروز خطا فعال می‌شن.انتخاب سطح افزونگی بر اساس نیازمندی‌ها: مقدار افزونگی باید براساس نیازهای کسب‌وکار، میزان تحمل خرابی (Fault Tolerance) و اهداف بازیابی (مثل RTO و RPO) مشخص بشه. مثلاً اگه برای کسب‌وکار، از دست دادن چند دقیقه سرویس مشکلی نداره، می‌تونی از افزونگی کمتر و ساده‌تر استفاده کنی. اما اگه نیاز به دسترسی‌پذیری بالا (High Availability) داری و حتی چند ثانیه قطعی می‌تونه مشکل‌ساز بشه، باید سیستم رو با افزونگی بالاتر و با چندین سطح محافظتی طراحی کنی.استفاده از چندین نسخه از منابع: یکی از پایه‌های افزونگی اینه که از چندین نسخه از یک منبع استفاده کنی. به عنوان مثال به جای استفاده از یک سرور، چند سرور رو پشت یه Load Balancer قرار بده تا اگه یکی از اون‌ها از دسترس خارج شد، بقیه همچنان درخواست‌ها رو پاسخ بدن و یا داده‌ها رو در چندین پایگاه داده ذخیره کن تا اگه یکی دچار مشکل شد، به راحتی به پایگاه داده دیگه‌ای سوییچ کنی.تقسیم منابع (Partitioning): تقسیم منابع نه تنها به مقیاس‌پذیری کمک می‌کنه، بلکه به افزایش دسترسی‌پذیری هم کمک زیادی می‌کنه. به این صورت که سیستم رو به بخش‌های کوچک‌تر (Partitions یا Shards) تقسیم می‌کنی. اگه یکی از این بخش‌ها دچار خطا بشه، بقیه بخش‌ها همچنان قابل دسترس خواهند بود و فقط بخش کوچکی از کل سیستم تحت تأثیر قرار می‌گیره. مثلاً اگه یه پایگاه داده بزرگ داری، می‌تونی اون رو به چندین بخش کوچک‌تر تقسیم کنی تا اگه یکی از بخش‌ها دچار مشکل شد، بقیه همچنان به کار خودشون ادامه بدن.پیاده‌سازی Fail-over: یکی از راهکارهای کلیدی برای افزونگی، پیاده‌سازی مکانیزم Fail-over هست. این یعنی اگه یکی از منابع در دسترس نباشه، سیستم به طور خودکار به یک منبع جایگزین سوییچ کنه. این کار رو می‌تونی برای هر نوع منبعی پیاده‌سازی کنی.حفظ سازگاری داده‌ها (Data Consistency): وقتی از افزونگی در لایه پایگاه داده استفاده می‌کنی، همیشه یه چالش به اسم سازگاری داده‌ها داری. وقتی داده‌ها بین چندین پایگاه داده یا کپی میشن، باید مکانیزمی داشته باشی که همزمانی و هماهنگی بین این داده‌ها رو تضمین کنه. اینجوری اگه به پایگاه داده دیگه‌ای سوئیچ کنی، مطمئنی که داده‌ها درست و به‌روز هستن.برنامه‌ریزی برای بازیابی (Recovery Planning): یه برنامه دقیق برای بازیابی داشته باش. این برنامه باید شامل چک‌لیست‌ها و پروتکل‌هایی باشه که نشون بده چه زمانی باید Fail-over انجام بشه و چطور سیستم رو به حالت نرمال برگردونی (Failback). همینطور باید مانیتورینگ و بررسی سلامت سیستم داشته باشی تا مطمئن شی همه چیز درست کار می‌کنه.ایجاد افزونگی در مسیریابی (Routing Redundancy): مسیریابی به همون اندازه که منابع فیزیکی اهمیت دارن، نقش مهمی در طراحی افزونگی داره. مسیرهای روتینگ باید همیشه یه مسیر جایگزین داشته باشن که در صورت خرابی مسیر اصلی، همچنان ترافیک به مقصد برسه.مدیریت افزونگی در برابر هزینه‌ها و پیچیدگیطراحی یه سیستم با افزونگی بالا همیشه به معنی پیاده‌سازی راه‌حل‌های پیچیده و پرهزینه نیست. هنر طراحی معماری اینه که بتونی بهترین تعادل رو بین هزینه، پیچیدگی و دسترسی‌پذیری برقرار کنی. برای بیشتر کاربردها، یه سطح مناسب از افزونگی می‌تونه بهت یه سیستم پایدار و قابل اطمینان بده بدون اینکه هزینه‌ها به شدت افزایش پیدا کنه. اما اگه نیازمندی‌های کسب‌وکار و سرویس‌دهی بحرانی دارن، می‌تونی با پیاده‌سازی راه‌حل‌های پیچیده‌تر مثل معماری‌های چند-منطقه‌ای (Multi-Region) به سطح بالاتری از پایداری و قابلیت اطمینان دست پیدا کنی.با رعایت این اصول، می‌تونی سیستمی طراحی کنی که نه تنها در برابر خرابی‌ها مقاومه، بلکه در مواجهه با بدترین سناریوها هم به کار خودش ادامه بده و کاربران بدون هیچ اختلالی به استفاده از خدماتت ادامه بدن.پایانامیدوارم که واستون مفید بوده باشه!منابع:https://learn.microsoft.com/en-us/azure/architecture/guide/design-principles/self-healinghttps://learn.microsoft.com/en-us/azure/architecture/guide/design-principles/redundancy سجاد غفاریان سجاد غفاریان Mon, 30 Sep 2024 11:00:40 +0330 https://virgool.io/@SajjadGhafarian/okr-sre-integration-part3-sf5y7op2bile در ادامه پست قبلی(تلفیق OKR و رویکردهای SRE - بخش دوم)، در این مقاله ما به بررسی نحوه تعیین اهداف و نتایج کلیدی (OKRs) موثر و مخصوص تیم‌های SRE می‌پردازیم؛ نکته‌ای که باید بهش توجه داشته باشیم اینه که باید اهدافی تعیین کنیم که نه تنها به چالش‌ها و مسئولیت‌های منحصر به فرد حوزه SRE مربوط باشن، بلکه دقیق، قابل سنجش و قابل دستیابی هم باشن... که در ادامه بیشتر درمورد این مسائل صحبت میکنیم.نکته مهم اول: تیم‌های SRE با ثبات سیستم، بهینه‌سازی عملکرد و پاسخ به Incidentها سروکار دارن، اهداف باید این مسئولیت‌های اصلی رو منعکس کنن.نکته مهم دوم: حوزه SRE یک حوزه پویاست و با فناوری‌های در حال تکامل و چالش‌های غیرقابل پیش‌بینی همراهه، OKRها باید قابل تطبیق و هماهنگ با این شرایط متغیر باشن.تدوین OKR بر محوریت SREدقیق بودن اهداف: اهداف باید واضح و دقیق باشن؛ به جای تعیین هدفی مبهم مثل «بهبود قابلیت اطمینان سیستم»، یک هدف مشخص‌تر می‌تواند «کاهش زمان توقف سیستم به میزان ۱۵% در سه ماه آینده» باشد.نتایج کلیدی قابل سنجش: نتایج کلیدی باید قابل سنجش باشن تا پیشرفت به طور موثری ردیابی شن؛ با استفاده از مثال قبلی، نتایج کلیدی قابل سنجش می‌توانند شامل «کاهش میانگین زمان توقف در هر Incident» یا «افزایش تعداد استقرارهای موفق بدون مشکل(successful deployments without incidents)» باشد.دست‌یافتنی و واقع‌بینانه بودن: اهداف باید چالش‌برانگیز اما دست‌یافتنی باشن؛ تعیین اهداف غیر واقعی می‌تونه تیم رو ناامید کنه، به عنوان مثال هدف‌گذاری Zero Downtime تقریبا غیرممکنه... در عوض، هدف‌گذاری برای کاهش قابل توجه Downtime میتونه یک هدف منطقی باشه.هماهنگی با اهداف گسترده‌تر: OKRها باید با اهداف گسترده‌تر سازمانی هماهنگ باشن، اگر شرکت به دنبال افزایش رضایت مشتری است، OKRهای SRE می‌تواند روی بهبود تجربه کاربر نهایی از طریق عملکرد بهتر سیستم تمرکز کند.بررسی و تطبیق مداوم: با توجه به طبیعت پویای کار، باید به طور منظم بازبینی و بررسی و با شرایط تطبیق داده شوند. این انعطاف‌پذیری به تیم اجازه می‌ده تا در پاسخ به چالش‌های جدید یا فناوری‌ها، استراتژی‌های مناسبی را پیاده‌سازی کند.تلفیق بازخورد(Feedback) در OKRهایادگیری از Incident: تجزیه و تحلیل حوادث گذشته و تلفیق درس‌های آموخته شده در OKRها می‌تواند به اهداف مستحکم‌تر و موثرتر منجر شود؛ این فرآیند تکراری به بهبود مداوم OKRها کمک می‌کند.تحلیل حوادث گذشتهتحلیل مبتنی بر داده‌ها: بعد از یه حادثه، تیم‌های SRE معمولاً تحلیل پس از واقعه (post-mortem analysis) انجام می‌دن، این موضوع شامل جمع‌آوری داده‌های مربوط به حادثه مثل علل، تاثیرات و... هستش که برای درس گرفتن از اشتباهاتمون و برنامه‌ریزی اهداف بعدیمون مهمن.شناسایی الگوها: با تجزیه و تحلیل چندین حادثه در طول زمان، تیم‌ها می‌تونن روندها و الگوها رو شناسایی کنن... به عنوان مثال، اگر چندین Incident به خاطر یه نوع خاص از System Failure اتفاق افتاده باشه، این موضوع می‌تونه منجر به بهبودهای هدفمند(targeted improvements) بشه که به شکل بنیادی اون مشکل رو حل میکنه.تلفیق تجربیات و آموزه‌ها در OKRتصحیح اهداف: تجربیات به دست آمده از تحلیل حوادث می‌تونه برای تصحیح اهداف موجود استفاده شه، به عنوان مثال، اگر داده‌های حادثه نشون دهنده مشکل تکراری یک سرویس خاص در سیستم باشه، می‌شه هدفی رو برای رفع و بهبود اون بخش تعیین کرد.تعیین نتایج کلیدی مرتبط: نتایج کلیدی باید با تجربیات به دست آمده هماهنگ باشن، مثلا یک نتیجه کلیدی مرتبط می‌تونه کاهش Downtime یا کاهش failure rate آن سرویس به یک درصد خاص باشه.اقدامات پیشگیرانه: یادگیری از حوادث اغلب به شناسایی اقدامات پیشگیرانه منجر می‌شه، مثل پیاده‌سازی ابزارهای مانیتورینگ جدید یا بازبینی روش‌های عملیاتی برای جلوگیری از حوادث مشابه در آینده.تلفیق بازخورد در OKRها روش قدرتمندی برای اطمینان از اینه که اهداف SRE به طور مداوم پالایش شده و هماهنگ با چالش‌های عملیاتی واقعی باقی بمونه؛ این روش پاسخ به Incidentها رو از یک استراتژی واکنشی به یک استراتژی پیشگیرانه تبدیل می‌کنه و هر حادثه فرصتی برای بهبود و رشد می‌شه.نتیجه‌گیریتعیین اهداف درست برای تیم‌های SRE نیاز به تعادل دقیقی از دقیق بودن، قابل سنجش بودن، دست‌یافتنی بودن و هماهنگی با اهداف سازمانی داره؛ تلاشمون اینه که اهدافی ایجاد کنیم که مستقیماً به جنبه‌های منحصر به فرد SRE پرداخته و به اندازه کافی انعطاف‌پذیر باشن تا با طبیعت پویا و گاهی غیرقابل پیش‌بینی چالش‌های Reliability و Stability سیستم سازگار باشن. با انجام این کار، تیم‌های SRE می‌تونن تلاش‌های خودشون رو موثرتر و متمرکزتر کنن و به طور قابل توجهی به اهداف گسترده‌تر سازمان کمک کنن..امیدوارم این مقاله واستون مفید واقع شده باشه.سجاد غفاریان - با کمک از یکسری منابع آنلاین! سجاد غفاریان سجاد غفاریان Sat, 30 Dec 2023 10:26:47 +0330 https://virgool.io/@SajjadGhafarian/okr-sre-integration-part2-tnhnb3rwryoq در ادامه مقاله قبلی(تلفیق OKR و رویکردهای SRE - بخش اول)، در این مقاله بیشتر به بررسی تلفیق OKR و رویکردهای SRE میپردازیم.تو این بخش می‌خوایم نگاهی بندازیم به تعادل دقیق بین دو نیروی به ظاهر متضاد تو حوزه مهندسی اتکاپذیری (SRE): حفظ قابلیت اطمینان سیستم و ترویج نوآوری. این تعادل برای هر سازمانی که به تکنولوژی برای پیشبرد کسب‌وکارش وابسته‌س خیلی مهمه و ورود اهداف و نتایج کلیدی (OKRs) به همراه SRE یه راه ساختارمند برای نوآوری و حفظ این تعادل فراهم می‌کنه.چالش دوگانه در SREحفظ Reliability سیستم: وظیفه اصلی تیم‌های SRE اینه که اطمینان حاصل کنن سیستم قابل اعتماد، در دسترس و بهینه عمل می‌کنه؛ این موارد معمولاً شامل برنامه‌ریزیهای دقیق، مدیریت ریسک و تمرکز روی ثبات و قابل پیش‌بینی بودن می‌شه.ترویج نوآوری: از طرف دیگه، نوآوری نیاز به آزمایش، ریسک‌پذیری محاسبه‌شده و پذیرا بودن تغییرات و ایده‌های جدید داره؛ این موضوع گاهی اوقات با هدف Reliability سیستم در تضاده، چون تغییرات جدید می‌تونن پیش‌بینی‌ناپذیری(Unpredictability) و اختلالات احتمالی به وجود بیارن.نقش OKRها در هماهنگ‌کردن/ادغام Reliability و نوآوریریسک‌پذیری ساختارمند(Structured Risk-Taking): سیستم OKR یه چارچوب برای تیم‌های SRE فراهم می‌کنه تا نوآوری رو به شکل ساختارمند انجام بدن؛ با تعیین اهدافی خاص در محوریت نوآوری، تیم‌ها می‌تونن ریسک‌های محاسبه‌شده‌ای داشته باشن. مثلاً، یه OKR می‌تونه شامل پیاده‌سازی یه تکنولوژی یا فرآیند جدید باشه که پتانسیل بهبود عملکرد یا کارایی سیستم رو داشته باشه.تعیین نتایج کلیدی برای نوآوری(Defining Key Results for Innovation): نتایج کلیدی در OKR نتایج قابل سنجشی هستن که می‌تونن برای سنجش موفقیت ابتکارات نوآورانه استفاده بشن. این معیارها می‌تونن شامل عواملی مثل تاثیر روی عملکرد سیستم، رضایت کاربر یا کارایی عملیاتی باشن. اینطوری، نوآوری فقط یه مفهوم نیست، بلکه یه موجودیت قابل سنجشه.تعادل بین اهداف(Balancing Objectives): OKRها به تیم‌های SRE اجازه می‌دن اهدافشون رو متعادل کنن، تا تلاش‌ها به سمت نوآوری، پایداری و Reliability سیستم رو خدشه‌دار نکنه. به عنوان مثال، در حالی که یک هدف ممکنه روی استقرار یک ویژگی جدید تمرکز کنه، هدف دیگری می‌تونه بر حفظ سطح خاصی از زمان بالا بودن سیستم یا کاهش نرخ خطاها تمرکز داشته باشه.تشویق نوآوری تدریجی(Encouraging Incremental Innovation): OKRها می‌تونن فرهنگ نوآوری تدریجی رو تشویق کنن، جایی که تغییرات کوچک و قابل مدیریت به طور منظم ایجاد و ارزیابی می‌شن. این ریسک مرتبط با تغییرات مقیاس بزرگ رو کاهش می‌ده و بهتر با اصل حفظ قابلیت اطمینان سیستم هماهنگه.همراهی با اهداف سازمانی گسترده‌تر(Aligning with Broader Organizational Goals): OKRها به هماهنگ کردن اهداف تیم SRE با اهداف گسترده‌تر سازمانی کمک می‌کنه. وقتی شرکت هدف نوآوری رو به عنوان بخشی از برنامه استراتژیک خودش قرار می‌ده، OKRها در SRE اطمینان حاصل می‌کنه که تلاش‌های فنی این جهت رو پشتیبانی می‌کنن بدون اینکه به قابلیت اطمینان لطمه‌ای وارد شه.نتیجه‌گیریتلفیق OKR تو رویکردهای SRE یه رویکرد متعادل برای قابلیت اطمینان سیستم و نوآوری فراهم می‌کنه. این موضوع یه مسیر ساختارمند برای ریسک‌پذیری ارائه می‌ده و اطمینان حاصل می‌کنه که نوآوری‌ها هم قابل سنجش هستن و هم با نیازهای پایدار نگه‌داشتن سیستم هماهنگن. با استفاده از OKRها، تیم‌های SRE می‌تونن به تلاش‌های نوآورانه سازمان کمک کنن و در عین حال ستون اساسی اتکاپذیری سیستم رو حفظ کنن.امیدوارم این مقاله واستون مفید واقع شده باشه.سجاد غفاریان - با کمک از یکسری منابع آنلاین! سجاد غفاریان سجاد غفاریان Tue, 19 Dec 2023 13:27:05 +0330 https://virgool.io/@SajjadGhafarian/okr-sre-integration-pjn4vovfytfy در این مقاله، می‌خوایم بررسی کنیم که چطور می‌شه رویکرد OKR (اهداف و نتایج کلیدی) رو با SRE (مهندسی اتکاپذیری) ترکیب کرد و چه تاثیراتی روی ساخت و نگهداری سیستم‌های نرم‌افزاری قابل اتکا می‌تونه داشته باشه و همزمان با اهداف کلی بیزینسی هم سازگار باشه.تعریف OKR: یه چارچوب تعیین هدفه که برای تعریف و پیگیری اهداف و نتایجشون استفاده می‌شه. به ما کمک می‌کنه هدف‌های بلندپروازانه با نتایج قابل سنجش تعیین کنیم و شفافیت و هماهنگی رو تو سازمان بیشتر کنیم.تعریف SRE: یک نقش/Role هستش که جنبه‌هایی از مهندسی نرم‌افزار رو برای حل مشکلات عملیات نرم‌افزارها به کار می‌بره؛ هدف اصلی ایجاد سیستم‌های نرم‌افزاری مقیاس‌پذیر و بسیار مطمئنه. SRE با استفاده از روش‌های مهندسی مختلف به حل مسائل عملیاتی نرم افزار می‌پردازه.هدف‌گذاری(Goals) متناسب با Reliability: با ترکیب OKR در SRE، تیم‌ها می‌تونن اهداف فنی‌شون رو با اهداف استراتژیک سازمان هماهنگ کنن. مثلاً یه OKR می‌تونه روی کاهش زمان System Downtime یا بهبود زمان پاسخ‌دهی تمرکز کنه، که مستقیماً به رضایت مشتری و بهبود فعالیت بیزینسی کمک می‌کنه.اهداف قابل سنجش(Quantifiable Objectives): SREها معمولاً روی معیارهایی مثل شاخص‌های سطح خدمات (SLIs) و اهداف سطح خدمات (SLOs) تمرکز دارن. با ترکیب این‌ها با OKR، معنی دادن به معیارهای فنی قابلیت اطمینان به شکل نتایج بیزینسی ممکن می‌شه. به عنوان مثال، یه OKR می‌تونه بهبود SLOها برای زمان بالا بودن سیستم(Uptime) باشه، که مستقیماً به هدف بزرگ‌تر بهبود تجربه مشتری کمک می‌کنه.در ادامه بیشتر درمورد فواید ترکیب SRE و OKRها صحبت میکنیم...پیاده سازی و تعریف یک رویکرد ساختارمنداولویت‌بندی واضح(Setting Clear Priorities): OKR به تعیین اولویت‌های واضح برای تیم‌های SRE کمک می‌کنه. با داشتن اهداف مشخص، SREها می‌تونن تلاش‌های خودشون رو روی کارهایی متمرکز کنن که بیشترین تاثیر رو روی قابلیت اطمینان سیستم و اهداف سازمان داره.موفقیت قابل اندازه‌گیری(Measurable Success): نتایج کلیدی در OKR از نوعی هستن که می‌شه اندازه‌گیریشون کرد و این موضوع پیگیری پیشرفت(Progress) و موفقیت رو آسون‌تر می‌کنه.بهبود تعاملات و Collaboration ترکیب OKR با SRE به همکاری بین تیم‌های مختلف کمک می‌کنه. SREها با کار کردن روی OKR مشترک، می‌تونن بهتر با بخش‌های توسعه محصول، بازاریابی و سایر واحدها هماهنگ بشن و این باعث می‌شه به روشی واحدتر به دستیابی به اهداف بیزینسی متمرکز بشیم.بهبود مداومبازخورد و سازگاری: OKRها همیشه ثابت نیستن؛ به صورت منظم مورد بازبینی و تجدیدنظر قرار می‌گیرن. این فرآیند تکراری خیلی خوب با اصل بهبود مداوم در SRE جور درمیاد. به تیم‌ها اجازه می‌ده تا استراتژی‌هاشون رو بر اساس عملکرد فعلی، چالش‌های جدید و تغییرات در محیط کسب‌وکار تطبیق بدن.در نتیجه‌...ترکیب OKR با SRE یه روش ساختارمند، قابل اندازه‌گیری و هماهنگ برای تضمین قابلیت اطمینان و کارایی نرم‌افزار فراهم می‌کنه. این ترکیب نه تنها به استحکام فنی سیستم‌ها کمک می‌کنه، بلکه اطمینان حاصل می‌کنه که این تلاش‌ها مستقیماً با دستیابی به اهداف استراتژیک سازمان در ارتباط هستن. این نقشه راه موفقیت درباره ایجاد یک رابطه هماهنگ بین عملکرد عالی عملیاتی و رشد بیزینسیه.اندازه‌گیری موفقیت: چطور OKR می‌تونه معیارهای عملکرد SRE رو بهبود ببخشهحالا می‌خوایم ببینیم که چطوری تلفیق اهداف و نتایج کلیدی (OKR) در SRE می‌تونه معیارهای عملکرد سنتی رو تقویت کنه و اطمینان حاصل کنه که عملیات فنی فقط درباره نگهداری سیستم‌ها نیست، بلکه در مسیر موفقیت کلی بیزینسی هم قدم برمی‌داره.تقویت معیارهای SRE سنتی با OKRبهبود زمان بالا بودن سیستم (Uptime): می‌شه OKR رو با هدف خاص بهبود زمان بالا بودن تعیین کرد. برخلاف اهداف سنتی SRE که ممکنه فقط روی نگهداری سیستم‌ها تمرکز کنن، رویکرد OKR این هدف رو با چشم‌انداز بیزینسی گسترده‌تری ترکیب می‌کنه. مثلاً، یه OKR می‌تونه بهبود زمان بالا بودن رو مستقیماً به رضایت بیشتر مشتری یا افزایش فروش مرتبط کنه.کاهش نرخ خطاها: تو SRE، پیگیری نرخ خطاها خیلی مهمه. با تنظیم OKR دور کاهش این نرخ‌ها، تمرکز از صرفاً ردیابی خطاها به جستجوی فعال برای کمینه کردن اون‌ها تغییر می‌کنه. این رویکرد فعال می‌تونه منجر به سیستم‌های قوی‌تر و تجربه بهتر کاربر بشه، که با هدف بزرگ‌تر بهبود کیفیت محصول هماهنگه.پاسخگویی سریع‌تر به Incidentها: OKR می‌تونه در تعیین و دستیابی به اهداف بلندپروازانه‌تر برای زمان پاسخ به Incidentها کمک کنه که البته این موضوع فقط درباره سریع حل کردن مشکلات نیست، بلکه درباره کمینه کردن تاثیر روی مشتریان و عملیات بیزینسیه.هماهنگ کردن معیارهای SRE با اهداف سازمانیمشارکت مستقیم در اهداف بیزینسی(Direct Contribution to Business Goals): با هماهنگ کردن معیارهای SRE با OKR، تلاش‌های فنی مستقیماً به اهداف گسترده‌تر بیزینسی کمک می‌کنن. به عنوان مثال، هدف SRE برای بهبود فرکانس انتشار ویژگی‌های جدید می‌تونه به OKRی مرتبط بشه که هدفش رشد بازار یا جذب مشتری باشه.تمرکز متعادل(Balanced Focus): این رویکرد اطمینان حاصل می‌کنه که تمرکز هم بر حفظ قابلیت اطمینان سیستم و هم بر دستاوردهای بیزینسی باشه. این باعث می‌شه SRE از یک عملیات پشت‌صحنه به یک راهبر کلیدی پیشبر بیزینس تبدیل شه.تاثیر قابل سنجش(Quantifiable Impact): OKR تاثیر تلاش‌های SRE رو به شکل شرایط بیزینسی قابل اندازه‌گیری می‌کنه. این می‌تونه به خصوص در ارتباط دادن ارزش کار SRE به ذی‌نفعان غیرفنی قدرتمند باشه، که نشون می‌ده چطور تعالی فنی از اهداف استراتژیک شرکت پشتیبانی می‌کنه.در نتیجه...تلفیق OKR و SRE یه تغییر مهم از معیارهای عملکرد سنتی به یه رویکرد جامع‌تره. این رویکرد پلی هستش بین قابلیت اطمینان(Reliability) فنی و موفقیت بیزینسی و اطمینان حاصل می‌کنه که هر جنبه‌ای از کار SRE با اهداف کلی سازمان هماهنگ باشه. این تغییر نه تنها قابلیت اطمینان و کارایی سیستم رو بهبود می‌بخشه، بلکه به طور بسیار مشهودی به رشد و موفقیت شرکت کمک می‌کنه.امیدوارم این مقاله واستون مفید واقع شده باشه!سجاد غفاریان - با کمک از یکسری منابع آنلاین! سجاد غفاریان سجاد غفاریان Mon, 18 Dec 2023 11:26:28 +0330 https://virgool.io/@SajjadGhafarian/over-engineering-in-system-design-md4teppvfxuf توسعه نرم‌افزارها و نگهداری سیستم ها در پروداکشن، یک فرآیند پیچیده و چالش‌برانگیز است که معمولاً به دلیل فشارهای زمانی، نیازهای کاربران و رقابت با رقبا میبایستی توسط توسعه‌دهندگان و کارشناسان SRE به شکل سریع و دقیق انجام گردد اما عدم توجه به اهمیت Reliability یا قابلیت اعتماد سیستم‌ها، وقوع Over-Engineering یا زیاده‌روی در فرآیند توسعه ویا نگهداری نرم‌افزار می‌تواند مشکلات جدی ای برای ما ایجاد کند.در این مقاله به بررسی اهمیت جلوگیری از Over-Engineering و تمرکز بر سادگی در توسعه و نگهداری سیستم ها به منظور افزایش Reliability سیستم می‌پردازیم.الف - Over-Engineering در توسعه و طراحی سیستم هادر ابتدا باید گفت، Over-Engineering در توسعه و طراحی سیستم ها به معنای طراحی و توسعه بیش از حد یک سیستم یا نرم‌افزار(کارهای غیرضروری یا بیش از حد پیشگیرانه) است، این امر ممکن است به دلیل استفاده از ابزارها و راهکار های پیچیده، اضافه کردن ویژگی‌های غیرضروری یا پیچیده کردن فرآیندها و ساختارهای نرم‌افزاری به وجود بیاید و گفتنی است که این امر ممکن است به مشکلاتی مانند افزایش هزینه توسعه(از همه نظر)، کاهش کارایی و کارآیی نامناسب/اشتباه و پیچیدگی در نگهداری سیستم منجر شود.ب - اهمیت سادگی در توسعه کدسادگی در توسعه نرم‌افزار و ساختار نگهداری سیستم ها به عنوان یک اصل میبایستی درنظر گرفته شود. سادگی به معنای استفاده از راهکارهای ساده، شفاف، و کارآمد برای رسیدن به اهداف موردنظر بیزینس و پروژه میباشند و سادگی کمک می‌کند تا ساختار کد مطلوب و قابل فهمی داشته باشیم که افزایش قابلیت اعتماد(همان Reliability) و تعمیر و نگهداری سیستم(troubleshoot) را تسهیل می‌کند.به زبون ساده، برای یک پروژه کوچیک و تیم کوچیک و یک بیزینس گنگ، لازم نیست از همون اول هزار دیزاین پترن و سیستم ها و ابزارهای پیچیده رو به کار بگیریم! شما محصول رو با سادگی آماده کنید و بعد از ایجاد نیاز، کد را ریفکتور و بهبود میدهید ویا معماری را باز طراحی میکنید. over-engineering در سطح یک بیزینس کوچک حتی میتواند به fail شدن و شکست پروژه هم منجر گردد!ج - مزایای جلوگیری از Over-Engineering و تمرکز بر سادگی:افزایش قابلیت اطمینان(Reliability): استفاده از رویکردهای ساده و کم‌ترین میزان پیچیدگی در توسعه نرم‌افزار، احتمال وقوع خطاها و مشکلات را کاهش می‌دهد و به تدریج Reliability سیستم را افزایش می‌دهد.صرفه‌جویی در منابع: Over-Engineering ممکن است منجر به تلف کردن منابع زیرساختی، مالی و انسانی شود و همچنین گفتنی است که تمرکز بر سادگی باعث می‌شود تا منابع بهینه‌تر مدیریت شوند و هزینه‌های توسعه کاهش یابد.انعطاف‌پذیری: سیستم‌های ساده‌تر معمولاً انعطاف‌پذیری بیشتری دارند و به راحتی با تغییرات و نیازهای جدید سازگار می‌شوند.د - رویکردهای بهینه‌سازی در توسعه کدتحلیل دقیق نیازها: برای جلوگیری از Over-Engineering، نیازهای واقعی کاربران باید دقیقاً تحلیل شوند و تنها ویژگی‌ها و فقط عملکردهای ضروری پیاده‌سازی شوند.رعایت اصول SOLID: اصول SOLID (مانند SRP، OCP و DIP) می‌توانند به شکلهای مختلف در کاهش پیچیدگی کد و افزایش سادگی مفید باشند.استفاده از تست‌ها: تست‌های واحد و تست‌های تکاملی (Integration Tests) به شناسایی مشکلات و کاهش خطاها در سیستم کمک می‌کنند.(گرچه تست نویسی بیش از حد هم ممکن است تاثیرات منفی زیادی داشته باشد! میزان تست نویسی را در حد معقولی نگهدارید!)نگهداری نرم افزارها و سیستم ها و Over-Engineering در حوزه SRE و DevOpsدر این دو حوزه، تمرکز بر قابلیت اعتماد، بهره‌وری، و پایداری سیستم‌ها بسیار مهم است، و Over-Engineering ممکن است این اهداف را به خطر بیاندازد. در ادامه به بررسی Over-Engineering در SRE و DevOps می‌پردازیم:در SRE:- افزایش پیچیدگی: در SRE، هدف اصلی ما تضمین قابلیت اعتماد(Reliability) در سیستم‌هاست و اگر مهندسان به طور زیادی به پیچیدگی‌های غیرضروری بپردازند، ممکن است سیستم به شکل پیچیده‌تر و سخت‌تری قابل نگهداری باشد.- مصرف منابع اضافی: Over-Engineering ممکن است به مصرف منابع اضافی نیز منجر شود که معمولاً بهینگی سیستم را کاهش می‌دهد و برای بیزینس هم بسیار هزینه بر میباشد.- کاهش توانایی تیم: سیستم‌های پیچیده‌تر به تست و آزمون، مانیتورینگ و هزینه نگهداری و اتومیشن بیشتری نیاز دارند. این ممکن است موجب کاهش توانایی تیم SRE در شناسایی مشکلات و رفع خطاها شود. در DevOps:- کاهش سرعت توسعه و تحویل: در DevOps، سرعت توسعه و تحویل نرم‌افزار از اهمیت بالایی برخوردار است. Over-Engineering ممکن است به افزایش زمان توسعه و تحویل منجر شود و داشتن این موضوع را تحت تاثیر قرار دهد.- کاهش انعطاف‌پذیری: همونطور که از نظر توسعه و کدنویسی هم گفته شد، سیستم‌های پیچیده و مرتبط با Over-Engineering معمولاً کمتر انعطاف‌پذیری دارند و به مشکلات در تغییرات و به‌روزرسانی‌های نرم‌افزاری منجر می‌شوند.- کاهش تعامل و همکاری: DevOps بر تعامل و همکاری بین توسعه و عملیات تأکید دارد. Over-Engineering ممکن است به افزایش میزان اختلاف و تضاد بین این دو تیم منجر شود.پس، برای جلوگیری از Over-Engineering در SRE و DevOps بهتر است:تمرکز بر اهداف اصلی: تیم‌های SRE و DevOps باید همیشه به اهداف اصلی خود، مانند افزایش قابلیت اعتماد و سرعت توسعه، توجه داشته باشند.تحلیل دقیق نیازها: تحلیل دقیق نیازهای کاربران اساسی‌ترین مرحله در توسعه سیستم‌ها و نگهداری توسط SRE و DevOps است.استفاده از ابزارها و روش‌های مناسب: از ابزارها و روش‌های مناسب برای مدیریت پیچیدگی و افزایش قابلیت اعتماد بهره برداری کنید.به طور کلی، در مهندسی SRE و دواپس، توازن بین اعمال و انجام کارهای ضروری و Over-Engineering بسیار مهم است، استفاده از رویکردهای مناسب و توجه به اصول اصلی این حوزه‌ها می‌تواند به تحقق اهداف اصلی این حوزه ها کمک کند.امیدوارم این مقاله واستون مفید واقع شده باشه!سجاد غفاریان - با کمک از یکسری منابع آنلاین! سجاد غفاریان سجاد غفاریان Thu, 05 Oct 2023 19:07:16 +0330 https://virgool.io/@SajjadGhafarian/incident-management-and-postmortem-epbn6in4ts2p یکی از مهمترین مسائلی که میبایستی در حوزه SRE رعایت کنیم و به عنوان یک فرهنگ آنرا پیاده سازی کنیم، تعریف فرآیندهای مدیریت Incident و سیستم Postmortem میباشد.چرا به این موارد نیازمندیم؟ در شرایط Incident و Outage، معمولا به دلیل فشار کاری و استرس بالا، تصمیم گیری و مدیریت تیم و کارها بسیار سخت و بسیار چالش برانگیز می باشد؛ این فرایندها در شرایط اینگونه، میتواند به مدیریت Incident کمک کند و تصمیم گیری و فرایندها را مشخص تر و سریعتر نماید و درنهایت فرهنگی را پیاده‌سازی کند که همه از تجربه‌ی همدیگه درس گرفته و بهره‌مند شوند.توضیحات: اصول و موارد مطرح شده در این مطب، با الگوبرداری از فصل چهاردهم و پانزدهم کتاب Site Reliability Engineering آماده شده است؛ اگر پیشنهادی برای بهبود ویا تکمیل توضیحات دارید، حتما کامنت بزارید که درموردش صحبت داشته باشیم.چه زمانی یک رخداد را Incident مینامیم؟ در صورتی که رخداد ما با هر کدام از گزینه های ذیل تطابق داشته باشد، رخداد را Incident مینامیم.آیا نیازی به درگیر شدن تیم(یا تیم‌ها) دیگری در رفع رخداد وجود دارد؟آیا سرویس‌دهنده ها یا استفاده کنندگان(تیم توسعه، تیم عملیات، مشتری‌ها و...) متوجه رخداد میشود؟آیا رخدادی پیش آمده است که بعد از گذشت یک ساعت آنالیز دقیق همچنان حل نشده است؟ساختار مدیریت رخدادتقسیم وظایفبسیار مهم است که هر کس، نقش خود را در سیستم بداند و هدررفت وقت و انرژی وجود نداشته باشد؛ هر شخص در وظایف خودش می بایست قدرت عمل و تصمیم گیری کافی را داشته باشد؛ در صورتی که Load کاری یک نفر افزایش پیدا کرد و به نقطه ای رسید که قابل مدیریت نباشد، آن شخص میبایستی از تیم لید درخواست اضافه کردن نیرو (به منظور تقسیم کار در شرایط اختلال) نماید.وظایف میتوانند به شرح ذیل تقسیم گردد:راهبر رخداد: راهبر رخداد مسئول مستقیم فنی و بیزینسی رخداد میباشد و در این دو لایه تصمیم گیری میکند؛ همچنین این شخص مسئول مشخص کردن افراد درگیر در رفع رخداد و تخصیص مسئولیت و تسک و اولویت بندی میباشد و همچنین تیم عملیاتیِ رفع اختلال را راهبری میکند.افراد عملیاتی: افرادی که مستقیما توسط راهبر رخداد و به جهت رفع مشکل مدیریت میشوند؛ نکته مهم برای توجه اینست که فقط افراد عملیاتی مجاز به اعمال تغییرات در سیستم می باشد و هیچ فرد دیگری نباید تغییری در سیستم ایجاد کند. همچنین تمامی تغییرات اعمال شده به اطلاع تمامی اعضای عملیاتی و راهبر میرسد.روابط بیرونی / واسطه: یک شخص مسئول آپدیت نگه‌داشتن Incident Report، اطلاع رسانی به افراد بیزینسی مربوطه و گرفتن فیدبک و اطلاع رسانی به تیم عملیاتی رخداد و گاهی اضافه کردن تسک در فرایند رفع رخداد میباشد(مثل آماده سازی یک گزارش خاص یا بررسی وضعیت یک سیستم ثانویه توسط تیم عملیاتی و…).برنامه‌ریز: یک شخص که مسئول مستقیم پشتیبانی افراد عملیاتی رخداد میباشد و به شکل جداگانه، بررسی میکند که چه عواملی باعث ایجاد مشکل شده و در آینده چگونه از به وجود آمدن این مشکل جلوگیری شود و تمامی عوامل تاثیر گذار را مورد توجه و بررسی قرار میدهد.فرآیندحتما در قدم اول، مدیران مرتبط از پیش‌آمد رخداد و شروع فرایند رفع اختلال مطلع شوند.بهترین حالت برای مدیریت رخداد، حضور تمامی افراد عملیاتی رخداد در یک اتاق جلسه مشترک(اصطلاحا War Room) به جهت تصمیم گیری و پیشبرد یکپارچه و متمرکز کارها میباشد.بهتر است که تمامی رفتارهای ریکوئست ها، ترافیک و… در یک داکیومنت مرجع در بازه های زمانی متفاوت(تایم لاین مشخص) ثبت و لاگ برداری شوند.یک داکیومنت(Incident Document) یکپارچه قابل ویرایش توسط تمامی اعضا(بستر پیشنهادی: Google Docs) که شامل تمامی رخدادهای مرتبط، تایم لاین رفع رخداد، دیالوگهای مرتبط، تغییرات و تصمیم گیریها و دلایلشان (در تیم فعلی و دیگر تیمهای سازمان) میباشد میبایستی تهیه و به شکل لحظه ای آپدیت شود. (تمپلیت کلی به منظور تمیز نگه‌داشتن ساختار دیتا میبایستی تعریف گردد).پس از رفع اختلال، گزارش رخدادی(Postmortem) آماده شود که شامل نکات ذیل باشد و این گزارش به اطلاع همه‎‌ی تیمهای مرتبط به جهت یادگیری تجربه برسد:خلاصه رخدادتاثیر و صدماتوضعیت فعلیدلیل یا دلایل اصلی ایجاد رخداد(Root Causes)تریگر(چه چیزی باعث فعال شدن باگ/اختلال شد)توضیحات تکمیلیوضعیت مانیتورینگ و آلرتها(چه چیزهایی دریافت کردیم و چه چیزهایی دریافت نکردیم)چه چیزی در سیستم به شکل خوب عمل کرد و از بزرگتر شدن مشکل جلوگیری کرد.چه چیزی در سیستم(فنی، ساختاری، تیمی و…) بد عمل کرد و می توانست بهتر باشد.در کجای سناریو و رخداد، شرایط به شکل شانسی خوب پیش رفت و چجوری میتونیم برنامه ریزی کنیم که این اتفاق خوب را پایدار کنیم.تایم لاینچرا باید گزارش رخداد ویا Postmortem داشته باشیم؟ما به عنوان افرادی با عنوان شغلی SRE، مرتبا درگیر سیستم‌های Large-scale، پیچیده و توزیع‌شده هستیم و این سیستم‌ها به شکل متداوم در حال اعمال تغییرات و اضافه کردن فیچر میباشند؛ با توجه به ماهیت این سیستم ها، Outage و Incident اجتناب ناپذیرند و می بایستی به عنوان بخشی از ماهیت سیستم‌ها مقبول واقع شوند؛ این فرهنگ Postmortem به ما کمک میکند که از اشتباهات خود و دیگران درس بگیریم و تجربیات خودمون در اختلال ها به اشتراک بزاریم؛ این موضوع باعث این میشه که یک اشتباه رو دوباره و در شرایط مختلف تکرار نکنیم و تجربه‌هامون رو به شکل مشترک گسترش بدیم.چه زمان Incident Managementـی وجود ندارد و تاثیرات آن چه میباشد؟توجه: یک نفر کارشناس فنی، پاسخگوی تمامی وجوه مشکل به لایه های بالاتر و دیگر تیمها باشد، مثل موارد تکنیکال، بیزینسی و مدیریت ارتباط با تیمهای دیگر؛ این موضوع باعث این میشود که بیشتر تمرکز در نهایت بروی مسئله Technical قرار بگیرد و خیلی وقتا تاثیرات اعمال تغییرات فنی در لایه ی بیزینسی و Big Picture(کلان) در نظر گرفته نشود.تعاملات ضعیف: در ساختاری که کارشناس در جریان کارهایی که دیگر همکارانش در راستای حل رخداد انجام میدهند نباشد و متوجه نشود که چه تغییراتی اعمال می شوند، حل مشکل و تشخیص عوامل پیچیده تر و سخت تر میشود؛ با مدیریت این فرایند و درگیر کردن افراد تیم و تیم‌های دیگر به شکل صحیح و درست از هدررفت وقت و انرژی جلوگیری میشود.خودمختاری: تصمیم گیری خودسرانه و اعمال تغییرات(حتی با اینکه قصد افراد فقط حل مشکل میباشد) و اطلاع ندادن به تیم، باعث بدتر شدن شرایط و سخت تر شدن فرایند حل مشکل میشود.Incident Management Best Practicesاولویت‌بندی: اولویت اولیه بکار انداختن دوباره سرویس(جلوگیری از خونریزی بیشتر!) و بازگشت به نقطه‌ی Stable میباشد. اما حتما می بایستی تمامی مدارک، لاگها و شواهد را برای بررسی دقیق تر و بیشتر نگهداری کنیم.آمادگی: فرایندهای Incident Management خودرا می بایستی داکیومنت کرده و آپدیت نگه داریم تا تمام اعضای تیم به شکل دقیق در جریان تجربه‌ها و تصمیمات قبلی قرار بگیرند.اعتماد: به هر عضو تیم که درگیر Incident میباشد؛ اعتماد در عملکرد داشته باشید و دست آنها را برای تصمیم گیری و ترابل شوت باز بگذارید.احساسات: احساسات خود را در جریان Incident مدیریت کنیم؛ در صورت اینکه احساس وحشت، ترس ویا سرگیجه و سردرگمی داشتید، از دیگران کمک بگیرید.درنظرگرفتن راهکارهای جایگزین: به شکل مداوم در فرایند حل مشکل، این گزینه را بررسی کنید که آیا ادامه دادن رویکرد فعلی با توجه به شرایط منطقی است یا نیازمند این هستیم که راهکار جایگزین دیگری را در پیش بگیریم؟تمرین و تکرار: فرایند Incident Management را به شکل مرتب و مداوم استفاده و رعایت کنید تا تبدیل به یک رویکرد و روال طبیعی در مدیریت اختلال در سیستمها شود.چرخش: نقش افراد تیم در حل مشکل را در هر تجربه و رخداد بچرخانید و بگذارید اعضای تیم در همه‌ی جایگاه ها قرار گرفته و با تمام فرایندهای در هر نقش به شکل کامل آشنا شوند.امیدوارم که این مطلب برای همه دوستان مفید واقع شده باشه و خوشحال میشم نظراتتون رو باهام به اشتراک بذارید.موفق باشید! / سجاد غفاریان سجاد غفاریان سجاد غفاریان Mon, 10 Jul 2023 10:22:44 +0330 https://virgool.io/@SajjadGhafarian/system-design-reliability-patterns-o5avbuq8qxg8 همونطور که احتمالا میدونید، همیشه ممکنه که شما به عنوان یک Site Reliability Engineer و باتوجه به دانش و تجربه‌هاتون درگیر طراحی سیستم هم بشوید و در کنار دیگر مهندسین نرم افزار برای پیاده سازی یک سیستم با تمرکز بر Reliability اعلام نظر کنید(که این سیستم ممکنه از قبل وجود داشته باشه و سعی در بهبودش داشته باشیم ویا ممکنه که یک سیستم جدید برای پیاده سازی درنظر گرفته شده باشه.)فرآیند System Design، فرایند تعریف مولفه‌های یک سیستم نرم افزاری و همچنین مشخص کردنِ interactionها و relationship آن‌ها را به منظور رفع یک مجموعه خاص از نیازها میباشد و به شکل کلی، در مهندسی نرم‌افزار، System Design یک مرحله در فرآیند توسعه نرم‌افزاره که بر روی high-level design یک سیستم نرم‌افزاری شامل معماری و اجزا تمرکز داره.آشنایی با Reliability Patterns هااین پترن‌ها، یک ساختار برای طراحی و پیاده‌سازی یک سیستم رو بهتون ارائه میکنن تا زیرساخت نرم افزاریتون در برابر Failureهای مختلف مقاوم باشه و در لود بالا، سیستمتون کارایی و پرفورمنس خودش رو بتونه به بهترین شکل نگه داره و حتی درصورت پیش اومدن هر اختلالی، ریکاور شدن از شرایط بحرانی رو واستون راحت‌تر و سریع‌تر کنه.این پترن‌ها به سه دسته‌ی اصلی تقسیم میشه:پترن‌های متمرکز بر Availabilityپترن‌های متمرکز بر High Availabilityپترن‌های متمرکز بر Resiliencyکه در ادامه کمی بیشتر درموردشون صحبت میکنیم و به پترن‌های زیرمجموعشون اشاره میکنیم.پترن‌های متمرکز بر Availabilityمولفه‌ی Availability، به عنوان percentage of uptime اندازه‌گیری میشود و میزان زمانی که یک سیستم فانکشنال است و به شکل صحیح کار میکند را برای شما مشخص میکند؛ Availability میتواند با پیش‌آمد مواردی از قبیل System Errorها، مشکلات زیرساختی، حملات امنیتی و System Load تحت تاثیر قرار بگیرد، در زمانی که سیستم های حیاتی و مهمی را طراحی میکنیم، عموما به استفاده کنندگان و کاربران یک SLA ارائه میدیم که خب این قرارداد مارو ملزم به این میکنه که تا جایی که میتونیم، سیستم رو پایدار نگه داریم و Availability رو به حداکثر خودش برسونیم. برای پیاده‌سازی و طراحی سیستمی که تمرکز ویژه ای به Availability دارد، میتونیم از پترن‌های زیر استفاده کنیم:Deployment StampsGeodesHealth Endpoint MonitoringQueue-Based Load LevelingThrottlingپترن‌های متمرکز بر High Availabilityسیستم‌های High Available، معمولا بروی زیرساخت‌های Cloud-based پیاده سازی میشن از ساختار توزیع‌شده و muti-zone استفاده میکنند امکانات مختلفی رو برای Replication در هر لایه‌ای رو واسمون فراهم میکنند و این باعث کاهش احتمال failure در لایه زیرساخت میشه و در نتیجه، سیستم‌ها هم میبایستی به نوعی طراحی و پیاده‌سازی شن که بتونین هرچه بهتر این بستر را adopt کرده و پایداری خودشون رو در بهترین حالت ممکن حفظ کنند.برای پیاده‌سازی و طراحی سیستمی که تمرکز ویژه ای بر High Availability دارد، میتونیم از پترن‌های زیر استفاده کنیم:Deployment StampsGeodesHealth Endpoint MonitoringBulkheadCircuit Breakerپترن‌های متمرکز بر Resiliencyسیستم‌های مبتنی بر Resiliency(یا سیستم‌های تاب‌آور!)، سیستم‌هایی هستند که به شکلی پیاده‌سازی شدن که درصورت بروز هرگونه Failureـی(چه سهوی و چه مخرب و عمدی)، بتونن به راحتی Recover شن و این اتفاقات را handle کنند.برای پیاده‌سازی و طراحی سیستمی که تمرکز ویژه ای بر Resiliency و تاب‌آوری دارد، میتونیم از پترن‌های زیر استفاده کنیم:BulkheadCircuit BreakerCompensating TransactionHealth Endpoint MonitoringLeader ElectionQueue-Based Load LevelingRetryScheduler Agent Supervisorدر علم مهندسی نرم افزار پترن‌ها، معماری‌ها و ساختارهای بسیار زیادی وجود دارن که احتمالا کمتر کسی بتونه به همشون اشراف کامل داشته باشه و باهاشون کار کرده باشه، پس مهمه که ما به عنوان افرادی که در این صنعت حضور داریم، در حد یک دیدکلی و توضیح یک خطی با این راهکارها آشنایی داشته باشیم که در صورت ایجاد نیاز، بتونیم راهکار را ارائه بدیم و در اون زمان هم میتونیم باتوجه به تصمیم جهت پیاده سازی، روی هرموردی که لازم بود عمیق شیم و ازش استفاده کنیم؛ خیلی وقت‌ها در سیستم‌های فعلی، به سمت معماری‌های پیچیده نمیرویم، مخصوصا وقتی که به trade-off های طراحی میرسیم و ممکنه این موارد برای ما هزینه‌ی پیچیدگی رو پیش بیاره، ممکنه که خیلی از ریسک‌های غیرپایدار بودن سیستم رو در یک شرایط خاص بپذیریم و در نتیجه از پیچیدگی و هزینه‌ی نگهداری زیاد جلوگیری کنیم.امیدوارم که این مقاله واستون مفید بوده باشه و بتونید ازش استفاده‌ی لازم رو ببرید!برای نوشتن این مطلب، با ویرایش هایی از این منابع کمک گرفتم که برای مطالعات تکمیلی، میتونید بهشون مراجعه داشته باشید:https://roadmap.sh/system-designhttps://learn.microsoft.com/en-us/azure/architecture/framework/resiliency/reliability-patternsموفق باشید!سجاد غفاریان سجاد غفاریان سجاد غفاریان Sun, 19 Mar 2023 17:41:07 +0330 https://virgool.io/@SajjadGhafarian/manage-kubernetes-with-argocd-kyverno-t6hxcwdvrrfe الان که اینجا هستیم، فکر میکنم که آشنایی اولیه با اینکه کوبرنتیز چیه و چه کاری تحت عنوان Container Orchestration Platform انجام میده دارید؛ در غیر این صورت بهتره که کمی درمورد این ابزار مطالعه‌ی اولیه داشته باشید تا بهتر بتونیم فایده نکاتی که در ادامه‌ی مطلب بهشون اشاره میکنیم رو متوجه بشیم.همونطور که میدونید، بعد از اینکه ریلیز جدیدی از اپلیکیشنمون ایجاد میشه، احتمالا با استفاده از CI Pipeline ها فرایند ایجاد Container Image رو در پیش میگیرید؛ کوبرنتیز یک ابزار بسیار جذاب برای ارائه ی امکانات مختلف به شماست و یکی از فوایدش، پیاده سازی Deployment Strategy های پیچیده هستش.کوبرنتیز برای ما در سازمان ها، تحت عنوان یک یک پلتفرم سرویس دهی میکنه و افراد مختلفی در جایگاه های مختلف(دواپس، SRE، توسعه دهنده و...) ممکنه با این پلتفرم به شکلی روزانه درگیر باشند؛ چالش موضوع ایجاست که ممکنه برخی از این استفاده کننده ها در جریان یکسری Best Practice ها و الزامات پیاده سازی یک اپلیکیشن در سطح کوبرنتیز باشن، اما قطعا افرادی هم وجود دارند که پالیسی ها و Right thing و Bad thing را درمورد این پلتفرم نمیدونن!جدا از راه های درست و غلط در استفاده از پلتفرم کوبرنتیز و باید نبایدهای تکنیکال که ممکنه به شکل تجربی بدست بیاد، در سازمان های مختلف بنا به سیاست ها و محدودیت ها و ساختار های موجود، یکسری الزامات و استاندارد ها میبایستی در پیاده سازی سرویس ها درنظر گرفته شوند که اگر با استفاده از فرایندهای عادی سازمانی بخوایم یکسری پالیسی ها و استانداردهای سازمانی رو اعمال کنیم، احتمالا درگیر فرایندهای سازمانیِ بسیار وقت گیر و طولانی ای میشیم(مثل مکاتبات زیاد، جلسات زیاد و...).آشنایی با Kyvernoابزار Kyverno یک Kubernetes-native policy engine هستش که بهتون این امکان رو میده که پالیسی ها و ساختار های موردنظرتون، Best Practiceهای موردنظرتون، سیاست ها و استانداردهای موردنظرتون رو As a code تعریف و پیاده سازی کنید؛ Kyverno به شکل مستقیم بروی Kubernetes Cluster دیپلوی میشه و از Custom Resource برای تعریف Policyها استفاده میکنه. با استفاده از Admission Webhookها، Kyverno میتونی Policy violation ها رو تشخیص بده و حتی از اعمال اونها، جلوگیری کنه.برای بهتر متوجه شدن موضوع، یک مثال رو باهم بررسی میکنیم:فرض کنید یک دولوپر در سازمان شما، از تگ های latest برای ایمیجهای اپلیکیشنش استفاده کنه و خب هممون میدونیم که این موضوع چه در کوبرنتیز و حتی در داکر، میتونه ایجاد ریسک کنه و عملکرد اپلیکیشن رو تحت تاثیر قرار بده؛ اگر policy engine ای در این سناریو وجود نداشته باشه، تا زمان اینکه دولوپر اپلیکیشن خودش رو روی عملیات ببره و یک نفر متوجه اشتباهش بشه و بهش خبر بده که اشکالش رو ویرایش کنه، ممکنه که ضررهای زیادی متحمل شده باشیم! اما اگر این policy engine وجود داشته باشه، درصورتی که این پالیسی تعریف شده باشه که نباید از ایمیج های دارای تگ latest استفاده کرد، کاربر به محض تلاش برای دیپلوی با یک خطا روبرو میشه که مشخصا بهش اطلاع میده که میبایستی از تگ های specific استفاده کنه.که البته، حتی این قابلیت وجود داره که CI/CD Workflow ما با این ابزار Integrate بشه و زودتر مارو در جریان اشتباهمون قرار بده که در ادامه، مثال این موضوع با Argo CD رو میبینیم...آشنایی با Argo CDقبل از هرچیز، باید بدونیم که مثل هر Kubernetes Manifest ای، پالیسی های Kyverno هم میتونن به شکل Git based مدیریت بشن؛ ابزار Argo CD، یک ابزار GitOps هستش که یکی از فواید اون اینه که به شکل مداوم تفاوت های بین desired state (وضعیت قابل انتظار باتوجه به کد) که به شکل کد در داخلش تعریف شده و live state ای که درحال اجرا در کلاستر هستش رو بررسی میکنه؛ احتمالا قابل حدس هستش واستون که با ترکیب این دو ابزار، میتونیم به شکل شفاف پالیسی های درحال اعمال رو مشخص کنیم و با استفاده از Argo CD که درصورت تشخیص Difference بهمون اطلاع میده(و یا به شکل اتومات وضعیت رو به قبل برمیگردونه ویا از اعمال تغییرات جلوگیری میکنه) enforce کردن پالیسی ها را اجرایی کنیم.Let's talk with Code!در مثال زیر، میخوایم که پالیسیِ require-resource-requests رو تعریف کنیم که الزام تعریف resource requests رو پیاده سازی میکنه و در ادامه، در Argo CD اعمالِ این پالیسی رو تعریف میکنیم:Kyverno Policy Argo CDـSync شدن Argo CD با پالیسیدر ادامه، سعی میکنیم دو پاد nginx رو در کلاستر دیپلوی کنیم، که یکیشون پالیسی رو رعایت میکنه و دیگری نمیکنه!همونطور که میبینید، nginx ای که پالیسی رو رعایت کرده بود pass و nginx ای که پالیسی رو رعایت نکرده بود، fail میشن:امیدوارم که این مقاله واستون مفید بوده باشه و بتونید ازش استفاده ی لازم رو ببرید!برای نوشتن این مطلب، با ویرایش هایی از این مقاله کمک گرفتم که میبایستی بهش اشاره داشته باشم.موفق باشید!سجاد غفاریان. سجاد غفاریان سجاد غفاریان Sun, 19 Feb 2023 04:19:50 +0330 https://virgool.io/Rocket/api-gateway-vhezjabesek4 خیلی دوست دارم بنویسم؛ نمیدونم چرا مغزم پیر شده و مثل قدیما دیگه ایده‌ای واسه نوشتن به ذهنم نمیرسه؛ دیگه بعد از کلی کلنجار رفتن با خودم، تصمیم گرفتم درمورد موضوع API Gateway ها بنویسم.از اونجایی که خودم توی شرکت آسا درگیر زیرساخت مربوط به این حوزه هستم، جدا از Knowledge Sharing، خوشحال میشم تجربیات بقیه همکارانانم در دیگر سازمان ها رو هم بدونم؛ اینکه زیرساخت و تکنولوژی و معماریشون به چه شکلی هستش و خلاصه خوشحال میشم درمورد این موضوع باهم گپ و گفتی داشته باشیم.شما در سازمانتون، ممکنه به عنوان یک SRE ویا توسعه‌دهنده، درگیر زیرساخت‌های مربوط به API Gateway‌ها بشید؛ مباحث مربوط به این حوزه خیلی گسترده شده و با توجه به استفاده از این کانسپت در معماری‌های میکروسرویس، ساختارهای فروش API و دیگر بیزینس‌ها، آشنایی با این محصول‌ها و بسترها میتونه یک موضوع بسیار مهم و کلیدی باشه؛ جدا از مباحث مربوط به خود APIها و API Gatewayها، تمامی موارد زیرساختی دیگه در حوزه دواپس و SRE مثل Scaling، مانیتورینگ، Logging، توسعه و نگه‌داری بروی Orchestratorها مثل کوبرنتیز، ارائه و پیاده‌سازی راهکاری‌های HA و FT برای افزایش Reliability و استفاده از CI/CD در بخش‌های مختلف توسعه و پابلیش API‌ها، میتونه موارد درگیر کننده‌ی شما باشه.پس پیشنهاد میکنم به عنوان توسعه‌دهنده ویا SRE، حتما درمورد این مفهوم مطالعه داشته باشید و اگر تجربه و دانش دیگری‌هم دارید، باهام به اشتراک بذارید و اگر علاقه‌مندید، درمورد کارهایی که انجام دادیم و به شکل جزئی‌تر درمورد تجربیاتی که کسب کردیم، صحبت کنیم و بنویسیم!شاید یکسری از بچه ها ندونن که API Gateway چیه، پس میشه گفت:به شکل مختصر، API Gateway ها یک HTTP server/proxy هستن که به شکل یک دیوار در جلوی APIهای سیستمتون قرار میگیرند و یک محل متمرکزی رو واستون فراهم میکنن که بتونید APIهارو مدیریت، امن، Route و محدود کنید؛ ساختار این API Gateway ها به شکلی هستش که معمولا نیازمند این هستند که مقیاس‌پذیر باشن و برای زیرساخت APIهای ما پرفورمنس بالا و HA فراهم سازند.بستر API Gateway های مدرن معمولا open-source/open-core هستش، به عنوان مثال، KONG یکی از معروفترین API Gatewayها، بروی بستر NginX ساخته شده و Express API بر اساس Node.js Express.گرچه قابل ذکره که یکسری API Management/Gateway های Cloud-based هم داریم که Cloud Provider هایی مثل AWS، G Cloud و Azure ارائه میدن و خیلی هم خفنن؛ ولی خب متاسفانه ما توی ایران دسترسی به این سرویس‌ها نداریم :)از کارهایی که با یک API Gateway میتونید انجام بدید، میتونیم موارد زیر رو بهشون اشاره کنیم:Authentication & Rate LimitingDownstream & Upstream Load BalancingIsolationCachingCORS PoliciesData Validation & TransformationAPI Canary Release/VersioningAPI Analytics(Business and Technical Based)Data Aggregation(in Advanced ones!)Logging / MonitoringMonetization (همون فروش API)Traffic ControlWrite Plugins for doing crazy stuff!جدای این فیچرها، یکسری چیزهای دیگه هم میتونه در اختیارتون قرار بده؛ مثل:سازگاری بسیار خوب با معماری‌های Cloud-native و Microserviceمقیاس‌پذیری بسیار بالاقابلیت پیاده‌سازی به شکل Centralized و Decentralizedقابلیت Integration و سازگاری برای توسعه و تست با بستر CI/CDقابلیت سازگاری با:سرویس‌های SOAP Basedسرویس‌‎های gRPC Basedسرویس‌های مبتنی بر GraphQLسرویس های مبتنی بر WebSocketهاو قطعا، سرویس‌های مبتنی بر RESTقطعا ابزارها و محصولات مختلفی از کمپانی‌های مختلف برای این مفهوم وجود داره که مشخصا هیچکدوم، همه فیچرهایبالارو به شکل یکجا و از پیش آماده نداره؛ از شناخته‌شده ترین ابزارها، میشه موارد زیر رو نام برد:KONGWSO2 (API Manager & Microgateway)Ocelotو ده‌ها مورد کوچیک و بزرگ دیگه.گرچه قابل اشارست که بنا به Stack، دانش، زیرساخت، معماری و هدف هرسازمان، ممکنه سراغ هرکدوم از این ابزارها بریم و از امکاناتشون استفاده کنیم، ممکنه برای Internal Usage امون یک API Gateway داخلی و برای فروشمون، External Gateway جداگونه داشته باشیم و برای هرکدوم، ساختار و کلاسترینگ و تکنولوژی جداگونه‌ای رو دنبال کنیم؛ با ابزارها، Message Brokerها و سرویس‌های مختلف ترکیبشون کنیم و در نهایت خروجی مدنظرمون برای بیزینس رو ایجاد کنیم.در نهایت خوشحال میشم نظری درمورد این موضوع داشتید باهام به اشتراک بذارید و از همدیگه چیزی یاد بگیریم!ارادتمند / سجاد غفاریان سجاد غفاریان سجاد غفاریان Sat, 03 Sep 2022 20:49:17 +0430 https://virgool.io/@SajjadGhafarian/devops-lehbprpnhrm1 چند وقتیه که خیلی دلم میخواد ویرگول جدید بنویسم، ولی مرتبا با خودم کلنجار میرم که خب چی بنویسم که واقعا مفید باشه؟ چی بنویسم که ملت واقعا بدردشون بخوره؟ مسئله اینه که دیگه این روزا، کسی توی مطالب و مقالات فارسی به دنبال موارد آموزشی نمیگرده، هرچند خودمم فکر میکنم درستشم همینه، یک مهندس کامپیوتر توی هر حوزه‌ای(برنامه‌نویسی، عملیات، شبکه، دواپس و...) باید با زبان انگلیسی راحت باشه تا بتونه هم مطالب و مقالات مفید رو مطالعه کنه و هم در مواقع مشکلات، بتونه در انجمن‌ها و وبسایتها به دنبال راهکار و مطالعه تجربیات یوزرها در سراسر دنیا باشه؛ خلاصه که بنظرم دیگه معنی نداره من بیام پست آموزشی بزارم بگم خب لینوکس چیست، فلان سرویس لینوکس چیست، داکر چیست، کانفیگ فلان مورد به چه شکلی انجام میشه و موارد مشابه؛ دیگه با یک سرچ ساده توی سایت‌های مرجع، هم میشه به مقالات قابل اطمینان تر رسید و هم با مثالها و توضیحات کامل‌تری روبرو شد؛ حداقلش فکر میکنم که اگر قراره چیزی رو آموزش بدم، بهتره که واسش ویدئو درست کنم و توی یوتیوب بزارم، چون این مورد رو حس میکنم واقعا استفاده میشه و کمک‌کنندست.چیزی که این روزها برای ما کاربرهای حوزه تکنولوژی جذابه، شاید یکی مطالب مربوط به مشخص شدن Roadmap باشه(برای تازه‌کارها) و جذاب‌تر از اون، مطالبی که توش درمورد چالش‌هامون صحبت میکنیم و بررسیشون میکنیم و حلشون میکنیم؛ مثل بلاگ‌های فنیِ بچه‌های اسنپ، کافه‌بازار و... که توش از چالشی که براشون توی پروژه پیش اومد صحبت میکنند، نحوه بررسی اون چالش و ابعاد مختلف موضوع رو شرح میدن و در نهایت میگن که چطور براش راهکار پیدا کردن و اون راهکار رو به چه شکلی پیاده‌سازی کردن؛ به شخصه برای منم اینجور مقالات که تجربیات رو منتقل میکنه خیلی مفیدتر و جذاب تره؛ حالا خوشحال میشم شماهم بگین که نظرتون درمورد این موضوع چیه و چه مطالبی رو احساس میکنید الان بیشتر میتونه براتون مفید واقع بشه؟گرچه گاهی مواقع، مطالبی که توش چیزهای جدید هم شرح داده میشه و معرفی میشه هم میتونه جذاب و مفید باشه؛ مثل این مطلب که میخوام توش، به برداشت و دیدگاه خودم بگم دواپس چیه؟چرا؟ چون خیلی از دوستانم ازم میپرسن که دواپس دقیقا چیه و چیکار میکنه و تنبل تر از این حرفان که برن سرچ کنن و مطالب دیگه رو بخونن... یا شایدم میخونن ولی هنوز یکسری چیزا براشون گنگ و حل نشدس(همونطور که برای من هم در اوایل یکسری مسائل حل نشده بود و الان هم همچنان مسائلی هست که حل نشدن هنوز واسم!)، در نتیجه گفتم یکبار به زبون خودم و به برداشت خودم، بگم که داستان چیه، شاید اگر دو روز دیگه یکنفر دیگه هم ازم پرسید دقیقا داری چیکار میکنی توی محل کارت، بتونم بهش لینک بدم بگم بیا این مطلب رو بخون متوجه شی :)).سعی میکنم چیزای تکراری ننویسم مثل مطالب دیگه، نیام باز بگم که دواپس یک فرهنگ است و فلان و فلان، دوست دارم سعی کنم به زبون خودم یک موضوع رو شرح بدم؛ شاید حتی توش خطا و اشکال هم داشته باشم، پس حرفه‌ای تر ها اشکالی دیدن حتما بهم بگن که روش بازنگری داشته باشم!خب؛ کلمه دواپس از کجا اومده؟نمیدونم والا، برین سرچ کنین ببینین از کجا اومده :))فقط در همین حد بهتون بگم که DevOps، ترکیبی از دو کلمه Development(توسعه) و Operation(عملیات) هستش؛ توی پروژه‌ها و شرکت‌ها، خب مشخصا یک تیم توسعه داریم که وظیفش نوشتن کد و اضافه کردن فیچر(همون چیزمیزایِ جدید) به سیستم هستش و یک تیم عملیات داریم که وظیفش، پایدار نگه‌داشتن سیستم و سرویس هستش.اینجا یک تناقض بزرگ داریم، اون چیه؟ اینکه برنامه‌نویس‌های ما مرتبا میان نرم افزار مارو تغییر میدن و توی این تغییرات، همراه با درست کردن یک چیز جدید، دوتا چیز که قبلا داشته درست کار میکرده رو خراب میکنن ?همیشه این بحث بین تیم عملیات و توسعه بوده که چون ارزش کار تیم توسعه به این بوده که سیستم رو توسعه بده، مرتبا سعی میکرده کد رو آپدیت کنه و عملیات هم مشکل داشتن با این موضوع که مرتبا چیزی که داره قشنگ کارِ خودش رو انجام میداده رو بهش دست بزنن، چون میترسن خدایی نکرده اتفاقی بیفته که سرویس از دسترس خارج شه و نتونن کارشون رو به خوبی انجام بدن.پس این تناقض باعث میشه که همیشه بحث داشته باشیم، توسعه میخواد کار خودش رو انجام بده که فیچر جدید اضافه کنه، عملیات هم میخواد کار خودش رو انجام بده که پایداری سرویس رو در بهترین حالت خودش حفظ کنه و این مرتبا آپدیت دادن توسعه(مخصوصا در پروزه‌های بزرگ)، این موضوع رو به خطر میندازه؛ پس یا باید عملیات کوتاه بیاد، یا تیم توسعه... خب اینجوری که نمیشه باید یک فکر دیگه واسش کرد...پس اینجا دواپس به وجود میاد، یک مهندس مظلوم که بین توسعه و عملیات(یا زیرساخت) قرار میگیره تا همه داد و بیدادهای هر دو طرف سر اون تخلیه شه ?. (شوخی میکنما!!)همونطور که از اسمش مشخصه، دواپس ترکیبی از دانش توسعه و عملیات هستش و میاد در این بین قرار میگیره تا اون تناقض رو حل کنه و بستری رو بسازه(در لایه‌های مختلف) که هر دو تیم بتونن به شکل خوبی کار خودشون رو انجام بدن و توسعه و پایداری به شکل خوبی مدیریت شه (عکس کاور رو ببینین خدایی چقدر قشنگ داره شرح میده این موضوعو ?).این مدیریت، در فازهای مختلف انجام میشه که باید درموردشون صحبت کنیم، در ادامه میخوام بهتون بگم مسئلمون چیه؟ راهکارش چیه؟ بعدش ابزاری که واسه این موضوع استفاده میشه چیه.چرخه دواپس و ابزارهایش!توی دواپس، ما دنبال این هستیم که تمامی فرآیندهارو به شکل اتومات انجام بدیم، توی هر لایه‌ای مثل Build کردن پروژه، تست کردن پروژه، دپلوی کردن پروژه بروی Stage و Production، مانیتور کردنش و هر مورد دیگه‌ای که توی فرآیندهای دواپسی ما انجام میشه. (اگر یکجا رفتین نیروی دواپس شدین، خداییش تنبلی نکنین، همه کارارو اتومات کنین هم خطای انسانی کمتره، هم خودتون راحت ترین، هم کارا به شکل اتومات و سریع‌تر انجام میشه، هم خیلی با کلاسه)خب بیاین باهم به شکل خیلی ساده، بررسی کنیم که فرآیند توسعه یک نرم افزار از لحظه کد نوشتن تا قرار گرفتن بروی سرور پروداکشن برای سرویس‌دهی به چه شکلی هستش و دواپس این وسط چه کاری میتونه واسشون انجام بده.(فقط قبل از اینکه شروع کنم و خیلی کلی درمورد یکسری موارد صحبت کنم، توجه داشته باشید که خیلی به شکل کلی داریم مسئله رو بررسی میکنیم و هر مسئله‌ای که داریم مطرح میکنیم، خودش یک دنیای هستش برای خودش و ساعتها و روزها میشه روی راهکارها، ابزارها و معماری‌هایشان صحبت کرد، پس به شکل جداگونه باید خوب مطالعه بشن تا کار باهاشون راحت تر باشه).فرآیندی که در ادامه دارم شرح میدم، نمونه ساده‌ی یک سناریو هستش و داستان میتونه خیلی پیچیده‌تر از این حرفا باشه و خیلی مولفه‌های دیگه رو هم شامل بشه، خلاصه که حواستون باشه!خب کد توسط تیم توسعه نوشته میشه، و بروی مخرن Git ما قرار میگیره(اینکه Git یا سیستم‌های کنترل ورژن چیه، خودش کلی جای بحث داره، برین بخونین درموردش خدایی جذابه...؛خلاصش اینه که بستری داره فراهم میشه که توسعه و نگه‌داری و کنترل ورژن و ایجاد فیچر و جلوبردن پروژه به شکل تیمی رو برای شما راحت‌تر میکنه)، دواپس میاد یک پایپلاین CI/CD(سی آی/سی دی) میسازه، حالا این پایپلاین چیه؟ یک ساختاری هستش که توسط ابزارهایی مثل Jenkins، Azure DevOps ، Gitlab و... ایجاد میشه و به ما اجازه میده که ما داخلش یکسری فرآیندهارو تعریف کنیم که به شکل اتومات انجام بشن(دارم خیلی خلاصه میگما! داستانش خیلی طولانیه برین سر فرصت بخونین درموردش)؛ در این پایپلاین، به شکل اتومات، کد رو از روی مخزن گیت برداشته میشه و میره روی Build Serverهای ما و پروژه Build میشه، پس فاز برداشتن کد و Build کردنش انجام شد به شکل اتومات، بعدش در فاز بعدی، پروژه ما وارد فرآیندی میشه که روش تست‌های مختلف انجام بشه که مطمئن بشیم قبل از انتشار، کدمون داره درست کار میکنه و مشکل جدی‌ای نداره(این تست ها میتونه توسط ابزارهای مختلفی مثل Selenium انجام بشه که اینم بحثش مفصله)، در مرحله بعدی، میریم که Deploy رو انجام بدیم و پروژه‌ی Build و Test شده رو به سرورهای پروداکشن یا استیج انتقال بدیم(فکر کنین اگر سرورهامون زیاد باشن چقدر این موضوع ترسناک میتونه باشه!).(همین مرحله میتونه خودش شامل فازهای مختلفی باشه، مثل استپ کردن سرویس‌های درحال اجرایِ قبلی، بکاپ‌گرفتن از فایلهای اجرایی قبلی(که اگر مشکلی پیش اومد بتونیم سریع rollback کنیم) و سپس انتقال پروژه جدید، اجرا کردن سرویس‌های مربوطه، اتومات‌سازی اجرای پروژه جدید(تعریف سرویس) و هزار مورد دیگر که میتونه به این فرآیند اضافه شه بسته به ساختار نرم افزارمون.)در کنار این موارد، ما فاز مانیتورینگ و مدیریت Log رو هم(توسط ابزارهایی مثل Prometheus+Grafana و ELK Stack) انجام میدین که مطمئن شیم، در سطح سرویس و زیرساخت، نرم افزارمون داره درست عمل میکنه و مشکل خاصی وجود نداره، یا اگر مشکلی داره به وجود میاد سریع متوجهش شیم و زود حلش کنیم.حالا یکبار دیگه به این تصویر بنگرید:چرخه دواپساین چرخه مرتبا درحال تکرار هستش، در بخش Dev، برنامه‌ریزی، توسعه‌کد، تست و Build داره انجام میشه و در بخش Ops، ریلیز، دپلوی، مانیتورینگ داره انجام میشه؛ این یعنی دواپس!حالا توجه داشته باشین که سناریویی که ما مطرح کردیم، خیلی ساده بود و فرآیند Build و Test بخاطر وابستگی‌هایی که ممکنه وجود داشته باشه، میتونه بسیار پیچیده و چالش برانگیز باشه؛ در ترکیب این لایه با Deploy، ممکن هستش که ما از راهکارهای Containerization استفاده کنیم و در نتیجه با ابزارهایی مثل داکر و کوبرنتیز(درصورت اسکیل بزرگتر و وجود چند کلاستر) هم درگیر شویم! دیگه خودتون حساب کنین چقدر داستان میتونه پیچیده شه؛ فقط خود کوبرنتیز خودش دنیایی هستش که ما توش راهکارهای مقیاس‌پذیری و High Availability و Fault tolerance رو به شکل پیچیده در لایه کانتینر، Storage، نتورک و... میتونیم مدیریت کنیم؛ یا مثلا در لایه زیرساخت و کانفیگ و مدیریت سرورها، میتونیم از ابزارهای Configuration Manager دیگری مثل Ansible استفاده کنیم که مدیریت سرورهای زیاد در Scaleهای بزرگ رو برامون تسهیل میکنه.(درمورد رسالت داکر و Containerization حتما مطالعه داشته باشین، چون بحثش مفصله اینجا بازش نمیکنم فعلا.)خیلی موارد رو کلی مطرح کردیم، ولی فکر کنم ایده گرفتین که چیکار داریم میکنیم، نه؟ده ها ابزار و راهکارهای دیگه توی هرکدوم از این لایه‌هایِ چرخه‌ی دواپس موجود هستش که میتونیم روزها درموردشون صحبت کنیم، فقط در لایه زیرساخت برین ببینین ابزارهایی مثل Kubernetes و OpenStack(که البته بیشتر مرتبط با Cloud Engineer ها هستش ولی گاهی در دواپس هم باهاش درگیر میشن) چه عظمتی دارن و چه کارهایی رو باهاشون انجام میدن، یا مثلا برین ببینین برای مانیتورینگ، چقدر راهکارها و ابزارها وجود دارن...(مانیتورینگ در سطح سرویس خیلی جذابه‌ها... فکر کن مثلا مانیتور کنی فلان صف من توی RabbitMQ اگر تعدادش از N کمتر بود، منو متوجه کن چون این موضوع طبیعی نیست).شرکتا هر کدوم هر بخش از دواپس رو که نیاز دارن پیاده سازی میکنن، خیلی از فرآیندها هنوز که هنوزه اتومات نیست، خیلی از این Stepها هنوز که هنوزه به شکل درست پیاده‌سازی نشده در بسیاری از شرکت‌ها، ده‌ها ابزار و راهکارهای دیگه هستش که میتونیم کلی درموردشون صحبت کنیم، لایه به لایه این موارد ابزارهای مختلفی داره که راهکارهای مختلفی رو پیاده‌سازی میکنن... برین ببینین چه چیزی توی پروژه و سازمانتون کمه، ببینین راهکارش چیه و ابزارش چیه... اون ابزار رو یاد بگیرین و پیاده‌سازی کنین.امیدوارم این مطلب واستون مفید واقع شده باشهحتما نظرتون رو باهام به اشتراک بذارین، خوشحال میشم واقعا.بگین دیگه چی بنویسم بدردتون بخوره؟ارادت / سجاد غفاریان سجاد غفاریان سجاد غفاریان Thu, 10 Feb 2022 15:32:19 +0330 https://virgool.io/NetworkBaz/%D9%BE%D8%B1%D9%88%D8%A7%D8%B2%DB%8C-%D8%A8%D8%B1-%D8%AF%D9%86%DB%8C%D8%A7%DB%8C-%D8%A7%D9%85%D9%86%DB%8C%D8%AA-%D8%B4%D8%A8%DA%A9%D9%87-%28%D9%82%D8%B3%D9%85%D8%AA-%D8%B4%D8%A7%D9%86%D8%B2%D8%AF%D9%87%D9%85%29-%E2%80%93-%D9%85%D9%81%D8%A7%D9%87%DB%8C%D9%85-%D8%B1%D9%85%D8%B2%D9%86%DA%AF%D8%A7%D8%B1%DB%8C%28%D8%A8%D8%AE%D8%B4-%D8%AF%D9%88%D9%85%29-gcbgzgjkryxa با سلام و عرض خسته‌نباشید! در ادامه قسمت قبلی از این سری آموزشی، امروز با ادامه مبحث رمزنگاری و رمزگشایی در خدمتتون هستم و امروز میخواهیم درمورد هش‌ها، امضاهای دیجیتال و... صحبت کنیم.هَـش‌ها(Hashes)فرآیندِ Hashing ویا هَش‌کَردن، متدی برای احراز و Verify کردنِ Data Integrity(دُرُستی و دست‌نخورده بودنِ دیتا) میباشد. مثل زمانی که شما از سایت‌های متفرقه IOSهای گوناگونِ سیسکو را دانلود میکنید وبا استفاده از بررسی MD5 آنها با MD5موجود در سایت سیسکو، از دست‌‌نخورده بودن و عدم خراب بودن فایل، اطمینان حاصل میکنید. فرآیند انجام Hashing فرآیندی است که یک‌تکه داده را دریافت میکند و با استفاده از یکسری پردازش‌ها و الگوریتم‌ها، یک مقدار Hashبا طول ثابت میسازد؛ یعنی چه 5کاراکتر را به تابع Hashing خود تحویل دهید وچه 10صفحه مَتن، همیشه و همیشه یک رشته‌متنی حاوی اعداد و حروف با طول یکسان(مثل 32کاراکتر) دریافت خواهید کرد. این فرآیند یک‌طرفه میباشد، یعنی اینکه شما هیچگاه نمیتواند از رشته‌هش دریافتیِ خود، داده اصلی را بازیابی کنید(بصورت عادی و معمول). نتیجه Hash کردن داده‌ها، همیشه و همه‌جا یکسان است، یعنی اینکه اگر به عنوان مثال از الگوریتم MD5 استفاده کنید، هرجا که داده را به الگوریتم بدهید، پاسخ شما همیشه یکسان میباشد(اگر داده دست‌نخورده باشد و درآن تغییری ایجاد نشده باشد). به عنوان مثال، در زیر کلمه NetworkBaz را با استفاده از الگوریتم MD5 هَش کرده‌ایم: DF8C2A8ACAA42F6E80FBDD9B0FE30DF5برای بررسی مثالی دیگر، فرض کنید که در شبکه، فرستنده تمامی پکت‌های ارسالی‌اش را هش میکند وهمراه با پکت به سمت گیرنده ارسال میکند؛ گیرنده پس‌از دریافت بسته، آنرا Hash میکند و سپس آنرا با Hash ارسالی از طرف فرستنده مقایسه میکند؛ درصورتی که هش‌ها یکسان باشند به‌این معنی است که داده در بین‌راه دست نخورده‌است و به‌صورت کامل و سالم دریافت شده‌است. از معروف‌ترین انواع هش‌ها میتوان موارد زیر را نام برد:Message digest 5 (MD5): 128-bitSecure Hash Algorithm(SHA-1): 160-bitSecure Hash Algorithm(SHA-2): between 224-bit and 512-bitHMAC ـHashed Message Authentication Code یا همان HMAC از همان مکانیزم Hashing استفاده میکند، بعلاوه‌ی اینکه دارای یک نکته بسیار جالب میباشد؛ بجای استفاده از یک هش که هرکسی میتواند براحتی آنرا برای خود محاسبه کند، از یک کلید مخفی(Secret Key) در الگوریتم برای Hashکردن استفاده میکند که فقط دیوایس‌های درارتباط بایکدیگر آن کلید را دارند. با استفاده از این روش، حتی اگر دربین راه، هکر قصد داشته باشد که پکت را شنود کند ویا اطلاعات و هش خودش را Inject کند، شکست میخورد و نمیتواند اینکاررا انجام دهد؛ چراکه فقط فرستنده و گیرنده از آن کلید در باخبر هستند وبا استفاده از این روش پکت‌هارا براحتی Verify میکنند. امضای‌دیجیتال(Digital Signature)در دنیای واقعی، وقتی شما چیزی‌را امضا میکنید به‌این معنی می‌باشد که برمواردی که در آن کاغذ ذکر شده‌است تعهد دارید ویا حداقل آن امضا نمایانگر اینست که شما "همان شخصی میباشید که ادعا میکنید". در دنیای رمزنگاری، یک امضای‌دیجیتال دارای 3 مزیتِ‌مهم میباشد: احرازهویت(Authentication)دُرُستی و سالم‌بودن‌ِداده(Data integrity)ـNon-repudiationامضاهای‌دیجیتال در عملیکی از بهترین روش‌های درکِ عملکردِ Digital Signatureها اینست که مطالب گفته‌شده در قسمت‌قبلی درمورد "کلیدهای Public و Private، رمزنگاری(Encryption) و Hashing" را به‌یاد آورید. فرض کنید دو دیواس داریم با نام‌های A و B. این دو دیوایس میخواهند که با یکدیگر ارتباط VPN برقرار کنند وهمچنین برای اطمینان ازاینکه درحال صحبت با دیوایسِ‌صحیح میباشند میبایستی یکدیگر را احرازهویت کنند؛ درنتیجه برای اینکار میخواهند که از Digital signatureها برای Verify کردن یکدیگر استفاده‌کنند. هردوی این دیوایس‌ها میبایستی Trustedبودن خودرا ثابت کنند، اما برای سادگی، ما دراینجا بصورت یکطرفه این موضوع را بررسی میکنیم: قبل از هرچیز، میبایستی بدانید که دیوایس A و B هردو دارای Public-private key-pair میباشند وهمچنین هردو دارای امضای‌دیجیتال از یک Certificate authority (یا به اختصار CA) میباشند که صحت هر دیوایس را تضمین میکند.(درمورد CAها بعدا بصورت مفصل صحبت خواهیم کرد.) اگر شما یک Digital Certificate را باز کنید، میتوانید نام آن موجودیت(به عنوان مثال دیوایس A) را ببینید و همچنین Public-key همان دیوایس A هم در همان Certificate قابل دسترسی است(چراکه درزمان درخواست دیوایس A از CA برای Digital Certificate، دیوایس A این Public-keyرا در اختیار CA قرار داده است)؛ همچنین یک Digital Signature هم برای خودِ CA در آن Certificate وجود خواهد داشت. پس تا اینجای‌کار، هردوی دیوایس‌های A و B ما به CAمدنظر اعتماد دارند و Digital Certificateهای خودرا از آن دریافت کرده‌اند. دیوایس A یک پکت را برمیدارد و برای آن یک Hash ایجاد میکند؛ سپس این هش را با استفاده از Private-key خودش، Encrypt میکند و این عبارت رمزشده را به پکت اضافه و آن پکت را برای دیوایس B ارسال میکند. به این هَشِ‌رمزنگاری‌شده، امضای‌دیجیتال ویا Digital signature گفته میشود.وقتی که دیوایس B پکت را دریافت میکند، Encrypted Hash یا همان هَشِ‌رمزنگاری‌شده را با استفاده از Public-key دیوایس A رمزگشایی میکند. بعد از بدست‌آوردن مقدار Hashاصلی، دیوایس B پکت را با همان الگوریتم Hashing، دوباره هش میکند و هشِ‌بدست‌آمده را با مقدار دریافت شده از دیوایس A مقایسه میکند، درصورتی که هردوی آن هش‌ها بایکدیگر برابر باشند، دیوایس B از 2 چیز اطمینان حاصل میکند، یکی اینکه دیوایس ارسال کننده همان دیوایس‌مدنظرش(یعنی دیوایس A) میباشد(چراکه فقط آن دیوایس دارای Private-key میباشد)؛ و دیگری اینکه دیتا کاملا سالم میباشد ودر بین راه دستکاری نشده‌است. به این فرآیند، احرازهویت با استفاده‌از امضای‌دیجیتال گفته میشود و عمولا بصورت دوطرفه وبا استفاده از IPSec VPN tunnel پیاده‌سازی میگردد.(در Configuration به‌آن rsa-signature گفته میشود.)ممکن‌است که برای شماهم سوال پیش‌آمده باشد که که دیوایس B چگونه از Public-key دیوایس A باخبر است؟ جواب اینست که قبل از هرچیز این دو دیوایس Digital certificateهای خودرا Exchange میکنند(که همانطور که گفتیم، این Certificateها حاوری Public-key هم میباشند). همچنین گفتنی‌است که دیوایس‌های A و B فقط به Certificateهای امضاشده توسط CAهای مورداعتماد خودشان اعتماد دارند و هر Certificateـی را قبول ندارند. امیدوارم که این پست براتون مفید واقع‌شده باشه؛ در قسمت آینده درمورد IPSec صحبت خواهیم کرد.با آرزوی‌موفقیت. سجاد غفاریان سجاد غفاریان Mon, 08 Oct 2018 19:46:35 +0330 https://virgool.io/NetworkBaz/%D9%85%D9%87%D9%86%D8%AF%D8%B3%DB%8C%E2%80%8C%D8%B4%D8%A8%DA%A9%D9%87:-%D8%A7%D8%B2-%DA%A9%D8%AF%D8%A7%D9%85-%D8%B1%D9%88%D8%AA%DB%8C%D9%86%DA%AF%E2%80%8C%D9%BE%D8%B1%D9%88%D8%AA%DA%A9%D9%84-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%DA%A9%D9%86%DB%8C%D9%85%D8%9F-qgs9osxruoss مدتی پیش یک مصاحبه‌کاری داشتم که شخصِ مصاحبه‌کننده درحال سوال کردن تجربیاتم در پروژه‌های قبلی بود؛ یادمه که ازم پرسید که چرا در فلان پروژه (که در سطح نسبتا وسیعی پیاده‌سازی شده بود) از روتینگ‌پروتکل EIGRP استفاده کردین ومثلا از OSPF استفاده نکردید؟ بارها شده‌بود که مقاله‌های مختلفی در مورد تفاوت‌ها مطالعه کرده بودم و با جزئیات هرکدوم از این روتینگ‌پروتکل‌ها هم آشنایی داشتم و چندباری هم درمورد این موضوع با همکارانم مذاکره و بحث کرده بودم، ولی متاسفانه نتونستم در جوابِ این سوال، توضیحاتم رو به قشنگی وبصورت کامل به اون شخص انتقال بدم...؛ نکته جالب اینجاست که این سوال واقعا از بهترین سوالاتی هستش که میشه در یک مصاحبه پرسید، چراکه فارغ از مباحث فنی، علمِ مهندسی‌شبکه‌ی شخص رو هم به چالش میکشه.یک معمار، طراح ویا مهندس‌شبکه میبایستی قادر باشه که توی یک محیط خاص، شرایط رو بسنجه و براساس نیازها، محدودیت‌ها و شرایط سازمان روتینگ‌پروتکل موردنظر را انتخاب و پیاده‌سازی کنه و صرفا این بحث، چیزی نیست که فقط براساس علاقه انتخاب و پیاده‌سازی بشه. فاکتورهای زیادی در این انتخاب دخیل هستند، از قبیل: "توپولوژی، Scale، بهینه‌بودن، زیرساخت، تجهیزات و وندور، روتینگ‌پروتکل فعلی، سرویس‌های فعلی، برنامه‌های سازمان برای آینده، دانشِ نیروها و..."؛ گرچه این بحث جزء مواردی هستش که با تجربه و حضور در محیطهایِ کاری مختلف، بهتر یادگرفته میشه و البته، کارشناس‌ها نظرات گوناگونی در مواضع مخلفت‌اش دارند(در نتیجه خوشحال میشم که نظرات خودتون رو هم در قسمت کامنت‌ها ارائه بدید). اما بازهم در ادامه میخوایم یکسری نکات رو شرح بدیم که میتونه و امیدوارم براتون کارآمد باشه. مقدمهبحث‌ها و دلایل استفاده از Routing Protocolها بر هیچکس پوشیده نیست!؛ مطمئنا ساختار Static Route و مسیریابی‌ایستا در بسیاری مواردی میتواند بهترین راهکار موجود باشد، مثلا ممکن‌است شبکه شما "بسیار بسیار کوچک" و "سر راست"بوده و در نتیجه، واقعا نیازی به سربار و پردازش اضافه در شبکه نداشته باشید؛ اینجور مواقع Static Routing میتواند بهترین پاسخ برای باشد. با افزایش مقیاس، پیچیده‌تر شدن شبکه، افزایش Nodeها، افزایش خطاها و درنتیجه افزایش نیاز به بهینه‌سازی، خودکارسازی و اتوماتیک کردن فرایندها، نیاز به استفاده از Routing Protocolها بیشتر میشود و درنهایت بجایی میرسیم که به خودمون میگیم وقتشه روتینگ پروتکل مورد نیازمون رو پیاده‌سازی کنیم دیگه!روتینگ‌پروتکلِ RIPروتینگ‌پروتکل RIP سالها به دنیا خدمت کرده‌است و بی‌شک، وجودش کمک بسیاری برای شبکه‌ها بوده‌است(و خواهد بود!)؛ اینروزها خیلی کم دیده میشه که در سطح Enterprise از این روتینگ‌پروتکل استفاده شود، چراکه نسبت به رقیب‌های دیگرش یعنی OSPF و EIGRP، حرف زیادی برای گفتن ندارد و به اندازه آنها بهینه، سریع و مقیاس‌پذیر نمیباشد، درنتیجه میتوان گفت دعوای اصلی بیشتر برسر OSPF یا EIGRP میباشد تا دیگر گزینه‌ها... درسته که هنوزم در بسیاری از مکان‌ها دیده میشود که هنوز هم از RIP استفاده میکنند، اما فکر میکنم کمتر کسی هنوز قبول داشته باشد این RP برای محیطهای بزرگ و مهم، قابل‌اطمینان و مفید باشد وصرفا دیده میشود که امروزه فقط برای کارراه‌اندازی از RIP استفاده میشود. گرچه یادگیری مفاهیم و عمقِ این RP برای یادگیری مباحث Routing و Routing Protocolها همیشه مفید بوده و خواهد بود. بالاخره OSPF یا EIGRP؟یکجورایی میشه گفت که در Enterpriseها، دعوای اصلی برسر EIGRP ویا OSPF میباشد؛ بزارید همین اول خیالتون رو راحت کنم و بگم که درکل، جوابی که میتونید به سوال اصلیِ‌ما بدهید اینست: بستگی به شرایط دارد! به چی؟ به همون مواردی که در اول پست ذکر کردیم! ده‌ها فاکتور از قبیل: توپولوژی، Scale، بهینه‌بودن، زیرساخت، تجهیزات و وندور، روتینگ‌پروتکل فعلی، سرویس‌های فعلی، برنامه‌های سازمان برای آینده، دانشِ نیروها و... هردوی این روتینگ‌پروتکل‌ها مزایا و معایب مخصوص به خودشون رو دارن و هیچوقت نمیشه گفت که روتینگ‌پروتکل‌ِ X، در تمامی Environmentها وشرایط گوناگون بهترین گزینه‌است؛ درنتیجه باید یاد بگیریم که هرکدام در شرایط گوناگون به چه شکلی عمل میکنند و بازدهی و Performanceاشان به چه صورت است. شاید بتوان گفت که در Scaleهای کوچک این موارد و این بررسی‌ها زیاد مهم نباشد و اهمیتی نداشته‌باشد، اما در مقیاس‌های بزرگتر مثل استانی، کشوری و...، اهمیت این موضوع که از کدام Routing Protocol استفاده کنیم بسیار مهم و حیاتی میباشد. برای انتخاب بین این دو مورد، هر محقق شناخته‌شده در دنیای Networking، تحلیل و نِگَرش خاص‌خودش را دارد که در انتهای مطلب مطرحشون میکنیم. قبل از هرچیز بذارید یکسری موارد و ویژگی‌های این روتینگ‌پروتکل‌هارا یادآوری کنیم:الگوریتمپروتکل EIGRP بر اساس الگوریتم DUAL(اختصار Diffusive Update Algorithm) و OSPF هم براساس الگوریتم SPF(اختصار Shortest Path First) عمل میکند؛ نکته‌مهم در تفاوت‌های این دو الگوریتم اینست که چگونه بهترین مسیر را محاسبه و معرفی میکنند. SPF براساس پهنای‌باند لینک‌ها و با استفاده از Cost، متریک را محاسبه کرده و بهترین مسیر را انتخاب میکند؛ ازآنطرف، EIGRP بصورت پیشفرض از Delay و پهنای‌باند برای محاسبه متریک استفاده میکند وهمچنین قابلیت تاثیر دادن موارد دیگر هم مانند MTU، Reliability، Load و... در آن وجود دارد.مصرف CPUپروتکل OSPF از تمامی موارد مربوط به شبکه، اطلاعات گوناگونی را نگهداری میکند و با پیش‌آمدنِ کوچک‌ترین تغییری در شبکه(Area یکسان)، تمامی روترهای Area میبایستی اطلاعات خودرا Re-sync کرده و الگوریتم را دوباره محاسبه کنند. از آنطرف، EIGRP فقط یکسری اطلاعات مهم را درزمان ایجاد همسایگی انتقال میدهد و ازآن به بعد، فقط برقراری همسایگی را بررسی میکند و تغییرات ایجاد شده را(در زمان اتفاق) به دیگران اطلاع میدهد؛ درنتیجه نیازی نمیباشد که در زمان تغییر تمامی روترها اطلاعات خودرا بروز کنند و دوباره الگورتیم را اجرا و محاسبه کنند؛ در نتیجه OSPF مصرف CPU بیشتری نسبت به EIGRP، به‌همراه دارد.زمان همگرایی(Convergence Time)باتوجه به ساختار EIGRP، بسیاری معتقدند که EIGRP زمان همگرایی کمتری نسبت به OSPFدارد، چراکه از راهکار Successor و Feasible Successor برای مسیرِ بکاپِ Loop-free استفاده میکند و در OSPF تشخیص و محاسبه مسیر جدید میتواند بیشتر زمان‌بر باشد. (گرچه بسیاری‌هم معتقدند که باتوجه به اینکه OSPF از BFD پشتیبانی میکند، با این ترکیب میتواند حتی از EIGRP هم بهتر عمل کند.)سادگیپروتکلEIGRP نسبت به OSPF، مفاهیم و Conceptهای کمتر و ساده‌تری دارد و درنتیجه این باعث میشود که در Scaleهای بزرگ و پیچیده، مدیریت OSPF سخت‌تر از EIGRP باشد.طراحی و معماریپروتکل OSPF دارای ساختارهای خاصی در طراحی میباشد(مواردی که میبایستی در طراحی و ایجاد Areaها و... درنظر داشته باشید.) اما EIGRP سخت‌گیری‌ها و محدودیتِ‌خاصی در زمانِ‌طراحی برای‌شما ایجاد نمیکند. شاید هم بتوان گفت که نکته مثبت درمورد OSPF همین است که اگر ازهمان ابتدا، بَنابَر این سیستم بخواهید شبکه خودرا طراحی کنید، مجبور میشوید که طراحی را به شکل صحیح و استانداردِ تعریف شده پیش ببرید و ساختارهای Areaبندی‌شده را ایجاد کنید، اما خب EIGRP به این صورت نیست و شما یک شبکه Flat و کُلی دارید.پروتکل OSPF توسط الگوریتم قدرتمند Dijkstra SPF عمل میکند که خب مسلما دارای مصرف منابع بیشتری نسبت به EIGRP(که از DUALاستفاده میکند)میباشد؛ به‌هرحال میتوان گفت که OSPF کنترل بیشتری در شبکه به‌ما میدهد، با دانستن وضعیت تمام لینک‌ها و وضعیت‌های موجود در یک Area، انتخاب مسیر میتواند بهتر و دقیق‌تر صورت‌بگیرد؛ بالاخره از روش Routing by Rumor(مسیریابی براساس شایعه) که EIGRP از آن استفاده میکند(مثل تمامی پروتکل‌های Distance Vector دیگر)که بهتر است! نه؟درکل، اینروزها دیگه با Open Standard شدن EIGRP، بحث‌های قدیمی که همیشه گفته میشد "چون شبکه Multi-vendorاست، باید از OSPF استفاده کنیم" تمام شده است و ازآنطرف، قدرتِ‌پردازش روترهای‌مدرنِ امروزی دیگر دربرابر الگوریتم‌ها و محاسبات OSPF کَم نمی‌آورند و تنها نکته‌ی مهم اینست انتخاب روتینگ‌پروتکل بستگی به شرایط دارد.یک - Integrationدرسته که روتینگ‌پروتکل EIGRP حالا به‌عنوان یک پروتکل استاندارد شناخته‌شده است و RFCهای آن دردسترس قرار گرفته‌اند؛ اما آیا واقعا درحال حاضر، بروی تمامی تجهیزات داخل سازمان شما، این RP تعبیه‌شده است و وجود دارد؟ پاسخ‌شما به احتمال بسیار زیاد خیر میباشد؛ مشکل سیسکو اینست که در بسیاری از مواقع سعی‌کرده است که مشتریان خودرا مجبور به Vendor lock-in کند و بسیاری از این کار خوششان نمی‌آید و دوست دارند که دست خودرا برای انتخاب تجهیزات دیگر، باز بگذارند. دو - Path Selectionتصمیم‌گیری برای انتخاب بهترین مسیر در OSPF بسیار باحال و حساب‌شده میباشد؛ RP با داشتن یک دیدِ کامل از تمامی اطلاعات موردنیاز و وضعیت‌ها در شبکه(معمولا یک Area)، بهترین مسیر موردنظر را انتخاب میکند و تمامی Forwarding decisionها براساس اینکه "کل شبکه به‌چه شکلی دارد عمل میکند" گرفته میشود، نه فقط بر اساس یک بخش کوتاهی که روتر نسبت به آن اطلاع دارد(?). گرچه قرار نیست که بگیم این راهکار مورد استفاده در Distance Vectorها و روش Routing by Rumor کاملا بد و بی‌مصرف است و Link-stateها عالین!؛ هرچی نباشه کل اینترنت ما برپایه BGPای که رفتارش مشابه Distance Vectorها است عمل میکند و حتی تصورش‌هم سخت است که رفتار مربوط به Link-stateها در اینترنت و این پروتکل، انجام پیاده‌سازی و انجام گردند(از BGP به عنوان یک پروتکل Path-Vector یاد میشود). زمان‌هایی هم هستند که به‌این اندازه دیدِکامل و اطلاعات زیاد، کاربرد ندارند و فقط باعث بار و پردازش زیاد میشوند، در اینجور مواقع مسلما EIGRP و BGP، بهترین موارد برای استفاده میباشند. سه - Route Summarizationدرمورد این موضوع زیاد نمیشه نظری خاصی رو اعلام کرد، نکته بسیارخوب در EIGRP اینست که درهرجایی، هر اینترفیسی و هرقسمتی، میتوانید Summarization انجام دهید و هیچ محدودیتی وجود ندارد؛ بسیاری بر این باورند که OSPF با اینکه محدودیت‌های در Summarization نسبت به EIGRPدارد، اما در Scaleهای بزرگ دقیقا همانجایی که نیاز میباشد این امکان را فراهم کرده‌است وشاید این قابلیت "Summarization در همه جا!" زیاد کاربردی نباشد.بسیاری معتقدند که درشبکه‌های بزرگ و خیلی پیچیده، OSPF گزینه‌بهتری میباشد، چراکه قدرت کنترل بیشتری به‌ما میدهد و عملکرد مفیدتری میتواند داشته باشد.(درمورد این موضوع، این مقاله‌ی نسبتا قدیمی از Jeff Doyle خیلی جالب و مفید هستش، پیشنهاد میکنم حتما مطالعه کنید.)در انتها، باتوجه به نتیجه‌های مختلفی که دیدم، همیشه و همیشه نکته بسیار مهم همان موضوعِ "بستگی دارد" میباشد و هیچوقت نمیتوان گفت که همیشه از فلان گزینه استفاده کنید، هرکدام از این روتینگ‌پروتکل‌ها، ده‌ها Concept و مفاهیم گوناگون برای شرایط گوناگون دارند، فقط میبایستی آن شرایط را تشخیص دهید و باتوجه به آنها، گزینه بهتر را انتخاب کنید.خوشحال میشم نظر و تحلیل شمارو هم درمورد این موضوع بدونم؛ حتما اگر چیزی در ذهنتون بود در قسمت کامنت‌ها ذکر کنید.موفق باشید. سجاد غفاریان سجاد غفاریان Wed, 03 Oct 2018 23:30:19 +0330 https://virgool.io/NetworkBaz/%D9%BE%D8%B1%D9%88%D8%A7%D8%B2%DB%8C-%D8%A8%D8%B1-%D8%AF%D9%86%DB%8C%D8%A7%DB%8C-%D8%A7%D9%85%D9%86%DB%8C%D8%AA-%D8%B4%D8%A8%DA%A9%D9%87-%D9%82%D8%B3%D9%85%D8%AA-%D9%BE%D8%A7%D9%86%D8%B2%D8%AF%D9%87%D9%85-%D9%85%D9%81%D8%A7%D9%87%DB%8C%D9%85-%D8%B1%D9%85%D8%B2%D9%86%DA%AF%D8%A7%D8%B1%DB%8C%D8%A8%D8%AE%D8%B4-%D8%A7%D9%88%D9%84-c4yhqcyoqnsn با سلام و عرض خسته‌نباشید خدمت تمامی دوستان خوبم؛ بعد از مدتی دوباره در خدمت شما هستیم با مبحثی جذاب و بسیار کاربردی!؛ در ادامه قسمت قبل از این سری آموزشی که درمورد VPNها صحبت کردیم، در این قسمت میخواهیم که مفاهیم و Conceptهای مربوط به مبحث رمزنگاری (یا همان Cryptography) را برای شما شرح دهیم و ببینیم که داستان از چه قرار است. در این مقاله درمورد تمامی مفاهیم موردنیاز از قبیل الگوریتم‌ها، هَشینگ، Encryption و... صحبت میکنم و سعی میکنم که یک مطلب و مقاله کاملی در این زمینه ارائه‌بدم. پس بامن همراه باشید ;) Cipher and Keysواژه‌شناسی و Terminology یکی از بخش‌های مهم یادگیری یک تکنولوژی میباشد، پس بزارید که قبل‌از شروع، بایکسری از موارد آشنا شویم: Ciphers: به مجموعه‌ای از یکسری قوانین‌خاص، Cipher ویا الگوریتم میگویند، این الگوریتم‌ها به‌ما به نحوه انجام Encryption و Decryption را شرح میدهند. امروزه صدها الگوریتم گوناگون رمزنگاری وجود دارند و بسیاری از آنها برای یسکری از محیطهای خاص ویا موارد خاص استفاده میگردند(مثل موارد دولتی و مربوط به امنیت ملی). از متدهای مرسومی که عموما Cipherها استفاده میکنند، میتوان به موارد ذیل اشاره کرد: ـSubstitution: در این نوع Cipherها، یکسری کاراکترها با یکسری کاراکتر دیگر جایگزین میشوند.ـPolyalphabetic: این روش تقریبا مانند همان روش قبلی میباشد، با این تفاوت که بجای استفاده از یک حرف از حروف الفبا، از چندین حرف و کاراکتر استفاده میگردد.ـTransposition: این روش Optionهای گوناگونی را ارائه میکند، مثل تغییر ترتیب حروف.کلیدها - Keys: کلیدها راهنماها و راهکاری برای reassemble کردن محتوا میباشند؛ بصورتی که در ابتدا محتوا توسط یک کلید مشخص‌شده و یکبار مصرف رمزنگاری میشود، سپس با این کلید که حاوی یکسری کاراکترها میباشد میتوان محتوا را در سَمت فرستنده رمزنگاری کرد و سپس در سمت گیرنده میتوان با همان کلید محتوا را رمزگشایی کرده و به داده اصلی دسترسی یافت.(در این بین فرایندهای بخصوصی هم برای انتقال کلید بین فرستنده و گیرنده انجام میگردد) Block and Stream Ciphersبر اساس نوع Cipher، الگوریتم‌های رمزنگاری(Encryption algorithms) میتوانند بروی قطعه(Block)ای از داده‌ها ویا Bit و Byteهای داده‌ها پیاده‌سازی گردند. به عنوان مثال بگذارید دو نمونه رو مقایسه کنیم. آشنایی با Block Cipher: ـBlock Cipher یک Symmetric Key Cipher میباشد که بروی گروهی‌از بیت‌ها(بلاک‌ها) پیاده‌سازی میگردد؛ یک Block Cipher Encryption algorithm ممکن است که یک بلاک 64بیتی از داده‌خام(Plain) را بگیرد و سپس یک بلاک 64بیتی Cipher Text به شما تحویل‌دهد. در این نوع Encryption از همان کلیدی که برای رمزنگاری استفاده شده است برای رمزگشایی هم استفاده میشود. از Symmetrical block cipher algorithmها میتوان موارد زیر را نام برد: Advanced Encryption Standard - AES Triple Digital Encryption Standard - 3DES BlowfishDigital Encryption Standard - DES International Data Encryption Algorithm - IDEA ـBlock Cipherها ممکن است در زمان‌هایی که بلاک‌ها به اندازه کافی دارای Data نمیباشند مقداری داده‌های موقت به بلاک اضافه کنند تا بتوانند یک بلاک کامل ایجاد کنند و سپس آنرا رمزنگاری کنند؛ به همین دلیل است که گاهی اوقات استفاده از این نوع Cipherها، دارای Overhead نسبتا بیشتری نسبت به دیگر Cipherها میباشد.ـStream Ciphers: ـStream Cipher یک Symmetric key cipher میباشد که در آن داده‌ها بیت‌به‌بیت توسط Key Stream رمزنگاری و Encrypt میشوند و در Output، به‌شما یک Ciphertext stream تحویل‌میدهد. بدلیل آنکه Cipher Stream مثل Block cipher نیازی به اضافه‌کردن داده برای Fitشدنِ‌بلاک ندارد، دارای Overhead کمتری نسبت به Block cipherها میباشد. Symmetric and Asymmetric Algorithms یادگیری دو مفهوم Symmetric و Asymmetric بسیار مهم و حیاتی میباشد، بگذارید قبل از هرچیز به Optionها و خصوصیات هرکدام نگاهی بیندازیم.ـSymmetric: همانطور که اشاره‌شد، یک الگوریتم رمزنگاری Symmetric(که همچنین به آن Symmetrical cipherهم گفته میشود) از یک کلید یکسان برای رمزنگاری و رمزگشایی داده استفاده میکند. هر دو دیوایس متصل‌شده توسط VPN که برای امن‌شدن از الگوریتم رمزنگاری Symmetric استفاده کرده‌اند، برای Encrypt و Decrypt موفقیت‌آمیز داده‌ها، به تمامی Key ویا Keyهای استفاده‌شده نیاز دارند. از الگوریتم‌های رمزنگاری Symmetric میتوان موارد زیر را نام برد: DES3DESAESIDEARC2, RC4, RC5, RC6Blowfishاین روزها، بسیاری از VPNهایی که ازآنها استفاده میکنیم از الگوریتم‌های رمزنگاری Symmetric استفاده میکنند؛ دلیل استفاده از این الگوریتم‌ها سرعت بسیار خوب و CPU Overhead بسیار کمتر آنها نسبت به الگوریتم‌های Asymmetric میباشد؛ باتوجه با ذات رمزنگاری و Encryption، میتوان گفت که هرچقدر که کلید طولانی‌تر و سخت‌تر باشد، به همان نسبت خواندن و متوجه‌شدن داده برای شخصی که دارای کلید نمیباشد سخت‌تر و غیرممکن‌تر میباشد. ما معمولا کلیدهارا با توجه به طول(Length)اشان نام‌گذاری میکنیم، یک کلید طولانی‌تر و بزرگتر به معنی امنیت بیشتر میباشد؛ طول یک کلید عادی عموما بین 112بیت الی 256بیت میباشد؛ برای یک symmetrical encryption algorithmـه امن طول کلید حداقل میبایستی 128بیت باشد تا بتوان گفت که به اندازه کافی Safe است.ـAsymmetric: از نمونه Asymmetric algorithmها میتوان الگوریتم‌های Public Keyرا نام برد؛ این الگوریتم‌ها در نوع خودشان بسیار جالب و جادویی میباشند!؛ در این نوع الگوریتم‌ها بجای استفاده از یک کلید یکسان برای رمزنگاری و رمزگشایی، از دو کلید متفاوت از یکدیگر برای Encryption و Decryption استفاده میکنیم(و نکته اینجاست که این دو کلید ازنظر ریاضی به یکدیگر ارتباط دارند و به عنوان یک Pair(جفت) عمل میکنند). به این جُفت Key pair و به یکی از این کلیدها Public Key(کلید عمومی) و به دیگری Private Key(کلید خصوصی) میگوییم. بذارید که نحوه عملکرد این دو را با یک مثال بررسی کنیم:فرض کنید که یک صدوقچه دارید که دارای یک قفل‌خاص میباشد؛ این قفل دارای دو Keyhole(سوراخ کلید) میباشد که یکی از آنها یک سوراخ‌ها بزرگ و دیگری کوچک میباشد؛ حالا نکته‌ی این قفل جادوئی اینجاست که اگر از سوراخ‌کلید کوچیکتر و کلید مربوط به خودش برای قفل کردن صدوقچه استفاده کنید، تنها راه باز کردن آن قفل، استفاده از Keyholeبزرگترِ و کلیدِ بزرگ مربوط به خودش میباشد و همین روال بصورت بلعکس هم میتواند انجام شود، یعنی اینکه میتوان از کلید بزرگ برای قفل کردن و از کلید کوچک برای بازگشایی آن استفاده کرد. این مثال رابطه‌داخلیِ بین Public key و Private Key را به خوبی توضیح میدهد، اما مشکلی که وجود دارد اینست که مصرف CPU در زمان استفاده از این KeyPairها برای Lock و Unlock داده‌ها بسیار زیاد میباشد و به همین دلیل‌است که در شرایط بسیار خاص از Asymmetric algorithmها استفاده میکنیم.بجای استفاده از آنها برای Encrypt کردن یک تکه‌داده، از آنها برای مواردی مانند "Authentication یک VPN Peer" ویا "ایجاد Keying materialـی برای Symmetrical algorithmهای خودمان" استفاده میکنیم. هردو این موارد نسبت به Encryptکردن کل پکت‌های کاربر، بسیار نادرتر میباشند.یکی از دلایلی که ما به این نوع الگوریتم Public key cryptography میگوییم اینست که ما همیشه اجازه میدهیم که یکی از این دو کلید بصورت عمومی انتشار داده شود و دردسترسی دیگران و هرکسی که میخواهد از آن استفاده کند، قرار بگیرد(Public Key). کلید دیگر ما Private key میباشد که همیشه میبایستی نزد دیوایسی که صاحب این KeyPair است محفوظ بماند. اگر بخواهیم مثالی از Public-Private Keypairها مثالی بزنیم، میتوان سر زدن به یک Secure Website را نام برد(وبسایت‌هایی که امن میباشند و از Https استفاده میکنند)؛ در Background از Public-Private Keypair سرور برای امن کردن Session استفاده میگردد؛ کامپیوتر شما به Public Key دسترسی دارد و سرور تنها دیوایسی است که دارای Private key میباشد؛ داده‌ها در سَمت کامپیوتر شما با استفاده از Public Key رمز میشوند و در سرور با استفاده از Private Key رمزگشایی میگردند. از Asymmetrical algorithmها میتوان موارد زیر را نام برد: ـRSA: که به افتخار ایجادکنندگان این الگوریتم Rivest، Shamir و Adleman از حروف اول نام آنها برای نامگذاری‌اش استفاده کرده‌اند؛ این روزها استفاده اصلی این الگوریتم برای authentication میباشد که البته بهش Public key cryptography standard (به اختصار PKCS)هم گفته میشود؛ طول کلید ممکن‌است بین 512 تا 2048 باشد که عموما برای امنیت نسبتا خوب، حداقل از کلید 1024بیتی استفاده میشود.ـDH: پروتکل Diffie-Hellman key Exchange؛ DH الگوریتمی میباشد که به دو دیوایس اجازه میدهد بر بستر یک شبکه غیرقابل‌اعتماد(Untrusted)، با یکدیگر Negotiate کنند و کلیدها و Secretهای موردنیاز خودرا Establishکنند. نکته جالب DH اینست که اگرچه خود الگوریتم Asymmetric میباشد، اما کلیدهای ایجادشده‌ی آن Symmetrical keyهایی میباشند که میتوانند توسط یک الگوریتم Symmetrical مثل 3DES و AES استفاده شوند.ـElGamal: این سیستم Asymmetrical بر اساس DH Exchange عمل میکند.ـDSA: این الگوریتم که اختصار Digital Signature Algorithm میباشد توسط National Security Agency ایالت‌متحده ایجاد شده است.ـECC: اختصار Elliptic Curve Cryptography میباشد. همانطور که گفته‌شد Asymmetrical algorithmها مصرف CPU Processing بیشتری نسبت به Symmetrical algorithm دارند اما به همان نسبت دارای امنیت بسیار بیشتری هم میباشند و عموما برای امنیت خوب، میتوانند دارای هر طول کلیدی بین 2048 تا 4096بیت باشند. در قسمت بعدی درمورد Hashها و موارد دیگر رمزنگاری صحبت خواهیم کرد...امیدوارم که این پست برای شما مفید واقع شده باشه.موفق باشید. سجاد غفاریان سجاد غفاریان Mon, 03 Sep 2018 19:07:16 +0430 https://virgool.io/NetworkBaz/%D9%BE%D8%B1%D9%88%D8%A7%D8%B2%DB%8C-%D8%A8%D8%B1-%D8%AF%D9%86%DB%8C%D8%A7%DB%8C-%D8%A7%D9%85%D9%86%DB%8C%D8%AA-%D8%B4%D8%A8%DA%A9%D9%87-%D9%82%D8%B3%D9%85%D8%AA-%DA%86%D9%87%D8%A7%D8%B1%D8%AF%D9%87%D9%85-%D9%85%D9%81%D8%A7%D9%87%DB%8C%D9%85-vpn-c710jqzeutnf بسیاری از سازمان‌ها برای فراهم کردن یکپارچگی‌داده، احراز هویت، و رمزنگاری‌داده از Virtual Private Networkها یا همان VPN ها استفاده میکنند تا از محرمانگی Packetهایشان بر بستر یک شبکه ناامن ویا اینترنت، اطمینان حاصل کنند. VPNها طراحی شده‌اند تا از هزینه‌های اضافی برای تهیه لاین‌های اختصاصی(Leased Line) بی‌کاربرد جلوگیری کنند؛ در ادامه قسمت قبل از این سری آموزشی، در این پست میخواهیم درمورد مفاهیم VPNها، رمزنگاری‌ها وهمچنین ضرورت استفاده از VPNها صحبت کنیم، پس با من همراه باشید ;) . اصلا VPN چیه؟اگر مفهوم Virtual Private Network را به بخش‌های جداگانه‌ای تقسیم کنیم، میتوان VPN را به این صورت تعریف کرد: ـ N - شبکه ویا Network، بستری که ارتباط و Connectivity را بین دو Device را فراهم میکند؛ این دو دیوایس میتوانند دو عدد کامپیوتر بروی یک LAN یکسان ویا دو کامپیوتر متصل به شبکه WAN باشند؛ به‌هرحال یک شبکه، Connectivity پایه‌ای را برای این دو دیوایس فراهم میکند. ـ V - مجازی ویا Virtual، به یک ارتباط منطقی(Logical connection) بین دو دیوایس نسبت داده میشود؛ برای مثال، یک کاربر ممکن است در تهران و یک کاربر دیگر در مشهد به اینترنت متصل شده‌باشند و ما میتوانیم برای این دو، یک شبکه منطقی(Logical network) بسازیم؛ این شبکه مجازی بین این 2 دیوایس، از اینترنت به عنوان transport mechanism استفاده خواهد کرد. ـ P - خصوصی ویا Private، شبکه‌مجازی‌ای که میتوانیم بین دو دیوایس حاضر در مشهد و تهران بسازیم، خصوصی و مخصوص سازمان‌شما خواهد بود.پس با توضیحات پایه‌ای و مفهومی VPN آشنا شدید؛ شبکه‌ِمجازی‌ِخصوصی!اگر ما بین دو دیوایس بر بستر اینترنت، VPNـی برقرار کنیم، چه چیزی باعث میشود که یک شخص نتواند پکت‌های مارا Sniff و بررسی کند؟ بصورت پیشفرض، هیچی! در نتیجه،ما به بسیاری از VPNها عناصری را اضافه میکنیم که محرمانگی و رمزنگاری را برای ما فراهم آورند، که اگر کسی پکت‌های ما را استراق سمع کرد، بدلیل استفاده از رمزنگاری، نتواند متوجه محتوای داخل پکت‌ها شود؛ این محرمانگی حاصل از رمزنگاری، میتواند از همان بخش P در حروف VPN حاصل شود.همچنین برای جلوگیری از تغییر و دستکاری پکت‌ها در بین مسیر، از Integrity checking استفاده خواهیم کرد و اطمینان حاصل میکنیم که از سَمت دیگر VPN، پکت‌هایی که ارسال‌شده‌اند را به شکل صحیح و درست میبینیم و عمل مخربی در این میان، صورت نگرفته‌است؛ بگذارید به مثال مشهد تهران خودمون برگردیم.اصلا چرا باید برای Connectivity بین این دو، از VPN استفاده کنیم وقتی که گزینه‌های دیگری هم روز میز است؟؛ میتونیم برای هرکدام از یوزرهای خود، یک Dedicated WAN(خط اختصاصی) بین مشهد و تهران خریداری کنیم. هر یوزر میتواند به سَمت خودش از لینک متصل شود و از ارتباط مستقیم بهره بگیرد. اما مشخصا مشکلی که در این میان وجود دارد، بحث قیمت میباشد؛ در اینگونه مواقع، بسیار عقلانی‌تر و ارزان‌تر است که از یک VPN بر بستر اینترنت برای برقراری ارتباط استفاده کنیم، تا اینکه بیاییم و یک "خط اختصاصی که فقط به یک مقصد خاص میرود" خریداری کنیم.یکی دیگر از مزیت‌های VPNها، Scalability(مقیاس‌پذیری) میباشد؛ اگر 10 ویا 20 کاربر دیگر هم نیاز داشته باشند که به مرکز اصلی بصورت مستقیم متصل شوند، ما میتوانیم براحتی از طریق Local Provider آنها این امکان برای برایشان فراهم کنیم؛ فقط با افزایش پهنای‌باند مرکز اصلی، میتوانیم هرتعدادی که میخواهیم برای کاربران بصورت Logical وبا استفاده از VPNها در بستر اینترنت، Connectivity فراهم کنیم. انواع VPNهابر اساس تعریف Virtual private networkها، موارد زیر میتوانند به عنوان تکنولوژی‌های VPN درنظر گرفته‌شوند: ـ IPSec: برای لایه سوم مدل OSI و IP Packetها، امنیت را پیاده‌سازی میکند و میتواند برای VPNهای Site-to-Site و remote-access استفاده گردد.ـ SSL: که اختصار Secure Sockets Layer میباشد، امنیت را برای یک TCP Session، با استفاده از قرار دادنش بروی یک SSL Tunnel رمزنگاری‌شده، پیاده‌سازی میکند و میتواند برای remote-access VPN ها استفاده گردد(مثل برقراری ارتباط رمزنگاری شده ی بین یک کلاینت و یک وب‌سرور که از HTTPS استفاده میکند).ـ MPLS: اختصار Multi-protocol Label Switching میباشد؛ MPLS و MPLS Layer 3 توسط Service Provider ارائه میشوند و به یک کمپانی اجازه میدهند که بین دو ویا چندین سایتشان Logical Connectivity داشته‌باشند و از شبکه SP برای انتقالات استفاده کنند. بصورت پیشفرض رمزنگاری‌ای برای L3 VPN وجود ندارد، اگرچه میتوان از IPSec درکنارش، برای رمزنگاری استفاده کرد.دو نوع اصلی از VPNهادو دسته‌بندی اصلی وجود دارد که VPNهای گوناگون در آنها قرار میگیرند: ـ Remote-access VPNها: ممکن است تعدادی از کاربران، نیاز به ایجاد یک VPN Connection بین یک‌کامپیوتر خاص و یک Headquarter اصلی(یا هرجای دیگر) داشته باشند، به این نوع ارتباطها Remote-access VPN Connection گفته میشود؛ remote-acceess VPNها میتوانند از تکنولوژی‌های IPSec ویا Secure Shell برای VPNهایشان استفاده‌کنند. به عنوان مثال بسیاری از مشتریان Cisco، از Cisco AnyConnect Client برای Remote-access SSL VPNهایشان استفاده میکنند. این روزها استفاده از SSL VPNها بسیار شایع‌تر میباشد، حتی باتوجه به اینکه AnyConnect از IPSec هم پیشتیبانی میکند(IKEv2).ـ Site-to-site VPNها: این نوع VPN ها توسط کمپانی‌هایی پیاده‌سازی میشود که نیاز به ارتباط مستقیم و امن بین سایت‌هایشان دارند(مثلا با استفاده از بستر اینترنت)، تا هر سایت بتواند با سایت‌های دیگر هم ارتباط داشته باشد؛ به این نوع پیاده‌سازی site-to-site VPN گفته میشود. site-to-site vpnها عموما از یک مجموعه از تکنولوژی‌های VPN به نام IPSec استفاده میکنند.برای بهتر متوجه‌شدن تفاوتشان، شکل زیر یک نمونه از VPNهای Site-to-site و یک نمونه از VPNهای remote-access را نشان میدهد. Cisco ASA در تهران و Headquarterاصلی قرار گرفته‌است و بصورتی کانفیگ شده‌است که Remote-access VPN Connectionهارا Accept کند و همچنین یک تانل site-to-site با یک مرکز در مشهد داشته‌باشد.مزایای اصلی VPNها چه از Remote-access VPNها استفاده کنید و چه از Site-to-site VPNها، از مزایای زیر بهره‌مند میشوند: Confidentiality(محرمانگی)Data integrity(یکپارچگی‌داده)Authentication(احراز هویت)Antireplay protection بگذارید به هریک، نگاهی دقیق‌تر بیندازیم: Confidentiality:ـ Confidentiality ویا محرمانگی به این معنی میباشد که فقط دیوایس‌های موردنظر میتوانند متوجه داده‌های ارسالی بشوند و محتوای آنهارا بفهمند. اگر دربین راه شخصی پکت‌هارا ببیند، نمیتواند از محتوای آنها سردربیاورد، چراکه محتوا به شکل حروف و اعداد بدون معنی و مفهوم میباشند؛ به عنوان مثال ممکن است محتوای پکت‌ها به این شکل باشند: سیستم Confidentiality مهمترین مزیت VPNها میباشد، چراکه فقط ارسال‌کننده و دریافت‌کننده که کلید(Key) ویا Secret را بلدند میتوانند داده‌هارا رمزنگاری و رمزگشایی کنند و هرشخصی که از این کلید اطلاعی نداشته باشد، قادر به Decrypt پیغام نمیباشد و صرفا دیدن این داده‌های نامفهوم برایش فایده‌ای ندارد. Data Integrity: اگر دو دیوایس بروی بستر یک VPN درحال ارتباط و انتقال پکت میباشند، یکی دیگر از موارد قابل اهمیت اینست که داده بصورت سالم و صحیح، end-to-end ارسال و دریافت شود و اتکر در بین راه قادر به خراب‌کردن داده و Injectکردن کوچکترین Bitـی نباشد. Authentication:مسلما برای امن نگه‌داشتن ارتباطات VPN ها، میبایستی از یک روش احرازهویت استفاده شود که مبادا Connectionشما بین دیوایس شما و اتکر برقرار شود ! ، پس نیاز به روشی برای احرازهویت خواهیم داشت تا بتوانیم فقط به افراد و موارد موردنظر خودمان اجازه برقراری ارتباط بدهیم. برای Authentication یک Peer راه‌های گوناگونی وجود دارد: Pre-shared keys - used for authentication onlyPublic and private key pairs - used for authentication onlyUser authenticationAnti-replay Protection:ممکن است یک Attacker، ترافیک VPN شمارا Capture کند و قصد این‌را داشته‌باشد که دوباره آنرا بازی‌دهد و ازش استفاده کند تا بتواند یکی از VPN Peerهارا به‌اشتباه بیندازد که باور کند که این Peer ، یک دیوایس مجاز میباشد؛ با این روش، دیوایس Attacker وانمود میکند که یک دیوایس دیگر است که مجاز به ادامه ارتباط است. بصورت پیشفرض برای جلوگیری از این حمله، در VPNها عملکردهایی برای جلوگیری از این‌مورد انجام میگیرند؛ به زبان ساده بخواهیم بگوییم به این صورت است که یکبار که یک پکت بر بستر VPN ارسال شود، دیگر همان بسته برای بار دوم در VPN Sessionفعلی، Valid نمیباشد.امیدوارم که این قسمت براتون مفید واقع شده باشه.در قسمت آینده درمورد Cryptography صحبت خواهیم کرد.موفق باشید. سجاد غفاریان سجاد غفاریان Mon, 13 Aug 2018 15:41:55 +0430 https://virgool.io/NetworkBaz/%D8%A7%D9%85%D9%86%DB%8C%D8%AA-bgp-%D9%86%DA%AF%D8%A7%D9%87%DB%8C-%D8%A8%D8%B1-bgpsec-i8aydcwarohx با سلام و عرض خسته‌نباشید خدمت تمامی دوستان عزیز؛ با بالا رفتن داستان‌های مربوط به BGP و اخبار مربوط به Hijackingهایی که در شبکه‌های‌اجتماعی و... میشنویم، گفتم خوب‌میشه که مقاله‌ای بنویسیم که توش بتونیم بحث‌های مربوط به امنیت در BGP رو بررسی کنیم و شرح بدیم. پس با من همراه باشید تا این مبحث رو باهم باز کنیم و بروی BGPSec هم نگاهی بیندازیم ;)افزونه: چند روز پیش در ویرگول، درمورد BGP Hijacking مربوط به تلگرام مطلبی نوشتم که مطالعه‌اش بنظرم بد نیست و میتونه مفید باشه.مشکلات امنیتی موجود در BGPپروتکل مسیریابی BGP، درزمان طراحی بصورت یک پروتکل امن نوشته‌نشده است و دارای اشکالات امنیتی بسیاری است هنوز که هنوزه، تمامی آنها حل نشده‌اند و بسیاری از کارشناسان و فعالان حوزه شبکه و امنیت‌شبکه معقداند که پروتکل BGP، هنوز یک پروتکل کاملا امن نمیباشد. یکی از انواع حملاتی که در BGP میتواند انجام شود، Route Hijacking میباشد و زمانی پیش‌می‌آید که یک AS مسیری نامعتبر و جعلی در شبکه Advertise میکند.(مثل داستان مربوط به تلگرام). اخیرا نوع جدیدی از این حملات انجام میشوند که ترکیبی از حملات BGP Hijacking و Man-in-the-middle میباشند؛ در این نوع حمله، ترافیک به یک نقطه‌خاص ارسال میشود و سپس از آن نقطه‌خاص به مقصد اصلی ارسال خواهد شد؛در نتیجه در اینجور مواقع اگر ترافیک رمزنگاری نشده‌باشد براحتی برای دریافت‌کننده‌ی‌میانی قابل مشاهده و بررسی است. امنیت BGPحالا در مقابل، برای جلوگیری از این حملات چه کاری میتوان انجام داد؟ سازمان Internet Engineering Task Force یا همان IETF اقدامات قابل توجهی برای امن کردن Routeها انجام داده‌است، نظیر ایجاد RPSL و SIDR. گروه Secure Inter-Domain Routing Working Group یا همان SIDR راهکارهایی را توسعه‌میدهند که برای امنیت BGP کاربرد خواهند داشت و برای احرازهویت Routeها در زمان Exchanging بکاربرده میشوهد.بعد از حادثه هایجک شدن YouTube توسط پاکستان در سال 2008، مسئله امنیت BGP بسیار مهمتر و قابل‌توجه‌تر شد. هدف اصلی SIDR کاهش اشکالات‌امنیتی در Inter-domain Routing system ها میباشد و دو آسیب‌پذیری‌ای که بیشترین تمرکز بروی آنها میباشد موارد زیر است: آیا یک AS اجازه ایجاد یک IP Prefix را دارد؟آیا AS-Path ارائه‌شده در Route همان مسیری میباشد که NLRI از آن استفاده کرده است؟(Network Layer Reachability Information)برای حل مورد دوم بروی راهکاری تمرکز شده‌است که کار AS Path Validation را انجام میدهد، به این راهکار BGPSec میگویند. BGPSec سعی‌میکند که اطمینان‌خاطر دهد که BGP Update دریافت شده توسط BGP Peer بدرستی مسیری را ارائه‌میکند که خود پیغام Update از فرستنده تا گیرنده طی کرده است. تا الان 40عدد RFC توسط SIDR بصورت رسمی ارائه‌شده است و درحال‌حاضر 2 عدد هم پیشنویس درحال بررسی دارند؛ میتوان گفت که RFCهایی که در سال 2017 برای BGPSec از حالت پیشنویس خارج‌ و بصورت رسمی ارائه‌شدند، قدمی بزرگ برای امنیت روتینگ برداشتند: ـ RFC 8205 - مشخصات BGPSec Protocolـ RFC 8206 - ملاحظات BGPSec برای انتقال ASـ RFC 8207 - ملاحظات عملیاتی BGPSecـ RFC 8208 - الگوریتم‌ها، کلیدها و امضاهای BGPSecـ RFC 8209 - گواهی‌نامه‌های BGPSecـ RFC 8210 - معرفی RPKIـ RFC 8211 - اقدامات مربوط به RPKIداکیومنت RFC 8205 توضیحات و مشخصاتی از BGPSec میباشد که بصورت استاندارد انتشار یافته‌است؛ در RFC به این صورت توضیح داده‌شده است که BGPSec یک افزونه برای روتینگ پروتکل BGP میباشد که میتواند توسط BGP Update Messageها امنیت را برای مسیر(Path)ها فراهم کند. BGPSec میتواند توسط یک Path Attributeـه اختیاری در BGP به‌نام BGPsec_Path، پیاده‌سازی شود. این مشخصه حاوی یک Digital Signature میباشد که میتواند توسط هر ASـی که Update message را انتشار میدهد، ایجاد شود. Digital Signature به‌ما این قابلیت را میدهد که فقط ASهای موجود در "لیست ASهای Update message" اجازه Advertise کردن Route را داشته‌باشد.در اصل، مقصود اصلی از ایجاد BGPSec ،فراهم کردن مکملی برای BGP Origin Validation میباشد(RFCهای 6483 , 6811) تا در زمانی که عمل Origin Validation(تصدیق مبدا) انجام میشود، بتوان بصورت همزمان از عمل Route Hijacking هم جلوگیری به عمل آورد؛ این کار توسط گواهی‌نامه‌های Resource Public Key Infrastructure(به اختصار RPKI) انجام میشود که تخصیص AS Numberها و IP Address هارا تصدیق و تایید میکند.(RFC 6480).همانطور که در RFC 6480 شرح داده‌شده‌است، سیستم RPKI راهی برای بهبود Routing Security میباشد که توسط همکاری IP Address Rangeها و ASNها از طریق Cryptographic Signatureها انجام داده‌میشود؛ RKPI از X.509 Certificateها استفاده میکند(که همراه افزونه‌هایی از IPv4 و IPv6 پریفیکس‌ها و ASNها میباشد).(RFC 3779).در زمان درخواست منابع، RIRها(APNIC، ARIN، AFRINIC، LACNIC و RIPE NCC) این Certificateهارا برای Resource Holderها صادر میکنند؛ عموما Certificateها هر سال Renew میشوند و هر RIR از Certificate شخصی و مربوط به سازمان خودش برای امضا Certificateهای صادر شده‌اش استفاده میکند. RKPI به Network Operatorها اجازه میدهد که یک اطلاعیه رمزنگاری‌شده و قابل اعتبارسنجی درمورد "route announcementهایی که آنها توسط ASN و IP Prefixهای خودشان مجاز به انتشار میباشند" ایجاد کنند.به این اطلاعیه‌ها Route Origin Authorisations (به اختصار ROA) گفته میشود، که همچنین میتواند برای مشخص کردن Maximum طول یک Prefix که یک AS مجاز به Advertise کردنش میباشد، استفاده شود. (مقاله مدیریت ROAها در RIPE) در تصویر زیر، توسط ابزار RIPE NCC RPKI Validator Tool، آمده‌ایم Prefixهایی که AS25 و AS42 مجاز به تبلیغ میباشند را استخراج کردیم. مقاله: نحوه Math کردن RKPI در سیسکو درصورت استفاده از BGPSec، مکانیزم عادی‌ما، حالا نیاز به استفاده از یک BGP attribute دیگر دارد و Negotiation با دیگر eBGP Peerها درمورد BGP capability؛ پس در نتیجه کم‌کم به Peerهای ما پیشنهاد داده میشود که با یکدیگر به توافق برسند و از این به بعد، با استفاده از BGPSec بایکدیگر صحبت کنند. در دنیای اینترنت آینده، Interconnected ASهایی که از BGPSec استفاده میکنند، قادر به تضمین این مورد میباشند که تمامی Routeهای Advertiseشده بدرستی و بدون اشکال توزیع شده‌اند؛ اگرچه زیبایی و قشنگی BGP امن‌شده، زمانی دیده میشود که non-BGPSec speakers کمتری در Routing Pathها وجود داشته باشد.امیدوارم که تا به اینجا این مقاله برای شما مفید بوده باشه و مورد توجه شما واقع بشه؛ انشاالله اگر استقبال خوبی از کاربران دریافت کنم، سعی میکنم که مقاله‌های بیشتر و بهتری درمورد این موضوع براتون آماده کنم.این مقاله از IETF Journal بسیار عالی هستش در این زمینه و بهتون پیشنهاد میکنم که حتما مطالعه کنید. موفق باشید. سجاد غفاریان سجاد غفاریان Mon, 06 Aug 2018 13:01:27 +0430 https://virgool.io/NetworkBaz/%D8%AF%D9%88%D8%B1%D9%87-%D8%A2%D9%85%D9%88%D8%B2%D8%B4%DB%8C-sdn-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-%DA%A9%D9%86%D8%AA%D8%B1%D9%84%D8%B1-hyskf8xwpqbv با سلام و عرض خسته‌نباشید خدمت همه دوستان عزیز؛ در ادامه قسمت قبلی از این سری آموزشی،امروز با مبحث کنترلر (Controller)ها، معماری‌توزیع‌شده و معماری‌متمرکز در خدمت‌شما هستم. در حدود سال 2010، رویکردهای جدید مربوط به شبکه‌های کامپیوتری ظهور کردند؛ رویکردهایی که محل تعدادی از توابع Control-planeهارا تغییر میدادند؛ بسیاری از این رویکردها، قسمت‌هایی از عملکرد Control-planeهارا وارد یک نرم‌افزار Centralizedشده به اسم کنترلر (Controller) کردند که در ادامه میخواهیم با مفاهیم مربوط به کنترلرها و معماری‌های شبکه آشنا شویم. با من همراه باشید ;).کنترلرها و کنترل‌متمرکز(Controllers and Centralized Control)اکثر پردازش‌های Control-planeهای سُنتی از یک معماری‌توزیع‌شده(Distributed Architecture) استفاده میکنند، یعنی اینکه Control-plane توزیع میشود و روی Deviceهای گوناگون اجرا میشود؛ برای مثال هر روتر، Processـه مربوط به Routing Protocolـه OSPFـه خودش را بصورت جداگانه اجرا میکند. آن Processهای مربوط به Control-planeهای توزیع‌شده، برای درست‌کار کردن از ارسال پیام به یکدیگر برای ارتباط(Communicate) استفاده میکنند؛ مثلا پروتکل OSPF که در بین روترهای خود، پیغام‌ها و پکت‌ها گوناگونی رد و بدل میکند. درنتیجه میتوان اظهار داشت که شبکه‌های سُنتی، از یک Distributed Control-plane استفاده می‌کنند.افرادی که مفاهیم Control-planeهای امروزی مانند STP،OSPF،EIGRP و... را ایجاد کرده‌اند، میتوانستند تصمیم بگیرند که از یک Control-planـه متمرکز استفاده کنند و منطق را در یک نقطه(دیوایس ویا سرور) قراردهند و لازم نباشد که پراسس‌های مربوط به Control-planeها، روی هر دیوایسی بصورت جداگانه اجرا شود؛ و در ادامه، نرم‌افزار مرکزی هم میتوانست با استفاده از پروتکل‌های مربوط به Messaging، اطلاعات گوناگون را از هر دیوایسی که میخواهد بدست آورد اما پردازش‌های مربوط به آنهارا در یک نقطه مرکزی(که میتواند دید وسیع‌تری نسبت به شبکه داشته‌باشد) انجام دهد؛ اما خب آنها تصمیم گرفتند که بجای این راهکار، از یک معماری‌توزیع‌شده استفاده کنند.برای انجام هرعملکردی در شبکه، مزایا و معایب گوناگونی برای معماری‌های توزیع‌شده و متمرکز وجود دارد؛ بسیاری از Control-planeها ، دارای سابقه طولانی و خوبی در "عملکرد در معماری‌توزیع‌شده" میباشند. به‌هرحال یک نوشتن یک اپلیکیشن متمرکز، بسیار آسان‌تر از نوشتن یک اپلیکشن توزیع‌شده میباشد؛ چراکه اپلیکیشن متمرکز، تمامی اطلاعات و موارد موردنیازش را در یک نقطه و بصورت آماده، دارد؛ حالا میتوان گفت که این دنیای‌نوظهورِ SDN و Network Programmability عموما از یک معماری متمرکز  و توابع و عملکردهای مربوط بهش در سرویسی به‌نام کنترلر (Controller)، استفاده میکند.یک کنترلر ویا یک SDNکنترلر(SDN Controller)، کنترل تجهیزات شبکه را، متمرکز میکند؛ اینکه چه‌مواردی، به چه اندازه‌ای Centralized بشوند، میتواند متفاوت باشد. برای شرح بیشتر ایده ی یک کنترلر، تصویر زیر را درنظر بگیرید، یک SDN Controller تمامی عملکردهای مهم Control-plane را متمرکز کرده‌است.در ابتدا، Controller درجایی از شبکه قرار میگیرد که بتواند به تمامی Devicesهای داخل‌شبکه از طریق IP دسترسی داشته‌باشد و بتواند آنهارا ببیند؛ همچنان هرکدام از دیوایس‌های شبکه، دارای یک Data-plane میباشند اما درنظر داشته‌باشید که هیچکدام از آنها دارای Control-plane نمیباشند. در تغییرات مربوط به SDN(همانطور که در شکل میبینید) ، کنترلر(یا برنامه‌ای که از Controller استفاده میکند) بصورت مستقیم تمامی Data-plane Entryهای جداول هر Deviceرا برنامه‌ریزی و مقداردهی میکند و دیگر دیوایس‌های ما جداول مربوط به Forwardingاشان را با استفاده از پردازش‌های سُنتی Control-planeتوزیع‌شده پُر نمیکنند.شکل فوق، فقط یک مدل از network programmability و SDN را نمایش‌میدهد، درحالی که موارد دیگری‌هم وجود دارند؛ این تصویر به ما پیش‌زمینه خوبی برای صحبت کردن درمورد کانسپت‌ها و مفاهیم مهم دیگر میدهد، بخصوص درمورد ایده‌های Southbound Interface(به اختصار SBI) و Northbound Interface(به اختصار NBI) که در ادامه قصد داریم که درموردشان صحبت کنیم. The Southbound Interfaceدر یک معماری شبکه برپایه کنترلر، کنترلر نیاز به صحبت‌کردن و ارتباط با دیوایس‌های داخل‌شبکه دارد؛ مثل تصویری که در بالا به شما نشان دادیم، عموما Networking Deviceها در نقشه‌ها و مستندات طراحی‌ و معماری‌های‌شبکه در زیر Controller قرار میگیرند، در بین کنترلر و دیوایس‌های‌شبکه یک Interface قرار دارد و با توجه به محل آن اینترفیس در شکل، به آن اینترفیس Southbound Interface یا SBI گفته میشود.نکته: درحالت عادی، کلمه Interface به کانکتور فیزیکی‌ای بروی روترها و سوئیچ‌ها نسبت داده میشود، اما در این مبحث، کلمه Interface(که در داخل SBI،NBIوAPI هم قرار دارد) به رابطها و اینترفیس‌های نرم‌افزاری نسبت داده‌میشود.ـ Application Programming Interface یاهمان API، متدی برای انتقال و جابجایی اطلاعات بین 2 اپلیکیشن میباشد یا اگر بخواهیم به‌شکل دیگری تعریفش را بیان کنیم، بایستی گفت که یک API، یک اینترفیس به یک اپلیکشن میباشد؛ برنامه‌ها داده‌هارا پردازش میکنند و API به آنها اجازه میدهد که داده‌هایشان را جابجا کنند. پروتکل‌ها عموما بایک ساختار و بدنه مشخص و مستندشده عمل میکنند، اما API عموما دارای کدها، توابع،متغییرها و ساختمان‌داده‌های گوناگون میباشند، که برنامه دیگری درداخل شبکه میتواند از آنها استفاده کند.بگذارید به همان SBI برگردیم؛ SBI یک اینترفیس بین کنترلر و نرم‌افزار روی دیوایس‌های‌شبکه است و اجازه میدهد که این دو بایکدیگر ارتباط داشته‌باشند، با این هدف که کنترلر بتواند Data-plane دیوایس را مدیریت کند. دریک معماری‌شبکه که برای Network Programmability ایجاد شده‌است، قابلیت‌های SBIها و APIهایشان، اطلاعات زیادی از توانایی‌ها و ضعف‌هایشان در اختیار ما قرار میدهند؛ برای مثال ممکن است بعضی از کنترلرها برای یکسری اهداف خاص، فقط اجازه استفاده از یک SBI (یا تعداد کم) را بدهند، درصورتی که بقیه موارد از تعداد زیادی SBI پشتیبانی میکنند و دست‌مارا در استفاده از SBIها باز میگذارند. مقایسه انواع SBIها، توضیحات و جزئیات مربوط به خودش را دارد که از حوصله این مطلب خارج است. در ادامه به شما 3 نمونه از معماری‌ها را معرفی میکنیم که بصورت اتفاقی، SBIهای گوناگونی هم دارند: ـ Openflow(از ONF)ـ OpFlex(از Cisco؛ توسط ACI استفاده میشود)ـ CLI(تلنت/SSH و SNMP؛ از Cisco؛ توسط APIC-EM استفاده میشود)The Northbound Interfaceبه پیش‌نیازهای برنامه‌نویسی که برای کنترلر موجود در عکس‌قبلی نیاز میباشد فکر کنید، تمرکز تصویر بر این‌است که به شما نشان دهد که کنترلر میتواند به Forwarding tableهای دیوایس‌ها Entry اضافه کند؛ اما سوال اینجاست که کنترلر از کجا میداند که چه‌چیزی را میبایستی به جدول‌ها اضافه کند؟ به چه صورت عمل میکند؟ قبل از اضافه کردن مقادیر، کنترلر شما به چه موارد و اطلاعاتی نیاز دارد تا بتواند مقداری را Addکند؟ احتمالا این موارد به ذهنتان میرسد:یک لیست از تمامی دیوایس‌ها در شبکهقابلیت‌های هر دیوایس(capabilities)اینترفیس‌ها و پورت‌های هر دیوایسوضعیت‌فعلی هر پورتتوپولوژی: هر دیوایس به چه‌جاهایی(دیوایس‌های دیگر) وصل شده‌است و بروی کدام اینترفیس‌ها این ارتباط را برقرار کرده‌اند.پیکربندی فعلی دیوایس: IP Addressها، VLANها و الی آخر... .در یک مدل کنترل‌متمرکز، کنترلر اکثر کارهای موردنیاز و مربوط به Control-planeرا انجام میدهد و تمامی اطلاعات مفید را از شبکه جمع‌آوری میکند(مثل مواردی که در لیست بالا مطرح شد) و در نهایت، خود کنترلر به تنهایی میتواند repository یا مخزنی‌متمرکز از این اطلاعات، برای شبکه، ایجاد کند.ـ NBIـه یک کنترلر بصورتی است که راه ارتباط مستقیم با کنترلر را برقرار میکند تا برنامه‌های دیگر بتوانند از دیتا و توابعش استفاده کنند. برنامه‌های گوناگون میتوانند اطلاعات گوناگونی را با استفاده از APIـه کنترلر، استخراج نمایند و همچنین NBI به برنامه‌ها اجازه میدهد که با استفاده از SBI از قابلیت‌های Controller در ارسال جریان ترافیکی به دیوایس‌ها استفاده کنند.برای اینکه ببینید NBI در کجا قرار میگیرد، در ابتدا درمورد خود Controller فکر کنید...، کنترلرِ ما یک نرم‌افزار است که بروی یک سرور اجرا شده‌است(که میتواند یک VM ویا یک سرور فیزیکی باشد)؛ یک اپلیکیشن میتواند بروی همان سروری که کنترلر قرار دارد اجرا شود و از یک NBI استفاده کند، ودر نتیجه هردو نرم‌افزار میتوانند با یکدیگر صحبت کنند(با استفاده از API).برای مثال به شکل زیر توجه کنید؛ مستطیل نارنجی رنگ نشان‌دهنده محل استقرار "نرم‌افزار کنترلر" میباشد؛ در این مثال ما کنترلر ما با استفاده‌از زبان Java نوشته‌شده است و یک دارای یک Java-based Native API میباشد. هرکسی میتواند براحتی اپلیکیشنی بنویسد که بروی این سیستم اجرا شود و از Java API کنترلر استفاده کند. با استفاده از آن API، اپلیکیشن میتواند اطلاعات گوناگونی درمورد شبکه بدست آورد؛ همچنین اپلیکشن میتواند که جریان‌های شبکه را مدیریت کند؛ کافی‌است از کنترلر بخواهد تا Action خاصی را در Forwarding tableهای دیوایس‌ها انجام دهد.نکته: NBI بر اساس محل قرارگیری در نقشه(بالای کنترلر) نامگذاری میشود، فقط کافیست که بدانید که شمال نقشه شما کجا میابشد. به همین راحتی!قبل از اینکه از بحث مربوط به NBIها خارج شویم، بگذارید نگاهی نزدیکتر به دیگر APIهایی که برای یک کنترلر استفاده میگردند داشته باشیم؛ Representational State Transfer (به اختصار REST) نوعی API میباشد که به اپلیکیشن‌ها اجازه میدهد بروی Hostهای مختلفی قرار بگیرند و از HTTP برای انتقال پیغام بر بستر API استفاده میکند.وقتی که شما نمونه‌های مربوط به SDN که با "یک اپلیکیشن بروی همان سیستم کنترلر" همراه است را میبینید(مانند تصویر بالا)؛ در این شرایط نیازی نیست که API پیغام‌هارا بر بستر شبکه ارسال کند، چراکه هردو برنامه بروی یک سیستم مشترک اجرا شده‌اند. اما وقتی که اپلیکیشن‌های ما بروی سرورها و سیستم‌های جدا از هم قرار گرفته باشند، نیاز است که API بتواند داده‌هارا بر بستر IP ارسال و دریافت کند، و اینجاست که RESTFUL APIها به کمک ما می‌آیند.شکل زیر، ایده اصلی REST API را نشان میدهد؛ اپلیکیشن بروی یک Host دیگر در بالای تصویر اجرا میشود و در این مثال، در مرحله اول، به یک URI خاص یک درخواست HTTP GET ارسال میکند. URI برای شناسایی یک Object بروی کنترلر استفاده میشود؛ برای مثال ممکن است که URI ما لیستی از اینترفیس‌های فیزیکی یک دیوایس به همراه وضعیت هریک از آنها باشد. در مرحله دوم، کنترلر پیغام بازگشتی را بصورت یک HTTP GET Response message به همراه Object ارسال میکند؛ اکثر REST APIها، درخواست دریافت یک داده‌ی ساختاریافته را میکنند و عموما از فرمت‌های مانند XML یا JSON برای Network programmability استفاده میکنند(مثل مرحله سوم در شکل فوق).امیدوارم که این قسمت براتون مفید واقع شده باشه...موفق باشید. سجاد غفاریان سجاد غفاریان Sat, 04 Aug 2018 15:20:22 +0430 https://virgool.io/InfoSec/iran-bgp-hijacking-b1ndn2zdgiq2 با سلام و عرض خسته‌نباشید خدمت همه دوستان عزیزم. به عنوان اولین پستم در ویرگول، دوست داشتم درمورد مبحثی که این روزها درموردش صحبت‌های بسیاری میشود افراد گوناگونی بخاطرش محکوم میشوند، بنویسم. در اینجا میخوایم بررسی کنیم که واقعا قضیه از چه قرار است و داستان چیه. صرفا مطالب کوتاه و توئیت‌های دیگری هم در این زمینه، بعد از این اتفاق، توی اینترنت انتشار پیدا کرد که کمی برای مردم این موضوع را توضیح دهد... اما اکثرا ناقص بوده ویا خیلی بد منظور را رسانده بودند... سعی میکنم تا تاجایی که امکان دارد از وجه تکنیکال موارد رو مطرح نکنم تا برای کسانی که کمتر با مفاهیم شبکه آشنا هستند، قابل درک باشد.قضیه از چه قرار است؟روز هشتم‌مردادماه(به میلادی 2018/07/30) وبسایت BGPStream، اطلاعیه‌ای انتشار داد که نشان میداد عمل Hijackingـی در مسیرهای BGP اتفاق افتاده است(لینک رویداد در وبسایت) :توئیت اکانت مربوط به BGP Streamحالا اصلا ببینیم که BGP چیه؟ وبسایت نامبرده کارش چیه و اصلا این اتفاقی که پیش‌اومده چی هستش؟ چرا این اتفاق افتاده؟ و در نهایت این اتفاق چه عواقبی در پیش داره؟خطاب به دوستان‌متخصص: بنده سعی دارم که تاجایی که امکان داره موارد فنی رو ساده و کوتاه بیان کنم، به همین دلیل از خیلی از پیش‌نیازهای نالازم(در این مقاله) و شرح‌های پیچیده میگذرم و سعی میکنم که خیلی ساده فقط منظور رو برسونم... چراکه این مقاله مقاله‌ای تکنیکال نیست. پس درمورد یکسری موارد، زیاد سخت نگیرید، چون نمیخوام بیش‌ازحد کاربر رو گیج کنم ?.مسیریابیپروتکل BGP که اختصار Border Gateway Protocol میباشد، روتینگ پروتکل مربوط به مسیریابی اینترنت است. حالا این یعنی چی؟اگر مسیریابی رو بخوایم به زبان ساده بخوایم شرح بدیم: توی زیرساخت مربوط به شبکه، هر کامپیوتری دارای یک IP Address هستش.این کامپیوترها با استفاده از کابل‌های شبکه به تجهیزاتی به اسم سوئیچ متصل میشوند. فرض کنید 6 ساختمان داریم و در داخل هر ساختمان یک سوئیچ قرار داده‌ایم. توی هر ساختمان، 20 کامپیوتر به هر سوئیچ متصل هستند. بلفرض IP Rangeـه مربوط به هرکدام از ساختمانها متفاوت ازیکدیگر هستند، پس داخل هر ساختمان یک دستگاه به اسم روتر قرار میدهیم که سوئیچ‌های ما آنها متصل شوند و روترها هم به یکدیگر متصل میشوند.پس هرکدوم از روترهای ما دارای یک رنج آی‌پی مخصوص به خودش است و وقتی کامپیوتر ما میخواهد پکتی به شبکه‌ای خارج‌از شبکه خودش ارسال کند(مقصدی که نمیشناسد و در IP Rangeـه او قرار ندارد)، می‌آید و بسته را به Default Gatewayـه خود یعنی روتر ساختمانش تحویل میدهد. روتر ما با اساس یکسری معیارهایی که برای خودش دارد(به این معیارها Metric گفته میشود)، تصمیم میگیرد که بسته را از چه مسیری به مقصد برساند که بهینه‌ترین مسیر باشد؟(از نظر کوتاهی مسیر،سرعت مسیر و...).مثلا فرض کنید که روتر ساختمان 1 میخواد به ساختمان 6 بسته‌ای ارسال کنه. همچنین فرض کنید که روترهای ما بصورت زیر(رنگ قرمز) کابل کشی شده‌اند؛ کدوم مسیر برای رسیدن به مقصد بهتر و کوتاه‌تره؟ مسیر اول یا دوم؟مسیر اولمسیر دوممسلما مسیر دوم بهتره!پروتکلی که تصمیم‌گیری‌های مربوط به این مسیریابی‌های خودکار رو انجام میده، بهش میگن روتینگ پروتکل.هر روتر به روترهای همسایه مسیرهایی که یاد داره رو اعلام میکنه و این اعلام کردن به روتر همسایش کمک میکنه که مسیر مقصدش رو پیدا کنه و بهینه‌ترین مقصد روهم پیدا کنه.این اعلام کردن مسیرهایی که یاد داره رو، بهش میگن Advertise(تبلیغ) کردن، یعنی اینکه این مقصدی رو که میخوای بهش برسی رو من بلدم، باید از اینجا بری... این نکته رو تو ذهنتون داشته باشین، در ادامه باهاش کار داریم ?.پروتکل BGPحالا باید گفت که ما روتینگ پروتکل‌های گوناگونی داریم، مثل RIP،OSPF،EIGRP و... ؛ اما تنها پروتکلی که در سطح اینترنت بکاربرده میشه و قابلیت Handle کردنه این حجم مسیر رو داره، پروتکل BGP هستش.مثالی که من زدم رو، سعی کنید مقیاسش رو بیشتر کنید و هر کشور رو مثل همون ساختمان‌ها فرض‌بگیرید...حالا میتونیم درمورد مواردی که میخوایم راحت‌تر صحبت کنیم...فرض کنید که تمامی سرورهای مربوط به تلگرام در لندن قرار گرفتن و دارای یک رنج خاصی IP آدرس میباشند. روترهای Service Providerهای لندن به تمامی روترهای همسایه‌اشان اطلاع میدهند و میگویند هرموقع خواستید به این مقصد(IPـه تلگرام) برسید، باید بسته‌هایتان را به ما تحویل بدید(میشه همون Advertise کردنی که درموردش صحبت کردیم...).(که روترهای مرزی و اصلی هم به همین صورت مسیریابی رو مرحله به مرحله انجام میدن که بسته رو به سرور مقصدش برسونن).حالا اتفاقی که افتاده اینه که روترهای مخابرات ایران به همسایه های خودشون در کشورهای دیگه، اعلام کردن که من مقصد شما(تلگرام) رو بلدم کجاس، باید به من تحویل بدید تمام بسته‌هاتون رو.که اصطلاحا گفته میشه که Routeـه مربوط به تلگرام رو Advertise کردن و بجای روترهای لندن، خودشون رو به‌عنوان مقصد معرفی کرده‌اند و چون در شبکه خودشون این مسیر رو به عنوان بهترین مسیر(بهترین Metric)معرفی کردند(در ادامه درموردش توضیح دادم)، وقتی بصورت جهانی Advertise میشود، باعث میشود نسبت به مسیرهای دیگر اولویت داشته باشند... در پروتکل BGP، به این عمل BGP Hijacking میگویند.در نتیجه؟در نتیجه تمامی BGP Peerهای شرکت مخابرات(همسایه های بروی بستر BGP در کشورهای دیگه)، اشتباها بسته‌های مربوط به تلگرام را به ایران و این ISP تحویل میدهد و در ترافیک‌های خارج‌از ایران اختلال ایجاد میشود.حالا کار BGPStream در اینجا چیه؟خیلی ساده میشه گفت که این سایت، همسایه‌هایBGPرو(که بهشون BGP Peer گفته میشه) Monitor میکنه و موارد اینچنینی از قبیل Hijacking،Leaking و... رو متوجه میشه و اطلاع میده.چرا این اتفاق پیش‌اومده؟ آیا دولت اینکار را انجام داده‌است؟باید خدمتتون عرض کنم که به احتمال بسیار زیاد خیر! انجام عمدی اینکار بسیار احمقانه است و عواقبش بدتر از فوایداش است! ویا اینکه اگر واقعا مقصود فیلترینگ بوده‌است، اینکار باید روی همه ISPها انجام شود، نه صرفا یک ISP. شواهد بسیاری نشون‌دهنده‌ی این هستش که این مشکل سهوا و از روی اشتباه و عدم دانش‌فنی لازم پیش‌اومده که ناشی از عدم وجود یک سیستم استاندارد Change Management هستش. بدلیل درخواست دولت از ISPها برای فیلتر کردن تلگرام، این شرکت قصد اینکار رو داشته و برای اینکار تعدای مسیر غیرمعتبر ایجاد کرده(که از داخل ایران، بسته‌ها نتونن به مقصد برسن)... در انتها اشتباها اون مسیرهارو Advertise کرده‌اند و باعث ایجاد این مشکل شده‌اند.طبق خبری که دوستان اعلام کردن، ظاهرا وزیر ارتباطات در نشتی اعلام کردن که که Routeـی به Null 0 در روتر(برای فیلتر تلگرام)اعمال شده‌بوده(روتینگ پروتکل قبلی OSPF بوده - این RP برای شبکه های IGP(داخلی) استفاده میشود) و درهنگام تغییر Routing Protocol به BGP، کارشناس‌ها حواسشون نبوده و این Routeهارو بجای شبکه داخلی، به بیرون شبکه Redistribute کردن؛ یعنی بجای Redistribute به iBGP ، به eBGP توزیع کرده‌اند.(معنیش همون چیزی میشه که در پاراگراف قبلی مطرح کردم).عموما برای اینگونه Routeها که با این اهداف ایجاد میشوند،بصورت دستی بهترین Metricها سِت میشوند که این مسیرهای جعلی، نسبت به ترافیک‌های اصلی اولیت بیشتری داشته باشند.روش‌های دیگری هم برای اولیت دادن به مسیر وجود دارد، مثل خبر سالهای گذشته(در یک مورد مشابه در ایران) اینه که Routeـی که توسط ایران Advertise شده، Specificتر بوده است و خب در مباحث مربوط به Routing در شبکه، این‌هم یکی از دلایلی است که یک مسیر نسبت به یک مسیر اولویت بیشتری پیدا میکند.(برای درک این مورد باید یکم بیشتر با موارد روتینگ و سابنتینگ آشنا باشین که توضیحشون از حوصله این مطلب خارجه...اما بخوایم ساده توضیحش بدیم: فرض کنید که درداخل روتر ما، یک لیستی هستش که برای یک مقصد مسیرهای متفاوتی رو داره... هرمسیری که بیشتر جزئی بشه، اولویت بیشتری نسبت به مسیرهای کلی‌تر داره)مثلا ممکنه بگیم که برای رفتن به مقصد 192.168.0.0 باید از این مسیر A برین(فرض کنین 0 به این معنا هستش که ‌بجای 0، هر عدد دیگری بود فرقی نداره)؛ اما اگر میخواید به 192.168.1.0 برین، از مسیر B برین... خب چون Routeـه دوم جزئی‌تر هستش...وقتی بسته‌ای بخواد به مقصد شبکه مربوط به 196.168.1.0 بره، مسیر B انتخاب میشه.توی سناریو ماهم به همین صورت بوده و مسیری که تبلیغ‌شده دارای سابنت جزئی‌تری بوده(سابنت اصلی/17 بوده و سابنت تبلیغ‌شده /24 بوده)و در نتیجه نسبت به ترافیک‌های دیگه اولویت داشته.(کل منظور این قسمت این بود که لازم نیست همیشه Metricهارو تغییر بدیم. اینگونه موارد هم میتونه باعث اولویت دادن به مسیر بشه)سناریوی دیگرطبق توئیت زیر:احتمال میرود که رنج‌آیپی ای که توسط مخابرات Advertiseشده...رنج مربوط به CDNـه تلگرام در ایران بوده که از قبلا در سیستم وجود داشته و در روند تغییر توپولوژی، اشتباها دوباره Advertise شده(و چون دیگر CDNـی درایران که مربوط به تلگرام باشد وجود ندارد، احتمالا این بلوک IP، به یک Locationـه دیگر اختصاص داده شده است... در نتیجه Advertise کردنش توسط ایران، باعث اشتباه و BGP Hijacking میشود) حالا چی میشه؟همونطور که میشه تشخیص داد، این عمل یک جرم بین‌المللی هستش(چه سهوا چه عمدا) که مسلما جریمه‌های سنگینی درپی خواهد داشت و درصورت شکایت شرکت Telegram، ممکنه که این موضوع خیلی جدی‌تر پیگیری بشه. شایعه‌هایی هم شنیده میشه که ممکنه برای جریمه چند روزی اینترنت ایران قطع شه!(که البته درحد همون شایعه هستش...)توئیت آقای جهرمی درمورد این موضوعویرایش: گزارش رسمی این واقعه، 13ام مرداد در وبسایت " سازمان تنظیم مقررات و ارتباطات رادیویی " منتشر شد. خوشبختانه تقریبا حدس‌و گمان‌های ما درست بود و حالا میبایستی منتظر باشیم و ببینیم چه عواقبی در انتظار سازمان میباشد.ویرایش 2: در ادامه این مبحث مقاله‌ای درمورد "امنیت در BGP و جلوگیری از هایجک" در وبلاگ خودم نوشتم که اگر علاقه‌مند بودید خوشحال میشم مطالعه کنید.لینک مطلبامیدوارم که این مطلب براتون مفید واقع شده باشه / اگر سوالی براتون پیش اومد، حتما در کامنت‌ها بپرسید.همچنین این مطلب رو برای دوستان خودتون هم به اشتراک بذارید تا بیشتر متوجه این موضوع بشن.پایان سجاد غفاریان سجاد غفاریان Wed, 01 Aug 2018 03:47:48 +0430