في أحد الأيام ، تم استدعاء إيفان إلى اجتماع لمناقشة مقاييس DevOps.
أعد كل مشارك للاجتماع قائمة بمقاييس معينة ، في رأيه ، تستحق التنفيذ.
عند الاستماع إلى التقارير ، حاول إيفان حساب عدد المقاييس المقترحة: 5.10 ، ومرة أخرى 10 ، وحوالي عشرة. اتضح 30 مع شيء.
لسبب ما ، جاءت الفكرة فجأة أن الناس تجمعوا ببساطة غوغل وكتبوا تلك الأسماء التي تبدو مثيرة للاهتمام لهم. على ما يبدو ، لم يفكر أحد في جوهر المقاييس.
يراقب من الجانب ، سأل إيفان نفسه الأسئلة: لماذا؟ لماذا بالضبط هذه المقاييس؟ ماذا سوف يعطيك؟ أصبح من الواضح فجأة أن الاجتماع جمع أشخاصًا كانوا بعيدًا عن الفهم الحقيقي لطبيعة المقاييس ، وأن كل شيء سينتهي كالمعتاد ، وذلك بفقد قدر كبير من الوقت وإلقاء العمل في سلة المهملات.
أصبح حزينا ومهينا. إنه لأمر مخز أن وقت الشركة وأموالها لا تذهبان إلى أي مكان ، ومن المحزن أن عملًا مفيدًا لن يتم.
لقد ظل إيفان يدرس المقاييس لفترة طويلة وفهم لفترة طويلة أن الموضوع خطير ومعقد للغاية ، وأنه من المستحيل التعامل معه من خليج الزورق على أي حال.
في ذلك اليوم ، انتهى الاجتماع بكل شيء ولا شيء - قررنا تنفيذ كل شيء في وقت واحد (لم يرغب أحد في تحمل مسؤولية الرفض ، لأنني لم أفهم لماذا يحتاج شخص آخر إلى هذه المقاييس).
قرر إيفان إعداد رؤيته لمقاييس DevOps ، والتأكد من أن كل مقياس له ما يبرره فيه ، وكان له غرض محدد ، وكان مفيدًا ومفهومًا.
هذا ما فعله ...
ماذا تريد أن تدار؟
بادئ ذي بدء ، قرر إيفان أن يفكر في الهدف الرئيسي ، والذي يتم إجراء المقاييس الخاصة به.
اقترح كل من الكتب التي تمت قراءتها جيدًا Lean Analytics و Practice of Tao Toyota: اختيار الرقم الذي تريد التحكم فيه كمقياس رئيسي. بعد ذلك ، حدد مكونات هذا الرقم التي يمكنك التأثير عليها كمقاييس.
أعلن هدف DevOps في الاجتماع الأخير "جودة البرمجيات" ، ولكن مفهوم الجودة كان غامضًا للغاية. ما هي الجودة؟ كيفية التعبير عنها في رقم واحد؟ ما المكونات التي تؤثر عليه؟
لسوء الحظ ، لا يمكن التعبير عن جودة البرنامج برقم واحد.
على أي حال ، هو الغرض من استخدام DevOps الجودة حقا؟
قبل عامين ، عمل إيفان مديراً لتكنولوجيا المعلومات في شركة صغيرة تنتج برمجياته الخاصة ، وهناك أطلق بنجاح DevOps واستخدمه. والغرض من هذا DevOps لم يكن حقا الجودة على الإطلاق. بدلا من ذلك ، الجودة أيضا. كان الهدف الرئيسي والوحيد هو القضاء على العمل اليدوي خلال عمليات النشر في حفلة موسيقية.
عن طريق إزالة العمل اليدوي ، حقق هذا التسارع وتقليل عدد الأخطاء التي أصبح من الممكن إطلاق تحسينات مرة واحدة على الأقل في الدقيقة.
وهكذا ، اتضح أنه كما
TARGET METRIC DevOps في حد ذاته يوحي نفسه
وقت التسليم
إن انخفاضه أو زيادته على وجه التحديد سيظهر تأثير القرارات الإدارية المتخذة.
زاد وقت التسليم (الوقت للسوق ، TTM) - بشكل سيء. انخفضت - ممتازة.
لكن وقت التسليم يعتمد على حجم المهمة وعلى مدة الاختبار وعلى العديد من العوامل الأخرى! نعم هذا صحيح.
ولهذا السبب قرر إيفان عمدا بدء العد التنازلي ليس من لحظة الترميز والتحليل ، ولكن من اللحظة التي تم فيها إنشاء التجميع (التوزيع) بالفعل وهو في التخزين وكل ما تبقى هو إجراء سلسلة من الفحوصات ونشرها على بيئة صناعية (ما يسمى التسليم المستمر ، CDL).
من المهم هنا أولاً تطوير مبدأ ، مفهوم ، يعتقد إيفان ، وتوسيع نطاقه ليشمل مناطق أخرى لم يتم الوصول إليها ، لأن الترميز والتجميع وجميع خطوات التطوير الأخرى تؤثر أيضًا على وقت التسليم تمامًا مثل مرحلة CDL. دعونا نفعل ذلك في واحدة - سنفعل ذلك في الآخر.
في الشركة الكبيرة التي يعمل فيها إيفان ، كانت المقاييس حيوية. رأى الآلاف من المطورين الشفرة وصنعت مئات من التجميعات يوميًا ، لكن لا أحد ، لم يكن أحد في الشركة يعلم كم من الوقت تقضي فرق العمل فعليًا على DevOps.
تدفقت الشكاوى من جميع الجوانب: DevOps هراء ، لا يعمل ، تباطأ بشكل رهيب ، لا معنى له. لكن لم يكن لدى أي شخص أرقام حقيقية ، وكان من المستحيل إثبات أو دحض تصريحات الفرق.
كان هذا هو الهدف الذي حدده إيفان لنفسه - لحساب الوقت الذي تقضيه الفرق في DevOps ، وعلى وجه الخصوص في مرحلة التسليم للجمعية.
لا يمكن أن يكون هذا ، حسب إيفان ، إذا أطلقت DevOps ذات مرة وأعطت تأثيرًا فوريًا ، فلماذا لا يكون الأمر هنا؟
أصبح إنشاء نظام من المقاييس مسألة شرف لإيفان.
السيطرة على ما يمكنك التحكم
كيفية إدارة وقت التسليم؟ هل هذا ممكن؟ - سأل ايفان.
إذا نظرنا إلى وقت التسليم كرقم ، يصبح من الواضح أن هناك أماكن في عملية DevOps تؤثر بشكل كبير على هذا الرقم.
كان لدى شركة إيفان معيار: كل مجموعة قبل الذهاب إلى الحفلة كان من المفترض أن تجتاز ثلاث مقاعد للاختبار ، والتي تم اختبار جوانب مختلفة من البرنامج عليها.
من الطبيعي أن "المجموعات" عليها "سقطت" بسبب الأخطاء ، وأنشئت مجموعات جديدة بدلاً منها.
اتضح أن المدرجات هي العناصر الرئيسية لوقت التسليم الكلي ، وأنها هي التي تؤثر على الوقت الكلي ، وزيادة ذلك.
وقت التسليم = الوقت في موقف 1 + وقت في موقف 2 + وقت في موقف 3بالتأثير على الوقت الذي تقضيه الفرق في كل جناح ، سيكون من الممكن التأثير على وقت التسليم النهائي.
بقي سؤالان بسيطان:
- كيفية حساب جسديا تكاليف الفرق على المدرجات و
- ماذا تفعل مع التوقف بين المدرجات (التوقف هو أيضا أحد مكونات وقت التسليم)؟
لم يكن لدى إيفان أي خيار سوى الغوص في غابة جنكينز ونيكزس (البرنامج المستخدم في CDL).
جنكينز ونيكزس مساعدة
تم تنفيذ مجموعة "Roll" على الحامل باستخدام جنكينز. في الواقع ، Jenkins هو sheduler منتظم ، مثل crontab ، ولكن مع ميزات متقدمة.
يعرف جنكينز كيفية عرض سجلات جميع الوظائف قيد التشغيل (مهام لتدوير التجميع على الحامل) في شكل RSS ، وهناك بداية ووقت انتهاء ورابط إلى مجموعة محددة.
اتضح أنه تحت تصرف إيفان حصل على بيانات في الوقت المحدد لبداية ونهاية أعمال التجميع ، أي كان من الممكن حساب الوقت الصافي الذي تقضيه الفرق على المدرجات بسهولة ودقة.
وإذا قمت بتفريغ البيانات من جميع المدرجات في قاعدة بيانات واحدة ، فيمكنك حساب وقت التوقف بين المدرجات. كان ذلك رائعا!
من Nexus (تخزين ملفات الشبكة) كان إيفان بصدد الحصول على تاريخ إنشاء التجميع نفسه ، وهكذا تحديد لحظة ظهوره والنقطة المرجعية.
كل شيء سقط في مكانه. تقريبا.
- وكيفية إدارة هذا ، فكرت إيفان؟ ..
أن تستمر. موضوع التأثير