سازمان دهی اَپی

این نوشته بخش پنجم (مشاهده بخش چهارم) از یک مجموعه هشت قسمتی و در مورد پروژه میکرومشاوره‌ای تحت عنوان «سازمان دهی اَپی و مدل‌های سیاست‌گذاری در بخش‌های عمومی و خصوصی» توسط «دپارتمان امور سربازان بازنشسته» نگاشته شده است.

این پروژه به دنبال بررسی اجمالی در مورد سیاست گذاری API و جهت کمک به “درک، برای تبیین بهترین راهکار‌های عملی بخش‌های عمومی و خصوصی، و بطور خاص جهت اولویت بندی به ساخت API ها، و استانداردهایی برای اینکه کدام APIها ساخته شوند، و از طرفی در دسترس قرار دادن APIها جهت استفاده کاربر نهایی خارج از سازمان” تولید شده است.

 

سازمان دهی اَپی

در این مقاله، سالیان متمادی تحقیقات انجام شده توسط آنالیز صنعتی API Evangelist ، در کنار مصاحبه‌های تلفنی انجام شده و توسط Skylight Digital با متخصصین حوزه API سازمان‌ها و موسسات بزرگی که سازمان دهی اَپی را در بخش‌های عمومی و خصوصی بر عهده دارند، گردآوری شده است.

 

 

 

 

مدل‌های سیاست‌گذاری برای APIها در بخش های خصوصی و عمومی (بخش پنجم)

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

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

در انتها این مقاله را با جمع بندی جزئیات سیاست‌گذاری رسمی APIها، و همچنین اقرار به اینکه درحال حاضر بیشتر سیاست‌های سازمان دهی اَپی و ساخت اَپی‌ها (API) اغلب از ابتدا به درستی طرح ریزی نشده اند، به پایان خواهیم برد.

این جمع بندی شامل شرح کامل نحوه سیاست‌گذاری های اَپی‌ (API) به همراه لیستی از عناصری که می‌توانند به سیاست‌گذاری API در شرکت های بزرگ کمک کنند، خواهد بود.

 

 

از توسعه تا تولید

پس از درک نقش‌های لازم برای شناخت سیاست‌گذاری، همینطور بستر اساسی معماری مورد نیاز، چگونگی شناخت موقعیت‌های موجود برای APIها، و حصول اطمینان از پیروی تیم‌ها از استانداردها، به طور ساخت‌یافته تری به بررسی موشکافانه این موضوع می‌پردازیم که تیم‌ها چگونه از مرحله توسعه به مرحله تولید می‌روند.

اینکه تیم‌ها چگونه در مقیاس‌های بزرگ بصورت موثری اَپی‌ها (API) را از یک ایده و طرح به سرویس‌های قابل عرضه در محیط تولید می‌رسانند.

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

 

تعریف صحیح

شرط اصلی برای اینکه تیم‌ها قادر باشند بطور متداوم به تولید اَپی‌ها (API) در مقیاس‌های مختلف ادامه دهند، آن است که چرخه حیات توسط تیم‌های ارشد، بخوبی تعریف، تکمیل و تصحیح شده باشد.

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

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

 

• قرارداد – الزام شروع همه سرویس‌ها بر اساس قرارداد OpenAPI قابل خواندن توسط ماشین که بطور کامل به همه جوانب عملکرد API و طرح آن پرداخته باشد. این قرارداد سنگ محکی برای درستی و صحت سرویس بوده، و تطابق کارکرد سرویس با سیاست‌های تنظیم شده توسط این قرارداد سنجیده خواهد شد.

 

• فرایند – فراهم سازی تعریف مناسب فرایندی برای همه توسعه دهندگان، بطوریکه در آن بطور واضح مشخص شده باشد هر سرویس چگونه و طی چه گام‌هایی به مرحله تولید خواهد رسید، تا به توسعه دهندگان متوجه مسائلی که در طی تولید سرویس‎‌ها با آن مواجه هستند، باشند.

 

• Scorecard – داشتن چک لیست و scorecard قابل خواندن توسط ماشین، که به هر توسعه دهنده کمک کند نمونه جداگانه‌ای برای کارهای در حال انجامشان در اختیار بگیرند.
• فراهم ساختن چک لیستی از هر چیزی که توسط توسعه دهنده‌ها باید مدنظر قرار داده شود، که آنها را قادر به بررسی کارهایی انجام شده، و کارهای باقی مانده‌ سازد. و همینطور تعریفی فراهم کند که بتوان گزارشاتی مطابق با سیاست‌های تعریف شده تهیه کرد.

 

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

 

