118036

چرا استفاده از Policy as Code و OPA باعث موفقیت تیم‌های سازمانی می‌شود؟

استانداردهای باز می‌توانند محرک کلیدی برای اعمال یا حتی تعریف استراتژی‌های حاکمیت API سازمان‌ها باشند. Open Policy Agent (OPA) یکی از این استانداردها است که در ابتدا در Styra ایجاد شد و سپس به یک پروژهٔ CNCF تبدیل شد.

برای کمک به شرکت‌ها جهت درک و پیاده‌سازی OPA در مقیاس بزرگ، چارلی ایگان، توسعه‌دهنده ارشد در Styra، در کنفرانس حاکمیت API در Tyk LEAP 2.0 با حاضران صحبت کرد. ما در ادامه برخی از نکات کلیدی جلسه چارلی را جمع‌آوری کرده‌ایم، شامل:

  • منظور از policy as code چیست – و چرا بسیار مفید است

  • چگونه policy as code چالش‌های حاکمیت منحصر به فرد سازمان‌ها را حل می‌کند

  • چگونه از OPA همراه با API Gateway استفاده کنیم

  • چرا OPA برای سازمان‌هایی با سیستم‌های گسترده و الزامات سختگیرانه ممیزی بسیار مفید است

Policy as Code به چه معناست؟

درک ارزش OPA با درک سیاست‌ها آغاز می‌شود. سیاست‌ها قواعد پایه‌ای هستند، مانند اینکه تنها مدیران مجاز به انجام برخی اقدامات در یک سیستم باشند یا کنترل دسترسی میان تیم‌ها یا بخش‌های مختلف.

سیاست‌های دیگری نیز وجود دارند. برای مثال، در دنیای غرب، در اکثر هواپیماها ردیف شماره ۱۳ وجود ندارد – بنابراین این یک سیاست است که در سیستم‌های رزرو بلیت هواپیما اعمال می‌شود. یک کسب‌وکار خرده‌فروشی، در مقابل، ممکن است فروش برخی محصولات را به بازه‌های زمانی خاص محدود کند.

کسب‌وکارها بر پایهٔ سیاست‌ها ساخته شده‌اند. این موضوع فقط دربارهٔ اینکه چه کسی می‌تواند به کدام سیستم دسترسی داشته باشد نیست. سیاست‌ها در واقع کدگذاری کارهایی هستند که کسب‌وکار انجام می‌دهد.

Policy as Code چیست؟

در بخش قبل چند مثال سیاست‌ها را در قالب زبان طبیعی دیدیم. مثال دیگری:

«در حال حاضر، فقط اعضای تیم پشتیبانی که on-call هستند می‌توانند آخر هفته‌ها بدون نیاز به بازبینی، دیپلویمنت به محیط production را انجام دهند.»

Policy as Code یعنی بیان یک سیاست با استفاده از زبان سیاست‌گذاری به‌جای زبان طبیعی. بنابراین اگر از زبان Rego (زبان OPA) استفاده کنیم، همین سیاست به شکل کدی قابل‌تعریف درمی‌آید.

opa

مزایای Policy as Code چیست؟

بسیاری از ما با مفهوم زیرساخت به‌صورت کد (IaC) آشنا هستیم و می‌دانیم چه مزایایی دارد. Policy as Code نیز همان مزایا را در سطح سیاست‌ها ایجاد می‌کند، از جمله:

  • پیکربندی نسخه‌گذاری‌شده که می‌توان به عقب یا جلو برگرداند و قابلیت ممیزی و بازبینی کدی دارد. شما می‌توانید نسخه‌های مختلف یک سیاست را بسازید و مطمئن باشید که سیاست در یک زمان مشخص با نسخهٔ مشخص ارزیابی شده است.

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

  • مدیریت مرکزی سیاست‌ها: می‌توان سیاست‌های سازمانی را به‌صورت مشترک استفاده کرد اما کنترل و ممیزی آن را در سطح مرکزی نگه داشت. مشابه مدیریت زیرساخت یا پلتفرم‌های کلان، می‌توانید کنترل یک سیاست خاص را به یک تیم بسپارید اما همچنان کنترل مرکزی کل ساختار را حفظ کنید.

  • همکاری و تست: ابزارهای سطح بالا امکان تست سیاست‌ها و اطمینان از رعایت قوانین سازمان را فراهم می‌کنند.

Policy as Code در مقیاس سازمانی

وقتی موضوع به مقیاس سازمانی می‌رسد، سه چالش عمده به‌وجود می‌آید:

  • سیستم‌های چندزبانه (Polyglot)

  • الزامات سختگیرانهٔ ممیزی

  • پیچیدگی بهینه‌سازی

