كيفية قياس النجاح. استراتيجيات المراقبة وعلاقتها بمشكلات العمل

قبل الإجابة على السؤال "كيف تقيس النجاح؟" ، عليك أن تفهم ما يعنيه "النجاح" بالنسبة لك. بالنسبة إلى Dev و Ops ، يختلف تعريف النجاح. بالنسبة لـ Dev ، يتم اختبار مشروع ناجح بالكامل. للتشغيل - الرصد. الاختبار والمراقبة ضروريان ، لكن الاختبارات لا تعطي تغطية 100٪ للمشكلة ، ولا يكفي 200 رد من HTTP للتأكد من أن النظام يعمل بشكل جيد. دافع ليون فاير في RIT ++ عن وجهة نظر مفادها أن DevOps لا تدفع لضمان أن جميع المقاييس في المراقبة تقع في المنطقة الخضراء. يدفعون لجعل المستخدمين سعداء . إذا كنت غير راضٍ - فالشركة تخسر المال ، ولا أحد يهتم بأن كل شيء أخضر.

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

عن المتحدث: ولد ليون فاير في جمهورية كانت صديقة في السابق ، لكنه نشأ في الولايات المتحدة. لقد بدأت البرمجة منذ سنوات عديدة ، وخلال ذلك الوقت عملت كمبرمج ومدير لم أكن قد عملت معه. شارك في الشركات الناشئة - بعضها كان أكثر نجاحًا ، والبعض الآخر لم يكن ناجحًا جدًا.

لسنوات عديدة ، يعمل ليون في OmniTI. تتخصص هذه الشركة في تطوير أنظمة قابلة للتطوير ، لذلك تتمتع ليون بفرصة فريدة لتصميم وبناء أنظمة للمواقع الأكثر زيارة في العالم - Wikipedia ، National Geographic ، White House ، MTV ، إلخ.

قبل الإجابة على السؤال "كيف تقيس النجاح؟" ، عليك أن تفهم ما يعنيه "النجاح" بالنسبة لك. لكل شخص ، ستكون الإجابة مختلفة.

إذا كنت تقرأ هذه المقالة ، فأنت على الأرجح تشارك في DevOps. هل أنت أكثر ديف من العمليات؟ أو ، على العكس ، Ops أكثر من Dev؟ بالنسبة إلى Dev و Ops ، يختلف تعريف النجاح قليلاً: بالنسبة لـ Dev ، بالطبع ، هو الاختبار.

الاختبار

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

افهمني بشكل صحيح ، الاختبار هو عملية إلزامية ، يجب أن يتم تضمينه في أي مشروع ، ولكن من الواضح أنه ليس كافياً لضمان النجاح .

هناك العديد من خيارات الاختبار المختلفة:

• اختبارات الأداء ؛
  
• اختبارات المستخدم ؛
  
• اختبار آلي ...
  

كم عدد طرق الاختبار التي تستخدمها - 1 ، 2 ، 3 ، 5؟ وماذا أنت لست مستيقظا في حالة تأهب ليلا؟ هل يعمل كل شيء في الإنتاج؟

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

هناك مشكلتان بسبب الاختبار الذي لا يكفي ببساطة. الأول ، بالطبع ، هو مشكلة البيانات . حقيقة أن المهمة تعمل محليًا ، ولكن لسبب ما لا تعمل في الإنتاج ، هي مشكلة قياسية.

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

Wolfe + 585 - أطول اسم أخير في العالم:

هوبرت بلين
Wolfeschlegelsteinhausenbergerdorffwelchevoralternwaren-gewissenhaftschaferswessenschafewarenwohlgepflegeundsorgfaltigkeitbeschutzen-vorangreifendurchihrraubgierigfeindewelchevoralternzwolfhunderttausendjahres-vorandieerscheinenvonderersteerdemenschderraumschiffgenachtmittungsteinund- siebeniridiumelektrischmotorsgebrauchlichtalsseinursprungvonkraftgestartsein-langefahrthinzwischensternartigraumaufdersuchennachbarschaftdersternwelchege-habtbewohnbarplanetenkreisedrehensichundwohinderneuerassevonverstandig-menschlichkeitkonntefortpflanzenundsicherfreuenanlebenslanglichfreudeundruhe-mitnichteinfurchtvorangreifenvorandererintelligentgeschopfsvonhinzwischensternartigraum،
الأب.

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

لذلك ، فإن المشكلة الثانية هي المشكلة مع المستخدمين .

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

حتى إذا كان هناك زر واحد في واجهة المستخدم الخاصة بك ، فسيظلون يجدون طريقة لكسر ما نقوم به.

أفضل مثال هو World of Warcraft .

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

