چه زمانی این همکاری مفید است
تیمهای مهندسی وقتی هر کاربرد باید استقرار، دسترسی، راز، تلهمتری و بازیابی را جدا بسازد وقت از دست میدهند. پلتفرم باید این تکرار را کم کند بدون آنکه مسئولیت عملیاتی پنهان شود.
تصمیمها پیش از اجرا
مسیر هموار را حول گردش کار واقعی توسعهدهنده و ظرفیت پشتیبانی طراحی میکنیم. تنانت کلاستر، هویت بارکاری، مرز شبکه، ارتقا، کنترل استقرار و مشاهدهپذیری با هم دیده میشوند. پلتفرم کوچک مفید از کاتالوگی که کسی نتواند اداره کند بهتر است.
معماری در بستر تصمیم
معماری مفهومی برای مرزهای تصمیم؛ محیط مشتری را نشان نمیدهد.
آنچه دریافت میکنید
- ارزیابی گردش کار توسعهدهنده و قابلیت پلتفرم
- طراحی تنانت کلاستر/بارکاری، دسترسی و چرخه عمر
- الگوهای استقرار قابل استفاده مجدد و نگهبانهای عملیاتی
- راهنمای مشاهدهپذیری، بازیابی و ارتقا
- مالکیت پلتفرم و مستندات ورود
نحوه کنترل تحویل
- 01انتخاب تیم و بارکاری نماینده.
- 02توافق قابلیتها و مرزهای پلتفرم.
- 03ساخت سرویسهای بنیادی و مسیر تحویل کنترلشده.
- 04اعتبارسنجی ایزولاسیون بارکاری، مدیریت خطا و عملیات روز دوم.
- 05ورود تیمها و اولویتبندی بهبودها با بازخورد تحویل.
مرزها و مقایسه گزینهها
Kubernetes حتی با صفحه کنترل مدیریتشده مسئولیت عملیاتی اضافه میکند. سرویس کاربرد مدیریتشده و الگوهای سادهتر را جایی مقایسه میکنیم که برای بارکاری مناسبترند؛ کلاستر پاسخ پیشفرض نیست.
پرسشها و پاسخها
چگونه به مهندسان مسیر قابل اتکا تا تولید بدهیم؟
بنیاد Kubernetes و پلتفرم توسعهدهنده بسازید تا تحویل برای تیمهای بهرهبردار تکرارپذیر، قابل مشاهده و پایدار باشد.
#تیم ما در زمان تحویل چه انتظاری داشته باشد؟
تحویل شامل ارزیابی گردش کار و قابلیت پلتفرم، طراحی تنانت و دسترسی و الگوهای استقرار با نگهبانهای عملیاتی است. شواهد پذیرش و مالک مستمر را پیش از اجرا توافق میکنیم.
#برای گفتگوی اول چه چیزی بیاوریم؟
هدف کسبوکار، معماری فعلی، مالکان بارکاری، محدودیتهای عملیاتی و مهلتهای ثابت را بیاورید تا تصمیمها و دسترسیهای لازم این همکاری مشخص شود.
#حوزه، هزینه و زمان تحویل چگونه تعیین میشود؟
ابتدا بارکاری و وابستگیها را محدود میکنیم. خروجیهای موردنیاز، آمادگی دسترسی، پوشش آزمون و پنجرههای تأیید برنامه تحویل را مشخص میکند؛ پیش از کشف، قیمت یا زمانبندی ثابت فرض نمیکنیم.
#