AWS

ماذا يحمل AWS، ولماذا يهمّ ذلك هنا

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

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

الاتصال قراءة فقط وبقائمة صريحة. قراءة حالة مهمة لا تحتاج صلاحية تشغيلها، وقراءة قائمة ملفات لا تحتاج صلاحية الكتابة فيها. وهذا التمييز هو ما يجعل الاتصال قابلاً للمراجعة.

• حالة الخدمات — ما يعمل وما تدهور وما هو مجدول.
• حالة المهام — انتهت أو أخفقت أو ما زالت جارية، ومتى.
• تخزين الملفات — وجود الملف وبياناته، ضمن مسارات محددة فقط.
• التكلفة والاستهلاك — أين يذهب الإنفاق، لمن يحقّ له.
• الوسوم والبيئات — إلى أي بيئة ينتمي المورد.

النطاق والتحكم من جهة AWS

الربط قراءة فقط. تحتوي السياسة على إجراءات الاطلاع والسرد والقراءة (describe وget وlist) على موارد مسمّاة، ولا شيء فيها يُنشئ أو يعدّل أو يحذف. معرفة حالة مهمة لا تحتاج صلاحية تشغيلها، ولذلك لا تُطلب هذه الصلاحية أصلاً.

والرؤية على طبقتين: سياسة IAM تحدد ما يستطيع الربط الوصول إليه من الأساس، وهوية السائل تحدد أيّ تلك الإجابات يحصل عليها هو.

أما بيانات الاعتماد فهوية IAM تنشئونها في حسابكم ولا يستخدمها غير هذا الربط. وإن كان الدور يُفترض (assume) من خارج الحساب فاضبطوا له معرّفاً خارجياً (external ID)، وهو الإجراء الذي توثّقه AWS لوصول الأطراف الثالثة. وإن لم يكن بدٌّ من مفتاح وصول فتدويره بأيديكم وبالجدول الذي تختارونه، وفصل السياسة أو حذف الهوية يسري من جهتكم دون الرجوع إلينا.

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

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

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

ما الذي يحلّ محلّه ربط AWS

ما يحلّ محلّه هذا هو طابور أمام عدد قليل من الناس. صلاحية لوحة التحكم مقيَّدة لأسباب وجيهة، فيتحول كل سؤال من خارج تلك المجموعة إلى مقاطعة — والإجابة في الغالب حقل واحد يقرأه أحدهم من شاشة.

والتكلفة غير مرئية لأنها موزّعة: دقيقتان هنا وخمس هناك، عدة مرات يومياً، على الأشخاص الذين تريدون مقاطعتهم أقل من غيرهم. لا أحد يسجّلها، فلا يراها أحد.

والاتصال يزيل الخطوة الوسيطة في الأسئلة ذات الإجابة المحددة، ويترك ما يحتاج حكماً — أو أي تغيير — حيث كان تماماً.

كيف تستفيدون فعلاً من ربط AWS

ابدأوا بالأسئلة التي تقاطع فريق السحابة أو المنصة اليوم. هي في العادة قليلة ومتكررة: هل انتهت مهمة الليل، وهل المشكلة عندنا أم عند AWS، وهل وصل الملف، وكم كلّف هذا المشروع الشهر الماضي. عدُّها في رسائل المحادثات والتذاكر لبضعة أسابيع يعطيكم قائمة الربط.

وإجابات السلامة لا تتجاوز جودة تنبيهات CloudWatch لديكم. فإن لم يكن على الخدمة ما يراقبها، فالجواب الصادق أنه لا شيء يراقبها. وحيث توجد التنبيهات، فإن إدخالها في النطاق مع أحداث AWS Health الخاصة بالحساب يتيح للمساعد التمييز بين عطل في أعمالكم وعطل في المنصة نفسها — أي سؤال «هل المشكلة عندنا أم عندهم؟» الذي ينتهي عادة عند مهندس. والوصول إلى AWS Health عبر API مرتبط بخطة الدعم التي لديكم مع AWS، فتحققوا منه قبل الوعد به.

وإجابات التكلفة والبيئات تعتمد على الوسوم. حين تحمل الموارد وسوماً متسقة للبيئة والمشروع والمالك، يكون لسؤال «كم تكلّف بيئة الاختبار؟» جواب واضح؛ وحين لا تحملها، لا يملك المساعد إلا أن ينقل الوسوم الموجودة. والوسوم التي يعرّفها المستخدم لا تظهر في بيانات التكلفة قبل تفعيلها وسوماً لتوزيع التكلفة (cost allocation tags) في لوحة الفوترة، وهذا سبب شائع لعودة أسئلة التكلفة بحسب الوسم فارغة.

البيانات الشخصية وموقع البيانات في ربط AWS

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

وموقع البيانات من جهة AWS تحدده المناطق التي اخترتموها لكل حمل عمل وكل حاوية. الربط يقرأ منها حيث هي، ولا ينقل البيانات المخزّنة بين المناطق أو الحسابات. دوّنوا الحسابات والمناطق المشمولة في الوثيقة نفسها التي تحمل سياسة IAM، لأن أي مراجعة — نظامية كانت أو داخلية — ستسأل أين توجد البيانات المصدرية، لا من يقرؤها فحسب.

وأغلب الأدلة في أيديكم أصلاً: سياسة IAM تجيب عن سؤال «ماذا يستطيع أن يقرأ؟»، وCloudTrail يجيب عن «ماذا قرأ فعلاً؟» — وكلاهما في حسابكم ويمكن مراجعته دون الرجوع إلينا.

طرق أخرى للإجابة عن أسئلة AWS، وما لكلٍّ منها وما عليه

لدى AWS أدواتها الخاصة. فـAmazon Q Developer يجيب عن أسئلة الموارد والتكلفة لمن سجّل الدخول إلى لوحة تحكم AWS، ضمن صلاحيات IAM الخاصة به، وتكامل المحادثة الذي تقدمه AWS ينشر التنبيهات والإشعارات في قنوات Slack أو Microsoft Teams. ولمن يعمل أصلاً داخل لوحة التحكم من المهندسين، هذه خيارات طبيعية.

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

وبعض الفرق تبني مساعدها الخاص على Amazon Lex أو Amazon Bedrock. وهذا يعني تحكماً كاملاً ومسؤولية كاملة: لا بد من جهة تملك نموذج الصلاحيات ومعالجة العربية والصيانة ما دام المساعد يعمل.

وأياً كان الطريق، فالإخفاق الذي يتكرر هو الصلاحية الواسعة. ربط سياسة ReadOnlyAccess الجاهزة من AWS سريع، لكنها تقرأ من الحساب أكثر بكثير مما يوحي به اسمها، بما في ذلك محتوى الملفات في S3. ولهذا تُكتب سياسة هذا الربط إجراءً إجراءً.