تأسست عام 2008 · النسخة الرقمية · 19 يونيو 2026

SMB IT Journal

مورد تقنية المعلومات للشركات الصغيرة

العربية
البنية التقنية

البيض الافتراضي والسلال

في حواراتي مع متخصصي تكنولوجيا المعلومات في الشركات الصغيرة، يبرز أحد العوامل الرئيسية للتردد في نشر الافتراضية، ويتمثل فيما يُعبَّر عنه بـ"لا تضع كل بيضك في سلة واحدة".

أفهم من أين ينبثق هذا القلق. تتيح الافتراضية احتواء أنظمة تشغيل ضيفة عديدة في نظام مادي واحد، مما قد يؤدي عند حدوث عطل في الأجهزة إلى تعطل جميع الأنظمة الضيفة المتواجدة عليه معاً ودفعةً واحدة. يبدو هذا أمراً سيئاً، لكن ربما لا يكون بالسوء الذي نتصوره للوهلة الأولى.

فكرة المثل الخاص بالبيض والسلال تقوم على أننا لا ينبغي تعريض جميع مواردنا للخطر في الوقت ذاته. يُطبَّق هذا عادةً في مجال الاستثمار، حيث يُشجَّع المستثمرون على التنويع والاستثمار في شركات مختلفة وأنواع متعددة من الأوراق المالية كالسندات والأسهم والصناديق والسلع. في حالة البيض (أو المال) نتحدث عن سلعة قابلة للتبادل. كل بيضة تساوي الأخرى. مجموعة البيض متكررة بطبيعتها.

إذا كان لدينا دزينة من البيض وكسرنا ستاً منها، يمكننا مع ذلك صنع عجة، ربما أصغر حجماً، لكننا سنأكل على أي حال. أكل عجة أصغر يكاد يكون مُرضياً بالقدر ذاته – لن نعاني من الجوع في كلتا الحالتين. وضع بيضنا المتكرر أصلاً في سلال متعددة يتيح لنا التحوط. نعم، حمل سلتين يعني أننا نولي اهتماماً أقل لكل منهما مما يزيد خطر فقدان بعض البيض، لكنه يُقلل من احتمال فقدان كل البيض. في حالة البيض، هذا اقتراح حكيم بالفعل. وكذلك طريقة ذكية للتخطيط للتقاعد.

هذه النظرية، لأنها تُردد كمثل دون تحليل دقيق أو فهم صحيح، تُطبَّق على مجالات غير ذات صلة كافتراضية الخوادم. غير أن الخوادم لا تشبه البيض. الخوادم، ولا سيما في الشركات الصغيرة، نادراً ما تكون سلعاً قابلة للتبادل حيث يكفي وجود ستة منها عاملة بدلاً من الاثني عشر المعتادة. في الغالب يضطلع كل خادم بدور فريد وكلها حرجة نسبياً لسير عمل الشركة. إذا لم يكن الخادم حرجاً، فمن غير المرجح أن يكون قادراً على تبرير تكلفة اقتنائه وصيانته في المقام الأول، وبالتالي لن يوجد أصلاً. حين تكون الخوادم قابلة للتبادل، كما في حالة مزارع الويب عديمة الحالة أو مجموعات الحوسبة الكبيرة، تكون مُهيأة بهذه الطريقة كوسيلة لتوسيع السعة ما وراء حدود صندوق مادي واحد، وبذلك تخرج عن نطاق هذا النقاش.

خدمات تكنولوجيا المعلومات في الشركة عادةً، على الأقل في بعض جوانبها، "تبعية سلسلية". أي أنها مترابطة، وقد يؤثر فقدان خدمة واحدة على خدمات أخرى إما لأنها مترابطة تقنياً (كاعتماد تطبيق تجاري على قاعدة بيانات) أو لأنها مترابطة في سير العمل (كحاجة موظف مكتبي إلى خادم الملفات ليزوده بملف يحتاج إلى تحريره بمعلومات من بريد إلكتروني بينما يناقش التغييرات عبر الهاتف أو المراسلة الفورية). في هذه الحالات، قد يتسبب فقدان خدمة رئيسية واحدة كالبريد الإلكتروني أو المصادقة على الشبكة أو خدمات الملفات في خسارة غير متناسبة في القدرة على العمل. إذا كانت ثمة عشر خدمات رئيسية وتعطلت إحداها، فإن إنتاجية الشركة من منظور خدمات تكنولوجيا المعلومات ستنخفض على الأرجح بنسبة تفوق عشرة بالمئة بكثير، وقد تقترب من مئة بالمئة في الحالات القصوى. هذا ليس حتمياً دائماً، ففي حالات فريدة يستطيع العمال "التحايل" على الخدمة المعطلة بفاعلية، لكن هذا نادر جداً. حتى إن ظل الناس قادرين على العمل، من المرجح أن إنتاجيتهم ستقل كثيراً عن المعتاد.

