ما وراء الصفارة: إتقان الاستجابة للحوادث من خلال أتمتة نظام التنبيهات

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

تطورت التنبيهات الحديثة. لم يعد مجرد نظام إشعارات؛ إنه الجهاز العصبي المركزي للاستجابة الآلية للحوادث. إنها نقطة الزناد لسلسلة من الإجراءات الذكية المصممة لتشخيص المشكلات ومعالجتها وحلها قبل أن يضطر الإنسان إلى التدخل. هذا الدليل مخصص لمهندسي موثوقية الموقع (SREs) ومحترفي DevOps وفرق عمليات تكنولوجيا المعلومات وقادة الهندسة المستعدين للانتقال إلى ما وراء الصفارة. سنستكشف المبادئ والممارسات والأدوات اللازمة لتحويل استراتيجية التنبيه الخاصة بك من نموذج إعلامي تفاعلي إلى محرك حل استباقي وآلي.

تطور التنبيه: من مجرد إشارات إلى التنسيق الذكي

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

المرحلة 1: العصر اليدوي - "هناك شيء معطل!"

في الأيام الأولى لتكنولوجيا المعلومات، كانت المراقبة بدائية. قد يتحقق البرنامج النصي مما إذا كان استخدام وحدة المعالجة المركزية للخادم قد تجاوز عتبة 90٪، وإذا كان الأمر كذلك، فأرسل بريدًا إلكترونيًا إلى قائمة التوزيع. لم يكن هناك جدول زمني للاستدعاء، ولا تصعيد، ولا سياق. كان التنبيه بيانًا بسيطًا، وغالبًا ما يكون غامضًا، للواقعة. كانت الاستجابة يدوية تمامًا: تسجيل الدخول والتحقيق والإصلاح. أدى هذا النهج إلى فترات حل طويلة (MTTR - متوسط ​​الوقت للحل) وتطلب معرفة عميقة بالنظام من كل مشغل.

المرحلة 2: عصر الإخطار - "استيقظ، أيها الإنسان!"

مثل ظهور منصات التنبيه المتخصصة مثل PagerDuty وOpsgenie (الآن Jira Service Management) وVictorOps (الآن Splunk On-Call) قفزة كبيرة إلى الأمام. قامت هذه الأدوات بإضفاء الطابع الاحترافي على فعل الإخطار. لقد قدموا مفاهيم مهمة أصبحت الآن معيارًا في الصناعة:

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

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

المرحلة 3: عصر الأتمتة - "دع النظام يتعامل مع الأمر."

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

المبادئ الأساسية لأتمتة الاستجابة للحوادث

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

المبدأ 1: التنبيهات القابلة للتنفيذ فقط

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

يجب أن يجتاز كل تنبيه في نظامك اختبار "SO WHAT؟". عندما يتم تنشيط تنبيه، ما هو الإجراء المحدد الذي يجب اتخاذه؟ إذا كانت الإجابة غامضة أو "أحتاج إلى التحقيق لمدة 20 دقيقة لمعرفة ذلك"، فيجب تحسين التنبيه. غالبًا ما يكون تنبيه وحدة المعالجة المركزية المرتفعة مجرد ضوضاء. تنبيه "كمون P99 الذي يواجهه المستخدم قد انتهك هدف مستوى الخدمة (SLO) لمدة 5 دقائق" هو إشارة واضحة لتأثير المستخدم ويتطلب اتخاذ إجراء.

المبدأ 2: دفتر التشغيل كرمز

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

يوفر هذا النهج فوائد هائلة:

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

المبدأ 3: الأتمتة المتدرجة والإنسان في الحلقة

الأتمتة ليست مفتاحًا كليًا أو معدومًا. يبني النهج التدريجي والمتدرج الثقة ويقلل المخاطر.

