What is Chaos Engineering, principles تعلم دروس ماهي هندسة الفوضى
What is Chaos Engineering, principles ماهي هندسة الفوضى
What is Chaos Engineering, principles تعلم دروس ماهي هندسة الفوضى
نظرًا لتزايد تعقيد الويب جنبًا إلى جنب مع تقنيات مثل الحوسبة السحابية والأنظمة الموزعة والخدمات المصغرة ، يصعب التنبؤ بإخفاقات النظام. لمنع الانقطاعات ، لجأت الشركات الكبيرة والصغيرة إلى هندسة الفوضى كحل.
تتيح لك هندسة الفوضى التنبؤ بالفشل المحتمل وتحديده عن طريق كسر الأشياء عن قصد. بهذه الطريقة ، يمكنك البحث عن الأعطال وإصلاحها قبل أن تصبح انقطاعات. هندسة الفوضى هي اتجاه متزايد لفرق DevOps وتقنية المعلومات. حتى شركات مثل Netflix و Amazon تستخدم هذه المبادئ في تطوير المنتجات.
إذا كنت جديدًا في هندسة الفوضى ، فأنت في المكان الصحيح. اليوم ، سوف نقدم مبادئها بعمق ونوضح لك كيفية البدء مع Kubernetes.
سنتعلم: في دروس هندسة الفوضى التالي
- ما هي هندسة الفوضى؟
- أدوات هندسة الفوضى
- مبادئ وعملية هندسة الفوضى
- مثال هندسة الفوضى: تطبيق Kubernetes
- ماذا نتعلم بعد ذلك
تعلم كيفية تدمير أنظمتك بشكل منتج.
تعلم مبادئ هندسة الفوضى مع Kubernetes من خلال هذا الغوص العميق في تجارب الفوضى ، مثل تدمير الشبكة ، واستنزاف العقد ، واختبار التوافر ، والمزيد.
ما هي هندسة الفوضى؟ chaos Engineering
هندسة الفوضى هي تخصص للتجربة على نظام لبناء الثقة في قدرة النظام على تحمل الظروف المضطربة في الإنتاج. من خلال هندسة الفوضى ، نحاول عمدًا كسر نظامنا تحت ضغوط معينة لتحديد الانقطاعات المحتملة ، وتحديد موقع الضعف ، وتحسين المرونة.
تختلف هندسة الفوضى عن اختبار البرامج أو حقن الأخطاء. تُستخدم هندسة الفوضى لجميع أنواع المتطلبات والمواقف غير المتوقعة ، بما في ذلك الزيادات في حركة المرور وظروف السباق والمزيد.
مع هندسة الفوضى ، نحاول أن نتعلم كيف يتفاعل النظام بأكمله عندما يفشل مكون فردي.
على سبيل المثال ، يمكن أن تساعد هندسة الفوضى في الإجابة على أسئلة الوظائف مثل هذه:
ماذا يحدث عندما لا يمكن الوصول إلى الخدمة بطريقة أو بأخرى؟
ما هي نتيجة الانقطاعات عندما يتلقى التطبيق عددًا كبيرًا جدًا من الزيارات أو عندما لا يكون متاحًا؟
هل سنواجه أخطاء متتالية عندما تعطل نقطة فشل واحدة أحد التطبيقات؟
ماذا يحدث عندما ينخفض طلبنا؟
ماذا يحدث عندما يكون هناك خطأ ما في الشبكات؟
التاريخ: تم تطوير Chaos Engineering لأول مرة في Netflix في عام 2008 عندما تم نقل خدمة بث الاشتراك إلى السحابة العامة. لاحظ مهندسو Netflix أنهم بحاجة إلى طرق جديدة لاختبار هذا النظام من أجل المرونة.
تم إنشاء Chaos Monkey في عام 2010 لهذا الغرض. منذ ذلك الحين ، نمت هندسة الفوضى ، وطبقت شركات مثل Google و Facebook و Amazon و Microsoft نماذج اختبار مماثلة.
فوائد هندسة الفوضى Chaos Engineering
تقدم هندسة الفوضى العديد من الفوائد التي لا تقدمها الأشكال الأخرى من اختبار البرامج أو اختبار الفشل. يمكن لاختبارات الفشل فحص حالة واحدة فقط في الانهيار الثنائي. هذا لا يسمح لنا باختبار نظام تحت ضغوط غير مسبوقة أو غير متوقعة.
من ناحية أخرى ، يمكن أن تمثل هندسة الفوضى مشكلات معقدة ومتنوعة وحقيقية أو حالات انقطاع الخدمة. باستخدام هندسة الفوضى ، يمكننا إصلاح المشكلات واكتساب رؤى جديدة حول أحد التطبيقات من أجل التحسينات المستقبلية.
تساعد تجارب الفوضى على تقليل حالات الفشل والانقطاع مع تحسين فهمنا لتصميم نظامنا. تعمل هندسة الفوضى على تحسين مدى توفر الخدمة وقوة تحملها ، وبالتالي يقل اضطراب العملاء بسبب الانقطاعات. يمكن أن تساعد هندسة الفوضى أيضًا في منع خسائر الإيرادات وخفض تكاليف الصيانة على مستوى الأعمال.
أدوات هندسة الفوضى chaos Engineering
قبل أن نبدأ في تحديد تجارب الفوضى وإجرائها ، نحتاج إلى اختيار أداة. هندسة الفوضى ليست بعد جزءًا من السوق الراسخ والمتطور. ومع ذلك ، هناك العديد من الأدوات التي يمكننا الاختيار من بينها.
تعد Simian Army ، التي طورتها Netflix ، واحدة من أبرز أدوات هندسة الفوضى. Simian Army هو الأفضل للخدمات في السحابة و AWS. يمكن أن تولد الفشل واكتشاف العيوب. Chaos Monkey من Netflix هي أداة مرونة لحالات الفشل العشوائي.
PowerfulSeal هي أداة قوية لاختبار مجموعات Kubernetes ، ويمكن استخدام Litmus لأحمال العمل ذات الحالة على Kubernetes. يستخدم Pumba مع Docker لاختبار الفوضى ومحاكاة الشبكة. تقدم Gremlin منصة هندسة الفوضى التي تدعم الآن الاختبار على مجموعات Kubernetes.
يستخدم Chaos Dingo بشكل شائع مع Microsoft Azure ، ويمكن استخدام وكيل Chaos HTTP لإدخال الإخفاقات في طلبات HTTP.
مبادئ وعملية هندسة الفوضى chaos Engineering
نظرًا لإجراء المزيد من الفرق للتجارب على مر السنين ، فقد تعلموا كيفية تطبيق مناهج هندسة الفوضى على أنظمتهم بشكل أكثر فعالية. أصبحت أفضل الممارسات هذه هي المبادئ الأساسية لهندسة الفوضى. دعونا نناقش المبادئ الأساسية لهندسة الفوضى التي يجب على كل فريق تنفيذها في تجاربهم.
بناء فرضية حول الحالة المستقرة
تريد بناء فرضية حول سلوك الحالة المستقرة. بعد ذلك ، تريد تنفيذ إجراءات قد تكون ضارة على زمن انتقال الشبكة أو التطبيقات أو العقد أو أي مكون آخر من مكونات النظام.
أنت تريد خلق مواقف عنيفة لتأكيد أن فرضية الحالة المستقرة لدينا صحيحة. إنك تهدف إلى التحقق من أنه عندما يكون نظامنا في حالة معينة ، فإنه يؤدي إجراءات معينة ، وينتهي بنفس التحقق من الصحة للتأكد من أن الحالة لم تتغير.
محاكاة أحداث العالم الحقيقي
تريد القيام بهندسة الفوضى بناءً على أحداث العالم الحقيقي. بمعنى آخر ، قم فقط بتكرار الأحداث التي من المحتمل أن تحدث في نظامنا. يتضمن ذلك تعطل التطبيق أو تعطل الشبكة أو فشل العقدة.
إجراء تجارب في الإنتاج Chaos Engineering
تريد إجراء تجارب الفوضى في الإنتاج. تريد تجربة الإنتاج لأن هذا هو النظام "الحقيقي". إذا قمت بإجراء تجارب الفوضى فقط أثناء التدريج أو التكامل ، فلن تتمكن من الحصول على صورة حقيقية لكيفية سلوك النظام في الإنتاج.
أتمتة التجارب وتشغيلها بشكل مستمر
تريد أتمتة تجاربنا للتشغيل بشكل مستمر أو يتم تنفيذها كجزء من خطوط أنابيب التسليم المستمر. قد يعني هذا كل ساعة ، كل بضع ساعات ، كل يوم ، كل أسبوع ، أو في كل مرة يحدث فيها حدث ما في نظامنا. أنت أيضًا تريد إجراء تجارب في كل مرة تنشر فيها إصدارًا جديدًا.
تقليل نصف قطر الانفجار Chaos Engineering
يجب عليك تقليل نصف قطر الانفجار لتجاربنا. عندما تبدأ بتجارب الفوضى ، فأنت تريد أن تبدأ صغيرًا وتتراكم بينما تكتسب الثقة في النظام. في النهاية ، يجب عليك إجراء تجارب عبر النظام بأكمله.
ملخص المبادئ Chaos Engineering
قم ببناء فرضية حول حالة الاستقرار
محاكاة أحداث العالم الحقيقي
إجراء تجارب في الإنتاج
أتمتة التجارب وتشغيلها بشكل مستمر
تقليل نصف قطر الانفجار
عملية هندسة الفوضى chaos Engineering
تبدو العملية العامة لهندسة الفوضى كما يلي:
حدد فرضية الحالة المستقرة: عليك أن تبدأ بفكرة عما يمكن أن ينحرف. ابدأ بالفشل في الحقن والتنبؤ بالنتيجة عند تشغيله على الهواء مباشرة.
قم بتأكيد الحالة المستقرة ومحاكاة بعض أحداث العالم الحقيقي: قم بإجراء اختبارات باستخدام سيناريوهات العالم الحقيقي لمعرفة كيف يتصرف نظامك في ظل ظروف أو ظروف ضغط معينة.
قم بتأكيد الحالة المستقرة مرة أخرى: نحتاج إلى تأكيد التغييرات التي حدثت ، لذا فإن التحقق منها مرة أخرى يعطينا نظرة ثاقبة حول سلوك النظام.
جمع المقاييس ومراقبة لوحات المعلومات: تحتاج إلى قياس متانة نظامك ومدى توفره. من أفضل الممارسات استخدام مقاييس الأداء الرئيسية التي ترتبط بنجاح العميل أو استخدامه. نريد قياس الفشل مقابل فرضيتنا من خلال النظر في عوامل مثل التأثير على زمن الوصول أو الطلبات في الثانية.
قم بإجراء التغييرات وإصلاح المشكلات: بعد إجراء التجربة ، يجب أن تكون لديك فكرة جيدة عما ينجح وما يجب تغييره. الآن يمكننا تحديد ما سيؤدي إلى انقطاع التيار الكهربائي ، ونعرف بالضبط ما الذي يكسر النظام. لذا ، قم بإصلاحه ، وحاول مرة أخرى بتجربة جديدة.
مثال هندسة الفوضى chaos Engineering example
دعنا الآن نطبق كل هذه النظرية على مثال من العالم الحقيقي لفهم هندسة الفوضى بشكل أفضل. سنستخدم Kubernetes. للبدء ، نقوم بإنشاء مجموعة Kubernetes. بعد ذلك ، سنقوم بنشر تطبيقنا البسيط وندمره. بعد ذلك ، سنوضح لك كيفية تحديد الحالات المستقرة ، وهو أمر بالغ الأهمية لهندسة الفوضى.
ملاحظة: إذا كنت جديدًا في Kubernetes ، فنحن نوصي بالدورة التدريبية A دليل عملي لـ Kubernetes قبل متابعة هندسة الفوضى. أو يمكنك المتابعة فقط للحصول على فكرة عن شكل هندسة الفوضى الأساسية.
أنشئ مجموعة Kubernetes
أولاً ، نحتاج إلى مجموعة Kubernetes لتدميرها. يمكنك اختيار Minikube و Docker Desktop و AKS و EKS و GKE. أدناه ، نستخدم Docker Desktop لإنشاء مجموعة. إذا كنت ترغب في معرفة كيفية إنشاء مجموعة باستخدام الأدوات الأخرى ، يرجى الرجوع إلى الدورة التدريبية مجموعة أدوات DevOps: Kubernetes Chaos Engineering.
انسخالكود واستكشف المستودع
نحتاج إلى نشر تطبيق تجريبي أعددناه أدناه. سنقوم باستنساخ مستودع vfarcic / go-demo-8 الذي أنشأه فيكتور فارسيتش.
git clone https://github.com/vfarcic/go-demo-8.git
بعد ذلك ، ندخل إلى الدليل حيث قمنا بنسخه المستودع.
cd go-demo-8
git pull
الآن ، قم بإنشاء مساحة اسم تسمى go-demo-8.
kubectl create namespace go-demo-8
الآن ، دعنا نلقي نظرة سريعة على التطبيق الذي سننشره ، والموجود في دليل pod-pods ، في ملف يسمى pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
name: go-demo-8
labels:
app: go-demo-8
spec:
containers:
- name: go-demo-8
image: vfarcic/go-demo-8:0.0.1
env:
- name: DB
value: go-demo-8-db
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /
port: 8080
readinessProbe:
httpGet:
path: /
port: 8080
resources:
limits:
cpu: 100m
memory: 50Mi
requests:
cpu: 50m
memory: 20Mi
يُعرَّف هذا التطبيق بأنه قرص واحد به حاوية واحدة تسمى go-demo-8. وهو يتضمن موارد أخرى مثل livenessProbe وreadinessProbe.
استمر في التعلم. Chaos Engineering
تعلم هندسة الفوضى لـ Kubernetes دون الحاجة إلى البحث في مقاطع الفيديو أو الوثائق. من السهل تخطي الدورات التعليمية القائمة على النصوص وتضمين بيئات البرمجة الحية ، مما يجعل التعلم سريعًا وفعالًا.
دليل عملي لـ Kubernetes
تطبيق التعريف على الكتلة
الآن ، نطبق هذا التعريف على مجموعتنا داخل مساحة الاسم go-demo-8. سيؤدي هذا إلى تشغيل تطبيقنا كجهاز Pod.
kubectl --namespace go-demo-8 apply --filename k8s/terminate-pods/pod.yamlحان الوقت الآن لتطبيق بعض الضرر وتدمير تطبيقنا!
قم بتثبيت البرنامج الإضافي Chaos Toolkit Kubernetes
لإجراء تجارب الفوضى على تطبيقنا ، يمكننا استخدام مكون Chaos Toolkit الإضافي لـ Kubernetes. لا تدعم مجموعة الأدوات هذه Kubernetes الجاهزة. نحتاج إلى مكون إضافي للميزات التي تتجاوز الميزات الأساسية الجاهزة. دعنا نثبت مكون Kubernetes الإضافي باستخدام pip.
pip install -U chaostoolkit-kubernetesملاحظة: استكشف المكوّن الإضافي Chaos Toolkit باستخدام الأمر Discover لمعرفة كل ميزاته وخياراته ووسائطه.
إنهاء مثيلات التطبيق
دعونا نبدأ في تدمير الأشياء. انظر إلى التعريف الأول الذي سنستخدمه ، والموجود في دليل الفوضى ، في ملف fileterminate-pod.yaml.
cat chaos/terminate-pod.yaml
هذا يعطينا الناتج التالي:
version: 1.0.0
title: What happens if we terminate a Pod?
description: If a Pod is terminated, a new one should be created in its places.
tags:
- k8s
- pod
method:
- type: action
name: terminate-pod
provider:
type: python
module: chaosk8s.pod.actions
func: terminate_pods
arguments:
label_selector: app=go-demo-8
rand: true
ns: go-demo-8
الآن بعد أن رأينا التعريف ، فلنقم بتشغيل terminate-pod.yaml.
chaos run chaos/terminate-pod.yaml
الإخراج كما يلي:
[... INFO] Validating the experiment's syntax
[... INFO] Experiment looks valid
[... INFO] Running experiment: What happens if we terminate a Pod?
[... INFO] No steady state hypothesis defined. That's ok, just exploring.
[... INFO] Action: terminate-pod
[... INFO] No steady state hypothesis defined. That's ok, just exploring.
[... INFO] Let's rollback...
[... INFO] No declared rollbacks, let's move on.
[... INFO] Experiment ended with status: completedبعد التحقق الأولي ، نفذت التجربة المسماة ماذا يحدث إذا أنهينا Pod؟ ووجدت أنه لا توجد فرضية ثابتة محددة. اذا حكمنا من خلال الإخراج ، هناك إجراء واحد إنهاء.
بعد ذلك ، عادت إلى فرضية الحالة المستقرة وقررت عدم وجود أي منها. ثم حاولت التراجع ، ووجدت أنها لا تستطيع. كل ما فعلناه حتى الآن هو تنفيذ إجراء لإنهاء Pod. يمكننا أن نرى النتيجة في السطر الأخير: انتهت التجربة بالحالة: مكتملة.
الآن ، لنخرج كود الخروج للأمر السابق. إذا حصلنا على 0 ، فهذا يعني النجاح في Linux. تخبر أكواد الخروج هذه النظام ما إذا كان فاشلاً أو ناجحًا!
الآن ، دعنا نلقي نظرة على البودات في مساحة الأسماء الخاصة بنا.
kubectl --namespace go-demo-8 get podsيوضح الناتج أنه لم يتم العثور على أي موارد في مساحة الاسم go-demo-8. نشرنا الحاوية الفردية وأجرينا تجربة دمرتها. لم نقم بأي عمليات تحقق. قمنا بتنفيذ إجراء واحد لإنهاء Pod ، والذي كان ناجحًا.
تعريف الحالات المستقرة state steady
أعلاه ، كل ما فعلناه هو تدمير بود. ومع ذلك ، فإن الهدف من هندسة الفوضى هو العثور على نقاط الضعف في مجموعاتنا. لذلك ، نبدأ عادةً في تحديد الحالة المستقرة التي نختبرها قبل التجربة وبعدها.
إذا كانت الحالة هي نفسها قبل وبعد ، فيمكننا أن نستنتج أن مجموعتنا تتسامح مع الخطأ في هذه الحالة. في حالة Chaos Toolkit ، نحقق ذلك من خلال تحديد فرضية الحالة المستقرة.
سننظر في تعريف يحدد الحالة التي سيتم التحقق من صحتها قبل وبعد إجراء ما.
cat chaos/terminate-pod-ssh.yaml
سوف يعطينا الإخراج:
> steady-state-hypothesis:
> title: Pod exists
> probes:
> - name: pod-exists
> type: probe
> tolerance: 1
> provider:
> type: python
> func: count_pods
> module: chaosk8s.pod.probes
> arguments:
> label_selector: app=go-demo-8
> ns: go-demo-8
القسم الجديد هو فرضية الحالة المستقرة steady-state-hypothesis. الآن يمكننا إجراء تجربة فوضى مناسبة لاختبار حالتنا المستقرة.
إجراء تجربة الفوضى وفحص المخرجات
دعونا نجري تجربة الفوضى لرؤية النتيجة الصحيحة.
chaos run chaos/terminate-pod-ssh.yaml
نحصل على ما يلي::
[... INFO] Validating the experiment's syntax
[... INFO] Experiment looks valid
[... INFO] Running experiment: What happens if we terminate a Pod?
[... INFO] Steady state hypothesis: Pod exists
[... INFO] Probe: pod-exists
[... CRITICAL] Steady state probe 'pod-exists' is not in the given tolerance so failing this experiment
[... INFO] Let's rollback...
[... INFO] No declared rollbacks, let's move on.
[... INFO] Experiment ended with status: failedهناك مشكلة حرجة هنا: مسبار الحالة الثابتة "pod-موجود" ليس في التوجه المحدد. فشل التحقيق قبل تنفيذ الإجراءات لأننا دمرنا البود. لذا فشلت تجربتنا وأكدت أن الحالة الأولية لا تتطابق مع ما نريد.
لذلك ، دعنا نطبق تعريف terminate-pods / pod.yaml لإعادة إنشاء Pod. بعد ذلك ، يمكننا أن نرى ما يحدث عندما نعيد تشغيل التجربة بفرضية الحالة المستقرة.
kubectl --namespace go-demo-8 apply --filename k8s/terminate-pods/pod.yaml
أعد تشغيل التجربة
مع ظهر جرابنا ، ويمكن إعادة تشغيل التجربة.
chaos run chaos/terminate-pod-ssh.yamlالإخراج كما يلي:
[... INFO] Validating the experiment's syntax
[... INFO] Experiment looks valid
[... INFO] Running experiment: What happens if we terminate a Pod?
[... INFO] Steady state hypothesis: Pod exists
[... INFO] Probe: pod-exists
[... INFO] Steady state hypothesis is met!
[... INFO] Action: terminate-pod
[... INFO] Steady state hypothesis: Pod exists
[... INFO] Probe: pod-exists
[... INFO] Steady state hypothesis is met!
[... INFO] Let's rollback...
[... INFO] No declared rollbacks, let's move on.
[... INFO] Experiment ended with status: completed
الآن ، نرى أن جراب المسبار قد أكد الحالة الصحيحة وتم تنفيذ الإجراء. يمكننا أيضًا أن نرى أنه تم إعادة تقييم الحالة المستقرة. كان Pod موجودًا قبل الإجراء ، وكان Pod موجودًا بعد الإجراء. ولكن ، واو يمكن أن توجد البودات إذا قمنا بتدميرها؟
أضف وقفة توقف
لم تفشل التجربة لأن تحقيقاتنا وإجراءاتنا نُفِّذت بعد بعضها البعض مباشرة. لم يكن لدى Kubernetes الوقت الكافي لإزالة الكبسولة بالكامل. لذا ، نحن بحاجة إلى إضافة وقفة لجعل التجربة أكثر فائدة. دعونا نلقي نظرة على YAML.
cat chaos/terminate-pod-pause.yamlيعطينا الناتج التالي:
> pauses:
> after: 10نرى هنا أننا أضفنا قسم توقف مؤقتًا بعد الإجراء الذي ينهي Pod. الآن ، عندما ننفذ الإجراء لإنهاء Pod ، سينتظر النظام 10 ثوانٍ قبل التحقق من صحة حالتنا.
قم بتشغيل التجربة مع وقفة
دعونا نرى ما نحصل عليه إذا نفذنا هذه التجربة مع توقفنا.
chaos run chaos/terminate-pod-pausyamlيعطينا الناتج التالي:
[... INFO] Validating the experiment's syntax
[... INFO] Experiment looks valid
[... INFO] Running experiment: What happens if we terminate a Pod?
[... INFO] Steady state hypothesis: Pod exists
[... INFO] Probe: pod-exists
[... INFO] Steady state hypothesis is met!
[... INFO] Action: terminate-pod
[... INFO] Pausing after activity for 10s...
[... INFO] Steady state hypothesis: Pod exists
[... INFO] Probe: pod-exists
[... CRITICAL] Steady state probe 'pod-exists' is not in the given tolerance so failing this experiment
[... INFO] Let's rollback...
[... INFO] No declared rollbacks, let's move on.
[... INFO] Experiment ended with status: deviated
[... INFO] The steady-state has deviated, a weakness may have been discoveredهذه المرة ، فشل المسبار وقال إن مسبار الحالة المستقرة "pod-موجود" ليس في التسامح المحدد لذلك فشل هذه التجربة. الآن ، أعطينا Kubernetes وقتًا كافيًا لإزالة Pod ، ثم تحققنا مما إذا كان Pod لا يزال موجودًا.
عاد النظام إلينا قائلاً إن البود غير موجود. يمكننا إخراج كود الخروج للأمر الأخير لنرى أنه فشل بالفعل.
ماذا نتعلم بعد ذلك
مدهش! لقد دمرنا تطبيقنا بشكل فعال باستخدام حالة الاستقرار وتعلمنا أساسيات هندسة الفوضى. بعد ذلك ، نرغب في إصلاح الأخطاء التي أنشأناها لجعلها تتسامح مع الأخطاء.
من هناك ، يمكننا القيام بجميع أنواع التدمير والاختبار لتطبيقنا مثل:
فحص المراحل والشروط
تجربة التوافر
عقد الصرف
تنفيذ فوضى عشوائية
و اكثر
لمعرفة كيفية تنفيذ المزيد من تجارب الفوضى ، فإن الدورة التعليمية التي يقدمها برنامج DevOps Toolkit: Kubernetes Chaos Engineering هي أفضل خطوة تالية. ستتعرف على الأنواع المختلفة من التجارب التي يمكنك إجراؤها في هندسة الفوضى. قرب نهاية الدورة ، ستتعلم كيفية إجراء التجارب في مجموعة Kubernetes. في النهاية ، ستكون مهندس فوضى واثقًا.
<< الصفحة الرئيسية