جنبش دواپس (DevOps) که نزدیک به 20 سال پیش شکل گرفت، مرز سنتی میان توسعهدهندگان نرمافزار و عملیات فناوری اطلاعات را در هم شکست و شعار «آن را میسازی، آن را اجرا میکنی» را به فلسفه اصلی خود تبدیل کرد. با این وجود، پذیرش این مدل در محیطهای کوبرنتز (Kubernetes) آنهمها ساده نیست؛ بهویژه زمانی که از تیمهای برنامهنویسی انتظار میرود پایگاههای داده و سرویسهای دادهای را نیز خودشان مدیریت کنند.
گرههای درگیری توسعهدهندگان با دیتابیسها
در دنیای مهندسی پلتفرم، توسعهدهندگانی که در کدنویسی و ساخت نرمافزار بینظیر هستند، ناگهان با پایگاههای دادهای مواجه میشوند که در دنیایی کاملاً متفاوت قرار دارند و به تخصص عملیاتی بخصوصی نیاز دارند. هدف اصلی مهندسی پلتفرم باید کاهش بار عملیاتی باشد، نه انتقال این بار به دوش تیمهای توسعه. یک پلتفرم داخلی قدرتمند باید مصرف پایگاههای داده را سادهتر کند، نه اینکه اجرای آنها را سختتر.
ابزارهایی مانند a9s Hub این رویکرد را در عمل پیادهسازی میکنند: توسعهدهندگان میتوانند پایگاههای داده را از طریق گردشکارهای بومی کوبرنتز درخواست کنند، در حالی که یک صفحه کنترل متمرکز، تأمین منابع، پشتیبانگیری، نصب پچهای امنیتی و حاکمیت داده را بر عهده میگیرد.
توهم سادگی در استقرار اولیه
استقرار پایگاهدادههایی مانند PostgreSQL، Redis یا OpenSearch با اجرای یک فرمان ساده مانند Helm install بسیار آسان به نظر میرسد. سرویس ظاهراً بدون مشکل راهاندازی میشود، به شرطی که همهچیز روی غلتک بیفتد. فاجعه زمانی آغاز میشود که سرویس دچار اختلال میشود و باید پایداری آن حفظ شود؛ فرآیندی که شامل نصب وصلهها، پایش مداوم، پشتیبانگیری و بازیابی صحیح است. این سطح از تخصص عملیاتی هرگز بخشی از ماموریت تیمهای محصول نبوده است.
برنامههای مدرن بهندرت به یک سرویس دادهای وابستهاند. یک پلتفرم SaaS ممکن است برای دادههای اصلی به PostgreSQL، برای کش به Redis و برای جستجو به Elasticsearch نیاز داشته باشد؛ تمامی این سرویسها باید در یک ساختار با دسترسیپذیری بالا (High Availability) فعالیت کنند. شعار «آن را میسازی، آن را اجرا میکنی» تنها زمانی معنادار است که توسعهدهندگان سرویسهای مورد نیاز خود را از طریق اتوماسیون درخواست کنند و عملیاتهای پیچیده در پسزمینه و توسط متخصصان انجام شود.
کابوس ارتقا و فیلاور در کلاسترهای سهگرهای
نخستین نقاط شکست معمولاً زمانی خود را نشان میدهند که نیاز به بهروزرسانی پایگاهداده بروز میکند. تصور کنید PostgreSQL روی نسخه خاصی مستقر شده و هفتهها بعد، یک آسیبپذیری امنیتی بحرانی کشف میشود. ارتقای سیستم نیازمند بررسی لاگهای تغییرات، ارزیابی ایمنی فرآیند و طی کردن مراحل پیشنیاز است. اتوماسیون پایگاهداده در کوبرنتز در اینجا حیاتی میشود، زیرا ارتقا بخشی از مدیریت چرخه حیات داده است و هرگز یک تنظیم یکباره محسوب نمیشود.
مدیریت PostgreSQL روی یک گره (Node) تنها بسیار ساده است. اما برای جلوگیری از قطعی سرویس، به یک کلاستر معمولاً سهگرهای نیاز دارید تا در صورت خرابی یکی، دیگری جایگزین آن شود. این ساختار تابآوری را بالا میبرد، اما پیچیدگیهایی را نیز ایجاد میکند که میتواند همان قطعی را که هدفش جلوگیری از آن بود، رقم بزند.
ارتقای یک کلاستر سهگرهای باید گره به گره انجام شود و فرآیند فیلاور (Failover) بهشدت مستعد خطاست. اگر فرآیند انتخاب گره جایگزین با شکست مواجه شود، ممکن است دو گره بهطور همزمان فرض کنند که گره اصلی (Leader) هستند. این اتفاق منجر به نوشتههای ناسازگار و در بدترین حالت، خرابی کامل دادهها میشود. گاهی با راهاندازی مجدد کلاستر مشکل در چند دقیقه حل میشود، اما در صورت خرابی واقعی دادهها، قطعی سرویس ممکن است ساعتها طول بکشد.
آینده در خودکارسازی پلتفرمهای داده نهفته است
مدیریت دادهها در کوبرنتز نیازمند مالکیت دقیق و تخصصی است. تیمهای توسعه نباید درگیر جزئیات پیچیده زیرساختی و عملیاتی دیتابیسها شوند. بلوغ واقعی در فضای ابری زمانی محقق میشود که پلتفرمهای داخلی، تمامی چالشهای چرخه حیات پایگاهداده را در پسزمینه و بهصورت خودکار مدیریت کنند تا تیمهای نرمافزاری بتوانند تمرکز خود را صرف خلق ارزش برای کسبوکار کنند.
