هل بنيتك التحتية جاهزة للمستقبل؟ تحقق من هذه المواصفات الثلاثة

قد يعمل النظام بشكل جيد اليوم ولا يزال يعاني عندما تنمو حركة المرور، أو تفشل الخدمة، أو يحتاج الفريق إلى إصدار التغييرات بوتيرة أسرع. لقد رأيت أن مراجعات البنية التحتية تركز على حجم الخادم بينما تغفل المجالات التي تخلق أكبر المخاطر: القدرة المحدودة، وخطط الاسترداد الضعيفة، وضعف الرؤية لسلوك النظام. لا يحتاج الإعداد الجاهز للمستقبل إلى استخدام كل التقنيات الجديدة. يجب أن يتعامل مع التغيير بأقل قدر من الاضطراب. هذه المواصفات الثلاثة تعطيني نقطة انطلاق عملية. 1. القدرة التي يمكن أن تنمو بدون إعادة بناء كاملة أتحقق من كيفية استجابة البنية التحتية عندما يرتفع الطلب. تتضمن المراجعة المفيدة ما يلي: - مساحة رأس وحدة المعالجة المركزية والذاكرة - نمو التخزين وسعة النسخ الاحتياطي - عرض النطاق الترددي للشبكة - حدود اتصال قاعدة البيانات - قواعد القياس التلقائي - سعة موازن التحميل - تغييرات التكلفة عند مستويات الاستخدام الأعلى قد لا يترك النظام الذي يعمل بنسبة 85% من وحدة المعالجة المركزية أثناء ساعات العمل العادية مجالًا كبيرًا لزيادة حركة المرور. يمكن أن تؤدي الحملة المفاجئة أو إطلاق المنتج أو الطلب الموسمي إلى دفع الخدمة إلى استجابات بطيئة أو طلبات فاشلة. أنا أيضا أنظر إلى نموذج القياس. يعني القياس الرأسي إضافة المزيد من الطاقة إلى جهاز واحد. يعني القياس الأفقي إضافة المزيد من الأجهزة أو مثيلات الخدمة. يمكن أن يدعم القياس الأفقي النمو بشكل أكثر مرونة، ولكن فقط عندما يدعمه التطبيق وقاعدة البيانات ومعالجة الجلسة وعملية النشر. يمكن لاختبار بسيط للقدرة أن يكشف عن الفجوات: 1. سجل حركة المرور العادية وحركة المرور القصوى. 2. قم بزيادة حمل الاختبار بخطوات صغيرة. 3. تتبع وقت الاستجابة ومعدل الأخطاء ووحدة المعالجة المركزية والذاكرة واستخدام قاعدة البيانات. 4. تحقق مما إذا كانت المثيلات الجديدة تبدأ كما هو متوقع. 5. قم بمراجعة التكلفة عند كل مستوى تحميل. 6. حدد نقطة واضحة للمراجعة اليدوية. على سبيل المثال، قد يتعامل متجر عبر الإنترنت مع 500 طلب في الدقيقة خلال الفترة العادية و2000 أثناء العرض الترويجي. إذا تم اختبار النظام عند 600 طلب في الدقيقة فقط، فإن الفريق يتخذ قرارات بأدلة محدودة. يمكن أن يُظهر اختبار التحميل المتحكم فيه ما إذا كانت المشكلة تأتي من خوادم التطبيقات، أو استعلامات قاعدة البيانات، أو حدود الشبكة، أو خدمة خارجية. ويجب أن يتضمن تخطيط القدرات أيضًا البيانات. غالبًا ما يتزايد حجم التخزين بهدوء حتى تصبح نوافذ النسخ الاحتياطي طويلة جدًا أو يبدأ أداء قاعدة البيانات في الانخفاض. أفضل تتبع النمو الشهري وتقدير الـ 12 إلى 24 شهرًا القادمة. لن يكون التقدير دقيقًا، لكنه يمنح الفريق الوقت للتخطيط. 2. أهداف الاسترداد التي تتوافق مع الأعمال النسخ الاحتياطية لا تساوي خطة الاسترداد. أتحقق من اثنين من المواصفات: - هدف وقت الاسترداد (RTO): المدة التي يمكن أن تظل فيها الخدمة غير متاحة - هدف نقطة الاسترداد (RPO): مقدار البيانات الحديثة التي يمكن أن تقبل الشركة فقدانها قد تقبل أداة داخلية صغيرة RTO لعدة ساعات. قد يتطلب نظام الدفع أو الطلب فترة استرداد أقصر. يعتمد الهدف الصحيح على تأثير الأعمال واحتياجات العملاء والتكلفة التشغيلية والحدود الفنية. يجب أن تجيب خطة الاسترداد على الأسئلة العملية: - أين يتم تخزين النسخ الاحتياطية؟ - كم مرة يتم إنشاء النسخ الاحتياطية؟ - هل النسخ الاحتياطية منفصلة عن البيئة الرئيسية؟ - من يستطيع استعادة النظام؟ - كم من الوقت يستغرق الترميم؟ - كيف يتم التحقق من تغييرات البيانات بعد الاسترداد؟ - ماذا يحدث إذا كانت المنطقة الأساسية أو مركز البيانات غير متوفر؟ - متى كان آخر اختبار للتعافي؟ قد يقوم الفريق بالإبلاغ عن النسخ الاحتياطية اليومية، ومع ذلك قد تفقد الشركة يومًا من المعاملات إذا تعذر استعادة النسخة الاحتياطية الأخيرة. أتعامل مع اختبار الاستعادة كجزء من المواصفات، وليس كتمرين اختياري. يمكن أن يتبع اختبار الاسترداد المفيد هذا النمط: 1. حدد بيئة اختبار منخفضة المخاطر. 2. استعادة نسخة احتياطية حديثة. 3. قياس الوقت اللازم. 4. التحقق من وظائف التطبيق واتساق البيانات. 5. تسجيل الأعطال والخطوات غير الواضحة. 6. قم بتحديث دليل التشغيل. 7. كرر الاختبار على فترات زمنية مخطط لها. لقد أظهرت حالات انقطاع الخدمة السحابية العامة لماذا يمكن لموقع واحد أن يخلق مخاطر تشغيلية. قد يؤدي التصميم متعدد المناطق إلى تقليل هذه المخاطر، ولكنه يجلب أيضًا تكلفة أعلى ومعالجة أكثر تعقيدًا للبيانات. يجب أن يعكس الاختيار متطلبات الخدمة بدلاً من التفضيل العام لمزيد من المناطق. وأتساءل أيضًا عما إذا كان بإمكان الفريق التعافي بدون الشخص الذي أنشأ النظام الأصلي. إذا كانت الإجابة لا، فإن التوثيق يحتاج إلى عمل. 3. المراقبة التي توضح ما يختبره المستخدمون يمكن أن تبدو البنية التحتية سليمة بينما يواجه العملاء صفحات بطيئة أو معاملات فاشلة. تعتبر مقاييس وحدة المعالجة المركزية والذاكرة مفيدة، لكنها لا تحكي القصة الكاملة. أريد أن أرى: - زمن استجابة الطلب، بما في ذلك قيم p95 أو p99 - معدلات الخطأ - التوفر - عمق قائمة الانتظار - وقت استعلام قاعدة البيانات - أداء ذاكرة التخزين المؤقت - عمليات النشر الفاشلة - الاتصالات المشبعة - معدلات نجاح معاملات المستخدم يمكن للمتوسطات إخفاء المشكلات. إذا كانت معظم الطلبات تستغرق 100 مللي ثانية بينما تستغرق مجموعة أصغر 8 ثوانٍ، فقد يبدو المتوسط ​​مقبولاً. توفر البيانات المئوية رؤية أفضل للطلبات الأبطأ. يجب أن تساعد السجلات الفريق في الإجابة على ثلاثة أسئلة: 1. ماذا حدث؟ 2. ما هي الخدمة التي تسببت في ذلك؟ 3. ما هي المستخدمين أو المعاملات التي تأثرت؟ يمكن أن يؤدي معرف الطلب الذي يتبع المعاملة عبر الخدمات إلى تقليل وقت التحقيق. يجب أن تشير التنبيهات أيضًا إلى الإجراء المحتمل. يقدم التنبيه الذي يشير إلى "ارتفاع وحدة المعالجة المركزية" إرشادات محدودة. التنبيه الذي يربط وحدة المعالجة المركزية العالية بأخطاء الدفع المتزايدة والنشر الأخير يمنح الفريق سياقًا أكثر فائدة. أوصي بمراجعة جودة التنبيه بعد وقوع الحوادث. إذا تلقى الفريق العديد من التنبيهات ولكنه أخطأ في التأثير على العملاء، فإن إعداد المراقبة يحتاج إلى تعديل. إذا لم يظهر أي تنبيه أثناء فشل معروف، فيجب توثيق الفجوة واختبارها. ينتمي الأمان إلى هذه المراجعة أيضًا. أتحقق من أذونات الوصول والتخزين السري وإجراءات التصحيح وعناصر التحكم في الشبكة وسجلات التدقيق. لا تحل عمليات التحقق هذه محل التقييم الأمني ​​الكامل، ولكنها يمكن أن تكشف عن نقاط الضعف الأساسية في العمليات اليومية. يمكن للمراجعة العملية أن تسجل كل مواصفات من 1 إلى 5: - 1: لا توجد خطة واضحة أو قياس موثوق - 2: توجد بعض الأدوات، ولكن الاختبار محدود - 3: تعمل العملية في ظل الظروف العادية - 4: تم اختبار العملية تحت الضغط - 5: يتم اختبار العملية وتوثيقها ومراجعتها مع تغير النظام وتكون النتيجة أقل فائدة من الأدلة التي تدعمها. يجب أن يكون الفريق قادرًا على عرض نتائج اختبار القدرات واستعادة السجلات ومراقبة لوحات المعلومات ودفاتر التشغيل المحدثة. عندما أقوم بتقييم البنية التحتية، لا أسأل ما إذا كانت تستخدم أحدث منصة. أسأل ما إذا كان بإمكانه دعم النمو المتوقع، والتعافي خلال فترة متفق عليها، وإظهار للفريق ما يواجهه المستخدمون. إذا كانت الإجابة غير واضحة، فإن الخطوة التالية ليست إعادة بناء كاملة. ابدأ بالقياسات، واختبر المناطق الضعيفة، وقم بتحسين الجزء الذي يحمل أكبر مخاطر العمل.