• المستوى 1: التشخيص الآلي. هذا هو المكان الأكثر أمانًا وقيمة للبدء. عند تنشيط تنبيه، يكون الإجراء الآلي الأول هو جمع المعلومات. قد يتضمن ذلك جلب السجلات من الخدمة المتأثرة، وتشغيل أمر `kubectl describe pod`، والاستعلام عن قاعدة بيانات للحصول على إحصائيات الاتصال، أو سحب المقاييس من لوحة معلومات معينة. ثم يتم إلحاق هذه المعلومات تلقائيًا بالتنبيه أو تذكرة الحادث. يمكن لهذا وحده أن يوفر لمهندس الاستدعاء 5-10 دقائق من جمع المعلومات المحموم في بداية كل حادث.
• المستوى 2: عمليات المعالجة المقترحة. الخطوة التالية هي تزويد مهندس الاستدعاء بإجراء معتمد مسبقًا. بدلاً من أن يتخذ النظام إجراءً من تلقاء نفسه، فإنه يعرض زرًا في التنبيه (على سبيل المثال، في Slack أو تطبيق أداة التنبيه) يقول "إعادة تشغيل الخدمة" أو "فشل قاعدة البيانات". لا يزال الإنسان هو صانع القرار النهائي، لكن الإجراء نفسه عبارة عن عملية آلية بنقرة واحدة.
• المستوى 3: المعالجة الآلية بالكامل. هذه هي المرحلة النهائية، المحجوزة للحوادث المعروفة جيدًا ومنخفضة المخاطر والمتكررة. مثال كلاسيكي هو جراب خادم ويب بلا حالة أصبح غير مستجيب. إذا كان لإعادة تشغيل الجراب احتمالية نجاح عالية ومخاطر منخفضة لآثار جانبية سلبية، فيمكن أتمتة هذا الإجراء بالكامل. يكتشف النظام الفشل، وينفذ إعادة التشغيل، ويتحقق من أن الخدمة تعمل بشكل جيد، ويحل التنبيه، وربما دون إيقاظ إنسان على الإطلاق.

المبدأ 4: السياق الغني هو الملك

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

• ملخص واضح لما هو معطل وما هو تأثير المستخدم.
• روابط مباشرة إلى لوحات معلومات المراقبة ذات الصلة (على سبيل المثال، Grafana، Datadog) مع نافذة الوقت والفلاتر الصحيحة المطبقة بالفعل.
• رابط إلى دليل التشغيل أو دفتر التشغيل لهذا التنبيه المحدد.
• البيانات الوصفية الرئيسية، مثل الخدمة المتأثرة والمنطقة والمجموعة ومعلومات النشر الحديثة.
• بيانات التشخيص التي تم جمعها بواسطة أتمتة المستوى 1.

يؤدي هذا السياق الغني إلى تقليل الحمل المعرفي على المهندس بشكل كبير ويوفر المعلمات اللازمة لنصوص المعالجة الآلية للتشغيل بشكل صحيح وآمن.

بناء خط أنابيب الاستجابة للحوادث الآلية: دليل عملي

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

الخطوة 1: المراقبة الأساسية

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

• المقاييس: بيانات رقمية متسلسلة زمنيًا تخبرك بما يحدث (على سبيل المثال، معدلات الطلبات، ونسب الأخطاء، واستخدام وحدة المعالجة المركزية). الأدوات مثل Prometheus والخدمات المُدارة من موفري الخدمة مثل Datadog أو New Relic شائعة هنا.
• السجلات: سجلات الأحداث المنفصلة مع ختم زمني. يخبرونك لماذا حدث شيء ما. تعد منصات تسجيل الدخول المركزية مثل ELK Stack (Elasticsearch و Logstash و Kibana) أو Splunk ضرورية.
• التتبعات: سجلات مفصلة لرحلة الطلب عبر نظام موزع. لا تقدر بثمن لتحديد الاختناقات والإخفاقات في هندسة الخدمات المصغرة. OpenTelemetry هو المعيار العالمي الناشئ لتجهيز تطبيقاتك للتتبعات.

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

الخطوة 2: اختيار منصة التنبيه وتكوينها

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

• عمليات التكامل الغنية: ما مدى جودة تكاملها مع أدوات المراقبة وتطبيقات الدردشة (Slack و Microsoft Teams) وأنظمة إصدار التذاكر (Jira و ServiceNow)؟
• واجهة برمجة تطبيقات (API) قوية و Webhooks: أنت بحاجة إلى التحكم البرمجي. تعد القدرة على إرسال واستقبال Webhooks الآلية الأساسية لتشغيل الأتمتة الخارجية.
• إمكانيات الأتمتة المضمنة: تضيف الأنظمة الأساسية الحديثة ميزات الأتمتة مباشرة. تتيح لك إجراءات أتمتة PagerDuty وتكامل Rundeck، أو قنوات الإجراءات في Jira Service Management (Opsgenie)، تشغيل البرامج النصية ودفاتر التشغيل مباشرة من التنبيه نفسه.