كما هو الحال مع أي لعبة ، في محتوى World of Warcraft الجديد ، ظهرت أفكار جديدة ورؤساء جدد باستمرار. لعن أحد الرؤساء الجدد أحد اللاعبين الـ 40 في المجموعة. كان مبدأ اللعنة أشبه بالقنبلة الموقوتة - لقد أزالت ببطء حياة كل من حولها. أي أنه كان من الضروري الهروب إلى الجانب - كان هناك ميكانيكا كاملة. وكان كل شيء على ما يرام حتى ، في مرحلة ما ، قرر أحد اللاعبين الانتقال إلى المدينة أثناء المعركة ...

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

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

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

ربما كان المثال الأكثر مثالية مؤخرًا ، منذ حوالي عام - هذه هي اللوحة اليسرى . هذه وحدة npm على node.js تكشف المسافات قبل السلسلة (في بداية السطر). لن نناقش لماذا تم عمل هذه الوحدة. ولكن اتضح أنه تم تضمينه في الكثير من الوحدات الشائعة. في مرحلة ما ، قرر المؤلف أن لديه ما يكفي ، وأزال هذه الوحدة من npm ، وطار 70 ٪ من الرمز المكتوب في node.js.

إذا كنت تعتقد أن هذه حالة معزولة ، فأنت مخطئ.

هناك أيضًا الوحدة النمطية الفردية ، وهي الآن في الدقيقة. تحدد هذه الوحدة رقمًا زوجيًا أم لا.

لن نناقش حقيقة أن 3 ملايين شخص لا يعرفون كيفية التحقق من التكافؤ / الغرابة. ولكن هناك 12 وحدة أخرى تستخدمها! ولا يُعرف عدد الوحدات التي لا تزال تستخدم هذه الوحدات. إذا بدا لك أنه لا يوجد شيء لكسرها - هناك 5 إصدارات!

بالعودة إلى خرافنا - هناك المزيد من الخيارات:

• قصر النظر - لا نعرف ماذا سيحدث في المستقبل. Y2K مثال ممتاز. لم يخطر ببال أحد أن كل شيء مكتوب في كوبول سيطير في عام 2000.
  
• عدد خيارات الاختبار .
  

هناك مثال جيد مرة أخرى مع World of Warcraft - لديهم العديد من الأمثلة الجيدة حول هذا الموضوع.

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

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

• تغيير في بيانات المصدر. نحن حقا لا نعرف ماذا سيحدث غدا.
  

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

المراقبة

هناك أسباب عديدة لضرورة المراقبة:

• رمز الكمال غير موجود.
• أصبحت الأنظمة أكثر تعقيدًا ؛
• تزايد الاعتماد الخارجي ؛
• الترقب -> الرد ؛
• ...

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

ما يجب أن يغطي الرصد؟ - هذا كل شيء! هذه إجابة قصيرة ، ولكن يجب أن تغطي كل شيء.

كل هذا مجرد مجردة. في الواقع ، لدينا جميعًا قائمة تحقق نراقبها:

• البنية التحتية
  
• قواعد البيانات
  
• التطبيقات
  
• نقاط التكامل ؛
  
• وقت معالجة الطلب ؛
  
• الحمل ؛
  
• ...
  

قد يكون هناك مليون شيء. يجمع الكثير مئات وآلاف وعشرات الآلاف من المقاييس على أنظمتهم.

سنجمع الكثير من المقاييس لهذا:

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

يعلم الجميع ما هو تويتر. يعالجون 500 مليون تغريدة في اليوم - وهو رقم مجنون.

لكنهم معروفون أيضًا بأخطائهم. الأخطاء أسطورية في تعقيدها أو سهولة - أي جانب للنظر إليه.

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

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

"طالما أستمر في جني المال ، من المذهل بالنسبة لي أن الخوادم تعمل."

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

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

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

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

مراقبة الأعمال

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

كمثال حي ، الرسم البياني لقراءة ذاكرة التخزين المؤقت مألوف للجميع.

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

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

للقيام بذلك ، يجب علينا:

1. فهم المشكلة - ما الذي نحتاج إلى مراقبته بالضبط.

2. حدد الخط الأساسي - أي أنه يكفي أن سرعة تنزيل المستخدم لم تتغير حتى لا يستيقظ أحد في منتصف الليل عندما تتوقف القراءة من ذاكرة التخزين المؤقت عن العمل.

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

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

مثال: كان لدي عميل يضم 100 مليون مستخدم. كانت شركة تسويق عبر الإنترنت أرسلت الكثير من رسائل البريد الإلكتروني واستخدمت اختبار أ / ب. بالنسبة لهم ، قمنا بجمع 6 آلاف مقياس.

