> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # James Hamilton: من ميكانيكي سيارات إلى مراكز بيانات AWS - URL: https://arabroot.io/articles/جيمس-هاملتون-من-ميكانيكي-سيارات-الى-مراكز-بيانات-aws/ - Published: 2026-10-27T06:42:05.000Z - Updated: 2026-10-30T23:17:27.000Z - Description: قصة James Hamilton من ورشة السيارات إلى تصميم مراكز بيانات AWS، وما تعلمه من انقطاع كهرباء Virginia ومن حساب الكلفة لكل سيرفر. - Author: فريق عرب رووت - Tags: الأدلة التقنية, قصص وتحقيقات, الاستضافة الذاتية في صباح يوم ممطر من أغسطس 2011 انقطعت الكهرباء العامة عن أحد مراكز بيانات Amazon في ولاية Virginia الأمريكية، وكان المفروض أن يحدث ما يحدث في كل انقطاع: تعمل البطاريات لثوان، ثم يدور المولد الاحتياطي ويتولى تغذية الأجهزة، ولا يشعر أحد من العملاء بشيء. وقد دار المولد فعلاً، ولكن الكهرباء لم تصل منه إلى السيرفرات، فبدأت البطاريات تفرغ دقيقة بعد دقيقة. وفي هذه الأثناء كان James Hamilton، المهندس المسؤول عن تصميم مراكز بيانات AWS، في مركز آخر قريب، فوصلته وفريقه التنبيهات وانطلقوا بالسيارة، ووصلوا بعد قرابة 15 دقيقة كما روى بنفسه في [محاضرته في AWS re:Invent 2012](https://www.youtube.com/watch?v=cwPZ6EkwUzs&ref=arabroot.io)، أي في اللحظة التي بدأت فيها السيرفرات بالتوقف صفاً بعد صف، والمولد خارج المبنى يدور بهدوء دون أن يغذي أي جهاز. ولخص الموقف بكلمتين كررهما: «Super annoying». هذا المشهد هو المدخل الذي اختارته مجلة WIRED في [ملفها عن Hamilton سنة 2013](https://www.wired.com/2013/02/james-hamilton-amazon/?ref=arabroot.io) بعنوان «لماذا وظفت Amazon ميكانيكي سيارات ليدير إمبراطوريتها السحابية»، والعنوان ليس مبالغة صحفية، فالرجل عمل فعلاً ميكانيكياً للسيارات الإيطالية الفاخرة قبل أن يصبح كبير معماريي قاعدة بيانات DB2 في IBM، ثم أحد قادة SQL Server في Microsoft، ثم المهندس الذي قاد في AWS قرارات مثل كتابة برنامج لوحات الكهرباء بنفسها، وبناء راوترات خاصة بها، ثم تصميم شرائح Nitro ومعالج Graviton. ولكن ما يجعل قصته مفيدة لنا كمهندسين ليس المسار الوظيفي، وإنما طريقة التفكير التي تظهر في كل محطة: أن تقيس الكلفة لكل وحدة عمل قبل أن تقرر، وأن تفترض أن كل شيء سوف يفشل، وأن تفتح الصندوق الأسود حتى لو كان لوحة كهرباء، وأن تكتب ما تعلمته في العلن. وسوف نناقش في هذا المقال ما يلي: - من هو James Hamilton، وكيف انتقل من ورشة السيارات إلى قواعد البيانات ثم إلى مراكز البيانات. - ورقة «On Designing and Deploying Internet-Scale Services» سنة 2007، ولماذا ما زالت تقرأ حتى اليوم. - ما الذي حدث بالتفصيل في انقطاع Virginia، وكيف يمر مسار الكهرباء من الشبكة العامة إلى السيرفر، ولماذا رفض حاسب صغير داخل لوحة التحويل تشغيل المولد. - لماذا يقول إن الحدث النادر ليس نادراً على الحجم الكبير، وكيف قادت هذه الفكرة إلى مناطق التوافر Availability Zones. - نموذج الكلفة الذي نشره بنفسه، مع تجربة صغيرة نعيد فيها حسابه بلغة Python ونجرب ماذا يحدث إذا تغير سعر الكهرباء أو نسبة الاستغلال. - لماذا تملك AWS العتاد من محطات الكهرباء إلى المعالج، ومتى لا يكون هذا القرار صحيحاً لغيرها. - مدونة Perspectives والقارب Dirona، ثم الدروس وقائمة تحقق لفريق يدير بنيته التحتية. ## من هو James Hamilton؟ تقول [صفحته الشخصية](https://mvdirona.com/jrh/work/?ref=arabroot.io) إنه اليوم نائب رئيس أول ومهندس متميز Senior Vice President and Distinguished Engineer في Amazon، وعضو في S-team وهو فريق القيادة الذي يضم كبار قادة الشركة، وإنه انضم إلى Amazon في يناير 2009 ضمن فريق AWS حيث عمل على كفاءة البنية التحتية وموثوقيتها وتوسع الخدمات، ثم صار دوره على مستوى Amazon كلها. وقبل ذلك عمل 12 سنة في Microsoft، قاد فيها خدمة Exchange Hosted Services وكان مديراً عاماً لفريق SQL Server WebData، وقبلها عمل في IBM حيث قاد فريق مترجم C++ وكان كبير معماريي DB2\. وتذكر الصفحة أيضاً أنه يحمل أكثر من 200 براءة اختراع في أكثر من 20 دولة، وأنه درس علوم الحاسب في جامعة Victoria ثم الماجستير في جامعة Waterloo الكندية. وفي فبراير 2026 أعلن في مدونته [انتخابه عضواً في الأكاديمية الوطنية للهندسة](https://perspectives.mvdirona.com/2026/02/national-academy-of-engineering/?ref=arabroot.io) الأمريكية National Academy of Engineering، وبدأ إعلانه بجملة تلخص شخصيته: «I love all forms of engineering»، أي أنه يحب كل أنواع الهندسة، وهذا ما سوف نراه في القصة: محركات السيارات، ثم محركات قواعد البيانات، ثم المولدات ولوحات الكهرباء، ثم محركات قاربه الذي يعيش عليه. والصورة التالية تبين المحطات التي سوف نمر عليها: ![خط زمني لمسيرة James Hamilton: ميكانيكي سيارات لست سنوات، ثم IBM وكبير معماريي DB2 في الثمانينات، ثم Microsoft لاثنتي عشرة سنة في SQL Server وExchange Hosted Services، وورقة LISA وبداية مدونة Perspectives في 2007، والانضمام إلى AWS في يناير 2009 مع ورقة The Cost of a Cloud، واستلام القارب Dirona في 2010، وانقطاع الكهرباء في مركز Virginia في أغسطس 2011، ومحاضرة Failures at Scale في 2012، وأول شريحة ASIC من AWS في 2016، ومعالج Graviton في 2018، وعضوية الأكاديمية الوطنية للهندسة في 2026](https://arabroot.io/content/images/2026/10/james-hamilton-01-timeline.webp) محطات James Hamilton من ورشة السيارات إلى مراكز بيانات AWS ## ميكانيكي سيارات قبل أن يكون مهندس برمجيات كتب Hamilton في [تدوينة إعلان انتقاله إلى Amazon](https://perspectives.mvdirona.com/2008/12/james-hamilton-joins-amazon-com/?ref=arabroot.io) في ديسمبر 2008 أنه لم يغير عمله إلا ثلاث مرات في 28 سنة: ست سنوات ميكانيكي سيارات، وعشر سنوات في IBM، واثنتا عشرة سنة في Microsoft. وتضيف صفحته الحالية تفصيلاً عن السنوات الأولى، فقد كان ميكانيكياً محترفاً يصلح السيارات الإيطالية والسيارات الفاخرة مثل Maserati وFerrari وLamborghini وAlfa Romeo. ولاحظ أن الصفحة الحالية تذكر 11 سنة في IBM بينما كتب في 2008 عشر سنوات، والفرق غالباً في طريقة عد السنة الأخيرة، ولا يغير شيئاً في القصة. وقد يتساءل البعض: ما علاقة إصلاح السيارات بتصميم مراكز البيانات؟ والإجابة تظهر في كلامه أكثر من سيرته، فهو يتعامل مع مركز البيانات كآلة واحدة لها مسار طاقة ومسار حرارة ونقاط فشل، تماماً كما يتعامل الميكانيكي مع محرك: لا يكفي أن تعرف ماذا يفعل كل جزء، وإنما يجب أن تعرف كيف يفشل، وكم يكلف إصلاحه، وما الذي يتأثر عندما يفشل. ولهذا تجد في محاضراته وصفاً دقيقاً للمولدات لا تجده عادة عند مهندسي البرمجيات، فهو يصفها بأنها محركات ديزل V16 بقوة 4,000 حصان، تصل إلى 1,800 دورة في الدقيقة خلال 7 إلى 8 ثوان، ويقول مازحاً في [محاضرة 2016](https://www.youtube.com/watch?v=AyOAjFNPAbA&ref=arabroot.io) إن وظيفة المولد الاحتياطي ليست وظيفة جيدة فلا تتقدم لها، لأنه يتلقى الاستهلاك Load كله فجأة وبسرعة. وما زال هذا الجانب حاضراً في حياته، ففي موقع قاربه [Dirona](https://mvdirona.com/?ref=arabroot.io) قسم كامل بعنوان Mechanical يكتب فيه عن صيانة المحركات والمولدات على القارب بنفسه، والفكرة التي نأخذها هنا بسيطة: المهندس الذي يعرف كيف تعمل الأشياء الفيزيائية لا يخاف من فتح الصندوق، وهذا بالضبط ما سوف يحتاجه في Virginia. ## IBM وDB2: مدرسة قواعد البيانات تقول WIRED إنه ترك السيارات إلى قواعد البيانات في الثمانينات، وعمل على DB2 في IBM ثم على SQL Server في Microsoft. وقد ذكر Hamilton نفسه في [محاضرة re:Invent 2014](https://www.youtube.com/watch?v=JIQETrFC%5FSQ&ref=arabroot.io) أنه كان كبير المعماريين Lead Architect لـ DB2 حين نقلت إلى أنظمة Unix، أي أنه عاش من الداخل التحول الكبير من الحاسبات المركزية Mainframes إلى سيرفرات Unix، ثم عاشه مرة أخرى في SQL Server مع انتقال العملاء إلى سيرفرات x86\. ويقول إن هذه التحولات الكبيرة نادرة، وإن من يميز مبكراً أي تحول حقيقي يكسب في مسيرته المهنية، وإن ما يميز التحول إلى السحابة هو سرعته. وفي المحاضرة نفسها يذكر تفصيلين تقنيين من تلك السنوات يبينان نوع المشاكل التي تدرب عليها. الأول أنهم كانوا قبل قرابة عشرين سنة يعملون بجهد كبير على مستودع بيانات Data Warehouse يشغل استعلاماً واحداً على 128 عقدة Node بالتوازي ويظهر للمستخدم كأنه قاعدة بيانات واحدة، ويقول إن هذا صعب جداً، وإن الصعب يكون غالياً. والثاني أن DB2 على الحاسبات المركزية كان يستطيع إصلاح الصفحة الممزقة Torn Page، وهي صفحة كتب جزء منها فقط على القرص بسبب انقطاع، من سجل المعاملات Log والقاعدة ما زالت تعمل، بينما تتوقف أغلب قواعد البيانات في هذه الحالة. هذه الخلفية مهمة لفهم كل ما جاء بعدها، فمهندس قواعد البيانات يتعلم مبكراً أن الكتابة على القرص قد تنقطع في منتصفها، وأن المعاملة إما أن تكتمل أو لا تحدث، وأن الاسترجاع بعد الفشل جزء من التصميم وليس إضافة لاحقة. وهو يعترف بانحيازه حين يقول إن قاعدة البيانات هي السبب الأكثر احتمالاً لأن توقظك في منتصف الليل، وإن أصعب المشاكل كلها في الحالة State، فلو لم تكن هناك حالة لشغلنا جميعاً تطبيقات ضخمة بسهولة. ## Microsoft: من بناء قاعدة البيانات إلى تشغيل الخدمة في Microsoft عمل Hamilton سنوات على SQL Server، ثم حدث التحول الذي غير اهتمامه. يحكي في [تدوينة الذكرى الخامسة عشرة لـ EC2](https://perspectives.mvdirona.com/2021/09/happy-15th-birthday-ec2/?ref=arabroot.io) أنه في أوائل 2005 شارك في تقييم تقني لشركة ناشئة تقدم خدمة مستضافة في السحابة قبل الاستحواذ عليها، وتم الاستحواذ فعلاً وأصبح هو المدير العام لها. ويقول إنه تعلم من تشغيلها درسين بسرعة: أن العملاء أحبوا نموذج الخدمة المستضافة وتبنوه بسرعة، وأن الخدمة كانت بعيدة عما هو ممكن، ففيها مشاكل توافرية وكان يرى إمكانية تحسين الكلفة والتوافرية عشرة أضعاف على الأقل. ومنذ 2005 كما يقول لم يعمل إلا على الخدمات السحابية. وفي العام التالي أعلنت Amazon خدمة S3 بسعر 15 سنتاً لكل غيغابايت في الشهر، ويقول إنه عمل في قواعد البيانات والتخزين طوال حياته ويعرف ما هو ممكن، وهذا السعر لم يكن ممكناً في نظره. فكتب تطبيقاً كبيراً نسبياً فوق S3 واختبره شهراً كاملاً قبل أن يعرضه على الرئيس التنفيذي ومدير التقنية في شركته، فجاءت فاتورته 3.08 دولار. ثم حضر لقاءات عملاء AWS في Seattle بعد إطلاق EC2 في أغسطس 2006 ورأى أن العملاء يشغلون أعمالهم كلها عليه مع أن التخزين الدائم لم يكن موجوداً بعد، فوصل إلى قناعة بأنه إذا أراد أن يكون جزءاً من الجيل القادم من الحوسبة فعليه أن يكون في AWS. وخلال هذه السنوات عمل أيضاً مع فريق أبحاث مراكز البيانات، وتقول WIRED إنه كان معمارياً في مجموعة بحثية اسمها Data Center Futures، وإنه بحسب تقارير ذلك الوقت كان من الدافعين نحو مراكز البيانات المعيارية Modular Data Centers المبنية من وحدات جاهزة مثل الحاويات. ويذكر في [تدوينة عن جائزة SIGCOMM](https://perspectives.mvdirona.com/2019/06/2019-acm-sigcomm-test-of-time-award/?ref=arabroot.io) أنه في أواخر 2008 وأوائل 2009 كان يدرس أثر درجات الحرارة العالية على أعطال السيرفرات، والطاقة التي تضيع في المراوح وتسرب التيار عند رفع حرارة الهواء، وأن أهم مشروع شارك فيه حينها كان مشروع الشبكات VL2 في Microsoft Research، والورقة التي خرجت منه فازت بجائزة Test of Time من ACM SIGCOMM سنة 2019. ## ورقة 2007: كيف تصمم خدمة يسهل تشغيلها؟ قبل أن ينتقل إلى AWS نشر Hamilton الورقة التي ما زال كثير من مهندسي التشغيل يعودون إليها: [On Designing and Deploying Internet-Scale Services](https://www.usenix.org/legacy/event/lisa07/tech/full%5Fpapers/hamilton/hamilton.pdf?ref=arabroot.io) في مؤتمر LISA سنة 2007، وكتبها باسم فريق Windows Live Services Platform. وتبدأ الورقة برقم يلخص المشكلة كلها: نسبة السيرفرات إلى مدير الأنظمة الواحد قد تكون 2 إلى 1 في الخدمات الصغيرة قليلة الأتمتة، وقد تصل إلى 2,500 إلى 1 في الخدمات الرائدة. والفرق بين الرقمين في رأيه ليس في أدوات الأتمتة وحدها، وإنما في الخدمة نفسها: هل صممت بحيث يسهل تشغيلها Operations-Friendly، أي تكتشف أغلب الأعطال وتتعافى منها دون أن يتدخل إنسان؟ وتقول الورقة إنها تجمع خبرة سنوات في تشغيل خدمات MSN وWindows Live، وآخرها قيادته لخدمة Exchange Hosted Services التي كانت حينها خدمة متوسطة فيها قرابة 700 سيرفر وأكثر من 2.2 مليون مستخدم، وتستفيد من أبحاث Berkeley في الحوسبة الموجهة للتعافي Recovery-Oriented Computing وأبحاث Stanford في البرمجيات التي تتوقف بالانهيار فقط Crash-Only Software. ### ثلاثة مبادئ قبل كل شيء تنقل الورقة عن زميله Bill Hoffman ثلاثة مبادئ تضعها في أولها، وهي أساس كل ما بعدها: - **توقع الفشل Expect failures:** أي مكون قد يتوقف في أي لحظة، والمكونات التي يعتمد عليها قد تتوقف، والشبكة سوف تفشل، والأقراص سوف تمتلئ، والمطلوب أن تتعامل مع كل ذلك بهدوء. - **اجعل الأشياء بسيطة Keep things simple:** التعقيد يولد المشاكل، والأشياء البسيطة أسهل في أن تكون صحيحة، فتجنب الاعتماديات غير الضرورية، وفشل سيرفر واحد يجب ألا يؤثر على باقي مركز البيانات. - **أتمت كل شيء Automate everything:** لأن البشر يخطئون وينامون وينسون، والعمليات المؤتمتة يمكن اختبارها وإصلاحها، ولذلك هي في النهاية أكثر موثوقية. ثم تقول الورقة إن فريقه يعتقد منذ زمن أن 80% من مشاكل التشغيل تبدأ في التصميم والتطوير، ولهذا كان قسم تصميم الخدمة هو الأكبر فيها، وإن الخدمات الأقل كلفة في الإدارة هي التي يعمل فيها فريق التطوير والاختبار والتشغيل بقرب شديد. وهذه فكرة سبقت كثيراً من النقاش الذي جاء لاحقاً تحت اسم DevOps، وقد شرحنا الفرق بين هذه الأدوار في مقال [الفرق بين DevOps وSRE وPlatform Engineering](https://arabroot.io/articles/%D8%A7%D9%84%D9%81%D8%B1%D9%82-%D8%A8%D9%8A%D9%86-devops-%D9%88-sre-%D9%88-platform-engineering/). ### اختبار الحمض: هل توقف أي سيرفر الآن؟ تحت عنوان صمم للفشل Design for failure تقول الورقة إن الخدمة إذا تجاوزت 10,000 سيرفر و50,000 قرص فإن الأعطال سوف تحدث عدة مرات في اليوم، وإذا كان كل عطل في العتاد يحتاج إلى تدخل فوري من إنسان فلن تتوسع الخدمة بكلفة معقولة. وتنقل عن Armando Fox من Stanford أن أفضل طريقة لاختبار مسار الفشل هي ألا تطفئ الخدمة بالطريقة النظامية أبداً، وإنما أوقفها بالقوة دائماً، لأن مسار الفشل الذي لا يستخدم كثيراً لن يعمل حين تحتاجه. ثم تضع اختباراً بسيطاً يمكنك أن تطبقه اليوم على أي نظام عندك: هل يستطيع فريق التشغيل إيقاف أي سيرفر في الخدمة في أي وقت دون أن ينقل عنه الضغط Load أولاً؟ إذا كانت الإجابة نعم فعندك تكرار متزامن Synchronous Redundancy لا يفقد بيانات، واكتشاف للفشل، وانتقال تلقائي. وإذا كانت الإجابة لا فعندك نقطة فشل واحدة حتى لو لم ترها بعد. وتقترح الورقة أن تعامل الأعطال كما تعامل التهديدات الأمنية في نمذجة التهديدات Threat Modeling: اكتب كل نمط فشل ممكن وكل تركيبة منها، وقرر لكل واحد هل تتحمله الخدمة أم أن خطره مقبول، وتحذر من أن التركيبات «غير المعتادة» من الأحداث تحدث أكثر مما تتوقع حين تشغل آلاف السيرفرات. وهذه الجملة الأخيرة عن التركيبات النادرة هي بالضبط ما سوف يعيشه بعد أربع سنوات في Virginia. ## لماذا انتقل إلى AWS في 2009؟ في ديسمبر 2008 كتب Hamilton في مدونته أنه استقال من Microsoft وسوف ينضم إلى فريق AWS في بداية العام التالي، وقال إنه كتب آلاف الأسطر من الكود فوق S3 كمستخدم، والآن سوف يساعد في تحسينها وتوسيعها. وأضاف أن تغيير العمل يجلب ضغطاً، ولهذا لم يغير عمله إلا ثلاث مرات، وأن التغيير يعلم التواضع، وختم بكلمة واحدة: «Onward!». ولكن الانتقال لم يكن قراراً عاطفياً، فقد كان في تلك الفترة يبني فهماً اقتصادياً للحوسبة السحابية سوف نراه بالأرقام بعد قليل، وقد شارك في يناير 2009 في ورقة [The Cost of a Cloud: Research Problems in Data Center Networks](https://www.microsoft.com/en-us/research/wp-content/uploads/2009/01/p68-v39n1o-greenberg.pdf?ref=arabroot.io) مع Albert Greenberg وDavid Maltz وParveen Patel من Microsoft Research، وقدم في مارس 2009 محاضرة بعنوان [Cloud Computing Economies of Scale](https://perspectives.mvdirona.com/2009/03/cloud-computing-economies-of-scale/?ref=arabroot.io) قال فيها إن تشغيل الخدمات الكبيرة يختلف عن تشغيل المؤسسات، فالبشر في المؤسسات هم الكلفة الأولى، بينما في الحوسبة السحابية تكون كلفة البشر منخفضة جداً بسبب الأتمتة، ويكون العتاد هو الكلفة الأكبر، والطاقة وما يرتبط بها سوف تلحق به. ويقول في [محاضرة 2014](https://www.youtube.com/watch?v=JIQETrFC%5FSQ&ref=arabroot.io) إنه تعرف على Amazon منذ 1999 حين دعوا Rick Dalzell وCharlie Bell، اللذين كانا يديران بنية Amazon التحتية، إلى مؤتمر High Performance Transaction Systems الصغير الذي يعقد بالدعوة كل سنتين، لأن الصناعة كانت مندهشة من حجم Amazon. وفي [محاضرة 2012](https://www.youtube.com/watch?v=cwPZ6EkwUzs&ref=arabroot.io) أعطى رقماً يبين الحجم الذي دخل فيه: كل يوم تضيف AWS من العتاد ما يكفي لتشغيل Amazon كلها كما كانت سنة 2003، حين كانت شركة إيراداتها 5.2 مليار دولار. ويطلب منك أن تنسى الخدمات الجديدة وتفكر فقط في هذا العمل اللوجستي: أن تصل الرفوف من المصنعين إلى رصيف التحميل في المركز الصحيح، ويكون هناك كهرباء وشبكة جاهزة، ويعمل كل شيء، ثم تعيد ذلك غداً. ## ماذا حدث في مركز Virginia في أغسطس 2011؟ نعود الآن إلى المشهد الذي بدأنا به، ونفصله كما شرحه Hamilton نفسه في ثلاثة مواضع: محاضرة [Failures at Scale](https://www.youtube.com/watch?v=cwPZ6EkwUzs&ref=arabroot.io) في re:Invent 2012، ومحاضرة [Tuesday Night Live](https://www.youtube.com/watch?v=AyOAjFNPAbA&ref=arabroot.io) في re:Invent 2016 التي قال فيها إنه كان بالصدفة في أحد مراكز AWS في Virginia حين حدث هذا العطل بالضبط، وتدوينة [At Scale, Rare Events aren't Rare](https://perspectives.mvdirona.com/2017/04/at-scale-rare-events-arent-rare/?ref=arabroot.io) سنة 2017\. أما تحديد المدينة بأنها Ashburn فهو من WIRED، التي حضرت محاضرة 2012 وقابلته في Las Vegas. ### كيف تصل الكهرباء من الشبكة إلى السيرفر؟ لكي تفهم ما حدث يجب أن تعرف مسار الكهرباء في مركز البيانات Data Center، وقد رسمه Hamilton في محاضرة 2012 وقال إنه مشترك في كل مركز بيانات عمل عليه تقريباً. شركة الكهرباء توصل جهداً عالياً، وفي المثال الذي عرضه 110,000 فولت، إلى محطة تحويل Substation تخفضه إلى جهد متوسط، وفي هذا المركز 13,500 فولت، ثم يدخل إلى أرض المركز ويخفض مرة أخرى إلى 480 فولت ثلاثي الطور، ثم يدخل المبنى. وداخل المبنى توجد لوحة التحويل Switchgear، وداخلها حاسب صغير مدمج اسمه المتحكم المنطقي القابل للبرمجة Programmable Logic Controller، واختصاراً PLC، يبيعه مصنع اللوحة معها. وهذا الحاسب يتحكم بقاطعين Breakers: قاطع الشبكة العامة Utility Breaker وقاطع المولد Generator Breaker، ووظيفته الأولى ألا يسمح أبداً بأن يتصل المصدران معاً، لأنهما غير متزامنين في الطور Phase، واتصالهما يعني انفجاراً كما قال. ووظيفته الثانية أن يراقب جودة الكهرباء، فإذا انقطعت الشبكة شغل المولد ونقل التغذية إليه. ![صف طويل من خزائن معدنية رمادية في غرفة كهرباء، على أبوابها مؤشرات وأزرار ولوحات تحذير، وهي لوحة توزيع بجهد متوسط](https://arabroot.io/content/images/2026/10/james-hamilton-07-photo-switchgear.webp) لوحة تحويل Switchgear بجهد متوسط 4,160 فولت: خزائن متجاورة فيها القواطع وأجهزة القياس والتحكم، وفي لوحات مثلها يعيش الـ PLC الذي يقرر متى يغلق قاطع الشبكة ومتى يغلق قاطع المولد. وهي صورة توضيحية وليست من المركز الذي نتحدث عنه. الصورة: Rsparks3، تنازل عن الحقوق [CC0](https://creativecommons.org/publicdomain/zero/1.0/?ref=arabroot.io)، المصدر: [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:4.16kV%5Fswitchgear.jpg?ref=arabroot.io) (تم تصغيرها وتحويلها إلى WebP). وبعد اللوحة يأتي مزود الطاقة غير المنقطعة Uninterruptible Power Supply، واختصاراً UPS، وهو بطاريات تغذي الأجهزة الحرجة Critical Load، أي السيرفرات والتخزين ومعدات الشبكة، في الثواني التي يحتاجها المولد ليبدأ. والصورة التالية تجمع هذا المسار: ![مسار الكهرباء في مركز البيانات من اليمين إلى اليسار: الشبكة العامة بجهد 110,000 فولت، ثم محطة التحويل ومحول الموقع من 13,500 إلى 480 فولت، ثم لوحة التحويل Switchgear وبداخلها PLC يتحكم بقاطع الشبكة وقاطع المولد، ثم UPS، ثم الأجهزة الحرجة من سيرفرات وتخزين وشبكة، والمولد الاحتياطي V16 متصل بلوحة التحويل ويصل إلى 1,800 RPM في 7 إلى 8 ثوان ويتولى التغذية خلال 15 إلى 20 ثانية. وفي الأسفل التسلسل الطبيعي والحالة النادرة التي يرفض فيها الـ PLC إغلاق قاطع المولد](https://arabroot.io/content/images/2026/10/james-hamilton-02-power-path-1.webp) مسار الكهرباء كما شرحه Hamilton، والنقطة التي يقرر فيها الـ PLC والتسلسل الطبيعي عند الانقطاع كما وصفه في تدوينة 2017 ومحاضرة 2016 كما يلي: 1. تنقطع الشبكة أو تخرج جودة الكهرباء عن الحدود المقبولة، فتنتظر لوحة التحويل بضع ثوان، عادة أقل من 10، لأن الكهرباء تعود في أغلب الحالات قبل أن تحتاج إلى فعل شيء. 2. إذا لم تعد الكهرباء ترسل اللوحة إشارة تشغيل إلى المولد، فيصل إلى 1,800 دورة في الدقيقة خلال 7 إلى 8 ثوان، وتعطيه اللوحة فترة قصيرة ليستقر. 3. حين يصبح جهد المولد ضمن الحدود تغلق اللوحة قاطع المولد وتنقل التغذية إليه، ويكون المولد قد تولى التغذية خلال 15 إلى 20 ثانية تقريباً. 4. طوال هذه الثواني يحمل الـ UPS السيرفرات، فلا يشعر أحد بشيء، وحين تعود الشبكة وتستقر تعود التغذية إليها ويطفأ المولد. ويقول Hamilton إن هذا التسلسل يعمل بشكل صحيح في كل مرة تقريباً، ولهذا لن ترى أغلب المنشآت في حياتها نمط الفشل الذي سوف نشرحه الآن. ![مولد ديزل كبير أخضر داخل غرفة، بمحرك ضخم ومروحة تبريد وأنبوب عادم يصعد إلى السقف، وعلى لوحته الجانبية اسم المولد](https://arabroot.io/content/images/2026/10/james-hamilton-08-photo-generator.webp) مولد ديزل احتياطي لمركز بيانات مستشفى: محرك كبير يحتاج ثوان ليصل إلى سرعته، وفي هذه الثواني يحمل الـ UPS السيرفرات، وهي الخطوات الأربع أعلاه. الصورة: Mikael Häggström، تنازل عن الحقوق [CC0](https://creativecommons.org/publicdomain/zero/1.0/?ref=arabroot.io)، المصدر: [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Power%5Fgenerator%5Fof%5Fa%5Fhospital%5Fdata%5Fcenter.jpg?ref=arabroot.io) (تم تصغيرها وتحويلها إلى WebP). ### لماذا رفض الـ PLC تشغيل المولد؟ في محاضرة 2012 قال إن ما حدث في أغسطس من العام السابق هو أن محول الجهد المتوسط، وهو محول بقدرة 10 ميغاواط، انفجر بطريقة سيئة جداً وأرسل ارتفاعاً مفاجئاً كبيراً في التيار نزلت حتى قاطع الشبكة. وقرأ الـ PLC هذا الارتفاع على أنه قصر مباشر Direct Short داخل مركز البيانات، لأن هذا ما يمكن أن يسبب تياراً بهذا الحجم. ومنطق المصنع هنا واضح: إذا كان هناك قصر داخل المبنى فإن إدخال المولد عليه قد يدمره، والمولد يكلف قرابة ثلاثة أرباع مليون دولار، ولذلك برمج المصنع اللوحة بحيث لا تعرض هذه القطعة الغالية لحدث قد لا تنجو منه. فماذا حدث بالتحديد؟ أرسلت اللوحة إشارة التشغيل، وبدأ المولد يدور بشكل سليم، ولكن الـ PLC لم يغلق قاطع المولد أبداً. وبقي الـ UPS وحده يحمل السيرفرات، وتقول تدوينة 2017 إن الـ UPS يفرغ في هذه الحالة خلال 5 إلى 10 دقائق، ثم تبدأ صفوف السيرفرات بالتوقف واحداً بعد الآخر. ولهذا وصل Hamilton بعد 14 أو 15 دقيقة من مركز آخر ليجد المولد يدور «سعيداً» كما قال، والسيرفرات تتوقف. ويضيف في محاضرة 2016 أن مصنع اللوحة جاء إلى المنشأة بعد ست ساعات ليشرح المشكلة، وأن مدير المركز كان غاضباً جداً لأن المولد كان يعمل ولم يتول التغذية، بينما كان المصنع غير معتذر، وقال إن هذا هو الوضع الذي يجب أن يكون. ![مقارنة بين خيارين بعد ارتفاع مفاجئ في التيار يقرؤه الـ PLC على أنه قصر أرضي: إعداد المصنع الذي يقفل المولد فلا يغلق قاطعه ويحمل الـ UPS السيرفرات 5 إلى 10 دقائق ثم تتوقف، وبرنامج AWS الذي يغلق قاطع المولد فإذا كان العطل خارج المبنى يستمر كل شيء، وإذا كان داخل فرع يفتح قاطع الفرع، وإذا كان أعلى من القواطع قد يتضرر مولد وهناك مولد احتياطي. وفي الأسفل مقارنة بين قرابة 750,000 دولار ثمن المولد و100 مليون دولار خسرتها شركة طيران أمريكية في عطل من النوع نفسه](https://arabroot.io/content/images/2026/10/james-hamilton-03-lockout-1.webp) قرار واحد في برنامج الـ PLC: إقفال المولد أم تغذية السيرفرات؟ ### قرار صحيح للمصنع وخاطئ لمركز البيانات هنا يظهر الدرس الأعمق في القصة، فالمصنع لم يخطئ في البرمجة بمعنى أن الكود فيه خطأ، وإنما اختار سلوكاً افتراضياً يناسب أولوياته: حماية المعدات، وتقليل احتمال القضايا كما قال Hamilton، لأن المصنع لا يعرف أين سوف تركب اللوحة ولا قيمة الاستهلاك الذي خلفها. وفي [تحليله لانقطاع الكهرباء في Super Bowl سنة 2013](https://perspectives.mvdirona.com/2013/02/the-power-failure-seen-around-the-world/?ref=arabroot.io) شرح هذه النقطة بوضوح: لوحات التحويل الحديثة فيها عدد كبير جداً من الإعدادات التي يؤثر بعضها في بعض، والمصنعون يشحنونها بإعدادات محافظة، لأن ضرر فتح القاطع بلا داع أقل في نظرهم من ضرر قاطع لا يفتح حين يجب، والإعدادات الافتراضية تستخدم أكثر مما يجب. أما في مركز البيانات فالمعادلة معكوسة، ويشرحها في تدوينة 2017 بثلاث حالات: - إذا كان العطل خارج المبنى، وهو كذلك في الأغلبية الساحقة من الحالات وفي كل الحالات التي رآها كما يقول، فإن الإقفال لا فائدة منه على الإطلاق، وإدخال المولد يبقي كل شيء يعمل. - إذا كان هناك قصر أرضي داخل المبنى فعلاً، فإن قاطع الفرع المتأثر سوف يفتح، ويستمر باقي المبنى على المولد، والسيرفرات خلف القاطع المفتوح تنتقل إلى مصدرها الثاني وتستمر بلا أثر على العملاء. - إذا كان العطل أعلى في نظام التوزيع ولا يحميه قاطع، أو فشل القاطع في الفتح، فقد يتضرر المولد، ويقول إنه يفضل أن يعرض أقل من مليون دولار للخطر على أن يضمن انقطاع الكهرباء عن الأجهزة كلها. ثم يضع الرقم الذي يحسم النقاش: في صيف 2016 أصاب نمط الفشل نفسه مركز بيانات شركة طيران أمريكية كبرى، والتقرير كان «لوحة التحويل فشلت وأقفلت المولدات الاحتياطية»، فألغت الشركة 1,000 من رحلاتها في اليوم الأول و775 في اليوم الثاني و90 في الثالث، وقال المدير المالي إن الشركة خسرت 100 مليون دولار من الإيرادات، أي قرابة 2% من إيراداتها الشهرية. فإذا كان عميل واحد قد يخسر 100 مليون دولار، فإن حماية مولد ثمنه ثلاثة أرباع مليون لا تبدو الأولوية الصحيحة كما كتب. ### الإصلاح: مراجعة كود لوحات الكهرباء ما فعلته AWS بعد هذا الحدث هو ما يجعل القصة مختلفة. يقول في محاضرة 2012، وتنقل WIRED الكلام نفسه، إن عندهم أكثر من مورد للوحات التحويل، وكلهم يفعلون الشيء نفسه، فمروا على برمجة الـ PLC عندهم جميعاً، وأصبحوا يقومون بمراجعة الكود Code Review لكل لوحات التحويل، وغيروا هذا السلوك. وفي محاضرة 2016 يوضح أنهم ما زالوا يستخدمون لوحات تجارية عادية، ولكنهم غيروا البرنامج الثابت Firmware الذي يتحكم بها، وتقول تدوينة 2017 إنهم كتبوا برنامج تحكم خاصاً بحيث يستمرون في الشراء من أكثر من مصنع، ولكن قرار نقل التغذية يتخذه برنامجهم هم، ولذلك لا يحدث الإقفال. ويضيف في 2016 تفصيلاً مهماً: كل منشآتهم مصممة لتكون فيها معدات احتياطية وقابلة للصيانة دون توقف Concurrently Maintainable، أي يمكن أن يكون نظام خارج الخدمة للصيانة ويحدث عطل في الوقت نفسه ويستمر كل شيء، فإذا تضرر مولد في الحالة النادرة فهناك مولد آخر خلفه. ويقول إن هذا من التفاصيل التي لن يشتري أحد AWS بسببها، ولكنهم فخورون بها، وإن العطل لم يتكرر عندهم منذ سنوات بسببها. ولكن لماذا لا يفعل الجميع ذلك؟ يجيب في محاضرة 2012 بأن المشكلة أن أغلب الناس لا يعرفون أصلاً، فأنت تشتري لوحة تحويل ولا تعرف أنها مليئة بالبرمجيات، ولا تعرف ماذا تفعل هذه البرمجيات، وتدقيق كود شخص آخر صعب جداً إذا لم يكن عندك أشخاص بالمهارات المناسبة، وأغلب المصنعين لن يعرضوه عليك أصلاً، ولذلك يقول إن هذا صعب على الأحجام الصغيرة. ويقول في تدوينة 2017 إن ما فاجأه أن مصنع اللوحة رفض تغيير هذا السلوك حتى حين عرضوا عليه أن يتحملوا هم كل ضرر قد يصيب المعدات. ### محول انفجر أم عمود إنارة سقط؟ إذا قرأت المصادر بعناية سوف تلاحظ أن السبب الخارجي يختلف بين روايتين. في محاضرة 2012 قال إن محول الجهد المتوسط بقدرة 10 ميغاواط انفجر، وهذا ما نقلته WIRED. أما في محاضرة 2016 وتدوينة 2017 فقال إن الحدثين اللذين شارك فيهما كان سببهما سيارة اصطدمت بعمود إنارة من الألمنيوم فسقط على طورين من خطوط الكهرباء، أي أن موصلاً ممتازاً للكهرباء سقط بين طورين لخط جهد عال، بل قال مازحاً إن العمود نفسه صدم مرتين ولا بد أن هناك حانة قريبة. ولا نعرف هل الروايتان عن الحدث نفسه أم عن حدثين مختلفين، فهو يقول إنه رأى هذا العطل مرتين، ولكن المهم أن النتيجة واحدة في الحالتين: ارتفاع مفاجئ كبير في التيار يقرؤه الـ PLC على أنه قصر داخلي فيقفل المولد. وفي الأسبوع نفسه تقريباً نشرت AWS بنفسها مثالاً رسمياً على هذه الفئة من الأعطال، ففي [ملخص حادثة منطقة EU West](https://aws.amazon.com/message/2329B7/?ref=arabroot.io) في Dublin يوم 7 أغسطس 2011 تقول إن محولاً بقدرة 10 ميغاواط وجهد 110 كيلوفولت عند شركة الكهرباء فشل، وإن أحد الـ PLC التي تضمن تزامن الطور بين المولدات لم يكمل توصيل جزء من المولدات، والتفسير الذي يدعمه كل ما رأوه أن قصراً أرضياً كبيراً اكتشفه الـ PLC منعه من إكمال مهمته. ففرغت أنظمة الـ UPS وفقدت المنطقة الكهرباء عن أغلب أجهزة EC2 وعن 58% من أقراص EBS في منطقة التوافر المتأثرة، واحتاج الفريق إلى تزامن الطور يدوياً لإعادة بعض المولدات. وكان من الإصلاحات التي أعلنوها إضافة PLC احتياطي معزول عن الأول. ولاحظ أن رقم 10 ميغاواط في ملخص Dublin هو نفس الرقم الذي ذكره Hamilton في محاضرة 2012، ولا يوضح أي من المصادر هل هناك علاقة بين الروايتين، ولذلك نتركهما كما وردتا. ## الحدث النادر ليس نادراً على الحجم الكبير عنوان تدوينة 2017 هو خلاصة فلسفته في الموثوقية: «At Scale, Rare Events aren't Rare». ويشرح الفكرة بالأرقام في محاضرة 2012: نسبة الأعطال السنوية للأقراص بين 4% و6%، وللسيرفرات بين 2% و4%، فإذا أخذت سيرفراً واحداً فمتوسط الزمن بين الأعطال طويل جداً، ولماذا تضيع وقتك في حماية شيء يفشل مرة كل عشرات السنين؟ ولكن إذا أخذت مركز بيانات فيه 64,000 سيرفر فسوف ترى قرابة 5 سيرفرات تفشل كل يوم و17 قرصاً، أي أكثر من 20 عطلاً يومياً بانتظام الساعة. ثم يضيف الملاحظة المهمة: هذا ينطبق على كل طبقات البنية، ليس على السيرفرات والأقراص فقط، وإنما على لوحات التحويل وأنظمة التبريد ووحدات توزيع الطاقة. وكلما قل عدد قطع نوع معين من المعدات قلت أعطاله المرئية، فقل اهتمام الناس بالحماية منه، وهذا ما يجعل الأعطال النادرة في المعدات الكبيرة خطيرة. فشركة الطيران في الغالب لم تر هذا العطل من قبل، وهو رآه مرتين في حياته المهنية لأنه يعمل على حجم أكبر بكثير. ![صورة من الأعلى لصفوف طويلة من المولدات الاحتياطية في حاويات بيضاء وفوق كل منها كاتم عادم، ومعها صف من الحاويات الرمادية ومعدات كهرباء صغيرة، بجانب جدار مبنى مركز بيانات](https://arabroot.io/content/images/2026/10/james-hamilton-09-photo-generator-rows.webp) صفوف من المولدات الاحتياطية ومعدات الكهرباء بجانب مركز بيانات واحد. وحين يكون عندك عشرات المولدات واللوحات في كل موقع، وعشرات المواقع، يصبح العطل الذي لا يراه مدير منشأة واحدة في حياته حدثاً يتكرر عندك. الصورة: Rsparks3، تنازل عن الحقوق [CC0](https://creativecommons.org/publicdomain/zero/1.0/?ref=arabroot.io)، المصدر: [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Data%5Fcenter%5Fbackup%5Fgenerators.jpg?ref=arabroot.io) (تم تصغيرها وتحويلها إلى WebP). وفي تحليله لانقطاع Super Bowl في فبراير 2013، حين فقد نصف ملعب Superdome الكهرباء وتوقفت المباراة 34 دقيقة، رتب الأدوات التي نملكها أمام أي عطل في أربع درجات، وهي صالحة لأي نظام برمجي أيضاً: 1. **تجنب العطل Fault avoidance:** معدات جيدة، وإعداد صحيح، وصيانة، واختبار متكرر، ويشمل ذلك الاختبار بالاستهلاك الكامل Full Load ثم قرب الحد الأقصى ثم فوقه لتتأكد أن القاطع يفتح في العطل الحقيقي فقط. 2. **التكرار Redundancy:** إذا لم تستطع تجنب العطل فاجعل نسخة أخرى تخفيه، وقدر أن حماية الملعب كاملاً بمولدات ولوحات وUPS دائمة تكلف أقل من 10 ملايين دولار، بينما كان ثمن الإعلان لمدة 30 ثانية في المباراة السابقة يزيد قليلاً على 4 ملايين. 3. **مناطق عطل صغيرة Small fault zones:** سقط نصف الملعب فقط لأن التصميم فيه منطقتان، ولو كانت أربعاً أو ستاً وزعت عليها الإنارة بالتناوب لخسر الملعب جزءاً من الإضاءة في كل مكان واستمرت المباراة ربما. 4. **التعافي السريع Fast recovery:** أتمت الاسترجاع ما أمكن، وإذا احتجت إلى البشر فأعطهم أدوات مراقبة وتسجيل ودربهم، فقد استغرق الفنيون قرابة 15 دقيقة للتحقق قبل إعادة الكهرباء، ثم احتاجت مصابيح التفريغ الغازي قرابة 15 دقيقة أخرى لتعود. وهذه الدرجات الأربع هي نفسها ما نشرحه في مقال [مفاهيم التوفر العالي High Availability للمبتدئين](https://arabroot.io/articles/%D9%85%D9%81%D8%A7%D9%87%D9%8A%D9%85-%D8%A7%D9%84%D8%AA%D9%88%D9%81%D8%B1-%D8%A7%D9%84%D8%B9%D8%A7%D9%84%D9%8A-high-availability-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/)، ولكن قيمة كلام Hamilton أنه يربط كل درجة بكلفتها، فلا يقول «أضف تكراراً» وإنما يقول كم يكلف التكرار وكم يكلف غيابه. ### الأتمتة التي لا تفعل أكثر مما يسمح للمهندس المبتدئ وفي محاضرة 2012 نفسها عرض مجموعة من التقنيات التي قال إنه كتبها قبل سنوات في ورقة LISA، وأهمها الحوسبة الموجهة للتعافي: إذا كان النظام مراقباً جيداً ورأيت أن جزءاً منه غير سليم، فأعد تشغيل العملية، فإن لم ينفع فأعد تشغيل السيرفر، فإن لم ينفع فأعد تثبيته، فإن لم ينفع فاستبدله. ويشرح لماذا تنجح هذه الطريقة بتصنيف قديم للأخطاء: خطأ Heisenbug الذي سماه Jim Gray، وهو خطأ يظهر في ظروف توقيت معينة ويختفي إذا أعدت المحاولة، وخطأ Bohrbug الذي سماه Bruce Lindsay، وهو خطأ يعطيك النتيجة الخاطئة نفسها كل مرة. وإعادة التشغيل تعالج النوع الأول جيداً، أما النوع الثاني فقد يجعلها كارثة، لأن الطلب نفسه سوف ينتقل من سيرفر إلى آخر ويسقطها كلها. والحماية التي يقترحها بسيطة: لا تسمح للأتمتة بأن تفعل أكثر مما تسمح به لمهندس مبتدئ. فإذا اتصل بك أحد وطلب إعادة تشغيل سيرفر واحد فستوافق، وإذا طلب إعادة تشغيل 60% من السعة فستقول له لننظر أعمق أولاً، وكذلك يجب أن تكون الأتمتة. ويضيف أن 80% من المشاكل صغيرة، فإذا عالجتها الأتمتة بقيت للبشر المشاكل الصعبة التي يحبونها، وله قاعدة تقريبية يذكرها: إذا أعطيت شخصاً مئة مهمة مملة يومياً فقرابة واحدة من كل خمس سوف يكون لها أثر غير مقصود. ومن التقنيات الأخرى في المحاضرة أن تضع قرابة ضعف الضغط المعتاد على سيرفر واحد في الإنتاج لتكتشف أين يبدأ النظام بالانهيار في الأداء قبل أن يصل إليه الأسطول كله، وأن يكون عندك وضع تشغيل مخفض Degraded Operations Mode، ومثاله في البريد الإلكتروني أن تتوقف عن تسليم الرسائل المصنفة مزعجة Spam عند الضغط فيمر البريد الحقيقي بسرعة، وأن يكون عندك ضبط للدخول Admission Control، لأنه في خدمة Messenger كان تسجيل الدخول أغلى عشر مرات من تبادل الرسائل، فحين سقطت الخدمة لحظة عاد عشرات الملايين معاً وأسقطوها مرة بعد مرة. وقد شرحنا أدوات ضبط الضغط في مقال [تحديد معدل الطلبات Rate Limiting وخوارزمياته](https://arabroot.io/articles/%D8%AA%D8%AD%D8%AF%D9%8A%D8%AF-%D9%85%D8%B9%D8%AF%D9%84-%D8%A7%D9%84%D8%B7%D9%84%D8%A8%D8%A7%D8%AA-rate-limiting-%D9%88%D8%AE%D9%88%D8%A7%D8%B1%D8%B2%D9%85%D9%8A%D8%A7%D8%AA%D9%87/). ## لماذا مناطق التوافر وليس مركزين على ساحلين؟ من أكثر ما يحب Hamilton شرحه نموذج مناطق التوافر Availability Zones، ويقول في محاضرة 2014 إن هذا ما جعله يقع في حب Amazon حين شرحوه له سنة 2000\. والفكرة تبدأ من ملاحظة يتفق عليها الجميع: إذا أردت أن تتجاوز ثلاث تسعات في التوافرية، أي 99.9%، فيجب أن يعمل نظامك في أكثر من مبنى، فهو يقول إن الأنظمة التي تعمل في مركز بيانات واحد تحصل إحصائياً على قرابة ثلاث تسعات مهما اجتهدت. والطريقة المعتادة في الصناعة كانت أن تضع مركزاً على ساحل والآخر على الساحل المقابل، فلن يصيبهما زلزال أو حريق في الوقت نفسه. ولكنه يسأل سؤالاً واحداً يكشف ضعفها: هل تجرؤ على فصل الكهرباء عن المركز الأساسي؟ ويقول إن الإجابة دائماً تكون «Are you insane»، أي هل أنت مجنون. والسبب فيزيائي: الكتابة على قرص SSD تأخذ قرابة 1 إلى 2 ملي ثانية، بينما الذهاب والعودة بين Los Angeles وNew York قرابة 70 إلى 74 ملي ثانية، فلا يمكن أن تنتظر كل معاملة هذا الزمن، ولذلك يكون النسخ غير متزامن Asynchronous Replication، أي أن آخر المعاملات قد لا تكون وصلت إلى المركز الآخر حين يقع العطل. وعندها تقف أمام خيارين سيئين كما يقول: إما أن تحول إلى المركز الآخر وتخسر بعض المعاملات، ويحتاج البشر بعدها إلى أسابيع لإعادة الاتساق من سجلات التدقيق، وإما ألا تحول وتخسر التوافرية، فيجتمع كبار المهندسين على الهاتف بعد عشرين دقيقة ويقولون إنه لم يتعطل أكثر من ساعة من قبل فلننتظر، وفي الغالب يطول العطل. ويضيف عيبين آخرين: المركز الاحتياطي لا يستقبل ضغطاً حقيقياً فلا تعرف هل يعمل فعلاً حتى تحتاجه، وفي نموذج النسختين لا تستطيع تشغيل أي مركز فوق 50% من سعته. أما نموذج AWS فيفصل بين سببين لاختيار الموقع كانا مخلوطين: المنطقة Region تختارها لتكون قريباً من عملائك أو لتلبي متطلبات الأنظمة المحلية، وداخل المنطقة تحصل على التوافرية من عدة مبان مستقلة بعيدة عن بعضها عشرات الكيلومترات كما قال في 2012، بكهرباء وتبريد مستقلين، ولكنها قريبة بما يكفي ليكون الزمن بينها أقل من 1 إلى 2 ملي ثانية، أي أسرع من الكتابة على SSD نفسها. فتستطيع أن تكتب كل معاملة في ثلاثة مبان قبل أن تؤكدها، وإذا فقدت مبنى بقيت عندك نسختان، وإذا حولت بالخطأ ثم رجعت فلن يلاحظ العميل. ![مقارنة بين الطريقة المعتادة بمركز أساسي في Los Angeles واحتياطي في New York بينهما قرابة 74 ملي ثانية ونسخ غير متزامن، وما يترتب عليها من خسارة معاملات أو توافرية واحتياطي غير مختبر وتشغيل تحت 50%، وبين مناطق توافر داخل منطقة واحدة بينها 1 إلى 2 ملي ثانية وكتابة متزامنة في أكثر من مبنى وضغط حقيقي على كل المباني](https://arabroot.io/content/images/2026/10/james-hamilton-05-az.webp) سؤال Hamilton لأي تصميم احتياطي: هل تجرؤ على فصل الكهرباء؟ ويعطي في محاضرة 2014 أرقاماً عن منطقة US East حينها: خمس مناطق توافر، و82,000 ليف ضوئي، وقرابة 25 تيرابت في الثانية من الحركة بين مناطق التوافر وحدها، وكل منطقة توافر هي دائماً مبنى مستقل واحد على الأقل وبعضها فيه ستة مبان. ويقول إن مركز البيانات الواحد عندهم بين 25 و30 ميغاواط، وإنهم يستطيعون بناء مراكز أكبر بسهولة، فقد عمل في مراكز تصل إلى 60 ميغاواط، ولكن فائدة الحجم تقل كلما كبر المركز، بينما يكبر نطاق الضرر Blast Radius إذا حدث شيء له. وهذه موازنة واضحة بين الكلفة والخطر، وهو يكره الرقم 2 تحديداً، فيقول في 2012 إن 2 رقم سيئ، لأنه إذا كانت إحدى القطعتين في الصيانة أو معطلة فأنت معرض للخطر بالكامل، وإن تشغيل ثمانية راوترات متوسطة أسهل وأرخص من راوترين ضخمين. ## قس الكلفة لكل وحدة عمل: نموذج Hamilton المنشور إذا كانت قصة Virginia تبين كيف يفكر في الفشل، فإن نموذج الكلفة يبين كيف يفكر في القرار. يقول في محاضرة 2014 إن من يعرفه يعرف أنه يقود عمله بالمقاييس Metrics، ويحب النماذج المالية تحديداً، لأنها رغم أنها تبدو مملة تكشف ما يحدث فعلاً، وإن نموذجه يثبت خطأ ثلاثة أو أربعة من أكثر المعتقدات انتشاراً في الصناعة. ### ورقة The Cost of a Cloud سنة 2009 تبدأ [ورقة The Cost of a Cloud](https://www.microsoft.com/en-us/research/wp-content/uploads/2009/01/p68-v39n1o-greenberg.pdf?ref=arabroot.io) المنشورة في ACM SIGCOMM Computer Communication Review في يناير 2009 بسؤال واحد: أين تذهب الكلفة في مراكز بيانات الخدمات السحابية؟ وتفترض مركزاً فيه قرابة 50,000 سيرفر مبنياً بتقنيات مفهومة ومعدات جيدة، وتحول كل كلفة إلى قسط على عمر الأصل بفائدة 5%، فتصل إلى جدول تقريبي: السيرفرات 45%، والبنية التحتية من توزيع الطاقة والتبريد 25%، وفاتورة الكهرباء 15%، والشبكة 15%. وفي الورقة ثلاث ملاحظات أهم من الجدول نفسه. الأولى أن كلفة الموظفين في هذه المراكز أقل من 5% بسبب الأتمتة، ولذلك حذفوها من الجدول، فالنسبة المعتادة في المؤسسة الجيدة موظف لكل 100 سيرفر، وفي مركز البيانات السحابي الجيد موظف لكل 1,000 سيرفر. والثانية أن استغلال السيرفرات Utilization قد يكون منخفضاً جداً، قرابة 10%، لأسباب منها عدم تناسب التطبيق مع السيرفر، وصعوبة توقع الطلب، وطول زمن الشراء، والاحتفاظ بالموارد لأن الفريق يطلبها بسهولة ولا يعيدها. والثالثة قاعدتان: «On is better than off»، أي أن السيرفر الذي اشتريته يجب أن يعمل في شيء مفيد لأن كلفته ثابتة على ثلاث سنوات، وابن المرونة على مستوى النظام وليس داخل كل مبنى، لأن كلفة البنية عالية بسبب أن كل مركز مصمم كي لا يفشل أبداً. وتشرح الورقة أيضاً أن من كل واط يصل إلى المركز يذهب قرابة 59% إلى معدات تقنية المعلومات، و8% يضيع في توزيع الطاقة، و33% يذهب إلى التبريد، وذلك بفرض مؤشر فعالية استخدام الطاقة Power Usage Effectiveness، واختصاراً PUE، يساوي 1.7، وهو نسبة كل طاقة المنشأة إلى طاقة معدات تقنية المعلومات وحدها. ### نموذج 2010: الكهرباء ليست أكبر كلفة، ولكن نشر Hamilton في مدونته نموذجاً أول سنة 2008 بعنوان [Cost of Power in Large-Scale Data Centers](https://perspectives.mvdirona.com/2008/11/cost-of-power-in-large-scale-data-centers/?ref=arabroot.io)، وقال إن أحد أسباب نشره أن يرد على العبارة المتكررة «الكهرباء هي الكلفة الأولى في مراكز البيانات الكبيرة»، ثم حدثه في سبتمبر 2010 في تدوينة [Overall Data Center Costs](https://perspectives.mvdirona.com/2010/09/overall-data-center-costs/?ref=arabroot.io) ونشر معها جدول البيانات Spreadsheet نفسه ليجرب الناس افتراضات أخرى. وخلاصته أن السيرفرات هي الكلفة الأكبر، وأن الكهرباء مهمة جداً ولكن ليس بسبب فاتورة الكيلوواط ساعة، وإنما بسبب معدات توزيع الطاقة التي تحتاجها لتستهلك الكهرباء، ومعدات التبريد التي تزيل الحرارة بعد استهلاكها. ولذلك عرف ما سماه كلفة الطاقة المحملة بالكامل Fully Burdened Cost of Power، وهي فاتورة الكهرباء مع كلفة البنية التي ترتبط بها، وبهذا القياس تصبح الطاقة الكلفة الثانية بعد السيرفرات. ويشرح نقطة يقع فيها كثيرون: إذا قارنت ثمن شراء السيرفرات بثمن بناء المركز مباشرة فسوف تجد المبنى أغلى، ولكن هذه المقارنة خاطئة، لأن المبنى يستهلك على 10 إلى 15 سنة والسيرفرات على قرابة 3 سنوات، أي أنك تشتري السيرفرات من 3 إلى 5 مرات خلال عمر المبنى، ولذلك يحول كل شيء إلى قسط شهري بفائدة 5%، وهي الطريقة التي تسمح بمقارنة أشياء لا تقارن عادة. ويذكر أيضاً أن الكفاءة تحسنت بسرعة بين النموذجين، فقبل سنتين كان 50,000 سيرفر يحتاج إلى مركز بقدرة حرجة 15 ميغاواط، وفي 2010 أصبح 46,000 سيرفر يكفيه 8 ميغاواط. ![توزيع الكلفة الشهرية لمركز بيانات فيه قرابة 46,000 سيرفر في نموذج Hamilton لسنة 2010: السيرفرات 56.6% بقيمة 1,998,097 دولاراً، وتوزيع الطاقة والتبريد 17.7% بقيمة 626,211، وفاتورة الكهرباء 13.4% بقيمة 474,208، ومعدات الشبكة 8.4% بقيمة 294,943، وباقي المبنى 3.9% بقيمة 137,461، والمجموع 3,530,920 دولاراً شهرياً. وتحتها جدول ورقة The Cost of a Cloud سنة 2009: السيرفرات 45% والبنية 25% والكهرباء 15% والشبكة 15%](https://arabroot.io/content/images/2026/10/james-hamilton-04-cost.webp) أين تذهب كلفة مركز البيانات؟ من جدول Hamilton المنشور ومن ورقة 2009 ### التجربة: نعيد حساب النموذج بلغة Python جداول الافتراضات والنتائج في تدوينة 2010 منشورة كصور، ولكن رابط جدول البيانات الأصلي ما زال يعمل على موقعه، فقمنا بتنزيل [ملف PerspectivesDataCenterCostAndPower.xls](https://mvdirona.com/jrh/TalksAndPapers/PerspectivesDataCenterCostAndPower.xls?ref=arabroot.io) وقراءة الافتراضات والمعادلات منه كما هي، ثم كتبنا السكربت التالي الذي يعيد الحساب بالمعادلات نفسها. ودالة `pmt` هي نفسها دالة `PMT` في Excel، أي القسط الشهري الذي يسدد مبلغاً على عدد من الأشهر بفائدة معينة: ```python # Recompute James Hamilton's 2010 data center cost model (PerspectivesDataCenterCostAndPower.xls) def pmt(rate, n, pv): """Monthly payment that repays pv over n months at the given monthly rate (Excel -PMT).""" return pv * rate / (1 - (1 + rate) ** -n) def model(critical_w=8_000_000, kwh=0.07, per_crit_watt=9.0, fac_months=120, w_server=165, server_cost=1450, srv_months=36, net_months=48, money=0.05, load=0.8, pue=1.45, pc_share=0.82, net_cost=12_807_300, net_w=413_650): r = money / 12 servers = (critical_w - net_w) / w_server facility = critical_w * per_crit_watt fac_month = pmt(r, fac_months, facility) rows = { "Servers": pmt(r, srv_months, servers * server_cost), "Networking": pmt(r, net_months, net_cost), "Power dist. & cooling": fac_month * pc_share, "Power (utility bill)": critical_w * load / 1000 * pue * kwh * 24 * 365 / 12, "Other infrastructure": fac_month * (1 - pc_share), } return servers, rows servers, rows = model() total = sum(rows.values()) print(f"servers: {servers:,.0f}") for k, v in rows.items(): print(f"{k:24s} ${v:>12,.0f}/month {v/total:6.1%}") print(f"{'Total':24s} ${total:>12,.0f}/month") print(f"cost per server per month: ${total/servers:,.2f}") print("\nwhat if:") for label, kw in [("power $0.03/kWh", dict(kwh=0.03)), ("power $0.15/kWh", dict(kwh=0.15)), ("PUE 1.2", dict(pue=1.2)), ("PUE 2.0", dict(pue=2.0))]: s, r = model(**kw); t = sum(r.values()) print(f" {label:16s} total ${t:,.0f} power share {r['Power (utility bill)']/t:5.1%} per server ${t/s:,.2f}") print("\ncost per useful server-month at different utilization:") for u in (0.10, 0.30, 0.60): print(f" {u:4.0%} busy -> ${total/servers/u:,.2f}") # The 2009 paper "The Cost of a Cloud" (Greenberg, Hamilton, Maltz, Patel) r = 0.05 / 12 print("\n2009 paper, recomputed per year:") print(f" servers 50,000 x $3,000, 3 years : ${pmt(r, 36, 50_000*3000)*12/1e6:5.1f}M (paper: $52.5M)") print(f" infra $200M over 15 years : ${pmt(r, 180, 200e6)*12/1e6:5.1f}M (paper: $18.4M)") print(f" power 50,000 x 180W, PUE 1.7 : ${50_000*180/1000*1.7*0.07*24*365/1e6:5.1f}M (paper: $9.3M)") ``` ونفذناه داخل Container من صورة Python الرسمية حتى تحصل على النتيجة نفسها على أي جهاز: ```bash docker run --rm -v "$PWD:/lab:ro" -w /lab python:3.12.7-slim python -I dc_cost.py ``` والمخرج سوف يكون كما يلي: ```text servers: 45,978 Servers $ 1,998,097/month 56.6% Networking $ 294,943/month 8.4% Power dist. & cooling $ 626,211/month 17.7% Power (utility bill) $ 474,208/month 13.4% Other infrastructure $ 137,461/month 3.9% Total $ 3,530,920/month cost per server per month: $76.80 what if: power $0.03/kWh total $3,259,944 power share 6.2% per server $70.90 power $0.15/kWh total $4,072,872 power share 24.9% per server $88.58 PUE 1.2 total $3,449,160 power share 11.4% per server $75.02 PUE 2.0 total $3,710,792 power share 17.6% per server $80.71 cost per useful server-month at different utilization: 10% busy -> $767.96 30% busy -> $255.99 60% busy -> $127.99 2009 paper, recomputed per year: servers 50,000 x $3,000, 3 years : $ 53.9M (paper: $52.5M) infra $200M over 15 years : $ 19.0M (paper: $18.4M) power 50,000 x 180W, PUE 1.7 : $ 9.4M (paper: $9.3M) ``` في المخرج أعلاه لاحظ التالي: - **عدد السيرفرات 45,978** ليس افتراضاً وإنما نتيجة: القدرة الحرجة 8 ميغاواط ناقص طاقة معدات الشبكة (413,650 واط في ورقة الشبكة داخل الملف) مقسوماً على 165 واط لكل سيرفر. أي أن النموذج يبدأ من الكهرباء المتاحة ويحسب كم سيرفراً تتسع لها، وهذا هو التفكير الصحيح لمن يبني مركزاً، فالقيد الحقيقي هو الميغاواط وليس المساحة. - **الأرقام الخمسة تطابق الملف الأصلي** حتى الدولار: 1,998,097 للسيرفرات و3,530,920 للمجموع، وهي نفس القيم المخزنة في الخلايا التي حسبها Excel، وبالتالي نعرف أننا فهمنا المعادلات كما قصدها. - **السيرفرات 56.6%** هي البند الأكبر بفارق كبير، وفاتورة الكهرباء 13.4% فقط، ولكن إذا جمعتها مع توزيع الطاقة والتبريد 17.7% تصل الطاقة المحملة بالكامل إلى 31.1%، وهذا هو المقصود بقوله إن الطاقة هي الكلفة الثانية. - **سعر الشبكة** في الملف محسوب بعد خصم 60% من سعر القائمة، وفي تعليق الخلية يقول ساخراً إن معدات الشبكة تسعر بشكل مبالغ فيه ثم يعطى عليها خصم كبير حتى يشعر المشترون في المؤسسات أنهم أدوا عملهم. - **الكلفة لكل سيرفر في الشهر 76.80 دولاراً**، وهذا هو الرقم الذي نسميه الكلفة لكل وحدة عمل Cost per Unit of Work في أبسط أشكاله، وكل قرار بعدها يقاس بأثره على هذا الرقم. ### ماذا يحدث إذا تغير سعر الكهرباء أو الاستغلال؟ القسم الثاني من المخرج هو تجربة «ماذا يحدث إذا…»، وهو ما يجعل النموذج أداة قرار وليس رسماً بيانياً. إذا كانت الكهرباء رخيصة بسعر 3 سنتات للكيلوواط ساعة فإن فاتورتها تنزل إلى 6.2% من المجموع، وإذا كانت غالية بسعر 15 سنتاً ترتفع إلى 24.9%، ويقول تعليق الخلية في الملف إن السعر يتراوح بين أقل من 3 سنتات وأكثر من 15 بحسب المنطقة. أي أن العبارة «الكهرباء هي الكلفة الأولى» قد تقترب من الصحة في منطقة غالية الكهرباء ومع سيرفرات رخيصة، وقد قال هو نفسه في تدوينة 2008 إن الطاقة المحملة بالكامل قد تصبح الكلفة الأكبر مع سيرفرات أرخص أو كهرباء أغلى. ولاحظ أن تحسين PUE من 1.45 إلى 1.2 يوفر قرابة 2.3% فقط من المجموع في هذا النموذج، وهذا يفسر لماذا تأتي أكبر المكاسب من السيرفرات نفسها: سعرها، وطاقتها، وكم تعمل. والسطر الأخطر هو الاستغلال: إذا كانت السيرفرات تعمل 10% من الوقت في عمل مفيد، وهو الرقم الذي ذكرته ورقة 2009، فإن كلفة السيرفر المفيد الواحد في الشهر تصبح قرابة 768 دولاراً بدل 77، وإذا رفعت الاستغلال إلى 60% تنزل إلى 128 دولاراً. هذا الفرق أكبر من أي تحسين في الكهرباء أو التبريد، وهو المعنى العملي لقاعدة «On is better than off»، وهو أيضاً السبب الاقتصادي وراء السحابة نفسها: أن تجمع عملاء كثيرين على أسطول واحد فيرتفع الاستغلال. وقد ناقشنا الوجه الآخر لهذه المعادلة، أي متى تكون السحابة أغلى عليك، في مقال [السحابة ليست دائماً الأرخص](https://arabroot.io/articles/%D8%A7%D9%84%D8%B3%D8%AD%D8%A7%D8%A8%D8%A9-%D9%84%D9%8A%D8%B3%D8%AA-%D8%AF%D8%A7%D8%A6%D9%85%D8%A7-%D8%A7%D9%84%D8%A7%D8%B1%D8%AE%D8%B5-%D9%85%D8%AA%D9%89-%D8%AA%D9%83%D9%84%D9%81%D9%83-%D8%A7%D9%83%D8%AB%D8%B1-%D9%85%D9%86-vps/). ### المشكلة التي ظهرت: أرقام الورقة لا تطابق المعادلة تماماً القسم الأخير من المخرج يعيد حساب أرقام ورقة 2009 بطريقة القسط نفسها، فتطابق فاتورة الكهرباء تقريباً، 9.4 مليون مقابل 9.3، ولكن السيرفرات تخرج 53.9 مليون سنوياً بينما تقول الورقة 52.5، والبنية 19.0 مقابل 18.4\. ولاحظنا أن 52.5 تساوي بالضبط 150 مليوناً مقسومة على 3 سنوات مضروبة في 1.05، أي أن الورقة استخدمت على الأغلب تقريباً أبسط للفائدة في هذا السطر، ولم نجد تفسيراً مشابهاً لرقم البنية. والفرق في الحالتين أقل من 4% ولا يغير ترتيب البنود ولا الخلاصة، ولكن الدرس العملي هنا أن تعيد الحساب بنفسك قبل أن تنقل رقماً من ورقة أو تدوينة، حتى لو كان الكاتب هو صاحب النموذج، وأن تعرف أي طريقة استهلاك يستخدمها كل مصدر قبل أن تقارن بينها. ## لماذا تملك AWS العتاد؟ قصة Virginia علمت AWS أن البرنامج داخل المعدات يقرر سلوكها، ونموذج الكلفة علمها أين يذهب المال، وإذا جمعت الدرسين تفهم القرار الذي ميز AWS بعد ذلك: أن تأخذ بيدها طبقة بعد طبقة من العتاد الذي كانت تشتريه جاهزاً. ويشرح Hamilton في محاضرة 2014 أن سوق السيرفرات والتخزين أصح بكثير من سوق الشبكات، ولكنه ما زال غير فعال لأنه مبني لخدمة عشرات الآلاف من العملاء بمتطلبات مختلفة، أما مزود السحابة فهو عميل واحد يعرف بالضبط ماذا يريد. ![جدول الطبقات التي أخذتها AWS بيدها مع ما تغير والسبب: المعالج Graviton منذ 2018 لأن منظومة Arm مفتوحة والكلفة تنخفض مع الحجم، وبطاقات Nitro منذ 2016 لأن العمل المتكرر في العتاد يأخذ تقريباً عشر الزمن والطاقة والكلفة، والشبكة براوترات خاصة وروابط 25G لأن كلفة الشبكة كانت ترتفع والكود الأبسط أعلى توافرية، والسيرفرات والتخزين المخصص لأنه لا حاجة إلى قناة بيع تكلف 30% ولا هامش هندسي زائد، وبرنامج لوحات التحويل لأن إقفال المولد يحمي قطعة بثلاثة أرباع مليون على حساب السيرفرات كلها، ومحطات الكهرباء لأن شركات الكهرباء لا تبني بسرعة نمو AWS](https://arabroot.io/content/images/2026/10/james-hamilton-06-stack.webp) الطبقات التي أخذتها AWS بيدها، وسبب كل منها بكلام Hamilton ### الشبكة: من «SUV مركز البيانات» إلى راوترات خاصة بدأ اهتمامه بالشبكات قبل AWS، ففي تدوينة جائزة SIGCOMM يصف المحول الشبكي الشهير في ذلك الوقت Cisco Nexus 7000 بأنه يحتاج عند تجهيزه بالكامل إلى 8 دوائر كهربائية بقدرة 5 كيلوواط لكل منها، أي 40 كيلوواط لـ 120 منفذاً فقط، وهي طاقة أكثر من أربعة رفوف سيرفرات، وكان يسمي هذه المعدات «SUV of the Data center» في محاضرة له في Stanford سنة 2010 بعنوان «Data Center Networks are in my Way». وكانت الشبكات في رأيه ما زالت في عصر الحاسبات المركزية: شركة واحدة تصمم الشريحة الأساسية ASIC واللوحات والهيكل والبرمجيات كلها، وتبيعها في حزمة واحدة بسعر عال جداً. وفي محاضرة 2014 قال إن الشبكة كانت «حالة طوارئ» في AWS لسببين اجتمعا: كلفة معدات الشبكة كانت ترتفع نسبة إلى كل المعدات الأخرى التي تنخفض أسعارها باستمرار، وفي الوقت نفسه كانت نسبة الشبكة إلى الحوسبة ترتفع، لأن السيرفر الواحد يحمل حوسبة أكثر في كل جيل، ولأن انخفاض كلفة الحوسبة يزيد تحليل البيانات الذي يحتاج إلى حركة كثيفة بين السيرفرات، أو ما يسمى حركة East-West. فقرروا قبل قرابة خمس سنوات من تلك المحاضرة أن يصمموا راوتراتهم بأنفسهم، تصنعها لهم شركات التصنيع حسب التصميم ODM، ويكتب فريق داخلي البرمجيات كاملة حتى أعلى الـ Protocol Stack، ويقول مازحاً إن مثل هذا الاقتراح في شركات كثيرة كان سيجعلهم يضعونك في غرفة صغيرة آمنة. والنتيجة الأولى لم تفاجئ أحداً: أرخص بكثير، ويقول إن عقد الدعم وحده لمعدات الشبكة كان يكلف عشرات الملايين من الدولارات. أما النتيجة التي فاجأته فهي أن التوافرية ارتفعت، والسبب كما يشرح أن الشركات المصنعة تجمع متطلبات معقدة من عملاء كثيرين في عشرات الملايين من أسطر الكود التي يصعب صيانتها، بينما AWS لا تستخدم أغلب هذه الميزات، فحلت مشكلة أبسط فجاءت أكثر موثوقية. ويضيف سببين آخرين: قاعدتهم أن أي تجربة سيئة لعميل يجب أن تظهر في المقاييس، وإلا فإن النقاش سوف يصل إلى الإدارة العليا، وأنهم يستطيعون إصلاح الكود كل أسبوع بدل انتظار إصدار المصنع كل 18 شهراً. ولاختبار الشبكة الجديدة شغلوا بيئة اختبار فيها 8,000 سيرفر بقدرة 3 ميغاواط، يقول إن قيمتها قرابة 40 مليون دولار لو اشتروها، ولكنهم استأجروها من السحابة لشهرين بكلفة بضع مئات الآلاف. وفي محاضرة 2016 شرح قراراً آخر يبين كيف يفكر في الكلفة لكل وحدة: الصناعة كانت تستخدم روابط 10 و40 جيجابت، وAWS اختارت 25 جيجابت حين كانت جديدة وفيها نقص في البصريات Optics. والسبب أن رابط 10 جيجابت يستخدم موجة ضوئية واحدة، ورابط 40 يستخدم أربع موجات فتكون كلفة بصرياته قرابة أربعة أضعاف، أما رابط 25 فهو موجة واحدة وكلفته قريبة من 10، فيحصلون على 50 جيجابت بموجتين فقط. وعرض الشريحة التي تشغل راوتراتهم حينها، Broadcom Tomahawk بسعة 3.2 تيرابت في الثانية، أي 128 منفذاً بسرعة 25 جيجابت، وقال إن تفكيك سوق الشبكات إلى شرائح تباع منفصلة هو ما جعل ذلك ممكناً. وقد شرحنا أساسيات هذه المعدات في مقال [المودم والراوتر والسويتش](https://arabroot.io/articles/%D8%A7%D9%84%D9%85%D9%88%D8%AF%D9%85-%D9%88%D8%A7%D9%84%D8%B1%D8%A7%D9%88%D8%AA%D8%B1-%D9%88%D8%A7%D9%84%D8%B3%D9%88%D9%8A%D8%AA%D8%B4-%D9%85%D8%A7-%D8%A7%D9%84%D9%81%D8%B1%D9%82-%D8%A8%D9%8A%D9%86%D9%87%D8%A7/). ### السيرفرات والتخزين: لماذا يكون المخصص أرخص؟ تقول WIRED إن Hamilton أكد لها في Las Vegas أن Amazon تصمم سيرفراتها بنفسها لتخفض الكلفة، ويشرح في محاضرة 2014 لماذا يكون السيرفر المخصص أرخص دون أي سحر كما يقول. السبب الأول قناة البيع: المصنع الذي يبيع لعشرات أو مئات الآلاف من العملاء حول العالم يحتاج إلى شبكة توزيع ضخمة تعرض السيرفرات وتبيعها وتدعمها، وهذه القناة تكلف قرابة 30%، أما مزود السحابة فعميل واحد، ولا يحتاج كما قال إلى من يأخذه إلى Super Bowl أو يلعب معه الغولف. والسبب الثاني أعمق وهو الهامش الهندسي Engineering Headroom: المصنع لا يعرف أين سيعمل السيرفر ولا في أي حرارة ولا بأي ضغط، وإذا اكتشف عيباً يتطلب فتح الصناديق عند آلاف العملاء في أنحاء العالم فهذه كارثة مكلفة جداً، ولذلك يصمم بهامش أمان كبير لا يستخدم غالباً. أما AWS فتعرف الضغط والبيئة بالضبط، وعندها فرق تستبدل آلاف الأقراص يومياً وتعرف أين كل مركز، فكلفة العطل عندها أقل، وتستطيع أن تصمم بهامش أصغر. ويذكر مثالاً على ذلك أنهم لا يضعون المعالج في ظل الذاكرة في مسار الهواء، وأنهم بالشراكة مع Intel يحصلون على معالجات تعمل أسرع عند عدد أنوية معين مما هو متاح في السوق. وعرض في 2014 رف تخزين صمموه قبلها بثلاث سنوات فيه 864 قرصاً ويزن 2,350 رطلاً، وقال إن أحداً لم يكن يريد رفاً بهذا الوزن، ولكنه لبعض الاستخدامات تصميم يغير الأسعار. ثم عرض في 2016 تصميماً أحدث في رف عادي بارتفاع 42U فيه 1,110 أقراص بسعة 8.8 بيتابايت. ### Nitro: نقل العمل المتكرر من البرمجيات إلى الشريحة في محاضرة 2014 شرح أين يضيع الزمن حين يرسل سيرفر رسالة إلى آخر: في البرمجيات من التطبيق إلى نظام التشغيل الضيف إلى الـ Hypervisor يكون الزمن بالملي ثانية، وفي بطاقة الشبكة بالمايكرو ثانية، وفي الألياف بالنانو ثانية، أي أن المشكلة كلها في البرمجيات على الطرفين. والحل المعروف تقنية SR-IOV التي تعطي كل آلة افتراضية بطاقة شبكة افتراضية في العتاد مباشرة، ولكن الصعب كما يقول ليس هذه التقنية، وإنما أين تضع العزل بين العملاء والقياس والحماية من هجمات حجب الخدمة وحدود السعة إذا تجاوز الضيف الـ Hypervisor. وحين نجحوا في ذلك تحسن متوسط زمن الشبكة قرابة الضعف، ونزل الزمن عند النسبة المئوية 99.9 إلى قرابة العشر، وهذه الحالات النادرة البطيئة هي ما يزعج التطبيقات فعلاً. ثم في محاضرة 2016 قال الجملة التي ما زالت تقتبس: «we're in the semiconductor business»، أي أن AWS أصبحت في صناعة أشباه الموصلات، وعرض أول شريحة مخصصة من AWS، وقال إن كل سيرفر ينشرونه فيه واحدة منها على الأقل. وشرح أنهم منذ قرابة 2011 نقلوا كود الشبكة الافتراضية من السيرفر إلى بطاقة الشبكة، لأن أي عمل متكرر يحدث طوال الوقت مثل معالجة الحزم أفضل في العتاد، وأعطى قاعدة تقريبية: إذا نقلت العمل إلى العتاد فإنك تحصل تقريباً على عشر الزمن وعشر الطاقة وعشر الكلفة. ويضيف أن هذا أكثر أماناً، لأنه إذا اخترق الـ Hypervisor فلا يصل المخترق إلى الشبكة، فهي تدار بنظام تشغيل منفصل على البطاقة. وفي [تدوينة AWS Nitro System](https://perspectives.mvdirona.com/2019/02/aws-nitro-system/?ref=arabroot.io) سنة 2019 قال إن تلك الشريحة وأجيالها التالية أصبحت أساس [نظام Nitro](https://aws.amazon.com/ec2/nitro/?ref=arabroot.io)، وإنهم يستهلكون ملايين منها كل سنة، وشرح مكوناته: بطاقة للشبكة الافتراضية VPC تنفذ التغليف وقواعد مجموعات الأمان Security Groups والحدود والتوجيه، وبطاقة لأقراص EBS تنفذ التشفير الشفاف وتظهر الأقراص البعيدة كأجهزة NVMe، وبطاقة للتخزين المحلي، ومتحكم ينسق بينها، وشريحة أمان Nitro Security Chip تمنع المعالج الرئيسي من تغيير أي برنامج ثابت Firmware على السيرفر، فلا يحدثه إلا AWS عبر نظام Nitro. والنتيجة أن أنوية السيرفر كلها تبقى للعميل في الأنواع الكبيرة، ولا يحجز منها شيء لعمل AWS. ولاحظ أن هذا هو نفس الدرس الذي تعلمه في Virginia، ولكن على مستوى السيرفر: البرنامج الذي يتحكم بالسلوك الحرج يجب أن يكون بيدك، سواء كان برنامج لوحة كهرباء يقرر متى يدخل المولد، أو برنامج بطاقة يقرر من يرى حزم من. ### Graviton: معالج انتظره أكثر من عشر سنوات في نوفمبر 2018 كتب Hamilton [تدوينة إعلان معالج Graviton](https://perspectives.mvdirona.com/2018/11/aws-designed-processor-graviton/?ref=arabroot.io) الذي يشغل أنواع EC2 A1، وقال إنه يوم كان ينتظره أكثر من عشر سنوات. وشرح لماذا يختلف المعالج عن الخدمات البرمجية: فريق Amazon الصغير قد يطلق خدمة ناجحة في أشهر، أما المعالج المخصص فيحتاج وقتاً أطول بكثير، وكلفته الهندسية عشرات الملايين وقد تصل إلى مئات الملايين من الدولارات، ولذلك لا يبرره إلا حجم إنتاج كبير. وسبب اختياره Arm في رأيه أن منظومتها مفككة أكثر حتى من منظومة x86: شركة Arm تصمم المعالج وترخصه، وشركات كثيرة تدمجه في شرائحها دون أن تملك مصانع، ثم تصنعها شركات متخصصة مثل TSMC، وفي كل طبقة منافسة، وقد شحنت هذه المنظومة 90 مليار معالج، ولا شيء يخفض الكلفة في عالم أشباه الموصلات أسرع من حجم الإنتاج. ويعترف بأنه حين انضم إلى AWS في 2009 لم يكن ليتوقع أنهم سوف يصممون معالجات سيرفرات خلال أقل من عشر سنوات. وفي 2022 كتب أن فريق Annapurna داخل AWS يقف خلف خطوط أشباه الموصلات الأربعة عندهم. واليوم تقول [صفحة Graviton الرسمية](https://aws.amazon.com/ec2/graviton/?ref=arabroot.io) إن الأنواع المبنية عليه أرخص حتى 20% من أنواع x86 المقابلة، وتستهلك طاقة أقل حتى 60% للأداء نفسه، وإن أكثر من 120,000 عميل يستخدمونه، وإن الجيل Graviton5 فيه 192 نواة. وهذه أرقام البائع نفسه، فقسها على تطبيقاتك قبل أن تعتمد عليها. ### محطات الكهرباء: السرعة قبل التوفير وأبعد طبقة عن البرمجيات هي محطات التحويل عالية الجهد، وقد قال في محاضرة 2014 إنهم صمموا وبنوا بعضها بأنفسهم، ولكن السبب ليس التوفير، فهو يقول إن التوفير صغير جداً ولم يكونوا ليفعلوا ذلك من أجله، وإنما السرعة، لأن معدل نمو AWS ليس معدلاً معتاداً عند شركات الكهرباء، فكان عليهم أن يفعلوا ذلك، وأصبحت هندسة الطاقة مهارة داخلية عندهم. وهذا يوضح أن سؤال «نبني أم نشتري؟» ليس دائماً سؤال كلفة، فقد يكون سؤال زمن أو سؤال سيطرة على السلوك كما في Virginia. ### متى لا يكون امتلاك العتاد قراراً صحيحاً؟ قد يقرأ أحد هذه القصة ويقرر أن على شركته أن تصمم سيرفراتها، وهذا خطأ يحذر منه Hamilton نفسه بطريقة غير مباشرة، فكل قرار مما سبق كان مشروطاً بالحجم: يقول عن تدقيق كود لوحات التحويل إنه صعب على الأحجام الصغيرة، وعن المعالج إنه يحتاج إلى حجم إنتاج كبير يبرر مئات الملايين، وتدوينة 2017 تقول صراحة إنه محظوظ بالعمل عند مشغل كبير يجعل الهندسة المخصصة لتجنب عطل نادر قراراً اقتصادياً ممتازاً. فالدرس للشركة المتوسطة عندنا ليس «صمم عتادك»، وإنما أن تفهم ما يحدث داخل العتاد الذي تشتريه أو تستأجره، وأن تعرف أين الكلفة وأين الخطر، ثم تقرر بمعلومات كما شرحنا في مقال [تشتري أم تبني؟](https://arabroot.io/articles/%D8%AA%D8%B4%D8%AA%D8%B1%D9%8A-%D8%A7%D9%85-%D8%AA%D8%A8%D9%86%D9%8A-%D8%A7%D9%84%D9%82%D8%B1%D8%A7%D8%B1-%D8%A8%D9%85%D8%B9%D9%84%D9%88%D9%85%D8%A7%D8%AA-%D9%86%D8%A7%D9%82%D8%B5%D8%A9/). ## الكتابة في العلن: مدونة Perspectives من أغرب ما في قصة Hamilton أن شركة معروفة بالكتمان مثل Amazon تركته يكتب، وتقول WIRED إنه بسبب المكانة التي يحظى بها من الموظفين القلائل في Amazon المسموح لهم بالتدوين عن أفكارهم الكبيرة. وأرشيف [مدونة Perspectives](https://perspectives.mvdirona.com/?ref=arabroot.io) يبدأ من أكتوبر 2007، وكان يكتب فيها بغزارة في سنواتها الأولى، بالعشرات في الشهر أحياناً، ثم قلت التدوينات مع السنوات، ولكنها ما زالت حية في 2026، وما زال يرد بنفسه على تعليقات القراء التقنية. وما يميز كتابته ثلاثة أشياء يمكن أن نتعلمها. الأول أنه ينشر الأرقام والنموذج وليس الخلاصة فقط، فقد نشر جدول البيانات الأصلي لنموذج الكلفة وكتب «feel free to change» ليغير القراء الافتراضات، وهذا ما سمح لنا بإعادة الحساب بعد 16 سنة. والثاني أنه يحلل أعطال الآخرين بهدوء وباحترام، فهو يقول في تدوينة 2017 إنه «connoisseur of failure»، أي متذوق للأعطال، ليس لأنه يستمتع بها وإنما لأنه يعتقد أن فهم أعطال أكثر يجعلنا نبني أنظمة لا تقع فيها، وحين عرض في 2012 تقرير ما بعد الحادثة لشركة أخرى حذف أسماءها وقال إنه يتعاطف مع كاتبه لأنه كتب مثله. والثالث أنه يحسب قبل أن يعلق، فحين احتفت الصحافة بمزرعة الطاقة الشمسية التي بنتها Apple لمركز بياناتها كتب بحسب WIRED أنه لا يستطيع أن يجعل الحساب يعمل، وقدر أن 100 فدان من الألواح تعطي قرابة 4% فقط من حاجة المركز، واقترح أن الأثر الأكبر يأتي من كفاءة توزيع الطاقة والتبريد والسيرفرات ورفع الاستغلال. وكثير من تحليلاته اللاحقة، مثل تحليل Super Bowl، كتبه في أيام بعد الحدث، ليس كخبر وإنما كتمرين هندسي: ماذا نعرف، وماذا لا نعرف، وكم كان سيكلف الحل. ولهذا تصلح مدونته مرجعاً لمن يريد أن يتعلم كيف يكتب تقرير ما بعد الحادثة Postmortem، وقد طبقنا هذه الطريقة في قصة [حريق مركز بيانات OVHcloud في ستراسبورغ](https://arabroot.io/articles/%D8%AD%D8%B1%D9%8A%D9%82-%D9%85%D8%B1%D9%83%D8%B2-%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-ovhcloud-%D9%81%D9%8A-%D8%B3%D8%AA%D8%B1%D8%A7%D8%B3%D8%A8%D9%88%D8%B1%D8%BA/). ## Dirona: مهندس يعمل من قارب حين قابلته WIRED في نوفمبر 2012 كان قد وصل للتو مع زوجته Jennifer وقطهما Spitfire بعد 11 يوماً في البحر من San Francisco إلى Hawaii على قاربهما Dirona، وقالت المجلة إنهما باعا منزلهما وسيارتهما وأغلب ممتلكاتهما وانتقلا للعيش على القارب، وإنه حين يكون القارب في Seattle يذهب بالدراجة إلى مقر Amazon. ويروي الزوجان القصة بتفاصيلها على [موقعهما](https://mvdirona.com/2018/01/dirona-around-the-world/?ref=arabroot.io): اشتريا أول قارب في 1999، قارباً ساحلياً سمياه Dirona، وحين سألهما البائع كم ساعة سوف يستخدمانه في السنة قالا خمسين أو مئة، لأن كليهما يعمل في وظيفة برمجيات مزدحمة، ثم باعاه بعد عشر سنوات وعليه 4,100 ساعة تشغيل. وفي فبراير 2010 استلما قاربهما الثاني، وهو [Nordhavn 52](https://mvdirona.com/dirona/?ref=arabroot.io) صالح للمحيطات، مداه 2,500 ميل بحري ويصل إلى 4,000 مع وقود إضافي على السطح، وأطول عبور قاما به كان 3,689 ميلاً بحرياً. وفي خريف 2011، أي بعد أشهر من حادثة Virginia، اقترح James أن يقوما بدورة سريعة حول العالم في قرابة ثمانية عشر شهراً ثم يعودا إلى العمل، فاستغرقت الدورة 42 شهراً بدل 18، ولم يعودا إلى العمل في Seattle كما خططا، و«James never did take time off» كما كتبا، أي أنه لم يأخذ إجازة واستمر يعمل بدوام كامل من القارب. وهذه ليست قصة جانبية، فالعمل بدوام كامل في منصب بهذا الحجم من قارب في وسط المحيط مشكلة هندسية بحد ذاتها: اتصالات عبر الأقمار الصناعية، وطاقة، ومحركات يجب أن تعمل لأن لا أحد سوف يأتي لإصلاحها، ولهذا قدم في مؤتمر HPTS سنة 2022 محاضرة بعنوان «IoT at Sea» كما تذكر صفحته. والقاعدة التي في قصة Virginia تنطبق هنا حرفياً: إذا لم يكن هناك من يأتي لإنقاذك فيجب أن تكون قد صممت للفشل قبل أن تبحر. ## الدروس للمهندسين لنفرض أنك في فريق بنية تحتية لشركة سعودية متوسطة، عندكم بعض السيرفرات في مركز بيانات مستضاف Colocation، وبعض الخدمات في السحابة، وتفكرون في التوسع. فما الذي تأخذونه من قصة Hamilton؟ ### افتح الصندوق الأسود، أو اسأل من يملكه لن تكتب أنت برنامج لوحة التحويل، ولكنك تستطيع أن تسأل مزود مركز البيانات أسئلة محددة: كيف يتصرف مفتاح التحويل التلقائي Automatic Transfer Switch عند ارتفاع مفاجئ في التيار يشبه قصراً أرضياً، هل يقفل المولد أم يتولى التغذية؟ متى اختبروا المولدات آخر مرة باستهلاك حقيقي أو باستهلاك اصطناعي Load Bank، وليس بالتشغيل دون أجهزة موصولة فقط؟ كم دقيقة يصمد الـ UPS باستهلاككم الفعلي؟ هل كل رف يأخذ الكهرباء من مسارين مستقلين A وB؟ وإذا لم يعرف المزود الإجابة فهذه معلومة مهمة بحد ذاتها. والأمر نفسه في البرمجيات: كل مكتبة وكل خدمة مدارة فيها إعدادات افتراضية اختارها شخص آخر لأولوياته هو، مثل مهلة الانتظار Timeout، وعدد المحاولات Retries، وسلوك الـ Circuit Breaker، فاقرأها وقرر هل تناسب أولوياتك. ### قس الكلفة لكل وحدة عمل قبل أي قرار بدل أن تسأل «كم تكلفنا السحابة شهرياً؟» اسأل «كم تكلفنا الطلبات الألف، أو العميل الواحد، أو السيرفر المفيد الواحد؟». وحول كل كلفة إلى قسط شهري على عمرها الحقيقي كما فعل Hamilton، فالسيرفر على 3 إلى 5 سنوات، والتجهيزات على عمرها، والكهرباء والترخيص والدعم شهرياً، ثم قسم على وحدة العمل. وستكتشف غالباً ما اكتشفه هو: أن الاستغلال يحرك الرقم أكثر من أي شيء آخر، وأن سيرفراً يعمل 10% من الوقت أغلى بكثير مما يظهر في الفاتورة. وتذكر التكاليف التي لا تظهر في المقارنة الأولى، كما شرحنا في مقال [التكاليف الخفية في السحابة](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D9%83%D8%A7%D9%84%D9%8A%D9%81-%D8%A7%D9%84%D8%AE%D9%81%D9%8A%D8%A9-%D9%81%D9%8A-%D8%A7%D9%84%D8%B3%D8%AD%D8%A7%D8%A8%D8%A9-egress-%D9%88%D8%A7%D9%84%D8%AA%D8%AE%D8%B2%D9%8A%D9%86/). ### صمم للفشل واختبر مسار الفشل في الإنتاج طبق اختبار الحمض من ورقة 2007 على أنظمتكم: هل تستطيعون إيقاف أي سيرفر الآن دون نقل الضغط عنه؟ وطبق سؤال المحاضرة على خطة التعافي من الكوارث: هل تجرؤون على فصل الموقع الأساسي في منتصف يوم عمل؟ فإذا كانت الإجابة لا، فخطتكم لم تختبر، وغالباً لن تعمل كما تتوقعون. ويقول Hamilton إن Amazon تطفئ سعة مركز بيانات كامل عمداً لتتأكد أنها تستطيع، وإن الأعطال شائعة بما يكفي لتحتاج إلى حماية، ولكنها ليست شائعة بما يكفي لتختبر الحماية، ولذلك يجب أن تصنع الأعطال بنفسك في وقت تختاره، والمهندسون كلهم حاضرون. والنسخ الاحتياطي ينطبق عليه الأمر نفسه، فالنسخة التي لم تختبر استعادتها ليست نسخة، كما شرحنا في [النسخ الاحتياطي بقاعدة 3-2-1](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/). ### لا تثق بالرقم 2، وصغر منطقة العطل نسختان من أي شيء تعني أنك معرض بالكامل حين تكون إحداهما في الصيانة، ولذلك فكر في N+1 أو N+2 حيث يمكن، وفي توزيع الاستهلاك على عدة قطع متوسطة بدل قطعتين كبيرتين. وحين لا تستطيع منع العطل فقلل ما يطاله: وزع الخدمة على أكثر من منطقة توافر، ولا تضع كل نسخ قاعدة البيانات خلف مفتاح شبكة واحد أو مسار كهرباء واحد، كما وزع Hamilton في اقتراحه إنارة الملعب على عدة مناطق بالتناوب. ### اكتب ما تعلمته في العلن لم يكن Hamilton ليؤثر بهذا القدر لو بقيت معرفته داخل Amazon، فالورقة والتدوينات والمحاضرات هي ما جعل مهندسين في شركات أخرى يغيرون إعدادات لوحاتهم ويعيدون حساب كلفهم. وإذا حللت عطلاً في عملك فاكتب تقريراً بلا لوم يشرح الآلية والكلفة والإصلاح، وإذا بنيت نموذج كلفة فانشر افتراضاته حتى يصححها غيرك، فالمجتمع التقني عندنا يحتاج إلى هذا النوع من الكتابة أكثر من حاجته إلى الأخبار. ## قائمة تحقق لفريق يدير بنيته التحتية الجدول التالي يجمع أسئلة القصة في شكل يمكن أن تمر عليه في اجتماع واحد: | السؤال | إذا كانت الإجابة لا | من القصة | | ------------------------------------------------------------------- | --------------------------------------------------------------- | ------------------------------------------- | | هل نعرف كيف يتصرف مفتاح التحويل والمولد عند ارتفاع مفاجئ في التيار؟ | اطلب من المزود وثيقة الإعدادات ونتيجة آخر اختبار باستهلاك حقيقي | إقفال المولد في Virginia وشركة الطيران | | هل كل رف يأخذ الكهرباء من مسارين مستقلين؟ | عطل في مسار واحد يوقف الرف كله | القاطع الفرعي والمصدر الثاني في تدوينة 2017 | | هل نستطيع إيقاف أي سيرفر الآن دون نقل الضغط عنه؟ | عندكم نقطة فشل واحدة لم تظهر بعد | اختبار الحمض في ورقة LISA | | هل نجرؤ على فصل الموقع الأساسي في يوم عمل؟ | خطة التعافي غير مختبرة | سؤال «هل تجرؤ على فصل الكهرباء؟» | | هل نعرف كلفة وحدة العمل، وليس الفاتورة فقط؟ | قراراتكم في الشراء والسحابة بلا أساس | نموذج الكلفة الشهرية المنشور | | هل نعرف نسبة استغلال السيرفرات؟ | قد تدفعون عشرة أضعاف ما تظنون للعمل المفيد | الاستغلال 10% في ورقة 2009 | | هل الأتمتة محدودة بما يسمح للمهندس المبتدئ؟ | خطأ واحد متكرر قد يسقط الأسطول كله | إعادة التشغيل وخطأ Bohrbug | | هل عندنا وضع تشغيل مخفض وضبط للدخول؟ | الضغط المفاجئ يتحول إلى انقطاع كامل | البريد المزعج وتسجيل الدخول في Messenger | | هل نكتب تقرير ما بعد الحادثة وننشره داخلياً على الأقل؟ | الدرس يضيع مع أول تغيير في الفريق | مدونة Perspectives | ## الخلاصة وصلنا لنهاية القصة، وأهم ما فيها: - عمل James Hamilton ميكانيكياً للسيارات الإيطالية ست سنوات، ثم في IBM على DB2، ثم 12 سنة في Microsoft على SQL Server والخدمات المستضافة، وانضم إلى AWS في يناير 2009، وهو اليوم نائب رئيس أول ومهندس متميز في Amazon. - في أغسطس 2011 توقف أحد مراكز AWS في Virginia لأن برنامج الـ PLC في لوحة التحويل قرأ ارتفاعاً مفاجئاً في التيار من خارج المبنى على أنه قصر داخلي فأقفل المولد، ففرغ الـ UPS خلال دقائق. فراجعت AWS كود لوحات التحويل عند كل مورديها وأصبح قرار نقل التغذية لبرنامجها هي. - فكرته الأساسية أن الحدث النادر ليس نادراً على الحجم الكبير، ومنها جاءت ورقة 2007 بمبادئها الثلاثة، ونموذج مناطق التوافر بالكتابة المتزامنة بين مبان قريبة مستقلة. - نموذج الكلفة الذي نشره يبين أن السيرفرات قرابة 57% من الكلفة الشهرية، وأن الطاقة المحملة بالكامل قرابة 31%، وإعادة حسابه تبين أن الاستغلال يحرك الكلفة لكل وحدة عمل أكثر من سعر الكهرباء. - امتلاك AWS للعتاد، من محطات الكهرباء إلى Nitro وGraviton، كان لكل طبقة سبب محدد بالكلفة أو السرعة أو السيطرة على السلوك، وكله مشروط بحجم لا تملكه أغلب الشركات، فالدرس لنا أن نفهم ما داخل العتاد وليس أن نصنعه. - كتب كل ذلك في العلن على مدونة Perspectives منذ 2007، وعمل بدوام كامل من قاربه Dirona خلال دورة حول العالم استمرت 42 شهراً. المصادر الأساسية: صفحة James Hamilton ومدونته Perspectives، ومحاضراته في AWS re:Invent سنوات 2012 و2014 و2016، وورقتا LISA 2007 وThe Cost of a Cloud، وملخص AWS لحادثة أغسطس 2011، وموقع Dirona، وملف WIRED سنة 2013. [![](https://arabroot.io/content/images/2026/10/ha-concepts-cover-cover.webp)دليلمفاهيم التوفر العالي High Availability للمبتدئينماذا يعني أن تبقى خدمتك تعمل رغم تعطل جزء منها، وكيف تحسب التوفر وتجد نقاط الفشل الواحدة وتقرر متى يستحق ذلك تكلفته.](https://arabroot.io/articles/%D9%85%D9%81%D8%A7%D9%87%D9%8A%D9%85-%D8%A7%D9%84%D8%AA%D9%88%D9%81%D8%B1-%D8%A7%D9%84%D8%B9%D8%A7%D9%84%D9%8A-high-availability-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/system-design-intro-cover-cover.webp)دليلمدخل إلى تصميم الأنظمة: من سيرفر واحد إلى ملايين المستخدمينكيف يكبر متجر إلكتروني من سيرفر واحد إلى نظام يخدم ملايين المستخدمين، وما الثمن الذي تدفعه في كل خطوة.](https://arabroot.io/articles/%D9%85%D8%AF%D8%AE%D9%84-%D8%A7%D9%84%D9%89-%D8%AA%D8%B5%D9%85%D9%8A%D9%85-%D8%A7%D9%84%D8%A7%D9%86%D8%B8%D9%85%D8%A9-%D9%85%D9%86-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1-%D9%88%D8%A7%D8%AD%D8%AF-%D8%A7%D9%84%D9%89-%D9%85%D9%84%D8%A7%D9%8A%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/ovh-fire-cover-cover.webp)دليلحريق OVHcloud في ستراسبورغ: نسخ احتياطية احترقت مع البياناتماذا حدث في حريق مركز بيانات OVHcloud سنة 2021، ولماذا فقد عملاء نسخهم الاحتياطية، وكيف تتأكد أن نسختك خارج الموقع فعلاً.](https://arabroot.io/articles/%D8%AD%D8%B1%D9%8A%D9%82-%D9%85%D8%B1%D9%83%D8%B2-%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-ovhcloud-%D9%81%D9%8A-%D8%B3%D8%AA%D8%B1%D8%A7%D8%B3%D8%A8%D9%88%D8%B1%D8%BA/)[![](https://arabroot.io/content/images/2026/10/cloud-cost-cover-cover.webp)دليلالسحابة ليست دائماً الأرخص: متى يكون VPS أوفر؟مقارنة فواتير تطبيق واحد على AWS وعلى VPS وسيرفر مخصص بأسعار رسمية، ومتى تربح السحابة ومتى يربح السعر الثابت.](https://arabroot.io/articles/%D8%A7%D9%84%D8%B3%D8%AD%D8%A7%D8%A8%D8%A9-%D9%84%D9%8A%D8%B3%D8%AA-%D8%AF%D8%A7%D8%A6%D9%85%D8%A7-%D8%A7%D9%84%D8%A7%D8%B1%D8%AE%D8%B5-%D9%85%D8%AA%D9%89-%D8%AA%D9%83%D9%84%D9%81%D9%83-%D8%A7%D9%83%D8%AB%D8%B1-%D9%85%D9%86-vps/)[![](https://arabroot.io/content/images/2026/10/cloud-hidden-costs-cover-cover.webp)دليلالتكاليف الخفية في السحابة وكيف تخفضهاالبنود التي لا تظهر في حساب يوم التصميم ثم تملأ فاتورة السحابة بعد أشهر، وكيف تحسب كل بند وتخفضه.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D9%83%D8%A7%D9%84%D9%8A%D9%81-%D8%A7%D9%84%D8%AE%D9%81%D9%8A%D8%A9-%D9%81%D9%8A-%D8%A7%D9%84%D8%B3%D8%AD%D8%A7%D8%A8%D8%A9-egress-%D9%88%D8%A7%D9%84%D8%AA%D8%AE%D8%B2%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/build-vs-buy-cover-cover-1.webp)دليلتشتري أم تبني؟ قرار Build vs Buy بمعلومات ناقصةكيف تختار بين الخدمة الجاهزة والأداة مفتوحة المصدر والبناء الداخلي بحساب التكلفة الكاملة لثلاث سنوات وقابلية الرجوع عن القرار.](https://arabroot.io/articles/%D8%AA%D8%B4%D8%AA%D8%B1%D9%8A-%D8%A7%D9%85-%D8%AA%D8%A8%D9%86%D9%8A-%D8%A7%D9%84%D9%82%D8%B1%D8%A7%D8%B1-%D8%A8%D9%85%D8%B9%D9%84%D9%88%D9%85%D8%A7%D8%AA-%D9%86%D8%A7%D9%82%D8%B5%D8%A9/)[![](https://arabroot.io/content/images/2026/10/platform-sre-devops-cover-cover.webp)دليلDevOps وSRE وهندسة المنصات: أين يلتقي كل منها؟ما الذي يعنيه كل مصطلح فعلاً، وكيف تحسب ميزانية الأخطاء، وما شكل الفريق المناسب لحجم شركتك.](https://arabroot.io/articles/%D8%A7%D9%84%D9%81%D8%B1%D9%82-%D8%A8%D9%8A%D9%86-devops-%D9%88-sre-%D9%88-platform-engineering/)[![](https://arabroot.io/content/images/2026/10/kent-beck-facebook-cover-cover.webp)دليلقصة Kent Beck في Facebook وما تعلمه صاحب TDD هناككيف دخل صاحب TDD إلى Facebook فلم يسجل أحد في درسه، وماذا تعلم هناك، وما حقيقة قوله إنه طرد منها.](https://arabroot.io/articles/%D9%82%D8%B5%D8%A9-kent-beck-%D9%81%D9%8A-facebook/) ## سجل التحديثات - أكتوبر 2026: كتابة القصة من المصادر الأولية: محاضرات Hamilton في re:Invent 2012 و2014 و2016، وتدويناته، وورقتاه، وجدول البيانات الأصلي لنموذج الكلفة الذي أعدنا حسابه بلغة Python.