آیا زیرساخت شما برای آینده آماده است؟ این 3 مشخصات را بررسی کنید

یک سیستم ممکن است امروز به خوبی کار کند و زمانی که ترافیک افزایش می‌یابد، سرویسی از کار می‌افتد، یا تیم باید تغییرات را با سرعت بیشتری انجام دهد، همچنان با مشکل مواجه شود. من دیدم که بررسی‌های زیرساخت بر روی اندازه سرور تمرکز می‌کنند در حالی که مناطقی را که بزرگترین خطرات را ایجاد می‌کنند از دست می‌دهند: ظرفیت محدود، برنامه‌های بازیابی ضعیف، و دید ضعیف رفتار سیستم. یک راه اندازی آماده برای آینده نیازی به استفاده از هر فناوری جدید ندارد. باید تغییرات را با اختلال کمتری مدیریت کند. این سه مشخصات به من یک نقطه شروع عملی می دهد. 1. ظرفیتی که می‌تواند بدون بازسازی کامل رشد کند من بررسی می‌کنم که وقتی تقاضا افزایش می‌یابد، زیرساخت چگونه پاسخ می‌دهد. یک بررسی مفید شامل موارد زیر است: - فضای اصلی CPU و حافظه - رشد فضای ذخیره سازی و ظرفیت پشتیبان - پهنای باند شبکه - محدودیت های اتصال به پایگاه داده - قوانین مقیاس خودکار - ظرفیت متعادل کننده بار - تغییرات هزینه در سطوح استفاده بالاتر سیستمی که با 85٪ CPU در ساعات کاری عادی کار می کند ممکن است فضای کمی برای افزایش ترافیک باقی بگذارد. یک کمپین ناگهانی، راه اندازی محصول یا تقاضای فصلی می تواند سرویس را به سمت پاسخ های آهسته یا درخواست های ناموفق سوق دهد. من به مدل مقیاس بندی هم نگاه می کنم. مقیاس عمودی به معنای افزودن قدرت بیشتر به یک دستگاه است. مقیاس بندی افقی به معنای افزودن ماشین ها یا نمونه های خدمات بیشتر است. مقیاس افقی می تواند رشد را با انعطاف بیشتری پشتیبانی کند، اما تنها زمانی که برنامه، پایگاه داده، رسیدگی به جلسه و فرآیند استقرار آن را پشتیبانی کند. یک آزمایش ظرفیت ساده می تواند شکاف ها را نشان دهد: 1. ترافیک عادی و ترافیک اوج را ثبت کنید. 2. بار تست را در مراحل کوچک افزایش دهید. 3. زمان پاسخ، نرخ خطا، CPU، حافظه و استفاده از پایگاه داده را پیگیری کنید. 4. بررسی کنید که آیا نمونه های جدید همانطور که انتظار می رود شروع می شوند یا خیر. 5. هزینه را در هر سطح بار بررسی کنید. 6. یک نقطه روشن برای بررسی دستی تعیین کنید. به عنوان مثال، یک فروشگاه آنلاین ممکن است 500 درخواست در دقیقه در طول یک دوره معمولی و 2000 درخواست را در طول تبلیغات رسیدگی کند. اگر سیستم فقط با 600 درخواست در دقیقه آزمایش شده باشد، تیم با شواهد محدود تصمیم گیری می کند. آزمایش بار کنترل شده می تواند نشان دهد که آیا مشکل از سرورهای برنامه، پرس و جوهای پایگاه داده، محدودیت های شبکه یا یک سرویس خارجی است. برنامه ریزی ظرفیت نیز باید شامل داده ها باشد. فضای ذخیره سازی اغلب بی سر و صدا رشد می کند تا زمانی که پنجره های پشتیبان خیلی طولانی شوند یا عملکرد پایگاه داده شروع به کاهش کند. من ترجیح می دهم رشد ماهانه را دنبال کنم و 12 تا 24 ماه آینده را تخمین بزنم. برآورد دقیق نخواهد بود، اما به تیم زمان می دهد تا برنامه ریزی کند. 2. اهداف بازیابی که با کسب و کار مطابقت دارند ** پشتیبان گیری با برنامه بازیابی برابری نمی کند. من دو مشخصات را بررسی می‌کنم: - **هدف زمان بازیابی (RTO): مدت زمانی که سرویس می‌تواند در دسترس نباشد - هدف نقطه بازیابی (RPO): چه مقدار از داده‌های اخیر کسب‌وکار می‌تواند قبول کند از دست دادن یک ابزار داخلی کوچک ممکن است یک RTO چند ساعته را بپذیرد. یک سیستم پرداخت یا سفارش ممکن است به یک پنجره بازیابی کوتاه‌تر نیاز داشته باشد. هدف مناسب به تأثیر کسب و کار، نیازهای مشتری، هزینه عملیاتی و محدودیت های فنی بستگی دارد. طرح بازیابی باید به سؤالات عملی پاسخ دهد: - نسخه های پشتیبان در کجا ذخیره می شوند؟ - هر چند وقت یکبار پشتیبان گیری ایجاد می شود؟ - آیا بک آپ ها از محیط اصلی جدا شده اند؟ - چه کسی می تواند سیستم را بازیابی کند؟ - ترمیم چقدر طول می کشد؟ - تغییرات داده ها پس از بازیابی چگونه بررسی می شود؟ - اگر منطقه اولیه یا مرکز داده در دسترس نباشد چه اتفاقی می افتد؟ - آخرین آزمایش ریکاوری کی بود؟ یک تیم ممکن است پشتیبان‌گیری‌های روزانه را گزارش کند، اما اگر آخرین نسخه پشتیبان بازیابی نشود، ممکن است هنوز یک روز از معاملات خود را از دست بدهد. من تست بازیابی را بخشی از مشخصات می دانم، نه به عنوان یک تمرین اختیاری. یک تست بازیابی مفید می تواند از این الگو پیروی کند: 1. یک محیط تست کم خطر را انتخاب کنید. 2. یک نسخه پشتیبان اخیر را بازیابی کنید. 3. زمان مورد نیاز را اندازه گیری کنید. 4. عملکرد برنامه و سازگاری داده ها را بررسی کنید. 5. ثبت شکست ها و مراحل نامشخص. 6. runbook را به روز کنید. 7. آزمون را در یک فاصله زمانی برنامه ریزی شده تکرار کنید. قطعی ابر عمومی نشان داده است که چرا یک مکان واحد می تواند خطر عملیاتی ایجاد کند. طراحی چند منطقه ای ممکن است این خطر را کاهش دهد، اما هزینه بالاتر و مدیریت داده پیچیده تر را نیز به همراه دارد. انتخاب باید منعکس کننده نیاز خدمات به جای ترجیح عمومی برای مناطق بیشتر باشد. من همچنین می‌پرسم که آیا تیم بدون شخصی که سیستم اصلی را ایجاد کرده است می‌تواند بهبود یابد؟ اگر پاسخ منفی است، مستندات نیاز به کار دارد. 3. نظارتی که تجربه کاربران را توضیح می‌دهد در حالی که مشتریان با صفحات کند یا تراکنش‌های ناموفق مواجه می‌شوند، زیرساخت می‌تواند سالم به نظر برسد. معیارهای CPU و حافظه مفید هستند، اما داستان کامل را بیان نمی کنند. می‌خواهم ببینم: - درخواست تأخیر، از جمله مقادیر p95 یا p99 - نرخ خطا - در دسترس بودن - عمق صف - زمان جستجوی پایگاه داده - عملکرد حافظه پنهان - استقرار ناموفق - اتصالات اشباع شده - نرخ موفقیت تراکنش کاربر میانگین‌ها می‌توانند مشکلات را پنهان کنند. اگر بیشتر درخواست‌ها 100 میلی‌ثانیه طول بکشد در حالی که یک گروه کوچک‌تر 8 ثانیه طول می‌کشد، میانگین ممکن است همچنان قابل قبول به نظر برسد. داده های درصدی دید بهتری از درخواست های کندتر می دهد. گزارش‌ها باید به تیم کمک کنند تا به سه سؤال پاسخ دهند: 1. چه اتفاقی افتاد؟ 2. کدام سرویس باعث آن شد؟ 3. کدام کاربران یا تراکنش ها تحت تأثیر قرار گرفتند؟ شناسه درخواستی که تراکنش بین سرویس‌ها را دنبال می‌کند، می‌تواند زمان بررسی را کاهش دهد. هشدارها همچنین باید به یک اقدام احتمالی اشاره کنند. هشداری که می گوید "CPU بالا" راهنمایی محدودی را ارائه می دهد. هشداری که CPU بالا را با افزایش خطاهای پرداخت و استقرار اخیر مرتبط می کند، زمینه مفیدتری را به تیم می دهد. توصیه می‌کنم کیفیت هشدار را پس از حوادث مرور کنید. اگر تیم هشدارهای زیادی دریافت کند اما تأثیر مشتری را از دست بدهد، تنظیم نظارت نیاز به تنظیم دارد. اگر هیچ هشداری در طول یک خرابی شناخته شده ظاهر نشد، شکاف باید مستند شده و آزمایش شود. امنیت نیز به این بررسی تعلق دارد. من مجوزهای دسترسی، ذخیره سازی مخفی، روال های وصله، کنترل های شبکه و گزارش های حسابرسی را بررسی می کنم. این بررسی‌ها جایگزین ارزیابی کامل امنیتی نمی‌شوند، اما می‌توانند ضعف‌های اساسی در عملیات روزانه را آشکار کنند. یک بررسی عملی می‌تواند به هر مشخصات از 1 تا 5 امتیاز دهد: - 1: بدون طرح واضح یا اندازه‌گیری قابل اعتماد - 2: برخی ابزارها وجود دارند، اما آزمایش محدود است - 3: فرآیند در شرایط عادی کار می‌کند - 4: فرآیند تحت استرس آزمایش شده است - 5: فرآیند آزمایش، مستند شده و بررسی می‌شود زیرا سیستم شواهد مفیدی را تغییر می‌دهد. امتیاز کمتر از آن است. یک تیم باید بتواند نتایج تست ظرفیت را نشان دهد، سوابق را بازیابی کند، داشبوردهای نظارتی و runbookهای به روز شده را نشان دهد. وقتی زیرساخت را ارزیابی می کنم، نمی پرسم که آیا از جدیدترین پلت فرم استفاده می کند یا خیر. من می‌پرسم که آیا می‌تواند از رشد مورد انتظار پشتیبانی کند، در یک پنجره توافق شده بهبود یابد و به تیم نشان دهد که کاربران چه چیزی را تجربه می‌کنند. اگر پاسخ نامشخص است، مرحله بعدی بازسازی کامل نیست. با اندازه گیری ها شروع کنید، مناطق ضعیف را آزمایش کنید و بخشی را که بیشترین ریسک تجاری را به همراه دارد، بهبود بخشید.