تكتشف العديد من فرق البنية التحتية حدود أنظمتها أثناء إطلاق المنتج، أو زيادة حركة المرور، أو حدث أمني. نادرا ما تكون المشكلة خادم واحد. غالبًا ما يكون ذلك مزيجًا من بطء التوسع وخطط التعافي الضعيفة والرؤية المحدودة لسلامة النظام. أحكم على البنية التحتية من خلال ثلاث مواصفات عملية: مدى نجاحها في التوسع، ومدى سرعة تعافيها، ومدى وضوح رؤية الفريق لما يحدث. تساعدني هذه الإجراءات في فصل النظام الذي يعمل اليوم فقط عن النظام الذي يمكنه دعم احتياجات العمل المتغيرة. 1. سعة مرنة تتوافق مع الطلب يمكن للبنية التحتية الجاهزة للمستقبل إضافة الموارد أو تحريرها مع تغير الطلب. قد يتضمن ذلك مثيلات الحوسبة أو الحاويات أو سعة قاعدة البيانات أو التخزين أو النطاق الترددي للشبكة. إنني أتطلع إلى ما هو أبعد من مجرد تسمية بسيطة "قائمة على السحابة". الأسئلة المفيدة أكثر تحديدًا: - هل يستطيع النظام التعامل مع الزيادة المفاجئة في حركة المرور؟ - كم من الوقت يستغرق التحجيم؟ -- هل يمكن أن يتقلص عندما ينخفض ​​الطلب؟ - هل تتناسب قاعدة البيانات مع طبقة التطبيق؟ - هل تستند قواعد القياس إلى إشارات مفيدة، مثل الطلبات في الثانية أو طول قائمة الانتظار؟ قد تتلقى شركة البيع بالتجزئة حركة مرور ثابتة خلال معظم أيام العام، ثم تشهد زيادة حادة خلال حملة موسمية. إذا توسعت خوادم الويب ولكن ظلت قاعدة البيانات ثابتة، فقد يظل المستخدمون يواجهون صفحات بطيئة أو أوامر فاشلة. لن تؤدي إضافة المزيد من خوادم التطبيقات إلى حل اختناق قاعدة البيانات. أفضّل اختبارات القدرات التي تعكس أنماط العمل العادية. يمكن للفريق اختبار حركة المرور المنتظمة، وحركة المرور القصوى، والقفز المفاجئ في حركة المرور. يجب أن يتتبع الاختبار وقت الاستجابة ومعدل الخطأ واستخدام الموارد والتكلفة. قد يكون الهدف المفيد هو: - 95% من الطلبات تستجيب خلال 300 مللي ثانية في ظل التحميل العادي - تظل معدلات الخطأ أقل من حد العمل المتفق عليه أثناء ذروة التحميل - تصبح سعة التطبيق الجديدة متاحة خلال فترة محددة - تظل اتصالات قاعدة البيانات ضمن نطاق التشغيل الآمن - تعتمد الأرقام الدقيقة على الخدمة. ما يهم هو أن الفريق يحددها قبل حدوث المشكلة. 2. الاسترداد الذي تم اختباره، وليس فقط توثيقه تكون خطة النسخ الاحتياطي ذات قيمة فقط عندما يتمكن الفريق من استعادة الخدمة. ألقي نظرة على قياسين: - هدف وقت الاسترداد: المدة التي يمكن أن تظل فيها الخدمة غير متاحة - هدف نقطة الاسترداد: مقدار البيانات الحديثة التي يمكن أن تتحمل الشركة خسارتها قد تحتاج منصة الدفع إلى نقطة استرداد يتم قياسها بالدقائق. قد تقبل أداة إعداد التقارير الداخلية نافذة أطول. الهدف الصحيح يأتي من تأثير الأعمال، وليس من القالب. قد يتضمن تصميم الاسترداد العملي ما يلي: - النسخ الاحتياطية التلقائية - النسخ المخزنة في موقع منفصل - البيانات المنسوخة عبر المناطق أو المناطق المتاحة - خطوات الاسترداد الموثقة - ضوابط الوصول لأنظمة النسخ الاحتياطي - اختبارات الاستعادة المنتظمة اكتشف بائع تجزئة متوسط ​​الحجم عبر الإنترنت ذات مرة أثناء تمرين الاسترداد أن النسخ الاحتياطية الخاصة به قد اكتملت، ولكن عملية الاستعادة تعتمد على المسؤول الذي كان بعيدًا. الملفات كانت موجودة. لا تزال الخدمة غير قادرة على العودة في الموعد المحدد. بعد التمرين، قام الفريق بتعيين مالكين واضحين، وتخزين تعليمات الاسترداد مع نظام النسخ الاحتياطي، واختبار الاستعادة كل ثلاثة أشهر. يكشف هذا النوع من الاختبارات عن الفجوات التي غالبًا ما تفوتها المستندات. تعتبر عملية الاستعادة الفاشلة أمرًا غير مريح، ولكنها تمنح الفريق مكانًا آمنًا لإصلاح العملية. أتحقق أيضًا مما إذا كان الاسترداد يغطي أكثر من الخوادم. قد تعتمد التطبيقات على DNS وخدمات الهوية والشهادات وقوائم انتظار الرسائل وواجهات برمجة التطبيقات التابعة لجهات خارجية وبيانات اعتماد قاعدة البيانات. يجب أن توضح خطة الاسترداد كيفية عمل هذه الأجزاء معًا. 3. إمكانية الملاحظة التي تربط الإشارات بالعمل تنتج البنية التحتية كمية كبيرة من البيانات. تساعد إمكانية المراقبة المفيدة الأشخاص على فهم تلك البيانات والاستجابة لمشكلات الخدمة. أتوقع ثلاثة أنواع من الإشارات: - المقاييس: زمن الاستجابة، وحركة المرور، ومعدل الخطأ، واستخدام وحدة المعالجة المركزية، واستخدام الذاكرة، وعمق قائمة الانتظار - السجلات: أحداث التطبيق، وسجلات الوصول، وتنبيهات الأمان، ورسائل النظام - الآثار: مسار الطلب عبر الخدمات لوحة المعلومات المليئة بالمخططات لا تعمل على تحسين العمليات تلقائيًا. يحتاج الفريق إلى مؤشرات خدمة واضحة وتنبيهات مفيدة. على سبيل المثال، قد لا يحتاج التنبيه بشأن الاستخدام المرتفع لوحدة المعالجة المركزية إلى اتخاذ إجراء فوري إذا ظلت أوقات الاستجابة مستقرة. إن الارتفاع في عمليات الدفع الفاشلة يستحق الاهتمام حتى عندما تبدو سعة الخادم طبيعية. أقوم بربط التنبيهات بتأثير العملاء كلما أمكن ذلك. يجيب إعداد المراقبة القوي على أسئلة مثل: - ما هي الخدمة المتأثرة؟ - متى بدأت المشكلة؟ - ما المستخدمين أو المناطق التي ترى المشكلة؟ - ما الذي تغير قبل ظهور المشكلة؟ - من يملك الإجراء التالي؟ - هل المشكلة تتزايد أم تتعافى؟ يمكن لشركة برمجيات استخدام تتبع الطلب لتكتشف أن صفحة الدفع البطيئة لا تنتج عن خادم الويب. قد يأتي التأخير من خدمة توصية المنتج أو من مزود دفع خارجي. هذا المستوى من التفاصيل يقلل من التخمين ويساعد الفريق على التركيز على العنصر الصحيح. يجب أن تتضمن إمكانية الملاحظة أيضًا إشارات التكلفة والأمن. يمكن أن يشير النمو غير المتوقع في مساحة التخزين، ونشاط تسجيل الدخول غير المعتاد، والزيادة الحادة في نقل البيانات إلى مخاوف تشغيلية أو أمنية. أستخدم هذه المواصفات الثلاثة كقائمة مراجعة عملية: 1. اختبار القدرة في ظل الطلب العادي والذروة والمفاجئ. 2. تحديد وقت الاسترداد وحدود فقدان البيانات لكل خدمة. 3. قم بإجراء تمارين الاستعادة وتسجيل النتائج. 4. تتبع مؤشرات الخدمة التي يواجهها المستخدم. 5. ربط التنبيهات بأصحابها وخطوات الاستجابة. 6. قم بمراجعة تكلفة البنية التحتية، والوصول، وتغييرات التبعية. لا يحتاج النظام إلى كل أداة جديدة لدعم النمو المستقبلي. فهي تحتاج إلى قدرة كافية لتلبية الطلب المتوقع، وعملية تعافي يمكن للناس القيام بها، ومعلومات واضحة عندما تتغير الظروف. عندما أقوم بمراجعة البنية التحتية، أطرح سؤالاً مباشرًا واحدًا: هل يستطيع الفريق شرح ما سيحدث عندما يرتفع الطلب، أو تفشل التبعية، أو يجب استعادة البيانات؟ إذا كانت الإجابة تعتمد على التخمين، فقد يحتاج النظام إلى مزيد من التحضير قبل التغيير الرئيسي التالي في العمل.