عند التعامل مع خوادم مادية، كل خادم يمثل نقطة عطل بحد ذاتها. لذا إذا كان لدينا عشرة خوادم، لدينا عشرة أضعاف احتمالية التوقف عما لو كان لدينا خادم واحد من تلك الخوادم. كل خادم نضيفه يجلب معه مخاطره الخاصة. إذا كان لكل عطل معامل توقف يساوي 2.5 – أي تأثير مالي على الشركة بمقدار خمسة وعشرين بالمئة من الإيرادات، لمدة يوم واحد مثلاً، فإن إجمالي متوسط الأثر على مدى عقد يعادل ما مجموعه توقفات كاملة للموقع بمقدار اثنين ونصف. أستخدم هنا مفهوم المعاملات والمتوسطات لتبسيط الأمر؛ لا داعي لتحديد مدة التوقف المتوسط أو أثره لأننا نحتاج فقط إلى تحديد الأثر النسبي لمقارنة السيناريوهات. إنه مجرد وسيلة لمقارنة الأثر المالي التراكمي لنوع حدث واحد بآخر دون الحاجة إلى أرقام محددة – هذا لن يساعدك في تحديد ميزانيتك، لكنه يوضح الموثوقية النسبية.

مع الافتراضية نمتلك القدرة الواضحة على الدمج. في هذا المثال، سنفترض أنه بمقدورنا تركيز هذه الخوادم العشر الموجودة على خادم واحد. حين نفعل ذلك كثيراً ما يُستثار رد فعل "كل بيضنا في سلة واحدة". لكننا إذا أجرينا بعض تحليل المخاطر سنجد أن هذا في الغالب مجرد خوف وقلق لا يستند إلى تقييم رياضي للمخاطر. وبافتراض المخاطر ذاتها كما في المثال أعلاه، سيتكبد خادمنا المنفرد في المتوسط توقفاً كاملاً واحداً للموقع مرة كل عقد.

قارن ذلك بالمثال الأول الذي كان أثره معادلاً لتوقفات كاملة للموقع بمقدار اثنين ونصف – فمخاطر الحل الافتراضي الموحد لا تتجاوز أربعين بالمئة من مخاطر الحل التقليدي.

ضع في اعتبارك أن هذا مبني على افتراض أن فقدان بعض الخدمات يعني خسارة مالية تفوق القيمة الصارمة للخدمة التي فُقدت، وهو ما يحدث في الغالب. حتى لو كانت الخدمة المفقودة لا تعادل أكثر من خسارة تلك الخدمة بعينها فنحن في نقطة التعادل ولا داعي للقلق. وفي حالات نادرة قد يكون الأثر الناجم عن فقدان نظام واحد أقل من "حصته من الكعكة"، وهذا عادةً لأن الناس مرنون وقادرون على التعامل مع النظام المعطل – كما لو تعطل برنامج المراسلة الفورية واكتفى الناس بالتحول إلى البريد الإلكتروني حتى يُستعاد، لكن هذه حالات نادرة وعادةً ما تقتصر على عدد قليل من الأنظمة، فيما تُسبب معظم الأنظمة كنظام ERP ونظام CRM والبريد الإلكتروني آثاراً غير متناسبة مع حجمها عند حدوث توقف.

ما نلاحظه هنا إذن هو أنه في الظروف العادية، فإن نقل عشر خدمات من عشرة خوادم إلى عشر خدمات على خادم واحد سيُقلل في الغالب من مخاطرنا لا يزيدها – في تناقض صريح مع نظرية "البيض في السلة". وهذا من منظور أعطال الأجهزة فقط. غير أن الدمج يوفر عدة عوامل موثوقية أخرى مهمة يمكن أن تؤثر تأثيراً بالغاً على حالتنا الدراسية.

مع الدمج نُقلل من حجم الأجهزة التي يجب على قسم تكنولوجيا المعلومات مراقبتها وإدارتها. عدد أقل من الخوادم يعني تخصيص وقت واهتمام أكثر لما تبقى منها. والاهتمام الأكبر يعني فرصة أفضل لاكتشاف المشكلات مبكراً ومزيداً من الفرص للاحتفاظ بالقطع الاحتياطية. أداء المراقبة والصيانة بصورة أفضل يفضي إلى موثوقية أعلى.

غير أن العامل الأهم ربما مع الدمج هو توفير تكاليف ملموس، وهذا إن أُحسن توظيفه يمكن أن يفتح أمامنا فرصاً لتحسين الموثوقية. مع الانخفاض الحاد في إجمالي تكلفة الخوادم قد يكون من المغري الاستمرار في إبقاء الميزانيات ضيقة ومحاولة الاستفادة من وفورات التكلفة مباشرةً. هذا مفهوم، وقد يكون النهج الصحيح لبعض الشركات. لكنه ليس النهج الذي أوصي به حين يكون التحدي هو الخروج من فكرة البيض والسلال.

بدلاً من ذلك، من خلال اعتماد نهج أكثر اعتدالاً يحتفظ بوفورات تكلفة كبيرة مع الإنفاق نسبياً بمقدار أكثر على خادم واحد، يمكنك اقتناء خادم أعلى مستوى (أي أكثر موثوقية)، واستخدام قطع أفضل، وتوفير قطع احتياطية في الموقع وما إلى ذلك. غالباً ما يمكن توظيف وفورات تكلفة الافتراضية مباشرةً في زيادة الموثوقية مما يُرجّح المعادلة أكثر لصالح نهج الخادم الواحد.