۱. سیستم‌های Polyglot

سازمان‌های بزرگ دارای سیستم‌های پراکنده هستند که توسط تیم‌های مختلف استفاده می‌شوند و گسترش آن به دلایل متعدد رخ می‌دهد. در مقیاس بالا، معمولاً تیم‌های مختلف با تخصص‌های متفاوت از بهترین ابزارها برای انجام کار استفاده می‌کنند. برای مثال، دانشمندان داده ممکن است از Python استفاده کنند، در حالی که درخواست‌های API با Go نوشته شده‌اند. هرچند این سیستم‌ها دارای اولویت‌ها و کاربردهای متفاوت هستند، اغلب همپوشانی‌هایی مانند داده‌های مشترک یا روش‌های مشابه احراز هویت کارکنان دارند.

واقعیت این است که این سیستم‌ها اغلب به‌صورت مستقل کار نمی‌کنند و این مسئله با جداافتادگی دپارتمان‌ها و خرید شرکت‌های دیگر تشدید می‌شود. همهٔ این‌ها باعث گسترش فناوری‌های مختلف و چالش‌های یکپارچه‌سازی می‌شود. تکامل طبیعی کسب‌وکار نیز پیچیدگی را افزایش می‌دهد. رسیدن به اندازه سازمانی زمان‌بر است، به این معنی که در زمان رسیدن به این مقیاس، با کدهای قدیمی، سیستم‌ها، دیتاسنترها و پلتفرم‌های مختلف، و همچنین زیرساخت‌ها و شبکه‌های متفاوت سروکار داریم.

۲. الزامات سختگیرانه ممیزی

سازمان‌های بزرگ معمولاً الزامات ممیزی و انطباق بسیار سختگیرانه‌ای دارند و اغلب با چارچوب‌های انطباق متعدد کار می‌کنند و در صورت عدم رعایت، با جریمه‌های سنگین و آسیب‌های اعتباری مواجه می‌شوند.

سازمان‌ها باید بدانند هر چارچوب انطباق برای هر تیم و هر اپلیکیشن چه معنایی دارد و باید به طور پیوسته انتظارات آن چارچوب‌ها را به شکل استاندارد برآورده کنند. این فراتر از دانستن این است که چه کسی چه زمانی به چه چیزی دسترسی داشته است؛ بلکه باید فهمید کدام سیاست دسترسی را اعطا کرده و داده‌ها چگونه ارزیابی شده‌اند.

این درک همچنین به تغییر سیاست‌ها گسترش می‌یابد؛ باید بدانید چه کسی نسخه‌های مختلف سیاست‌ها را ایجاد کرده، سیاست‌ها چگونه تغییر کرده‌اند و این تغییرات چه تأثیری بر دسترسی‌ها و داده‌ها داشته‌اند. داشتن یک مسیر ثبت (paper trail) برای همهٔ این موارد دشوار است، به‌ویژه در سیستم‌های پراکنده و گسترده.

۳. پیچیدگی بهینه‌سازی

عوامل زیر به پیچیدگی اشاره دارند:

  • نیاز به latency بسیار پایین

  • محدودیت‌های مالی و زیرساختی

  • مجموعه‌داده‌های بزرگ

  • کاربران و سرویس‌های جهانی و توزیع‌شده

این مسائل بهینه‌سازی تصمیم‌گیری‌های سیاستی را پیچیده می‌کند.

استفاده از OPA همراه با API Gateway

OPA ابزاری است که با محیط تیم‌ها سازگار می‌شود. این یک موتور سیاست‌گذاری متن‌باز و عمومی است که به شما امکان می‌دهد تصمیمات سیاستی را به آن واگذار کنید. می‌توانید منطق سیاست‌ها را که در اپلیکیشن‌ها یا سیستم‌ها مستقر است، جدا کرده و به یک مدل استاندارد ارزیابی سیاست منتقل کنید.

OPA جایگزین API Gateway نیست؛ بلکه ابزاری است که می‌توان آن را با API Gateway ادغام کرد تا قابلیت سیاست‌گذاری را به آن لایه اضافه کند. API Gateway نقطهٔ اعمال سیاست است، در حالی که OPA نقطهٔ تصمیم‌گیری سیاست است.

در مثال معمول، سرویس (می‌تواند API Gateway یا اپلیکیشن یک تیم باشد) یک درخواست به OPA ارسال می‌کند که شامل اطلاعاتی دربارهٔ تصمیم مورد نیاز است. OPA بر اساس سیاست‌ها و داده‌های بارگذاری‌شده تصمیم را برمی‌گرداند. این نحوهٔ کار هر ادغام سطح بالا با OPA است.

