۱۲ اصل برای بهبود devsecops

سازمان‌های SaaS وقتی پای قابلیت اطمینان برنامه‌ها، مقیاس‌پذیری، امنیت و رضایت مشتری به میان می‌آیند، پیشرو هستند. در اینجا ۱۲ اصل وجود دارد که رهبران devsecops می توانند از SaaS اتخاذ کنند.

• ۱. یک ذهنیت مشتری اول را اتخاذ کنید
• ۲. کنترل نسخه را به داستان های کاربر چابک متصل کنید
• ۳. ویژگی های جدید را در گروه های آلفا منتشر کنید
• ۴. نیاز به امنیت بر اساس طراحی
• ۵. تشخیص واحد آزمایش کافی نیست
• ۶. تست های خودکار از کارشناسان موضوع
• ۷. کد را برای امنیت و کیفیت اعتبارسنجی کنید
• ۸. الزامات عملیاتی غیرکاربردی را ایجاد کنید
• ۹. کانال‌های SLO و اولویت‌های هشدار را به‌طور معنادار انجام دهید
• ۱۰. قابلیت مشاهده و پایش خطوط لوله داده

را اجرا کنید

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

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

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

Raghav Gurumani، مدیر ارشد فناوری شرکت SaaS می‌گوید: «CTO ارزش محصولی را درک می‌کند که نه تنها از نظر عملکردی قوی است، بلکه دائماً در دسترس، سریع و غیرقابل نفوذ در برابر تهدیدات امنیتی است. www.zuper.co/” rel=”nofollow”>Zuper. مدیران ارشد فناوری می‌توانند با تأکید بر اهمیت ایجاد تعادل بین این سه و استفاده از رویکردهای تکراری، به تیم‌های سازمانی آموزش دهند که به این مثلث آهنین اطمینان، عملکرد و امنیت دست یابند.»

در این مقاله، ۱۲ اصل توصیه شده توسط رهبران فناوری SaaS را به اشتراک می‌گذارم که رهبران فناوری اطلاعات کسب و کار می‌توانند آن‌ها را در برنامه‌نویس‌ها اعمال کنند. من این اصول را در سه حوزه گروه بندی کرده ام:

• روش‌های عملیاتی به سمت چپ را به سمت نیازمندی‌ها و توسعه سوق دهید، با اتخاذ ذهنیت مشتری اول.
• بدانید که تیم‌های devsecops باید بیشتر اتوماسیون تست را فراتر از تست واحد انجام دهند تا از قابلیت اطمینان و عملکرد برنامه اطمینان حاصل کنند، به‌ویژه با استفاده زیاد و انواع مختلف کاربران.
• با تعریف اهداف سطح خدمات (SLOs) و استفاده از ابزارهای قابل مشاهده، نظارت و اتوماسیون ابری، به عملکرد و قابلیت اطمینان بالاتری دست یابید.

۱. یک ذهنیت مشتری اول را اتخاذ کنید

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

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

توصیه: تیم‌های Devsecops باید جلسات منظمی را با کاربران نهایی برنامه‌ریزی کنند تا نحوه استفاده آنها از برنامه‌ها را مشاهده کنند و به راه‌هایی برای بهبود عملکرد برنامه گوش دهند.

۲. کنترل نسخه را به داستان های کاربر چابک

متصل کنید

در حالی که اکثر شرکت‌ها کنترل نسخه را اتخاذ کرده‌اند، دیوید بروکس، معاون تبشیری در Copado، می‌گوید توسعه‌دهندگان تمایل دارند تمرکز کنند. بیش از حد در مدیریت شعبه در مخزن آنها. “توسعه مدرن مبتنی بر چابک است و بسیاری از ابزارهای توسعه دهنده تغییرات را مستقیماً بر اساس داستان های کاربر مدیریت می کنند.”

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

توصیه: علاوه بر اتصال جریان‌های کاری بین ابزارهای چابک و کنترل نسخه، تیم‌های devsecops باید استانداردسازی خط‌های لوله CI/CD را با پرچم‌های ویژگی در نظر بگیرند. و از استراتژی‌های آزادسازی قناری استفاده کنید.

۳. ویژگی های جدید را در گروه های آلفا

منتشر کنید

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

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

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

۴. نیاز به امنیت بر اساس طراحی

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

Steve Touw، CTO در Immuta، می‌گوید: “با اجرای امنیت با طراحی و اعمال امنیت در همان ابتدا ممکن است در توسعه محصول خودمان، متوجه شدیم که نگهداری و مدیریت پشتیبان ما از دیدگاه مدیریت آسیب‌پذیری به طور قابل توجهی کاهش یافته است.»

توصیه: CIOها، CISOها، و مدیران تحویل باید به وضوح الزامات غیرقابل مذاکره در مورد اقدامات امنیتی، آزمایش‌ها و معیارهای مورد نیاز هنگام خودکارسازی مسیرهای تولید را تعریف کنند.

۵. تشخیص واحد تست کافی نیست

می‌توانید فشار تایر را بررسی کنید، سطح روغن را بررسی کنید و ده‌ها آزمایش دیگر را روی موتور خودروی خود انجام دهید. اما آیا خودرو انتظارات شما را در برخورد با پیچ ها، دست اندازها و سایر شرایط جاده برآورده می کند؟