كما ذكرت في مقال آخر، بيت من طوب واحد أكثر احتمالاً للصمود في وجه عاصفة من بيت أو بيتين من القش. امتلاك المزيد من شيء ما لا يجعله بالضرورة الخيار الأكثر موثوقية.

تأتي هذه الفوائد بالكامل من جانب الدمج في الافتراضية لا من الافتراضية ذاتها. توفر الافتراضية أيضاً ميزات إضافية للحد من المخاطر بمعزل عن ذلك. تصوير الأنظمة والاستعادة السريعة، فضلاً عن الاستعادة إلى أجهزة مختلفة، من المزايا الرئيسية لأي منصة افتراضية تقريباً. يمكن أن يؤدي هذا دوراً مهماً في استراتيجية التعافي من الكوارث.

بالطبع، هذه المفاهيم جميعها لا تهدف إلا إلى إثبات أن الافتراضية والدمج على صندوق واحد قادران على التفوق على نهج "تطبيق واحد لخادم واحد" التقليدي مع تحقيق وفورات في التكلفة – مما يكشف أن مثال البيض والسلال مُضلل ولا ينطبق على هذا السيناريو. ينبغي ألا يكون ثمة تردد يُذكر في الانتقال من بيئة تقليدية إلى بيئة افتراضية استناداً إلى هذه العوامل.

تجدر الإشارة إلى أن الافتراضية يمكنها بعدئذٍ تعزيز موثوقية الأجهزة الاعتيادية التقليدية بتوفير ميزات تجاوز الفشل شبيهة بالحاسبات الضخمة (Mainframe) وهي ما وراء قدرات المنصات غير الافتراضية. وهذا يُقرّب الأجهزة الاعتيادية من المنصات RISC الأكبر حجماً والأعلى تكلفةً. يمكن لهذه الميزات أن توفر مستوى حماية بالغاً، لكنها كثيراً ما تتجاوز ما هو ملائم لأقسام تكنولوجيا المعلومات التي تنتقل لأول مرة من بيئة خوادم أجهزة قديمة غير مزودة بتجاوز الفشل. التوفر العالي ميزة رائعة لكنها كثيراً ما تكون مكلفة وغير ضرورية في أحيان كثيرة، ولا سيما حين تنتقل الشركات من بيئات يُنظر إليها على أنها أقل موثوقية في الماضي إلى بيئات أكثر موثوقية اليوم. وبما أننا ارتقينا بالفعل بالموثوقية فوق ما كان يُعد ضرورياً في الماضي، فهناك احتمال كبير ألا تكون هناك حاجة ماسة الآن إلى قفزة هائلة في الموثوقية، لكن نظراً للتراجع الكبير في تكلفة التوفر العالي، فمن الممكن أن يكون مبرراً من حيث التكلفة في حين لم يكن كذلك من قبل.

على المنوال ذاته، كثيراً ما تُثار مخاوف من الافتراضية لأنها تُعدّ تقنية جديدة غير مُجربة. هذا بالتأكيد غير صحيح لكن يسود هذا الانطباع في بيئة الشركات الصغيرة وخوادم الأجهزة الاعتيادية. في الواقع، أدخل IBM الافتراضية في الستينيات، ومنذ ذلك الحين استمرت كركيزة لخوادم الحواسيب الضخمة ومنصات RISC عالية المستوى – تلك الأنظمة التي تطالب بأعلى مستويات الموثوقية. في عالم خوادم الأجهزة الاعتيادية كانت الافتراضية تحدياً تقنياً أكبر واستغرقت وقتاً طويلاً قبل أن يمكن تطبيقها بكفاءة كافية لجعلها عملية الاستخدام في العالم الحقيقي. لكن حتى في عالم خوادم الأجهزة الاعتيادية، تتوفر الافتراضية منذ أواخر التسعينيات، فعمرها يقارب خمسة عشر عاماً، وهو بعيد جداً عن أن يكون تقنية ناشئة – في عالم تكنولوجيا المعلومات إنها راسخة ومحترمة. افتراضية المنصات الاعتيادية مجال ناضج يضم عدة موردين يحظون باحترام واسع ومنتجات بالغة التطور. استخدام الافتراضية كمعيار لجميع تطبيقات الخوادم أو كادها نمط مؤسسي راسخ ومقبول منذ أمد بعيد، ونمط يمكن الآن اعتماده بسهولة من قِبل شركات من أي حجم وكل الأحجام.

الافتراضية، وقد تكون هذه مفاجأة، هي في الواقع مكوّن بالغ الأهمية في استراتيجية الموثوقية. بدلاً من إضافة المخاطر، يمكن الاقتراب من الافتراضية بوصفها منصة للحد من المخاطر – أداة لتعزيز موثوقية منصات الحوسبة لديك من خلال مسارات متعددة.

موسوم بـredundancy reliability risk

إعلان

SMB IT Journal — the IT resource for small business