در همان زمان، OPA گزارش‌های ممیزی دربارهٔ تمام داده‌های عبوری، تمام تصمیمات گرفته‌شده، تمام تغییرات نسخه‌های سیاست و نسخه‌های سیاست استفاده‌شده برای تصمیمات خاص را ارسال می‌کند و همهٔ این‌ها را در بخش audit خود ثبت می‌کند.

چگونه OPA به سازمان‌هایی با سیستم‌های Polyglot کمک می‌کند

راه‌های مختلفی برای ادغام OPA وجود دارد: از طریق REST API، استفاده درون‌پردازه‌ای و ادغام با زبان‌ها و فریم‌ورک‌های دیگر. همچنین الگوهای متنوعی برای اجرای OPA وجود دارد: می‌توان آن را به عنوان sidecar، کنار API Gatewayها، درون‌پردازه، در همان container اپلیکیشن‌ها و حتی به‌صورت سرویس مرکزی اجرا کرد. این انعطاف‌پذیری برای سازمان‌هایی با سیستم‌های چندزبانه ایده‌آل است.

نمونه واقعی: Zalando، خرده‌فروش بزرگ مد در اروپا، دارای حدود ۳۰۰۰ اپلیکیشن است که بیش از ۲۰۰۰ مهندس آن‌ها را توسعه داده‌اند. قبل از استفاده از OPA، Zalando متوجه شد که از زبان‌ها و فریم‌ورک‌های متعدد استفاده می‌کند و دسترسی‌ها را به روش‌های متنوع پیکربندی می‌کرد.

این شرکت تصمیم گرفت احراز مجوز را با OPA به یک چارچوب استاندارد منتقل کند. با OPA، مجوزدهی به‌صورت استاندارد انجام می‌شد و کنترل مرکزی واگذار شد، در حالی که منطق سیاست مرتبط با دامنه یا اپلیکیشن می‌توانست به تیم‌ها واگذار شود. Zalando همچنین از قرار دادن OPA در instanceهای API Gateway بهره برده است، که باعث می‌شود تصمیمات سیاستی با latency بسیار کم ارائه شود. این کار همچنین به کاهش هزینه‌های ویژگی پلتفرم کمک کرده است.

چگونه OPA در ممیزی کمک می‌کند

Policy as Code می‌تواند نسخه‌گذاری، تست و انتشار کنترل‌شده داشته باشد. علاوه بر این، لاگ‌های درخواست OPA شامل داده‌های ورودی و خروجی، اطلاعات نسخه سیاست، اطلاعات نسخه داده و موارد دیگر است. این لاگ‌ها تصویر کاملی از چرایی هر تصمیم در هزاران اپلیکیشن ارائه می‌دهند.

نمونه واقعی: Capital One از چارچوب مدیریت OPA برای ثبت لاگ‌های دقیق و سوابق انطباق استفاده می‌کند، هم برای تغییرات سیاست‌ها و هم برای تصمیمات گرفته‌شده. استانداردسازی بخش مهمی از دلیل ادغام OPA بود، به‌عنوان بخشی از تلاش گسترده‌تر برای یکپارچه‌سازی ابزارها در حالی که الزامات ممیزی مختلف رعایت می‌شود. این شرکت همچنین از OPA برای کنترل مرکزی سیاست‌ها همراه با تفویض و بازبینی همتا استفاده می‌کند. جالب است بدانید، این شرکت از OPA نه تنها برای انطباق، بلکه برای اهداف عملیاتی نیز استفاده می‌کند، مانند نظارت بر تولید داده‌های ممیزی.

چگونه OPA به بهینه‌سازی کمک می‌کند

OPA برای تأخیر بسیار پایین و نیازهای سختگیرانه حافظه مناسب است.

Miro

Miro برای سیستم بلادرنگ خود به تأخیر بسیار پایین نیاز داشت و با اجرای OPA درون‌فرایندی توانست تصمیم‌های احراز مجوز را در حد چند میلی‌ثانیه ارائه دهد.

Gusto

Gusto از OPA برای بهینه‌سازی عملکرد پرس‌وجوها با اجرای دسته‌ای (batch) استفاده می‌کند تا چندین پرس‌وجو را در قالب یک درخواست اجرا کند، بدون از دست دادن ثبت کامل تصمیم‌ها.

رازهای موفقیت در GraphQL چه هستند؟
چرا کدهای پاسخ ۲۰۰ همیشه به معنی «همه‌چیز خوب است» نیستند؟

دیدگاهتان را بنویسید

سبد خرید
علاقه‌مندی‌ها
مشاهدات اخیر
دسته بندی ها