این را می‌توان برای برنامه‌های نرم‌افزاری نیز گفت، و در حالی که تست‌های واحد به تأیید مؤلفه‌ها و رابط‌ها کمک می‌کنند، برای تأیید عملکرد انتها به انتها یا تجربه کاربر کافی نیستند.

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

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

۶. تست های خودکار از کارشناسان موضوع

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

Brooks of Copado می‌گوید: «توسعه‌دهنده‌ها نگران ارائه کدی هستند که طبق درخواست کار می‌کند، اما برای اطمینان از نرم‌افزار قوی که با تمام تغییرات پیکربندی مشتری کار می‌کند، کارشناسان موضوع (SMEs) باید آزمایش‌هایی را ایجاد کنند که نشان دهد کاربران چگونه از ویژگی‌ها در دنیای واقعی. بهترین راه این است که SMEها با استفاده از ابزاری برای ثبت مراحل و سپس ایجاد آزمایشات خودکار، آزمایش اکتشافی انجام دهند.»

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

۷. اعتبار کد برای امنیت و کیفیت

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

McKee از Sonar می‌گوید: «برای تقویت تلاش‌های QA، توسعه‌دهندگان باید تجزیه و تحلیل کد استاتیک را در گردش کار خود ادغام کنند. “تحلیل استاتیک خودکار ساختار داخلی یک برنامه را بررسی می کند و با کشف مسائل اضافی، تست واحد را تکمیل می کند. با ترکیب هر دو، توسعه دهندگان می توانند به طور فعال کیفیت کد را در طول چرخه عمر توسعه مدیریت کنند، به سرعت باگ ها را شناسایی و برطرف کنند، و قابلیت اطمینان و امنیت کلی نرم افزار را افزایش دهند.”

توصیه: کاهش بدهی فنی یک مسئله اصلی برای شرکت‌ها است، بنابراین یافتن ابزارهایی که مسائل امنیتی و کیفیت کد را اسکن می‌کنند و ادغام مراحل در CI/CD باید یک نیاز غیرقابل مذاکره باشد.< /p>

۸. الزامات عملیاتی غیر کاربردی

را ایجاد کنید

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

دیوید کافی، معاون مدیریت محصول در شبکه‌های نرم‌افزاری و مدیر ارشد محصول NS1 در IBM. “همه چیز در یک پشته فناوری برای یک سرویس ابری مهم است، و نادیده گرفتن جزئیاتی مانند اینکه کدام سرویس DNS یا اتصال شبکه می‌تواند تاثیر نامطلوبی بر در دسترس بودن و مقیاس یک سرویس ابری بگذارد.”

توصیه: معماران، کارشناسان عملیاتی و امنیتی باید استانداردهایی را در مورد الزامات غیرعملکردی و معیارهای پذیرش پیش‌نویسی کنند که تیم‌های توسعه چابک از داستان‌های کاربری خود به آنها اشاره می‌کنند.

۹. کانال‌های SLO و اولویت‌های هشدار را به‌طور معنی‌داری انجام دهید

یک روش منسوخ برای تعیین انتظارات در مورد عملکرد برنامه، بیان قراردادهای سطح خدمات هدف (SLA) حول یک معیار عملیاتی، مانند ۹۹.۹٪ زمان کار است. یک رویکرد مدرن، تعریف SLOها و بودجه‌های خطا است که تعیین می‌کنند تیم‌های توسعه‌دهنده چه زمانی باید بهبودهای عملیاتی را اولویت‌بندی کنند.

آصاف ییگال، یکی از بنیانگذاران، می‌گوید: «اگر مهندسان اصلاح عملکرد را بدون چشم‌انداز وسیعی انجام دهند که SLOها مهم هستند – آنهایی که با سود رضایت کاربر مرتبط هستند – در این صورت ما هر موفقیتی را که می‌توانیم از یک پلت فرم مشاهده انتظار داشته باشیم محدود می‌کنیم. و معاون محصول در Logz.io. “CTOها نه تنها مسئولیت دارند که نتایج معنی‌داری را از تیم مهندسی به دست آورند، بلکه با تعیین اولویت‌های هشداری که به وضوح نقش حیاتی آنها در موفقیت کسب‌وکار بازی می‌کنند، استرس را برای مهندسان کاهش می‌دهند.”

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

۱۰. قابلیت مشاهده و پایش خطوط لوله داده

را اجرا کنید

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

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

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

۱۱. کنترل‌های مدیریت و دسترسی خارجی را قفل کنید

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

ایگور جابلوکوف، بنیانگذار و مدیر عامل Pryon.

Jablokov همچنین اصول اساسی دیگری از جمله اجرای احراز هویت چندعاملی و قفل کردن دسترسی خارجی غیر ضروری را توصیه می‌کند.

توصیه: متخصصان امنیت اطلاعات باید آخرین آسیب‌پذیری‌ها را بررسی کنند، مانند OWASP Top 10 و SANS 25 خطرناک ترین خطاهای نرم افزار. از اینها می توان برای ارائه چک لیست های امنیتی، آموزش و پشتیبانی به تیم های devsecops استفاده کرد.

۱۲. محیط های آماده به کار داغ

را پیکربندی کنید

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

Jablokov از Pryon می‌افزاید، “برنامه خود را در حالت آماده به کار در یک فروشنده ابری دیگر اجرا کنید، زیرا مهم نیست که چقدر افزونگی و خرابی در hyperscalerها تعبیه شده است، آنها به خودی خود در برابر خطاها غیرقابل نفوذ نیستند.”

>

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

موازنه کلیدی است

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