في نوفمبر 2018 ، تم إنشاء قسم دعم المعلومات في ليتوانيا ودعا
أندريه يوماشيف لقيادة. في العام الماضي ، يساعد القسم الشركة على العمل والتطوير والحفاظ على البنية التحتية بأكملها تحت السيطرة. ولكن هذا لم يكن الحال دائما. قبل البدء في العمل ، واجه Andrei أطلالًا: Nagios نصف ميت ، و Cacti ودمى غيبوبة مشروطة ، ويكي 120 صفحة ميتة ، وجداول مهام غير متماسكة وقائمة حديدية ، والهندسة القديمة ، و 340 قلبًا غير نشط ، و 2 TB من ذاكرة الوصول العشوائي و 17 TB مساحة القرص التي لم يتم تسجيلها لسبب ما في جداول المخزون. الخطط التي لا تعمل ، والمواعيد النهائية التي تنقطع ، وبيئة العمل والأدوات غير الموجودة - كل هذا ينتظر أندريه في مشروع جديد.
في
DevOpsConf 2019 ، قدم Andrei تقريراً عرض فيه أمثلة حية على ما يستحق وما لا ينبغي القيام به عند إدخال مشروع لم تره أو تعرفه جيدًا. في الأسفل ، هناك نسخة محدثة من القصة - كيفية تحليل مجموعة المشاكل بشكل صحيح وبناء خطة نشاط ، وكيفية حساب مؤشر الأداء الرئيسي بشكل صحيح ومتى تتوقف في الوقت المناسب.
أندريه يوماشيف هو صاحب شركات التطوير الخاصة به في مختلف المجالات (عبر الإنترنت وغير متصل) ، وهو مستشار في بناء العمليات ، ورئيس قسم دعم المعلومات في LiteRes.
قليلا عن LiteRes. هذا هو أكبر مورد للكتب الإلكترونية والسمعية في روسيا ، دار نشر ومجموعة من مشاريع الشراكة. هذه هي مئات الآلاف من سطور Perl ، والعديد من مجموعات قواعد البيانات والمستودعات. هذا هو 2 غيغابايت من حركة المرور الصادرة في الثانية ، ومئات الآلاف من الطلبات الفريدة في اليوم ، والعديد من الرفوف في مراكز البيانات المختلفة وأكثر من 100 خوادم. الكل في الكل ، هذه ليست مجرد مكتبة إلكترونية.
الخطوات الأولى
اعتدت العمل في LiteRes على أساس سعر قطعة. ممارسات الشركة تتفوق مع تسجيل الموظفين عن بعد في الدولة.
يعمل نظام إنجاز المهام باللتر على مبدأ "المزاد". في متعقب المهام الداخلي ، يصف المديرون والمهندسون المعماريون مهام المشاريع الداخلية ويقيمونها بالعملة المحلية. العملة هي "الفطر والعشب والشجرة".
ثم يبدأ "المزاد السهل" - أي مطور يمكنه القيام بالمهمة أو الصفقة. أحسنت - تدفع لك. لم أكن أعمل على الإطلاق - أنت لا تفهمها. بطريقة مرحة ، يهتم الناس بإنجاز المهام. لمعرفة المزيد حول هذا النظام ، راجع عرض Dmitry Gribov.
العمل من أجل الفطر.يناسبني النظام - لقد دعمت تجربة برل في البرمجة ، وعملت عندما كانت مريحة ولم أكن أقضي الكثير من الوقت عليها. في هذا الوضع ، قضيت بضع سنوات حتى نوفمبر من العام الماضي وأعتقد أنني أفهم هيكل النظام البيئي.
كنت مخطئا
لقد دعيت إلى الشركة وأبلغت أن خدماتي كمطور في شركة بيرل ليست ضرورية ، وقد عرض عليّ أن أترأس قسمًا جديدًا. في نوفمبر 2018 ، أصبحت رئيس قسم المعلومات.
أمامي أضع مساحات مفتوحة: عدة رفوف بالحديد في العديد من مراكز البيانات في موسكو ، والهندسة القديمة ، والموارد الخارجية ، والغياب شبه التام للوثائق ذات الصلة للجميع. بدا الافتتاحي شيء مثل هذا: "الآن هذا هو إرثك ، وتحسين ، لا كسر ودعم". كان هناك بعض قائمة المهام الجاهزة والخطط الأولية للسنة المقبلة. كان من الضروري فهم كل هذا وتحويله إلى شكل بشري.
كان هناك شعور بأنني كنت أنظر إلى الهاوية ، وكانت الهاوية تنظر إلي.
لقد ساعدتني تجربة السنوات الماضية كثيرًا عندما طورت موقفًا واضحًا عند العمل مع شخص غريب أو غير مفهوم. بادئ ذي بدء ، هذه دراسة شاملة وخطة عمل دنيا. هذا هو المكان الذي بدأت فيه.
النظافة هي مفتاح الصحة
النظام هو أولا وقبل كل شيء.
لأول شهر تمكنت من العثور على:
- أوراق Google المبعثرة مع المهام الحالية ومجموعة من المعلومات المفيدة ؛
- وثائق مبعثرة: كلمة ، نصوص ، قصاصات من صفحات ويكي 120 القديمة ؛
- نصف القتلى Nagios؛
- مراقبة حية مشروطة من الصبار.
- دمية قديمة جدا مع علامات نادرة للحياة.
كل هذه الأنقاض جمعت أيضا 400 متر.
أنقاض التي وجدت في الشهر الأول.كنت ممتعًا قليلاً ، وقراءة كل شيء بطلاقة وتمسك عمليات Trello. نقل المهام الحالية لزملائه إليه وبدأ في الحلم - لكتابة خطة للربع والسنة.
الخطأ الأول
لا توجد خطط حتى تستكشف المنطقة.
الخطة متوهجة بالحرارة والصحة ، لكنها لم تأخذ بعين الاعتبار الواقع. كان جميلًا وبسيطًا: تنفيذ المراقبة وتحليل السجلات ونقل النشر إلى CI / CD. في مكان ما في النهاية ، كان هناك "تحليل ضعيف لضعف المشروع". الخطوات الأولى الكلاسيكية.
لقد نسيت الشيء الرئيسي. أولويتي الأولى ليست في تنفيذ أدوات لتنفيذ الأدوات ، ولكن لضمان سلامة واستقرار الخدمة ككل.
بينما كنت أكتب الخطة وتعذّب عليها أسئلة زملائي ، وصلت المشكلات الأولى. نفدت إحدى العقد في إحدى مجموعات الكتل من المساحة ، وانتهت SSD ككل على العقدة الأخرى للمجموعة نفسها. لقد اشتريت بشكل عاجل أقراصًا كبيرة جديدة ، وسرعان ما اكتسب قسمنا خبرة في استبدال هذه الأقراص عن طريق نسخ النظام من قرص إلى قرص. بعد استبدال الأقراص ، قمنا ببناء الكتلة من الصفر إلى SST. تم بناء المجموعة على Percona و Galera ، ومثل هذا الترفيه لا يذهب إليه مقابل لا شيء.
بينما كنت أسافر بين مراكز البيانات ، ولدت
براعم الشك الأولى حول الخطة.
آه آه آه آه!في الوقت نفسه ، كانت كثافة العمل الأسود عالية لدرجة أنني لم أفكر في جمع تاريخ طبي كامل ، لكنني ببساطة التقطت بعض الصور لمزيد من الدراسة.
في موازاة ذلك ، ظهرت مقدمة أخرى. في لتر هناك إصدارات صوتية من الكتب. حتى لا يسترجع المستمع التسجيل في كل مرة مرة أخرى ، لدينا آلية تتعقب لحظة التوقف. في المرة التالية التي تستمع فيها ، يتم تشغيل إصدار الصوت من القسم المطلوب. في هذه المهمة ، تطلب الأمر العثور على حوالي 500 مركز بشكل أسرع وتيرابايت من ذاكرة الوصول العشوائي وقليلًا من التحليل في Java.
لقد بدأت في إيجاز Azure و Google و DigitalOcean وكل ما تقدمه من حلول قطرة. التسوّل في الحاويات ، لماذا لا تنفذها ببهجة؟ علاوة على ذلك ، في الخطة "الكبرى" كانت هناك نقطة منفصلة حول هذا الموضوع.
لقد مر شهر على المراسلات وعروض التسعير ، تمت إضافة كل شيء إلى المهام في Trello ، والتي ولدت جزءًا كبيرًا منها ، لكن النتيجة لم تتقدم. تساءلت إن كنت ذاهبا إلى هناك. قبلي ، كان كل شيء يعمل بطريقة ما ولن يتوقف ، بغض النظر عن مقدار النشاط الفارغ الذي أراه. جلست بعناية لدراسة المخزون الذي تمكنت من جمعه شيئًا فشيئًا. ثم نهض وذهب إلى الجولة الثانية من مراكز البيانات.
الزيارة الثانية الهادئة لمراكز البيانات تضع كل شيء في مكانه. عندما رأيت كل هذا ليس في وحدة التحكم ، وليس في Excel ، ولكن على قيد الحياة ، تغير وعيي بالواقع بشكل جذري. أدركت أنني لست مشغولاً على الإطلاق بما يجب أن أفعله. لأنك أولاً تحتاج إلى فهم ما أعمل معه.
حتى أفهم ما أعمل به ، فإن جميع الخطط مضيعة للوقت.
لقد درست الرفوف ، وقارن الواقع مع القوائم ، وأعدلت التعديلات ، وتعثرت على وحدة شبه تحتوي على 20 شفرة. من بين عشرين عامًا ، كان يعمل 4. فقط ، وقمت برش الشفرات وأدركت أننا لا نحتاج إلى أي قطرات للحل. لأنني وجدت 340 نائمة نائمة ، 2 تيرابايت من ذاكرة الوصول العشوائي و 17 تيرابايت من مساحة القرص! هذه هي الخلفية القديمة ، والعقد القديمة من الكتل التي توقفت ببساطة عن استخدام ، والوقت قد مسح ذاكرة وجودها. لقد دحرجة Kubernetes على هذه الشفرات وتخلصت من مهمة واحدة رئيسية.
إخراج الخطأ الأول
تحليل ودراسة. بدون تحليل أولي للوضع ، لا يتحرك القطار.
بفضل رحلة مدروسة إلى الحقول ، كان لدي بالفعل خطة ذات صلة إلى حد ما بالمعدات والهيكل العام للنظام. في الفناء كان يناير. لقد أمضيت شهرين في هذا الأمر ، نصفه أنا فقط تجرأت من جانب إلى آخر. لم أكن أعرف أي النار يجب إطفاؤها أولاً ، ما هي المهمة التي يجب حلها أولاً - تدفق الدعم لم يذهب إلى أي مكان.
في موازاة ذلك ، استنتجت ثلاثة قواعد. هذه هي عواقب الخطأ الأول.
ثلاثة نتيجة طبيعية.الخطة الثانية
رميت المهام الثانوية من المقدمة - تحليل السجل وتنفيذ CI / CD. على نطاق الكارثة العامة ، هذه الأشياء الصغيرة ليست مهمة. لقد عمل اللتر لسنوات وطور منطقه الخاص للعمل مع السجلات ، واكتسب شيطانًا عصاميًا. دفعت إلى الخطة الخامسة ما الذي نجح ولم يتطلب التدخل.
الخطة الثانية بدت شيئا من هذا القبيل.
التعامل مع الرصد . في شكله الحالي ، لم يعكس ما لا يقل عن ثلث المشكلات ، رغم أنه نجح.
صف المنطق العام لترا بأكمله . تعد أسماء الخوادم كبيرة ، لكن الحزم الرئيسية هي معرفة مهمة: ماذا وأين وأين ولماذا ولماذا. الخطأ السابق أوضح أنه بدون هذا بأي شكل من الأشكال.
التحجيم . تقريبا آخر موارد مجانية استغرق Kubernetes. وفقًا للحد الأدنى من التقديرات ، كان من المفترض أن ينهي مجموعة العمل بأكملها خلال ستة أشهر.
جرد وحالة المعدات . كجزء من الرحلة ، قمت حرفياً بحذف شبكة من عدد من الخوادم التي تخيفها علاماتها - "النسخ الاحتياطي" ، "الاشتراك" ، "bgp". مرة أخرى ، أقراص ، إسقاط الأقراص.
تكييف الأدلة إلى الواقع . معظم التعليمات قديمة أو غير كاملة.
مرت الأشهر الستة الأولى دون أن يلاحظها أحد في حركة التداول ، وشراء المعدات والمتاعب ، وأخيراً أثبتت نفسي في الخطأ الثاني.
الخطأ الثاني
لا نقلل.
أي مصطلح يتبادر إلى الذهن هو التقليل . بالتأكيد ، يمكنك الاستفادة بسرعة من المشروع. ولكن لزيادة العوائد ، اضرب الوقت المخطط له
مرتين على الأقل . خاصة في مشروع معقد ومحمّل بدرجة كبيرة ، والذي ينمو بشكل مطرد في حركة المرور بأكثر من 100٪ سنويًا.
لماذا على الأقل مرتين؟ إذا كان المشروع غير مستقر ولم يتم بحثه ، فاستعد لحقيقة أن أي نشاط سيؤدي إلى أنشطة أخرى في الأماكن المجاورة. يبدو أن استبدال الأقراص - وهو أسهل؟ يكون الإجراء بسيطًا إلى أن تصادف عملية شراء ، ثم جدولة وقت العقد المحددة ، ثم الصيانة بعد استبدال القرص. قدرت هذه العملية البسيطة في الأسبوع. في النهاية ، استغرق الأمر أسبوعين ونصف - حتى مع وجود خطة شراء بسيطة.
مثال آخر هو شراء وتركيب معدات جديدة. شراء والعصا ، ما هو الصعب جدا؟ لم تأخذ أكثر من شهر لهذا دون مراعاة وقت التسليم. في الواقع ، لا يزال أحد الهياكل الثلاثة يقف أمام مكتبي. وذلك لأن المعدات ببساطة لم يكن لديها مساحة كافية - قمنا بحساب المكان في الثقوب بين التثبيت الحالي. عندما وصلنا إلى أحد مراكز البيانات بقصد هز الرف ، أدركنا فجأة أن الخادمين "لا يمكن المساس بهما". الأول هو المضيف ، وهو ببساطة غير آمن للمسه. والثاني هو سلة مكونة من 16 قرصًا ، يتم إيقاف تشغيلها وهو محفوف بكومة من كومة البيانات. لم يتم وضع القش ، ولم يتم إجراء التحليل ، ومن الجيد أن يتمكنوا من الالتصاق اثنين من أصل ثلاثة.
إذا بدا أن كل شيء سيكون بسيطًا ، فستواجه قريبًا مشكلات . أثار هذا التثبيت سؤالًا جديدًا - إذا كان كل شيء سيئًا للغاية في المكان ، فكيف سنوسع؟ مهمة صغيرة الآن ولدت عرق عملاق. في عام 2020 ، وفقًا للخطة ، نقل مركز بيانات واحد إلى آخر وتوسيع الباقي بواسطة الرفوف. هذا يعني الترحيل داخل مركز البيانات بين الوحدات. تم استكمال عملية الترحيل بإعادة هيكلة الشبكة ونقلها إلى 10G.
لا تقلل من شأن التوقيت وعتبة الدخول والنتائج.
المفاهيم الأساسية
بالطبع ، تم وصف جوهر الأخطاء بالفعل في ويكي على أنه مفاهيم أساسية.
أي عملية بيروقراطية تستمر لمدة شهر على الأقل . وهذا ينطبق على المشتريات ، وإبرام شروط جديدة مع مركز بيانات أو مقاولين آخرين - على كل شيء. أعتبر كحقيقة.
بعد انتهاء العقد والدفع ، يستمر أي تسليم أسبوع ونصف على الأقل ، من الأقراص إلى المعالجات. تعلم التفاوض مع الموردين لتواريخ ما قبل التسليم. على سبيل المثال ، يتم شحن الأقراص على دفعات صغيرة إلينا الآن حتى الدفع وحتى قبل الموافقة على التطبيق.
على الرغم من عدم وجود فهم واضح للتنفيذ ، إلا أن أي خطة لتنفيذ شيء ما تظل خطة. كلما كانت الخطوات أقصر ، كان ذلك أفضل.
على سبيل المثال ، للتبديل من MySQL إلى ClickHouse ، تبدو الخطوة الواسعة كما يلي: "لنملأ بعض الخوادم ، ثم ارسم تذكرة لإعادة الدمج والانتقال!" في الواقع ، أدت دراسة مفصلة لهذه المشكلة إلى خطوات جديدة: شراء معدات إضافية ، على سبيل المثال ، المعالجات والأقراص ، وتذاكر مفصلة لتغيير منطق متتبع سلوك المستخدم ، والحفاظ على التكامل العكسي ، وخوادم قائمة الانتظار ، وغيرها الكثير.
كلما كانت الخطة أكثر تفصيلاً ، كان ذلك أفضل. إن الكتابة بضربة عريضة هي ضمان لخطأ 100٪ في الموعد النهائي.
إخضاع أي خطة لأقصى قدر من النقد وتوقع أقصى قدر من المخاطر . تأكد من إلقاء نظرة على الخطة من وجهة نظر العمل - ما هي الأرباح التي تحققها كل خطوة.
كان علينا تنفيذ تطبيقات إلزامية: المراقبة ، Ansible ، لكننا لم ننس عنصر الأعمال.
- من خلال تغيير بنية الشبكة ، سنكون قادرين على قبول حركة مرور إضافية وحل العديد من المشكلات الحالية.
- من خلال تغيير نوع تخزين المحتوى ، سنقوم بتقليل عدد الأخطاء مع عودة الكتب وزيادة سرعة العمل مع البيانات.
- قم بنقل الواجهة الخلفية إلى السحابة - قم بتوسيع الحمل على الفور أثناء حملات التسويق.
- تُعتبر ترجمة التتبع إلى ClickHouse فرصة للمحللين لفهم احتياجات القراء والمستمعين المحبوبين لدينا بشكل أفضل.
أفضل طريقة للتعامل مع الموقف الذي تكون فيه ضليعًا في الموضوع هي طلب مساعدة المتخصصين ، وليس Stack Overflow . الاتصال الصوتي يحل المشكلة عدة مرات أسرع من المراسلات الطويلة أو قراءة الوثائق.
بعد ستة أشهر
على الرغم من حقيقة أن المهام الجذرية التي استندت إليها في البداية كانت لا تزال تنزلق ، بفضل البحث والتصحيحات ، ظهر شيء جيد على يدي.
أداة مكتوبة ذاتيا لجرد الشبكات والعناوين. قام بانتظام باستغلال جميع الشبكات الفرعية الخاصة بنا والتحقق من البيانات مع تكوين BIND. جعل هذا الأمر من السهل والسريع تشغيل خدمات جديدة وفهم الحمل الحقيقي لتجمعات الشبكة. لم أرغب حقًا في قضاء بعض الوقت في ذلك ، لكنني لم أجد بديلًا جاهزًا ، واستغرق البحث عن عنوان لتخصيصه لمورد جديد الكثير من الوقت. أثناء كتابة الأداة ، ظهرت المسودة الأولى للخطة على الشبكة.
الدمية لم تعد ميتة ومشوشة . كنت مسلحًا باستنتاج من الخطأ رقم واحد ولم أحاول حتى الانتقال إلى Ansible ، وهو الأمر الأكثر راحة بالنسبة لي.
أكثر أو أقل تزوير Nagios . لقد نقلته من المكتب إلى مركز البيانات وقمت بتوزيعه في ثلاث نقاط. كان أسرع بكثير وأرخص من تطبيق Zabbix. لقد قمنا بتوصيل فتحة بها تنبيهات غير صحيحة في الوقت والأحداث ، وإعادة تشكيل بسيطة للقواعد وإدخال نقاط تحكم إضافية.
فهم صيانة مجموعات قاعدة البيانات المستخدمة.
ويكي منتفخة بشدة . وقالت إنها "حصلت على الدهون" من التعليقات والتعليمات على العمل مع البيئات.
ثلاثة هيكل HP الذي اشتريناه للتثبيت في المستقبل.
فهم المسار إلى ما تبقى من 2019 في تقريب أوضح.
النظام البيئي المعاد تدويره لعمل الإدارة.
كل هذه الستة أشهر عملت وحدي تقريبا. الموظفون الذين ورثوا هم أكثر مسؤولي النظام. لم يكونوا حريصين حقًا على الخوض في جوهر DevOps.
بصعوبة كبيرة ، وجدت اثنين من المتخصصين في الفريق - صغار ومتوسطي. لقد جمعت أكبر قدر ممكن من المعرفة والظهور وكلمات المرور من المسؤولين الحاليين وافترقت معهم بقلب شديد.
نظام العمل والبيئة والأدوات
سأخبرك عن أهمية إدخال نظام بيئي وبيئة عمل. لقد ذكرت بالفعل تريللو ، لكن لم أقل لماذا ولماذا قمت بتنفيذها. لن يتم بناء أي عمل بدون تحديد الأهداف والبيانات المنظمة. يتضح هذا جزئيًا من الخطأ الأول - جمع كل ما هو.
خذ كل شيء ، لا تعطي أي شيء.
العملية هي محرك التقدم . لذلك ، عملت طوال هذا الوقت على النظام ، على الرغم من عرقلة البحث وسير العمل. بفضل النظام ، بعد ستة أشهر وضعت قاطرة البخار للقسم على قضبان مستقرة.
إن توفير أدوات الدعم والدورة القصيرة حول استخدامها يوفر الكثير من الوقت لك ولزملائك. خاصة إذا كنت في القمة تفهم في الإدارة وقدرتك قليلاً على الحفاظ على النظام على سطح المكتب وفي الحياة.
نحن لا نعقد الأدوات ، نذهب من البسيط ونقدم ما يلزم . في بداية العام ، فكرت في تعقب المهام الذي يناسبنا. طرد فورا جيرا و Redmine - الكثير من السيطرة. سنقضي الوقت في ملء النماذج ، وليس المهام. صفحات Google - أعتقد أنه لا يستحق شرح لماذا لا.
كان تريللو مثاليًا . بعض الأعمدة البسيطة: "Backlog" - حيث تضاف جميع الأخطاء أو المهام الملحوظة للمستقبل ، "للإكمال" - المهام الرئيسية التي يجب القيام بها ، و "إنهاء". بعد ذلك بقليل ، كان هناك خمسة أعمدة: "تراكم" ، "وقفة" ، "سبرينت" ، "إنهاء" و "دراسة".
في "وقفة" نفذت الأشياء التي فقدت أهميتها في عملية العدو. في "التعلم" - المهام التي تتطلب البحث ويجب ألا تضيع حتى لحظة فهم المعرفة ونقلها إلى الويكي. أصبح سبرينت دليلاً على أننا قد تحولنا إلى نظام العدو. جربنا واخترنا التوقيت الأمثل - أسبوعان. نستخدم هذا الجزء الآن ، ولكن هناك مقطع آخر يناسبك.
وقت العدو هو فردي لكل شركة .
الاجتماعات الأسبوعية الإلزامية هي الابتكار التالي بعد Trello. نحن لا نعمل عمليا في المكتب. في الوقت الذي يمكن أن نقضي فيه على الطريق ، نكرس أنفسنا للعمل. ولكن مرة واحدة في الأسبوع ، يجتمع القسم بأكمله في المكتب لمدة 2-3 ساعات بشكل متقطع ، ويناقش مسار العدو والمهام التي نشأت. وفقًا لذلك ، بالإضافة إلى مرة واحدة كل أسبوعين ، نخطط للعداء التالي.
ثم ذهب تنفيذ الحد الأدنى من الأدوات اللازمة. تم نقل جميع مستودعات الخدمة ذات التكوينات - Puppet و Nagios و DNS - من SVN إلى GitLab جديدة. أنها مدمن مخدرات جينكينز له. الآن تم تحديث تكوينات DNS تلقائيًا ، ويمكن قراءة تعديلات زملاء Puppet عبر طلبات الدمج أسهل وأكثر ملاءمة. في السابق ، تم نقل كلمات المرور من شخص لآخر ، والآن يتم جمعها بدقة في 1Password. الآن هذا هو الحل الوحيد المدفوع في البنية التحتية.
من السهل تنفيذ وتهيئة الأدوات التي أنتجت العملية ، ومن السهل التحكم فيها.
المشاكل
في لتر نمت حركة المرور وأضاف العمل: مجموعات الفشل ، وقطع مكسورة من الحديد ، والمكونات. كان النصف الثاني من العام يقترب ، والذي تم التخطيط لتطويره.
في هذا الوقت ، ظهر اثنان من أكثر الكتب مبيعًا - كتاب جديد لمؤلف شهير ومرسوم من رئيس دولة صديقة بشأن حظر الكتب. سكب على نطاق واسع الشكاوى حول عدم إمكانية الوصول إلى الموقع. تم إصدار المرسوم منذ وقت طويل ، لكننا لم نعرفه إلا عندما بدأوا في حظرنا حقًا عبر مجموعة كبيرة من العناوين. لحسن الحظ ، أشار المرسوم إلى اسم مجال واحد فقط - "litres.ru".
زيادة عدد الزيارات (أراد الجميع مبيعًا) من خلال الوكلاء ، لقد أخطأنا في الهجوم على DDoS ودفعنا ثمنها بعملة صعبة. أتذكر كيف دفعنا فواتير إحدى الشركات التي وعدتنا بالحماية من DDoS. بعد الدفع مباشرة ، قمت بتبديل DNS إلى عناوينهم ، وبعد 10 دقائق تذكرت الخطأ الأول وقمت باستعادة DNS بشكل محموم. لم يكن هناك أي حركة مرور للقمامة ، ولكن كان هناك ثمن خيول لحركة المرور التي تمر عبرها - الكتب والصوت والأغلفة. لن أقول كم كلفنا 20 دقيقة من الحياة في عناوين الآخرين.
في ذلك المساء اتصلت Cloudflare وتحدثت عن مشاكلنا. Anti-DDoS . , Cloudflare . . , DDoS' , .
. KPI.
KPI
. . , , .
KPI. — .
- . — .
- Downtime. — .
- . , --, , . , .
KPI, — . , , KPI, .
. 90%. , . — , . . , .
-Nagios -Puppet Zabbix Grafana Ansible. « ».
Prometheus , Zabbix. Zabbix, Prometheus — . — . .
, , .
. ,
, . — . , .
. - -, - . , . . . . .
, .
2 . 3 « », — . .
. : , , , Ansible, .
. , . . .
.
— , , . .
. — , .
. , . . 2019. , , , — . .
. .
.
, - , . .
- , , .
- , .
- , , — .
- , , , — , .
. , - . , , , .
.
— , , . , , .
, — - . , .
« , ». , — , , , .
, , .
—
Ansible? , , Puppet ? — .
CI/CD? , . CI/CD , — .
., , . - ? , KPI? , -.
- — , , .
.
:سيعقد مؤتمر DevOpsConf المهني القادم في الربيع. لا يزال البرنامج قيد التطوير - اشترك في النشرة الإخبارية ، فأخبرنا متى نحدد التواريخ والموقع. وسيتم عقد الاجتماع القادم لمهندسي DevOps في HighLoad ++ 2019 في نوفمبر. يحتوي قسم DevOps على 13 تقريرًا عن أعباء العمل في AWS ، ونظام مراقبة في لامودا ، وسيارات لنقل النماذج ، وحياة بدون Kubernetes ، والحياة مع Kubernetes ، والحد الأدنى من Kubernetes وأكثر من ذلك بكثير. انظر القائمة الكاملة للموضوعات والملخصات في صفحة منفصلة " تقارير " وحجز التذاكر . سيتم عقد HighLoad ++ هذا العام في ثلاث مدن في وقت واحد - في موسكو ونوفوسيبيرسك وسانت بطرسبرغ. في نفس الوقت كيف سيكون وكيف تصل إلى هناك - تعرف على صفحة الترويجي منفصلة الأحداث.