در قسمت اول مقاله در مورد اینکه مفهوم دواپس چیست؟ صحبت کردیم و به طور مختصر لیست 5 اقدام اساسی در تکامل این فرهنگ آن پرداختیم در ادامه مقالات اقدامات دیگر را بررسی خواهیم کرد.
2. مشاهده‌پذیری، Telemetry و Semantic Logging
در بین سازمان‌هایی که تکامل بالایی پیدا کرده‌اند، اکثریت همیشه Logging، آثار و معیارهای سنجش برنامه کاربردی را همراه با برنامه کاربردی یا سرویس پیاده‌سازی می‌کنند تا مانیتورینگ و هشداردهی در عملیات تولیدی به‌صورت Downstream ساده‌سازی شود. این امر مشاهده‌پذیری را که عبارت است از قابلیت پاسخ به سؤالات در مورد سازمان خود، از جمله سؤالاتی که از قبل از وجود آن‌ها خبر نداشتیم فراهم می‌کند.
عبارت مشاهده‌پذیری در سیستم‌های صنعتی شروع شد و دستیابی به آن می‌تواند به‌سادگی اضافه کردن یک حسگر جریان درون یک لوله‌ی آب یعنی اندازه‌گیری داخلی و اتصال آن به یک نمایشگر خراجی یعنی اضافه کردن Telemetry باشد. انجام این کار به اپراتور این امکان را می‌دهد که با مشاهده‌ی یک نتیجه‌ی خارجی یکی از ویژگی‌های داخلی سیستم را مشاهده کند.
ویدیوهای بیشتر درباره ی DevOps
در یک برنامه کاربردی، مشاهده‌پذیری معمولاً با اضافه کردن معیارهای سنجش عملکرد، ردیابی تماس میکروسرویس وSemantic Logging بدست می‌آید تا فعالیت واقعی یک برنامه کاربردی توصیف شود و این می‌تواند هم شامل معیارهای سنجش فنی مثل زمان پاسخ‌دهی End-to-End و معیارهای سنجش کسب‌و‌کار مثل درآمد به ازای هر تراکنش باشد. این کار به تیم‌ها توانایی پیکربندی مانیتورینگ خود را از طریق شاخص‌های واقعی موفقیت ارائه می‌دهد و کاربران مجبور نیستند که نتیجه را حدس بزنند.
مشاهده‌پذیری به تیم‌ها این توانایی را می‌دهد که با معماری‌های مدرن قابل‌ترکیب، مثل کلود، میکروسرویس‌ها، Containerها، APIها و زیرساخت بدون سرور کار کنند. این معماری‌ها با وجود تمام مزایایی که دارند، ممکن است قابلیت دید اندکی به عملکرد زیرساخت فراهم کنند. در سیستم‌های پیچیده و مبهم، حذف معیارهای سنجش، اثرات و Logها برای ساختن مشاهده‌پذیری درون سیستم در زمان انتشار متخصصان DevOps را در جایگاه اصلی قرار می‌دهد تا بتوانند مانیتورینگ معناداری را برای هر سناریویی در آینده تعریف و پیکربندی کنند.
بیشتر بخوانید: DevOps چیست؟ معماری و سه اصل مبنایی این رویکرد کدام است – قسمت اول
منظور از اندازه گیری در دواپس چیست؟ اندازه‌گیری بخشی اصلی از DevOps است و مانیتورینگ تقویت شده فقط برای Ops یا یک تیم DevOps جدید نیست بلکه برای تمام تیم‌هایی است که با تکنولوژی سرکار دارند. مانیتورینگ تقویت‌شده برای تیم‌ها نشان‌دهنده‌ی یکی از مهم‌ترین ارکان DevOps بوده و نیازی نیست تیم جدیدی با قدرت‌های ویژه ساخته شود، بلکه در عوض باید تمام تیم‌های موجود را تقویت کنیم تا به شیوه‌های جدیدی با هم کار کنند.
مانیتورینگ و هشداردهی Self-Service می‌تواند به‌راحتی توسط افراد زیر مورداستفاده قرار گیرد و بسیار مفید واقع شود:
توسعه‌دهندگانی که کد خود را در زمان اجرا در تولید مانیتور می‌کنند.
تیمی از توسعه‌دهندگان که با همکاران خود در بخش عملیات کار می‌کنند تا برنامه‌های کاربردی عملیاتی را ارائه دهند.
یک تیم DevOps که به‌عنوان یک گروه واحد برای تعریف اقدامات مانیتورینگ خود کار می‌کند.
یک تیم پیچیده متشکل از چندین تیم که در آن‌ها متخصصان Ops برنامه‌های کاربردی ارائه‌شده توسط توسعه‌دهندگان را به‌عنوان بخشی از یک سیستم بزرگ‌تر مانیتور می‌کنند.
فارغ از شرایط به‌خصوص، مانیتورینگ و هشداردهی Self-Service یک اقدام متقابل است به این الگوی قدیمی که بخش‌های Dev و Ops جدا از هم کار می‌کردند. صرفاً ارائه‌ی دسترسی به این معیارهای سنجش کلیدی فرهنگ اشتراک را ایجاد می‌کند، چرخه‌های بازخورد را تکمیل می‌کند و فرهنگ یادگیری مداوم را بین تیم‌ها ترویج می‌دهد.
بیشتر بخوانید: آسیب‌پذیری برنامه‌هایِ تحت وبِ بانک‌ها و اهمیت استفاده از Secure DevOps
استفاده مجدد از الگوهای پیاده‌سازی برای ساخت برنامه‌های کاربردی یا خدمات با استفاده از دواپس
تحقیقات نشان داده است که قابلیت مبنایی دومی وجود دارد که برای موفقیت DevOps ضروری میباشد، یعنی قابلیت استفاده مجدد از فرایندها، سیستم‌ها، ابزار و روتین‌های پیاده‌سازی از پیش تعریف شده یا برای ساختن برنامه‌های کاربردی یا سرویس‌های End-to-End کامل.
استفاده‌ی مجدد از کد برای مهندسی نرم‌افزار با کیفیت بالا ضروری بوده و این امر به کد پیاده‌سازی و کد مانیتورینگ نیز قابل‌تعمیم میباشد. استفاده از مانیتورینگ به‌عنوان کد و زیرساخت به‌عنوان کد باعث سریع‌تر شدن چرخه‌های انتشار، کاهش اشتباهات میشود و به Dev و Ops این امکان را می‌دهد که بهترین کار ممکن را انجام دهند.
3. استفاده مجدد از الگوهای تست برای ساخت برنامه‌های کاربردی یا خدمات
خودکارسازی تست نرم‌افزار به‌اندازه‌ی خودکارسازی پیاده‌سازی و مانیتورینگ آن مهم یا حتی از آن مهم‌تر است. تغییرات کوچک می‌توانند به شیوه‌هایی غیرقابل‌پیش‌بینی با سرویس‌های دیگر تعامل کنند و بدون وجود یک سیستم تست قدرتمند، ممکن است متوجه آن تغییرات نشویم. در ادامه برخی از ملاحظاتی که باید در حین اولویت‌بندی مدنظر قرار گیرند، مطرح میشود:
اگر تیم‌های کیفیت از تیم‌های Dev و Ops جدا باشند، شاید بهتر باشد کمی برای یکپارچه‌سازی آن‌ها در برنامه‌های DevOps صبر کنیم. تمرکز روی ایجاد الگوهای تست خوب در چارچوب تیم خود: این امر برای تیم‌های Ops می‌تواند به معنای داشتن فرایندی برای تست کردن تغییرات زیرساخت، پیش از پیاده‌سازی در تولید باشد. اما برای تیم‌های Dev می‌تواند به معنای پیاده‌سازی توسعه‌ی مبتنی بر تست یا همان TDD یا روش‌های دیگری به‌عنوان بخشی از جریان کاری چابک باشد.
اقدامات نزدیک به تولید، مثل آماده‌سازی، مانیتورینگ، هشداردهی و غیره معمولاً برای تیم‌ها اولویت بالاتری دارند زیرا اکثر مشکلات در این موارد مشاهده می‌شوند. بهتر است ابتدا مشکلات پیاده‌سازی خود را حل کنیم تا زمان لازم برای بهبود تست‌های خود را داشته باشیم.
شاید الگوهای تست کمتر از الگوهای پیاده‌سازی قابلیت استفاده‌ی مجدد را داشته باشند زیرا تست کردن به ویژگی‌های یک برنامه کاربردی یا سرویس مربوط بوده و همچنین فرایندهای مختلفی مثل Smoke Testها، Unit Testها، تست‌های عملیاتی، تست‌های تطبیق‌پذیری و تست‌های پیچیدگی را پوشش می‌دهد که هم در محیط‌های استاتیک/White Box و هم پویا/Black Box وجود دارند؛.
تست کردن در تولید معمولاً سخت‌تر و پیچیده‌تر از تست کردن در پیش‌تولید است، زیرا اهداف آن با اهداف تست پیش‌تولید متفاوت است. از طریق ارائه‌ی مداوم، تیم‌ها می‌توانند در تولید آزمون‌وخطا کنند تا ایده‌های جدید را تست نمایند. این امر ارزشمند است، اما با تست در تولید که روی تجربه‌ی کاربری، کیفیت و قابلیت ترمیم به صورت خودکار و غیره تمرکز دارد متفاوت است.
استفاده از فرایندهای تست با قابلیت استفاده‌ی مجدد یک اقدام اساسی میباشد اما معمولاً در مراحل بعدی از مسیر تکامل انجام میشود، پس‌ازاینکه الگوهای پیاده‌سازی به‌خوبی تثبیت شده باشند. اگر اجباری برای اولویت‌بندی وجود دارد، پیشنهاد میشود که اول روی اقدامات دیگر تمرکز کرده و برای رسیدگی به این مورد صبور باشید. اما وقتی‌که این اقدام شروع شد، مهم است که اطمینان حاصل شود، الگوهای تست قابلیت اشتراک‌گذاری دارند. مثلاً می‌توان تست‌ها با قابلیت استفاده مجدد را در ابزار تست خودکارسازی‌شده رمزگذاری کرد و دسترسی به آن ابزار را یعنی همراه با گزارش‌ها و داشبوردهای نتیجه بین تمام ذینفعان به اشتراک گذاشت.
4. تیم‌ها بهبودهایی را برای ابزاری که توسط تیم‌های دیگر فراهم‌شده است ارائه می‌دهند
قابلیت ارائه‌ی بهبود برای ابزار که توسط تیم‌های دیگر فراهم میشود، یک قابلیت کلیدی و بنیادی است. بهبود در ابزار معمولاً به‌صورت دستی و Ad Hoc و در یک تیم واحد انجام میشود تا وقتی که یک تغییر موجب نیاز به همکاری با تیم‌های دیگر شود.
5. پیکربندیها توسط ابزار مدیریت پیکربندی مدیریت می‌شوند
معیار تکامل سازمان با دواپس چیست؟ وقتی سازمان‌ها در تکامل DevOps خود پیشروی کنند، اقدام به مدیریت پیکربندیها با ابزار مدیریت پیکربندی در سازمان ریشه می‌دواند. برای افرادی که مدت زیادی طرفدار DevOps بوده‌اند، جای تعجب ندارد که این اقدام مبنایی برای موفقیت باشد. برای سال‌هایی طولانی، مدیریت پیکربندی خودکارسازی‌شده محرک DevOps بوده، به‌خصوص در روزهای اولی که زیرساخت به‌عنوان کد مدنظر قرار می‌گرفت و حرکت DevOps حول مبتکران اولیه در مدیریت پیکربندی خودکارسازی‌شده می‌گشت. اخیراً حرکت به Cloud بیش‌ازپیش روی اهمیتِ یک سیستم مدیریت پیکربندی و پیاده‌سازی برای مدیریت پیچیدگی یک پیاده‌سازی مدرن تأکید دارد. بررسی محرک‌های اولیه DevOps می‌تواند نشانگر اهمیت مدیریت پیکربندی باشد.