بسیاری از تیم های زیرساختی محدودیت های سیستم های خود را در طول راه اندازی محصول، افزایش ترافیک یا یک رویداد امنیتی کشف می کنند. مشکل به ندرت یک سرور است. اغلب ترکیبی از مقیاس‌بندی آهسته، برنامه‌های بازیابی ضعیف و دید محدود به سلامت سیستم است. من زیرساخت‌ها را با سه ویژگی عملی قضاوت می‌کنم: اینکه چقدر خوب مقیاس می‌شود، چقدر سریع بهبود می‌یابد، و اینکه تیم چقدر می‌تواند به وضوح ببیند چه اتفاقی می‌افتد. این اقدامات به من کمک می کند سیستمی را که فقط امروز کار می کند از سیستمی که می تواند نیازهای در حال تغییر کسب و کار را پشتیبانی کند جدا کنم. 1. ظرفیت کشسانی که با تقاضا مطابقت دارد یک زیرساخت آماده برای آینده می تواند منابع را با تغییر تقاضا اضافه یا آزاد کند. که ممکن است شامل نمونه های محاسباتی، کانتینرها، ظرفیت پایگاه داده، فضای ذخیره سازی یا پهنای باند شبکه باشد. من فراتر از یک برچسب ساده "مبتنی بر ابر" نگاه می کنم. سؤالات مفید بیشتر مشخص هستند: - آیا سیستم می تواند افزایش ناگهانی ترافیک را مدیریت کند؟ - جرم گیری چقدر طول می کشد؟ - آیا وقتی تقاضا کاهش می یابد می تواند کاهش یابد؟ - آیا پایگاه داده با لایه برنامه مقیاس می شود؟ - آیا قوانین مقیاس بندی بر اساس سیگنال های مفیدی هستند، مانند درخواست در ثانیه یا طول صف؟ یک شرکت خرده‌فروشی ممکن است در بیشتر ایام سال ترافیک ثابتی دریافت کند، سپس در طول یک کمپین فصلی شاهد افزایش شدید آن باشد. اگر سرورهای وب مقیاس شوند اما پایگاه داده ثابت بماند، کاربران ممکن است همچنان با صفحات کند یا سفارشات ناموفق روبرو شوند. افزودن سرورهای برنامه بیشتر، گلوگاه پایگاه داده را حل نمی کند. من تست های ظرفیت را ترجیح می دهم که الگوهای عادی کسب و کار را منعکس می کند. یک تیم می تواند ترافیک منظم، اوج ترافیک و یک جهش ناگهانی ترافیک را آزمایش کند. این آزمایش باید زمان پاسخ، میزان خطا، استفاده از منابع و هزینه را دنبال کند. یک هدف مفید ممکن است این باشد: - 95 درصد درخواست‌ها در مدت 300 میلی‌ثانیه تحت بارگذاری معمولی پاسخ می‌دهند - نرخ خطا در زمان اوج بارگذاری کمتر از حد توافق شده تجاری باقی می‌ماند - ظرفیت برنامه جدید در یک بازه زمانی مشخص در دسترس می‌شود - اتصالات پایگاه داده در محدوده عملیاتی ایمن باقی می‌مانند اعداد دقیق به سرویس بستگی دارد. آنچه مهم است این است که تیم قبل از بروز مشکل آنها را تعریف کند. 2. بازیابی آزمایش شده، نه تنها مستند شده طرح پشتیبان تنها زمانی ارزش دارد که تیم بتواند سرویس را بازیابی کند. من به دو اندازه گیری نگاه می کنم: - هدف زمان بازیابی: مدت زمانی که سرویس می تواند در دسترس نباشد - هدف نقطه بازیابی: چه مقدار از داده های اخیر کسب و کار می تواند از دست بدهد یک پلت فرم پرداخت ممکن است به یک نقطه بازیابی نیاز داشته باشد که در چند دقیقه اندازه گیری شود. یک ابزار گزارش داخلی ممکن است پنجره طولانی تری را بپذیرد. هدف درست ناشی از تاثیر تجاری است، نه از یک الگو. یک طرح بازیابی عملی ممکن است شامل موارد زیر باشد: - پشتیبان‌گیری خودکار - کپی‌های ذخیره شده در یک مکان جداگانه - داده‌های تکرار شده در مناطق یا مناطق موجود - مراحل بازیابی مستند - کنترل‌های دسترسی برای سیستم‌های پشتیبان - تست‌های بازیابی منظم یک خرده‌فروش آنلاین با اندازه متوسط ​​زمانی در طی یک تمرین بازیابی متوجه شد که پشتیبان‌گیری‌هایش کامل شده است، اما مدیر فرآیند بازیابی وابسته به یک نفر بود. فایل ها وجود داشت. سرویس هنوز نتوانسته است طبق برنامه بازگردد. پس از تمرین، تیم صاحبان مشخصی را تعیین کرد، دستورالعمل‌های بازیابی را با سیستم پشتیبان ذخیره کرد و هر سه ماه یک بار بازسازی را آزمایش کرد. این نوع آزمون شکاف هایی را که اسناد اغلب از قلم می اندازند، آشکار می کند. بازیابی ناموفق ناخوشایند است، با این حال مکان امنی را به تیم می‌دهد تا فرآیند را اصلاح کند. من همچنین بررسی می کنم که آیا بازیابی بیشتر از سرورها را پوشش می دهد یا خیر. برنامه‌ها ممکن است به DNS، خدمات هویت، گواهی‌ها، صف‌های پیام، APIهای شخص ثالث و اعتبار پایگاه داده بستگی داشته باشند. یک طرح بازیابی باید نشان دهد که این بخش ها چگونه با هم کار می کنند. 3. قابلیت مشاهده که سیگنال ها را به عمل متصل می کند زیرساخت مقدار زیادی داده تولید می کند. قابلیت مشاهده مفید به افراد کمک می کند تا آن داده ها را درک کنند و به مشکلات سرویس پاسخ دهند. من انتظار دارم سه نوع سیگنال: - ** معیارها:** تأخیر، ترافیک، نرخ خطا، استفاده از پردازنده، استفاده از حافظه، عمق صف - ** گزارش‌ها:** رویدادهای برنامه، سوابق دسترسی، هشدارهای امنیتی، پیام‌های سیستم - ردیابی: مسیر درخواست در بین سرویس‌ها داشبورد پر از نمودارها به طور خودکار عملیات را بهبود نمی‌بخشد. این تیم به نشانگرهای خدمات واضح و هشدارهای مفید نیاز دارد. به عنوان مثال، اگر زمان پاسخگویی ثابت بماند، ممکن است هشدار در مورد استفاده زیاد از CPU نیازی به اقدام فوری نداشته باشد. افزایش پرداخت های ناموفق حتی زمانی که ظرفیت سرور عادی به نظر می رسد، شایسته توجه است. هر زمان که ممکن است هشدارها را به تأثیر مشتری متصل می کنم. یک تنظیم نظارت قوی به سؤالاتی از قبیل: - کدام سرویس تحت تأثیر قرار می گیرد؟ - موضوع از چه زمانی شروع شد؟ - کدام کاربران یا مناطق مشکل را می بینند؟ - قبل از ظهور موضوع چه چیزی تغییر کرد؟ - مالک اکشن بعدی کیست؟ - آیا موضوع در حال رشد است یا بهبود می یابد؟ یک شرکت نرم‌افزاری می‌تواند از ردیابی درخواست استفاده کند تا متوجه شود که کندی صفحه پرداخت توسط وب سرور ایجاد نمی‌شود. تأخیر ممکن است از طرف یک سرویس توصیه محصول یا یک ارائه دهنده پرداخت خارجی باشد. این سطح از جزئیات حدس و گمان را کاهش می دهد و به تیم کمک می کند تا روی جزء مناسب تمرکز کند. قابلیت مشاهده نیز باید شامل هزینه و سیگنال های امنیتی باشد. رشد غیرمنتظره ذخیره سازی، فعالیت غیرمعمول ورود به سیستم، و افزایش شدید در انتقال داده ها می تواند به نگرانی های عملیاتی یا امنیتی اشاره کند. من از این سه مشخصات به عنوان یک چک لیست بازبینی عملی استفاده می‌کنم: 1. آزمایش ظرفیت در شرایط عادی، پیک و تقاضای ناگهانی. 2. زمان بازیابی و محدودیت های از دست دادن اطلاعات را برای هر سرویس تعریف کنید. 3. تمرینات بازیابی را اجرا کنید و نتایج را ثبت کنید. 4. نشانگرهای سرویس رو به روی کاربر را ردیابی کنید. 5. پیوند هشدارها به مالکان و مراحل پاسخ. 6. هزینه زیرساخت، دسترسی و تغییرات وابستگی را بررسی کنید. یک سیستم برای حمایت از رشد آینده به هر ابزار جدیدی نیاز ندارد. این نیاز به ظرفیت کافی برای تقاضای مورد انتظار، یک فرآیند بازیابی که مردم می توانند انجام دهند، و اطلاعات شفاف در هنگام تغییر شرایط نیاز دارد. وقتی زیرساخت را بررسی می‌کنم، یک سوال مستقیم می‌پرسم: آیا تیم می‌تواند توضیح دهد که وقتی تقاضا افزایش می‌یابد، وابستگی از کار می‌افتد یا داده‌ها باید بازیابی شوند، چه اتفاقی می‌افتد؟ اگر پاسخ به حدس و گمان بستگی داشته باشد، ممکن است سیستم قبل از تغییر عمده تجاری بعدی به آمادگی بیشتری نیاز داشته باشد.

