قصة كيف وجدنا أنفسنا على شفا الإفلاس ، حتى قبل إطلاق المنتج الأول ، وكيف تمكنا من البقاء وما هي الدروس التي تعلمناها.
في مارس 2020 ، عندما ضرب COVID العالم ، تضررت شركتنا الناشئة Milkie Way بشدة وكادت أن تغلق. لقد أنفقنا 72000 دولار أثناء البحث والاختبار الداخلي لـ Cloud Run مع Firebase لعدة ساعات.
بدأت في تطوير خدمة الإعلان في نوفمبر 2019. كان الهدف الرئيسي هو إطلاق الإصدار الأول الوظيفي الأدنى من المنتج ، لذلك عمل الكود على حزمة بسيطة. استخدمنا JS و Python ونشرنا منتجنا على Google App Engine.
مع فريق صغير جدًا ، ركزنا على الترميز وتطوير واجهة المستخدم وإعداد المنتج. لم أمضِ أي وقت تقريبًا في إدارة السحابة - لقد أمضيت ما يكفي فقط لتشغيل النظام وتوفير عملية التطوير الأساسية (CI / CD).
إعلان سطح المكتب
لم يكن الإصدار الأول مناسبًا للغاية ، لكننا أردنا فقط إصدار نسخة للتجريب ، ثم العمل على الإصدار العادي. بسبب COVID ، اعتقدنا أن هذا هو الوقت المناسب للانطلاق حيث يمكن للوكالات الحكومية في جميع أنحاء العالم استخدام الإعلان لنشر التنبيهات.
أليس من الرائع إنشاء بعض البيانات على النظام الأساسي عندما لا يقوم المستخدمون بتحميل المحتوى الخاص بهم بعد؟ أدى هذا الفكر إلى مشروع آخر ، Announce-AI لتوليد المحتوى. البيانات الغنية هي أحداث مختلفة مثل تنبيهات الزلازل والأخبار المحلية ذات الصلة.
بعض التفاصيل الفنية
استخدمنا وظائف السحابة لبدء تطوير Announce-AI. نظرًا لأن روبوت الكشط كان لا يزال في مهده ، فقد قررنا استخدام هذه الميزات خفيفة الوزن. ولكن كانت هناك مشاكل في القياس لأن المهلة الزمنية للوظائف السحابية تبلغ 9 دقائق تقريبًا.
وفجأة علمنا بنظام Cloud Run ، والذي كان له بعد ذلك حد كبير للاستخدام المجاني! بدون فهمها تمامًا ، طلبت من الفريق نشر وظيفة "الاختبار" Announce-AI في Cloud Run وتقييم أدائها. كان الهدف هو اللعب مع Cloud Run لاكتساب الخبرة.
جوجل سحابة تشغيل
نظرًا لأن لدينا موقعًا صغيرًا للغاية ، فقد استخدمنا قاعدة بيانات Firebase من أجل البساطة ، نظرًا لأن Cloud Run لا يحتوي على أي مساحة تخزين ، ونشر SQL Server أو قاعدة بيانات أخرى مفرط للغاية للاختبار.
لقد قمت بإنشاء مشروع GCP ANC-AI Dev جديد ، وقمت بإعداد ميزانية الفوترة السحابية الخاصة بي بمبلغ 7 دولارات ، وحفظت مشروع Firebase الخاص بي بخطة مجانية (Spark). أسوأ حالة تخيلناها هي تجاوز حد Firebase اليومي.
بعد إجراء بعض التعديلات ، أعددنا الكود ، وقدمنا بعض الطلبات اليدوية ، ثم تركناه قيد التشغيل.
يبدأ الكابوس
في يوم الاختبار ، سارت الأمور على ما يرام ، وعدنا إلى تطوير إعلان. في اليوم التالي بعد العمل ، في وقت متأخر من بعد الظهر ، ذهبت لأخذ قيلولة. عندما استيقظت ، رأيت عدة رسائل بريد إلكتروني من Google Cloud ، كل ذلك على فترات من عدة دقائق.
البريد الإلكتروني الأول: الترقية التلقائية لمشروع Firebase
البريد الإلكتروني الثاني: تجاوزت الميزانية
لحسن الحظ ، فإن بطاقتي بها حد 100 دولار. لهذا السبب ، لم تتم المدفوعات ، وعلقت Google خدمة حساباتنا.
الحرف الثالث: البطاقة مرفوضة
قفزت من السرير ، ودخلت في خدمة Google Cloud billing ورأيت فاتورة بحوالي 5000 دولار. في حالة من الذعر ، بدأ في النقر على المفاتيح ، ولم يفهم ما كان يحدث. في الخلفية ، بدأت أفكر في كيفية حدوث ذلك وكيفية دفع فاتورة 5000 دولار ، في هذه الحالة.
كانت المشكلة أن النتيجة كانت تتزايد كل دقيقة.
في خمس دقائق أظهر مبلغ 15000 دولار ، في 20 دقيقة - 25000 دولار ، لم أفهم متى ستتوقف الأرقام عن الزيادة. ربما سوف تنمو إلى أجل غير مسمى؟
بعد ساعتين ، توقف الرقم عند أقل من 72000 دولار بقليل.في
هذا الوقت ، كنت أنا والفريق في مؤتمر عبر الهاتف ، صدمت تمامًا ولم يكن لدي أي فكرة عما يجب فعله بعد ذلك. لقد أغلقنا الفواتير ، وأغلقنا جميع الخدمات.
نظرًا لأننا في جميع مشاريع GCP ، قمنا بتسوية بطاقة واحدة ، تم تعليق جميع حساباتنا ومشاريعنا.
الكابوس مستمر
حدث هذا ليلة الجمعة ، 27 مارس - قبل ثلاثة أيام من خططنا لإطلاق الإصدار الأول. توقف التطوير الآن لأن Google علقت جميع مشاريعنا المرتبطة بخريطة واحدة. كانت معنوياتي تحت الأرضية ، وبدا مستقبل الشركة غير مؤكد.
جميع مشاريعنا السحابية معلقة ، التطوير متوقف.
وبمجرد أن استسلم عقلي للواقع الجديد ، قررت في منتصف الليل اكتشاف ما حدث بشكل طبيعي. بدأت في كتابة مستند مع تحقيق مفصل في الحادث ... وسميته "الفصل 11" [هذا فصل من قانون الإفلاس - تقريبًا. لكل.].
كما بقي اثنان من الزملاء الذين شاركوا في التجربة مستيقظين طوال الليل ، يبحثون ويحاولون فهم ما حدث.
في صباح اليوم التالي ، السبت 28 مارس ، اتصلت وكتبت رسائل إلى عشرات مكاتب المحاماة لتحديد موعد أو التحدث إلى محام. كانوا جميعًا بعيدين ، لكنني تمكنت من الحصول على رد من أحدهم عبر البريد الإلكتروني. نظرًا لأن تفاصيل الحادث معقدة للغاية ، حتى بالنسبة للمهندسين ، فإن شرح ذلك لمحامي بلغة إنجليزية بسيطة لم يكن سهلاً في حد ذاته.
بالنسبة لنا ، كشركة ناشئة ، لم تكن هناك طريقة لاسترداد 72000 دولار ،
وبحلول هذا الوقت ، كنت قد درست بدقة الفصلين السابع والحادي عشر من قانون الإفلاس واستعدت عقليًا لما قد يحدث بعد ذلك.
بعض الراحة: ثغرات GCP
يوم السبت ، بعد إرسال رسائل بريد إلكتروني إلى المحامين ، بدأت في قراءة وتصفح كل صفحة من وثائق برنامج "شركاء Google المعتمدون". لقد ارتكبنا أخطاء ، ولكن لم يكن هناك ما يدعو Google إلى السماح لنا بإنفاق 72000 دولار بشكل كبير إذا لم نقم بأي مدفوعات من قبل!
GCP و Firebase
1. ترقية تلقائية لحساب Firebase إلى حساب مدفوع
لم نتوقع هذا ، ولم يتم تحذير ذلك في أي مكان عند التسجيل في Firebase. تم توصيل فوترة GCP الخاصة بنا بتنفيذ Cloud Run ، لكن Firebase جاء ضمن خطة مجانية (Spark). بدون سبب واضح ، تمت ترقية برنامج "شركاء Google المعتمدون" إلى خطة مدفوعة وفرض علينا المبلغ المطلوب.
اتضح أنهم يطلقون على هذه العملية "التكامل العميق بين Firebase و GCP".
2. لا توجد "حدود" للفواتير. الميزانيات تتأخر ليوم واحد على الأقل
يتم تأخير فوترة برنامج "شركاء Google المعتمدون" فعليًا لمدة 24 ساعة على الأقل. في معظم المستندات ، تقترح Google استخدام الميزانيات وميزة إيقاف التشغيل السحابي التلقائي. ولكن بحلول الوقت الذي يتم فيه تشغيل وظيفة إيقاف التشغيل أو إرسال إشعار إلى المستخدم ، يكون الضرر قد حدث بالفعل.
تستغرق مزامنة الفوترة يومًا تقريبًا ، ولهذا السبب لاحظنا الفاتورة في اليوم التالي.
3. كان من المفترض أن تحصل Google على 100 دولار وليس 72 ألفًا!
نظرًا لعدم سداد أي مدفوعات من حسابنا حتى الآن ، كان على برنامج "شركاء Google المعتمدون" أولاً أن يأخذ رسومًا قدرها 100 دولار أمريكي وفقًا لمعلومات الفوترة ، وإذا لم يدفع ، أوقف الخدمة. ولكن هذا لم يحدث. اكتشفت السبب لاحقًا ، لكن هذا أيضًا ليس خطأ المستخدم!
كانت الفاتورة الأولى لنا حوالي 5000 دولار. القيمة التالية هي 72 ألف دولار.
الحد الأقصى لاستحقاق السداد لحسابنا هو 100 دولار
4. لا تعتمد على لوحة معلومات Firebase!
لم يقتصر الأمر على إعداد الفواتير فحسب ، بل استغرق أيضًا تحديث لوحة معلومات Firebase أكثر من 24 ساعة.
وفقًا لوثائق Firebase Console ، قد تختلف الأرقام الموجودة في لوحة التحكم "قليلاً" عن تقارير الفوترة.
في حالتنا ، اختلفوا بنسبة 86.585.365.85٪ أو 86 مليون نقطة مئوية. حتى عندما وصلت الفاتورة ، كانت Firebase Console لا تزال تعرض 42000 قراءة وكتابة شهريًا (أقل من الحد اليومي).
يوم جديد ، تحدٍ جديد
بعد ست سنوات ونصف في Google وكتابة العشرات من مستندات المشروع وتقارير التحقيق والمزيد ، بدأت في كتابة مستند لـ Google ، واصفًا الحادث وأضف ثغرات Google إلى التقرير. سيعود فريق Google إلى العمل في غضون يومين.
تصحيح: اقترح بعض القراء أنني كنت أستخدم جهات اتصال Google الداخلية. في الواقع ، لم أتواصل مع أي شخص واخترت المسار الذي سيتبعه أي مطور أو شركة عادية. مثل أي مطور صغير آخر ، قضيت ساعات لا تحصى في الدردشة والاستشارات وصياغة رسائل البريد الإلكتروني الطويلة والإبلاغ عن الأخطاء. في إحدى المقالات التالية حول الإبلاغ عن الحوادث ، سأعرض المستندات التي أرسلتها إلى Google.
آخر يوم في Google
بالإضافة إلى ذلك ، كان من الضروري فهم أخطائنا وتطوير إستراتيجية تطوير المنتج. لم يكن كل من في الفريق على علم بالحادثة ، لكن كان من الواضح أننا كنا في ورطة كبيرة.
في Google ، واجهت ملايين الدولارات في خطأ بشري ، لكن ثقافة Google توفر الموظفين (باستثناء أنه يتعين على المهندسين كتابة تقارير طويلة لاحقًا). هذه المرة لم يكن هناك جوجل. رأس مالنا الصغير وعملنا الشاق على المحك.
تخبرنا جبال الهيمالايا الصامدة ...
كانت هذه هي المرة الأولى التي أتلقى فيها مثل هذه الضربة. هذا يمكن أن يغير مستقبل شركتنا وحياتي. علمتني هذه الحادثة عدة دروس في مجال الأعمال ، بما في ذلك أهمها - تلقي الضربة.
في ذلك الوقت ، كان لدي فريق من سبعة مهندسين ومتدربين ، واستغرق الأمر من Google حوالي عشرة أيام للرد علينا بشأن هذه الحادثة. في غضون ذلك ، كان علينا استئناف التطوير ، وإيجاد طريقة للالتفاف حول تعليق الحسابات. على الرغم من كل شيء ، كان علينا التركيز على الميزات ومنتجاتنا.
قصيدة "تخبرنا جبال الهيمالايا المستمرة"
لسبب ما ، كانت قصيدة من طفولتي تدور باستمرار في رأسي. كان كتابي المفضل ، وتذكرته كلمة بكلمة ، رغم أنني قرأته آخر مرة منذ أكثر من 15 عامًا.
ماذا فعلنا بالفعل؟
كفريق صغير جدًا ، أردنا تجنب الإنفاق على الأجهزة لأطول فترة ممكنة. انتهت مهلة مهام السحابة وتشغيل السحابة.
مثيل واحد سيتخلص باستمرار من عناوين URL من الصفحة. ولكن بعد 9 دقائق ، ستكون هناك مهلة.
بعد ذلك ، بعد أن ناقشت المشكلة بشكل عرضي ، قمت بتدوين الشفرة الأولية على السبورة في دقيقتين. أدركت الآن أن هذا الرمز به الكثير من العيوب المعمارية ، ولكن بعد ذلك كنا نهدف إلى دورات إصلاح أخطاء سريعة لتعلم أشياء جديدة وتجربتها بسرعة.
أعلن مفهوم الذكاء الاصطناعي في Cloud Run
للتغلب على قيود المهلة ، اقترحت استخدام طلبات POST (مع عنوان URL كبيانات) لإرسال وظائف إلى مثيل و - تشغيل مثيلات متعددة بشكل متوازٍ ، بدلاً من الانتظار لواحد. نظرًا لأن كل مثيل في Cloud Run سيؤدي إلى إلغاء صفحة واحدة فقط ، فلن يكون هناك مهلة أبدًا ، وستتم معالجة جميع الصفحات بالتوازي (مع القياس جيدًا) ، ويتم تحسين العملية بشكل كبير حيث يتم استهلاك Cloud Run بدقة مللي ثانية.
مكشطة تشغيل السحابة
إذا نظرت عن كثب ، فإن العملية تفتقد بعض التفاصيل المهمة.
- يحدث العودية الأسية المستمرة: لا تعرف المثيلات متى تتوقف بسبب عدم وجود عبارة break.
- يمكن أن يكون لطلبات POST نفس عنوان URL. إذا كان هناك رابط للصفحة السابقة ، فإن خدمة Cloud Run سوف تتعثر في تكرار لانهائي ، ولكن الأسوأ من ذلك كله ، أن هذه العودية تتضاعف أضعافا مضاعفة (تم تعيين الحد الأقصى لعدد الحالات على 1000!)
كما يمكنك أن تتخيل ، فقد أدى ذلك إلى وضع 1000 حالة تقدم طلبات وتكتب إلى Firebase DB كل بضعة أجزاء من الثانية. لقد رأينا أنه كان هناك حوالي مليار طلب في الدقيقة يمر عبر قراءات Firebase في وقت ما!
ملخص معاملة نهاية شهر GCP
116 مليار قراءة و 33 مليون يكتب
حقق الإصدار التجريبي لتطبيقنا على Cloud Run 116 مليار قراءة و 33 مليون عملية كتابة إلى Firestore. يا!
تكاليف قراءة Firebase:
$ (0.06 / 100،000) * 116،000،000،000 = 69،600 دولار
16000 ساعة تشغيل في السحابة
بعد الاختبار ، من إيقاف السجلات ، خلصنا إلى أن الطلب قد انتهى ، لكنه في الواقع دخل في عملية خلفية. نظرًا لأننا لم نلغي تثبيت الخدمات (كنا نستخدم Cloud Run لأول مرة ولم نفهمها حقًا في ذلك الوقت) ، استمرت العديد من الخدمات في العمل ببطء.
في غضون 24 ساعة ، تم تشغيل جميع هذه الخدمات في 1000 حالة لما مجموعه 16022 ساعة.
كل أخطائنا
انشر الخوارزمية الخاطئة في السحابة
سبق أن نوقشت أعلاه. لقد وجدنا طريقة جديدة لاستخدام طلبات POST بدون خادم والتي لم أجدها في أي مكان على الإنترنت ، لكننا نشرناها دون تحديد الخوارزمية.
انشر Cloud Run بالمعلمات الافتراضية
عندما أنشأنا خدمة Cloud Run ، اخترنا القيم الافتراضية لها. الحد الأقصى لعدد الحالات هو 1000 والتزامن هو 80 طلبًا. لم نكن نعلم أن هذه القيم هي في الواقع أسوأ سيناريو لبرنامج الاختبار.
إذا اخترنا الحد الأقصى للحالات = 2 ، فستكون التكاليف أقل بمقدار 500 مرة.
إذا حددنا التزامن = 1 ، فلن نلاحظ النتيجة.
استخدام Firebase دون فهم كامل
أنت فقط تفهم شيئًا من التجربة. Firebase ليست لغة يجب تعلمها ، إنها منصة حاوية. يتم تحديد قواعدها من قبل شركة Google معينة.
أيضًا ، عند كتابة كود Node.js ، عليك التفكير في عمليات الخلفية. إذا انتقل الرمز إلى عمليات الخلفية ، فليس من السهل على المطور معرفة أن الخدمة قيد التشغيل. كما علمنا لاحقًا ، تسبب هذا أيضًا في معظم المهلات لوظائف السحابة الخاصة بنا.
تعتبر الأخطاء السريعة والإصلاحات السريعة فكرة سيئة في السحابة
السحابة ككل مثل سيف ذو حدين. إذا تم استخدامه بشكل صحيح ، فقد يكون مفيدًا جدًا ، ولكن إذا تم استخدامه بشكل غير صحيح ، فقم بإلقاء اللوم على نفسك.
إذا قمت بحساب عدد الصفحات في وثائق GCP ، يمكنك نشر عدة مجلدات سميكة. يستغرق الأمر وقتًا طويلاً وفهمًا عميقًا لكيفية عمل الخدمات السحابية لفهم كل شيء ، بما في ذلك الفوترة واستخدام الوظائف. مما لا يثير الدهشة ، أنها توظف موظفين بدوام كامل لهذا الغرض!
Firebase و Cloud Run فعالان حقًا
في ذروته ، يعالج Firebase حوالي مليار قراءة في الدقيقة. هذه أداة قوية للغاية. كنا نلعب مع Firebase منذ شهرين أو ثلاثة - وما زلنا نكتشف جوانب جديدة ، ولكن حتى ذلك الحين لم يكن لدي أي فكرة عن مدى قوة هذا النظام.
الشيء نفسه ينطبق على Cloud Run! إذا قمت بتعيين عدد العمليات المتوازية إلى 60 ، max_containers == 1000 ، ثم مع طلبات 400 مللي ثانية ، يمكن لـ Cloud Run معالجة 9 ملايين طلب في الدقيقة!
60 * 1000 * 2.5 * 60 = 9.000.000 طلب في الدقيقة
في المقابل ، يعالج بحث Google 3.8 مليون استفسار في الدقيقة.
استخدم المراقبة
على الرغم من أن Google Cloud Monitoring لن يوقف الفوترة ، إلا أنه يرسل تنبيهات في الوقت المناسب (تأخير 3-4 دقائق). ليس من السهل إتقان مصطلحات Google Cloud في البداية ، ولكن إذا استغرقت بعض الوقت ، فإن لوحة القيادة والتنبيهات والمقاييس ستجعل حياتك أسهل قليلاً.
تتوفر هذه المقاييس لمدة 90 يومًا فقط ، ولم يتم حفظها معنا.
نحن على قيد الحياة
فوه ، تم نقله بعيدًا
بعد فحص تقريرنا الطويل عن الحادث الذي يصف الموقف من جانبنا ، وبعد العديد من المشاورات والمحادثات والمناقشات الداخلية ، غفرت لنا Google النفقات!
شكرا جوجل!
لقد حصلنا على عوامة نجاة واستخدمنا هذه الفرصة لإكمال تطوير المنتج. هذه المرة مع تخطيط وهندسة معمارية أفضل وتنفيذ أكثر أمانًا.
Google ، شركة التكنولوجيا المفضلة لدي ، ليست مجرد شركة رائعة للعمل معها. إنها أيضًا شركة رائعة للعمل معها. تعد أدوات Google سهلة الاستخدام للغاية للمطورين ، وتحتوي على وثائق رائعة (في معظمها) ، وتتطور باستمرار.
(ملاحظة: هذا رأيي الشخصي بصفتي مطورًا فرديًا. فشركتنا ليست مدعومة أو تابعة لشركة Google بأي شكل من الأشكال).
ماذا بعد؟
بعد هذا الحادث ، قضينا عدة أشهر في دراسة السحابة وبنيتنا. في غضون أسابيع قليلة ، تحسن فهمي كثيرًا لدرجة أنني تمكنت من تقدير تكلفة تجريف "الإنترنت بالكامل" باستخدام Cloud Run باستخدام خوارزمية محسنة.
أجبرني الحادث على إجراء تحليل عميق لبنية منتجنا ، وتخلينا عن الإصدار الأول لبناء بنية تحتية قابلة للتطوير.
في الإصدار الثاني من Announce ، لم ننشئ MVP فحسب ، بل أنشأنا منصة يمكننا من خلالها تطوير منتجات جديدة في تكرارات سريعة واختبارها بدقة في بيئة آمنة.
استغرقت هذه الرحلة وقتا طويلا ... أعلنتم إطلاقه في نهاية نوفمبر ، بعد حوالي سبعة أشهر من الإصدار الأول ، ولكنه قابل للتطوير للغاية ، ويستحوذ على أفضل ما في السحابة ، وهو مُحسَّن للغاية.
أطلقنا أيضًا على جميع المنصات ، وليس الإنترنت فقط.
علاوة على ذلك ، أعدنا استخدام النظام الأساسي لإنشاء منتجنا الثاني ، Point Address . كما أنها تتميز بقابلية التوسع والهندسة المعمارية الجيدة.