تبدو العديد من خطط البنية التحتية سليمة على الورق، ولكنها لا تزال تسبب مشاكل بعد مرور عام. يمتلئ التخزين بشكل أسرع من المتوقع. يحتاج التطبيق الجديد إلى واجهة مختلفة. تضيف أدوات الأمان حملاً إضافيًا على الأنظمة القديمة. ومن ثم تقضي الفرق وقتًا أطول في تحديد الحدود بدلاً من تحسين العمل. أقوم بمراجعة ثلاث مواصفات قبل الموافقة على الخادم أو البيئة السحابية أو ترقية الشبكة أو النظام الأساسي للتخزين: - السعة والأداء - التوافق والتكامل - الأمان والتحكم التشغيلي. تساعدني هذه المجالات في تحديد ما إذا كان قرار البنية التحتية يمكنه دعم الاحتياجات المستقبلية دون الدفع مقابل ميزات لن تستخدمها الشركة. ## 1. السعة والأداء أبدأ بالتحقق من أداء النظام في ظل الاستخدام العادي وتحت الضغط. قد تدرج ورقة المواصفات سرعة المعالج أو الذاكرة أو حجم التخزين أو النطاق الترددي للشبكة أو حدود المثيلات السحابية. هذه الأرقام مهمة، لكنها لا تحكي القصة بأكملها. ألقي نظرة أيضًا على: - مستويات الاستخدام الحالية - ذروة الطلب - نمو المستخدم المتوقع - نمو البيانات - متطلبات النسخ الاحتياطي - تغييرات عبء العمل - الأداء أثناء الصيانة أو الفشل قد تعمل الشركة التي تضم 80 موظفًا بشكل جيد على خادم الملفات الحالي الخاص بها. هذا لا يعني أن نفس الخادم سيدعم بوابة عملاء جديدة وملفات تصميم أكبر ووظائف التحليلات اليومية. أفضل تسجيل ثلاثة أرقام: 1. متوسط ​​الاستخدام الحالي 2. ذروة الاستخدام خلال فترات الانشغال 3. الاستخدام المتوقع خلال دورة التخطيط التالية على سبيل المثال، قد يستخدم بائع تجزئة صغير عبر الإنترنت 55% من سعة قاعدة البيانات الخاصة به في يوم عادي ويصل إلى 85% خلال العروض الترويجية الشهرية. إذا تمت إضافة قناة مبيعات جديدة، فقد يصل النظام إلى الحد الأقصى في وقت أقرب مما يتوقعه الفريق. إن مراجعة الرقم المتوسط ​​فقط من شأنه أن يخفي نقطة الضغط. أتحقق أيضًا من كيفية تحجيم المنصة. هل يمكنني إضافة ذاكرة؟ هل يمكن توسيع التخزين دون انقطاع طويل؟ هل يمكن للخدمة السحابية زيادة سعة الحوسبة من خلال عملية واضحة؟ هل تدعم الشبكة المزيد من الأجهزة وحركة مرور أعلى؟ يترك التصميم المفيد مجالًا للنمو مع إبقاء التكلفة مرئية. إن شراء سعة أكبر بكثير مما يمكن أن تستخدمه الشركة يمكن أن يخلق مشكلة خاصة بها من خلال ارتفاع تكاليف الترخيص والطاقة والدعم والإدارة. ## 2. التوافق والتكامل نادرًا ما تعمل البنية التحتية بمفردها. فهو يتصل بالتطبيقات وأنظمة الهوية وأدوات المراقبة ومنصات النسخ الاحتياطي وخدمات الدفع وأجهزة الموظفين. أقوم بمراجعة التوافق قبل النظر إلى الميزات الإضافية. قد يكون للمنتج مواصفات قوية ويستمر في إحداث تأخيرات إذا لم يتمكن من الاتصال بالأنظمة الموجودة بالفعل. تتضمن قائمة المراجعة الخاصة بي ما يلي: - دعم نظام التشغيل - متطلبات التطبيق - دعم واجهة برمجة التطبيقات والبروتوكول - خيارات الهوية والوصول - معايير الشبكة - توافق النسخ الاحتياطي - دعم المراقبة والتنبيه - خيارات تصدير البيانات - فترات دعم البائع يستحق تصدير البيانات اهتمامًا وثيقًا. إذا كانت الخدمة تجعل من الصعب استرداد بيانات العمل، فقد تواجه الشركة مشكلات أثناء الترحيل أو تغيير العقد. أسأل عن التنسيق الذي تستخدمه البيانات، والمدة التي تستغرقها عملية التصدير، وما إذا كانت عملية التصدير تتضمن الإعدادات والسجلات وسجلات الوصول. والمثال الواقعي هو انتقال الشركة من تخزين الملفات المحلية إلى التخزين السحابي. قد تعمل خدمة التخزين بشكل جيد مع المستندات المكتبية، ولكن قد يعتمد فريق التصميم على ملفات كبيرة أو أذونات خاصة أو برامج تتوقع مسار شبكة محلية. إذا تم تفويت هذه التفاصيل، فقد يواجه الموظفون وصولاً بطيئًا أو سير عمل معطلاً. أقوم باختبار الاتصال مع مجموعة صغيرة قبل إجراء تغيير أوسع. يجب أن يشمل الاختبار مستخدمًا عاديًا ومسؤولًا وعاملًا عن بعد ونظامًا يتبادل البيانات مع النظام الأساسي. غالبًا ما تكشف تعليقاتهم عن المشكلات التي لا تظهرها المواصفات الفنية. التوافق يشمل أيضًا الأشخاص. يمكن للنظام الذي يتطلب خطوات يدوية معقدة أن يزيد من طلبات الدعم ويؤدي إلى نتائج غير متناسقة. تساعد مسارات العمل الواضحة البنية التحتية على البقاء مفيدة بعد مغادرة فريق التثبيت. ## 3. الأمن والتحكم التشغيلي يجب أن يكون الأمن جزءًا من مراجعة المواصفات، وليس عنصرًا يضاف بعد الشراء. أتحقق من كيفية تعامل النظام مع الهوية والأذونات والتشفير والتحديثات والسجلات والنسخ الاحتياطية والاسترداد. وأسأل أيضًا من يمكنه تغيير الإعدادات وكيف يتم تسجيل هذه التغييرات. تشمل الأسئلة الرئيسية ما يلي: - هل تدعم المنصة المصادقة متعددة العوامل؟ - هل يمكن تعيين الوصول حسب الدور؟ - هل من السهل تعطيل الحسابات غير المستخدمة؟ - هل يتم تسجيل إجراءات المسؤول؟ - هل يمكن إرسال السجلات إلى نظام المراقبة الحالي؟ - كيف يتم تسليم التحديثات الأمنية؟ - هل يمكن فصل النسخ الاحتياطية عن أنظمة الإنتاج؟ - كم من الوقت يستغرق التعافي بعد الفشل؟ - هل يستطيع الفريق اختبار التعافي دون التأثير على الخدمات المباشرة؟ تكون النسخة الاحتياطية مفيدة فقط عندما تتمكن الشركة من استعادة البيانات المطلوبة خلال فترة زمنية مقبولة. أطلب من الفريق اختبار نموذج الاسترداد بدلاً من الاعتماد على رسالة حالة تفيد بأن النسخة الاحتياطية قد اكتملت. على سبيل المثال، قد يكون لدى إحدى الممارسات الطبية الصغيرة نسخ احتياطية يومية ولكن لا توجد عملية استرداد تم اختبارها. إذا فشل الخادم الرئيسي، فقد يكتشف الموظفون أن الحساب الاحتياطي لم يعد يعمل أو أنه لم يتم تضمين التطبيق الرئيسي. يمكن لعملية التعافي أن تكشف هذه الفجوات بينما لا تزال الخدمات العادية متاحة. يعتمد التحكم التشغيلي أيضًا على الوثائق. أريد رؤية مخطط النظام وقائمة الملكية وعملية التحديث ومسار التصعيد ودليل الاسترداد. هذه الوثائق لا تحتاج إلى أن تكون طويلة. إنهم بحاجة إلى مساعدة موظف مدرب آخر على فهم ما هو موجود وماذا يفعل عندما تتوقف الخدمة عن العمل. ## عملية مراجعة عملية أستخدم جدول مراجعة بسيطًا لكل مقترح بنية تحتية: | المنطقة | أسئلة للتسجيل | |---|---| | القدرة | ما هو الحمل الحالي وذروة الحمل والنمو المتوقع؟ | | الأداء | ماذا يحدث أثناء فترات الانشغال أو الصيانة أو الفشل الجزئي؟ | | التوافق | ما هي الأنظمة والتطبيقات والأجهزة الحالية التي يجب أن تتصل؟ | | الأمن | كيف يتم التعامل مع الوصول والتحديثات والسجلات والنسخ الاحتياطية والاسترداد؟ | | العمليات | من يملك النظام، وكيف سيتم إدارة التغييرات؟ | | التكلفة | ما هي تكاليف الشراء والترخيص والدعم والتدريب والخروج؟ | أطلب من المورد الرد على حالات استخدام محددة بدلاً من إرسال معلومات عامة عن المنتج فقط. "هل يمكن أن يدعم هذا أعمالنا؟" واسع جدًا. "هل يمكن لـ 40 مستخدمًا عن بعد الوصول إلى نظام المستندات أثناء تشغيل النسخ الاحتياطية الليلية؟" ينتج إجابة أكثر فائدة. وجهة نظري بسيطة: ينبغي الحكم على القرار المتعلق بالبنية الأساسية من خلال مدى دعمه للعمل اليومي، والطلب في المستقبل، والتعافي من الاضطرابات. المواصفات العالية لا تؤدي تلقائيًا إلى إنشاء تصميم جيد. يربط الاختيار الصحيح بين القدرة والتوافق والأمان والعمليات العملية. إن مراجعة هذه المواصفات الثلاثة قبل الموافقة عليها تعطي الفريق صورة أوضح عما يمكن أن يدعمه النظام، وأين حدوده، وما هي الأسئلة التي لا تزال بحاجة إلى إجابات. هل أنت مهتم بمعرفة المزيد عن اتجاهات الصناعة وحلولها؟ اتصل بـ Zhan: 458602957@qq.com/WhatsApp +8618555395111.

المراجع Google، 2016، هندسة موثوقية الموقع: كيف تقوم Google بتشغيل أنظمة الإنتاج، المعهد الوطني للمعايير والتكنولوجيا، مايو 2010، دليل التخطيط للطوارئ لأنظمة المعلومات الفيدرالية Amazon Web Services، أكتوبر 2023، AWS Well-Architected Framework Microsoft، 2024، Azure Well-Architected Framework The Linux Foundation، 2022، إمكانية المراقبة السحابية الأصلية مارتن كليبمان، 2017، تصميم تطبيقات كثيفة البيانات