در قسمت اول مقاله در مورد شرح کلی مفهوم DevOps و سه اصل مبنایی آن صحبت کردیم و بیان نمودیم که فرهنگ DevOps برمبنای تیم‌های چندرشته‌ای بنا شده است که به‌طور مداوم ویژگی‌ها و خدمات جدید را می‌سازند و پیاده‌سازی می‌کنند. در DevOps، توسعه‌دهندگان مسئول حفظ کدی که می‌نویسند هستند، به این معنی که حوادث را به‌طور کارآمدتری حل می‌کنند. در این قسمت در مورد معماری آن صحبت خواهیم نمود.
معماری DevOps چیست؟
معماری DevOps عموماً به زیرساختی اشاره دارد که اهداف فرهنگ DevOps را ساده‌سازی می‌کند؛ یک معماری واحد برای DevOps وجود ندارد و سازمان‌های IT لزوماً نیازی به این ندارند که برای فعال‌سازی آن معماری‌های کنونی خود را کنار بگذارند. اما در سازمان‌های DevOps اصول هسته‌ای یا بهترین راهکارهایی حول معماری وجود دارد.
رشد DevOps با رشد پلتفرم‌های کلود همزمان شده است و تکنولوژی‌های کلود و دیگر تکنولوژی‌های مجازی‌سازی تأثیر قابل‌توجهی روی موفقیت DevOps دارند. تکنولوژی‌های متداولی که در زیرلایه سازمان‌های DevOps وجود دارند یا آن را تسهیل می‌کنند شامل پلتفرم‌های کلود، مجازی‌سازی و میکروسرویس‌ها می‌باشند.
- کلود: پلتفرم‌های Cloud به IT این امکان را می‌دهند که منابعی را در محیط‌های مجازی به جای On-Premises منتشر کنند. این پلتفرم‌ها به کاربران این امکان را می‌دهند که به‌سرعت و با انعطاف بسیار بالا به منابع دسترسی پیدا کنند.
- مجازی‌سازی قبل از مجازی‌سازی: سرور یک قطعه سخت‌افزاری واقعی بود و اگر به سرور ثانویه‌ای نیاز داشتیم، باید آن را خریداری می‌کردیم. مجازی‌سازی امکان ایجاد سرورهای مجازی یا دسکتاپ‌ها و غیره را فراهم می‌کند تا به‌جای آماده‌سازی یک سخت‌افزار جدید، تیم‌های نرم‌افزاری بتوانند محیط‌هایی مجازی را روی سرورهای کلود یا On-Premises بسازند. این امر برای تیم‌هایی که با سرعت چابکی کار می‌کنند Bottleneck قابل‌توجهی را از بین می‌برد و آماده‌سازی خودکار سرعت را تا جایی بالا می‌برد که توسعه‌دهندگان بتوانند به منابع موردنیاز خود در چند دقیقه دست پیدا کنند.
بیشتر بخوانید: منظور از NetDevOps چیست؟ چه مزایایی دارد و پیاده‌سازی آن چگونه صورت می گیرد؟
- میکروسرویس‌ها: معماری یک میکروسرویس از واحدهایی تشکیل شده است که آزادانه به هم متصل شده‌اند و دارای عملکردهای محدودی هستند و برای تشکیل یک سیستم کامل کنار هم قرار می‌گیرند. وقتی سیستم‌ها یا برنامه‌های کاربردی بزرگ‌تر از این ماژول‌ها با عملکردی واحد تشکیل شده باشند، ساخت و اصلاح آن‌ها ساده‌تر می‌گردد. این رویکرد متشکل از اجزای مستقل به تیم‌های DevOps مجزا این امکان را می‌دهد که با وابستگی‌های کمتر بروزرسانی‌هایی را پیاده‌سازی کنند و این یعنی می‌توانند با ریسک کمترِ ایجاد اختلال حرکت کنند.
معماری برای یک سازمان DevOps مجازی‌سازی، کلود و میکروسرویس‌ها را مورد استفاده قرار می‌دهد. همچنین تلاش می‌کند خودکارسازی تست، مانیتورینگ و اقدامات امنیتی را بهینه‌سازی کند تا جریان‌های کاری DevOps را فعال نماید. به‌طور کالی، خودکارسازی در DevOps یکی از عوامل کلیدی محسوب می‌شود و همان‌طور که تمایل به Cloud وجود دارد، تمایل به خودکارسازی نیز وجود دارد. این تمایلات یا بهترین راهکارها معماری سازمان‌ها DevOps را شکل خواهند داد.
نقش کلود در DevOps
رایانش کلود یکی از عوامل اصلی در فرهنگ مفهوم DevOps است، سرعت، مقیاس و کارآمدی کلود به تیم‌های چابک و DevOps این امکان را می‌دهد که سرعت و کیفیت کار خود را افزایش دهند. ابزار یا همان Software as a Service هم کارآمدی و هم اقتصادی بودن را برای تیم‌های نرم‌افزاری به ارمغان آورنده‌اند و نرم‌افزار SaaS خودش مثالی از یک محصول دائماً تکرارشونده است که نیازمند یک رویکرد DevOps است.
بااینکه شاید همه‌ی برنامه‌های کاربردی را در کلود قرار ندهیم، یک اقدام DevOps خوب این است که برای تمام برنامه‌های کاربردی اول‌ازهمه به کلود فکر کنیم. سؤالی که باید در هنگام برنامه‌ریزی برای یک برنامه کاربردی یا سرویس جدید پرسیده شود این نیست که: «آیا باید آن را در Cloud قرار دهیم؟ بلکه این است: آیا دلیلی دارد که آن را در کلود قرار ندهیم؟ گاهی اوقات در رابطه با نیازهای امنیتی و قانونی یا بر اساس زیرساخت کلی شما، چنین دلایلی وجود خواهد داشت اما کلود همیشه باید برای یک سازمان DevOps پیش‌فرض باشد.
DevSecOps چیست؟
DevSecOps اقدامات امنیتی را در فرایند DevOps یکپارچه‌سازی می‌کند و باعث می‌شود که همه‌ی افراد در رابطه با امنیت مسئولیت‌پذیر باشند، نه اینکه صرفاً در انتهای یک فرایند کد را به تیم امنیتی دیگری ارائه دهند. هدف از DevSecOps این است که نرم‌افزارهای ایمن را سریع‌تر و با نقص‌ها و دوباره‌کاری‌های کمتری ارائه دهد.
بیشتر بخوانید: منظور از NetDevOps چیست؟ چه مزایایی دارد و پیاده‌سازی آن چگونه صورت می گیرد؟
در کل، سه اصل بنیادی DevSecOps عبارت‌اند از:
- معرفی تفکر امنیتی در آغاز فرایند توسعه.
- معرفی تفکر امنیتی به‌عنوان یک مسئولیت هسته‌ای در توسعه، نه نگرانی یک تیم جداگانه.
- خودکارسازی فرایندهای امنیتی برای حذف جریان کارآمد DevOps.
بهترین راهکارهای DevOps
بهترین راهکارهای DevOps روی فرهنگ تمرکز دارند و رویکردی را توصیف می‌کنند که مبتنی بر همکاری، منعطف و متمرکز بر کارآمدی، چابکی و ارائه‌ی ارزش نهایی است. اما هیچ مجموعه قانون یا بهترین راهکاری وجود ندارد که این فلسفه‌ی کلی را عملی کند. بهترین راهکارها و ارزش DevOps در هر صنعت متفاوت خواهد بود، زیرا نیازهای یک توسعه‌دهنده‌ی نرم‌افزار با نیازهای افرادی که در خرده‌فروشی، تولید، بخش سلامت، خدمات مالی و غیره هستند متفاوت است.
دیمن ادواردز و جان ویلیس که از اولین حامیان DevOps بودند، سرواژه‌ای به نام CAMS را معرفی کردند که اصول کلیدی توسعه را بیان می‌کرد. این سرواژه مخفف واژه‌های فرهنگ، خودکارسازی، اندازه‌گیری و اشتراک است.
- اقدام متمرکز بر کاربر: حلقه‌های بازخورد کوتاه برای درک و بهره‌برداری از دیدگاه کاربران.
- ساختن با توجه به هدف: این امر باعث می‌شود سازمان‌ها کمتر به نقش تعریف‌شده‌ی هر فرد فکر کنند و بیشتر به این فکر کنند که سازمان به‌طورکلی چطور محصولات IT را برای کاربران داخلی و خارجی می‌سازد.
- مسئولیت به‌صورت End-to-end: به جای اینکه هر عضو از تیم فقط مسئول نقش خودش باشد و این‌گونه توسعه‌دهندگان هیچ مسئولیتی در خرابی زیرساخت و تیم‌های عملیاتی هیچ مسئولیتی برای کد اشتباه نداشته باشند، DevOps سعی می‌کند این Siloها را از بین ببرد و نتایج موفق را تبدیل به تمرکز و مسئولیت کل تیم کند.
- تیم‌های مستقل با عملکرد متقابل: برای هر محصولIT، تیم باید تمام مهارت‌ها و مسئولیت‌ها را داشته باشد تا محصول را از ایده تا دسترس‌پذیری و همچنین در چرخه‌های بهبود جلو ببرد تا وقتی که عمر محصول تمام شود.
- بهبود مداوم: تیم‌های DevOps همیشه به دنبال بهبود سرعت و کیفیت و پیشگیری از اتلاف منابع هستند.
- خودکارسازی هر چیزی که ممکن است: برای کار سریع‌تر، کارآمدتر و مؤثرتر، حیاتی است که تا جای ممکن از خودکارسازی IT استفاده شود تا وقت اعضای تیم آزادتر شود و بتوانند کارهای ارزشمندی انجام داده و امکان خطای انسانی کاهش یابد.
ابزار DevOps
ابزار DevOps با فراهم کردن امکان مدیریت توسعه‌ی کد، تست و زیرساخت به سازمان‌ها کمک می‌کنند اصول DevOps را پیاده‌سازی کنند. DevOps اصولاً به فرهنگ ایجاد و ارائه‌ی محصولات نرم‌افزاری ارتباط دارد، اما ابزار خودکارسازی و محصولات دیگر برای زنده کردن آن تکامل فرهنگی ضروری هستند.
ابزار متعددی وجود دارند که برای ساده‌تر شدن اقدامات فرهنگی DevOps طراحی شده‌اند. ابزاری برای کنترل مبدأ، پیکربندی و مدیریت انتشار، مانیتورینگ و غیره وجود دارند.
بهترین ابزار DevOps
بهترین ابزار DevOps ابزاری هستند که به فرایندها و افراد تشکیل‌دهنده‌ی فرهنگ DevOps خدمت می‌کنند. DevOps محصولی نیست که بتوان آن را خریداری و پیاده‌سازی کرد و بعد گفت: «حالا ما DevOps داریم.» الکس آنر، متخصص تکنولوژی DevOps در روزهای اولیه DevOps مطلبی را با این عنوان منتشر کرد: «ارجحیت افراد به فرایندها و ارجحیت فرایندها به ابزار» و در آن روی ارجحیت فرهنگ به ابزار تأکید کرد.
بااین‌وجود چندین محصول قابل‌توجه وجود دارد که می‌تواند به تیم‌های DevOps کمک کند کار خود را به انجام برسانند. فهرستی از ابزار برجسته که هم متن‌باز هستند و هم اختصاصی عبارت‌اند از:
- مدیریت کد منبع: Git (GitLab، GitHub) ،Bitbucket
- مدیریت پیکربندی: Puppet ،Chef، Ansible ،CFEngine
- مدیریت انتشار: Jenkins ،Travis ،CircleCl ،TeamCity ،Gradle ،Bamboo
- تنظیم (Orchestration): Mesos ،Zookeeper ،Kubernetes
- مانیتورینگ، مجازی‌سازی، Containerization:
- Nagios ،Icignia ،Monit ،OpenStack ،Vagrant ،AWS ،Docker Kubernetes
- تجزیه‌و‌تحلیل‌های چرخه عمر Log و برنامه کاربردی: Splunk یک ابزار مدیریت Log پیشرو است که برای DevOps ایدئال می‌باشد.
نحوه‌ی شروع به کار در DevOps
برای شروع به کار در DevOps، اول باید فرهنگ کنونی خود را در نظر بگیریم. شناسایی Siloها و Bottleneckهایی که جلوی توسعه، پیاده‌سازی، بازخورد و تکرار مداوم و سریع را می‌گیرند برای درک اینکه در کجا می‌توان پیشرفت کرد.
اندی مان، نویسنده و حامی ارشد تکنولوژی در Splunk به تازه‌کاران در Splunk توصیه می‌کند که «با توجه به سازمان منحصربه‌فرد خود در مورد مسیرشان در DevOps تصمیم‌گیری کنند اما اطمینان حاصل کنند که به نکات حیانی که شاخص‌های کلیدی برای موفقیت هستند دقت نمایند.» برخی از اصول راهگشا عبارت‌اند از: حذف اصطکاک، حرف Bottleneckها. استقبال از شکست و یادگیری از آن. سنجش. تکامل مداوم.
گزارش State of DevOps که توسط یکی از سازندگان نرم‌افزار پیشرو در DevOps به نام پاپت نوشته شده است، تکامل اقدامات DevOps را به پنج مرحله تقسیم‌بندی می‌کند. این گزارش پیشرفت را برمبنای مدل CAMS (فرهنگ، خودکارسازی، اندازه‌گیری و اشتراک) می‌سنجد. در این گزارش اقدامات اساسی برای اتخاذ DevOps و موفقیت آن شناسایی شده است:
- مانیتورینگ و هشداردهی توسط تیمی که سرویس را مدیریت می‌کنند قابل پیکربندی باشند.
- الگوهای پیاده‌سازی برای ساخت برنامه‌های کاربردی یا خدمات مجدداً مورد استفاده قرار می‌گیرند.
- الگوهای تست برای ساخت برنامه‌های کاربردی یا خدمات مجدداً مورد استفاده قرار می‌گیرند.
- تیم‌ها بهبودهایی را برای ابزاری که توسط تیم‌های دیگر فراهم شده است ارائه می‌دهند.
KPIهای DevOps
KPIهای کلیدی شامل موارد زیر هستند:
- تکرر پیاده‌سازی‌ها: با هدف انجام پیاده‌سازی‌های کوچک‌تر به تعداد بیشتر.
- تکرر پیاده‌سازی‌های ناموفق: هدف گرفتن برای تعداد کمتر.
- ویژگی‌های منتشر شده در هر فصل: لزومی ندارد که هر سه ماه یکبار باشد، اما اکثر رهبران کسب‌و‌کار در این بازه زمانی کار می‌کنند.
- متوسط زمان کشف یا MTTD: وقتی مشکلی پیش بیاید چقدر طول می‌کشد تا متوجه شویم؟
- متوسط زمان بازیابی یا MTTR: وقتی مشکلی پیش بیاید چقدر طول می‌کشد تا مشکل حل شود؟
- متوسط زمان پیاده‌سازی یا MLT: از وقتی که درخواست یک کد انجام می‌شود تا زمان پیاده‌سازی آن چقدر طول می‌کشد؟
- Uptime: ردیابی دسترس‌پذیری، اندازه‌گیری زمان Downtime برنامه‌ریزی‌شده برای Maintenance و همچنین قطعی‌های برنامه‌ریزی‌نشده.
- نرخ فرار از نقص: چند نقص به جای اینکه توسط تیم‌های QA متوقف شوند، وارد تولید می‌گردند؟
- عملکرد برنامه کاربردی: وقتی تغییری ایجاد می‌شود، عملکرد برنامه کاربردی چه فرقی می‌کند؟
وقتی چالش‌های خود و نحوه‌ی اندازه‌گیری پیشرفت را شناسایی کردیم، می‌توانیم شروع کنیم به شکل دادن مجدد به فرهنگ خود. Siloهای بین توسعه‌دهندگان، تست‌کنندگان، تیم‌های عملیاتی و تحلیلگران امنیتی را از بین می‌بریم. تحلیلگران کسب‌و‌کار را وارد بحث می‌کنیم، به همه‌ی افراد آموزش می‌دهیم که هدف‌شان صرفاً انجام کارهایی که در لیست خود دارند نیست، بلکه باید مسئولیت را برای سرعت و کیفیت کلی تولید و ارائه‌ی نرم‌افزار تقسیم کنند و همچنین فرصت‌های آموزشی را با تغییراتی در فرایند و زیرساخت ترکیب می‌کنیم و در نهایت حتماً باید به یاد داشته باشیم که DevOps چیزی نیست که در شش ماه یا یک سال در آن کامل و بدون نقص شویم. همان‌طور که جر هامبل، یکی از حامیان DevOps می‌گوید: «DevOps هدف نیست، بلکه یک فرایند دائمی برای بهبود مداوم است.»