• بازبینی – الزام همه سرویس‌ها به طی کردن مجموعه ای از چرخه‌های حیات جهت بازبینی توسط تیم‌های دیگر، اجبار صاحبان سرویس‌ها به ارائه کارشان به همه تیم‌های بازبینی و کار کردن در کنار آنها جهت برطرف ساختن همه نگرانی های احتمالی و حصول اطمینان از تطابق آنها با تمامی جوانب سیاست‌ها.

 

• جلسات بهبود – فراهم ساختن جلسات مختلفی که طی آن همه توسعه دهندگان در مورد کارشان بازخورد دریافت کنند، سرویس‌هایشان را بهبود دهند، و سلامت هر کار را پیش از ارسال جهت قرار گرفتن در محیط تولید بهبود بخشند.

 

شرکت های ارائه دهنده ساختارها برای تیم های سازمان دهی اَپی و توسعه دهنده اَپی‌ (API)، بسیار ساده تر از خود تیم‌ها قادر به شناسایی سرمنشا سیاست‌گذاری‌ها خواهند بود.

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

داشتن یک چرخه حیات خوب تعریف شده برای توسعه API، تاثیر بسزایی در تبیین هر چه بهتر سیاست‌ها خواهد داشت.

 

 

 

 

 

مجازی سازی

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

 

• ماکت – ایجاد ماکتی برای تمام endpointهای API ها، مجازی سازی تمامی جنبه های یک API، و تست عملکرد یک API در اولین مرحله های چرخه حیات آن.

 

• داده ها – الزام برای ایجاد داده های طراحی شده و مجازی سازی شده برای ارائه به تمامی ماکت‌های اَپی‌ها (API)، بطوری که پاسخ‌های واقع‌گرایانه‌ای جهت تشخیص رفتار API در مرحله تولید مشخص شود.

 

• Sandbox – فراهم آوردن محیط کاملاً آزمایشگاهی جهت انتشار APIها در آن توسط توسعه دهندگان. بدین صورت مشخص خواهد شد که در مرحله تولید با چه مسائلی مواجه خواهند بود، ولی در محیطی مطمئن و امن تر.

 

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

این موضوع باعث حصول اطمینان تیم از آمادگی سرویس برای پیاده سازی خواهد شد و ایرادهای کار در مقایسه با قرارداد اولیه وجود دارد را برطرف خواهد کرد.

 

 

فناوری

متوجه شدیم یکی از مهمترین عواملی که تیم‌ها به توجه به آن، سیاست‌گذاری APIهایشان را تنظیم می‌کنند، فناوری های بکار رفته توسط آنهاست.

فناوری، بسیاری از ساختارها و چارچوب‌هایی که سازمان‌ها طبق آن‌ها اَپی‌ها را توسعه داده و درنهایت پیاده سازی می‌کنند را مشخص کرده، و برای برخی سازمان‌های که استراتژی خود را طبق سیاست‌گذاری‌های مشخص بطور رسمی پیاده نکرده اند، بیشتر این سیاست‌ها را تبیین می‌کند.

 

• احراز هویت – استفاده از راهکارهای استاندار احراز هویت مانند Basic Auth، API Key، OAuth و JWT . حصول اطمینان از اینکه تیم ها می‌دانند از هر پروتوکل در چه زمانی استفاده کنند، آنها را چطور پیکربندی کرده و به عنوان بخشی استراتژی سیاست‌گذاری API خود استفاده کنند.

 

• فریم ورک – تکیه بر استفاده از فریم ورک های برنامه نویسی و تزریق نظم به فرایند، و سیاست‌گذاری برای اینکه APIها چگونه ساخته خواهند شد، پیش از اینکه APIها به مرحله تولید برسند.

 

• Gateway – اعمال مقررات و ساختارهای لازم به سیاست‌گذاری سرویس‌ها در طی در دسترس قرار گرفتن آنها برای محیط تولید. بسیار از گروه‌ها از sandbox یا نسخه ویژه توسعه دهندگان gateway استفاده می‌کنند که حاوی بسیاری از عناصر بکار رفته در نسخه نهایی خواهد بود.

 

• مدیریت – مشابه gateway، تیم ها برای مشخص کردن اینکه API شان چه عملی انجام خواهد داد، بر لایه مدیریت API تکیه می‌کنند، که تحولات، قالب‌های خط مشی، و گونه‌های مختلف دیگری از استانداردسازی صورت گرفته پیش از تولید API را فراهم می‌سازد.

 

• Vendor – تکیه بر فناوری برای ایجاد سیاست‌گذاری در مرحله پیاده‌سازی API ، ابزار مناسبی جهت کنترل چرخه حیات برای vendorها فراهم می‌آورد. چنانچه یک vendor راهکارهای بخصوصی برای انجام هر یک از هر امور فراهم نیاورد، ممکن است جایی در میان تیم های توسعه دهنده پیدا نکند. برای بسیاری از شرکت‌ها، سیاست‌گذاری بدین معنی پیدا می‌کند.

 

