M C

Loading

Blog

طريقة آمنة لاكتشاف الموارد غير المستخدمة في منصة جوجل كلاود

سير عمل عملي للقراءة فقط لتحديد موارد Google Cloud غير المستخدمة، وربطها بالمالكين والتكاليف، والموافقة على تنظيفها دون تعريض بيئة الإنتاج للخطر.

طريقة آمنة لاكتشاف الموارد غير المستخدمة في منصة جوجل كلاود

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

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

لماذا تحتاج الموارد غير المستخدمة إلى سجل أدلة

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

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

بالنسبة إلى الفرق التي تعتمد أنماط وصول مضبوطة، تنطبق هنا العقلية نفسها الكامنة وراء وصول Looker للقراءة فقط عبر MCP. امنح الأشخاص معلومات كافية للتحقيق واتخاذ القرار من دون منح سير عمل الإبلاغ القدرة على تغيير البنية التحتية الحية.

سير عمل للقراءة فقط لتنظيف منصة جوجل كلاود

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

1. أنشئ مخزونا في نقطة زمنية محددة

ابدأ بـ Cloud Asset Inventory بدلا من مجموعة من البرامج النصية الخاصة بكل خدمة. إذ يمكنه تصدير بيانات الأصول الوصفية عبر مؤسسة ومجلدات ومشاريع إلى BigQuery، مما ينشئ لقطة قابلة للاستعلام من بيانات الموارد الوصفية. ويمكن أن يتضمن التصدير أسماء الموارد وأنواعها وتسلسلها الهرمي والتصنيفات والوسوم، وهي تشكل أساس سجل المخزون. تصدير بيانات الأصول الوصفية إلى BigQuery | Cloud Asset Inventory

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

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

2. أضف إشارات التوصيات والاستخدام

يحدد المخزون المرشحين، لكنه لا يثبت الهدر. أضف إشارات من Active Assist وRecommender. توثق Google تصدير التوصيات إلى BigQuery عبر BigQuery Data Transfer Service، بما في ذلك التوصيات الخاصة بمثيلات VM الخاملة، والأقراص الدائمة غير المرفقة، وعناوين IP الخاملة، والمشاريع غير المراقبة. ويمكن أن تشمل البيانات المصدرة أيضا أثر التكلفة ومعلومات الملاحظة للتحليل. تصدير التوصيات إلى BigQuery | Recommender

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

على سبيل المثال، يمكن أن يكون القرص المفصول مرشحا قويا عندما لا تكون له حاجة استعادة معروفة، ولا توجد استجابة من المالك، وتوجد إشارة توصية مستمرة. أما الخدمة منخفضة الحركة فدلالتها أقل حسما. فقد تكون خدمة google cloud run مخفضة السعة عمدا بين أعباء العمل المدفوعة بالأحداث، لذا تحتاج دورة حياتها وسجل نشرها ومالكها التجاري إلى مراجعة قبل التنظيف.

3. حدد الملكية قبل إسناد اللوم

تخصيص التكلفة هو الجسر بين المخزون التقني والقرار الذي يمكن لشخص ما اتخاذه بمسؤولية. تصف FinOps Foundation تخصيص التكلفة بأنه إسناد تكاليف السحابة إلى أصحاب المصلحة الخاضعين للمساءلة من خلال آليات مثل الحسابات والوسوم والتصنيفات والتجميعات الهرمية. إطار عمل FinOps: تخصيص التكلفة

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

حدد عقدا صغيرا من التصنيفات المطلوبة لأحمال العمل الجديدة: التطبيق، والفريق، والبيئة، ومركز التكلفة، ودورة الحياة أو تاريخ الانتهاء عند الحاجة. لا يلزم أن تكون القيم مثالية في اليوم الأول. فبيانات الملكية المتسقة أثمن من تصنيف موسع لا يحافظ عليه أحد.

استخدم نموذج ثقة بدلا من قائمة حذف

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

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

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

اربط الأدلة التقنية بسياق الفوترة

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

تؤكد قدرة تحسين الاستخدام في إطار FinOps على التحديد والتحسين المستمرين لاستخدام السحابة بالتعاون مع أصحاب المصلحة. وهذا يدعم عملية متكررة بدلا من عملية تطهير سنوية للموارد. إطار عمل FinOps: تحسين الاستخدام

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

بالنسبة إلى google cloud project غير مراقب، وسع نطاق الأدلة إلى ما وراء إشارة الخدمة غير النشطة. راجع IAM للمشروع، وربط الفوترة، ونشاط التدقيق الأخير، وتبعيات الشبكة، وآثار سياسات المؤسسة، وأعمال الترحيل المعروفة. يمكن لحذف المشروع أن يؤثر في عدة google cloud services، لذا ينبغي التعامل معه كحدث مقصود ومعتمد في دورة الحياة، لا كاختصار للتنظيف.