الخطوة 3: تحديد مرشحي الأتمتة

لا تحاول أتمتة كل شيء مرة واحدة. ابدأ بالفاكهة المتدلية. يعد سجل الحوادث الخاص بك منجم ذهب من البيانات لتحديد المرشحين الجيدين. ابحث عن الحوادث التي تكون:

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

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

الخطوة 4: تنفيذ دفتر التشغيل الآلي الأول

دعنا نمر عبر مثال ملموس: يفشل جراب تطبيق ويب في مجموعة Kubernetes في فحص حالته الصحية.

1. المحفز: تكتشف قاعدة Prometheus Alertmanager أن المقياس `up` للخدمة كان 0 لأكثر من دقيقتين. يشغل تنبيهًا.
2. المسار: يتم إرسال التنبيه إلى منصة التنبيه المركزية الخاصة بك (على سبيل المثال، PagerDuty).
3. الإجراء - المستوى 1 (التشخيص): يتلقى PagerDuty التنبيه. من خلال webhook، فإنه يشغل دالة AWS Lambda (أو برنامجًا نصيًا على نظام أساسي بلا خادم من اختيارك). هذه الدالة:
   • تحلل حمولة التنبيه للحصول على اسم الجراب ومساحة الاسم.
   • تنفذ `kubectl get pod` و `kubectl describe pod` مقابل المجموعة ذات الصلة للحصول على حالة الجراب والأحداث الأخيرة.
   • تجلب آخر 100 سطر من السجلات من الجراب الفاشل باستخدام `kubectl logs`.
   • تضيف كل هذه المعلومات كملاحظة غنية مرة أخرى إلى حادث PagerDuty عبر واجهة برمجة التطبيقات الخاصة به.
4. القرار: في هذه المرحلة، يمكنك اختيار إخطار مهندس الاستدعاء، الذي لديه الآن جميع بيانات التشخيص اللازمة لاتخاذ قرار سريع. أو، يمكنك المتابعة إلى الأتمتة الكاملة.
5. الإجراء - المستوى 3 (المعالجة): تتابع دالة Lambda لتنفيذ `kubectl delete pod <pod-name>`. سيقوم وحدة التحكم ReplicaSet الخاصة بـ Kubernetes تلقائيًا بإنشاء جراب جديد وصحي ليحل محله.
6. التحقق: ثم يدخل البرنامج النصي في حلقة. ينتظر 10 ثوانٍ، ثم يتحقق مما إذا كان الجراب الجديد قيد التشغيل واجتاز فحص الاستعداد الخاص به. إذا نجح بعد دقيقة، فسيقوم البرنامج النصي باستدعاء واجهة برمجة تطبيقات PagerDuty مرة أخرى لحل الحادث تلقائيًا. إذا استمرت المشكلة بعد عدة محاولات، فإنها تستسلم وتصعد الحادث على الفور إلى شخص، مما يضمن عدم تعلق الأتمتة في حلقة فشل.

الخطوة 5: توسيع نطاق الأتمتة الخاصة بك وتطويرها

نجاحك الأول هو الأساس الذي يمكنك البناء عليه. يتضمن تطوير ممارستك ما يلي:

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

العنصر البشري في عالم آلي

الخوف الشائع هو أن الأتمتة ستجعل المهندسين مهملين. الحقيقة هي العكس: إنها ترفع من دورهم.

تحويل الأدوار: من رجل إطفاء إلى مهندس الوقاية من الحرائق

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

أهمية عمليات الترحيل والتحسين المستمر

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

• هل قدمت تشخيصاتنا الآلية المعلومات الصحيحة؟
• هل يمكن معالجة هذا الحادث تلقائيًا؟ إذا كان الأمر كذلك، فما هو عنصر الإجراء لبناء هذه الأتمتة؟
• إذا تمت محاولة الأتمتة وفشلت، فلماذا فشلت، وكيف يمكننا جعلها أكثر قوة؟

بناء الثقة في النظام

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

الاعتبارات العالمية لأتمتة الاستجابة للحوادث

بالنسبة للمؤسسات الدولية، يوفر النهج الذي يركز على الأتمتة مزايا فريدة.

عمليات تسليم "اتبع الشمس"

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

التوحيد القياسي عبر المناطق

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

إقامة البيانات والامتثال

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

الخلاصة: رحلتك إلى الاستجابة للحوادث الأكثر ذكاءً

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

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