بسیاری از طرح های زیرساختی روی کاغذ سالم به نظر می رسند و هنوز یک سال بعد مشکلاتی را ایجاد می کنند. فضای ذخیره‌سازی سریع‌تر از حد انتظار پر می‌شود. یک برنامه جدید به یک رابط کاربری متفاوت نیاز دارد. ابزارهای امنیتی بار اضافی را به سیستم های قدیمی اضافه می کنند. سپس تیم ها زمان بیشتری را صرف رفع محدودیت ها می کنند تا بهبود کسب و کار. من قبل از تأیید سرور، محیط ابری، ارتقاء شبکه یا بستر ذخیره سازی سه ویژگی را بررسی می کنم: - ظرفیت و عملکرد - سازگاری و یکپارچگی - امنیت و کنترل عملیاتی این قسمت ها به من کمک می کنند تا قضاوت کنم که آیا یک تصمیم زیرساخت می تواند نیازهای آینده را بدون پرداخت هزینه برای ویژگی هایی که کسب و کار استفاده نمی کند، پشتیبانی کند یا خیر. ## 1. ظرفیت و عملکرد من با بررسی نحوه عملکرد سیستم تحت استفاده معمولی و تحت فشار شروع می کنم. یک برگه مشخصات ممکن است سرعت پردازنده، حافظه، اندازه ذخیره سازی، پهنای باند شبکه یا محدودیت های نمونه ابری را فهرست کند. این اعداد مهم هستند، اما کل داستان را بیان نمی کنند. من همچنین به موارد زیر نگاه می‌کنم: - سطوح استفاده فعلی - اوج تقاضا - رشد مورد انتظار کاربر - رشد داده‌ها - نیازهای پشتیبان‌گیری - تغییرات حجم کاری - عملکرد در حین تعمیر و نگهداری یا خرابی شرکتی با 80 کارمند ممکن است روی سرور فایل فعلی خود به خوبی اجرا شود. این بدان معنا نیست که همان سرور از پورتال مشتری جدید، فایل‌های طراحی بزرگتر و کارهای تحلیلی روزانه پشتیبانی می‌کند. من ترجیح می‌دهم سه رقم را ثبت کنم: 1. میانگین استفاده فعلی 2. حداکثر استفاده در دوره‌های شلوغ 3. استفاده مورد انتظار در چرخه برنامه‌ریزی بعدی برای مثال، یک خرده‌فروش آنلاین کوچک ممکن است از 55 درصد ظرفیت پایگاه داده خود در یک روز عادی استفاده کند و در طول تبلیغات ماهانه به 85 درصد برسد. اگر کانال فروش جدیدی اضافه شود، سیستم ممکن است زودتر از آنچه تیم انتظار دارد به حد مجاز خود برسد. بررسی تنها رقم متوسط، نقطه فشار را پنهان می کند. من همچنین بررسی می کنم که چگونه پلت فرم مقیاس می شود. آیا می توانم حافظه اضافه کنم؟ آیا می‌توان فضای ذخیره‌سازی را بدون قطعی طولانی افزایش داد؟ آیا سرویس ابری می تواند ظرفیت محاسباتی را از طریق یک فرآیند واضح افزایش دهد؟ آیا شبکه از دستگاه های بیشتر و ترافیک بالاتر پشتیبانی می کند؟ طراحی مفید در عین اینکه هزینه را قابل مشاهده نگه می دارد، فضایی را برای رشد باز می کند. خرید ظرفیت بسیار بیشتر از آنچه که کسب و کار می تواند استفاده کند می تواند از طریق هزینه های بالاتر مجوز، انرژی، پشتیبانی و مدیریت مشکل خود را ایجاد کند. ## 2. سازگاری و یکپارچه سازی زیرساخت به ندرت به تنهایی کار می کند. با برنامه ها، سیستم های هویت، ابزارهای نظارت، پلتفرم های پشتیبان، خدمات پرداخت و دستگاه های کارمند ارتباط برقرار می کند. من سازگاری را قبل از بررسی ویژگی های اضافی بررسی می کنم. یک محصول ممکن است مشخصات قوی داشته باشد و اگر نتواند با سیستم‌هایی که از قبل وجود دارد متصل شود، باز هم تاخیر ایجاد می‌کند. چک لیست من شامل: - پشتیبانی از سیستم عامل - الزامات برنامه - پشتیبانی از API و پروتکل - گزینه های هویت و دسترسی - استانداردهای شبکه - سازگاری پشتیبان - پشتیبانی نظارت و هشدار - گزینه های صادرات داده ها - دوره های پشتیبانی فروشنده صادرات داده ها مستحق توجه دقیق است. اگر سرویسی بازیابی داده های تجاری را دشوار کند، ممکن است شرکت در طول مهاجرت یا تغییر قرارداد با مشکلاتی مواجه شود. می‌پرسم داده‌ها از چه فرمتی استفاده می‌کنند، صادرات چقدر طول می‌کشد و آیا صادرات شامل تنظیمات، گزارش‌ها و رکوردهای دسترسی است یا خیر. یک مثال واقعی، شرکتی است که از ذخیره‌سازی فایل‌های محلی به ذخیره‌سازی ابری می‌رود. سرویس ذخیره‌سازی ممکن است برای اسناد اداری به خوبی کار کند، اما تیم طراحی ممکن است به فایل‌های بزرگ، مجوزهای ویژه یا نرم‌افزاری وابسته باشد که انتظار یک مسیر شبکه محلی را دارد. اگر این جزئیات نادیده گرفته شوند، کارمندان ممکن است دسترسی آهسته یا جریان کاری شکسته را تجربه کنند. قبل از ایجاد یک تغییر گسترده تر، ارتباط را با یک گروه کوچک آزمایش می کنم. این آزمایش باید شامل یک کاربر عادی، یک مدیر، یک کارگر از راه دور و سیستمی باشد که داده ها را با پلتفرم مبادله می کند. بازخورد آنها اغلب مسائلی را آشکار می کند که مشخصات فنی نشان نمی دهد. سازگاری شامل افراد نیز می شود. سیستمی که به مراحل دستی پیچیده نیاز دارد می تواند درخواست های پشتیبانی را افزایش دهد و نتایج متناقضی ایجاد کند. گردش کار پاک به زیرساخت کمک می کند پس از خروج تیم نصب مفید بماند. ## 3. امنیت و کنترل عملیاتی امنیت باید بخشی از بررسی مشخصات باشد، نه آیتمی که پس از خرید اضافه شود. من بررسی می‌کنم که سیستم چگونه هویت، مجوزها، رمزگذاری، به‌روزرسانی‌ها، گزارش‌ها، پشتیبان‌گیری و بازیابی را مدیریت می‌کند. همچنین می‌پرسم چه کسی می‌تواند تنظیمات را تغییر دهد و این تغییرات چگونه ثبت می‌شوند. سوالات کلیدی عبارتند از: - آیا پلتفرم از احراز هویت چند عاملی پشتیبانی می کند؟ - آیا می توان دسترسی را بر اساس نقش تعیین کرد؟ - آیا اکانت های استفاده نشده به راحتی غیرفعال می شوند؟ - آیا اقدامات مدیر ثبت شده است؟ - آیا می توان لاگ به سیستم مانیتورینگ موجود ارسال کرد؟ - به روز رسانی های امنیتی چگونه ارائه می شود؟ - آیا می توان بک آپ ها را از سیستم های تولیدی جدا کرد؟ - بهبودی پس از یک شکست چقدر طول می کشد؟ - آیا تیم می تواند بازیابی را بدون تأثیر بر خدمات زنده آزمایش کند؟ پشتیبان گیری تنها زمانی مفید است که کسب و کار بتواند داده های مورد نیاز را در مدت زمان قابل قبول بازیابی کند. از تیم می‌خواهم به جای تکیه بر یک پیام وضعیت که می‌گوید پشتیبان‌گیری کامل شد، یک نمونه بازیابی را آزمایش کنند. برای مثال، یک مطب کوچک پزشکی ممکن است پشتیبان‌گیری روزانه داشته باشد، اما روند بازیابی آزمایش شده نداشته باشد. اگر سرور اصلی از کار بیفتد، کارکنان ممکن است متوجه شوند که حساب پشتیبان دیگر کار نمی کند یا یک برنامه کلیدی در آن گنجانده نشده است. یک تمرین ریکاوری می‌تواند این شکاف‌ها را در حالی که خدمات عادی هنوز در دسترس هستند، آشکار کند. کنترل عملیاتی نیز به مستندات بستگی دارد. من می‌خواهم نمودار سیستم، فهرست مالکیت، فرآیند به‌روزرسانی، مسیر تشدید و راهنمای بازیابی را ببینم. این مدارک نیازی به طولانی بودن ندارند. آنها باید به یک کارمند آموزش دیده دیگر کمک کنند تا بفهمد چه چیزی وجود دارد و وقتی یک سرویس از کار افتاد چه کاری انجام دهد. ## یک فرآیند بررسی عملی من از یک جدول بررسی ساده برای هر پیشنهاد زیرساخت استفاده می کنم: | منطقه | سوالات ثبت | |---|---| | ظرفیت | بار فعلی، اوج بار و رشد مورد انتظار چقدر است؟ | | عملکرد | در طول دوره های شلوغ، تعمیر و نگهداری یا خرابی نسبی چه اتفاقی می افتد؟ | | سازگاری | کدام سیستم‌ها، برنامه‌ها و دستگاه‌های موجود باید متصل شوند؟ | | امنیت | دسترسی، به‌روزرسانی‌ها، گزارش‌ها، پشتیبان‌گیری و بازیابی چگونه انجام می‌شود؟ | | عملیات | چه کسی مالک سیستم است و تغییرات چگونه مدیریت خواهند شد؟ | | هزینه | هزینه های خرید، مجوز، پشتیبانی، آموزش و خروج چقدر است؟ | از تامین کننده می خواهم به جای ارسال اطلاعات کلی محصول، به موارد استفاده خاص پاسخ دهد. "آیا این می تواند از کسب و کار ما حمایت کند؟" بیش از حد گسترده است "آیا 40 کاربر راه دور می توانند در حین اجرای پشتیبان گیری شبانه به سیستم اسناد دسترسی داشته باشند؟" پاسخ مفیدتری تولید می کند. دیدگاه من ساده است: یک تصمیم زیرساختی باید بر اساس میزان حمایت از کار روزانه، تقاضای آینده و بهبودی از اختلال قضاوت شود. مشخصات بالا به طور خودکار طراحی خوبی ایجاد نمی کند. انتخاب صحیح ظرفیت، سازگاری، امنیت و عملیات عملی را به هم متصل می کند. بررسی این سه مشخصات قبل از تایید به تیم تصویر واضح‌تری از آنچه که سیستم می‌تواند پشتیبانی کند، محدودیت‌های آن کجاست و سوالاتی که هنوز نیاز به پاسخ دارند، می‌دهد. علاقه مند به یادگیری بیشتر در مورد روندها و راه حل های صنعت هستید؟ با ژان تماس بگیرید: 458602957@qq.com/WhatsApp +8618555395111.

مراجع Google، 2016، مهندسی قابلیت اطمینان سایت: چگونه Google سیستم‌های تولید را اجرا می‌کند موسسه ملی استانداردها و فناوری، می 2010، راهنمای برنامه‌ریزی احتمالی برای سیستم‌های اطلاعات فدرال خدمات وب آمازون، اکتبر 2023، چارچوب خوش‌معماری AWS Microsoft، 2024، Azure Frame Well-Architected Linux, N. مارتین کلپمن، 2017، طراحی برنامه های کاربردی داده فشرده