المأساة (من
الألمانية Tragödie من
اللاتينية tragoedia من
اليونانية τραγωδία
الأخرى ) هو نوع من الأعمال الفنية المعدة للتدريج على المسرح حيث تؤدي المؤامرة الشخصيات إلى نتيجة كارثية.
تتم كتابة معظم المآسي في الآية. كتب هذه المأساة باروخ Sadogursky (
jbaruch ) وليونيد Igolnik (
ligolnik ). إذا كنا نتحدث عن DevOps على نطاق واسع ، فما هي إلا مأساة؟
تتميز هذه المقالة بخطورة الواقعية ، وتصور واقع تطور كبير للغاية ، مثل مجموعة من التناقضات الداخلية. تكشف عن أعمق تضارب الواقع في شكل شديد التشبع الشديد ، والحصول على قيمة الرمز الفني.
والآن ننتهي من لعب Belinsky ومرحبا بكم في القطع! هناك نص وفيديو. لا تأخذ رهائن!
كما تعلمون ، كان اليونانيون يعشقون مخططات فين. وسوف نعرض لك ما يصل إلى ثلاثة - وكل شيء عن DevOps.
هناك وصف تقليدي لـ DevOps - هذا هو تقاطع مجالات العمليات والتطوير وضمان الجودة. من المثير للاهتمام تاريخياً أن QA أضيفت هناك لاحقاً.
لكن اليوم سنتحدث عن شيء آخر - تقاطع التكنولوجيا والعملية والناس. حول ما عليك القيام به مع هذه المكونات الثلاثة للحصول على DevOps.
قارن الآن اثنين من الرسوم البيانية:
في بعض الأحيان يحدث ذلك.
شركة البنتاغون
لنبدأ القصة مع شركة أسطورية تسمى البنتاغون ، والتي تتعامل مع معاملات بطاقات الائتمان.
القانون الأول - رجال الاطفاء
الناس . بدأت الشركة عملها للتو ، ولديها ثلاثة مهندسين. جاء الثلاثة من نفس شركة الدفاع. الرجال أذكياء بما فيه الكفاية ، لذلك لديهم كل شيء: JavaScript ، Node ، React ، Docker ، microservices.
العملية . كيف يمكن أن تبدو العملية عندما يكون هناك ثلاثة أشخاص في الفريق؟ كانبان: إما على قطعة ورق أو تريلو. الرجال أذكياء ويفهمون أن هناك حاجة إلى ضمان الجودة منذ البداية ، وبالتالي اختبارات TDD والوحدات والتكامل. لا توجد عمليات ، وكلها لها جذر.
أدوات وفقًا لذلك ، لثلاثة أشخاص يقومون فقط بتربية شيء ما:
JIRA ،
GitHub ،
Travis CI ، إلخ.
لنتحدث عن كيف يعيش هؤلاء الناس على هذا المكدس الجميل. أولاً ، كما هو الحال في الشركات الناشئة الجيدة - نحن نشهد وننشر منتجًا وننتظر العميل الأول.
فجأة ، حدثت معجزة - قررت إحدى المنظمات التي تنظم أفضل المؤتمرات في الفضاء ما بعد السوفييتي الثقة في هؤلاء الرجال وإجراء معاملاتهم من خلالهم.
ماذا تفعل الشركة الناشئة عندما تحصل على أول عميل لها؟ يحتفل! وفي مكان ما حوالي الساعة الثالثة من الليل ، عندما يكون كل شيء في حالة
خاصة ، يتصل العميل ويقول إنه لا شيء يعمل.
بالطبع ، أولاً ، الذعر!
الخطوة التالية هي القتال! نحن ننظر إلى السجلات ، على سبيل المثال.
نظرنا ، نظرنا ، اتضح أن أحد أبطالنا الثلاثة - فازيا ، بعد عودته إلى المنزل بعد المهرجان ، ارتكب فكرته الصغيرة. نتذكر أنه بعد اجتياز الاختبار والاختبارات ، كل شيء يطير إلى الإنتاج.
حسنًا ، من منا لم يفشل في الإنتاج؟ لن نلوم فاسيا. ارجع إلى الالتزام السابق. لن! لسبب ما ، لا توجد مكتبة كافية ، تسمى لوحة اليسار.
بالنسبة لأولئك الذين لا يعرفون ماذا حدث للوحة اليسرى ، نقول. لذا ،
في 23 مارس 2016 ، انقطع نصف الإنترنت . بشكل عام ، تقوم وحدة اللوحة اليسرى في JavaScript ببساطة بإدراج مسافات على الجانب الأيسر من الخطوط. وكان نصف الإنترنت يعتمد بشكل مباشر أو عابر على هذه الوحدة. تمكن مؤلف الوسادة اليسرى بطريقة ما من الشجار مع أصحاب مستودع npm المركزي ، لذلك ابتعد عنهم ، وأخذ كل عمله. يعد npm بشكل عام نظامًا غامضًا: فهو لا يتحقق فقط عند إضافة وحدة نمطية جديدة للتنزيل ، بل يتحقق أيضًا من جميع الوحدات القديمة.
وهكذا ، ومرة تلو الأخرى ، تستمر مكافحة النار. والمشكلات هي نفسها طوال الوقت.
القانون الثاني - تركيب إنذار الحريق
أخبار الشركة: عجينة مرتفعة ، وجدت مستثمر ، استأجرت 27 شخصًا ، واحد منهم بخلفية عملية. ظهر 100 عميل وحتى الدعم الفني.
وبالتالي ، يجب أن تحصل العملية أيضًا على ترقية. ظهر سكروم عادي ، اختبار استكشافي. لقد أدركنا أن NoOps غير موجود على الإطلاق ، نظرًا لوجود Ops (إذا كانت البنية بدون خادم ، فعندئذ لا يزال الخادم موجودًا ، فهو ليس ملكك). نظرًا لأنه من الخطأ إيقاظ الفريق بأكمله ليلًا ، فقد ظهر مطور عند الطلب.
تبعا لذلك ، توسعت مجموعة الأدوات. على الأقل ، ظهرت قاعدة المعارف ، حيث يوجد الآن مرافق ، ويحتاج إلى البحث عن معلومات في مكان ما. حداثة أخرى هي
JFrog Artifactory : نظام يسمح لك بتخزين ما تم إرساءه بالأمس حتى تتمكن من التراجع بسهولة (الدرس باستخدام اللوحة اليسرى لم يذهب سدى) ، بدلاً من إعادة بنائه من جديد. وضعنا نظامًا لجمع السجلات والبحث عنها.
تمت إضافة
Pingdom - نظام مراقبة ساحر: تعطيه عنوان url ، ويخبرك إذا كان يعمل أو تعطل.
لذا ، في هذه المرحلة قاموا بجمع المال مرة أخرى. لذا ، نلاحظ. الجمعة ، الثالثة صباحا ، يتصل العميل. شيء لا يعمل: بطاقة Visa و MasterCard ، لكن American Express لا يعمل.
وكيف يتفاعل الدعم أولاً عندما يتصل العميل في الثالثة صباحًا؟ هلع!
ثم ندعو المصاحبة. خمن من هو في الخدمة؟ بالطبع ، فازيا! تخمين ما هي الدولة Vasya. أجل لكن Vasya يجمع نفسه ، وينظر إلى الدعم الذي أرسله ، ويقول إنه على دراية كاملة بهذا الأمر وقد فعل ذلك بالفعل. لذلك ، Vasya ببساطة يأخذ وإصلاح. الجميع سينامون. يبدأ استخلاص المعلومات يوم الاثنين.
في ما يلي مثال على مستند محدد ننتجه لقاعدة المعرفة ، بحيث يمكن العثور عليه بسرعة إذا تكرر شيء ما مرة أخرى. بالإضافة إلى ذلك ، يظهر أحيانًا للعملاء:
تعرض الوثيقة العناوين الرئيسية والأسباب والخصائص وقائمة الأحداث. يجب الإشارة إلى الأعراض ، مع إعطاء وصف فني لما تم كسره بالضبط وكيفية إصلاحه. أهم جزء من الوثيقة هو السبب الرئيسي وراء سقوط شيء ما.
في حالة Vasya ، لدينا تجاوز سعة قائمة انتظار السجل. تحتاج إلى مسحها من معاملات بطاقة الائتمان ، بالإضافة إلى زيادة حجمها. على سبيل المثال ، عند 42!
هذه العملية جيدة جدًا للتحسين الداخلي المستمر وتضمن تركيب "كاشفات الدخان" نفسها. السبب الثاني لأهمية هذا المستند هو تقرير العميل. بعض الخدمات ، بعد "الاستلقاء" لبعض الوقت ، تنشر أسباب ذلك.
في بعض الأحيان ، تتحول المشكلة إلى كارثة لدرجة أنه لا يستحق الحديث عنها.
في GitLab
في فبراير 2017 ، حذف شخص قاعدة بيانات إنتاج. فيما يلي التحليل الذي قام GitLab بتحميله:
لذا ، في مكان ما يوجد نسخة احتياطية ، لا أحد يعرف أين. ثم تم العثور على نسخ احتياطية ، ولكن تبين أنها فارغة. نعم ، هناك تفريغ قاعدة. ولكن تم صنعه في إصدار مختلف من postgres ، لذلك لا يتناسب. لدينا لقطات ، لكن ليس لديهم قاعدة بيانات. لم يعمل النسخ المتماثل من S3 إما بسبب نقص البيانات.
وبالتالي ، لم تنجح خمس تقنيات مختلفة للنسخ الاحتياطي للبيانات. نعتقد أنه لا يمكن نشر ذلك ، لأنه لن يثق بهم أي شخص آخر. ولكن ، اعتمادًا على كيفية التحدث عنه ، قد يغفر العميل. صحيح ، مرة واحدة فقط.
بالمناسبة ، ذلك الرجل الذي فعل ذلك حصل على ترقية. بالإضافة إلى ذلك ، قام بتغيير وضع تويتر الخاص به إلى
أخصائي قاعدة بيانات (إزالة) في GitLab .
الفصل الثالث - ذروة
إذن ما الذي يحدث في شركتنا؟ لقد قاموا بجمع المال مرة أخرى ، واستأجروا مجموعة من الناس - والآن لدينا خمسة مهندسي عمليات وشخص واحد يشارك في الأداء. يوجد مهندس رئيسي. ظهر فريق نجاح العملاء ، يغطي جميع الصناعات التي قد تحتاج إلى دعم. يتم تباطؤها حتى يتمكن بقية الفريق من مواصلة العمل. غالبًا ما يوجد في هذا الفريق مجموعة يمكنها بناء علاقات مع العمليات أو الدعم ، وهناك أيضًا بشكل دوري هناك تحتاج إلى إسقاط المهندسين على scrum ، أو على العدو ، أو لمدة شهر. نمت الشركة ، ظهر محامٍ ، مدير مالي. نمت قاعدة العملاء إلى 1000.
مع نمو الفريق ، يجب أن تتغير عملية التطوير.
ظهرت
SAFE - إطار يشرح ما يجب القيام به في حالة وجود الكثير من الفرق أو مراكز التطوير - أكثر من واحد. يمكن أن يؤدي عدد العمليات الموجودة في Safe إلى قتل الحصان ، ولكن إذا كان يمكن القيام بها جميعًا في وقت واحد. إذا استبعدت فقط تلك القطع المطلوبة في هذه المرحلة من تطوير الشركة ، فيجب أن يكون كل شيء على ما يرام.
يظهر اختبار النظام عندما يكون لدى الفرق الكبيرة احتياجات معينة أو إذا كان لديك نظام ضخم تحتاج منه لبناء شيء ما. يمكن لفرق الشحوم الفردية اختبار أنظمتها بشكل جيد ، ولكن يجب أن يكون الشخص مسؤولًا عن حقيقة أنه يجب تجميع النظام بأكمله في الإنتاج.
ماذا عن فريق العمليات؟ كما قلنا ، هناك خياران للقيام DevOps. الأول مخصص للكتاب وللحصول على إرشادات من Netflix و Google و Twitter. والثاني هو في الحياة الواقعية ، حيث لا يمكن الوثوق في جميع المهندسين بجذر الإنتاج.
يعد مسار التصعيد مفهومًا مهمًا يسمح لك بحل أي مشكلة في وقت معين ، لأنه في نهاية مسار التصعيد يوجد هاتف محمول لمدير تنفيذي ، بعد مكالمة تختفي جميع المشاكل في 5 ساعات و 58 دقيقة.
SOC II - مجموعة من المعايير التي يوفرها البائع للعميل. تؤكد هذه المعايير أن الشركة لديها حلول أمنية معينة ، وأساليب لتقسيم العمل.
Backlog - قائمة المشاكل التي يجب معالجتها لتحسين النظام. عادة ما يصبح المهندس المعماري الخلفي هو المهندس الرئيسي ، الذي يجب أن ينظر إلى احتياجات النظام واحتياجات المنتج وتحديد أولويات هذه المهام.
يتم بالطبع تحسين الأدوات أيضًا.
هناك المزيد من الأخبار. تمت ترقية Vasya. وهو الآن نائب رئيس قسم الهندسة.
الجمعة والسبت والأحد يمر - لا شيء يأتي. كل شيء يعمل. الجميع في حالة صدمة. يأتي يوم الاثنين ، يأتي محام إلى فاسيا ويقول أنه كان في مؤتمر للمحامين واستمع إلى LGPL 2.2 هناك. ليس لدى Vasya أي فكرة إذا كان لديهم LGPL 2.2.
عمل الناس لفترة طويلة ، ثم وجدوا LGPL 2.2. بحاجة إلى قطع. ولكن يتم قطع هذا عن طريق قطعة صحية من النظام ، ولم يقم أحد بإلغاء الإصدار غدًا. حسنا ، لا شيء ، تعامل مع هذا.
يأتي مدير الصندوق إلى فازيا:
- كم من المال تحتاج للخوادم والإنتاج؟ وضع الميزانية للعام القادم ...
- 42 - يقول فاسيا.
قمنا أيضا بحل هذه المشكلة.
يأتون إلى Vasya ويقولون أن هناك عميل محتمل ، لكنه يخشى أنه لم يكن لدينا مثل هذا العميل الواسع النطاق أبدًا ، ويريد أن يقتنع بأنه سيكون جيدًا. نعلم من التاريخ أنه في هذه المرحلة مات الجميع.
ولكن بما أنه يجب أن يكون لدينا نهاية سعيدة ، فقد أرفقناها بالمأساة اليونانية.
الخاتمة - التحسين الاستباقي
الآن دعونا نتحدث عن المرحلة الأخيرة من توسيع نطاق DevOps - التحسين الاستباقي. حول الوقاية من الحرائق.
لا تحدث تغييرات للناس. ولكن مع العملية - إلى حد كبير.
نظرًا لأن لدينا مهندس أداء ، يجب عليه مراقبة النظام بطريقة أو بأخرى. ظهرت إدارة الترخيص والأمن. أداء استباقي - نحن الآن نراقب بعناية أين تتحرك المؤشرات الرئيسية وتصلح الأشياء قبل اندلاع حريق هائل. عند توسيع نطاق منتج ما ، من المستحسن أن يكون لديك شيء يقول: إذا كنت تريد الحصول على خدمة صغيرة ، فيجب على الأقل أن يكون لديها مراقبة قياسية وسجلات وما إلى ذلك.
تبعا لذلك ، هناك أدوات تدعم كل هذا. على سبيل المثال ، أداة
JFrog Xray لمراقبة الترخيص والأمان.
Blazemeter - نظرًا لوجود أداء استباقي الآن ، تحتاج إلى إنشاء حمل بطريقة أو بأخرى. تظهر الأمور مثل خدمة المحاكاة الافتراضية للخدمة ، والتي تتيح لك استخدام كائنات وهمية لواجهات برمجة التطبيقات البعيدة ، لأنه ليس كل بائع تعمل معه يمكنه توفير واجهة برمجة تطبيقات تجريبية.
التحليل
دعونا نحلل بعض الأحداث من الأعمال السابقة.
تذكر الحالة عندما خطط فاسيلي ميزانية بإصبع في السماء؟ في العمل على أحد منتجاتنا ، أردنا معرفة الموارد التي تم إنفاقها عليها. بعد تجميع كل ما كان متراكمًا ، حصلنا على هذا الرسم التخطيطي:
اعتقدنا خطأً أننا كنا ننفق 80٪ على ميزة كبيرة أ - في الواقع ، لا يتطلب الأمر سوى 13٪. في الوقت نفسه ، يذهب ما يصل إلى 34 ٪ إلى إبقاء الأضواء مضاءة - الأشياء التي يجب القيام بها في المنتجات: إصلاح الأخطاء وتحديث المكتبات وما إلى ذلك.
في الواقع ، لا يوجد سوى مقياس موضوعي واحد لجودة المنتج: رضا العملاء ، والذي يتم التعبير عنه في دعوات الدعم.
المثال الثاني. كسرنا كل العيوب الحرجة:
65 ٪ من التذاكر تنتمي إلى المستويات الأولى من الأهمية. هل هذا كابوس؟
الآن خذ نفس البيانات وانظر إليها من زاوية مختلفة.
الآن يعكس الرسم البياني الوضع بعد استخلاص المعلومات. اتضح أن المهندس أغلق 52 ٪ من التذاكر باستخدام المعلومات المقدمة ، أي أنه كتب للدعم ما لم يعرفوه. تم إغلاق حوالي 20 ٪ فقط من التذاكر مع تغيير نوع الرمز. وهكذا ، اتضح أن البحث والتطوير ليس على خطأ. ولا يلام حتى الدعم. في الواقع ، كنا نفتقر إلى التدريب - وفاسيا ، مثل نائب الرئيس للهندسة ، بعد رؤية مقدار الوقت الذي يقضيه في كل أنواع الهراء ، أرسل مجموعة من المهندسين لتدريب الدعم.
قام الرجال بتصحيح الوثائق في الاختناقات وتصحيح السجلات. ونتيجة لذلك ، اختفت القطعة ، التي استغرقت الكثير من وقت المطورين.
الاستنتاجات
في جميع المراحل ، من مكافحة الحرائق إلى تركيب أجهزة الإنذار وحل المشكلات بشكل استباقي ، هناك العديد من العمليات والأشخاص والمتخصصين والمناهج والأدوات التي تحتاج إلى تثبيت. كل هذا لا يمكن القيام به في يوم واحد. بالإضافة إلى ذلك ، ليست هناك حاجة لبعض الأشياء في بعض مراحل التطوير.
من المهم أن نفهم أنه في الناس وفي العمليات والأدوات هناك حاجة إلى بعض التحسينات باستمرار.
ما يحتاج إلى تحسين بالضبط ، سوف نساعد في معرفة الأرقام التي تحدثنا عنها. فقط على أساس هذه البيانات يمكننا اتخاذ القرارات الصحيحة حول مكان استثمار الوقت وما يجب المضي قدما.
ولا تنس المبدأين الأساسيين لـ DevOps:
- أنت تبنيه - أنت تمتلكه.
- الألم تعليمي.
في يوم الأحد المقبل ، سيقدم باروخ وليونيد تقريرًا بعنوان "#DataDrivenDevOps" في DevOops 2018 في سان بطرسبرج. تعال ، سيكون هناك الكثير من الأشياء المثيرة للاهتمام: إليك التقارير ، وهنا جون ويليس ، وهنا حفلة مع BoFs والكاريوكي . في انتظارك!