بدأ كل شيء ، كما هو الحال دائمًا ، بمكالمة. يرن الهاتف - هذا يعني حدوث شيء ما.

" لدينا مشكلة." شيء ما لا يعمل.

- حسنًا ، ما الذي لا يعمل بالضبط؟ ما يتم التعبير عن هذا في؟

- بدأنا في الحصول على دخل أقل.

- و؟

- لا يعمل شيء في النظام.

- لا أفهم ذلك. إذا كان الدخل أقل ، تحدث إلى فريق المبيعات الخاص بك. لماذا تتصل بي؟

- لا ، أنا متأكد من أن شيئًا ما في النظام لا يعمل!

- حسنا ، دعنا نرى.

الحمد لله كان لدينا مقياس الإيرادات ، حتى نتمكن من رؤيته. يظهر الرسم البياني حقًا أنه في مرحلة ما انخفض دخلهم بنسبة 15٪. نظرًا لعدد المستخدمين ، يعد هذا أمرًا مهمًا جدًا.

حسنًا ، يجب أن أنظر. بادئ ذي بدء ، أتحقق من سرعة التنزيل - عادي.

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

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

هنا مثل هذا الارتباط!

نحن محظوظون لأن لدينا هذه المقاييس. إذا لم يكن لدينا ، سنضيفها - هذه إجابة بسيطة للغاية.

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

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

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

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

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

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

- اسمع ، هل يمكنك مساعدتي بسرعة؟

- ماذا تحتاج؟

- هل يمكنك إزالة شارة American Express من الموقع؟

- بالطبع استطيع! لماذا فجأة؟

- كما تعلمون ، نتجادل معهم هنا ، وحتى نقبل أمريكا
صريح بشكل عام.

"أعتذر لأتساءل متى توقفت عن تناولهم؟"

- قبل عطلة نهاية الأسبوع ، في رأيي - يوم الجمعة أو السبت .

لن يضع أي شخص في عقله الصحيح مجموعة مترية على النسبة المئوية للتفويضات من نوع معين من بطاقات الائتمان! بعد هذا الحادث ، بالطبع ، وضعنا.

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

النجاح للعمل

بالنسبة للأعمال التجارية ، يمكن أن يكون النجاح مختلفًا ؛ ذلك يعتمد على الأهداف. الأهم من ذلك ، كيف يمكن قياس ذلك؟ تقليديًا ، نقيس أداء النظام ، أحيانًا كمهندسين ، وننسى أنه يمكنك قياس أي شيء.

على سبيل المثال ، يمكنك قياس إدمان الكحول الخاص بك. بالمناسبة ، أنا لا أمزح. يوجد في مكتبنا مسودة بيرة بأربع حنفيات. نظرًا لأننا جميعًا مهندسون ، قرر زميلي استخدام أجهزة استشعار Raspberry Pi لمعرفة كمية البيرة التي نشربها وأي منها.

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

بالصدفة ، وجدنا تطبيقًا آخر لهذا.

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

نكتة ، ولكن في النهاية كانت لديهم مشاكل خطيرة ، لأنه من السيئ بشكل عام شرب في العمل ، وحتى بيرة شخص آخر!

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

عادةً ما تكون معايير نجاح الأعمال التجارية تشتمل في النهاية على المال:

• الربح ؛
  
• الدخل
  
• التكاليف
  
• الفعالية.
  

مقاييس الأعمال:

• التسجيل
  
• المشتريات ؛
  
• مشاهدات الإعلان
• التحويلات ؛
• نسبة العائد
• كمية البيرة في حالة سكر

كل هذا له معادل نقدي. , , — , . , .

. . , , .

, — . , — , — , . , — 99- , SLA .

, , -.

, . , , , . , .

. , . . . , 3 , .

— . , , , , .

.

: , , , - .

, . , , , 50 % « », , .

1 ?

1-2 . . 10 000 , . , 10 000 , - .

1 . 600-700 . , 600 — , . , , . 800 , , — .

, , . 0 , - , ! .

, - . — , .

99- 50- , . , .

, — , DevOps — .

, , .

Value stream mapping — . , . , , , , , . , , .

:

1. MTTD (mean time to discovery) — , .
2. MTTR (mean time to recovery) — , .
3. , .
4. / .

, , , , . : « — . , , ».

, , . , .

. , — , , . , . .

— , , . , , , . — .

في 1 و 2 أكتوبر ، سيتم عقد مؤتمر محترف حول دمج عمليات التطوير والاختبار والتشغيل DevOpsConf Russia في موسكو .

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

تعال وانظر كيف لا يمكن فصل التطوير والاختبار والتشغيل .