شما خیلی دیر برنامه ریزی ابری انجام می دهید

اگر Cloudops به خوبی پیش نمی رود، احتمالاً برنامه ریزی مهم نادیده گرفته می شود یا تا زمانی که خیلی دیر در این فرآیند باقی مانده است.

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

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

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

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

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

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

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

مشکل این است که بسیاری از توسعه‌دهندگان راه‌حل‌های ابری بر این باورند که استفاده از agile و devops به معنای اشتباه کردن چندین بار قبل از یک بار درست کردن آن است. این هرگز هدف چابک یا توسعه نیست. این در مورد یادگیری از اشتباهات ما و تنظیم برای تبدیل کردن توسعه راه حل و استقرار فرآیندی بسیار مقرون به صرفه است. فکر کردن به برنامه ریزی عملیاتی زودهنگام و اغلب یکی از مواردی است که در لیست چگونگی موفقیت با این موارد توسعه راه حل ابری است. به من اعتماد کن.