صمم قائمة الموافقات حول القرارات الفعلية

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

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

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

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

أين يناسب نهج السياسة كرمز بأمان

تعد السياسة كرمز مفيدة للاكتشاف والإشعارات المتسقة. يدعم Cloud Custodian سياسات Google Cloud ويوثق أساليب التشغيل التجريبي أو المعتمد على المعلومات، ما يتيح للفرق تقييم السياسات وإرسال النتائج من دون معالجة الموارد فورا. توثيق Cloud Custodian لـ Google Cloud

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

يفيد ذلك بشكل خاص المؤسسين التقنيين الذين يحتاجون إلى إشراف من دون وظيفة FinOps كبيرة. كما يتكامل جيدا مع قائمة تحقق من صحة صور السحابة: إذ تحول الممارستان افتراضات التشغيل الخطرة إلى أدلة ومراجعة وضوابط قابلة للتكرار.

قائمة تنفيذ لأول 30 يوما

  • اختر نطاقا تجريبيا، مثل مجلد واحد أو وحدة أعمال أو بيئة غير إنتاجية.
  • صدر لقطة من Cloud Asset Inventory إلى BigQuery ووثق الحقول التي سيحتفظ بها فريقك.
  • صدر رؤى Recommender ذات الصلة إلى BigQuery واحفظ سياق توصياتها.
  • حدد أولوية الملكية والحد الأدنى لعقد تصنيفات الموارد.
  • أنشئ قائمة مراجعة تحتوي على روابط الأدلة والمالك ومستوى الثقة والإجراء المقترح وتاريخ الانتهاء.
  • راجع النتائج مع مالكي التطبيقات قبل تحديد أي تاريخ للإزالة.
  • سجل نتائج الاحتفاظ والإيجابيات الكاذبة لتحسين القواعد المستقبلية.
  • فقط بعد استقرار دورة المراجعة، فكر في أتمتة تنفذ الإجراءات المعتمدة مسبقا.

يمثل هذا النهج أيضا إجابة عملية عن ما هي منصة جوجل كلاود من منظور نموذج التشغيل. فهي، إلى جانب كونها مجموعة من المنتجات المدارة، بيئة ينبغي إدارة خدماتها ومشاريعها وهوياتها وتكاليفها وإشارات ملكيتها معا. سواء كان فريقك يتعلم عبر google cloud skills boost، أو يخطط لـ google cloud next، أو يدير أحمال عمل ناضجة، فإن هذه الرؤية المشتركة تجعل ضبط التكاليف أكثر أمانا.

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

المصادر

FAQ

كيف أجد موارد Google Cloud غير المستخدمة من دون حذف أي شيء؟

صدر بيانات الموارد الوصفية باستخدام Cloud Asset Inventory، وأضف نتائج Recommender، وأرسل المرشحين إلى قائمة موافقات. أبق هويات وسياسات الاكتشاف للقراءة فقط إلى أن يحظى إجراء تنظيف محدد بموافقة موثقة.

هل يستطيع Recommender إثبات أن المورد آمن للإزالة؟

لا. يقدم Recommender إشارات وسياقا مفيدين للتحسين، لكن تبعيات الخدمة ومتطلبات الاستعادة والتوقيت التجاري لا تزال تتطلب مراجعة من المالك قبل الإزالة.

ما الموارد التي ينبغي أن يفحصها المشروع التجريبي للتنظيف أولا؟

ابدأ بأنواع الموارد التي لها إشارات واضحة، مثل توصيات مثيلات VM الخاملة، والأقراص الدائمة غير المرفقة، وعناوين IP الخاملة، والمشاريع غير المراقبة. حافظ على نطاق المشروع التجريبي محدودا بما يكفي ليتمكن المالكون من مراجعة كل نتيجة.

ما التصنيفات التي تساعد على تعيين الملكية لتنظيف السحابة؟

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

متى ينبغي السماح لأتمتة التنظيف بإجراء تغييرات؟

اسمح بذلك فقط بعد التحقق من قواعد الاكتشاف والاستثناءات وتعيين الملكية وعملية الموافقة وتوقعات الاستعادة. ينبغي للأتمتة تنفيذ موافقة مسجلة، لا استبدال قرار الموافقة.

ملاحظة تحريرية: ساعد الذكاء الاصطناعي في البحث والصياغة. اختيرت المصادر للتحقق.

Mohamed CHAMI — Full-Stack Developer

Full-Stack Developer & Solutions Architect · Casablanca, Morocco

8+ years building Java/Spring Boot/Angular enterprise solutions. Former Senior Software Engineer at NTT Data and Satec. Authorized Google Workspace and Microsoft 365 Partner for Morocco.

من هو محمد شامي؟

LinkedIn · GitHub · Contact

Leave a Comment

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها بـ *