• شکل‌دهی – بیشتر تیم‌ها مجموعه‌ای از ابزار متن باز و شخصی سازی شده برای پیشبرد از توسعه به تولید، تایید اعتبار، مرور، تغییر حالت، شکل دادن و استحکام کد ها و رابط ها برای آماده سازی جهت استفاده در تولید دارند.

 

• رمزگذاری – الزام استفاده از رمزگذاری بطور پیش‌فرض برای ذخیره سازی و در هنگام انتقال اطلاعات، با استفاده از فناوری مناسب به منظور حصول اطمینان از امنیت، به عنوان یک پارامتر پیش‌فرض برای هر چیزی که در معرض عموم قرار خواهد گرفت. بدین وسیله احتمال ایجاد رخنه کاهش یافته و خسارت ایجاد شده در صورت بروز رخنه احتمالی را به حداقل خواهد رساند.

 

مدل سازمان دهی اَپی

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

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

 

 

 

 

 

ارکستراسیون (هماهنگ سازی)

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

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

 

• خط لوله – سرویس‌ها، ابزار و تفکرات مبتنی بر CI/CD ، باعث ایجاد روند خط لوله برای بسیاری از تیم‌ها شده اند، که بصورت استانداردی برای فرایند تولید APIها به عنوان خط لوله ای قابل اجرا، قابل تکرار، قابل اندازه گیری و قابل تشخیص برای هر تیمی، در آمده است.

 

• مراحل – معین کردن مرحله‌های مشخصی که پس از توسعه، و در عین حال پیش از تولید وجود دارند، و مستلزم تضمین کیفیت، بررسی‌های امنیتی، حسابرسی رعایت و دیگر سیاست‌ها برای راهکارهایی که مشخص شوند، خواهد بود.

 

• Hookها – اعمال hookهای خوب تعریف شده قبل و بعد از commit کردن سرویس‌ها به repository در طول خط لوله سرویس‌ها، و با رعایت سیاست‌گذاری، به عنوان پیش‌فرضی برای تمامی سرویس‌ها، فارغ از اینکه مربوط به کدام سازمان باشند.

 

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

 

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

 

ارکستراسیون باعث روشن شدن امور در روند تبدیل خدمات از توسعه به تولید شده، و در عین حال باعث اطمینان از اجرای سیاست‌گذاری نیز می‌شود.

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

 

 

دپارتمان حقوقی

علاوه بر فناوری، دپارتمان حقوقی نیز باید نقش بزرگی در رفتن از مرحله توسعه به مرحله تولید داشته باشد، و با استفاده از تعداد معدودی سنگ بنای مشخص، و به منظور تنظیم صحیح سیاست‌گذاری ساخت APIها از نظر حقوقی، چارچوب ساخت یافته ای ارائه دهد که در عین اینکه بسادگی قابلیت اعمال بر تمامی سرویس را داشته باشد، در عین حال قابلیت تنظیم دقیق مدارک حقوقی برای هر سرویس بصورت جداگانه را دارا باشد.

 

• شرایط استفاده از خدمات – این شرایط باید توسط یک واحد مرکزی و در رابطه با تمامی خدمات، طوری تنظیم شوند که مناسب کل مجموعه، ماژولار و همچنین قابل خواندن توسط ماشین و انسان باشند.

 

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

 

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

 

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

 

• تفاهم نامه سطح کیفی خدمات – این تفاهم نامه باید برای تمامی سرویس‌ها، و طوری تنظیم شود که مناسب کل مجموعه، ماژولار و همچنین قابل خواندن توسط ماشین و انسان بوده، و قابلیت سنجش و تهیه گزارش به عنوان بخش بزرگتری از استراتژی سیاست‌گذاری را دارا باشد.

 

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

 

 

 

 

 

 

دپارتمان حقوقی نقش مهمی در سازمان دهی اَپی و سیاست‌گذاری API و پیشبرد آنها از مرحله توسعه به تولید، بازی خواهد کرد، و به همین خاطر به راهنمای واضحی نیاز خواهیم داشت که همه توسعه دهندگان از تمامی موارد مورد نیاز آگاه باشند.

مشابه عناصر فنی و حرفه‌ای تولید سرویس‌ها، عناصر حقوقی نیز باید قابلیت دسترسی، درک و اجرای آسان را داشته، و در عین حال منافع همه کسانی که در روند تولید و کارکرد سرویس‌های تجاری نقش دارند، را تضمین نماید.